We are currently testing the Niagara Data Channel (NDC) in our project. However, according to the tutorial (Niagara Data Channels 5.4 Update | Tutorial), it appears to only work for hit effect types or effects that don’t require runtime position updates.
What can we do if we need to update the effect’s location at run time? For example, I have multiple bullets spawned, like over 50 or even more, and each has a trail effect attached to bullets. Currently, we just spawn a new niagara system(same effect system) and attach it to the bullet, but it costs a lot of CPU time as we have to execute the system spawn/update scripts for each spawn trail system.
Is NDC capable of handling this case? Or are there other ways that could help?
Hi there, interesting in the same thing. I’ve managed to write a custom logic to delete particles based on index assigned to them from NDC that spawned it, but didn’t find the way to push update of what index to delete from another NDC.
The problem we are facing now is that we can not guarantee that the index of the updated position matches exactly with the particles spawned from the emitter, especially when some particles die and new particles are born.
Currently I’m trying to push int32 index from NDC when spawning is started and assuming that all the control over that index is done in some C++ class manager. But actually I still didn’t manage to pass an array of positions to update all particles…
Not sure I’m doing it the right way honestly From what I see now looks like Data Channels is more suitable for hit & forget kind of systems
What I’m trying to do is to spawn bullets singular particles in first emitter using NDC and then generate the trail of particles behind each bullet using child emitter by receive event + update the positions…
I was thinking that we could identify the spawned particle by using NiagaraID?
NiagaraID is composed of two values:
AcquireTag: It’s the tickcount for the current emitter instance, the same as Emitter.TickCount, which you can access from the module script.
Index: the index of the total spawned particle in this tick.
So on the C++ side, we could use the NiagaraID to store and update the position array, and some data manager stuff to do that. And in the Niagara module script, we can retrieve the correct data(ie, updated position) for this particle by using NiagaraID as well.
Maybe it’s worth trying.
(If it works, then we could do the same trick with the Niagara data interface array as well)
From what I see now looks like Data Channels is more suitable for hit & forget kind of systems
