This page provides some details on how Phoenix FD works in Maya.

How does Phoenix's fluid simulation work?

This page contains information on how Phoenix simulations work internally. Steps for setting up a simulation can be found on the Getting Started with Phoenix FD page.

Phoenix's fluid simulation calculates how a fluid (fire, smoke, or liquid) would evolve during a period of time. It runs in sequential steps, and in each step the fluid is calculated a little further in time ahead of the previous step. This way each new step depends on the previous step, and a new step cannot start before the last one has already finished. This is one of the biggest differences between distributed rendering and distributed simulations - e.g. if you want to simulate 100 frames, you can not run frames 1-50 on one machine and frames 51-100 on another machine simultaneously.

The result of each simulation step is a velocity field - i.e. the fluid simulation calculates the speed and direction of the movement of the fluid in different points in space. The two most important processes in a simulation are Advection - how the fluid moves through space, and pressure solve, called Conservation in Phoenix - which is basically the step that makes simulated fluids behave like real-world fluids - swirling, rolling and creating plumes. Both of these options are controlled from the Dynamics rollout of the Phoenix Simulators.

In order to see the effect of the fluid simulation, the velocity field can carry other data channels with it when it moves - e.g. Temperature, Smoke, Liquid, etc., which can be enabled from the Output rollout.

Each simulation step roughly does the following:

• Reads the scene nodes which interact with the simulator - obstacle geometries, emitters of fluid which can be either geometries or particles, forces, etc.
• Adjusts the simulation velocity during the Conservation phase.
• Moves the fluid along the velocity field during the Advection phase.

In a 3D software, the simulation runs from a certain start frame to an end frame on the timeline. Each frame, one or more simulation steps can be calculated. This is controlled by the Steps Per Frame (SPF) parameter under the Dynamics rollout. In case there are fast moving geometries in the scene, or the fluid itself has to move fast, it's good to use more Steps Per Frame, so the scene could be read more often, or the Advection can work in shorter intervals, otherwise the movement will break up and will not be smooth. However, using more steps will require more time for the simulation to calculate, e.g. using twice more steps will take twice more time to simulate.

There is also another downside to using more steps - each time the fluid is moved during the Advection phase, it gets blurred, which is a part of the algorithm unfortunately. This means that the more steps pass, the more detail would be lost and the Temperature or Smoke channels will lose their fine details over time. So if a simulation running with 1 Step Per Frame gets significantly smoothed and blurred after 1000 frames, the same simulation would lose that much detail only after 50 frames if 20 Steps Per Frame are used. And not only the material channels lose their detail the more steps pass - the velocity field loses detail as well, so if a smoke plume rolls energetically into a mushroom at the beginning of the simulation, it would gradually lose its momentum and lose its shape later. This is why it's always best to use as few Steps Per Frame as possible and increase them only when needed. Note also that the Time Scale parameter has the same effect - running the simulation with Time Scale of 0.1 for 50 frames will produce lose a much detail as it would take 500 frames with Time Scale of 1.0. This is why Phoenix offers several different methods for retiming a simulation after it has run once at regular speed.

Because simulation is a relatively slow process, at the end of each frame Phoenix saves the fluid data up to this moment to a new cache file. Cache files are numbered with their frame numbers by default, which can be controlled by the Output rollout. Note that if you have many steps per frame, a cache file would be saved only once per each frame - e.g. if you have 5 Steps Per Frame, the simulation will run 5 steps and just then a new cache file would be saved. Cache files make it possible to quickly scroll through the timeline and preview the simulated cache sequence, and also to render it without the need to simulate each time you need to go to a specific frame. Starting a new simulation would overwrite the existing cache files. Additionally, cache files can be used later by Phoenix to run a Re-simulation which would add more detail or re-time an already simulated cache sequence.

While the simulation runs, it's in the background, and the user interface of 3ds Max remains active. You can change many simulation parameters (except for a few initial core parameters) during the simulation and see how they affect it. Rendering is also enabled and you don't have to wait until the end of the simulation to render images and see how the simulation looks and fits into the scene.

Simulation Terminology

