Heating Up

One final ingredient that often goes along with a fluid system like this one is the heat of the fluid or gas at each location. Sources of smoke are usually hot, which heats up the air the smoke initially occupies, causing the smoke to rise because higher temperatures mean more energy, which means the fluid molecules are moving faster, which means higher pressure, which means lower density (remember density is only proportional to pressure at constant temperature), which makes the hot air rise.

Now, that's a complex sequence of events, but it's initially simpler to just model the result "hot air rises" and have the relative temperature of a cell create a proportionate upward force on the velocity field at that cell. We can do this trivially by adding a scaled copy of the heat field to the Y velocity field.

Similarly, rather than attempt to model the effects of heat in the initial phases of a simulation, I found it easier to simply model the expected results. So, although a flame creates heat which makes the smoke rise, more pleasing results were found by "manually" giving the volume of air around the flame an initial upward velocity and letting the heat take it from there.

With more complex systems, such as an explosion, the fiddly physics happen in the first tenth of a second, so you can just skip over that and set up something that looks visually pleasing with our simplified physics.

Filtering Out Artifacts

The simplistic application of forces we perform for acceleration due to pressure (Figure 2) has the tendency to introduce artifacts into the system. These typically appear as unnatural looking ripples. The way to deal with them is to smooth out the velocity and pressure fields by applying a simple diffusion filter.

If you use the Stam-style reverse advection with projection, you have to use a computationally intensive filter, iterating several times. But with the inherent diffusion of forward advection, in cooperation with the accuracy of the combined forward and backward accounted advection, we can get away with a single iteration.

It's often difficult to see exactly what effect a change can have on a fluid system. The fluid is very complex looking, and small changes to parameters often have an outcome that's not immediately obvious. The ideal way to solve this problem is to set up your system so you can run two copies of the same system in parallel, with one using the modified parameters. The difference becomes obvious. Figure 3 shows such a comparison.

Fluid Ideas

I've glossed over a few other important aspects here, but details of these aspects can be found in the accompanying code.

Be sure to pay particular attention to how you handle the cells that are at the edge of the system, as the differing number of neighbors has a significant effect. At the edges of a system you have the option of reflecting, wrapping, or zeroing values, depending on what you want.

By wrapping in one direction, you essentially get a tiling animated texture in that direction, which could be used as a diffusion or displacement map for the surface of a moving stream of fluid.

There's also the issue of friction. Motion in a fluid is generally quite viscous, which can be implemented as a simple friction force that applies to the velocity field. If there's no friction in the fluid it will slosh around forever, which is generally not the desired effect. Different viscosity settings give very different visual results.

There is a large number of variables that you can tweak to give radically difference visual results, even in my rather simple implementation. Spend some time playing with these values just to see what happens.

[EDITOR'S NOTE: This article was independently published by Gamasutra's editors, since it was deemed of value to the community. Its publishing has been made possible by Intel, as a platform and vendor-agnostic part of Intel's Visual Computing microsite.]