I built an interactive explosion simulator in the browser

The hard part was not making an explosion bright. A radial gradient can do that. The hard part was making twelve events move as if they came from twelve different causes rather than one animation wearing twelve color palettes.

I wanted a compact conventional blast to feel abrupt, low, and broken. An industrial fireball should roll and keep burning. A meteor impact should carry directional momentum into a tall dust column. A volcano should pulse for a long time without beginning as a fireball. A fictional plasma burst should look luminous, electrical, and clearly imaginary. A nuclear airburst should remain the one event that earns a rolling cap and connected stem.

That became the Explosion Dynamics Lab: an interactive explosion simulator and atmospheric visualization that runs entirely in the browser. It is also open source on GitHub.

Why build an explosion simulator?

Explosions are visually interesting because several systems occupy the same moment at very different speeds. The first flash and pressure shell are almost instantaneous. The visible hot gas, smoke, dust, debris, buoyant rise, and wind-driven cloud evolve much more slowly. Treat all of that as one expanding circle and the result may read as an explosion for half a second, but it does not remain convincing when paused or scrubbed.

I was interested in the graphics problem, not destructive prediction. How do you make a browser communicate speed, density, heat, turbulence, scale, and cooling without turning the interface into a blast calculator? How do you preserve the recognizable silhouette of an event while keeping every number normalized and every environment fictional?

The answer was to separate what should be analytical from what should emerge from a simulated field.

A hybrid model for fast and slow physics

The initial flash, thin pressure shell, refractive ring, ground reflection, fast debris, camera response, electrical arcs, and meteor trail are analytical effects. They are short-lived, visually specific, and cheaper to calculate directly.

The main plume is different. In Cinematic mode, its large-scale motion comes from normalized velocity, temperature, smoke, incandescent, and dust fields running on the GPU. Each fixed simulation step advects those fields, adds buoyancy and wind, restores rolling motion with vorticity confinement, approximately projects the velocity to reduce divergence, and converts cooling incandescent material into smoke.

A multislice shader then reconstructs the two-dimensional vertical field into a 2.5D volume. Density controls opacity. Hot regions emit light into nearby material. Short density probes create approximate self-shadowing. Seeded curl detail breaks up perfect symmetry. Bloom, heat distortion, exposure, and tone mapping finish the image without defining its silhouette.

This follows a useful principle from graphics research: spend the expensive simulation on the motion that must remain coherent, then use bounded rendering approximations to make that motion legible.

Twelve events, seven visual families

The original procedural renderer could produce useful flashes, rings, particles, and analytical overlays, but its cloud motion depended too heavily on circles and scripted lobes. The improved engine organizes the presets into seven physical or visual families:

• Conventional blasts use strong radial impulses, broad ground dust, rapid cooling, and low broken silhouettes.
• Industrial fireballs sustain heat longer, convert more incandescent density into heavy smoke, and roll through multiple ignition pockets.
• Ground-coupled events combine vertical jets, ground sheets, ejecta curtains, and dense particulate loading.
• Meteor events begin with elongated directional trails; a ground impact adds an asymmetric surface jet and ejecta stage.
• Volcanic eruption uses repeated pulses, a sustained ash column, altitude wind, and falling particulate instead of an initial blast cloud.
• Fictional plasma favors luminous cyan-violet filaments, oscillating forces, refraction, and very little conventional soot.
• Nuclear-scale visualizations distinguish an airburst research model, a dust-heavy ground burst, and a much slower extreme-scale cloud.

Within those families, every preset gets its own source timing, force balance, volume depth, opacity, erosion, shadows, emission curve, distortion, tracer behavior, and adaptive quality budget. The result is not twelve independent engines. It is one reusable fluid system with twelve materially different configurations.

The silhouette test

Color is seductive because it can hide structural sameness. Make one cloud orange, another gray, and another blue, and they initially feel different. Turn them into solid black shapes and the illusion disappears.

I used silhouette as a design constraint. The compact blast had to remain low and wide. The industrial fireball needed a billowing mass that grew into soot. The underground event needed a heavy base and vertical debris jet. The meteor airburst needed an offset atmospheric cloud. The impact needed a taller dust column and radial curtain. The volcano needed repeated cauliflower surges and an umbrella top. Plasma needed a sphere of filaments. Only the nuclear airburst should resolve into the familiar stem and rolling cap.