Simulations use the laws of physics as well as some of its terminology. While you might be familiar with the term fluid as meaning "liquid", in physics the term fluid refers to both liquids and gases. When this documentation refers to a fluid, it means the liquid or gas effect being created.

The simulation grid is divided into cells (voxels) that contain the fluid's properties at their coordinates. Examples of commonly used properties are Temperature and Velocity. Each cell has an individual channel for each property that holds the value of the property for that cell. When you start a simulation, the channel values from one sub-frame to the next are calculated and cached for later playback. The values will change over the course of the simulation, which is what makes the fire, smoke, or liquid appear to move and change from one frame to the next. Channel values can be set in a number of ways, ranging from texture maps to responses to forces like gravity or wind.

Resimulation is the process of simulating over an existing simulation, which is called a base simulation. Resimulation is sometimes desirable to add additional effects to a simulation created previously.

Particle vs. Grid-Based Simulation

There are two main approaches used in simulation systems:

In a particle simulation, particles move through space and each particle carries properties of the fluid - mass, color, temperature. Particles interact with each other - attract and push each other apart, or exchange properties such as color and viscosity. Phoenix uses particles for simulations of liquid effects such as foam, splash or mist. The more particles there are in a simulation, and the more they need to interact with each other, the slower the simulation runs.

In a grid simulation, the fluid moves through voxels (cells), which are static pieces of space ordered in a grid. The grid is like a 2D image made of pixels, but in 3D space these have volume and are called voxels. Fluid flows in and out of voxels, so with time a voxel's properties such as temperature, density or color can change. Phoenix uses grid simulations for gaseous effects such as fire and smoke. Grid-based effects are contained within a rectangular grid, while particle-based effects have no such space constraint. Particles tend to look and act like individual droplets (or, in the case of a close collection of particles, a glob of droplets), while grid-based effects can be very nebulous and atmospheric in appearance and can gradually fade and thin out. A major downside of grid simulations, however, is that while particles keep their properties throughout the simulation, a grid simulation could gradually fill up with smoke or liquid or alternatively - could have matter disappear from it with time. This can be avoided by using more Steps Per Frame or higher Conservation Quality, but is still a major issue if trying to simulate liquids with a grid solver. Note that the higher you set these options or the more voxels there are in a grid simulation, the slower it runs.

A third hybrid method between particle and grid simulations are the FLIP simulations, which Phoenix uses for liquids. FLIP simulations take the best from both worlds and produce much better liquid effects. FLIP liquid simulations were first added in Phoenix 3.0. Before that, liquid were simulated using the grid solver. In Phoenix 3, you can still import and simulate older scenes saved from Phoenix 2 using the old grid liquid solver. Note that Phoenix uses pure particle simulation for the secondary particle systems such as Foam, Splash, WetMap and Mist as these are simpler and don't suffer from issues that liquids in pure particle or grid simulations have, such as having to maintain volume and not collapse on themselves if put in a large container.

Since particles and voxels are quite different, they can be rendered using many different methods as well. Phoenix can render voxels as volumetrics, such as clouds or explosions. Note that FLIP simulations produce both particles and voxels, so you can render liquids as smoke as well. Particles can be rendered using a Phoenix Particle Shader, which can draw them as points, bubbles, or could also voxelize particles into a grid and render that as fog using the volumetric shader - this is how you can render mist from a waterfall, for example. Voxel grids can also be meshed so that you can get a surface and apply standard render materials over it. For this, Phoenix offers several render modes in the Simulator's Rendering rollout - Mesh, Isosurface, Cap Mesh and Ocean Mesh. While the mesh modes produce a standard mesh in the viewport that you can export or modify, its surface is made up of polygons which may appear too jagged at times, so switching to Isosurface mode would allow you to render very smooth surfaces which are calculated at render time.

Types of Simulations

Simulations performed by Phoenix FD can be roughly divided into two major categories:

These categories are for convenience only, and are not rigid. Once you've created a few basic simulations and have become more familiar with Phoenix FD, you will have a better grasp of how the tools work, and when creating an effect that is not strictly fire or liquid you'll know how to represent it most efficiently. For example, sparks or thin smoke might seem to fall into the "fire" category, but in practice these effects might be better served by particles and thus should use some of the tools designed for liquids.

