Source/Nodes/Caching

= Analysis: Caching =

With a procedural workflow and more complex computations, caching is important to maintain good performance. There are a few different types of caches, each solving different problems. This document is intended to clarify discussion on this topic.

Alembic Caches
This type of cache stores an entire scene or collection of objects on disk, with baked transformations and geometry. Rigs, modifiers and other procedural effects are baked. Fast streaming of an animation sequence is possible. Alembic and USD are the common file formats, and can store an animation sequence in one file.

Use Cases

 * Interop between different applications.
 * Hand-off between different parts of the animation pipeline (e.g. animation -> physics -> lighting).
 * Better performance opening and playing back files.

Challenges

 * Blender and file format data structures may differ, causing subtle data loss or meaning some Blender features must be avoided.
 * Materials, lights and other custom Blender data must be defined outside Alembic and re-attached to the geometry after loading.
 * Need pipeline support to keep caches up to date and share them. A lot or little manual work for users.
 * New ways for things to fail, due to incomplete implementations and bugs in code that would otherwise not be needed.

Physics Caches
For physics simulation, each frame depends on the previous one and computing physics for the entire frame range up to the current frame is too slow. In general, physics baking is expensive to compute and may be run as a batch job on a user's computer or a render farm. Blender physics systems use custom file formats for this currently, with the exception of OpenVDB smoke. Other 3D apps also often use custom formats, with one file per frame.

Use Cases

 * Caching for physics playback in the viewport, if it's fast enough to be interactive.
 * Baking on a local computer for slower physics.
 * Baking on a render farm for even more expensive physics, or different variations.

Challenges

 * Good usability of clearing and saving caches, showing what is up to date, .. is a challenge. Users do many experiments before finding the final parameters.
 * File format must support fast random access read, and fast append write.
 * Disk space usage can be significant, especially for volumes.
 * Needs pipeline support when sharing and render farms are involved, may go out of date.
 * Current custom file format does not support topology changes, just array of points.

Memory Caches
While Blender is running, the result of node evaluation or other computations also must be cached in Blender. This allows quicker updates for editing and animation playback.

Use Cases

 * Cache evaluated mesh of each object, only update those that changed.
 * Cache intermediate node evaluation results, for faster parameter tweaking.
 * Cache animation sequence over multiple frames in the background.
 * Image textures loaded from disk.

Challenges

 * Memory usage is a concern, especially when caching intermediate results. Memory limits can help.
 * Keeping input and evaluated data in sync and intelligent updating just what is needed is hard (depsgraph).

Compile Caches
With more advanced node system, we can dynamically compile programs. If there are many such programs in a complex scene, caching the compilation is important.

Use Cases

 * Function nodes compiled to LLVM.
 * Eevee shaders compiled to GLSL.
 * Cycles kernels compiled to OpenCL.

Challenges

 * Initial wait time when opening files or rendering can be long for initial cache fill.
 * Separate fast-to-compile and fast-to-run code paths are possible, but lead to extra code maintenance and bugs.
 * Machine code typically cannot be shared between systems, so every user has to wait.
 * Compilation performance is somewhat out of our own control and for GPUs driver dependent, difficult to rely on.