The Inferno Recall operator allows you to load cached Inferno simulation data for fast viewport recall/playback.
Recall sim data (RAM cache): loads simulation data from a live simulation via a RAM cache.
Recall TYV data (RAM cache): loads data from a cached TYV file sequence via a RAM cache.
Recall VDB data (RAM cache): loads data from a VDB file sequence via a RAM cache.
Recall VDB data (live): loads data directly from a VDB file sequence on disk each frame, without RAM caching.
From Inferno Export operator: the file path will be read automatically from an Inferno Export operator in the same flow.
From specified path: the file path is set manually using the filename field.
Controls which simulation channels will be loaded from the cache, and (optionally) the names of the corresponding VDB grids to read from when recalling VDB data.
Density: when enabled, the density channel will be recalled.
Temperature: when enabled, the temperature channel will be recalled.
Temperature units: the unit system used to interpret temperature values in the recalled data, for conversion into the simulation’s internal normalized units.
Color: when enabled, the color channel will be recalled.
Fuel: when enabled, the fuel channel will be recalled.
Velocity: when enabled, the velocity channel will be recalled.
Velocity mode: controls how velocity data is stored in the source VDB.
Vector grid: velocity is stored as a single vector grid. Specify the grid name.
Scalar grids: velocity is stored as three separate scalar grids. Specify X/Y/Z names.
Vel scale: a multiplier applied to recalled velocity values.
Emitter vel: when enabled, emitter velocity data will also be recalled.
Flags: when enabled, voxel flag data will be recalled.
The RAM cache stores recalled simulation frames in memory to avoid repeated disk reads during playback and rendering.
The VRAM cache will automatically swap to system RAM if the VRAM cache takes too much space on the GPU for the simulation itself to continue. This way, manual management of the VRAM cache is not needed, unless a 3rd party plugin has VRAM requirements that make it necessary to swap the VRAM cache to system RAM at certain times (ex: you want to free up some VRAM used by the cache so that a 3rd party renderer can use the GPU).
If you are retiming your Inferno simulation and are also simulating with less than 1 step per frame, you should enable “cache subframes” - otherwise the quality of the retiming result may suffer.
Conserve VRAM: when enabled, VRAM held by the simulation itself will be swapped to system RAM during cache recall, and will only be swapped back once the simulation is resumed. Enabling this setting can free up extra VRAM for more VRAM-intensive recall post-processing effects.
Per-channel compression settings: when enabled, cache compression can be configured on a per-channel basis.
Compression modes:
Lossless: data is compressed without any quality loss.
Lossy - standard: data is compressed to a lower bitrate, at the expense of some precision. Produces negligible lossy artifacts.
Lossy - strong: data is compressed to an even lower bitrate, at the expense of more precision. May produce slightly more noticable lossy artifacts.
Lossy - extreme: data is compressed to the lowest bitrate, at the expense of even more precision. May produce noticable lossy artifacts, like visible banding over large temperature ranges.
Lossy - VQVDB: data is compressed/decompressed using a neural network-based lossy compression model (VQVDB). Results in much larger/better compression ratios than alternative methods (up to 16x, compared to 3-4x of non-ML methods), but is slower to compress/decompress and may also produce more visible artifacts in comparison to raw lossless compression.
Uncompressed: data is stored without any compression (not recommended).
VQVDB models are used when the compression mode for a channel is set to “Lossy - VQVDB”.
VQVDB scalar model: the neural network model used to compress scalar grid channels (density, temperature, fuel).
VQVDB vector model: the neural network model used to compress vector grid channels (velocity).
The Masking rollout has parameters which allow you to mask out certain areas of a cached fluid simulation.
Clear emission voxels: when enabled, density will be cleared from voxels that were marked as emissive during the simulation.
Clear %: the percentage of density to remove from emissive voxels.
Clear emission voxels: when enabled, temperature will be cleared from voxels that were marked as emissive during the simulation.
Clear %: the percentage of temperature to remove from emissive voxels each step.
The Retiming rollout enables smooth temporal interpolation of recalled simulation frames, allowing playback at a different speed.
The actual retiming of an Inferno simulation can be controlled from the “Retimer” rollout of the parent tyFlow object - the same way retiming of normal particle simulation is controlled.
Affect velocity magnitude: when enabled, the velocity magnitudes in the recalled data will also be scaled by the retiming factor.
Smooth retiming interpolation: enables smooth frame interpolation using a high-fidelity velocity-based advection/tracing algorithm to blend between adjacent cached frames.
“Smooth retiming interpolation” requires that velocity values be cached along with density/temperature/fuel values, in order to properly compute the interpolated fluid values.
Override dt: when enabled, the time delta used for velocity-based interpolation will be set to the specified value rather than derived from the cache frame rate.
Velocity interpolation: when enabled, velocity values themselves will be retimed using the smooth retiming algorithm. When disabled, velocity data will not be interpolated by the algorithm (reducing post-retiming VRAM usage, but preventing the computation of velocity-dependent effects like motion blur).
Conserve VRAM: when enabled, VRAM held by the simulation itself will be swapped to system RAM during cache retiming, and will only be swapped back once the simulation is resumed. Enabling this setting can free up extra VRAM for the retiming algorithm (which may be necessary when retiming high-resolution simulation caches).
The Upres rollout applies super-resolution processing to recalled simulation data, increasing the effective voxel resolution of the cache.
Fast fluid upres: uses ILM’s Fast Fluid Upres algorithm to generate additional detail in the higher-resolution grid. This is generally the preferred upres method, as it is fast and can produce very detailed results.
ML upres: uses various machine learning models to infer higher-resolution detail from the cached data.
The ILM upres method is generally preferred over the ML upres method, because it is much faster and produces finer details. However, in some more complicated setups where fluid emission is controlled in non-standard ways (ex: using an Inferno Modify operator), it may produce more artifacts and less predicable results from given inputs. In those cases, the ML method may be preferred as it tends to produce more predicable results regardless of how idiosyncratic an Inferno setup may be.
Clear velocity: when enabled, the velocity grid will be cleared before the upres pass, reducing upres VRAM requirements (but preventing the post-upres computation of velocity-dependent effects like motion blur).
Conserve VRAM: when enabled, VRAM held by the simulation itself will be swapped to system RAM during cache upres, and will only be swapped back once the simulation is resumed. Enabling this setting can free up extra VRAM for the upres algorithm.
The raw VRAM requirement for an upres operation is the cube of the upres factor. For example, a cached frame that takes up 1 GB of space in VRAM, will take up 8GB of space when upres’d by 2x (1GB x 2^3), and 27GB of space when upres’d by 3x (1GB x 3^3). However, tyFlow also employs upres optimization procedures which clear out empty regions of an upres’d cache, resulting in actual VRAM requirements less than the cubed upres factor (often times reducing actual post-upres VRAM requirements by up to 50%). Either way, users should be aware that by enabling cache upres, the amount of VRAM required to process and display a cached frame will increase dramatically.
Euler: simple single-step advection.
Runge-Kutta 2: second-order Runge-Kutta integration.
Runge-Kutta 4: fourth-order Runge-Kutta integration.
The advection type and number of backtrace steps have a direct impact on the quality of the upres result. Using RK advection modes can improve how fluid vectors are traced through a grid, leading to smoother plumes, and number of backtrace steps controls how much fine detail the algorithm will produce (more steps = more detail).
Match density dissipation: when enabled, the upres pass will apply the same density dissipation rate as configured in the Birth Inferno operator.
Match temperature cooling: when enabled, the upres pass will apply the same temperature cooling rate as configured in the Birth Inferno operator.
Enabling these parameters applies an inverse dissipation/cooling pass to the backtrace reduced, helping to match the actual dissipation/cooling values applied to voxels during the simulation. Disabling these parameters effectively disables any dissipation/cooling in the result - the intensity of voxel values will be equal to the intensity of the values sampled at N backtrace steps away from the current frame.
Advect subframes: when enabled, the upres advection will be evaluated at sub-frame intervals for improved temporal accuracy.
High quality backtrace: when enabled, a higher-quality backtrace algorithm will be used at the cost of additional computation. This algorithm is better at matching voxels with their source emitters, leading to more consistent results around areas where emission is occurring.
Mip-map anti-aliasing: when enabled, mip-map filtering will be applied during advection to reduce aliasing artifacts.
Track emitters: controls how emitter voxels are tracked and preserved during the upres pass.
By flags: emitter voxels are identified using voxel flag data from the cache.
By threshold: emitter voxels are identified by comparing channel deltas against a threshold value.
The “flags” mode should be used in normal circumstances, except in cases where voxel emission is not controlled by explicit emitters (ex: when using Inferno Modify to “emit” fluid) - in those cases, “threshold” mode may be needed to produce consistent results, since emissive voxels will be identifies using a delta-threshold heuristic, rather than by reading explicit emission flags from voxels in the grid.
Model: the machine learning model file used for ML-based upres inference.
Adaptive processing: when enabled, upres processing will be skipped for sparse regions of the grid that fall below an activity threshold, improving performance.
Batch grids: when enabled, multiple grid channels will be processed together in a grouped upres batches.
FP16 precision: when enabled, inference will run in 16-bit floating-point precision, reducing VRAM usage. Note: some GPUs have limited FP16 support, resulting in a performance reduction when this setting is enabled - so it is disabled by default.
Overlap blending: when enabled, neighboring upres tiles will be blended together at their boundaries to reduce seam artifacts.
Padding: the number of voxels of padding to include around active regions when processing boundaries.
Sharpening can be applied to a cache in order to artificially boost fluid details.
Unsharp mask: when enabled, an unsharp masking filter will be applied to sharpen density values.
Sigma: the radius of the blur used to compute the unsharp mask. Larger values affect broader features.
Strength: the strength of the unsharp mask sharpening effect.
Reverse advection: when enabled, reverse-advects density along the direction of fluid velocity vectors in order to give the illusion of fluid sharpening/tightening.
Strength: specifies the magnitude of reserve-advection vectors to use.
Unsharp mask: when enabled, an unsharp masking filter will be applied to sharpen temperature values.
Sigma: the radius of the blur used to compute the unsharp mask.
Strength: the strength of the unsharp mask sharpening effect.
Reverse advection: when enabled, reverse-advects temperature along the direction of fluid velocity vectors in order to give the illusion of fluid sharpening/tightening.
Strength: specifies the magnitude of reserve-advection vectors to use.
The Effects rollout applies post-process modifications to fluid grid voxel values. Each relative channel can be enabled independently.
By enabling modifiers in the Effects rollout, you can perform simulation-independent voxel value tuning. For example, by enabling “relative to meshes” for density values, you can make density voxels near a scene mesh more transparent relative to their distance to the mesh - resulting in smooth density falloff outward from a mesh surface.
Relative to temperature: when enabled, recalled density values will be scaled based on the local temperature value.
Relative to density: when enabled, recalled density values will be scaled based on the local density value itself.
Relative to velocity: when enabled, recalled density values will be scaled based on the local velocity magnitude.
Relative to meshes: when enabled, recalled density values will be scaled based on proximity to the specified mesh objects.
Zero distance if inside volume: when enabled, voxels that fall inside the mesh volume will be treated as having zero distance to the surface, causing the relative force multiplier to use the minimum value for those voxels.
Relative to density: when enabled, recalled temperature values will be scaled based on the local density value.
Relative to velocity: when enabled, recalled temperature values will be scaled based on the local velocity magnitude.
Relative to meshes: when enabled, recalled temperature values will be scaled based on proximity to the specified mesh objects.
Zero distance if inside volume: when enabled, voxels that fall inside the mesh volume will be treated as having zero distance to the surface, causing the relative force multiplier to use the minimum value for those voxels.
The inside/outside test performs a simple nearest-normal calculation to deduce whether a voxel is inside or outside of a mesh. This test may fail for open meshes, self-intersecting meshes, or groups of meshes that intersect each other. It works best on closed meshes that do not intersect.