Creating a Caching Graph

A caching graph automatically steps through every variant used in the configurator experience. NVIDIA recommends you create a caching graph before publishing the configurator. By creating a cache, the final published configurator file can preload everything needed, resulting in faster reaction times between variant switching. This eliminates the wait for shaders to compile or textures to download, resulting in a responsive and high quality experience for the final users.

This graph can be automatically triggered by the publisher extension in the next section. In the example file, it can be found at /Graphs/CacheGeneration

The figure shown above is a sample caching graph found inside the sample files. This graph is built with the following concepts:

1. A messageBus event and a keyboard event can be used to trigger the graph. The keyboard input is a backup option if the cache is to be triggered manually.

   1. Be aware that any keyboard event could be triggered by a user. A branch is included to lock out manual generation unless the allowManualCache graph variable is enabled. It is recommended to leave this off and only turn it on when using a local file to manually trigger the cache generation.

   2. The messageBus event must be named “GenerateCache” to work with the extension in the Package and Publish section.

2. There are three nested loops in this graph. The upper loop is fed a list of every prim in the stage that has a variant to be cached. This prim list is manually created in a Constant Target node, but could conceivably be generated dynamically using more complicated graphs with nodes like Find Prims.

   1. First, the upper loop is fed a list of every prim in the stage that has a variant to be cached. The prim list is manually built in a “constant target” node. This list only needs to include prims with variants that need to be processed for caching, not necessarily every variant in the stage.

   2. Next, each prim from the master list is queried for a list of every variantSet contained on that prim.

   3. Finally, each variantSet is looped through for a list of every variant contained within the variantSet.

3. In the final loop, each variant is set by using a Set Variant Selection node with the prim, the variantSet, and the variant all passed through from the earlier loops.

   1. A delay node has been added with a variable for length of time. This allows the UJITSO caching system some time to process the state of the stage and collected the required data it needs to cache. For very large files, it is recommended to set this value to a larger number (or reduce the size and fidelity of the files themselves). By default, it has been set to a 1s delay.

   2. There is an info string printed to console to report the status of the variant selection, it is only used for feedback and to track the progress of the graph.

4. When complete, the first loop of prims exits and sends a messageBus event announcing that it has successfully completed. It will also send another warning to the console announcing it has completed. A warning is used so it is easier to see in the console, not because there is anything incorrect to warn about.

In the example file, with the default 1s delay, the caching graph should take no more than a minute to complete. This length would be extended with longer delays, more prims and variants to loop through, or larger datasets that require more loading time.