利用者:Phonybone/PointCache/InitialThoughts

Point Caching with Alembic - Initial Thoughts

• Our old point cache system uses the concept of a PTCacheID. It holds mostly callbacks and flags and is used as a generic type struct to delegate interpretation of the data in a cache to the appropriate subsystem (particles, softbody, etc.).

This concept is mirrored in Alembic with the "Schema" (although in a much more sophisticated way obviously). Most classes in Alembic have 2 variants: one for reading point cache data (like ISchema, IPoints) and one for writing (OSchema, OPoints). We could try to make combined schemas that work for input and output at the same time, but it might be beneficial to keep these separate.

By defining a schema for all the current types of point cache users we should be able to convert point caches without requiring deep design changes in these systems:

• Softbody
• Particles/Hair(?)
• Cloth
• Smoke
• Dynamic Paint
• Rigid Body Sim

• Alembic differs from the current Blender point cache design in the way it stores point cache data.

Currently Blender objects store point caches in individual components of objects that make use of caching.

In terms of structure Alembic is supposed to work on the scene level. Each cache contains a hierarchy of "Objects" which in turn contain properties. I'm uncertain about whether or not such a scene-level approach would fit Blender design or if there are advantages/disadvantages to one of the approaches that force us to chose one of them.

It might also be possible to implement a hybrid system:

1. Per-object data for the purpose of point caching
2. Scene-level export/import for pipeline integration

• Currently a list of DNA PointCache structs is stored in all the cached types. I'm not sure about the value of using multiple caches per object, to me it seems not very useful, but maybe artists actually use it ...

Furthermore the RNA definition for these point cache lists is horrible: it defines a collection property inside PointCache, which leads back to the list of which it is a part - uagh! Presumably that was a lazy solution to avoid defining the collection in each of the point cache use cases ...

• The most used backend for Alembic seems to be the HDF5 file format as a quasi-standard for interchangeable files in pipelines. While having this option is great for import/export, it has a number of drawbacks according to Steve LaVietes' explanation on the ML. Using Ogawa for our point cache might be a better option in the long run, short of writing a complete custom file storage format.

Ogawa also has a stream-based constructor, which would make it easier to store the archive directly in Blender DNA, compare:

HDF5 WriteArchive class

Ogawa WriteArchive class