Particle Systems: Fire, Smoke and Sparks

Fire is one of the oldest things a game tries to draw and one of the hardest to draw honestly. A real flame has no surface, no edge one could trace with a pencil; it is a churning region of hot gas that glows, rises, tears apart and vanishes, and the smoke above it is a slower, darker version of the same restlessness. No mesh can describe such a thing, and for a long time the solution has been not to describe it at all, but to suggest it with a swarm.

That swarm is a particle system: an object that spawns many small, short-lived elements, gives each a position, a speed, a colour and a size, changes those values over the element's brief life according to a few curves, and then destroys it. Each particle on its own is almost nothing, usually a soft blurred sprite on a square of two triangles. Hundreds of them, born continuously and dying continuously, overlapping and fading, produce the impression of flame, of smoke rolling from a chimney, of sparks spitting from an anvil.

This essay walks through the anatomy of such a system in the terms Unity uses, from the emitter that gives birth to particles through the modules that shape their lives, the camera-facing quads that carry their images, and the cost those quads impose on the graphics card. It ends with the choice every Unity developer now faces between the long-standing Particle System component, often still called Shuriken, and the GPU-driven Visual Effect Graph.

Emitters and the brief life of a particle

Every particle begins at an emitter. The emitter is not a visible object but a set of rules about birth: how many particles appear per second, whether they arrive in a steady stream or in sudden bursts, and what initial values each newborn receives. In Unity's Particle System these rules are split between the Main module, which sets Start Lifetime, Start Speed, Start Size, Start Color and the Max Particles cap, and the Emission module, which sets Rate over Time, Rate over Distance and any timed Bursts.

Lifetime is the most important single number in the whole system, because it governs both the look and the cost. The number of particles alive at any moment is, in a steady state, roughly the emission rate multiplied by the lifetime. An emitter producing 40 particles per second with a lifetime of 2.5 seconds will hold about 100 living particles; doubling the lifetime doubles the crowd. A designer who wants a taller column of smoke and raises the lifetime has also, perhaps without noticing, doubled what the renderer must draw.

Randomness is what keeps the crowd from looking like a parade. Almost every starting value can be set not as a constant but as a range between two constants or as a curve sampled at random, so that one ember is born a little larger and faster than its neighbour, another a shade redder. Without this variation the eye immediately catches repetition and the effect looks like a pattern stamped on the screen; with too much of it, the effect dissolves into noise. Good particle work lives in the narrow band between.

The Main module also sets the simulation space, a small choice with large consequences. In local space, particles move with their emitter, so a torch carried by a running figure drags its whole flame along like a rigid ornament. In world space, a particle is released into the scene at birth and keeps its own path, so the same moving torch leaves a trail of rising embers behind it. For fire and smoke, world space is nearly always what the eye expects, because real flames do not follow the hand.

Modules that shape the motion

Beyond birth, a particle's life is described by optional modules that each modify one aspect of it. The Shape module decides where within the emitter a particle appears and in which direction it is first launched: from the surface of a sphere, from inside a cone pointing upward, from a box, from the edges of a mesh. A campfire is often a narrow cone aimed at the sky; a fountain of sparks from a grinding wheel is a flatter cone tilted sideways; a smouldering log might use the log's own mesh as its shape.

Velocity over Lifetime and its relatives then bend the path. A flame particle may be launched slowly upward and accelerate as it rises, as if lifted by heat, while a gentle orbital component makes the column twist. Gravity Modifier pulls sparks down in arcs, and the Noise module adds turbulence by pushing each particle through a shifting field, the single most effective tool for making smoke look like a fluid rather than a set of balloons drifting in straight lines. A Collision module lets sparks bounce off the ground before they die.

Color over Lifetime and Size over Lifetime do most of the expressive work. Each takes a gradient or curve across the normalized life of a particle, from zero at birth to one at death. A flame might start a hot near-white yellow, deepen to orange, then to a dull red, and fade its alpha to nothing before the end. Smoke works almost in reverse: born small and faint, it swells as it rises and grows briefly more opaque before thinning out, because real smoke spreads and dilutes into the air above.

A large part of fire's illusion comes from texture rather than motion. The Texture Sheet Animation module plays a grid of frames on each particle, so a single quad can flicker through a short hand-drawn or simulated sequence of a flame lick. Combined with random starting frames and rotation, a few dozen particles carrying these animated images can read as a far busier fire than they really are. Sub Emitters, meanwhile, allow one particle's death to spawn others, as when a rocket's trail ends in a burst of sparks.

Billboards and the flat illusion

The Renderer module decides what each particle actually looks like on screen, and by far the most common choice is the billboard. A billboard is a flat quad that, every frame, is rotated to face the camera squarely. Because it always presents its full face to the viewer, a soft round texture on it reads as a puff of smoke from any direction, and the player never catches the quad edge-on and sees it vanish into a line. The illusion is cheap and remarkably convincing at a distance.

