This page provides information on the Simulation rollout of the Simulator.
Overview
The Simulation roll-out contains the main panel controlling the simulation process. It also displays some statistical info like simulation times and the content of the cache file for the current frame. The content may be grid channels such as Temperature, Velocity, etc., as well as particle groups. You can choose the channels from the Output rollout, while the particle groups may be created by the Fire Source, or Splash and Foam sections of the Simulator.
Most simulations require a 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. Phoenix FD provides a scripting system that allows you to execute any action at the end of the simulation, including rendering. For more information, see the Nightly Simulation and Rendering section on the Tips and Tricks page.
UI Path: ||Select PhoenixFD Simulator|| > Attribute Editor > PhoenixFD Simulator > Simulation rollout
Actions
Above the Simulation rollout are several actions for controlling the simulation.
Start, Pause, Stop, Resume – Starts, pauses and stops the simulation. Once the simulation has been paused, the option to Resume becomes available. Note that you can stop a running simulation using the Shift+Escape key combination, or with the Escape key, if the option to do so is enabled in the PhoenixFD Global Preferences.
Restore – Continues a simulation from the currently viewed frame on the timeline. This way a Phoenix simulation that has been stopped previously can be resumed from the point you left off, even after the software was closed and re-opened.
Restoring does not work for cache sequences imported from 3rd party software. It is only possible when the full internal state of a Phoenix simulation is exported (controlled by the Backup Interval parameter in the Output rollout). Frames with the full state are called Backup frames. When a Backup frame is currently viewed, the text "Can Restore From Here" appears in the Cache File Content list. The Restore command finds the latest Backup frame up to the current timeline frame and continues the simulation from there.
Load – Loads the data from a single cache as an initial state for the simulation and starts simulating from the Start Frame the same way the Start action works. The cache can be of the .aur, .vdb, or .f3d formats and so can be imported from a 3rd party software into Phoenix. The loaded grid will be resized to fit the grid's dimensions at the Start Frame. The loaded cache does not need to be a Backup frame or to contain velocity at all - the simulator will load any available channels from the cache file and the rest of the simulated channels will be empty as when starting a brand new simulation. If you wish to smoothly continue a simulated sequence from a given frame, please use the Restore command instead.
Load Current – Same as the Load command, but instead of loading the initial state from a cache file, the currently viewed simulation data would be used.
Phoenix FD Template Dropdown – Sets the controls for the simulator. Advanced will show all the controls for the simulator, while Fire, Smoke, and Liquid will only show parameters related to those types of simulations.
When running a new simulation, Phoenix saves each simulated frame in a cache file with a .aur or .vdb 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:
Inside the cache folder, the default names use the simulator's name. For example, a simulator named "PhoenixFDSimulator1" outputs these cache files:
You can manually change the output path from the Output rollout. After Phoenix has created the .aur frame cache files, you can preview them in the viewport and render them using V-Ray or another renderer.
The diagram to the right illustrates the basic simulation workflow.
For more information on changing paths for cache files, see the Tips and Tricks page.
Parameters
Use Timeline Start Frame | start_from_timeline - When enabled, the Simulation will run from the Timeline Start Frame to the Timeline End Frame or the Custom Stop Frame, depending on the options.
Custom Start Frame | startFrame – Explicitly sets the Start frame of the Simulation. This can also be a negative number.
Use Timeline Stop Frame | stop_from_timeline - When enabled, the Simulation will run from the Timeline Start Frame or the Custom Start Frame to the end of the Timeline.
Custom Stop Frame | stopFrame – Explicitly sets the End frame of the Simulation. This can also be a negative number.
Skip Dynamics Before Start Frame | skipStartFrames – If enabled, the simulation will jump to the starting frame at the start of the simulation. Disabling will evaluate from the start of the timeline to allow Maya dynamics to run before simulating. For instance, Maya's nParticles are sensitive to large jumps in the timeline and disabling this option when the start frame for the Phoenix FD Simulator is different from the start frame of other dynamics in the scene could potentially resolve issues related to this. However, it is best to cache all dynamics before using them in a Phoenix FD simulation.
Auto Save Before Simulation | autoSave – The scene will be saved before starting the simulation.
Use Advection Origin for Motion Blur | rendUVWForMB – The Advection Origin channel will be used to calculate the fluid movement for more precise motion blur. This will replace the normal UVW/RGB channel.
Forward Simulation | forwardSim – Enabling will first move the scene geometry and then simulate the fluid. This will fix simulation lag relative to scene changes.
Progress sub-section
This section of the UI displays information on the current simulation.
Elapsed – The amount of time the simulation has run.
Estimated Left – Estimated time until the simulation reaches the set Stop frame.
Performance – How much time since the last frame was calculated and the frame calculated per second.
Used RAM – Shows how much RAM Phoenix FD is using while simulating.
Frame – Percentage of the current frame calculated.
Total – Percentage of total simulation complete.
Cached Frames – Shows the frame range which contains simulated caches.
Cache File Content sub-section
This area displays information on the current simulation. Any data from channels that have been loaded into the simulator are shown. This includes the minimum and maximum ranges for each channel. Check the Grid Channel Ranges and Particle Channel Ranges pages for more information.
Note that the Container Dimensions show the loaded cache size as seen in the scene, in the currently selected units. This size is not multiplied by the Scene Scale parameter from the Grid rollout. If you want to see how big the container is as seen by the Phoenix simulator when the Scene Scale parameter is used, check the Total Cells info in the Grid rollout.
Scripting
For more information and examples, please see the Scripting documentation.
Use Script | useScript – Enables using Mel or Python script during the simulation.
Script File | scriptFile – Specifies the Mel or Python script file to use during the simulation.
Python help – Shows quick usage information about the phxfd Python module inside the Script Editor.
Edit Script – Opens the script file in the default external editor.
Threading
Threads Limit | threadsLimit – Specifies an upper limit on the number of threads used for the simulation. When the value is set to 0, the maximum number of threads (cores) will be used.
NUMA Node Start | NUMANode0 – If the value of Threads Limit is 0, this parameter specifies the starting index of the NUMA nodes that will be used for simulation.
NUMA Node End | NUMANode1 – If the value of Threads Limit is 0, this parameter specifies the end index of the NUMA nodes that will be used for simulation.
Note: NUMA stands for Non-Uniform Memory Access and currently is available only on Windows. NUMA can be used to restrict the threads used for simulation based on the physical CPUs available on the system (in multiprocessor systems). In this way, better memory access can be achieved when multiple simulations are run on the same machine.