One of the most important reasons to use simulations in 3D work is to obtain effects that would be extremely difficult or impossible by using only traditional methods of mesh modeling and keyframe animation. Free-flowing fluids and smoke are good examples of this. In this chapter I’ll talk about Blender’s powerful volumetric fluid and smoke simulation tools, which are capable of animating a wide variety of fluid and smoke scenes much more realistically than could be done by hand.
In this chapter, you will learn to
Blender’s fluid simulator was developed as a project sponsored by the Google Summer of Code 2005. The official name of the simulator is the El’Beem Fluid Simulator, a play on the name of the method it uses to calculate deformations, the Lattice-Boltzmann method.
The Lattice-Boltzmann method (LBM) is a state-of-the-art technique in computational fluid dynamics for calculating the movement of fluid surfaces. It operates by treating the fluid surface as a lattice of triangles over which a large number of particles travel and collide with each other. The transference of force from the collisions of the particles drives the movement of the fluid surface. This method is capable of producing convincing fluid movement and allowing a variety of parameter settings to influence the characteristics of the fluid. Furthermore, its calculations are local and so the algorithm can be parallelized. LBM is a good method for simulations in which detailed interaction between the fluid and solid objects is desirable, as in the case of CG animation. LBM also has the potential for considerably expanded functionality in the future. For now, there is more than enough interesting and useful functionality to keep Blender users busy exploring the potential of fluid simulation, so let’s get to it.
Every fluid simulation has two necessary components. The first is a defined area in which to carry out the simulation, and the second is a source for the fluid itself. The fluid simulation algorithm operates by dividing space into discrete units called voxels. You can think of voxels as being something like 3D pixels. In fact, the word voxels derives from the words volumetric and elements, just as pixels derives from picture and elements. In the same way that a single image or display must be limited to a finite number of pixels, an area of calculation for fluids is limited to a portion of space that can be divided into a finite number of voxels. This portion of space is called the domain, and its area is defined by the Domain object. Without defining a Domain object, it is not possible to initiate a fluid simulation.
One way to introduce fluid to the domain is via the Fluid object. This is a mesh positioned inside the domain that defines the volume of the fluid for the simulation. As you’ll see later in the chapter, the name of this component is somewhat misleading. The properties of the fluid itself, and the mesh representing the simulated fluid in motion, are all dealt with by the Domain object. For example, when you want to assign a material or activate a Subsurf modifier on your fluid, you will do this on the Domain object mesh. The Fluid object is used to define the volume and to set some initial velocity parameters.
For your first fluid simulation, the Domain will be already set up, if you’re using a default Blender installation. The familiar default cube will do fine. In fact, for your Domain object, you can always use the default cube and simply scale it to suit your needs. The Domain object never needs any special geometry, and although you can use another shape such as a sphere, a monkey, or even a plane for your domain, the domain will always be calculated as a 3D rectangular box.
Because the domain of your fluid simulation is going to be a 3D rectangle, you generally have an ideal domain mesh provided automatically in the form of Blender’s trusty default cube. To get started on fluids now, I’ll present a few examples that use the default cube entirely unmodified as the domain. Go ahead and fire up a session of Blender, and then open a Front view by pressing 1 on the number pad. Right now, you should be looking at your cube in Orthogonal view mode. Press the Z key to enter Wireframe mode, as in .
Enabling the cube as a fluid domain is simple. The pertinent buttons can be found in the Physics area of the Properties window, shown in .
Make sure the default cube is selected. Then click Fluid and select Domain, as shown in .
That’s all there is to setting up a fluid domain. This determines the area in which the fluid simulation will be carried out. There are several parameters to set, which I’ll discuss shortly. However, for the time being, you can leave things as they are.
There’s still something important missing, and that’s the Fluid object. To add one, make sure that your cursor is snapped to the center of the cube (select the cube, press Shift+S, and select Cursor To Selected); then press the spacebar to add an Icosphere mesh. Use the default parameters for the Icosphere so that you wind up with something like .
Any shape will do as a fluid. I’ve selected an Icosphere here mainly for visibility, although, as you’ll see shortly, the Boolean properties of Fluid objects mean that spheres can be especially easy to work with. The Fluid object mesh itself is used only to determine the initial shape and volume of the fluid. When the fluid simulation begins, a new mesh is created in that shape, so the geometry of the Fluid object mesh becomes irrelevant.
To enable the sphere as a Fluid object, once again go to the Physics properties area, this time with the Sphere object selected, click Fluid, and choose Fluid, as shown in .
You’ve now finished setting up the fluid simulation and are ready to run the simulator, a process also called baking the fluid.
When the simulator runs, it creates a new mesh for every frame of the animation, representing the shape of the fluid at that moment. These meshes are numbered and stored in your system’s default temporary directory by default. On my Windows 7 system, for example, the path filename base for the fluid cache is C:\Users\tony\AppData\Local\Temp\cache_fluid. For now, let’s create a specific directory for each simulation example by replacing the cache_fluid string with cache_ex1. Select the Domain object, and set the output directory on the Fluid simulation panel to the temporary directory for your own system. Click Bake, as shown in .
When you bake the fluid, the animated sequence is created frame by frame. Some illustrative sample frames can be seen in . If you play the animation while baking, it should play back the frames as they bake. The bake will take a few minutes. If you get tired of waiting, you can press Esc at any time and you will be able to play back what you have baked so far in something like real time. If you do stop in the middle but want to bake the whole simulation, you will have to go back and start baking from the beginning. If you want to go through these examples quickly and don’t mind lower quality than what you see in the figures, try setting the Resolution to a lower value in the Fluid properties area with the Domain object selected.
After the fluid is baked, take a look in the directory you saved the fluid cache to. You’ll find a lot of files with names such as fluidsurface_final_0000.bobj.gz. These files contain the actual meshes for each frame of the fluid simulation. For this reason, it’s good to get into the habit of assigning a new output directory for each fluid project you create. If you do a lot of fluid simulations, these can begin to take up space, so be sure to clean out your fluid simulation output directories from time to time.
After you’ve baked your fluid, you can run the animation as you would run it ordinarily in Blender, using Alt+A or the animation playback button on the timeline. Don’t forget to view the splashing fluid in Solid mode from a variety of angles to admire your handiwork.
In Shaded mode, the Fluid object is still visible and will most likely occlude most of the simulation. Sending the Fluid object to a different layer will get it out of the way.
Adding a Subsurf modifier and selecting Set Smooth will improve the overall look of curved surfaces but will greatly slow down the simulation. As you’ll see later in this chapter, there are other, better ways to improve the look of fluid surfaces, which can make subsurfacing redundant, but in cases where the simulation looks choppy, subsurfacing can improve things considerably.
After a fluid is baked, the Domain object assumes the shape of the fluid simulation mesh and does not return to its original shape in Object mode as long as the fluid sim meshes remain in the specified output directory. (You can still see the Domain object’s original shape in Edit mode.)
To return the domain to its original shape in Object mode, there are several possibilities. One is to clear the meshes from the output directory by hand via your Windows, Mac, or Linux OS interface. Another is to select a new, empty output directory for your fluids.
The fluid in the simulation takes its volume and initial shape from the Boolean intersection of the Domain object with the Boolean union of all enabled Fluid objects. To see this in action, let’s return to the previous example. I selected a new output directory to clear the shape of the Domain object, so it’s back to the original cube shape. Let’s see how multiple Fluid objects behave in a simulation:
This behavior can be useful, because it enables you to work with fluids by manipulating simple shapes and doing very little modeling for the initial shape of the fluid. For example, when placing fluid in a container, it may be simpler to fill a container with overlapping balls rather than trying to accurately model the inside shape of the container. This is how I placed the fluid in two of the examples later in this chapter.
When multiple fluids do not overlap, they behave as you would expect. Try reducing the size of the Fluid object spheres in this example so that they don’t overlap, and rebake the fluid. The result should look similar to .
By default, the amount of fluid that is released from a Fluid object depends on the volume of the original Fluid object. This can be altered so that the amount of fluid depends on the surface area of the object’s mesh. This makes it possible to use nonclosed meshes as Fluid objects. There are three options for initializing fluid volume from the Fluid object:
For an example of how these two initialization methods interact, consider the shape in .
You can create a similar shape by adding a UV sphere to a new session of Blender. I used eight rings and eight segments to create the shape shown in .
For this example, I positioned the mesh to be bisected by the wall of the domain to show a cross section of the fluid that is produced. In , you can see how the various Init options create different initial fluid states and amounts. The first image shows the Init Volume option. Note that the mesh ring around the middle of the sphere does not contribute any fluid, because Init Volume is concerned only with closed meshes. The second image shows the simulation with the Init Shell option selected. In this case, the fluid begins in a hollow state conforming to the surface of the mesh, with the nonmanifold ring producing fluid. In the third image, both methods are active. In the case of a simple closed mesh, this would result in a slightly larger amount of fluid than Init Volume. In this example, the nonmanifold portion of the mesh is taken into account.
Every fluid has a particular viscosity, which determines the speed and ease with which it flows. Viscosity is a measure of the fluid’s resistance to the forces that deform it. Fluids with high viscosity flow slowly and are perceived as thick, whereas low-viscosity fluids, such as water, are thin. For example, think of the difference between the way that fluids such as water, motor oil, honey, and magma flow—this mainly has to do with their viscosities.
The value used in Blender is known more precisely as the kinematic viscosity. In Blender’s fluid simulator, the fluid’s viscosity can be entered by hand or by using a preset value. Preset viscosity values are also available in the drop-down menu in the Domain World panel. The preset viscosities include Honey, Oil, and Water. The default is Water.
If you select Manual, you can enter a Base viscosity value and an Exponent by hand, as shown in . The default is Base 1 and Exponent 6, which represents the value 1 × 10–6 (the value for water, as shown in ). Remember, the viscosity setting is only one of several parameters that affect the appearance of viscosity in the simulation. Several other factors, notably the resolution of the simulation, also have a great impact on how the fluid looks. The Manual setting can come in handy if you want to simulate a fluid with a significantly different viscosity than the presets, or if you are trying to fake the effect of a fluid simulation that occupies more than a 10-meter area, because a larger area can “thin” the fluid out. Coupled with particle-based spray, using the Manual setting can enhance the effect of larger-scale simulations.
Some fluids and their kinematic viscosities are listed in .
Fluid | Kinematic Viscosity |
Water (20°) | 1 × 10–6 (0.000001) |
Oil SAE 50 | 5 × 10–5 (0.00005) |
Honey (20°) | 2 × 10–3 (0.002) |
Chocolate syrup | 3 × 10–3 (0.003) |
Ketchup | 1 × 10–1 (0.1) |
Melting glass | 1 × 100 (1) |
In addition to setting viscosity, you can set the degree to which the fluid sticks to a surface or slips off the surface. This is done using the Domain Boundary tab. Of course, this produces only an approximation of the behavior of real fluids. In reality, all fluid sticks to surfaces at the molecular level, but to the naked eye, fluids such as water appear to slide right off certain surfaces. Because the fluid simulator operates at resolutions much lower than molecular scale, it is unconvincing to have fluids such as water appear to stick to surfaces. For fluids that should not appear sticky or gluey, select Free Slip from the Slip Type drop-down menu. No Slip will cause the fluid to stick to surfaces, and Partial Slip will set slippage according to the values you enter in the panel’s fields. You can set these options on individual obstacles as well.
Another quality of fluids that can be represented in Blender is compressibility. This is the degree to which the fluid shrinks in size or compresses under pressure. In nature, all fluids are very slightly compressible, but this is too slight to be noticeable at the scales that animators usually want to work with. In fact, the El’Beem simulator can work much faster if the fluid is considered to be slightly more compressible than it would be in nature, which is why this parameter exists. If you find that your fluid seems overly bouncy or elastic, you may want to consider lowering the compressibility.
When you use a Fluid object, the amount and initial location of the fluid introduced to the domain are determined by that object when the simulation begins. Animating the location or scale of a Fluid object will have no effect on the behavior of the fluid after the fluid has been generated. This is suitable for situations in which the amount of fluid you want to deal with is static, such as a sink full of water, but in cases where you want to introduce fluid to or remove fluid from the scene over time (such as an open tap or an unplugged drain), it is necessary to use Inflow and Outflow objects.
Using an Inflow object enables you to produce a steady stream of fluid into the simulation.
For a quick example, fire up a fresh session of Blender and do the following:
As you can probably imagine, the Outflow object is the exact opposite of the Inflow object, and it provides a way to get fluid out of the simulation domain. For an example of an outflow in action, set up a fluid simulation with the default cube and an Icosphere, as in the first example in this chapter, with the cube as the domain and the Icosphere as the Fluid object. Copy the default cube by pressing Shift+D and scale down to 0.2 along the x- and z-axes. To do this, press the S key to scale, followed by Shift+Y to keep the y-axis constant, as seen from the Front view in .
Place this new object in the lower corner of the default cube, as in .
Because this object was copied from the default cube, it already has Fluid Simulation enabled but with Domain selected. Change this to Outflow. Otherwise, if Fluid Simulation is not enabled, enable it and select Outflow. As in the other examples, select the Domain object and click Bake. The resulting fluid simulation will look similar to the images in . As you can see, the fluid is removed from the simulation when it comes in contact with the Outflow object.
In running the previous examples, you probably noticed that this default simulation setup is moving in slow motion. This is because the fluid simulator’s default time span does not coincide with the 10-second default animation length in Blender. The fluid simulator calculates time and space independently from what is going on in other parts of Blender, enabling you to set the parameters for the fluid simulation directly in real-world terms.
The time span for the fluid simulation is set in the Fluid panel of the Domain object. It is set in seconds. By default, the Start time of the fluid simulation is set to 0 and the End time is set to 4, meaning that the simulation covers a time span of 4 seconds. As I mentioned, this is totally independent of the actual animation length. The animation’s length of time is the number of frames divided by the frame rate. By default, the number of frames is set to 250 and the frame rate is set to 25 frames per second, so the default length of a Blender animation is 10 seconds. If the fluid time span is shorter than the animation time span, the fluid simulation will “stretch” to fit the animation time, and so the fluid movement will be in slow motion when the animation is viewed at regular speed. If the time span set in the Fluid Simulation panel is longer in seconds than the actual length of the rendered animation, the motion will be sped up to fit into the time span of the animation. For realistic speeds, the time span of the animation in seconds should be equal to the number of frames divided by the frame rate of the animation.
The real-world size of the simulation domain is set independently within the simulation itself and relates to how fast the fluid appears to move. The size is set in the Real World Size field on the Domain panel in the Fluid Simulation panel of the Domain object. The size is measured in meters, so the default size of 0.500 means that the fluid simulation is calculated within a half-meter cube. If the shape of the Domain object is oblong, the size value represents the longest edge of the Domain object’s bounding box.
How you set the size value depends on the size of the area within your scene that needs to have fluid simulation enabled. Take into consideration the relative size of the props you are using and also the area in which splashes and spills need to happen. The maximum real-world size for a fluid simulation is 10 meters.
In terms of the time and memory needed for calculating the fluid simulation, and also in terms of the quality of the results, the most significant parameter to set is the Resolution parameter. As I mentioned before, the fluid simulation domain is divided into discrete units called voxels. The density of voxels in the domain is the resolution of the fluid simulation. Resolution in this sense is directly analogous to image resolution; higher resolution yields clearer and more-detailed representations. The numerical resolution value you enter indicates the number of voxels that make up the longest edge of your domain. The amount of memory required to calculate a domain of a certain resolution does not depend in any way on the absolute size of the object or on the real-world size of the simulation, but it does depend on the volume of the domain with respect to the longest edge of the domain. This means that for any given resolution, a perfect cube-shaped domain will require the most memory.
In practice, the resolution you need is dependent on two factors: the precision or fineness of the interaction between the fluid and other objects and the size of the area in which the fluid has to interact. Having a fluid that interacts in a convincing way with small objects but also involves a large area (and remember, splashing counts!) requires high resolutions. If your resolution is too low, your fluid will appear thick and gluey even if its viscosity is set correctly. In the bottle example shown in , higher resolution (over 300) is needed because the fluid has to be fine enough to come out of the bottle smoothly, but the domain needs to be big enough to allow for a fairly spread-out splash. This example required slightly more than 3 gigabytes of RAM. The amount of memory needed goes up with the cubed value of the resolution, meaning that slightly higher resolution can take considerably more memory. Blender’s fluid simulator has a maximum resolution of 512, which requires almost 13 gigabytes to process. Hardware is not the only bottleneck here. Some operating systems also place limits on the amount of RAM that can be used at one time by a particular program.
Blender’s fluid simulator has several options for using particles in conjunction with the simulation. Particles within the simulation are related to Blender’s native particle systems but are restricted in the degree to which they can be adjusted by hand. In this way, particles generated by the fluid simulator are analogous to meshes generated by the fluid simulator, which cannot be edited by hand, cannot take shape keys, and so forth.
There are two distinct ways to use the particles, although they are not entirely independent of each other. One use of particles is to enhance the appearance of the fluid sim meshes themselves. In this case, the particles are used to contribute actual geometry to the mesh, which can result in the appearance of higher-resolution simulations and greatly increase the “splashiness” of the simulation. The other option is to use the same particles in a more traditional way, to add a halo-based haze to the fluid that follows the fluid’s movement in a sensible way. This can be particularly good for simulating foam and spray from rushing water and can be useful when faking larger-scale fluid effects. Furthermore, there are three distinct types of particle systems created by the fluid simulator that are used in slightly different ways, as you will see in the next section.
To see a good example of how particles can be used to get splashier fluids, set up a fluid simulation with an inflow along the lines of the example shown earlier in .
The relevant fields for adding a particle-based effect can be found in the Domain Particles panel in the Physics properties area of the Domain object. The degree of splashiness (and the number of particles) is determined by the value in the Generate Particles field. The default value of 0 means no particles are generated. A value of 1.00 means a “normal” number of particles are generated, and a value of greater than 1 means more than a normal number are generated. The degree of splashiness that you actually see as a result of the particles depends also on the force with which the fluid strikes an obstacle or wall. This, in turn, depends on the initial velocity of the fluid and on the impact factor of the obstacle, which I talk about in the next section.
In order for the particles to affect the mesh geometry, it is also necessary to set the Surface Subdivisions on the Domain Boundary panel to a value greater than 1. The values should be set as shown in .
shows several renders of the same frame in the same animation to illustrate the difference in using varying amounts of particles: 0, 0.05, 1, and 5. (All simulations are Resolution 50 with Surface Subdivisions set at 2.) As you can see, a greater value for particles increases the splashiness of the simulation. Increasing the fluid’s velocity also increases the violence of the splash.
When you set a Generate Particles value of greater than 0, two particle systems are created: Drops and Floats. The two systems move differently and play complementary roles in augmenting the simulation. These same particles can also be used as halo particles, to obtain a haze or foam effect that follows the motion of the fluid simulation in a convincing way. An additional type, Tracer particles, can also be used in this way.
To access these three particle simulations individually, as objects in their own right, it is necessary to enable yet another type of object for the fluid simulation, namely a Particle object. You’ve probably noticed the Particle option on the Fluid Simulation drop-down menu by now. This is what you will select to enable the Particle object.
To see an example of this in action, set up a fresh fluid simulation with the default cube as the domain and a small Icosphere as the fluid, as shown in . For the particle control objects, I’ve also added three Suzannes to the simulation by pressing the spacebar and selecting Add > Mesh > Monkey and placed them in an accessible spot. These do not need to be inside the domain area, and any Mesh object will do. The entire setup should look something like .
You set up particle objects the same way you do fluid and domain objects—by enabling Fluid Simulation and selecting Particle. Each Particle object can be used to control one or more of the three types of particles available. The three types are as follows:
Although it is possible to activate all three particle types on a single Particle object, I’m using three separate monkeys for visualization purposes. Enable fluids with the Particle options selected as in .
As for the fluid simulation itself, I’ve left all the values on the domain at the default, except of course the particle values. To create Drop and Float particles, you must enter a nonzero value into Generate Particles, and to create a Tracer, you must enter the number of particles you want as Tracer particles. For presentation purposes in this example, I’ve set the particles at a very high level in order to make them as visible as possible in the screen shots. I set the Tracer particles at 10,000 and the Generate Particles value at 10.00. In practice, a Generate Particles value of 1.00 is considered “normal,” and depending on the situation, even much less than this is often sufficient.
When you bake the fluid simulation, the three particle systems are generated. These particle systems now can be selected similarly to ordinary particle systems, by selecting their base mesh, which is the Particle object associated with the particle type. As you can see in , when the monkey associated with Drops is selected, the float particle system shows up as a selected system, and likewise for Floats and Tracer. This figure should also give you an idea of the different roles that the Drop, Float, and Tracer particles play. As you can see, Drops spread out from the center, whereas Floats tend to stay collected in a central area where fluid is. Tracers trail behind the falling fluid and lead back to the original sphere-shaped Fluid object mesh (over time, they will catch up to the fluid’s current location).
You can add a material to a fluid simulation Particle object in the same way as you would with any other object. To edit the halo settings for the particle system, activate Halo on the particle material. Although the Particle object mesh is entirely separate from the particles, its relationship with the particles is similar to that of the emitter mesh with ordinary particle systems. You can parent another mesh to the Particle object and use Blender’s dupliverts functionality to associate an instance of the mesh with each particle. You can manually edit some of the particle settings on the Particle object, such as the life span, but you are restricted from editing others, such as the number of particles, which are determined by the fluid simulator.
In the following examples, Tracer particles are turned off (set to 0) and Generate Particles is set at 0.05. Even with this light use of particles, you can already get an idea of the possibilities. Set the particle material values as in , with a Clouds texture as shown in (mapped to alpha), to get a steam-like effect as in .
Changing the halo type as in and giving the particles a distinctive blue-green color will result in the eerie phosphorescent effect in .
Finally, by creating small spheres (I used Icospheres of subdivision 1, to minimize extraneous vertices) and dupliverting them onto the particles, as discussed in Chapter 3, “Sculpting and Retopo Workflow,” it is possible to create a reasonably convincing bubble effect, as shown in . The material for the bubbles is a copy of the water material with Ray Mirroring increased slightly.
Making fluid splash around in the shape of a cube is fun for a while, but the real usefulness of the fluid simulator truly becomes clear only when you introduce other objects for the fluid to interact with. Such objects are called obstacles in Blender’s fluid simulation. In this terminology, an obstacle is not just a dam or a wall but any object that interacts physically with the fluid. A cup is an obstacle for the coffee inside it, and your whole body is an obstacle when you scoop water up with your hands and splash it on your face—although in Blender these two cases are treated slightly differently, as you will see shortly.
In the simplest case of a nondeforming mesh obstacle, enabling the object as an obstacle for a fluid simulation is as simple as—you guessed it—enabling the fluid simulation for the object and selecting Obstacle.
To look at a simple example of this, start a new session of Blender.
If the obstacle and the fluid intersect at the beginning of the simulation, the place where they intersect is removed from the fluid. In , the highlighted Obstacle object bisects the Fluid object completely, resulting in the simulation behavior shown in .
For a simple example of fluid interacting with an animated obstacle, set up a fluid simulation with a default cube as the domain and an Icosphere as the fluid.
If an object is deformed by an armature or in some other way, it is necessary to check the Export Animated Mesh option when making the object an Obstacle, as in . This takes extra computing time and should be used only when the actual shape of the obstacle mesh changes over time.
As an example of this, I set up a simple rigged arm obstacle and a fluid system that uses a rectangular fluid, placed at the bottom of the domain, as shown in .
In , you can see the resulting fluid behavior when the armature is animated and the corresponding arm mesh splashes.
Fluid simulation parameters can be animated. Viscosity, Gravity, Size, even Resolution parameters can be keyed in the ordinary way: by pressing the I key with the mouse over the relevant field in the Properties window. One parameter that is particularly notable is the Enabled check box for Inflow objects, shown in . This parameter is used to animate turning the flow on and off.
Obviously, because the fluid simulation itself depends on the keyed values, it is necessary to set the keys prior to baking.
A CG fluid simulation needs to be set up in such a way that it looks right in the shot. When working in the highly controlled environment of CG, it’s sometimes easy to forget the degree to which naturalistic phenomena can need time to get into position. Blender fluid systems often begin in unnatural states, and the transition into the correct state for the shot may involve unwanted movement or splashing. You may find it necessary to run a simulation for some time before your actual shot begins, in order to let the fluid find some equilibrium. You may also need to apply off-camera “cheats” such as guiding or pushing your fluids in ways that do not show up in the shot itself. You have to be creative. The important thing is to get the shot you’re after. Nobody sees what goes on before and after the shot or outside the boundaries of the camera.
In this section, you will look at a few examples of fluid setups and see how to get the results shown. When dealing with fluids, there are few absolutes, and the settings you use will depend very much on the specifics of your own shot. These aren’t step-by-step tutorials but rather a broad look at how specific projects can be approached with the fluid simulator. The .blend files are available on the website that accompanies this book so you can study the details more closely, and I have glossed over some steps that I assume intermediate Blender users can fill in for themselves. The intention of these examples is to get you on the right track to using fluids in your own projects and to explain why certain choices are made so that when you do get down to fiddling with the parameters on your own work, you won’t be fiddling blindly.
The image you saw previously in required considerably high resolution, because of the very literal bottleneck preventing the fluid from flowing freely at lower resolutions. In this case, the minimal resolution enabling me to accomplish the effect was 335, which consumed 3 gigabytes of RAM. At lower resolutions, the voxels were simply too large to recognize the small opening.
The bottle’s mesh is shown in . It’s a simple model, and the material is a standard glass material.
Because I wanted to start the simulation with the bottle full of fluid, I needed Fluid objects that would fit nicely inside the bottle. Of course, it would be possible to model some kind of container Fluid object to fit, but this may be more trouble than it’s worth. Instead, I added a single Icosphere, enabled Fluid Simulation with Fluid for the type, and copied the sphere, resizing and moving the copies around as needed to fill the inside of the bottle. The resulting collection of Fluid objects is shown in . Remember, the fluid volume is calculated as the Boolean union of all these Icospheres. Alternately, in a simple case like this bottle, you could also create the Fluid object by selecting internal faces of the Bottle object, duplicating and separating them into another object, scaling down slightly, and then closing the mesh and recalculating the normals. I prefer the Icospheres approach because it requires no mesh editing at all and enables you to fill even complex spaces easily.
The idea was to have the fluid splash out of the bottle as the bottle tumbled through the air. Obviously, there is a lot of randomness to this process, and controlling it precisely is not possible, so some trial and error is unavoidable. You can see one of my early experiments in .
The fluid movement in this attempt was fairly realistic, but I wanted a more explosive, dynamic splash. To accomplish this, I turned particles on in the fluid settings and I added an invisible obstacle a small distance from the mouth of the bottle, parented to the Bottle object, as shown in .
Because the splash had to take up a lot of space and I did not want the camera to see the splash hitting the walls of the domain, the domain needed to be fairly big in relation to the bottle, as you can see in . This is why the resolution needed to be as high as it was.
Finally, I keyed the movement of the bottle by hand, as shown in . Because I was mainly interested in using the frames as still illustrations, the actual movement of the bottle was not important to me; I wanted to produce only a variety of splash patterns that I could later render as stills. Note that although the bottle’s movement is keyed, the Fluid objects stay in place, because the fluid has not been baked. After all the obstacles have been fully animated, the fluid simulation is run.
The material for the orange soda is shown in . shows the Fluid settings, and shows some of the steps of the fluid as it baked.
After you’ve baked the fluid, you can work on finding the best location for the camera, placing the background, and setting up the lights for the effect you want, as I’ve done in .
To create the image in , I used a method of placing fluid similar to what I used for the bottle of pop, except that in this case both inflows and outflows were also necessary, because the creek is flowing in and out of the frame.
To start, I created the simple creek bed shown in . The object has Fluid Simulation enabled as an Obstacle object, initialized by Shell, because it is a plane with no volume.
For the rocks, I used subsurfaced cubes pulled in various oblong shapes to give them a bit of character (), and I lined the creek bed with copies of the rocks (). The rocks are all Obstacle objects initialized by volume, so it’s easiest to set the Fluid Simulation settings before copying the objects. Otherwise, you will have to create fluid settings on each one later.
The fluid domain is shown in . It covers the minimal area possible to ensure that splashes do not hit the domain wall in view of the camera.
Because I want the creek to flow in a specific direction, I know I will need inflow and outflow objects, but I also want to make sure that the creek starts out full, if only to save time so that I don’t have to wait for it to fill up. I filled the creek in the same way I filled the bottle in the previous example, by using a number of Icospheres with Fluid Simulation enabled and Fluid selected for the type of object. The Fluid objects can be seen in . For visualization purposes, I gave these objects a blue-tinted material. This isn’t necessary for you to do, because the objects themselves will never be rendered. They are used only to give the fluid simulation its initial shape.
I placed four Inflow objects among the Fluid objects. These are shown from below (Ctrl+number pad key 7), in in purple. (The image is repeated in the color insert.) I placed these Inflow objects slightly lower than the Fluid objects, so they are visible only from the underside of the riverbed mesh. Note that in both of these figures, the riverbed itself is seen in Wireframe view mode. The Inflow objects are all angled so that their local x-axes point downstream, as you can see in the direction of the local axis manipulator for the selected sphere in the figure, and their initial velocity is set to be positive in the x-axis. Each one was adjusted after several experimental bakes to keep the flow and level of the creek’s water convincing.
Finally, I placed three Outflow objects in the simulation domain, shown in red from the front view (NUM1) and at a slight angle in . The main one occurs at the end of the creek simulation, just out of view of the camera. Another broad Outflow object was placed above the entire simulation to get rid of stray splashes that could cause unconvincing patterns, such as revealing the presence of the domain wall. Finally, a small Outflow object was placed above the first Inflow object, to control the flow and prevent the water from rising above the banks of the creek. You might also notice the unassuming monkey head off to the left of the simulation setup. This is of course the Particle object associated with Drops and Floats, set to a halo material.
The banks of the creek should be grassy, so I added a grass particle system and weight-painted the banks as shown in , repeated in the color insert. Note that the weight-painting is done with this camera angle in mind. Grass that is farther away from the camera does not need to be as thick as grass that is closer to the camera. Even though the farther bank is less heavily weighted, it still appears denser than the close-up grass.
When the fluid is baked, it progresses as in . The first frame is unnatural looking, because it still retains the shape of the series of spheres that provide the initial volume. Ten frames later, this shape is gone, but the creek has not begun to settle into its flow. About 60 frames into the simulation, the splashing is at its wildest, because the fluid has hit the banks and obstacles and the Inflow objects have begun to produce more fluid to push things downstream. The wild splashing subsides and the simulation settles into a normal flow at about frame 90, after which the motion remains fairly steady, and the simulation begins to most closely resemble the ordinary motion of a small river.
The simulation was baked with Generate Speed Vectors enabled in the Fluid panel (it is enabled by default) and then rendered with Vector pass selected in the Render Layer tab, making it possible to use the vector blur composite node when compositing. Motion blur can greatly enhance the sense of rushing water in this kind of situation, and it especially improves the appearance of the halo particles that follow the water’s flow. The node setup for compositing is shown in .
For more in-depth technical information about the Lattice-Boltzmann method used in the Blender fluid simulator, a technical report by Nils Thuerey and Ulrich Ruede is available online at .
Currently, the implementation of the LBM in Blender is an excellent, straightforward fluid simulator that allows the simulation of fluids of whatever viscosity you like. Still, one of the advantages of the LBM is that it has the potential for considerably expanded functionality. Using LBM-based simulation, it will be possible to extend Blender’s fluid simulator to combine fluids of multiple viscosities and to exploit the underlying particle structure of the fluid simulation to control fluids in a way analogous to the way particles can currently be controlled. This is sure to lead to many exciting developments in Blender fluid simulation. Keep an eye on the Blender release notes to see what improvements future releases bring.
Like everything in Blender, fluid simulations are best used in conjunction with a selection of appropriate tools. Keep in mind how you can use other Blender functionality to enhance your effects. For example, the fluid simulator and the dense meshes it creates are demanding of computer resources. You can get much more mileage out of your hardware if you make good use of Blender’s compositing functionality to break up complex scenes. For the same reason, never use a fluid simulation when a wave-modified plane will do!
Another Blender feature introduced since the first edition of this book is the volumetric smoke simulation, which can also be used to create convincing fire by using the appropriate material and texture settings.
Setting up a smoke simulation is surprisingly simple, even more so than setting up a basic fluid sim. As with the fluid sim, you need a volumetric domain, which can be the default cube. Click Smoke in the Physics properties area and click the Domain button, as shown in .
For a Flow object, you can use a simple plane, as shown in . Size it down and place it near the bottom of the domain. Don’t place it flush against the domain wall, because there needs to be a small amount of space for the simulation to work properly.
Click Smoke and Flow in the Physics properties area. The placement of the plane and the smoke settings is shown in .
Believe it or not, that’s all there is to setting up a basic smoke simulation. Press Alt+A or click the Play button on the timeline to play the animation, and you should see something like the puff of smoke shown in .
Pretty simple, huh? Well, not so fast. Creating the smoke simulation is very simple, but actually rendering smoke is a little trickier. If you click the Render button now, you won’t see any sign of your smoke simulation. You’ll only see the default cube, looking very ordinary. Unlike rendering fluid, where each frame of the fluid simulation is ultimately represented by an ordinary mesh and rendered with standard materials, rendering smoke requires using truly volumetric materials.
To give the domain a volumetric material, set the material type to Volume, as shown in . If you render now, you’ll see something like the cube shown in . I set up a simple textured floor plane (set to receive transparent shadows) and lightened the background sky color. You can see that the volumetric material gives the cube a smoky appearance. However, you still don’t see the actual simulation.
To see the simulation, you need to use a voxel data texture to determine the density of the material.
Smoke simulation is based on a traditional particle system. When you set an object as a Smoke Flow object, a particle system is created automatically. You can manually edit the features of this particle system. Review Chapter 6, “Working with Particles,” for ideas on how to adjust the particle values in interesting ways. In this example, you can leave the defaults, but you should uncheck Emitter on the Render panel so that the flow plane itself is not rendered, as shown in .
The floor material values I’m using are shown in . The final render is shown in .
At this point, the smoke may appear somewhat uniform and blobby. As a final step, you can check Smoke High Resolution and set Divisions to 2 to activate the smoke wavelet functionality. This will create a considerably more computationally expensive simulation, so you should perform most of your previsualization without using the High Resolution option.
Convincing flames can be created by adding flame-colored textures to a smoke simulation and adjusting the light emission values. To create a simple campfire, start once again with a domain cube and a flow plane about the sizes shown in .
This is the point where the fire simulation differs most sharply from ordinary smoke simulation. Rather than a single voxel data texture for smoke, you will use two voxel data textures: one for smoke and one for the flame part of the simulation. The smoke texture will give the simulation its density, and it works similarly to the previous example. The smoke texture values are shown in . Note that the influence is on Density only.
The fire texture values are shown in (repeated in the color insert of the book). Rather than influencing Density, this texture influences Emission and Emission Color. It also influences Reflection negatively. Fire should emit light, it should be fire-colored (obviously), and it should not reflect light that is shown on it, unlike smoke.
To make the fire texture convincingly fire colored, you’ll use a color ramp. In the Color panel, check the Ramp check box. You can add colors to the ramp by clicking Add and move them right and left along the ramp by clicking the vertical lines representing the color. Refer to the color version of in the color insert of the book to see the colors there. From left to right there you’ll see a transparent (alpha zero) bar, an orange bar, a yellow bar, and a pale whitish bar. These colors from right to left will represent the flame from its base to where it fades into the smoke.
The base of fire and smoke simulations, where the particles are first released, is always the least convincing part of the simulation, because the individual particles are visible. It’s always good to conceal this as much as you can. In this example, I conceal this a bit by placing objects intersecting the flow plane in a way that will break up the base of the flame visually. Of course, fires usually are burning something, so adding objects around the base of a flame usually makes sense. In this case, I simply added a cylinder and duplicated and spun it around with an Array modifier object offset with an empty, as shown in .
Smoke simulations respond to force fields. To give the campfire a more interesting smoke pattern, I added a weak vortex force field, as shown in . The positioning and values for the Vortex object are shown in .
A still render of the finished campfire can be seen in (repeated in the color insert of this book). You can find the .blend file among the downloadable files for this book.