Missing Chaos Notify events in Bleuprint?

Development Asset Creation
, ,
1

Hi, I had a quick question about chaos notify events. I’ve noticed in blueprint you are able to read Collision, Break, Crumble and Removal notify events, but there is no Trail event. I was surprised this was not here, because the Niagara Chaos DI does have access to it. Was wondering if I’m missing something?

I did notice you can also use a Chaos destruction listener, where you have access to trail events. Is this what should be used instead? It didn’t feel very controllable for different types of assets as it will pick up anything and this only has Trail, Collision and Break events available but no Crumble or Removal?

Similarly Niagara Chaos DI doesn’t have access to Crumble and Removal. Wondering if this is something that was overlooked?

Many thanks,

Niels

2

Steps to Reproduce

  • Add a geometry collection to a Blueprint

  • No trail event will be available

  • Add a Niagara Chaos DI to a level

  • No removal or crumble data will be available

3

Hello [mention removed]​

I’ve checked the source code for the GeometryCollectionComponent, and indeed, the events available to BP are only OnChaosBreakEvent, OnChaosRemovalEvent, and OnChaosCrumblingEvent:

`DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam(FOnChaosBreakEvent, const FChaosBreakEvent&, BreakEvent);

DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam(FOnChaosRemovalEvent, const FChaosRemovalEvent&, RemovalEvent);

DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam(FOnChaosCrumblingEvent, const FChaosCrumblingEvent&, CrumbleEvent);

DECLARE_DYNAMIC_MULTICAST_DELEGATE(FOnGeometryCollectionFullyDecayedEvent);

DECLARE_DYNAMIC_MULTICAST_DELEGATE(FOnGeometryCollectionRootMovedEvent);
DECLARE_MULTICAST_DELEGATE_OneParam(FOnGeometryCollectionRootMovedNativeEvent, UGeometryCollectionComponent*);

…

UPROPERTY(BlueprintAssignable, Category = “Chaos”)
FOnChaosBreakEvent OnChaosBreakEvent;

UPROPERTY(BlueprintAssignable, Category = “Chaos”)
FOnChaosRemovalEvent OnChaosRemovalEvent;

UPROPERTY(BlueprintAssignable, Category = “Chaos”)
FOnChaosCrumblingEvent OnChaosCrumblingEvent;

// todo(chaos) remove when no longer necessary
FOnChaosBreakEvent OnRootBreakEvent;

FOnGeometryCollectionFullyDecayedEvent OnFullyDecayedEvent;
FOnGeometryCollectionRootMovedEvent OnRootMovedEvent;
FOnGeometryCollectionRootMovedNativeEvent OnRootMovedNativeEvent;`[Image Removed]

For Niagara Data Interface Chaos Destruction, like you already described, the Data Sources available are Collision, Breaking, and Trailing:

[Image Removed]

In Niagara, there’s also a Chaos Destruction Event User Parameter I’m not particularly sure how to use, and that one has, among other data, a Type variable whose exact purpose I was not able to determine:

[Image Removed]As you noticed, the Trail event is not available to BPs.

What is your use case? Let me know what exactly you are trying to do, and we can decide how to proceed.

All the best,

[mention removed]​

4

Hi [mention removed]​ thanks for the quick reply.

“In Niagara, there’s also a Chaos Destruction Event User Parameter I’m not particularly sure how to use” I had a similar experience here. Haven’t been able to figure out how it could be used.

To give context for the use case.

The Niagara Data Interface Chaos Destruction is great to use for setting up some quick prototyping on a destructible, but I’m apprehensive to use it on a larger scale. For it to work with realtime destruction, you always need the Niagara system active and placed in the world so it can pick up the events triggered by chaos destruction instead of dynamically spawning in the system. ( this feels quite backwards having to always load in a Niagara system in a level and pay for the overhead even when it’s not getting used)

If you just have 1 type of destruction and a Niagara system that’s fine, but once your destruction becomes more complex and dynamic and of different physical types etc, it would mean that you would need quite a few different Niagara systems actively running, waiting for chaos events to happen. (that or you would have to build some management system around it to decide what Niagara system should get loaded at which point, but datachannels would basically do this for you)

Hence why I was exploring the option to set up my own datachannels for chaos destruction. I’m a big fan of the datachannel Island workflow, because it can clean the up the Niagara system when it stops being used. I was looking at doing a simple datachannel write from my chaos event notifies in bp ( which works like a charm), instead of using the Chaos data interface. You have full control there to which datachannel you want to write the info to per chaos asset and it’s all dynamic etc. But since we don’t have trails available there, we can’t hit all our visual targets

Many thanks,

Niels

5

Hello [mention removed]​

Thank you for the reply.

I believe your analysis is correct: The way the system is currently set up, it’s expected to have all the NiagaraSystems enabled from the get-go, waiting for the Chaos events to pop up and using that to spawn its particles on the correct position and with the proper velocity. I haven’t checked this performance-wise, but I can imagine it becoming an issue when the number of Niagara systems increases.

Also, the lack of the trail event is limiting.

I’ll open up a ticket to bring this to the attention of the dev team.

All the best,

[mention removed]​

6

Hello [mention removed]​

Thank you again for reaching out and reporting this issue.

I’ve made a JIRA report to be added to the Unreal issue tracker website (https://issues.unrealengine.com).

Epic will decide if the issue will be made publicly accessible, and the whole process can take a few days, so keep that in mind.

If/once it is made publicly available, you will be able to track the resolution by checking this link:

I’ll close the case, but feel free to reply if you have anything else to add.

All the best,

[mention removed]​