Free · Relaxing · No sign-up

Fluid dynamics simulator

Drag your mouse or finger to stir up colorful, swirling ink and smoke — a real fluid dynamics simulation running live, right here.

Drag to stir the fluid

🔒 Runs entirely in your browser — nothing is recorded or sent anywhere.

A real simulation, not a video loop

🌀

Stable fluids solver

Every frame solves velocity diffusion, pressure projection and advection on a grid — genuine Navier-Stokes fluid dynamics, not a pre-rendered animation. Vorticity confinement puts back the small eddies that a stable solver otherwise smooths away.

🎨

Eight fluids, not one

Ink, smoke, lava, plasma, aurora, wet paint, milk in coffee and mercury — each with its own viscosity, dissipation, buoyancy and colour treatment. The dye types carry a hue field through the flow so colours blend the way real dyes do.

🧘

Made to unwind with

No goals, no score — just a satisfying, endlessly different visual to fidget with during a break.

What is being simulated

Real-time fluid simulations of this kind are usually built on Jos Stam's 1999 "Stable Fluids" method, which made interactive fluid possible by using an unconditionally stable solver. Earlier approaches became unstable and exploded numerically if the time step was too large relative to the grid, which made them impractical for anything interactive.

The simulation solves a simplified form of the Navier-Stokes equations on a grid, in a repeating cycle: add forces where the user interacts, diffuse velocity, advect the velocity field along itself, and then project the result to enforce incompressibility — the condition that the fluid neither gains nor loses volume, which is what produces the characteristic swirling behaviour.

Advection is the step that makes it stable. Rather than moving each cell's contents forward, Stam's method traces backwards from each cell to find where its contents came from and samples there. That backward trace cannot overshoot in a way that amplifies, which is what removes the instability.

Why it looks right without being accurate

This is visual approximation rather than engineering simulation. The backward-tracing advection introduces numerical diffusion — the field is repeatedly resampled and interpolated, which smooths it out — so the simulated fluid loses fine detail and small vortices faster than a real one would. It looks plausible and would be unacceptable for aerodynamic or hydraulic analysis.

Grid resolution caps what can be represented. Vortices smaller than a cell simply do not exist, and since real turbulence has structure at every scale, a real-time simulation necessarily discards the small end of it. Vorticity confinement is a common addition that injects energy back at small scales to compensate, which restores the appearance of detail without restoring the physics.

Engineering computational fluid dynamics uses far finer grids, more accurate schemes, and turbulence models, and runs on clusters for hours or days. The trade here is entirely deliberate: sixty frames per second in a browser, at the cost of physical fidelity.

Running it in a browser, on the CPU

Simulations like this are usually pushed onto the GPU, with the velocity and dye fields held as textures and each step run as a fragment shader. This one is not: it runs in plain JavaScript over Float32Array grids on the main thread, which keeps it to a single small file with no WebGL context to lose, no shader compilation to fail, and identical behaviour on hardware where WebGL is blocked or software-emulated. The trade is that the grid has to stay small enough for one CPU core.

Cost scales with the number of cells, so it scales with the square of the linear resolution — doubling the grid quadruples the work. Measured end to end on this build, one frame costs about 3.7ms at Low, 8.5 to 10ms at Medium and around 14ms at High, against the 16.7ms a 60fps frame allows. The frame rate is measured continuously and shown under the canvas; if the machine cannot hold the budget the quality drops a step on its own rather than letting the whole thing crawl.

The pressure projection is the expensive part, because it solves a system iteratively — a full pass over the grid per iteration. GPU implementations often run twenty to fifty; this one runs four to seven depending on quality, which is the single biggest lever on both speed and how much the fluid actually swirls. Four iterations is where the flow starts to read as a smear. The simulation also stops entirely when the tab is not visible, since a continuous main-thread load is a real battery drain for a page nobody is looking at.

Fluid simulator FAQ

Is this a real physics simulation?

Yes — it runs Jos Stam's classic "stable fluids" Navier-Stokes solver (diffusion, pressure projection and advection) on a grid every frame, the same technique behind most real-time smoke and ink effects, plus vorticity confinement to restore the small eddies a stable solver smooths away.

What are the eight fluids?

Ink in water, smoke, lava, plasma, aurora, wet paint, milk in coffee and mercury. They are not just colour swaps: each sets its own viscosity, dye diffusion, dissipation, buoyancy and vorticity, so lava crawls as a thick ribbon, smoke rises and thins, plasma throws off filaments, and mercury settles almost immediately.

Does it run on the GPU?

No. It is plain JavaScript over typed-array grids on the main thread — one small file, no WebGL context to lose and no shaders to compile, so it behaves the same where WebGL is blocked or software-emulated. The cost is that the grid must fit one CPU core: about 3.7ms a frame at Low, 8.5 to 10ms at Medium and 14ms at High, against the 16.7ms a 60fps frame allows.

What do the Brush, Force and Swirl sliders do?

Brush sets the radius of dye and force injected under the pointer. Force scales how hard a stroke pushes the velocity field. Swirl scales vorticity confinement — turn it up for whipping filaments, down for a smooth, syrupy flow. Quality changes the grid resolution and the number of pressure iterations, which is the main trade between how much the fluid swirls and how fast it runs.

Why does the colour change as I drag?

On the dye fluids — ink, wet paint and milk — each stroke starts at a fresh hue and drifts as it travels, and that hue is carried through the flow by the same advection as the dye itself, so colours blend where strokes cross. The other fluids read their colour straight off a fixed gradient driven by density, which is what makes fire and plasma glow rather than mix.

Does this use my camera, microphone or any personal data?

No — it only reads mouse or touch position on this page. Nothing is recorded, uploaded or stored. It also stops simulating entirely when the tab is not visible, so it is not quietly burning battery in a background tab.

Is this physically accurate?

No. It solves a simplified form of the Navier-Stokes equations on a coarse grid with numerical diffusion that smooths away fine detail, and vorticity confinement puts energy back at small scales by a rule that is chosen for looks, not derived from the physics. It is built to look convincing at sixty frames per second, not to be quantitatively correct.

Why does it slow down on a large screen?

Cost scales with the number of grid cells, so with the square of the resolution — doubling the linear resolution quadruples the work. The iterative pressure solve is the most expensive part. The frame rate is shown under the canvas, and the quality drops a step automatically if the machine cannot hold sixty.