How the Simulator Works

Each simulation requires a simulator node to be present. This non-rendering, box-shaped scene element positions the grid in the scene, and the simulation takes place inside it. This object's parameters hold all the information about the simulation such as content, shading, and physical position in addition to parameters needed to run the simulation such as the start frame and steps per frame.

See the Simulator | PhoenixFDSimulator page for information on how to set up a simulator manually, and for links to rollouts with all the parameters. You can also use the Quick Simulation Setup buttons to automatically create a simulator for your scene.

Channel Setup

When you set up a simulation, you indicate which channels are to be used by the cells in the grid on the Output rollout. 

These channels are selected automatically for the appropriate type of simulation when you use the Quick Simulation Setup buttons.

One or more additional channels can also be added to the simulation as needed:

An additional benefit of using channels is that you can perform a resimulation with all the channel data from the previously created simulation. 

Activity During Simulation

At each step, Phoenix FD recalculates the grid content by repeating three main (core) actions:

Depending on the core settings, one or more additional operations can be included in the process. These operations are:

Burning

The burning process requires Fuel and Smoke as additional channels (they will be included automatically). As in the real world, the burning process converts the fuel into smoke and produces some heat which expands the fluid. There is no separate channel for oxygen, however it is taken into consideration using the smoke and the fuel to be calculated. The relation is oxygen=1-fuel-smoke. The energy of the fuel controls how much heat will be produced and the inflation/expansion rate controls how fast the ignition will propagate.  
For convenience the second parameter is just called Propagation, but advanced users should keep in mind that the real meaning of the parameter is inflation/expansion rate.

Cooling

The cooling reduces the temperature due to the IR emission. It should not be confused with the cooling caused by convection. Cooling is a very complicated process, similar to calculating Global illumination in rendering. As a result, a simplified cooling formula is used.

Vorticity Confinement

The vorticity confinement keeps the small turbulences alive. Why do we need this kind of correction? The fluid transport (advection) moves the grid content from cell to cell according to the velocity. In a traditional case, the movement of any given point is not an integer count of cells. This causes the content of the cell to be mixed with the content of the neighboring cells during the advection. As a result, the fine details in the velocity tend to disappear. Amplify them to make the fluid more turbulent.

Interaction with External Objects

By default, the grid and particles in a simulation interact with scene objects. For example, in a liquid simulation, the liquid will bounce off or flow around any geometry it encounters.

There are three types of external objects that can interact directly with the simulator:

In every simulation step, all the nodes in the scene are enumerated and processed whether or not they belong to one of the above mentioned groups and have permission to interact with the simulator.

Rigid Bodies

All geometry objects in the scene are considered to be rigid bodies. They can affect the simulation in three different ways:

Another Phoenix simulator can also be used as Rigid body. In this case, the Surface Channel is used to determine the surface.

Particles

The particles can interact directly with the simulation only as sources, depending on the Emit Mode (Inject or Brush) of the Fire Source | PhoenixFDSource. The velocity of the injected fluid is the velocity of the particle, which allows the fluid to be involved in the particles' motion.

Fields

Forces create a region or "field" around them which can change the velocity of the fluid in two different ways:

Adding Fine Details

There are two direct methods that can be used to add fine details in the shading. In order to enhance the realism of the movement of small details in the fluid, V-Ray comes with a Particle Texture called Particle Texture | PhoenixFDParticleTexture. When used in combination with a particle system driven by a Phoenix Simulator, the particle texture is capable of properly animating the small details along the fluid surface.

The two methods are:

Surface Driven vs. Volumetric Displacement

Displacement in Phoenix FD works by shifting the point of sampling with an offset, the direction of which is determined by the gradient of the effects channel while the distance is determined by the brightness of a given map. There are two different modes used to sample the aforementioned map, switched by a checkbox in the rendering rollout. If the checkbox is NOT checked, the map is sampled at the point of shading, and we call this "volumetric displacement". If the checkbox is checked, the coordinates are first projected over the surface as determined by the effects channel. The point of projection is then used as map coordinates. We call this "surface driven displacement." Surface driven displacement is slower and requires some initial calculations, but it keeps the topology of the iso-surfaces. Volumetric displacement is faster, but tends to produce island-like formations if the displacement value is too big. Beside performance, volumetric displacement has one more important advantage: it does not require the distinct surface of the effects channel. Therefore, it will work fine in scenes where surface-driven displacement produces flickering.

