Page History
This page provides information on how to get the most out of Chaos Phoenix FD for Maya.
Overview
...
This page provides tips on a variety of topics to help you get the most out of Phoenix FD.
Changing Paths
...
| Anchor | ||||
|---|---|---|---|---|
|
Changing the Default
...
Phoenix Paths
...
Phoenix FD saves each simulated frame in a cache file with an *.aur extension, numbered using the frame index. By default, the cache files are stored under the data folder of the Maya project folder. They are put in a folder with the same name as the scene and with "_Phoenix_frames" appended:
...
You can manually change the output path from the Output rollout. The default paths and file names above are generated using the $(scene_path) macro as an output path, and there are other macros you can use as well, or just manually enter the path you need.
After Phoenix FD has Phoenix has created the *.aur frame cache files, you can preview them in the viewport and render them using V-Ray or the default renderer. By default, Phoenix FD looks Phoenix looks for render/preview input files in the $(same_as_output) path, which is the path in the Output Rollout. So even if you change the output manually, the render will keep reading from the new location. You may also manually change the render input path to a series of cache files that you have stored somewhere else previously, or to the cache files of a different simulator in the same scene. It is possible to change the path to a series of *.f3d or *.vdb files exported from other simulation software as well. Here is the basic flow:
...
| Anchor | ||||
|---|---|---|---|---|
|
Changing the Default
...
Phoenix Paths for Resimulation
...
Resimulation takes as input a sequence of *.aur, *.f3d, or *.vdb cache files, and processes them in order to improve the grid detail, change the time-scale of the animation, or run a particle simulation again without changing the grid content.
During resimulation, Phoenix FD reads Phoenix reads cache files in the Input Resimulation Path, performs some of the above operations, and then saves a new cache sequence in the Output Resimulation path.
When resimulation is enabled, the preview and rendering will read from the Output Resimulation Path instead of the Input Path.
By default, Phoenix FD reads Phoenix reads the files in the $(same_as_output) path, which are already simulated by the regular simulation process, and then saves new *.aur caches in the $(scene_path) path with "_resim" appended at the end of the file name.
Otherwise, if you enter your paths manually, please make sure that the Input Resimulation Path resolves to an existing cache sequence with an exported Velocity channel. (You can check the channels present in a cache file form the Simulation rollout ). Also, beware that if the Output Resimulation Path coincides with the Input Resimulation Path, Phoenix FD will Phoenix will not prevent you from overwriting your existing cache files - it's valid to do so if you need a more complicated setup.
...
Maya Batch rendering copies the scene elsewhere on the hard drive. By default, Phoenix FD uses Phoenix uses paths to the cache files such as $(same_as_output) or $(scene_path), which search for the cache files next to the Maya scene file. When Maya batch copies the scene, it won't copy the cache files with it, and the scene will not be able to load its cache files, so your fluid will not be rendered. To fix this, please change the Input path to an absolute path such as "D:/caches/frame_####.aur" so that the scene file would always be able to find its cache files no matter where the scene is copied. If you are using Resimulation, make sure to update the resimulation paths as well.
...
Units to Use When Simulating
...
The Phoenix FD Simulator Phoenix Simulator works best when the scale of the container matches the real-world size of the simulated effect. You can check the dimensions of the container in the Grid rollout, and also you can check the dimensions of an already simulated cache in the Simulation rollout. If you are simulating a camp fire, your container should be at most a couple of meters wide. Note that it doesn't matter if this is two meters or two thousand millimeters - the way you view the units is irrelevant. Phoenix FD always Phoenix always converts internally the units to a common world-size length, so the only important thing is how big the container is according to the Grid or Simulation rollouts. If you are simulating a volcano for example, the container should be several hundred meters wide, or several hundred thousand millimeters.
...
Setting Up a Network Simulation
...
Phoenix FD simulates Phoenix simulates linearly, frame after frame so the calculation of each frame depends on the previous one. That is why the simulation licenses for Phoenix FD cannot be used to distribute (and speed up) a simulation over the network. Instead, several simulations with varying parameters can be simulated, each on a separate computer. This process can be done using a render manager such as Backburner or Deadline, and it does not require a GUI license for Phoenix FD. However, this can be done with scripting only – currently there is no user friendly GUI for this.
...
Initializing Part of the Grid with Liquid, Smoke or Other Content
...
Since Phoenix FD 3Phoenix 3.0 there is a per object option to start the simulation with the object's volume filled with liquid.
...
Create a PhoenixFDSource, and select Volume Brush for Emit Mode. Select the channels that must be filled.
Create a geometry covering the volume that should be filled with the desired channel, and add it to the Source Objects set in the PhoenixFDSource PhoenixSource rollout.
Animate the Brush Effect parameter from 100 in the first frame to 0 in the second frame.
Disable the Velocity checkbox of the PhoenixFDSource PhoenixSource, or the fluid may refuse to leave the volume of the emitter.
...
Some simulations are hard to handle because of moving objects in them (e.g. a fire ball or bottle with liquid). The first, but not the only problem that appears is the need to cover the entire route of the moving object with the simulator object, and this requires really huge amount of cells to get the needed resolution. Even for a novice it's apparent that such simulation is not efficient. The simulation is concentrated in a very small area which is moving in the huge empty grid. But this is not all. In the case of moving a bottle with liquid, you may have a short route that is easy to cover, but you still may have problems because the bottle changes its representation in the grid and each frame it must push the particles inside.
Phoenix FD has Phoenix has a very elegant solutions for such cases - the Inertial forces option within the Dynamics rollout. It binds the simulator to the moving object, and the needed forces will be produced to ensure the realistic fluid response.
...
There are many situations when the simulation area is narrow and its volume is not very large by itself, but for some reason, its bounding box is big and requires a huge grid to cover it. A perfect example for such a situation is a waterfall - the upper area can be covered by a box, which is wide, but not very tall; the vertical area can be covered by a tall and not very wide box; but together they have to be covered by a box that is both wide and tall, so a large grid has to be simulated for only a small significant volume.
For liquids, Phoenix FD provides Phoenix provides very easy way to do this. You have to simulate first the source simulator, and afterwards start the recipient simulator. The recipient simulator must link to the source simulator through the Cascade Simulator parameter in the Grid rollout of the Simulator.
For smoke/fire, the ability to put a Phoenix FD Simulator Phoenix Simulator as a source for another one is used. When a Phoenix FD object is used as a source, the implicit surface is determined by the Surface channel in the Rendering rollout, the Isosurface Level defines the geometry surface, and the newly born fluid will appear over it. You have to set the isosurface level to a very small value, thus making the source surface a box. To avoid the additional speed added by the discharge parameter, in the Fire Source rollout, use either the Volume Brush for the Emit Mode with Brush Effect set to 100%, or use Volume Inject mode with a very low Outgoing Velocity (e.g. 0.001). Do not make it zero, because the system will decide that this is not a source and will skip it. To transfer the parameters of the gas from the first simulator to the second one, import the used channels of the first simulator into the map slots of the source helper using a Grid Texture | PhoenixFDTexture. Since the simulation will usually run multiple times, add the second simulator in the exclude list of the source simulator to avoid backward interference.
...
| Anchor | ||||
|---|---|---|---|---|
|
...
If there are multiple Phoenix FD Simulators Phoenix Simulators in your scene and you'd like them to run one after the other without any user input, Phoenix FD provides Phoenix provides you with the option to connect them in a sequence. The Sequencing options are found on the Phoenix FD Shelf → Play button ( right mouse button click ) → Sequence multiple simulators to start in order. When two simulators, A and B, are part of a sequence, A is calculated and its contents for the entire Start/Stop Frame range are cached to disk. Then, the calculation for simulator B is automatically started. Such setup could be useful when multiple simulators interacting with each-other are present in your scene.
...
Phoenix FD has many tools for changing the animation timing of a cache sequence after it is simulated. The Input rollout has a variety of animation controls in the Time Bend section where you can change the speed of the animation, loop, or directly animate the cache index for each timeline frame. When using these controls, Phoenix FD often Phoenix often needs to internally blend between two cache files to produce a given frame on the timeline. The Time Bend Controls blend cache files on the go, at the moment when a new frame is loaded on the timeline - either while you're previewing the simulation in the viewport, or when rendering. For fire/smoke simulations, if you don't want this slowdown, you can bake a new sequence of re-timed caches using Time Bend Resimulation, as described below.
...
These are the Backup Frames Phoenix FD uses Phoenix uses when you press Restore on the Simulation rollout. In order to restore a stopped simulation, the simulator needs all the simulation data, so these cache files contain all the internal simulator data - velocities, particle IDs, etc. and thus they are larger. You can control how often such frames are written to cache from the Output rollout's Backup Interval option. By default the Backup Interval is set to 15 frames, and if you don't intend to Restore the simulation later, you can turn this off by setting it to 0, so you can save some hard drive space.
...
A common problem when setting up DR is that by default Phoenix FD looks Phoenix looks for the cache files in the same directory as the scene file using the $(work_path) keyword. However, at the start of a network render, the scene file is copied to all render machines on the network to a new location, e.g. C:\Users\[user]\AppData\Local\backburner\Jobs\, while cache files are not automatically sent to the host machine. The cache files are not sent because on one hand they may be really huge and may overload the disk space of the host, and also because in many cases not all of them are actually used in the rendering. This is why when the rendering begins, if the hosts are looking for the cache files in the same directory where the scene file is, the cache files won't be found.
...
If you are not using a UNC path, and instead your path points to a drive on your local computer, or is one of the Phoenix FD keywords Phoenix keywords ($(work_path), $(scene_path), $(scene_dir), etc...), you will receive a message that states "You are using local machine Input path with distributed rendering!".
...
A single Particle Shader, by default, shades all selected particle systems using the same color.
In Phoenix FD 3Phoenix 3.10, we added a Color Map slot you can use to color the particles differently, but it can do so much as a texture allows it to - e.g. a checker won't be too much of a interesting shading, and furthermore, it won't change with time, and even if you animate it, it still won't fit the particle movement. However, you can plug a Phoenix FD Phoenix Grid Texture in the Color Map slot - this way the particles from a Phoenix FD simulation Phoenix simulation can read voxel data from the grid channels, such as Speed or RGB.
In Phoenix FD 3Phoenix 3.11, we extended the Phoenix FD Phoenix Particle Texture so particles can be shaded using their own channels. Before, what the Particle Texture could do was to take the particle positions and create white areas around each particle in 3D space on a black background. Since Phoenix FD 3Phoenix 3.11, the Particle Texture can color the areas around each particle using a color from a particle channel - e.g. the Age, Position, Speed, or even just the particle RGB. This way you can plug the Particle Texture into the Particle Shader's Color Map slot and shade the particles that way.
...
Rendering with an External Volumetric Shader
...
Phoenix FD is Phoenix is able to export its content as a texture (see Grid Texture | PhoenixFDTexture). This makes it possible to use an external volumetric shader for the rendering, such as the VRayEnvironmentFog.
...
| Fancy Bullets | ||
|---|---|---|
| ||
|
...
Most simulations require long time to calculate and it's very convenient to let them run during the night. However, you still have to render the result in the morning and this also consumes a lot of time. The Phoenix FD scripting Phoenix scripting system allows you to execute any action at the end of the simulation, and that includes the rendering as well. You just have to enable the scripting from the Simulation rollout and open the script text.
...
| Code Block | ||
|---|---|---|
| ||
import maya.cmds as cmds
def OnNewFrame(node, t, dt):
cmds.vrend() |
Rendering
...
Phoenix together with VRayAerialPerspective, VRayEnvironmentFog, VRaySphereFade or VRayVolumeGrid on V-Ray CPU
...
If you have volumetric effects in your scene such as an Environment Fog, an Aerial Perspective, V-Ray Sphere Fade or a Volume Grid, V-Ray CPU won't be able to properly determine their positions along the camera rays. Consequently, these effects will render as if they were placed one after the other in the camera frustum.
To resolve this problem, you could switch the volumetric rendering mode to Volumetric Geometry for Fire / Smoke, and respectively for particles you could enable Render as Geometry in the Phoenix FD Particle Phoenix Particle Shader. This will allow V-Ray CPU to properly blend your Phoenix FD simulation with the rest of the volumetric effects in your scene. Note that in these modes you might have to increase the V-Ray Max Transparency Levels option under the Materials rollout of V-Ray's Overrides tab.
...
Importing and Rendering Simulations from FumeFX and Houdini
...
Phoenix FD can import Field3D (*.f3d) and OpenVDB (*.vdb) cache files that other fluid simulators have simulated and exported. This way you can render them with Phoenix FD's shader and make use of Phoenix FD's special features.
| Note |
|---|
Field3D files which come from FumeFX must be exported with gzip compression. If they are exported with the default proprietary FumeFX compression, they will not be imported properly in Phoenix FD. |
Note that you may import not only atmospheric simulations, but Houdini liquids as well. You can also create a Phoenix FD Phoenix Ocean using such caches, as long as the liquid touches the sides and the bottom of the container.
The procedure is as follows:
Create a PhoenixFDSimulator PhoenixSimulator object in your scene. The grid size is not important because the imported cache files will override it.
From the Input rollout specify the Cached Frames path and pick any file of your sequence and the entire sequence will be loaded. You can also manually type in the format of the sequence using format specifiers for the frame number. Phoenix FD supports Phoenix supports the following frame number formats types:Code Block #: frame 1 becomes "1", frame 10 becomes "10", frame 1000 becomes "1000"; ##: frame 1 becomes "01", frame 10 becomes "10", frame 1000 becomes "1000"; ####: frame 1 becomes "0001", frame 10 becomes "0010", frame 1000 becomes "1000"; etc. %d: frame 1 becomes "1", frame 10 becomes "10", frame 1000 becomes "1000"; %4d: frame 1 becomes "⋅⋅⋅1", frame 10 becomes "⋅⋅10", frame 1000 becomes "1000"; %04d: frame 1 becomes "0001", frame 10 becomes "0010", frame 1000 becomes "1000"; etc. <frame>: frame 1 becomes "1", frame 10 becomes "10", frame 1000 becomes "1000"; <frame4>: frame 1 becomes "⋅⋅⋅1", frame 10 becomes "⋅⋅10", frame 1000 becomes "1000"; <frame04>: frame 1 becomes "0001", frame 10 becomes "0010", frame 1000 becomes "1000"; etc.
- Phoenix FD will Phoenix will ask you if you'd like to load a predefined render preset. The presets Phoenix FD comes Phoenix comes with are to be used as starting points when importing a foreign cache.
- By that time you will be able to see a preview of the cache in the viewport, and you will also be able to check which grid channels are loaded under the Simulation rollout, in the Cache File Content list.
- In case you want to render using motion blur, or resimulate over the imported cache, you must have the velocity channel exported as well. You can scale the motion blur velocities if needed, by adjusting the Motion Blur Multiplier parameter in the Rendering rollout.
...
| Fancy Bullets | ||
|---|---|---|
| ||
|
Supported Channels
...
Phoenix FD supports Phoenix supports the following channels:
| Fancy Bullets | ||
|---|---|---|
| ||
|
...
Different applications use different channels and names for them. When loading f3d/ vdb files, Phoenix FD tries Phoenix tries to automatically make the conversion to the supported channels. If a channel is not mapped by default, you can manually set it in the 3rd Party Channel Mappings sub-rollout in the Input rollout:
...