Changes to the Alembic Exporter

This blog post describes the intended changes to the Alembic exporter in Blender 2.90. Here Sybren Stüvel talks about these changes, the motivation behind them, and where feedback from the community is welcome.

Recently I have been working on a new Alembic exporter, in such a way that both Universal Scene Description (USD) and Alembic can be exported using the same code base. This makes the export of Alembic and USD consistent, which comes with a few changes.

Transform: to inherit or not to inherit?

In Blender, an object always inherits the transform of its parent. In other words, the transform of an object is computed by taking the transform of the parent object, and then applying the object’s own transform on top of it. In Alembic, this is not the case. An object can be the child of another object, without inheriting its transform. This is a per-object setting that can be turned on or off.

When exporting to Alembic, Blender 2.83 turns on this “inherits transform” setting only when the object has a parent. All other transform are marked “non-inheriting”.

Unless there are strong objections to this change, Blender 2.90 will simply always mark transforms as inheriting. This is how Blender works, and to me it makes sense to reflect that in the written Alembic files. More importantly, the Alembic plugin for USD only supports inheriting transforms and ignores non-inheriting ones. This change would make the Alembic files that Blender writes compatible with a USD-based workflow as well.

Names of Meshes

Let’s say there is a mesh object named Suzanne, of which the mesh is named MonkeyMesh. Blender 2.83 ignores the mesh name, and writes it to Alembic as “/Suzanne/SuzanneShape“.

The USD exporter will simply use the datablock name when exporting that datablock. That means that it uses the object name for the object and the mesh name for the mesh, exporting to “/Suzanne/MonkeyMesh” in the above example.

This is what the Alembic exporter in Blender 2.90 will do as well. In those cases where it is important to maintain the old naming, this can be done by changing the mesh name to the object name with “Shape” appended.

Names of Particle Systems

Almost all the data that is written to Alembic is using the same naming scheme: it takes the name from Blender and replaces spaces, periods, and colons with undercores. Particle systems are exceptions here: in Blender 2.83 their names do not go through this replacement of characters.

By switching to the approach used by the USD exporter, the Alembic files will be using a consistent naming strategy. That means that all names will undergo the same replacement rules, and spaces, periods, and colons in particle system names will also be replaced with underscores.

Note that this change is about applying consistent naming rules. The replacement of spaces, periods, and colons was part of the initial patch that brought Alembic support to Blender. Unfortunately, I have not been able to find any public definition of what forms a valid name in Alembic.

The Alembic source code seems to allow pretty much anything as name, but as always, this not only depends on the file format but also on the capabilities of the software that reads the Alembic files. The Maya exporter seems to only handle colons as special case, but this is of course related to what other symbols Maya does (not) accept in names. Feedback on this, or information on how other DCCs like Houdini handle this, is welcome.

Blender could be made more liberal in the allowed names as well, and also allow spaces or periods in the name. If you have more knowledge about this, either from format specifications or from studio workflow experience, please let us know in a comment.

Object Instances

When objects are instanced into the scene, the output of Blender 2.83 is sometimes hard to predict, and not the prettiest either. For each instance of an object, Blender 2.83 tries to write it to the Alembic file with its own name, but when this name is already used by a different object, it simply appends an underscore. This means that you can then have “Suzanne“, “Suzanne_“, all the way up to “Suzanne_________” if you have ten instances. When these instances are created by a particle system, it becomes even harder to know what is going on.

The USD exporter, and thus also the Alembic exporter in Blender 2.90, numbers the instances. The above example would simply produce “Suzanne-0” up to “Suzanne-10“. This also supports nesting, so when an instanced object itself also instances objects, it could result in a name like “Suzanne-7-9“.

Dropped unofficial support for HDF5

The Alembic format supports two compression methods: HDF5 and Ogawa. Ogawa is the newer of the two, is faster to read and write, and also produces smaller files. Blender has never officially supported HDF5, but there was a build-time option to enable the format for import & export. This has never been enabled in any Blender release, though.

After a short discussion, it has been decided to remove the unofficial support for HDF5 as of Blender 2.90. Recent DCCs will very likely already write to the Ogawa format, and older files can be converted with the abcconvert tool.

Conclusion

All the above changes are aimed at better consistency in the exported files, and at giving artists and TDs more control. Please let me know in the comments what you think about these changes.