Example: Surface Driven vs Volumetric Displacement

Smoke Reality vs. Apparency

There is a well-defined connection between the transparency and the emissive light in the real world. As an example, for smoke (diffuse light), the connection is pretty clear and everyone has intuitive sense of how it works. For the emissive light, however, most of the people will give the wrong answer when asked, "Is a smokeless fire fully transparent?" The common, yet wrong, answer is, "Yes it is. If there is no smoke, the flame is fully transparent and will cast no shadows." However, the correct answer is "No, the fully transparent gases cannot emit any light, even if they are hot enough." This is why acetylene flame is less bright than a candle, despite its higher temperature. It just produces less smoke. However, this way of shading can seem strange and inconvenient, because there is no clearly separated control over the smoke and flame. Be careful when trying to achieve denser smoke, because the result can be an undesired brighter flame.

For this reason, Phoenix FD provides different modes of shading: physical and detached. This is controlled by the Fire Opacity Mode parameter in the Fire rollout. In Fully Visible mode, the emissive part is fully independent of the transparency and you are not obligated to keep in mind the aforementioned connection. In Use Smoke Opacity mode, the smoke's alpha controls the Fire's opacity. There is also the Use Own Opacity mode where the fire has a separate opacity curve that can be adjusted independently from that of the smoke.

Foam and Splashes

The PhoenixFD solution for creating foam and splashes is particle based and is achieved by two relatively separate features - a foam/splashes particle simulator and a foam/splashes particle shader. The particle simulator is embedded in the PhoenixFD Simulator node and exports its content via PhoenixFDPGroup nodes, supporting position, velocity, size and id channels. The particle shader is designed as a separate component: PhoenixFDFoam. This component can render PhoenixFDPGroup and any standard particle system that exports position, size and velocity channels.

Rendering of Foam and Splashes

The Particle Shader | PhoenixFDFoam node can render the particle systems in several different ways - as separate bubbles/droplets, as points, as mist, or as fog. In fog mode, the bounding box of all particles is calculated and a grid based shader is constructed using the bounding box and the fog resolution parameter. This mode is most suitable for surface foams, when the grid height is relatively large and the particle count is huge. The other mode (particle-based shading) is more complicated and interesting; it allows us to achieve a larger variety of effects. One reasonable question about this mode is why we need it, when one can render each particle as geometry with the proper material instead. There are several advantages, but the most important one is the ability to convert the scattering into diffuse color, which gives the natural bright appearance of the foam and the splashes. Another important advantage is cellular mode, which allows shading of close-up foam.

There are three different modes of shading for spherical particles - bubbles, cellular, and splashes. In each mode, a particle is represented as a sphere with a radius equal to its size and with certain optical properties. The "bubble" and "cellular" modes are intended for foam rendering and have the same optical properties of the surface. They differ in the geometry representation only - bubble mode uses simple spheres, whereas cellular mode builds polyhedron-like cells, similar to real foam. The cell walls are not flat, but slightly curved, which provides a more realistic appearance.

Example: Rendering of Foam and Splashes

Resimulation

In order to perform resimulation, the base simulation must be processed first, and its Velocity channel must be exported. Then, to enable the resimulation, the Enable option in the Resimulation rollout must be checked. While this option is enabled, the simulator works in resimulation mode (i.e. all simulator functionality is now related to the resimulation).

The resimulation can affect the grid content and the particles separately. If only the grid is resimulated, the particles will be directly copied from the base simulation. If only the particles are resimulated, the grid content will be directly copied from the base simulation. Both grid content and the particles can be resimulated at the same time.

The resimulation process uses the velocity force of the base simulation to achieve the same flow of the fluid. This force can be resized if the user wants to increase the resolution when resimulating. There are two methods to resize the velocity force: interpolation and wavelet turbulence. The second method tries to add high frequency detail that is lost with simple interpolation, but it requires that the base simulation exports a special "Wavelet" channel and "Wavelet UVW" channel in addition to the regularly exported channels.

