February | 2019 | Softology's Blog

I am a huge fan of anything related to fluid simulations. This interest was once again sparked when Daniel Shiffman covered fluid simulation in his latest Coding Train video.

As always, I recommend Coding Train to any developer. Dan has a unique way of making his programming topics both interesting and entertaining.

The code converted during the Coding Train video (Mike Ash’s Fluid Simulation For Dummies) is based on Jos Stam’s Stable Fluids code.

Jos Stam

Jos Stam wrote his seminal paper Real-Time Fluid Dynamics for Games back in March 2003. I have lost count of the times I seen the paper cited or linked to. It has had a huge influence on fluid simulation.

The original source code from the paper is provided here and here.

Going back 11 years, one of my first YouTube videos was this super low resolution example of 2D fluid simulation using Stam’s methods.

3D Fluid

My main objective when revisiting Stam’s stable fluids was to get a 3D version going.

A quick Google search led me to Blain Maguire’s implementation which I was able to translate into a working 3D fluid simulation.

By default Stam’s fluid method generates a fairly smoothed fluid/smoke flow. To make things more interesting you want to add a bit of turbulence. The key term here is “vorticity confinement”. Vorticity confinemement was first described in the paper Visual Simulation of Smoke by Fedkiw et al.

I found some 3D source code for adding vorticity confinement to Stam’s stable fluids here. See the fluid.cpp file inside the fire32.tar.gz archive.

At this stage I had 3D fluid working. Now comes the fun part, how to display the fluid.

Displaying 3D Fluid

Once you get the code working, the main issue becomes how to display the fluid.

Stam’s fluid uses what is known as an Eulerian approach to fluid simulation. Rather than track individual fluid particles (as in SPH simulations) the fluid is simulated by tracking velocity and density at fixed grid based locations in 3D space. This means that as the simulation runs you have a 3D grid of fluid properties that need to be displayed.

The method I use is to hide the cells that contain a fluid velocity lower than a threshold value. 0.01 seems to work OK for my tests. Then render the cells as spheres or cubes. Color shaded based on fluid velocities.

For a fake volume rendering like approach you can render the fluid using translucent billboard quads. If you run a pre-render pass over the array and strip any cell that is surrounded by other cells it results in only having the “shell” of the fluids rendering. Rendering these shells with the billboard particles gives a nice result.

Movie results

Availability

3D Jos Stam Stable Fluids are now included in Visions of Chaos.

Jason.

Origins

Back in the 1980’s Fred Mitchell designed a method to visualize Newtonian gravity he called the Mitchell Gravity Set or MGS. See here for his page explaining MGS.

This process of plotting dynamic systems is usually referred to as basins of attraction. See this paper and this paper for other versions of plotting gravitational basins of attraction. Similar methods are used when plotting Root-Finding Fractals and the basins of a Magnetic Pendulum.

The 2D images in this post are from when I first experimented with MGS back in 2005.

The basics of MGS is that you have a number of gravity objects (stars or gravity wells) in 2D space. Each pixel of a 2D image becomes the starting coordinate for a particle in that 2D space. The particle is attracted to the stars through Newtonian gravity and moves. You follow the path the particle takes for a number of steps and color the pixel depending on how long it took to be flung out of the simulation area.

I ended up rewriting/translating my old code into GLSL for speed. Click here to see the shader source code that generates these 2D Gravity Set images.

By playing with the various star positions and masses you can get a variety of different images.

The following image shows the current Gravity Set Options dialog in Visions of Chaos showing the various settings that can be tweaked.

Revisiting and Extending Into The 3rd Dimension

I was recently contacted by Fred again and he mentioned he was working on getting a 3D version of MGS going. Getting the 2D code going in 3D is simple enough. Just a few extra lines for adding the Z dimension, so I was inspired to have a go at seeing what the 3D versions could look like. The settings dialog is extended as follows.

Similar to the other 3D grid based displays like 3D Cellular Automata I have worked with, displaying a 3D grid of values can be tricky.

The following examples use a 500x500x500 resolution space.

The most obvious is a 3D Grid of little cubes. Each smaller cube is a starting point for the gravity calculations. Color the cubes depending on which gravity well they come closest to during their journey.

That gives you a general idea of what the shapes of the 3D Gravity Set will be, but the interior is completely hidden.

You can slice an eighth of the cubes away….

or even slice a half…

Another option is to only display the cubes for only half of the gravity wells….

or even for only a single well.

Then came the idea for “volumetric rendering”. I already had code for rendering transparent billboard quads so I used that. I am only rendering the edges of each gravity well area. If you render all points the image is just a white blob mess.

Another method. Export the visible cubes as a OBJ point cloud. Import the OBJ into MeshLab. Use MeshLab to generate normals for the points and then marching cubes to generate a mesh from the point cloud. Export the mesh as a PLY format file. Import the PLY into Blender and render it. These are rough results. I am sure someone who knows more about MeshLab and Blender could clean up the mesh and make a much better looking render.

Here is a sample movie of rotating gravity sets.

Magnetic Pendulum Alternative to MGS

I also tried using Magnetic Pendulum formulas in 3D to do similar plots. The formula is a 3D extension of the 2D code I used here. Otherwise the rest of the code is the same as for the 3D MGS above.