Can the Niagara Data Channel(NDC) system support updating the attributes (such as position) of the Niagara system?
In our case, the same Niagara system will be spawned approximately 20-50 times within 2-3 seconds, resulting in a significant increase in CPU performance as each system (even the same one) has to run its system/emitter scripts. Additionally, the Niagara system will be attached to an actor that is updated/controlled by the gameplay code, such as the actor’s position.
We noticed that the NDC system tries to improve this kind of situation, but it seems more suitable for those Niagara systems that spawn and never move, for example, the hit effect. Any idea that the NDC can support this?
Of course, if you have another solution that could help, we are glad to hear it as well!
Thanks,
Joe
Hi, this sounds like an applicable use-case for NDC, even with the Niagara system attached to a moving actor. Just be sure to keep track of the transforms (world vs local space) depending on what sort of visual you’re aiming to create. If you have additional questions about this, feel free to reach out!
Hi Camille,
Thanks for the reply!
Let me add more information here. For example, we have a Niagara system called the cube system, and say the cube system only emits one cube; the gameplay side spawns 20 actors, and each of them has one cube system attached to it. Each actor has its own behaviours controlled by gameplay logic, like its position, rotation, and lifetimes as well.
By using the NDC system, we can write the transform information of each actor into the NDC buffer and read the data. In theory, we will maintain two data buffers, the spawn data buffer and the update data buffer. The spawn data buffer is fill with the data when a new actor was spawned by the gameplay side. And the update data buffer fills the data buffer with the information from actors that have already spawned.
But how to update the emitted particles’ attributes and make sure they’ve been updated properly? Remember that the actor has its own lifetime, this means some of the particles will die in the N frame and others might die in the N+1 frame, so the data array size changes dynamically.
The above situation differs from the NDC tutorial (https://dev.epicgames.com/community/learning/tutorials/RJbm/unreal-engine-niagara-data-channels-intro), which demonstrates the impact type of the Niagara system (hit, spawn particle, and forget it).
Do you have any suggestions for our case?
Thanks for the extra context.
If it’s only ever a single item (like a cube), it might be easier to manage if each actor just had a mesh component and your material of choice applied (omitting Niagara).
In the case that you need Niagara for additional visual effects, you could spawn new particles every frame for the current state and kill the old particles. They could still have persistent ribbons or other effects following these particles as long as the NDC data contains a persistent ID for each item that you generate a ribbon ID from. Better support for proper persistence is something that’s on the team’s radar, but the approach here is what we’ve used for similar situations.