The Explosion You Never Actually Computed

A grenade goes off. You watch hundreds of sparks scatter across the screen, bounce off the brick wall, skitter along the floor, fade into smoke. Your brain logs it as realistic and moves on.

None of those sparks touched a wall mathematically. Not a single one.

That's the central trick in particle system design, and once you see it, you can't unsee it. Game engines use a strict, layered hierarchy to decide what gets real collision math and what gets a convincing illusion. The split is more aggressive than most players suspect.

Two Worlds Running at Once

Every modern game engine manages at least two parallel representations of the world: the simulation layer and the presentation layer.

The simulation layer is expensive. It tracks rigid bodies, cloth, ragdolls, destructible objects. A box falling off a shelf gets real physics: mass, velocity, angular momentum, collision response with the floor. The engine's physics system (Havok, PhysX, Bullet, or a proprietary equivalent) solves actual differential equations for these objects, typically at a fixed timestep somewhere between 60Hz and 120Hz. Each collision check costs CPU time. Each response costs more.

The presentation layer is cheap by design. Particle systems live here almost entirely. A particle is usually nothing more than a position, a velocity vector, a lifespan counter, and a handful of render properties. It weighs almost nothing. The engine can run ten thousand of them simultaneously precisely because it has stripped out the physics.

The question is where the line gets drawn, and why.

The Three-Tier Decision

Engines don't make a binary choice. They work across three tiers, and a single visual effect can span all three at once.

Tier one: full rigid-body collision. Reserved for objects that matter to gameplay. A grenade bouncing down a hallway needs real collision because where it lands changes the outcome. A car door flying off an exploding vehicle might get real physics if it could kill the player. These objects are registered with the physics engine, assigned a collider shape, and processed every simulation tick. The count stays low, usually under a few hundred active rigid bodies per scene in a typical action game.

Tier two: simplified world collision. Some particles do collide with the world, just cheaply. Unreal Engine's Niagara system, for example, offers a GPU-side collision mode where particles query a depth buffer (a screen-space snapshot of scene geometry) rather than testing against actual 3D meshes. The particle checks: is my projected position behind the depth buffer surface? If yes, deflect. This is a screen-space approximation. It misses geometry that isn't currently visible. It breaks down at oblique angles. But it runs in parallel on the GPU, costs almost nothing per particle, and looks plausible at a glance. Bullet casings skipping across the floor, rain droplets hitting a puddle, embers settling on a surface: this is their home.

Tier three: pure visual approximation. Most particles never test anything. Smoke, volumetric steam, magical auras, distant fire: they simulate as if the world doesn't exist. Their "physics" is just a velocity vector modified by a drag coefficient and a noise field each frame. They look like they're interacting with the world because artists tune their emission shapes, their lifespans, and their fade curves to suggest plausible behavior. The collision is entirely in your head.

Why Depth-Buffer Collision Is Genuinely Clever

This is worth sitting with.

Imagine a campfire scene. Embers lift off, drift, and land on surrounding rocks. The geometry of those rocks is complex: crevices, slopes, overhangs. Testing each ember against the rock mesh in the physics engine would require the CPU to run narrow-phase collision detection (the expensive kind, testing actual polygon surfaces) potentially thousands of times per frame. It would be like asking a bouncer to verify every party guest's ID against a full background check, in real time, while the music plays.

Instead, the GPU already has a depth buffer sitting around. It was generated for rendering as part of the normal frame pipeline. It's essentially a 2D image where each pixel encodes how far away the nearest surface is from the camera. The particle system samples this image, reprojects the particle's world position into screen space, and checks whether the particle has crossed into solid geometry. If it has, bounce it back.

Total additional cost: nearly zero, because it's piggybacking on work the renderer already did.

The honest limitation: it's a view-dependent lie. Rotate the camera quickly and particles might briefly clip through geometry that just came into view. Most players never notice, because the effect is gone in milliseconds and the brain is busy tracking the action.

What People Assume (And Where That Goes Wrong)

The common assumption is that more particles means more physics. It's the opposite. Particle systems scale precisely because they shed physics aggressively as count increases.

Take two developers, Priya and Marcus, both building explosion effects in Unreal Engine 5. Priya uses 200 particles with depth-buffer collision enabled. Convincing sparks, floor contact, done. Marcus tries to make it "more accurate" and registers each particle as a physics actor, giving all 200 real rigid-body collision. His frame time spikes. The physics solver stalls. The explosion looks identical but costs twenty times more. Priya ships her effect. Marcus rewrites his.

The lesson isn't that accuracy is bad. It's that accuracy is a budget item, and particle effects almost never justify spending it. That's not a compromise, it's the correct engineering call, and anyone who tells you otherwise hasn't shipped a scene with more than a dozen active effects running simultaneously.

There's a second misconception worth killing: GPU particles are always less accurate than CPU particles. Not true. For world collision specifically, GPU depth-buffer sampling can be more visually consistent than CPU-side sphere casting, because it automatically reflects the actual rendered geometry rather than a lower-resolution collision proxy. The physics engine's collision mesh is often simplified to 30-40% of the visual mesh's polygon count. The depth buffer isn't.

The Gameplay Exception

All of this changes the moment a particle affects gameplay.

If a fireball needs to deal damage, it stops being a particle and becomes a projectile: a proper physics object with a collider, registered with the game's hit-detection system, capable of triggering events. It might look like a particle (same shader, same glow), but under the hood it's a different class of object entirely.

Some engines handle this with a hybrid. The visual particle system runs independently for the flame trail and sparks, while a single invisible sphere collider follows the fireball's trajectory and handles hit detection. You see hundreds of particles. The physics engine sees one sphere. It's a puppet with a very convincing costume.

The classic rocketjump in arena shooters works this way. The rocket is one rigid body. The explosion is a radius check on the physics layer, plus a pure-visual particle burst that has nothing to do with the damage calculation. The fire you see and the force you feel are computed by entirely separate systems.

Tuning Belief, Not Reality

Particle artists don't simulate physics. They simulate the appearance of physics, which is a different craft entirely.

An ember that behaves realistically in a fluid dynamics simulation rises quickly, cools, slows, and drifts unpredictably. Accurate. Also visually inert, hard to read, and unimpressive on screen. Real ember behavior, it turns out, looks wrong. So artists push the upward velocity, add a spiral noise pattern, extend the lifespan, and brighten the glow curve near the end. Physically incorrect. Emotionally correct.

So here's the question worth asking next time a game's effects wow you: are you responding to physics, or to a very well-tuned fiction about physics?

The engine calculates what's cheap and approximates what's expensive. The artist's job is to make sure the approximation triggers the right feeling. Sometimes the collision math matters. Mostly, it doesn't. The sparks on your screen are a negotiation between a physics budget and a human visual system that is, it turns out, remarkably easy to fool, and the best effects artists in the business have made a career out of knowing exactly how little math that actually requires.