Adventures in Fluid Simulation

Back to Blog Listing

Adventures in Fluid Simulation

I spent ten years building fluid simulation tools for VFX: a three-day Stable Fluids prototype, sparse level sets for Scooby-Doo 2, tetrahedral and vortex solvers at Exocortex, and three pieces of my software on Harry Potter and the Deathly Hallows.

Ben Houston • June 22, 2026 • 13 min read

graphicscodingvfx

In the autumn of 2002, I stepped off a cheap one-way flight from Ottawa to Winnipeg with no contract, no accommodation, and no clear idea of what I was getting into. A friend from high school had told me that Frantic Films, a visual effects studio in Winnipeg, needed a 3D coder. There was a single phone call interview. I said yes, bought the ticket, and showed up. They were a little surprised when I appeared on the Monday.

My first assignment was to build a fluid simulator from scratch.

I kept coming back to fluid simulation for the next ten years. First came a 2D proof-of-concept I hacked together in three days. Then came vortex and tetrahedral solvers that made it into Harry Potter and the Deathly Hallows: Part 2 and Moby Dick. Along the way I co-authored nine papers and filed four patents, cited over 500 times. Across three generations of solvers, studios used the work on around twenty films. It was some of the most demanding engineering work I have done.

The Stable Fluids Shortcut#

They handed me a printout of Jos Stam's 1999 SIGGRAPH paper, Stable Fluids, pointed me at a computer, and left me to it.

Frantic Films didn't know I had already written an open-source FFT library called Exocortex DSP. The Stable Fluids method exploits periodic boundary conditions that Fast Fourier Transforms can solve with speed. I already had the FFT infrastructure. I already knew how to build C# visualization frameworks from previous projects. Within three days, I had a working 2D fluid solver.

The team was impressed enough to move me out of the $20/night hostel I was staying at and into a proper hotel while I found actual accommodation. We also agreed on compensation. I hadn't negotiated anything before getting on the plane.

Building the 3D Solver: Smoke, Water, and a Memory Problem#

The 2D solver was a proof of concept. The real work was the 3D solver, which I built over the following months by working through the research of Ronald Fedkiw and his collaborators at Stanford, as well as papers by James O'Brien at Berkeley.

We started with smoke, the simpler case, since you only need to track a density field, and then tackled water, which forced us to track the fluid surface. We used level set methods to represent the water surface as an implicit signed-distance function, evolved over time using front-tracking techniques.

Memory became the hard constraint. In 2003 we were on 32-bit Windows machines with a hard 2 GB per-application memory limit. There was a 3 GB boot-flag option, and we used it, but it was still tight. A full 3D level set and velocity field at production resolution blew through that budget.

RLE Level Set Simulations

We solved it with a run-length encoded (RLE) representation that excluded dead space from both the level set and the velocity fields. In air regions, we tracked no cells. In the level set, we skipped interior and exterior regions and kept only a narrow band near the surface.

Our first implementation encoded along X with conventional 2D allocation for Y and Z, which recovered most of the memory savings. We later developed a hierarchical version that kept every dimension sparse and recovered more memory. Morten Bojsen-Nielsen, Christopher Batty, Ola Nilsson, Ken Museth, and I published the full journal treatment as Hierarchical RLE Level Set in ACM Transactions on Graphics in 2006. Ken later created OpenVDB, now the industry standard for volumetric data in VFX. Researchers have cited the paper close to 200 times.

The Tar Monster: Scooby-Doo 2#

The first major film application of our fluid system was Scooby-Doo 2: Monsters Unleashed (2004), where we simulated the Tar Monster, a large, viscous liquid creature. The RLE architecture made the simulation fit in memory at the required resolution.

We also developed a guided animation system for this work with Chris Bond, who headed the VFX studio, and Mark Wiebe. We wanted to art-direct the tar monster's motion toward intended shapes while preserving the underlying simulation. To handle occlusion and blending, we used a unified level set representation. We published the approach as a SIGGRAPH sketch in 2003 and patented the occlusion method.

Mark Wiebe also co-authored the companion SIGGRAPH 2004 sketch The Tar Monster: Creating a Character with Fluid Simulation, which covered the production side of what we built.

Scooby-Doo 2 Tar Monster

Exocortex: A New Technical Direction#

In early 2005 I left Frantic Films to found Exocortex, wanting to build a company focused on software. Fluid simulation stayed central to our work, but I decided to rethink our technical foundations.

At Frantic Films we had built everything in C#. The garbage-collected managed memory model had made development fast, but we kept running into walls: memory pressure from the GC, difficulty with efficient multithreading, poor cache utilization, and limited ability to squeeze performance out of the hardware. For production-scale fluid simulation, C# was the wrong tool.

At Exocortex, we switched to C++ and adopted Intel Threading Building Blocks (TBB) for parallelism and SIMD intrinsics for vectorization. My key collaborator in this era was Stefan Xenos, now a senior engineer at Google. Stefan did important work on a cache-optimized kernel system. Instead of passing data through one operation at a time, we layered multiple transforms and analyses together over a small block of data that fit in cache, completing the entire stack before moving to the next block. Simulations ran faster because the CPU spent less time waiting on memory.

We over-corrected. We spent a lot of time on low-level optimizations that, in hindsight, distracted us from building market share. C# had its problems, but we had replaced one set of rabbit holes with another. The right answer sat somewhere in between. Intel featured Exocortex in their Visual Adrenaline magazine at SIGGRAPH around the time of the Harry Potter release, distributed to all SIGGRAPH attendees. That still felt exciting.

