Cache Settings Rollout

tyFlow’s realtime timeline caching allows for smooth playback of a simulation in the viewport after it has been computed.


Playback cache

  • Enable playback cache: controls whether realtime timeline playback caching is enabled or disabled.

  • Cache subframes: when enabled, subframes will be cached.

Caching subframes can help improve playback accuracy when retiming (slowing) playback, but can significantly increase cache memory requirements. For example, caching subframes when time step is set to ‘12 frame’ will double RAM usage while caching.

  • Enable terrain caching: controls whether static terrain events and terrain meshes will be cached.

When enabled, terrain caching will cache static terrain events (events whose timing modes are all set to ‘on entry’), preventing unnecessary recalculations of terrain data when possible. If an operator’s timing is not set to ‘on entry’, the event will not be cachable, and each successive resimulation will require all of the event’s operators (and all downstream events) to be recalculated as well. Furthermore, if any Terrain Copy Out operators are present in the event, they must be listed after any terrain-modifying operators. If they are listed before, the event (and all downstream events) will not be cached.

  • Clear unused meshes: when the playback cache is disabled, enabling this setting will clear any meshes created on prior frames that are not still referenced by any particles on the current frame. This can help to free up extra RAM during simulations where a lot of meshes are discarded by particles over time. The option is not available if the playback cache is enabled because meshes that have been discarded on the current frame may still be referenced on prior frames by the playback cache.

The “clear unused meshes” setting will be ignored during tyCache export unless “combine meshes per-frame” is enabled in the tyCache export settings.

  • Clear Cache: clears the contents of the cache and effectively resets the simulation.

Particle cache channels

  • [Channel name - data type]: lists the available channels to save with the cache, and their corresponding data type.

Data types and their corresponding size in bytes:
byte = 1 byte
int16 = 2 bytes
int32 = 4 bytes
float16 = 2 bytes
float32 = 4 bytes

The number in square brackets next to some data types represents the number of values that must be stored for that particular channel. For example, a position channel requires X/Y/Z values, each of which is stored as a float32 data type. So the size in bytes for a particular particle position value is 12 bytes (float32 x 3 values).

Mapping values are stored as a float32[3] x the number of mapping channels assigned to the particle.

Custom float data values are stored as a float32 x the number of custom float data channels assigned to the particle.

Custom vector data values are stored as a float32[3] x the number of custom vector data channels assigned to the particle.

Custom TM data values are stored as a float32[12] x the number of custom TM data channels assigned to the particle.

You can estimate how much RAM will be required to cache a particular flow by using the following equation:
(number of particles) x (number of frames) x (total size of all saved channels in bytes)
For example, a simulation of 1 million particles over 250 frames which caches particle positions and velocity will require approximately 7GB of RAM. This resulting value should only be considered an estimate, since caching requires some extra overhead not contained within any particular channel. The amount of overhead varies depending on the complexity of the flow and is displayed in the Cache rollout.

Caching can use a lot of RAM up very quickly, depending on the complexity of your flow. If your machine has limited RAM and you are planning on simulating many millions of particles, it is best to turn caching off and instead export the particles to disk using tyFlow’s available export options. tyFlow makes no effort to check whether RAM allocations are possible on a given system, which means that if your RAM is full and tyFlow needs more of it in order to continue a simulation, tyFlow could cause crash. This ‘fast and loose’ approach to simulating is by design, and it is up to the user to ensure their system is capable of handling the simulations they are trying to run.

Global mesh cache

Processing scene geometry can take a considerable amount of time each time a simulation runs. Without a global mesh cache (ie, in tyFlow versions before 1.019), all input geometry data (vertices, faces, maps, etc) must be re-processed by tyFlow, and various other acceleration structures must be re-built, each time a simulation is refreshed. If the input geometry is of a high enough resolution, this can lead to massive simulation slowdowns, even if only a few particles are actually simulated. When the global mesh cache is enabled, it will keep all of that pre-processed geometry information stored in RAM across multiple simulations and multiple flows, so that it only needs to be computed a single time (until the geometry itself is changed by the user, which will trigger a re-cache of the data for the modified object). This can drastically improve simulation times, at the expense of extra RAM usage.

  • Enable global mesh cache: when enabled, the mesh cache will be enabled for all non-excluded flows in the scene.

“Enable global mesh cache” is a global setting that affects all scenes and flows on a particular machine. If you wish to disable the mesh cache permanently, simply disable this setting once.

  • Include this flow: when enabled, this particular flow will be include in the global mesh cache. When disabled, it will be excluded.

Use the “include this flow” setting for per-flow control over which flows will be included or excluded from the global mesh cache. Enabling or disabling the global mesh cache itself will have a machine-wide effect (ie, will affect all flows in all scenes), which may not always be desirable.