Simulation nodes: Automatic cache reset behavior #105724

New Issue

Hans Goudey · 2023-03-13T15:15:19+01:00

Hans Goudey commented

2023-03-13 15:15:19 +01:00

Terminology

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

Stepping

Some node evaluations don’t involve a time step (e.g. loading a file). In those cases the simulation inputs are used unmodified as simulation outputs.

If an iteration is computed during node evaluation then the simulation outputs are defined as follows:

When cached data is available for the exact current frame the outputs simply expose the cached data.
Simulation inputs are ignored.
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.

Invalidating Caches

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.

Reset

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.

Baking

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.

Notes

“Memory cache” vs “disk cache” distinction should not be relevant to most of the examples below.
Undo is effectively a file load operation too.

# Terminology 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* ![image](/attachments/5d53bb74-1004-4b35-a48c-643583e488dc) # Stepping Some node evaluations don’t involve a time step (e.g. loading a file). In those cases the simulation inputs are used unmodified as simulation outputs. ![image](/attachments/b573bc70-777b-465d-a724-d80687c98897) If an iteration is computed during node evaluation then the simulation outputs are defined as follows: 1. When cached data is available for the exact current frame the outputs simply expose the cached data. Simulation inputs are ignored. ![image](/attachments/cfcde9a3-5793-41b8-8337-82508f203bc5) 2. 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. ![image](/attachments/ac84e6a7-148a-46be-9f21-967c3984bc35) 3. 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. ![image](/attachments/0f1c503d-d68f-4ebc-81a4-d7b1e0b972a2) # Invalidating Caches 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 1. The simulation input on the start frame is different. 2. 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. ## Reset 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](#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. # Baking 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. # Notes * “Memory cache” vs “disk cache” distinction should not be relevant to most of the examples below. * Undo is effectively a file load operation too.

image.png

81 KiB

image.png

92 KiB

image.png

80 KiB

image.png

71 KiB

image.png

66 KiB

👍 1 ❤️ 1

Hans Goudey added the