Unity offers variations for particular cases. A Stretched Billboard elongates the quad along the particle's velocity, which turns tiny dots into streaking sparks and rain into falling lines. Horizontal and Vertical billboards face only partly toward the camera, useful for ground decals such as a scorched ring or for effects that should stay upright. When a flat image will not do, the Mesh render mode draws a small model per particle, such as splinters from a broken crate or chunks of masonry, at a higher cost per particle.

The weakness of billboards appears where they meet solid geometry. A large flat smoke quad passing through a wall or the ground shows a hard, straight seam where it is cut off, betraying the trick at once. The standard remedy is soft particles, a shader technique that reads the depth buffer and fades a particle's alpha as it approaches the surface behind it, so that smoke appears to thin out against a floor rather than slice into it. It needs a depth texture to be available, which brings its own small cost.

The cost of transparency

Most fire and smoke particles are transparent, and transparency is where particle systems spend their real budget. An opaque surface can be drawn once per pixel, with the depth buffer quietly discarding anything hidden behind it. A transparent surface cannot hide what lies behind it, so every overlapping layer must be shaded and blended in turn, from back to front. When twenty smoke quads overlap the same patch of screen, that patch is shaded twenty times in one frame. This repeated shading of the same pixel is called overdraw.

Overdraw is insidious because it scales with screen area, not with particle count. A hundred small sparks far away might touch a few thousand pixels; ten large smoke billboards filling the view up close might each cover a third of the screen, multiplying the work across millions of pixels. This is why a smoke effect that runs perfectly in a wide shot can drop the frame rate sharply when the camera walks into it, and why mobile GPUs, with limited fill rate, suffer the most from effects that look modest on paper.

The defences are mostly matters of discipline. Fewer, better textured particles usually beat many plain ones. Textures can be trimmed so their transparent corners are not drawn at all, for instance by drawing each particle with a tighter outline mesh than a plain square. Large particles near the camera can be faded out or culled. Additive blending, common for fire and sparks, at least avoids the need for strict sorting, though it does not reduce the shading. Unity's scene view and rendering debug tools can visualize overdraw directly, which is far more instructive than guessing.

Sorting, light and lifecycle

Because transparent layers are blended from back to front, their order matters, and particles bring two separate sorting problems. Within one system, the Renderer module's Sort Mode chooses how particles are ordered against each other: by distance from the camera, oldest in front, youngest in front, or not at all, which is cheapest and perfectly acceptable for additive sparks whose blending does not depend on order. Between whole systems, Unity sorts each renderer as a single object, so two overlapping effects can pop in front of one another as the camera moves; the Sorting Fudge value exists to bias that decision.

Fire is a light source, and players notice when it lights nothing. The Lights module can attach real-time lights to a fraction of the particles, but every real-time light carries a cost, so it is best used sparingly, with a low ratio and a hard cap. A common alternative is a single point light placed beside the effect, its intensity nudged up and down by a small script to match the flicker. Pushing the particles' colour into high dynamic range values and letting a bloom post-process spread them gives the glow without any additional light.

An effect also has a lifecycle that must be managed like any other object. Looping systems such as a hearth fire can be prewarmed so they appear fully grown on the first frame instead of sprouting from nothing. One-shot effects such as an impact can use Stop Action set to Destroy or Disable, though in a busy game it is wiser to keep a pool of systems and reuse them than to instantiate a new one per hit. The Culling Mode setting decides whether an effect off screen keeps simulating, pauses, or pauses and later catches up.

Shuriken and the Visual Effect Graph

The Particle System component, nicknamed Shuriken since its introduction, simulates particles on the CPU. Every living particle's position and properties are updated by the processor each frame, then handed to the GPU for drawing. This makes it flexible and widely compatible: it works in the Built-in render pipeline, in URP and in HDRP, on every platform Unity targets, and scripts can read and modify individual particles through methods such as GetParticles and SetParticles, or respond to collisions through OnParticleCollision. Its limit is scale, since the CPU can comfortably manage thousands of particles but not millions.

The Visual Effect Graph takes the opposite approach. Its effects are authored as node graphs divided into contexts for spawning, initialization, updating and output, and the simulation runs on the GPU through compute shaders. Because a graphics card can update an enormous number of particles in parallel, VFX Graph can handle counts that would overwhelm the CPU, along with features such as particles that sample signed distance fields or attract to a mesh. It is supported in HDRP and URP, not in the Built-in pipeline, and it requires hardware with compute shader support.

The choice is less about quality than about fit. VFX Graph excels at dense, spectacular effects, magic storms and drifting ash over a whole valley, but its particles live on the GPU, so gameplay code cannot easily inspect each one, and physics interaction with the scene is more limited than Shuriken's. A small, reactive effect that must report collisions to a script, or a game that targets older mobile hardware, is often better served by the classic component. Many projects use both, each where it belongs.

Whatever the tool, the underlying craft remains the same patient observation of how real things behave. A torch on a palisade at night, the kind of light Crown & Ashes depends on, is not a single shape but a short flicker of yellow-white at the wick, a lick of orange above it, a thread of dark smoke, and the occasional spark that rises, cools and falls. The particle system that captures it is a small set of curves and textures, tuned until the crowd of quads stops looking like quads at all.