Niagara Emitter Communication

[Aphi]

I’ve run into a bit of a wall with Niagara, I feel should be easy to solve, but after a lot of deep diving I’ve only found complicated or non-performant solutions to the problem.

Say I have a particle system that spawns particles from the emitter location that fly off in random directions. From those particles I want to then have Sub-particles that spawn around the Main particle and have their own behavior before flying back to the position of the Main particle. This seems like something that should be easily doable – for example ribbons are often added to particles and almost share that same kind of behavior.

However, what I’ve found is that when I create two particle systems – one for the Main particles and one for the Sub particles that break off from the Main, move around, then fly into the Main – there is no way to reliably handle the Sub-particles retrieving the position of their parent particle from the Main emitter.

I was guided to look at the Follow the Leader example in the “Niagara Advanced particles” system in the official Content Examples project. However this kind of setup using the attribute reader seems to only work if the Main and Sub emitters are given a fixed amount of particles that are spawned as a burst and never killed.

If we try any other way of setting up this system using a Spawn Rate or continually spawning particles on Main/Sub/both then the attribute reader will proceed to - presumably - error out and only send/receive default 0 values. My assumption is that it hits an error and reports default values instead. I thought maybe this was related to the Sub emitter using an invalid ID that breaks it for the rest of the system, but even when making the Main emitter burst spawn one particle and Sub continuously spawn to read a fixed ID it still seemed to only read incorrect values.

As far as solutions go, I know I could make each Main particle instead just it’s own Niagara System, this would let me just use the Emitter Location and solves the whole deal, but for environmental effects this is a bit costly and would require a Blueprint to handle spawning the Main particles.

Curious to see how others may have solved this issue

[Niels]

The particle attribute reader should still be the solution you’re looking for.

The data interface can read either by index or by id, so typically the trick is to, in the sub particle spawn script, find some valid index (by getting the number of particles in the main emitter), and caching off the id of that particle. Then, while doing the follow behaviour in the update script, use the id to find the main location as well as check if the ID is still valid, and if not, either remove the sub particle or find a new valid main particle to follow.

[Aphi]

I’ve done some testing and found that when Spawn Rate is ticked on either or both emitters it will never correctly find a parent ID. I’ve included most of what I’ve done below.

Perhaps Spawn Index is not a consecutively assigned value but a randomly hashed value when not assigned as instantaneous burst, but this wouldn’t make sense when Spawn Rate is set on the Sub emitter. There may also be some kind of optimization on UE’s side that just breaks the nodes as they are still marked experimental, I’m not so sure

[Niels]

I think GetIdBySpawnIndex is just the particles that spawned this frame. There should be a node that let’s you fetch the id, position, etc, using buffer index

[Aphi]

Ah, I misunderstood the difference between GetIdByIndex and GetIdatSpawnIndex.
This was it, things are now working as expected, thanks for taking the time to answer this!