Since the resimulation can do sub-steps, it must do conservation of the velocity force on its own. However since this conservation is valid only inside a single frame, the global flow will not be affected, and lower conservation values can be used, which can greatly increase the overall simulation speed.

When resimulating, almost all simulator parameters can be changed (for example the SPF limits, advection step, time scale). However this can produce a flow of the fluid that is different from the original.

The restore function works with resimulation cache, even if the Velocity channel is not exported. However the base cache must be preserved.

Here are examples of what can be achieved with resimulation.

Exported Files

The result of the simulation is a sequence of files called cache files. Each cache file has two sections, one each for grid and particle information. PhoenixFD uses its own file format that allows it to keep both grid and particles in single cache and also additional values used to restore simulations starting from certain frames.

The grid can be likened to a multi-channel 3D bitmap, but instead of colors it contains physical values called channels (temperature, smoke density, velocity, etc.). There is only one grid in given file, but it can contain more than one channel.

The cache file can contain multiple particle systems, for example foam particles and splash particles, each of them with its own channel set. The particles are represented in the scene by hidden objects named in a specific manner. For example, the object representing the liquid particles of the simulator PhoenixFDLiquid01 is called PG [Liquid] of system [PhoenixFDLiquid01]. These objects obey the Maya standards for particle systems, allowing their content to be accessed by 3rd party software.

Channels, Diagrams and Gradients

After the simulation, cache files containing the exported physical channels are produced. In the real world, the connection between the physical quantities and the visual appearance is well-defined. However, for more flexibility in Phoenix FD, the user is allowed to choose how the render elements depend on the physics. For example, in the real world, the temperature determines the emissive color; however, in Phoenix FD, the velocity can be set to determine the emissive color instead of the temperature. The physical channel used to determine any given render element is called a source, and the dependence between the physical quantity and the render element is determined by tables called palettes. For the rendering of the volumetric content, three render elements are calculated for each point: emissive color, diffuse color, and opacity (alpha). To calculate each of them, the shader performs the following steps:

The control over the above mentioned process is arranged in Fire, Smoke Color, and Smoke Opacity rollouts where the user can choose the source and the palette for each channel. For the emissive color, both a diagram and a gradient are used, because–as opposed to the diffuse color–it can be outside the range 0-1. When this happens, the gradient will appear saturated. For each render element, the user is also allowed to select a texture map as the source channel. In this case, the palette is skipped and the sampled color is used directly.

Particle Export

There are several particle types that the PhoenixFD Simulator exports:

The particles are exported in separate PhoenixFDPGroup nodes. The first two types have one particle group per type, while the third type is exported in per-source groups. The difference between those groups is in the particle birth and simulation methods that they use.

The birth of particles can be performed automatically (for foam and splashes) by a user source (see Fire Source | PhoenixFDSource) or by a script. When automatic birth is used, the simulator calculates a "birth potential" for each cell and compares this potential with the birth threshold set by the user. If the potential is above the threshold, the simulator creates new particles in the quantity specified in the "birth rate" parameter, in thousands per cubic scene unit. Both foam and splashes are born in this way; the only difference is how the "birth potential" is calculated. Additionally, when a splash particle hits the water surface, foam is automatically created.

The simulation of the particles is very different for each type. The simplest one is the "drag". This type of particle simulation generates particles that are just dragged with the fluid. The second type (by complexity) is the splashes type. The splashes are just left in free fall until they hit some object or the water surface. The free fall is not the simplest one, it is affected by the movement of the air (do not forget that Phoenix simulates the air too, not just the liquid!) and the air-splashes interaction is controlled by the air friction parameter. The most complicated type is foam. The foam particles interact not only with the fluid, but with each other as well. This interaction produces a repulsive force when the particles are too close, and an attractive force when they are not, ensuring the foam's consolidation. This process is the most expensive one and is controlled by the B2B interaction parameter. When only surface foam is needed, the aforementioned process can be switched off by setting the parameter to zero.

Notes