Point Cache replacement based on Alembic #37578

New Issue

Lukas Tönne · 2013-11-22T11:32:01+01:00

Lukas Tönne commented

2013-11-22 11:32:01 +01:00

The goal of this project is to implement a new Point Cache system based on the Alembic library and unify the various caching methods used in Blender.

This is a prerequisite for further work on particle systems. Having a working Alembic exporter/importer will also greatly benefit integration of Blender into larger pipelines.

Current Issues

Point cache is used for most physics simulations, but does not include mesh caching. For this there is a separate Mesh Cache modifier , using mdd or pc2 file formats, with its own limiations. Using a unified point cache system would help scene management.
Alembic, unlike the current point cache binary format, supports arbitrary data attributes. This is very important for flexible simulations and user-defined data in particles and mesh data (vertex groups, custom data layers , etc.).
Point cache is limited to fixed-size data sets. This is sufficient for many simulations which only deform geometry (cloth, hair), but for particles and constructive modifier caching variable point data sets are important.
Compression in the point cache file format leaves a lot to be desired. Alembic is specifically designed to have a small memory/disk space footprint and make good use of threading for fast export/import.
Point cache binary format is unique to Blender. While it is fairly simple to interpret, it does not facilitate import/export and integration into larger pipeline workflows. Alembic on the other hand is a commonly used tool and can leverage a large developer community.
Settings for caches are object-centric, each simulation writes its own separate cache files. Baking all caches is simply a loop over all objects, which is not very efficient. Having scene-level settings and operators would make Alembic export/import easier.

Proposal

Keep basic cache settings on Scene level:

"Disk Cache" vs. "Memory Cache": This could be reframed as having cache file output by default and use ''packing'' in .blend files like we do with images.
Output directory setting for cache files (with nice defaults)
Frame ranges
Automatic cache recording settings (see below)

Optional overrides on object/sim level

If deviating settings are needed for individual simulation caches. By default it should not be necessary to tweak each cache individually.

Question: How do we handle automatic caching?

Current approach is to automatically record point cache when stepping through frames, unless the cache is explicitly baked.
This breaks easily when jumping over frames and or scrubbing in the timeline, because simulations need a contiguous ordered frame range for correct results.
Does this work well enough to justify keeping it? Are there alternatives to this behavior?
One suggestion was to make simulations independent from the animation playback by default, but this makes it difficult to sync simulation results to keyframe-animated objects and to record valid caches on-the-fly.

Question: Do we really need multiple caches for each object? This feature adds a list of point caches for every object, only the active cache is used, the others are basically a version control system. Could this be moved to the scene level? The problem with this way of "versioning" is that there is really no way to roll back to a previous version, other than comparing the results without any way to revert settings.

Directory and File Names
How should directories and file naming work?
Current naming scheme works per object and uses a combination of output directory + filename:

Directory is chosen in this order:
- explicit path if specified by the user
- or constructed as //blendcache_<blend file name>/ (if .blend is saved and thus relative paths work)
or using a temp folder like <tmp folder>/blendcache/
File name is generated as <basename>_<frame number>_<cache index>.bphys
- <basename> can be specified by the user or otherwise the ID datablock name (usually Object) is used
- <cache index> is generated automatically by default (-1), but needed if multiple caches exist in the same ID block.

Frames, Times and Sample Indices
There are 3 different modes of interpreting "time" that need to be managed in a clean way:

Blender usually defines data in terms of frame.

