Skip to main content

Caching

Caching will bake the groom data into externally written files for a specified time sequence.

Traditional fur systems store the entire dataset representing all the fibres that will be rendered, which can result in extremely large files.

Due to its procedural nature, Yeti caches store only the inputs required to regenerate the groom at render time or for viewport display. This approach leads to smaller cache files, faster write times, and the ability to modify parameters without the need to re-cache.

Cache File Format​

Yeti's cache file format is built on top HDF5 which is extremely extensible.

Every cache file represents a Yeti graph with global variables, input objects, grooms and guides with relevant dynamic and static attributes.

It's possible to inspect the data stored in a Yeti cache using HDFView.

Cache Previews​

By default, Yeti stores the current viewport evaluation as a preview in the cache. This preview allows artists to get faster viewport feedback when referencing the cache during lighting. You can toggle this feature on or off in the Yeti node's I/O options.

The current density value for the graph is also stored with the preview. If, when viewing the cache, the density is lower than the stored value the fur will be culled; if higher the density value stored within the cache will be drawn.

Caching a Yeti Graph​

This can be done with the pgYetiCommand and a few simple flags or using the Write Cache button in the I/O palette.

If you would like to cache a graph using the UI select the Yeti node you would like to cache and open the I/O palette in the Attribute Editor. The Write Cache button can be used to start the caching process which will use the Frame Range and Samples specified in the UI.

Caching a Graph

To cache a graph via command line make sure that the Yeti Node is selected ( alternatively you can provide the node shape name on the command line ) and use:

pgYetiCommand -writeCache filename -range startframe endframe

the command will use standard C syntax for resolving the frame number - eg. %04d for 4 padding, so for example, I would cache 20 frames of my furry monster using:

pgYetiCommand -writeCache “/myCacheDir/furryMonster.%04d.fur” -range 1 20

once executed you will see your scene step through the time line and cache the results to individual files.

Concurrent Caching​

If multiple Yeti nodes are selected (or passed as parameters) they will all be cached concurrently, to allow Yeti to save the cache data to node specific files the <NAME> tag can be used. For example:

pgYetiCommand -writeCache “/myCacheDir/furryMonster_<NAME>.%04d.fur” -range 1 20

will output cache files named furryMonster_furryMosterShape.0001.fur for the first frame if furryMonsterShape was the provided node name.

Additionally, multiple file names may be specified separated by the pipe symbol which allows more explicit naming. For example:

pgYetiCommand -writeCache “/myCacheDir/furryMonster_<NAME>.%04d.fur|/aDifferentCacheDir/nakedMonster_<NAME>.%04d.fur” -range 1 20

will output the first node to /myCacheDir and the second to /aDifferentCacheDir with their respective names. If providing multiple cache names you will need as many names as there are nodes to be cached.

Viewport Update​

By default Yeti will update the current 3d viewport while caching so you can preview the results as it goes - as displaying the fur as it caches means the graph will need to evaluate you may want to turn this off in some cases to speed up the process.

If caching via the UI there is a toggle used to control this behavior.

On the command line the -updateViewport true/false parameter can be used.

The command line export will not obey the UI toggle so you will have to explicitly control this from the command line.

Sample Count​

By default, Yeti will cache out three samples for every frame. For instance, for frame 1, it will cache 0.5, 1.0, and 1.5. For frame 2, it will cache 1.5, 2.0, and 2.5. The cache can be referenced at any time, but it will be clamped outside the time samples. If a time is requested that doesn't correspond directly to a sample, Yeti will interpolate accordingly.

In certain cases, when a character's motion is extremely rapid, the scene needs to be sampled at a higher rate to capture the shape changes more accurately. This is possible by using the -samples nsamples parameter.

For instance, if you wanted to cache the previous example with 5 samples compared to 3, you would do this:

pgYetiCommand -writeCache “/myCacheDir/furryMonster.%04d.fur” -range 1 20 -samples 5

and now frame 1 will be stored as 0.5, 0.75, 1.0, 1.25, 1.5 as you would expect.

Displaying a Yeti Cache​

Once a groom has been cached to disk, it can be referenced for display and rendering purposes.

To do this, create a new Yeti node (press CR in the Yeti shelf) and set the Cache Filename parameter to the full path of the cache files. For example:

/myCacheDir/furryMonster.%04d.fur

Then set the file mode to Cache which will cause the node to evaluate and display the result in the viewport.

When referencing a cache Yeti will only use a Render license.

If at some point a corrective groom, new guide set or input geometry is added to the Yeti node this will cause a license to be checked out - prior to reading a cache make sure the node isn't being fed new data to avoid unexpected licenses being checked out.

Rendering a Yeti Cache​

There's no difference between rendering a live groom and a cache file. The result should look the same. Instead of exporting a temporary cache file for rendering, the on-disk cache will be referenced directly.