View Fluid Simulation
A Fluid Simulation (”fluid sim”) is a special toolset that helps to mimic the effect of fluids in an environment. It’s important to note here that the term “fluids” is used more along the scientific terms, where the term fluid can incorporate fire, smoke, gas, etc. The term may or may not actually refer to liquids like water. Neat, huh? That’s why some fuid sims that you see on the market may not actually include the ability to simulate that icy cool glass of milk you had in mind. At least, not today. Then again, there are some sims on the market that handle liquids very well. We are only now starting to see simulation systems that handle both with a high degree of competency, and they have widely varying costs involved.
Fluids and other simulations are notoriously difficult to “control” in the way that a director or client may want you to do. So, what is a fluid sim anyway? Here is where things can get technical. Fluids can be anything from fire, gas, smoke to water, milk, mercury and so on. Fluids interact with the environment. Some fluids can be encased within the environment, much like a glass of beer is encased within the glass itself. Fluids are subject to the physical forces around them: gravity, heat, friction, wind and so on. There are many different kinds of fluids: solvents, like water, gradually wear away its surroundings. Think Grand Canyon. Fuels or combustables require an ignition and atmosphere in order to ignite and burn. The type of fuel will dictate the behavior post-ignition. In human terms, gasoline will burn differently and produce different soot and smoke particles than will magnesium. Oh, and fuels can be either solid, liquid or gas. Other fluids are corrosive or acidic; they burn on contact, often with devastating results.
Fluids are influenced by their surroundings. In the case of containers or other nearby matter, fluids can be either repelled or absorbed. Hydrophobic materials will repel many different types of liquids, with water being the most common. The results will be no absoprtion by the material, and the fluid will tend to pool and blob up if on a level surface. This children’s product called “Moon Sand” is a classic example of an hydrophobic material (and fun to play with, too!) Hydrophilic materials will absorb liquids, and this will be apparent when a material, such as a woven cotton cloth, changes color and texture when absorbing the material. Regular sand will absorb the liquid until it becomes saturated, at which point the particles will become a slurry, suspended within the liquid until the liquid evaporates back into a gas. Typically fluid sims will NOT account for the way the fluid interacts with surrounding materials by modifying those materials (turning wood to charcoal for example). You will need to account for this change yourself, using the other tools at your disposal.
Fluid sims will correctly replicate the transition of energy from the fuel to the fluidic state. As you ignite a fuel and then observe it as it burns, you will see that once the resulting burn achieves a certain termperature, smoke will be more and more prevalent, as the soot generated by the burn is driven into the air by the heat of the burn. This smoke will be influenced by air currents, and the air currents will turbulate as they are also affected by the heat of the burn. As the smoke particles cool, they will change color (typically lighten) and will then eventually dissipate into the air and scatter away.
Today’s fluid sims will get you great fire and smoke effects, or great water and liquid effects, and sometimes both. Today’s fluid sims will also use the GPU card, depending upon the card itself and the application. A good, reasonably new gaming card will do the trick. Having the simulation tasks offloaded to the GPU will often get the sim completed faster than just the CPU alone. And that’s good, because fluid sims meant to simulate larger scale events such as building fires, rocket exhaust and so on will typically take longer to simulate than a campfire. That said, we are getting to the point to where you can actually see the final result rendered on the GPU. This has already occured in some feature film pipelines, and developments such as this tend to migrate down into DCC applications after a period of time.
Another thing to be aware of is that most fluid sims will not take advantage of network rendering or render farms, at least, not for the simulation parts. What that means is that you will need to run the simulation on a single machine, and then save the result in a cache file. Once you have done that, you can then use the render farm to render the results, and they will be consistent machine to machine.
Fortunately, rendering the result of a fluid sim doesn’t take very long, especially in consideration of the time it takes to generate the sim in the first place. The most expensive rendering options for the results of a fluid sim are about the same as a typical scene: global illumination, 3D motion blur, and depth of field. A few tests on key frames will let you know if you can afford to render those effects directly, or if you need to seek other options.
In production pipelines, its quite common to render the simulation results separately, and composite the render passes of the scene together for the final results. Doing so allows you additional options in the 2D image realm that are not available, or expensive (in terms of time) in the 3D rendering realm.
So how do fluid sims perform this magical feat? The sim engine will take the information that you provide, in the form of properties or attributes (and hopefully presets!) and will then consider other inputs, such as particles, as these attributes interact in a container over time. You need to provide a container, as a fluid sim cannot simulate the universe (yet). The container is a cube that you define in the 3D editor. Typically, you need to make the cube large enough to hold the simulation, but not so large as the sim won’t complete, or beyond what the camera (and anything that will reflect the sim) will actually see. In some cases, fluid sims have a “dynamic volume” which can change the size of the fluid container on the fly. In many sims, once complete, the container can actually be animated within a scene from its original position, which is a great time saver. In addition, you can even reuse the results of a sim in multiple shots or scenes, as long as they conditions are similar enough to where you can get away with it. You can even reference some sims in other scenes if you like.
So, once you have the attributes, the sim container volume, and the ignition condition (typically a particle emitter, though not always), the simulation can actually begin. The simulation volume takes the container and dices it up into little cubes. These cubes are called “voxels.” You can think of them as 3D pixels, because, well, everyone else does. Similar to 3D rendering, these voxels are then tested for activity, and if there is activity (some action that occurs as a result of the simulation), then that activity is further examined (via the attributes) to produce the scientifically correct behaviors of fluids according to the laws of physics. The simulation progresses through the timeline, gradually resolving the outcome. Most fluid sims will show some representation of the simulation’s progress in the 3D editor. Once you have an initial pass, the sim will revaluate given the attributes you specify. In some cases, you can “fake” additional detail with shaders that the sim will allow. Use this option if you can, as the option of continuing the sim to extreme granularity will take longer than it does for congress to pass a budget, and more painful than it would be for you to pass a stone (well, maybe not).
In the end, you will have a simulation that can then be rendered. If you cached the simulation, you have the option of rendering on a render farm. You are free to light the scene that contains the sim after the fact, and animate, etc, after the sim has been performed. Remember, the sim is not actually visualized until its rendered in the render engine. Until that point, you can think of it as a series of directions that will react to environmental changes like lighting. If any animation you do is intended to affect the sim, like a car driving through ground fog, than you will need to at least have a placeholder animation set up prior to the simulation.
Simulations are NOT camera-depedent, so you are free to choose camera angles after the fact, though beware of the camera seeing off the boundaries of the container. The results will look very odd in that case. You can also render any amount of cameras with any point of view, focal length, etc. The simulation is just about itself, and anything that you need to directly affect or interact with it.
It’s a good idea to keep in mind that while a fluid sim is following reality as dictated by the rules of physics, you are free to manipulate that reality. As noted, you can change lighting, camera angles, and so on, after the sim has completed. You can use the sim results in different scenes. You can treat the sim container as any other object within a scene, and scale it, animate it and more, up to a point (and that threshold is defined by you most of the time).