Adventures in Fluid Simulation

Back to Blog Listing

Adventures in Fluid Simulation

How I spent a decade pushing the boundaries of fluid simulation for Hollywood VFX — from hacking together my first solver in three days at a Winnipeg hostel, to watching three pieces of my own software run simultaneously on Harry Potter and the Deathly Hallows, and almost accidentally inventing Gaussian Splatting for fluids along the way.

Ben Houston • June 22, 2026 • 15 min read

graphicscodingvfx

This is the story of ten years building fluid simulators for Hollywood visual effects, from my first job out of university to a credit on Harry Potter.

In the autumn of 2002, I stepped off a cheap one-way flight from Ottawa to Winnipeg with no contract, no accommodation, and no particularly 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.

What followed was ten years of increasingly ambitious fluid simulation work — from a 2D proof-of-concept I hacked together in three days, to novel vortex and tetrahedral solvers that made it into Harry Potter and the Deathly Hallows: Part 2 and Moby Dick, to an attempt at real-time fluid simulation that bears an uncanny resemblance to a technique rediscovered a decade later. Along the way I co-authored nine papers and filed four patents, collectively cited over 500 times. Across all three generations of solvers, the work touched around twenty films in total. Technically, it was some of the most demanding work I have ever done. Commercially, the story is more complicated — but I'll get to that.

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.

What Frantic Films didn't know — and what turned out to be a decisive shortcut — was that I'd already written an open-source FFT library called Exocortex DSP. The Stable Fluids method is elegant partly because it exploits periodic boundary conditions that can be solved efficiently with Fast Fourier Transforms. 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 — and we finally 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 introduced the need to explicitly 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.

But the real technical challenge was memory. 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 entirely.

RLE Level Set Simulations

Our solution was a run-length encoded (RLE) representation that excluded dead space from both the level set and the velocity fields simultaneously. In air regions, we tracked no cells at all. In the level set, we skipped interior and exterior regions entirely, maintaining 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 fully hierarchical version that was more algorithmically consistent and even more efficient — avoiding any dimension retaining a full 2D allocation. The full journal treatment of this work, published as Hierarchical RLE Level Set in ACM Transactions on Graphics in 2006, was co-authored with Morten Bojsen-Nielsen, Christopher Batty, Ola Nilsson, and Ken Museth — who would later go on to create OpenVDB, now the industry standard for volumetric data in VFX. The paper has been cited nearly 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 was essential for getting the simulation to fit in memory at the required resolution.

We also developed a guided animation system for this work, co-authored with Chris Bond (head of the VFX studio) and Mark Wiebe: rather than letting the physics run freely, we wanted to art-direct the tar monster's motion toward intended shapes without overriding the underlying simulation entirely. This required a unified level set representation for handling occlusion and blending. 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 entirely on software. Fluid simulation stayed central to our work, but I made a deliberate decision 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 constantly ran 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), who did important work on a cache-optimized kernel system. The approach was elegant: rather than passing data through one operation at a time, you would layer 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. The result was dramatically better cache locality and a meaningful speedup on real simulations.

I should be honest, though: we over-corrected. We spent a lot of time on low-level optimizations that, in hindsight, were a distraction from building market share. C# had its problems, but we had replaced one set of rabbit holes with another. The right answer was probably somewhere in between — and we did at least get external validation for the approach: Intel featured Exocortex in their Visual Adrenaline magazine at SIGGRAPH around the time of the Harry Potter release, distributed to all SIGGRAPH attendees. That was genuinely 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. Using 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 fundamentally can't, and to handle complex boundary conditions more naturally. 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. It was proof that tetrahedral fluid simulation could survive contact with a real production, even if the complexity of working with unstructured meshes kept it from ever being as broadly approachable as grid-based tools.

Slipstream: Vortex Particle Simulation#

The more commercially successful Exocortex fluid product 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.

This gave Slipstream a key production advantage: no bounding box. Every traditional grid-based solver requires you to define a simulation domain upfront — if your smoke drifts outside that volume, it simply vanishes. Vortex methods are inherently unbounded. For large atmospheric or environmental effects, this was a real practical benefit.

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 fully abandoning the physics. The theoretical foundations were captured in a 2013 paper co-authored with Mauricio Vines, J. Lang, and W.S. Lee in IEEE Transactions on Visualization and Computer Graphics.

The Real-Time Tangent: Gaussians and Unreal Engine#

While building the vortex-based solver, Stefan Xenos and I explored whether fluid simulation could be pushed to real time. We developed an Unreal Engine 3 plugin that ran vortex-based fluid simulation at real-time frame rates. The method was highly scalable: perfectly sparse except where the vortices existed and where they were actively advecting fluid, which kept the computational cost tightly bounded.

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

SlipstreamRT real-time fluid simulation running in Unreal Engine.

The fluid volumes were represented as Gaussians — initially spherical, but stretching 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 at this now, the resemblance to 3D Gaussian Splatting — the influential 2023 technique for real-time neural rendering — is striking. We were essentially doing dynamic volumetric Gaussian splatting for fluid simulation, about a decade earlier. The core idea of representing a continuous field as a collection of oriented Gaussians that split under deformation maps closely to what Gaussian Splatting later formalised. I still think there may be value in revisiting the approach with the more rigorous theoretical framework that Gaussian Splatting has since developed.

The real-time experiment ultimately didn't become a standalone product — we noticed there was stronger demand for the offline VFX use case and refocused — but it generated some of our more cited patent work.

Harry Potter and the Deathly Hallows: Part 2#

The peak of Slipstream's production use came through our partner VFX studio Gradient Effects on Harry Potter and the Deathly Hallows: Part 2 (2011). The film required large-scale atmospheric effects that would have been impractical to achieve with a bounded grid solver at the required scale and resolution — exactly the problem Slipstream was designed for.

Harry Potter fluid simulation

What made this particularly striking to me was a convergence I hadn't planned for: 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 — running on the same film simultaneously.

It was a strange and quietly 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. The collaboration was genuinely formative.

Selected papers and patents, in roughly chronological order:

Lessons from a Decade of Solvers#

There is a version of this story that focuses entirely on the technical achievements and calls it a clear success. In a narrow sense, it was. But here is the honest comparison: across ten years of work and three generations of fluid simulators, the work touched around twenty films. Deadline, which I co-created at the same time using a filesystem as a database, has been used on hundreds upon hundreds of films and continues being used today.

The fluid simulation work was far more technically demanding — more raw innovation, more rewrites, more research, more sheer problem-solving. And it had a fraction of the impact.

The most important thing I learned: product success comes from the size of the addressable market and how well you serve it, not from the technical complexity of what you built. Every VFX studio needs to render. Only some need fluid simulation. That asymmetry explains everything. Technical complexity can make something slightly more defensible, but it is essentially irrelevant compared to whether you are solving a real market opportunity. The technically easier path, taken seriously and executed well, will almost always outperform the technically hard path taken for its own sake.

The C++ transition at Exocortex is a smaller version of the same lesson. We had real problems with C# — memory pressure, GC pauses, poor cache performance — and we fixed them. But we overcorrected, spending months on low-level optimizations that, in hindsight, were a distraction from building market share. When you fix the thing that hurt you last time, it's easy to go too far. The switch cost us development velocity, and the deep optimization work, while intellectually satisfying, wasn't what our customers were paying for.

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 genuinely difficult problems shaped how I think about engineering. But I try to carry that lesson forward: chase the market, not the complexity.

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.