Any notion of "time" is secondary, defined by the frames-per-second (fps) settings in the scene and additional start/end frames.
Some simulations also add their own interpretation of time on top of this, by using time scale factors (e.g. [[ http://wiki.blender.org/index.php/Doc:2.6/Manual/Physics/Smoke/Domain#Generic_options | smoke sim time scale options ]]), although these factors are mostly for the internal simulation time step and don't have much consequence for mapping sample times.

Alembic samples can be accessed
- directly by an index (0..N)
- or by using a time value which is mapped to a sample index based on a time sampling (see [Time Sampling overview ]], [ https:*code.google.com/p/alembic/source/browse/lib/Alembic/Abc/ISampleSelector.h#47 | ISampleSelector class )

While it would be possible to largely ignore time sampling for Blender cache files and simply read each cached sample as a frame, it is probably more reliable and flexible to calculate time values as defined by the scene render range and fps settings. This would allow using externally generated Alembic files which use a different sampling rate than the current scene and map them into the scenes frame range.

Ultimately it could be very useful to integrate cached data into the NLA editor as a track. At that point the direct sample<->frame relationship that might still exist for cached data from the same scene is useless anyway.

Proposed Changes

Output directory is by default specified on scene level, using the same rules as before.
Alembic cache files don't store files for each individual frame, instead one file for the whole cached frame range is used
2 possible behaviors:
- Each cached simulation/modifier creates its own file in the cache folder
- Combine caches in a single scene cache file.

  This is more in line with standard Alembic use, but makes it more difficult to cache objects separately

In both cases identifier names for cache data are a problem.

This is already the case with current point caches: Renaming an object will sever the mapping to file names, leading to unused files on the disk and making re-bake necessary.

Modifiers

Almost all cacheable data is located somewhere in modifier stacks, so these require some special attention. While caching the final result of mesh modifier evaluation (final_dm) is obviously useful, we also want to support partial caching and layered evaluation of mesh stages and simulation.

Proposal

Add a "Point Cache" modifier for defining intermediate stages that can be cached. It would have almost no settings and just let users define fixed points, rather than caching every modifier (too much data) or relying on some heuristic of modifier "cost" to determine suitable stages.
By default there is one virtual Cache modifier instance shown at the end of the stack. This does not have to be a real modifier, but just reflect caching of the final_dm result. Caching can be disabled entirely by disabling this modifier. [Is it preferable to leave this completely to the user and not do any modifier caching at all by default?]

Base modifier stack with cache		Modifier stack with intermediate caching

Open Questions

How to treat multiple successive cache modifiers? Can/Should this be prevented, or just ignore redundant instances? Similarly for caches at the beginning of the stack where they are useless.
Should these caches also handle internal data of simulation modifiers (smoke/fluid voxels, particles, hair, ...). Or do they only handle DerivedMesh caching and leave sim data to explicit cache instances elsewhere (physics tab) [I would prefer the latter to keep design clean and avoid nasty corner cases]

Caching vs. Export

These two cases may need to have somewhat different requirements in terms of necessary data attributes, sampling, etc. (while running the same backend input/output functions).

Caching is an internal procedure. The data being written only has to be interpreted by Blender itself (although the files would largely follow Alembic schemas where applicable). Some data attributes (e.g. normals) might be omitted here, since reconstructing them is fairly cheap. [confirm?]
Export is a one-way procedure to describe Blender data in a generic format for other software. All possible data attributes should be included to ensure compatible results.

Implementation

(somewhat outdated)

Scene stores global settings for caching
Simulations and modifiers can have own settings if needed
Cache data is separate from other DNA by default, but can be packed into blend files like images
Point Cache is a thin API, using Alembic as a backend
Different schema implementations (writer/reader) are created for the various DNA types and to handle interpolation (comparable to current PTCacheID )
Scene writer/reader ties everything together for exporting the scene as a whole, possibly using object hierarchy (flattening scene structure for export would also be possible)

Notes

Build instructions for Alembic and the development branch:

http://wiki.blender.org/index.php/User:Phonybone/PointCache/BuildNotes

Unsorted list of thoughts on Alembic implementation details:

http://wiki.blender.org/index.php/User:Phonybone/PointCache/InitialThoughts

Original dia file for the diagram: point_cache.dia

The goal of this project is to implement a new Point Cache system based on the [Alembic library ](https://code.google.com/p/alembic/) and unify the various caching methods used in Blender. This is a prerequisite for further work on particle systems. Having a working Alembic exporter/importer will also greatly benefit integration of Blender into larger pipelines. ### Current Issues * Point cache is used for most physics simulations, but does not include mesh caching. For this there is a separate [Mesh Cache modifier ](http://wiki.blender.org/index.php/Doc:2.6/Manual/Modifiers/Modify/Mesh_Cache), using mdd or pc2 file formats, with its own limiations. Using a unified point cache system would help scene management. * Alembic, unlike the current point cache binary format, supports arbitrary data attributes. This is very important for flexible simulations and user-defined data in particles and mesh data (vertex groups, [custom data layers ](http://wiki.blender.org/index.php/Dev:Source/Architecture/Custom_Element_Data), etc.). * Point cache is limited to fixed-size data sets. This is sufficient for many simulations which only deform geometry (cloth, hair), but for particles and constructive modifier caching variable point data sets are important. * Compression in the point cache file format leaves a lot to be desired. Alembic is specifically designed to have a small memory/disk space footprint and make good use of threading for fast export/import. * Point cache binary format is unique to Blender. While it is fairly simple to interpret, it does not facilitate import/export and integration into larger pipeline workflows. Alembic on the other hand is a commonly used tool and can leverage a large developer community. * Settings for caches are object-centric, each simulation writes its own separate cache files. Baking all caches is simply a loop over all objects, which is not very efficient. Having scene-level settings and operators would make Alembic export/import easier. ### Proposal # Keep basic cache settings on Scene level: - "Disk Cache" vs. "Memory Cache": This could be reframed as having cache file output by default and use ''packing'' in .blend files like we do with images. - Output directory setting for cache files (with nice defaults) - Frame ranges - Automatic cache recording settings (see below) # Optional overrides on object/sim level ``` If deviating settings are needed for individual simulation caches. By default it should not be necessary to tweak each cache individually. ``` # **Question**: How do we handle automatic caching? ``` Current approach is to automatically record point cache when stepping through frames, unless the cache is explicitly baked. This breaks easily when jumping over frames and or scrubbing in the timeline, because simulations need a contiguous ordered frame range for correct results. Does this work well enough to justify keeping it? Are there alternatives to this behavior? One suggestion was to make simulations independent from the animation playback by default, but this makes it difficult to sync simulation results to keyframe-animated objects and to record valid caches on-the-fly. ``` # **Question**: Do we really need multiple caches for each object? This feature adds a list of point caches for every object, only the active cache is used, the others are basically a version control system. Could this be moved to the scene level? The problem with this way of "versioning" is that there is really no way to roll back to a previous version, other than comparing the results without any way to revert settings. **Directory and File Names** How should directories and file naming work? Current naming scheme works per object and uses a combination of output directory + filename: - Directory is chosen in this order: - explicit path if specified by the user - or constructed as `//blendcache_<blend file name>/` (if .blend is saved and thus relative paths work) # or using a temp folder like `<tmp folder>/blendcache/` - File name is generated as `<basename>_<frame number>_<cache index>.bphys` - `<basename>` can be specified by the user or otherwise the ID datablock name (usually Object) is used - `<cache index>` is generated automatically by default (-1), but needed if multiple caches exist in the same ID block. **Frames, Times and Sample Indices** There are 3 different modes of interpreting "time" that need to be managed in a clean way: * Blender usually defines data in terms of **frame**. ``` Any notion of "time" is secondary, defined by the frames-per-second (fps) settings in the scene and additional start/end frames. Some simulations also add their own interpretation of time on top of this, by using time scale factors (e.g. [[ http://wiki.blender.org/index.php/Doc:2.6/Manual/Physics/Smoke/Domain#Generic_options | smoke sim time scale options ]]), although these factors are mostly for the internal simulation time step and don't have much consequence for mapping sample times. ``` * Alembic samples can be accessed - directly by an **index** (0..N) - or by using a **time** value which is mapped to a sample index based on a time sampling (see [Time Sampling overview ]], [[ https:*code.google.com/p/alembic/source/browse/lib/Alembic/Abc/ISampleSelector.h#47 | ISampleSelector class ](https:*code.google.com/p/alembic/wiki/AlembicPoint9UsersGuide#Time_Sampling)) While it would be possible to largely ignore time sampling for Blender cache files and simply read each cached sample as a frame, it is probably more reliable and flexible to calculate time values as defined by the scene render range and fps settings. This would allow using externally generated Alembic files which use a different sampling rate than the current scene and map them into the scenes frame range. Ultimately it could be very useful to integrate cached data into the NLA editor as a track. At that point the direct sample<->frame relationship that might still exist for cached data from the same scene is useless anyway. **Proposed Changes** * Output directory is by default specified on scene level, using the same rules as before. * Alembic cache files don't store files for each individual frame, instead one file for the whole cached frame range is used * 2 possible behaviors: - Each cached simulation/modifier creates its own file in the cache folder - Combine caches in a single scene cache file. ``` This is more in line with standard Alembic use, but makes it more difficult to cache objects separately ``` * In both cases identifier names for cache data are a problem. ``` This is already the case with current point caches: Renaming an object will sever the mapping to file names, leading to unused files on the disk and making re-bake necessary. ``` **Modifiers** Almost all cacheable data is located somewhere in modifier stacks, so these require some special attention. While caching the final result of mesh modifier evaluation (`final_dm`) is obviously useful, we also want to support partial caching and layered evaluation of mesh stages and simulation. **Proposal** * Add a "Point Cache" modifier for defining intermediate stages that can be cached. It would have almost no settings and just let users define fixed points, rather than caching every modifier (too much data) or relying on some heuristic of modifier "cost" to determine suitable stages. * By default there is one virtual Cache modifier instance shown at the end of the stack. This does not have to be a real modifier, but just reflect caching of the `final_dm` result. Caching can be disabled entirely by disabling this modifier. [*Is it preferable to leave this completely to the user and not do any modifier caching at all by default?*] | ![base_modifiers.png](https://archive.blender.org/developer/F121707/base_modifiers.png) Base modifier stack with cache | | ![cached_modifiers.png](https://archive.blender.org/developer/F121709/cached_modifiers.png) Modifier stack with intermediate caching | | -- | -- | -- | **Open Questions** * How to treat multiple successive cache modifiers? Can/Should this be prevented, or just ignore redundant instances? Similarly for caches at the beginning of the stack where they are useless. * Should these caches also handle internal data of simulation modifiers (smoke/fluid voxels, particles, hair, ...). Or do they only handle DerivedMesh caching and leave sim data to explicit cache instances elsewhere (physics tab) [*I would prefer the latter to keep design clean and avoid nasty corner cases*] **Caching vs. Export** These two cases may need to have somewhat different requirements in terms of necessary data attributes, sampling, etc. (while running the same backend input/output functions). * *Caching* is an internal procedure. The data being written only has to be interpreted by Blender itself (although the files would largely follow Alembic schemas where applicable). Some data attributes (e.g. normals) might be omitted here, since reconstructing them is fairly cheap. [*confirm?*] * *Export* is a one-way procedure to describe Blender data in a generic format for other software. All possible data attributes should be included to ensure compatible results. ### Implementation (*somewhat outdated*) ![point_cache.png](https://archive.blender.org/developer/F29943/point_cache.png) - Scene stores global settings for caching - Simulations and modifiers can have own settings if needed - Cache data is separate from other DNA by default, but can be packed into blend files like images - Point Cache is a thin API, using Alembic as a backend - Different schema implementations (writer/reader) are created for the various DNA types and to handle interpolation (comparable to current [PTCacheID ](http://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/BKE_pointcache.h;885354daec2fa8181aeb27b637c80e4ee4c247df$122)) - Scene writer/reader ties everything together for exporting the scene as a whole, possibly using object hierarchy (flattening scene structure for export would also be possible) ### Notes * Build instructions for Alembic and the development branch: ``` http://wiki.blender.org/index.php/User:Phonybone/PointCache/BuildNotes ``` * Unsorted list of thoughts on Alembic implementation details: ``` http://wiki.blender.org/index.php/User:Phonybone/PointCache/InitialThoughts ``` * Original [dia ](https://wiki.gnome.org/Apps/Dia) file for the diagram: [point_cache.dia](https://archive.blender.org/developer/F29958/point_cache.dia)

Lukas Tönne commented

2013-11-22 11:32:01 +01:00

Changed status to: 'Open'

Lukas Tönne self-assigned this 2013-11-22 11:32:01 +01:00

Thomas Beck commented

2013-11-22 16:07:07 +01:00

Added subscriber: @plasmasolutions

Jasper van Nieuwenhuizen commented

2013-11-23 14:16:55 +01:00

Added subscriber: @jasperge-2

Martin Lindelöf commented

2013-11-24 15:30:35 +01:00

Added subscriber: @MartinLindelof

Jayraj Kharvadi commented

2013-11-25 06:38:38 +01:00

Added subscriber: @JayrajKharvadi

Lukas Tönne commented

2013-11-26 17:18:29 +01:00

In my development branch i have now removed the point cache ListBases. As noted in the task description this feature does not add much value and it made the code unnecessarily complicated.

Older cache data is only useful for comparing to newer results, but one cannot actually revert to the previous settings just from the cache - for this you need to actually save a different .blend file version, which has its own cache anyway ... Such versioning functionality needs to be handled as part of the asset management or simply by making cache data backups outside of Blender.

The RNA code for accessing the point_caches collection was also causing recursion issues, basically the point cache contained a reference to itself, which is bad. Without the need to handle potential lists everywhere the code as well as the workflow becomes much simpler.

In my [development branch ](https://github.com/lukastoenne/blender/tree/pointcache) i have now removed the point cache ListBases. As noted in the task description this feature does not add much value and it made the code unnecessarily complicated. Older cache data is only useful for comparing to newer results, but one cannot actually revert to the previous settings just from the cache - for this you need to actually save a different .blend file version, which has its own cache anyway ... Such versioning functionality needs to be handled as part of the asset management or simply by making cache data backups outside of Blender. The RNA code for accessing the point_caches collection was also causing recursion issues, basically the point cache contained a reference to itself, which is bad. Without the need to handle potential lists everywhere the code as well as the workflow becomes much simpler.

Philipp Oeser commented

2013-11-29 13:17:11 +01:00

Added subscriber: @lichtwerk

Jonathan Williamson commented

2013-12-01 16:33:34 +01:00

Added subscriber: @JonathanWilliamson

Sebastian Brachi commented

2013-12-01 16:34:05 +01:00

Added subscriber: @Brachi

Bastien Montagne commented

2013-12-01 16:43:10 +01:00

Added subscriber: @mont29

Christian Krupa commented

2013-12-01 19:35:21 +01:00

Added subscriber: @krupa-2

Sayantan Chaudhuri commented

2013-12-02 09:16:23 +01:00

Added subscriber: @SayantanChaudhuri

Sayantan Chaudhuri commented

2013-12-02 09:20:32 +01:00

Removed subscriber: @SayantanChaudhuri

Jeffrey commented

2013-12-03 09:41:38 +01:00

Added subscriber: @italic

Lukas Tönne commented

2013-12-06 10:06:59 +01:00

I'd like point caches to works as unobtrusively as possible. However, in order to store a valid state of the simulation/modifier results and keep in sync with the user settings some rules need to be established.

The current scheme works like this:

When the cache is "baked" the simulation is calculated explicitly for the whole frame range. After that the user settings are locked superficially in the UI to indicate that they won't have any effect until "free bake", i.e. the cache is released.
Without a baked cache, the results are still calculated if a the frame range is walked through (animated with alt+a) in a valid order from the start frame onward. But any change to settings or a dependency (e.g. controller object) will invalidate the cache.
Starting caching on a later frame than the start frame doesn't work very well. The cache will store results from the current frame onward if invalidated, but then the results in earlier frames are useless. Sometimes the cache will not be properly invalidated once going back, i can't quite figure out when this happens. So it becomes a hit-and-miss affair which is not good. Better have a limited system with reliable results than a sophisticated machine that you cannot trust ...

I'd like to know if and how this system could be improved.

For a start, it's not really necessary to perform a full simulation over the whole frame range if the cache is already valid. Then we could have an option "lock/unlock" instead of the "bake"/"free bake" operators. What this means is that, when locked, a simulation/modifier will never perform calculations but try to read results from the cache. If no valid cache result is available for a frame this should be clearly indicated in both the property buttons and the 3D viewport (instead of misplaced particles/etc. like it often happens now).

Notice how "lock" refers to the simulation settings rather than the cache! It can be seen as a 3rd option in addition to completely enabling/disabling a simulation - expensive calculations are avoided and the simulation is treated as read-only data.

In addition to, and separate from this, there can be a "bake"/"full update" operator. What this does is simply run through the simulation frame range once to calculate correct results for every frame and cache them. This can be a scene-wide operator, since generally a simulation is calculated in relation to other objects, so there is no need to re-run this for every simulation on its own. Essentially this is a slightly modified "run animation" (alt+a) operator, which just runs through the frame range once instead of looping.

After performing this "full update" there will be valid results for every frame, so it makes sense to lock the simulation settings. But it's not necessary and could be left to the user. A clear indicator for "all frames cached" should help.

I'd like point caches to works as unobtrusively as possible. However, in order to store a valid state of the simulation/modifier results and keep in sync with the user settings some rules need to be established. The current scheme works like this: * When the cache is "baked" the simulation is calculated explicitly for the whole frame range. After that the user settings are locked superficially in the UI to indicate that they won't have any effect until "free bake", i.e. the cache is released. * Without a baked cache, the results are still calculated if a the frame range is walked through (animated with alt+a) in a valid order from the start frame onward. But any change to settings or a dependency (e.g. controller object) will invalidate the cache. * Starting caching on a later frame than the start frame doesn't work very well. The cache will store results from the current frame onward if invalidated, but then the results in earlier frames are useless. Sometimes the cache will not be properly invalidated once going back, i can't quite figure out when this happens. So it becomes a hit-and-miss affair which is not good. Better have a limited system with reliable results than a sophisticated machine that you cannot trust ... I'd like to know if and how this system could be improved. For a start, it's not really necessary to perform a full simulation over the whole frame range if the cache is already valid. Then we could have an option "lock/unlock" instead of the "bake"/"free bake" operators. What this means is that, when locked, a simulation/modifier will never perform calculations but try to read results from the cache. If no valid cache result is available for a frame this should be clearly indicated in both the property buttons and the 3D viewport (instead of misplaced particles/etc. like it often happens now). Notice how "lock" refers to the simulation settings rather than the cache! It can be seen as a 3rd option in addition to completely enabling/disabling a simulation - expensive calculations are avoided and the simulation is treated as read-only data. In addition to, and separate from this, there can be a "bake"/"full update" operator. What this does is simply run through the simulation frame range once to calculate correct results for every frame and cache them. This can be a scene-wide operator, since generally a simulation is calculated in relation to other objects, so there is no need to re-run this for every simulation on its own. Essentially this is a slightly modified "run animation" (alt+a) operator, which just runs through the frame range once instead of looping. After performing this "full update" there will be valid results for every frame, so it makes sense to lock the simulation settings. But it's not necessary and could be left to the user. A clear indicator for "all frames cached" should help.

Daniel Salazar commented

2013-12-09 04:14:54 +01:00

Added subscriber: @zanqdo

Daniel Salazar commented

2013-12-09 04:28:57 +01:00

Hi Lukas, I'm thinking this more from the character animation workflow than the simulation workflow. I think there can be 2 types of point cache: the manual persistent cache and the automatic disposable cache. This could create a solid difference between actual simulation cache and just playback stuff like frame-scrubbing a sim that can be easily recreated.

The disposable cache could be set to automatically cache even general animation data (from modifier stack) so that for example consecutive playbacks with a few heavy characters are greatly accelerated, only recalculating the needed parts or characters and completely skipping calculation of the rest.

The persistent cache is more like when you decide to bake and lock a character so that it becomes uneditable unless you decide to release the persistent cache, make some edits and maybe bake again.

The persistent cache can have the added ability of remapping the timing and other nice tricks.

Edit: I just read your last comment @LukasTonne, you're already planning some kind of locking behavior. Great, just hoping we can extend this concept to anything worth caching and not only to simulations.

Hi Lukas, I'm thinking this more from the character animation workflow than the simulation workflow. I think there can be 2 types of point cache: the **manual persistent** cache and the **automatic disposable** cache. This could create a solid difference between actual simulation cache and just playback stuff like frame-scrubbing a sim that can be easily **recreated**. The **disposable cache** could be set to automatically cache even general animation data (from modifier stack) so that for example consecutive playbacks with a few heavy characters are greatly accelerated, only recalculating the needed parts or characters and completely skipping calculation of the rest. The **persistent cache** is more like when you decide to bake and **lock** a character so that it becomes uneditable unless you decide to release the persistent cache, make some edits and maybe bake again. The persistent cache can have the added ability of remapping the timing and other nice tricks. Edit: I just read your last comment @LukasTonne, you're already planning some kind of locking behavior. Great, just hoping we can extend this concept to anything worth caching and not only to simulations.

Aditia A. Pratama commented

2013-12-09 05:35:02 +01:00

Added subscriber: @AditiaA.Pratama

bassam kurdali commented

2013-12-09 06:24:36 +01:00

Added subscriber: @BassamKurdali

bassam kurdali commented

2013-12-09 06:27:54 +01:00

Thinking from a project pipeline perspective: It would be invaluable at render time to render only caches, not rigged characters. Several advantages accrue:

Scrubbing for lighters is real time.
No matter the complexity of dependencies, links, rigs, lighting files are super reliable.

No issue with renderfarms with linking, Python scripts, drivers, etc that might require 'unsafe' setting to render correctly

Secondary thing that would be really cool is sculpting on caches, keying caches etc.

Thinking from a project pipeline perspective: It would be invaluable at render time to render only caches, not rigged characters. Several advantages accrue: - Scrubbing for lighters is real time. - No matter the complexity of dependencies, links, rigs, lighting files are super reliable. # No issue with renderfarms with linking, Python scripts, drivers, etc that might require 'unsafe' setting to render correctly Secondary thing that would be really cool is sculpting on caches, keying caches etc.

Jeffrey commented

2013-12-09 08:23:56 +01:00

I'm curious how this would play into final rendering, such as motion blur and sub-frame animation. I know it's possible to export a cache in sub-frame increments, but how motion blur will work is beyond me. Does Alembic have any provisions for this or will it be entirely up to Blender (or other software of preference) to interpret and interpolate between cache steps?

Lukas Tönne commented

2013-12-09 11:00:15 +01:00

@zanqdo: Yes, a form of locking could certainly be helpful to prevent accidentally losing cached data, combined with operators that calculate the whole cache to ensure it is valid in every frame. I just think that we need to keep the cache away from the simulations for the sake of design.

When the cache is "locked" it means it will not accept overwriting. The "full bake" operator can temporarily disable locking as part of an explicit user action. This is almost what the current "baked" flag means, the subtle difference being that we don't expect the cache to contain everything per se, although the operator would usually do a full calculation to ensure a valid cache state before locking it. It makes the code a lot simpler if we just view locked as a mechanism to prevent cache writes instead of making assumptions about validity in every frame. It would also be an internal cache feature, cache write attempts would just have no effect and locked does not have to be checked by callers everywhere.
To indicate the locked cache state in the UI we can disable buttons that would invalidate the cache, as it happens now when the cache is baked. Just be aware that it is difficult to make this absolutely watertight: Generally a simulation/modifier can depend on a lot of other things outside of it's own settings scope, like controller objects, other mesh surfaces etc. So this should be seen more as an independent feature of the sim (in self-contained character rigs it could work fairly well). The "bake cache" button could be made available in locked state as well, so you can re-bake the cache explicitly if you know external influences have changed and require a cache update.
Remapping time is again a feature of the cache user (sim/modifier/rig/...) and the cache itself should not need to know about it. I'll have to look into this closer to figure out how current NLA tools could do that. Perhaps such uses of cache data should be entirely separate from the original "cache creator", so you'd have one object that defines the setup and writes to the cache, and then any number of instances which can use the cache data read-only, do time remapping and so on. Otherwise i can see this becoming quite complicated when you have to always take into account what sort of timing a rig uses.

@BassamKurdali: I think this goes in the same direction as the last point above: Keep rig/mod/sim settings (collectively "cache writers") separate from instances ("cache readers"), which can add further modifications on top of the cached data (lighting, timing, materials, ...). I'll try to make a coherent design proposal for this.

Sculpting on cached data is a cool idea, which is only partially realized in "particle edit mode" so far. There are some tricky challenges though, like how to visualize the time domain in a meaningful way. When you compare it to regular sculpting: there you have a brush with some spatial extent whose effect can be shown all at once (all mesh vertices visible at the same time). But if you modify cache data at one point in time it's not so easy to show how this changes in the time dimension. "Ghost frames" are one approach, but it's most suitable for point data (like particles), i think it becomes difficult for use with surface geometry. Maybe there are proven solutions ...

@italic: Alembic does not do interpolation itself, but it is quite flexible in how it stores sub-frame samples. An Alembic file can have multiple different "time samplings", which usually relates to the frames. The standard would be 1-sample-per-frame, but we can add more fine-grained sampling next to it for fast moving objects that require detailed motion blur.

How this data is then interpreted for rendering etc. is up to Blender. IIRC our current renderers use spline segments to model the subframe motion of objects, which is good enough in most cases.

@zanqdo: Yes, a form of locking could certainly be helpful to prevent accidentally losing cached data, combined with operators that calculate the whole cache to ensure it is valid in every frame. I just think that we need to keep the cache away from the simulations for the sake of design. * When the cache is "locked" it means it will not accept overwriting. The "full bake" operator can temporarily disable locking as part of an explicit user action. This is *almost* what the current "baked" flag means, the subtle difference being that we don't expect the cache to contain everything *per se*, although the operator would usually do a full calculation to ensure a valid cache state before locking it. It makes the code a lot simpler if we just view *locked* as a mechanism to prevent cache writes instead of making assumptions about validity in every frame. It would also be an internal cache feature, cache write attempts would just have no effect and *locked* does not have to be checked by callers everywhere. * To indicate the locked cache state in the UI we can disable buttons that would invalidate the cache, as it happens now when the cache is baked. Just be aware that it is difficult to make this absolutely watertight: Generally a simulation/modifier can depend on a lot of other things outside of it's own settings scope, like controller objects, other mesh surfaces etc. So this should be seen more as an independent feature of the sim (in self-contained character rigs it could work fairly well). The "bake cache" button could be made available in *locked* state as well, so you can re-bake the cache explicitly if you know external influences have changed and require a cache update. * Remapping time is again a feature of the cache user (sim/modifier/rig/...) and the cache itself should not need to know about it. I'll have to look into this closer to figure out how current NLA tools could do that. Perhaps such uses of cache data should be entirely separate from the original "cache creator", so you'd have one object that defines the setup and writes to the cache, and then any number of **instances** which can use the cache data **read-only**, do time remapping and so on. Otherwise i can see this becoming quite complicated when you have to always take into account what sort of timing a rig uses. @BassamKurdali: I think this goes in the same direction as the last point above: Keep rig/mod/sim settings (collectively "cache writers") separate from instances ("cache readers"), which can add further modifications on top of the cached data (lighting, timing, materials, ...). I'll try to make a coherent design proposal for this. Sculpting on cached data is a cool idea, which is only partially realized in "particle edit mode" so far. There are some tricky challenges though, like how to visualize the time domain in a meaningful way. When you compare it to regular sculpting: there you have a brush with some spatial extent whose effect can be shown all at once (all mesh vertices visible at the same time). But if you modify cache data at one point in time it's not so easy to show how this changes in the time dimension. "Ghost frames" are one approach, but it's most suitable for point data (like particles), i think it becomes difficult for use with surface geometry. Maybe there are proven solutions ... @italic: Alembic does not do interpolation itself, but it is quite flexible in how it stores sub-frame samples. An Alembic file can have multiple different "time samplings", which usually relates to the frames. The standard would be 1-sample-per-frame, but we can add more fine-grained sampling next to it for fast moving objects that require detailed motion blur. How this data is then interpreted for rendering etc. is up to Blender. IIRC our current renderers use spline segments to model the subframe motion of objects, which is good enough in most cases.

Beorn Leonard commented

2013-12-09 16:13:25 +01:00

Added subscriber: @BeornLeonard

Martin Lindelöf commented

2013-12-09 20:40:50 +01:00

Removed subscriber: @MartinLindelof

sarazin jean francois commented

2013-12-14 12:47:08 +01:00

Added subscriber: @sarazinjean-francois

sarazin jean francois commented

2013-12-14 19:44:32 +01:00

Hello Lukas! When you ask :Do we really need multiple caches for each object? There is an important parameter, when we work with teamates, animators often overwrite pointcache for only a character, and render team sees updates in its scene. Would it be possible to do this if there is only one big cache file for the scene? Would it possible to link a character from a file, and a set from another file? And would it be possible to overwrite a file while someone else is reading it?

Lukas Tönne commented

2013-12-16 13:34:04 +01:00

@sarazinjean-francois: The "multiple caches for each object" refers to the list feature in every single object. This has very limited use and causes a number of complications in the code.

That being said, i like the concept of instancing cached data. I have outlined this a bit above, but needs to get a more precise design. Basically the current caches are very closely attached to the objects that generate them, making an object that works only as a cache instance is really cumbersome atm (requires using "external" caches and mismatching settings can easily break it).

Reading/writing cache files simultaneously should be as smooth as possible. I have to investigate the details of how Alembic files can be accessed more-or-less simultaneously, but generally it should follow a one writer / multiple readers model. Using the cached result of a writer in the same frame would be nice, the depgraph should enable us to let the writer finish writing the result in that frame before readers access it for instancing.

@sarazinjean-francois: The "multiple caches for each object" refers to the list feature in every single object. This has very limited use and causes a number of complications in the code. That being said, i like the concept of instancing cached data. I have outlined this a bit above, but needs to get a more precise design. Basically the current caches are very closely attached to the objects that generate them, making an object that works only as a cache instance is really cumbersome atm (requires using "external" caches and mismatching settings can easily break it). Reading/writing cache files simultaneously should be as smooth as possible. I have to investigate the details of how Alembic files can be accessed more-or-less simultaneously, but generally it should follow a one writer / multiple readers model. Using the cached result of a writer in the same frame would be nice, the depgraph should enable us to let the writer finish writing the result in that frame before readers access it for instancing.

sarazin jean francois commented

2013-12-17 00:04:44 +01:00

This writer reader thing seems great.

Instancing cache could be like image management. It sounds good to me. By the way, i think cache should be written with absolute frames, and not in seconds. Time management should be the software Task . I rather keep things simple, ie for compositing it is easier to work with images sequences, as soon you work with movie file you have some framerate issue between projects.

This writer reader thing seems great. Instancing cache could be like image management. It sounds good to me. By the way, i think cache should be written with absolute frames, and not in seconds. Time management should be the software Task . I rather keep things simple, ie for compositing it is easier to work with images sequences, as soon you work with movie file you have some framerate issue between projects.

Ghost commented

2013-12-18 01:31:21 +01:00

Added subscriber: @ErickNyanduKabongo

Lukas Tönne commented

2013-12-19 12:30:34 +01:00

@sarazinjean-francois: The "time" values in Alembic are not per-se seconds. We can also interpret the time values as frames (1 frame = time interval of 1.0) instead of scaling by the fps (1 frame = time interval of 1/fps). This can be changed fairly easily though, so we can have a look at what would work best for interchangeability (the ominous "industry standard").

Sergej Reich commented

2013-12-25 09:24:01 +01:00

Added subscriber: @sreich

Warren Bahler commented

2013-12-30 03:01:04 +01:00

Added subscriber: @WarrenBahler

Warren Bahler commented

2013-12-30 03:01:04 +01:00

I just discovered the point animation features in messiah studio.

would the task here bring blender closer to implementing functionality like this?:
http://www.usefulslug.com/messiah4/PointAnimationSmall.mov

this would make animation extremely powerful, especially for lip syc, muscle animation, small cloth effects and so on....

I just discovered the point animation features in messiah studio. would the task here bring blender closer to implementing functionality like this?: http://www.usefulslug.com/messiah4/PointAnimationSmall.mov this would make animation extremely powerful, especially for lip syc, muscle animation, small cloth effects and so on....

Daniel Salazar commented

2013-12-30 08:45:33 +01:00

@WarrenBahler Just so you know you can do this with the AnimAll addon

Warren Bahler commented

2013-12-30 14:31:54 +01:00

@zanqdo Wow, I didn't realize you can actually edit the mesh with Animall, very cool work, thanks

Alex Fraser commented

2014-01-02 23:59:16 +01:00

Added subscriber: @z0r

Bartosz Moniewski commented

2014-01-18 09:36:45 +01:00

Added subscriber: @BartekMoniewski

Nathan Mitchell commented

2014-02-11 21:12:55 +01:00

Added subscriber: @nmitchell

bassam kurdali commented

2014-02-11 21:47:15 +01:00

@WarrenBahler @zanqdo actually it's a good question: is there anything in the design above that would prevent sculpting directly on the cache (not on the underlying mesh) ? the diagrams don't show this but don't explicitly prevent it either.

Kévin Dietrich commented

2014-02-17 13:24:42 +01:00

Added subscriber: @kevindietrich

Will Nielsen commented

2014-03-17 02:34:45 +01:00

Added subscriber: @k9crunch

Mert commented

2014-03-17 15:09:20 +01:00

Added subscriber: @mrt3d

Florian Richter commented

2014-03-17 19:33:45 +01:00

Added subscriber: @FlorianRichter

Joss Smith commented

2014-03-23 12:12:17 +01:00

Added subscriber: @obadonke

andreas atteneder commented

2014-03-24 22:01:14 +01:00

Added subscriber: @andreas.atteneder

pyrochlore commented

2014-04-01 12:36:58 +02:00

(Migrated from localhost:3001)

Added subscriber: @pyrochlore

Robert Ives commented

2014-04-03 13:56:21 +02:00

Added subscriber: @RobertIves

boris cohen commented

2014-05-16 17:18:24 +02:00

Added subscriber: @boby

Max Hammond commented

2014-06-20 23:03:42 +02:00

Added subscriber: @MaxHammond

Karja Krähwald commented

2014-07-28 21:06:24 +02:00

Added subscriber: @karja

Manuel Rais commented

2014-08-19 11:12:37 +02:00

Added subscriber: @g-lul

Campbell Barton commented

2014-11-03 14:07:57 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-11-03 14:07:57 +01:00

Generally agree scene level baking is good so not much comments on what is written in the proposal.

Some feedback:

re: simulations independent from the animation playback by default - This seems fine to me. If you want real result you need to play from start or bake it.

re: Do we really need multiple caches for each object? - I think not, but its worth considering how/if we might use multiple alembic files per scene.

Other comments: ... questions infact!

Question: How to handle different resolutions from render/viewport - if you have subsurf - for example, set at different resolutions before the cache modifier, Bake for viewport display - but want to use for render.
Question: How to handle linked library data? (you make an animation on a character in another scene and want to link it in) -issue raised by Ton today.
Question: How to handle garbage collection (you have some data in an alembic file and the object gets removed).
Question: (relates to depsgraph and may not need to solve now), but what might be the workflow for using multiple alembic files on one mesh. maybe link-duplicate the mesh & rename.
Question: You already covered it mostly - but per simulation frame range vs global alembic frame range. (assume there would be some way to toggle between them).

Generally agree scene level baking is good so not much comments on what is written in the proposal. Some feedback: re: `simulations independent from the animation playback by default` - This seems fine to me. If you want real result you need to play from start or bake it. re: `Do we really need multiple caches for each object?` - I think not, but its worth considering how/if we might use multiple alembic files per scene. ---- Other comments: ... *questions infact!* - Question: How to handle different resolutions from render/viewport - if you have subsurf - for example, set at different resolutions before the cache modifier, Bake for viewport display - but want to use for render. - Question: How to handle linked library data? (you make an animation on a character in another scene and want to link it in) -*issue raised by Ton today.* - Question: How to handle garbage collection (you have some data in an alembic file and the object gets removed). - Question: *(relates to depsgraph and may not need to solve now)*, but what might be the workflow for using multiple alembic files on one mesh. *maybe link-duplicate the mesh & rename*. - Question: You already covered it mostly - but per simulation frame range vs global alembic frame range. (assume there would be some way to toggle between them).

Mohamad commented

2015-07-07 02:08:05 +02:00

Added subscriber: @MobyMotion

Mike Pan commented

2015-09-02 22:02:24 +02:00

Added subscriber: @MikePan

Wei-Cheng Sun commented

2015-12-06 06:32:00 +01:00

Added subscriber: @Wei-ChengSun

xueke pei commented

2016-01-11 09:38:27 +01:00

Added subscriber: @xuekepei

Manuel Grad commented

2018-05-27 11:02:33 +02:00

Added subscriber: @ManuelGrad

Sybren A. Stüvel commented

2018-06-12 18:02:59 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2018-06-25 11:15:05 +02:00

In #37578#189565, @LukasTonne wrote:
Reading/writing cache files simultaneously should be as smooth as possible. I have to investigate the details of how Alembic files can be accessed more-or-less simultaneously, but generally it should follow a one writer / multiple readers model.

Alembic explicitly does not allow changing an existing file, and from my experience does not even allow opening a file for reading unless it has been properly closed for writing (my hunch is that it writes some index only on closing). There are no provisions for simultaneous access, and writing to a file that's opened for reading will actually cause an exception (#51141). As a result, I have serious doubts about the usability of Alembic to replace the current Point Cache.

> In #37578#189565, @LukasTonne wrote: > Reading/writing cache files simultaneously should be as smooth as possible. I have to investigate the details of how Alembic files can be accessed more-or-less simultaneously, but generally it should follow a one writer / multiple readers model. Alembic explicitly [does not allow changing an existing file](https://groups.google.com/forum/#!msg/alembic-discussion/X-2ue86pw5g/Z2fZpW1eAgAJ), and from my experience does not even allow opening a file for reading unless it has been properly closed for writing (my hunch is that it writes some index only on closing). There are no provisions for simultaneous access, and writing to a file that's opened for reading will actually cause an exception (#51141). As a result, I have serious doubts about the usability of Alembic to replace the current Point Cache.

Julien Leménicier commented

2019-11-04 21:43:01 +01:00

Added subscriber: @lemenicier_julien

Maciej Jutrzenka commented

2019-12-31 01:15:45 +01:00

Added subscriber: @MaciejJutrzenka

Maciej Jutrzenka commented

2019-12-31 01:15:45 +01:00

Can we have also option of adding moddifier instance. and what it does it let's as choose... alembic file. it reads attribute like orient, Scale.. and we also choose what is the instance object. it can be collection or object. And that is how we could have instancing based on pointcloud. with is very very usefull.

Summarry:

ability to use attributes like orient/scale to drive instances.

Can we have also option of adding moddifier instance. and what it does it let's as choose... alembic file. it reads attribute like orient, Scale.. and we also choose what is the instance object. it can be collection or object. And that is how we could have instancing based on pointcloud. with is very very usefull. Summarry: - ability to use attributes like orient/scale to drive instances.

Sybren A. Stüvel commented

2020-01-02 12:33:46 +01:00

Changed status from 'Confirmed' to: 'Archived'

Sybren A. Stüvel closed this issue

2020-01-02 12:33:46 +01:00

Sybren A. Stüvel commented

2020-01-02 12:33:46 +01:00

@MaciejJutrzenka This is not the place to ask for new features.

I'm closing this task, as my concern about using Alembic for such caches hasn't been replied to in 1½ years.

Since Lukas did think about things and wrote down some designs, I do feel that this is still useful information, so I've added a link to my personal Alembic page on the wiki so that it's not forgotten.

@MaciejJutrzenka This is not the place to ask for new features. I'm closing this task, as my concern about using Alembic for such caches hasn't been replied to in 1½ years. Since Lukas did think about things and wrote down some designs, I do feel that this is still useful information, so I've added a link to [my personal Alembic page on the wiki](https://wiki.blender.org/wiki/User:Sybren/Alembic) so that it's not forgotten.

xueke pei commented

2020-01-03 17:51:07 +01:00

Removed subscriber: @xuekepei

jeremy bepoix commented

2022-04-22 09:59:58 +02:00

Added subscriber: @jeremybep

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Point Cache replacement based on Alembic #37578

Current Issues

Proposal

Keep basic cache settings on Scene level:

Optional overrides on object/sim level

Question: How do we handle automatic caching?

or using a temp folder like <tmp folder>/blendcache/

Implementation

Notes

No issue with renderfarms with linking, Python scripts, drivers, etc that might require 'unsafe' setting to render correctly

or using a temp folder like `<tmp folder>/blendcache/`