Scalability and Best Practices for Niagara
- Emitter overhead: "Niagara uses a virtual machine for running its scripts on the CPU" for extensibility and parallelization; "With a VM that mimics the SIMD nature of the GPU, we can have all our Niagara scripts work for both CPU and GPU by default." Trade-off is per-emitter overhead. "Even when targeting your particles for GPU simulation, we still run the System and Emitter scripts on the CPU so they can interact with the game thread. This means the overhead is fixed, and the only way to avoid it is to reduce the number of emitters in a system or the number of instances in your level." 5.4 experimental Lightweight Emitters.
- GPU vs CPU: "Choosing between CPU and GPU simulations only changes the target of the particle simulations, that is, only the scripts in the Particle Spawn, Particle Update, and Simulation [Stages]... Particle scripts have the largest opportunity for parallelization, so they benefit the most from targeting the GPU, and in most cases GPU sims are more performant, and allow for a greater number of particles. For emitters with a small number of particles a CPU sim may be better suited, as GPU resources cannot be divided as granularly. The exact breakdown is hardware dependent, but a simulation of 1 particle can potentially take up the same resources as one with 64 particles."
- "in some projects, and on some platforms the GPU is the bottleneck, and CPU sims may be a better fit. This is especially common for platforms that have less GPU memory like mobile. The flipside can be true, and a project that is CPU bound may still benefit from moving simulations, even those with a small number of particles, to the GPU." Validate assumptions by profiling.
- Fixed vs Dynamic Bounds: "fixed bounds will be more performant than dynamic bounds since it requires less work." Exception: small effect travelling far (bullet trace) — fixed bounds much larger, relevant while out of view. cvars fx.Niagara.EmitterBounds.DynamicSnapValue / DynamicExpandMultiplier / FixedExpandMultiplier.
- Avoid warmup (frames evaluated sequentially → hitches). Particle reads via attribute reader data interface generally more performant than events. Sorting disabled by default; when enabled sorts run on GPU (overhead, index buffer memory); Niagara.GPUSorting.CPUToGPUThreshold, Niagara.GPUCulling.CPUToGPUThreshold. Pool priming reduces runtime allocations but may hitch if loaded dynamically.