At 60 frames per second, a renderer has 16.67 milliseconds to do everything in a frame: animate characters, light the scene, and draw the effects. A particle system competing for that budget cannot afford to update each particle one at a time. This constraint, more than any artistic choice, explains why visual effects moved off the central processor and onto the graphics processor, and why simulations that once required render farms now run live inside a game engine viewport.
The constraint
Everything in a frame shares 16.67 ms
At 60 frames per second a renderer has one-sixtieth of a second to do all of it. Particles compete for a slice of that budget — which is why updating them one at a time stops working.
Why the CPU Reached Its Limit
Traditional particle systems run on the CPU. The processor updates particles in sequence across a handful of cores, applying forces and advancing each one before moving to the next. For real-time work, that approach caps a practical scene in the thousands to low tens of thousands of particles before the frame budget is gone. Push past that and the frame rate falls.
Film and offline VFX avoided the limit by abandoning real time. Tools such as SideFX Houdini simulate millions of particles for smoke, fire, and fluids, but a single frame can take minutes or hours to compute on a render farm. The workflow is submit and wait: the artist changes a parameter, queues the job, and reviews the result later. The quality is high. The iteration speed is not.
So for decades there were two separate worlds. Real-time particles were cheap and limited. High-volume particles were expensive and slow. Nothing bridged them, because the CPU could not do both at once.
The GPU Rewrite
The update for a single particle does not depend on any other particle. Apply the forces acting on it, integrate its velocity, advance its position, and increase its age. Each particle runs the same short program on its own data. That independence makes the workload a near-perfect match for a graphics processor, which is built to run thousands of identical operations in parallel.
One particle, one short program
The update depends on nothing but itself
Because a particle's update needs no data from any other particle, the same four steps can run on every particle simultaneously — the property that makes the GPU a near-perfect fit.
Why the GPU wins
Same work, run in parallel instead of in sequence
Each particle runs the same short program on its own data, independent of the others. The CPU walks them through a handful of cores one at a time; the GPU runs thousands at once.
Sources: Epic Niagara [1]; Unity VFX Graph [2]; Latta, "Building a Million Particle System," NVIDIA [3].
Modern engines exploit this with compute shaders. Particle state lives in buffers on the GPU and is updated entirely on the GPU each frame, then drawn without ever returning to the CPU. Epic's Niagara system, which replaced the older Cascade system in Unreal Engine, runs simulations on either the CPU or the GPU; the GPU path raises the practical ceiling into the millions of particles per frame.[1] Unity's VFX Graph takes the same compute-shader approach for the same reason.[2]
The core technique predates both engines. NVIDIA's reference work 'Building a Million Particle System' described how to store particle positions and velocities in GPU textures and advance them with successive shader passes.[3] Storage and naming have changed since, but the principle is the same one every real-time system uses today: keep the data on the GPU, update it in parallel, never copy it back.
The bridge
High volume and real time finally meet
For decades, particles were either cheap-and-limited or high-volume-and-slow. The GPU fills the corner that was always empty: millions of particles, inside a real-time frame.
Sources: Niagara [1]; Unity VFX Graph [2]; SideFX Houdini (offline reference).
The result is the bridge that did not exist before. A million-particle simulation now fits inside a real-time frame, so the high-volume world and the interactive world finally meet.
The Tradeoffs
The speed comes from keeping particle state on the GPU, where the rest of the program cannot easily read it. Copying that data back to the CPU stalls the pipeline and erases the performance gain. So gameplay logic that must react to individual particles — such as a projectile that triggers an event when it strikes a target — often still runs on CPU particles. GPU particles are for volume and spectacle. CPU particles are for effects that talk to game logic.
Collision is the second compromise. A GPU particle system rarely tests against full scene geometry, because that test is expensive. Instead it collides against cheaper approximations: the camera's depth buffer, or precomputed signed distance fields that describe the distance to the nearest surface. The effect looks correct from the camera, but it is an approximation. Particles can pass through surfaces the depth buffer cannot see, such as anything behind the camera or hidden by another object.
Volume & spectacle
- Millions per frame, never copied back to the CPU.
- Collide via approximations — depth buffer or signed distance fields.
- Hard for game logic to read individual particles.
Effects that talk to logic
- React to individual particles — e.g. a projectile triggering an event on impact.
- Easily read by the rest of the simulation.
- Lower counts; bound by sequential updates.
This is why the move to the GPU is not a clean replacement. It is a division of labor. The engineer chooses the GPU when the goal is scale and the CPU when the effect must interact with the rest of the simulation.
Looking Ahead
The deeper change
From submit-and-wait to live in the viewport
The real shift isn't the particle count — it's the iteration loop. When a large simulation runs inside the frame budget, the artist sees the final result immediately instead of queuing a render.
Demanding film simulations still run offline; the default for real-time work has shifted to the GPU.
The deeper change is not the particle count. It is the collapse of the iteration loop. When a large simulation runs inside the frame budget, the artist authors the effect and sees the final result immediately, rather than submitting a job and waiting for a render. The render farm has not disappeared, and the most demanding film simulations still run offline. But the default for real-time work has shifted to the GPU, and the gap between a preview and a final frame keeps narrowing. The next constraint to fall will not be how many particles a system can move, but how closely a real-time approximation can match what an offline solver still does better.
References
- Epic Games — Niagara VFX System overview, Unreal Engine documentation.
- Unity Technologies — Visual Effect Graph package documentation.
- Lutz Latta — "Building a Million Particle System," NVIDIA / GDC 2004. In GPU Gems 3.
