Page MenuHome

Alembic: support instancing
Needs ReviewPublic

Authored by Sybren A. Stüvel (sybren) on Apr 7 2017, 11:50 PM.



@Kévin Dietrich (kevindietrich) I would love to have some quick feedback on this, as it's quite a major feature.

This patch introduces support for an Alembic feature: instancing

  • On export: for objects that share their data, the data is written only once. Subsequent writes reference the first object's data.
  • On import: mesh and camera instances are properly handled. Once the approach to handle those is fleshed out, we can add support for other types relatively easily.

I've attached a blend file that's suitable for writing instanced mesh data and camera data, but please also test with wild ideas of your own ;-)

NOTE: one thing I really should add is a check on the modifiers of the object. After all, we can't instance mesh data when the object has different modifiers, and this isn't taken into account in the current code. However, if there is anything else I overlooked, let me know ;-)

Diff Detail

rB Blender
temp-sybren-abc-instancing (branched from master)
Build Status
Buildable 528
Build 528: arc lint + arc unit

Event Timeline

The overall approach seems fine, though this makes me even more think that a proper hierarchical data-structure should be developed to handle conversions between Alembic's tree and Blender's linked list model. I just added some comments about the code style for now. We should really work on trying to have consistent code, especially consistent with Blender's code style guidelines.

I haven't tested the code yet, but I highly suggest you to make some experimental builds and post them to blenderartists to get tests made by the community. This feature is quite requested and the community will be more creative than I can when it comes to finding corner cases and bugs ;)


This naming convention for typedefs is rather confusing. Also map is absent from the name. There is no rule in Blender, but usually I go with the POSIX style, i.e. object_data_map_t. In the depsgraph, camel case is used, i.e. ObjectDataMap.

In any case, the m_ prefix should be reserved for member variables not types. Same go for other typedefs.


At some point we should unify the naming convention for method names. There was already some discrepancy in the patch before I took over it, but I want to move away from camel case. And there needs to spaces around assignment operators.




This doesn't seem to be used.