Maelstrom: Tetrahedral Fluid Simulation#

The first major Exocortex fluid product was Maelstrom, a fluid simulator built on unstructured tetrahedral meshes rather than a regular Cartesian grid. Tetrahedral discretization, the same kind of representation used in engineering FEM simulations, allowed Maelstrom to adapt resolution to geometry in ways that grid-based solvers can't, and to handle complex boundary conditions with fewer compromises. Stefan Xenos co-authored the associated paper with Christopher Batty and me.

Tetrahedral fluid simulation

A mid-production shot from Moby Dick using MaelstromFX for the liquid simulation.

Maelstrom found its production use on the SyFy film Moby Dick (2010), where Will Garrett used it for the ocean simulations. Those shots gave us proof that tetrahedral fluid simulation could work on a real production, even if the complexity of unstructured meshes kept it from reaching as many artists as grid-based tools.

Slipstream: Vortex Particle Simulation#

The Exocortex fluid product with the most commercial traction was Slipstream, a vortex particle-based fluid simulator. Rather than discretizing a velocity field onto a grid, Slipstream represented the fluid as a collection of vortex filaments, whorls of rotational energy that advect through space and induce velocity in the surrounding fluid according to the Biot-Savart law.

For artists, Slipstream had one useful advantage: no bounding box. Traditional grid-based solvers require you to define a simulation domain upfront. If your smoke drifts outside that volume, it vanishes. Vortex methods are unbounded. For large atmospheric or environmental effects, that mattered.

Slipstream VX running the full vortex simulation in real time on the GPU.

SlipstreamRT real-time fluid simulation running in Unreal Engine.

Slipstream launched as a plugin for Autodesk Softimage. We later built versions for Houdini and Maya that included more sophisticated guidance controls, letting artists steer simulations toward desired shapes without abandoning the physics. Mauricio Vines, J. Lang, W.S. Lee, and I published the theoretical foundations in a 2013 IEEE Transactions on Visualization and Computer Graphics paper.

The Real-Time Tangent: Gaussians and Unreal Engine#

While building the vortex-based solver, Stefan Xenos and I tried to push fluid simulation into real time. We developed an Unreal Engine 3 plugin that ran vortex-based fluid simulation at real-time frame rates. The method stayed sparse except where vortices existed and where they advected smoke volumes, which kept the computational cost bounded.

We represented the smoke volumes as Gaussians. They started spherical, then stretched over time as the fluid moved. When a Gaussian stretched too far, it would split into two, preserving detail. We developed heuristics for the splitting behaviour and filed patents covering the approach.

Looking back now, the representation resembles 3D Gaussian Splatting, the 2023 technique for real-time neural rendering. We represented a continuous smoke field as oriented Gaussians that stretched, split, and moved through space. Gaussian Splatting later gave a more rigorous framework to a related representation. I still think our old fluid approach would be worth revisiting with that newer math.

The real-time experiment didn't become a standalone product. We noticed stronger demand for the offline VFX use case and refocused, but the work generated some of our more cited patents.

Harry Potter and the Deathly Hallows: Part 2#

Our partner VFX studio Gradient Effects used Slipstream on Harry Potter and the Deathly Hallows: Part 2 (2011). The film needed large-scale atmospheric effects. A bounded grid solver would have struggled with the required scale and resolution. We had designed Slipstream for that exact problem.

Harry Potter fluid simulation

I hadn't planned the convergence: Harry Potter and the Deathly Hallows: Part 2 used Slipstream for the vortex simulations, Krakatoa to render the particles advected through those simulations, and Deadline to schedule all of those renders across the farm. Three tools I had built or co-created, each developed years apart, for different reasons, at different companies, ran on the same film.

It was a strange and satisfying thing to see.

The Academic Record#

The fluid simulation work produced a body of research spanning both the Frantic Films and Exocortex years. My primary academic collaborator throughout was Christopher Batty, who joined Frantic Films as an undergraduate intern in 2004, a year after I arrived, and went on to become a Professor of Computer Graphics at the University of Waterloo. Working together at that early stage, when we were both figuring things out in a production environment, pushed both of us forward in ways that are hard to separate from what came later.

Selected papers and patents, in chronological order:

Lessons from a Decade of Solvers#

On paper, the fluid simulation work looks like the bigger technical achievement. Across ten years and three generations of solvers, studios used it on around twenty films. Studios have used Deadline, which I co-created at the same time using a filesystem as a database, on hundreds of films, and they continue to use it today.

The fluid simulation work demanded more raw innovation, more rewrites, more research, and more sheer problem-solving. It had a fraction of the impact.

That comparison taught me more than the papers did. Rendering sits in the daily workflow at VFX studios. Fluid simulation is a narrower need. A harder technical problem can give you a more defensible product, but customers still buy the tool that solves the problem sitting in front of them.

The C++ transition at Exocortex taught the same lesson at a smaller scale. C# gave us real problems: memory pressure, GC pauses, and poor cache performance. We fixed them, then kept going. We spent months on low-level optimizations that distracted us from building market share. The switch cost us development velocity, and our customers weren't paying for deep optimization work.

I don't regret the fluid simulation work. The academic contributions were real, the film credits were real, and the experience of pushing that hard against difficult problems shaped how I think about engineering. I try to carry that lesson forward by paying more attention to the market than to the difficulty of the work.

This post is part of a series on my early career in VFX software. See also: Building Deadline: Finding Product Market Fit in a VFX Studio.