Simulation nodes: Automatic cache reset behavior #105724
To make discussion of inputs and outputs easier, the following naming convention is be used:
- Input sockets of the “Simulation Input” node are simulation inputs
- Output sockets of the “Simulation Input” node are iteration inputs
- Input sockets of the “Simulation Output” node are iteration outputs
- Output sockets of the “Simulation Output” node are simulation outputs
If an iteration is computed during node evaluation then the simulation outputs are defined as follows:
When cached data for the current frame is not available, but exists for an earlier frame, an iteration is performed with the necessary time step.
Simulation inputs are ignored.
Iteration inputs are cached data.
When previous data is unavailable or invalid, then the current simulation inputs are used and piped straight to iteration inputs.
This is only correct for the start frame (to keep results deterministic), so on other frames a warning should be shown if no cached input is available.
A cache becomes invalid if the scene data is changed such that the output for the current frame will be different. This could be because
- The simulation input on the start frame is different.
- Scene data used during the iteration (e.g. an Object Info node) changed.
In practice it will be difficult to determine precisely when changes do or do not affect the simulation. False positives have to be expected, that is: invalidating the cache when it wouldn’t have to be. This is because we have to rely on coarse depsgraph dependencies. It is preferable to invalidate the cache unnecessarily than to keep cached results and miss potential changes. Over time the dependencies affecting nodes may be refined for more stable caching.
The term "reset" describes the point when a simulation reverts to the initial scene data, typically when animation jumps back to the start frame (Point 3 in Stepping).
Conditions that can cause a reset (only when cache is invalid!)
- Jump to start frame
- Jump to other frame, with a warning
- Start frame is changed (might invalidate cache)
A reset should not happen just because the cache got invalidated. For example: A particle simulation might use an object as emitter. The user moves this object manually during simulation, which constantly invalidates the cache. However, the particle simulation should not reset: all the current particles remain in the simulation.
The last valid simulation state is always retained even if the rest of the cache is invalidated. That way simulations can be tested dynamically.
Baked caches are never invalidated automatically.
If a baked cache exists then the simulation input should never be used and no further iterations should happen. The simulation output is always read from the cache.
A baked cache must be freed explicitly, at which point it reverts back to a dynamic cache.
- “Memory cache” vs “disk cache” distinction should not be relevant to most of the examples below.
- Undo is effectively a file load operation too.
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?