TABLE OF CONTENTS


Overview

Caching is a means of storing snapshots of data over time so they be referenced elsewhere in a pipeline, usually to optimize workflows and processes. Traditionally caching a fur system stores the full dataset that represents all of the fibres that will be rendered - when dealing with large grooms of millions of hairs with many attributes this can lead to extremely large files.


Due to it’s procedural nature Yeti caches differ in that all that is stored are the inputs needed to regenerate the groom either at render time or for display in the viewport - this leads to much smaller cache files and faster write times as well as allowing for parameters to be changed without having to recache.


Historically the cache format that Yeti uses also stores meshes, particles etc. - if just an import node is used in a graph these primitives may be cached individually and rendered.


Cache File Format

Yeti’s cache file format is built on top HDF5 format which is extremely extensible - by default attributes and data sets are written using the GZip compression scheme to improve disk space usage.


If one was interested in inspecting the data stored within a Yeti cache the HDFView application can open and view all of the relevant data.


Every cache file represents a Yeti graph with global variables, input objects, grooms and guides along with all of the attributes both dynamic and static.


Cache Previews

By default Yeti will use the current viewport evaluation as a preview to store in the cache, this is used to provide faster feedback to artists in the viewport when referencing the cache for lighting purposes. This feature can be toggled on/off if needed in the I/O options of the Yeti node.


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.



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 seperated 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 mulitple 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 3 samples for every frame - for frame 1 this would be 0.5, 1.0 and 1.5 and for frame 2 this would be 1.5, 2.0 and 2.5 etc. The cache may be referenced at any time but will be clamped outside of the time samples, if a time is requested that doesn’t lie directly on a sample Yeti will interpolate accordingly.


In some instances where a character may have extremely snappy motion the scene will need to be sampled at a higher rate to capture the change in shape more accurately - this is possible with the -samples nsamples parameter. So if you wanted to cache the above example with 5 vs 3 you would do:


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

As with the groom it’s straight forward to reference and render a cache file. Create a new Yeti node ( CR in the Yeti shelf ), unlike the groom where it requires the input geometry the cache will have stored that information thus it lives on it’s own in the scene. In the Cache Filename parameter specify the full path to the cache files, in this example it would be:


/myCacheDir/furryMonster.%04d.fur


as per the example above.


Set the file mode to Cache the node should evaluate and display the result in the scene.


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

Rendering when referencing a cache is no different than not - in fact it’s the same thing, but when not referencing a cache an extra step of storing a temporary cache is taken - both means look identical to the renderers.