Can someone please help me understand what makes up for Emitter State's module runtime cost in Niagara?

Hello, Niagara has a Performance button that shows the “module runtime cost in percent”. When looking at the Emitter State, what affects the runtime cost of that module? If you make an Empty emitter the Emitter State’s runtime cost is really high, but the emitter is empty, why is it high? Furthermore two very similar emitters can have different Emitters can have different runtime cost. Is the runtime cost of the Emitter State affected by Particle Spawn and Particle State? Is it affected by Emitter Properties?

from my experience it’s a sum of everything really. creating/instancing an Niagara system is costly, each emitter has an added costs, that’s why it’s better to combine multiple renderers into one emitter if you say you just want the same effect but a different mesh, texture or material.

In general you just run into problems if you’re trying to spawn Niagara systems all over the place as they just have a high instancing cost to exist in general, my take on this is that there’s just so much happening under the hood for Niagara to work that unfortunately you can’t just have such potentially complex systems exist everywhere.

It’s always better to pool them, update their positions and then animate them when possible, especially for things like bullet trails and other world spawneable effects.

Then it gets to each particle that has to be spawned, higher spawn bursts are more costly to instantiate then a higher spawnrate, to me it feels that the engine has to wait for all the particles to get created in a thread before it renders the entire system. this was especially noticeable on low end devices, like mobile/vr. spawn bursts just wasn’t smart to use :smiley: .

Finally you can check the costs of each module using the performance button.

this will show the miliseconds it takes to compile each module and you will notice they increase as your particle count goes higher, especially the modules in the update thread like curl noise and mesh rotations.

There’s also the Niagara baker where you can just bake out the entire simulation, which significant reduces overhead, but of course doesn’t allow for much dynamism.

Hope this helps a bit, there’s unfortunately not much resources about optimization

1 Like

Hi!!! Thank you this is really helpful and informative!! One thing I don’t understand, what does it mean “it’s always better to pool them”? What is pool them?

It’s always better to pool them, update their positions and then animate them when possible, especially for things like bullet trails and other world spawneable effects.

Can you elaborate on this please? It sounds important but I’m not sure I understand it. Niagara is such a joy to work with, I always love finding out new things about it and its potential

1 Like

Afaik pooling is spawning pre-emptively or loading it in memory before “Needing” it.

You can for example use “event begin play” to spawn your particle system and update the location whenever you explode a barrel or bullet effect.

I’ve heard of studios having pooled about 100 Niagara systems in a hidden arsenal location and their FX management blueprint will move them to the correct actor, Once it’s complete they put them back in their arsenal and re-use them later on.

There are different ways of doing it, so it is best to ask your friendly neighbourhood programmer how to properly set it up, as every game will be different.