That constraint pushed the system away from palette swaps and toward different source geometry.

Deterministic chaos

Fluid motion should feel irregular, but an interactive tool also needs repeatability. Explosion Dynamics Lab uses numeric seeds for source offsets, turbulence, tracer placement, and reconstruction detail. Replay the same preset, seed, settings, quality tier, and timeline position, and the simulator reconstructs the same visual event.

The solver advances at a fixed 30 Hz simulation step. Scrubbing backward resets the field and deterministically replays it from the beginning. PNG and MP4 exports use the same renderer and the same seed rather than substituting a lighter animation. This matters because an export should capture the experiment you composed, not an approximation of it.

Making WebGL fluid simulation fit a phone

Every device cannot run the High profile. The lab keeps Mobile, Balanced, and High tiers, then lets each event apply bounded multipliers to grid size, pressure iterations, volume slices, detail texture resolution, shadow work, and tracer count.

A compact blast does not pay for the same source duration and volume depth as a volcanic column. A phone uses the reduced GPU tier rather than silently returning to the old plume. When WebGL2 or the required render targets are genuinely unavailable, the Canvas renderer remains a visible compatibility fallback, and developer diagnostics report why.

Effects Overview is separate. It intentionally uses a clear analytical display for normalized luminous, pressure, thermal, and particulate progression. Choosing Overview is a visualization decision, not a GPU failure.

What the research contributed

The implementation adapts ideas from four established computer-graphics papers: Animating Explosions, Visual Simulation of Smoke, Physically Based Modeling and Animation of Fire, and Smoke Simulation for Large Scale Phenomena.

Those sources informed the separation between a fast analytical shock and slower incompressible plume, semi-Lagrangian advection, pressure projection, buoyancy, vorticity confinement, cooling, density-based opacity, temperature-driven emission, self-shadowing, and layered volume reconstruction.

The lab does not copy their dimensional detonation, material, destruction, or engineering inputs. It adapts safe visual methods into bounded dimensionless controls. The result is research-informed computer graphics, not validated computational fluid dynamics.

Safety was part of the product design

An explosion simulator can easily drift from visual education into operational information. This one deliberately excludes explosive materials and ratios, construction, triggers, weapon design, delivery systems, targeting, real maps, addresses, coordinates, casualties, damage optimization, and exact engineering predictions.

The event names describe visual archetypes. The scales are normalized for screen readability. The environments are generic. The overview has no population, infrastructure, or target layer. Even the fuel-air-style preset is only a rolling-combustion visual category; it contains no composition or ignition information.

Those restrictions did not make the project less interesting. They clarified the real problem: how to communicate motion, phase, atmosphere, and scale through interactive graphics.

What building it taught me

First, a shared engine becomes valuable when its configurations can change structure, not just style. Reuse should make differences easier to build, not erase them.

Second, fallbacks need identities. Effects Overview, reduced motion, Mobile quality, and a genuine renderer failure are four different states. Treating them as the same “simpler version” makes both the interface and debugging worse.

Third, determinism is a creative feature. A seed turns a fleeting simulation into something you can revisit, compare, export, and discuss.

Finally, the paused frame matters. If an animation only works because everything moves quickly, it probably lacks coherent structure. A compelling still frame is evidence that density, lighting, silhouette, and large-scale motion are doing real work.

Computational Studio 02

The Gray-Scott Reaction Lab became Computational Studio 01: a world where two virtual chemicals organize themselves after a disturbance. Explosion Dynamics Lab is Studio 02. Its subject is almost the inverse—energy released quickly, followed by structure emerging through cooling, turbulence, atmosphere, and time.

Both projects are really about the same thing: building systems you can touch, then letting their internal rules answer back.

Open Explosion Dynamics Lab

Research Confidence

This article is based on:

• Yngve, O'Brien, and Hodgins on analytical shock optics and simulated post-detonation flow
• Fedkiw, Stam, and Jensen on incompressible smoke, pressure projection, buoyancy, and vorticity confinement
• Nguyen, Fedkiw, and Jensen on fire cooling, smoke conversion, emission, and participating-media rendering
• Rasmussen and colleagues on large-scale smoke, layered reconstruction, multiscale turbulence, and particles
• Direct implementation, deterministic contract tests, and production verification of the browser simulator

Confidence Level: Experimental

Frequently asked questions