Caching
Caching saves a Yeti node's result to files on disk, one for each frame, so lighting and rendering can use it without the rig or the original scene.
Traditional fur systems store every fibre that will be rendered, which can make for very large files. Because Yeti is procedural, its cache files store only the inputs needed to regenerate the fur, at render time or for display in the viewport. This gives you smaller cache files, faster writes, and the ability to change parameters without caching again.
Cache File Format
Yeti's cache file format (.fur) is built on HDF5, which is very extensible.
Each cache file holds a Yeti graph, with its global variables, input objects, grooms and guides, and their animated and static attributes.
You can inspect the data in a Yeti cache with HDFView, or with the pgYetiCacheInfo command-line tool.
Cache Previews
Yeti can also store a preview in each cache file: the fully evaluated groom at the Yeti node's viewport density, as it would be displayed in Maya. Turn this on with Generate Preview in the I/O section of the Yeti node's Attribute Editor, or with the -generatePreview flag.
Yeti itself doesn't display the preview when it reads a cache. It's there for your own pipeline tools: because the preview is already evaluated, a tool can read it from the cache file and display the groom in another application without running the Yeti graph. The preview is stored in the cache file's /preview group, alongside the density it was generated at.
Generating a preview means evaluating the graph once more for each sample, so caching takes longer and the files are larger. Previews aren't stored for graphs that output meshes.
Caching a Yeti Graph in the UI
To cache a graph from the UI, select the Yeti node you want to cache and open the I/O section of its Attribute Editor.
Set the Output Cache File Name, the frame range and the number of samples to write for each frame.
To watch the viewport update while caching, turn on Update Viewport While Caching. This tends to slow caching down.
When you're ready, click Write Cache to start.
Caching a Yeti Graph with a Script
Caching with a script is the recommended method for anything beyond simple workflows, because it's much more flexible.
Use the pgYetiCommand command to cache. In its simplest form, give it the file name, the frame range and the Yeti node:
pgYetiCommand -writeCache <filename> -range <startframe> <endframe> <nodename>
Use C-style formatting for the frame number in the file name, for example %04d for a frame number padded to four digits. So, to cache 20 frames of a furry monster:
pgYetiCommand -writeCache "/myCacheDir/furryMonster.%04d.fur" -range 1 20 myFurryMonsterYetiShape
When you run it, the scene steps through the timeline and caches each frame to its own file.
See the caching scripting reference for all of the available flags.
Caching Several Nodes
If you pass several Yeti nodes, Yeti caches them all at once. To write each node to its own files, include the <NAME> tag in the file name. For example:
pgYetiCommand -writeCache "/myCacheDir/furryMonster_<NAME>.%04d.fur" -range 1 20 furryMonsterShape
writes the cache files furryMonster_furryMonsterShape.0001.fur, furryMonster_furryMonsterShape.0002.fur and so on, and
pgYetiCommand -writeCache "/myCacheDir/furryMonster_<NAME>.%04d.fur" -range 1 20 furryMonsterShape evenFurrierMonsterShape
writes the cache files furryMonster_furryMonsterShape.0001.fur, furryMonster_evenFurrierMonsterShape.0001.fur, furryMonster_furryMonsterShape.0002.fur, furryMonster_evenFurrierMonsterShape.0002.fur and so on.
When you cache several nodes, make sure each one gets its own file name. If two nodes would write to the same file, only one of them is cached.
You can also give a separate file name for each node, separated by the pipe symbol (|), for more explicit naming. For example:
pgYetiCommand -writeCache "/myCacheDir/furryMonster_<NAME>.%04d.fur|/aDifferentCacheDir/evenFurrierMonsterShape_<NAME>.%04d.fur" -range 1 20 furryMonsterShape evenFurrierMonsterShape
writes the first node to /myCacheDir and the second to /aDifferentCacheDir, with their own names.
When you give several file names, you need one for each node you're caching. This works with -writeCache, but not with -writeAlembic.
Viewport Update
By default, Yeti doesn't update the viewport while it caches. Displaying the fur as it caches means the graph has to be evaluated for display too, which slows caching down, but you can turn it on to preview the results as you go.
When caching from the UI, use the Update Viewport While Caching toggle.
From a script, use the -updateViewport true flag. Scripted caching ignores the UI toggle, so you have to set this flag yourself.
Sample Count
By default, Yeti caches three samples for every frame. For example, for frame 1 it caches 0.5, 1.0 and 1.5, and for frame 2 it caches 1.5, 2.0 and 2.5. You can read the cache at any time: times outside the samples are clamped to the nearest sample, and times between samples are interpolated.
When a character moves very fast, you may need to sample the scene more often to capture the changes in shape accurately.
To do this, use the -samples <int numberOfSamples> flag. The number of samples is always odd, so an even number is rounded up.
For example, to cache the earlier example with 5 samples instead of 3:
pgYetiCommand -writeCache "/myCacheDir/furryMonster.%04d.fur" -range 1 20 -samples 5 myFurryMonsterYetiShape
Now frame 1 is stored as 0.5, 0.75, 1.0, 1.25 and 1.5, as you'd expect.
Alternatively, you can give exact sample times with the -sampleTimes <string sampleTimes> flag, as a space-separated list of offsets from each frame.
For example:
pgYetiCommand -writeCache "/myCacheDir/furryMonster.%04d.fur" -range 1 20 -sampleTimes "-0.3 -0.15 0.0 0.15 0.3" myFurryMonsterYetiShape
stores frame 1 at the sample times 0.7, 0.85, 1.0, 1.15 and 1.3.
See the scripting reference for more details.
Displaying a Yeti Cache
Once you've cached a groom to disk, you can reference the cache for display and rendering.
To do this, create a new Yeti node (click CR on the Yeti shelf) and set its Input Cache File Name to the full path of the cache files. For example:
/myCacheDir/furryMonster.%04d.fur
Then set Input Mode to Cache. The node evaluates the cache and displays the result in the viewport.
A Yeti node only needs a render (batch) license, whether it reads a cache or evaluates its own graph. Yeti checks out an interactive license only when you brush a groom, open the Graph Editor, or use pgYetiGraph to create nodes or change the Graph Editor's selection. To avoid checking out interactive licenses by accident, don't do these in scenes that only read caches.
Rendering a Yeti Cache
Rendering a cache is no different from rendering a live groom, and the result looks the same. The only difference is that the renderer reads the cache on disk directly, instead of Yeti exporting a temporary cache for rendering.