Avoiding grid artifacts on the source surface

Distributed rendering

Rendering with an external volumetric shader

Max. transp. levels of V-Ray and pure geometry mode

Complex rendering and "Circular reference" message

Simulation in 2D

Noise/slice like artifacts

Fluid simulations in hollow objects

Simulation and rendering of fine smoke without using a huge grid resolution

Init part of the grid with liquid or other content

Nightly simulation and rendering

Moving geometry vs moving simulator

 

Avoiding grid artifacts on the geometry surface

In many cases the grid cells are visible on the geometry surface, especially when it's not parallel to one of the main planes. The reason for this behavior is the fact that the geometry in the grid is represented by freezing the overlapped cells. These cells may become visible if there is a big difference between their properties and the environment. For example the frozen cells are dry, but the environment is water. How this can be avoided? One possible way is to use Inscribed voxel mode that just hides them inside the geometry. However in cases of transparent geometry this does not help, the artifacts remain visible. Very helpful in case of liquids is the Gizmo option of the rendering, combined with the Inscribed mode. It clearly cuts off the artifacts.

 

 

Water-glass artifacts
A Gizmo is used to clear the artifacts

 

 

Distributed rendering

One of the most desired features is distributed rendering. A very common problem in the DR setup is that by default Phoenix FD looks for the cache files in the same directory where the scene file is. However, cache files are not automatically sent to the host machines like the scene is, and when the render begins the hosts are looking for the cache files in the same directory where the scene file is. One may ask why the cache files are not sent? The reason is that in many cases not all the cache files are used in the rendering. It is also hard to predict the exact cache files that will be used. Besides, they may be really huge and may overload the disk space of the hosts. The solution is to set a network visible input path, instead of copying the caches. Push the browse button to select input path and type \\your_computer_name in the text field of the dialog. This will open a browsing window and you just have to find the caches and select one of them.

 

 

Rendering with an external volumetric shader

Phoenix FD is able to export its content as texture (see Phoenix texmap) and this makes it possible to use an external volumetric shader for the rendering, for example the V-Ray environment fog.

Simple setup for V-Ray environment fog:

Max. transp. levels of V-Ray and pure geometry mode

Rendering in pure geometry mode causes high transparency level and you have to increase the Max. transp levels of V-Ray to a bigger value, given by the following formula:

max transp level=grid size*100/step.

 

The image to the right illustrates an issue that occurs when 3ds Max transp. levels is not high enough.

 

 

 

 

 

 

 

 

 

 

 

 

Complex rendering and "Circular reference" message

In many cases when the rendering setup is complicated, the user will get an unexpected message stating "Can't make a circular reference". This message appears when the object depends on itself, mostly when a channel is exported as texture and that texture is used for shading. To avoid this message usually a second Phoenix FD object is introduced. Its input path is redirected to the first one, and the whole render setup is made with it. The first Phoenix FD object should be disabled for rendering (it is used only for the simulation).

 

An example of a circular reference
Render set-up to avoid the circular reference

 

Simulation in 2D

Phoenix FD has the ability to perform a 2D simulation, if one of the grid sizes is set to 1. To keep features like the embedded gravity and pressure decay, it is recommended to keep the Z direction active.

Noise/slice like artifacts

Despite the difference in the appearance both artifacts are caused from the same thing - too big value of the advancing step compared to the opacity gradient. Depending on the situation there are two ways to solve the problem: decrease the advancing step or decrease the transparency gradient. The first solution will increase the rendering time, the second one will decrease the sharpness of the resulting image.

 

Noise
Slices
Low gradient
Low advancing step

 

Fluid simulations in hollow objects

When simulating fluids in hollow objects one must make sure that the normals of the geometry are pointing inwards.

 

 

 

Init part of the grid with liquid or other content

Since Phoenix FD 2.1 there is an automatic initial fill up of the grid. In many cases, however, you may need non rectangular area to be filled or in general to convert any geometry into liquid.

 

Using brush mode source

  1. Create a geometry covering the volume that should be filled with the liquid.

  2. Exclude this geometry from the interaction, by adding it in the simulator's exclude list, or simply by hiding it.

  3. Create a liquid source, and select Brush for the If not solid option.

  4. Animate the discharge from 100 to 0 for the first two frames.

  5. Disable the velocity checkbox of the liquid source helper.

 

 

 

Nightly simulation and rendering

Most simulations require lots of time to calculate and it's very convenient to let them run during the night. However, you still have to render the result at the morning and this also consumes a lot of time. Phoenix FD scripting system allows you to execute any action on the end of the simulation, and that includes the rendering as well. You just have to enable the scripting (simulation panel) and open the script text. There is a function "OnSimulationEnd", find it and remove the "--" symbols in front of the line (this means uncommenting it) and type "max quick render". This action is equivalent to pushing the quick render button. Remember not to delete the output sequence, otherwise a prompting dialog will appear and the rendering won't start automatically.

 

Moving geometry vs moving simulator

There is certain group of simulations that are hard to handle because of the presence of moving objects in them, for example a fire ball or bottle with liquid. The most common complain of the users in such cases is "i have to make a moving bottle, but the liquid penetrates through the geometry". The first solution that the users try in this situation is to make the walls thicker, but in the most cases it does not help. The problem occurs because from the simulator's point of view the bottle just disappears and appears again few cells forward, but the liquid remains at the old position, that is already not in the bottle.

Phoenix FD has very elegant solutions for such cases- the inertial forces option. Just bind the simulator to the moving object and the the needed forces will be produced to ensure the realistic fluid response.