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.

18 comments 2,353 Views
  1. It all seems to make a lot of sense 🙂
    Look forward to see where you can take this, and what other more relevant people say.

  2. Looks great, thank you for the awesome work! The only ask I have is for Alembic to support more than one attribute so that when importing alembics from Houdini, I can use the point attributes on the mesh.

  3. Are there any plans for the USD Importer?

  4. What about:
    a) curve rendering (not working)
    b) not recognizing meshes if 1st frame does not contain one (.abc sequence)

    • a) That sounds like an issue of the importer, not the exporter.
      b) That sounds like something that should be supported. Please file a report about that.

  5. Hello Sybren,

    These changes all look good to me. I also have one more suggestion.

    Is it possible to provide an option to export hairs as a point cloud?

    The reason I am suggesting this is that in Blender we use hairs for instancing objects (like trees, grass, etc.) and point (emitter type) particles are used for things in motion. But, other 3D programs, like Houdini for example, use point clouds. And when exporting blender files containing hair instances to alembic, for say rendering in an external rendering engine, they expect a point cloud for instancing. In my case I used Guerilla Render, but I checked out the Clarisse documentation as well. It also expects a point cloud. (will let you know if I read about others as well)

    I am not sure about the details of the upcoming particle nodes and how instancing will be done then on. But, if we are to continue using hairs for instancing, I feel it’s a good idea to provide that option to export hairs as point clouds.

    • I think it’s an interesting approach, and it doesn’t sound too difficult to do either. Maybe this would be a good thing to look at once Blender has a new hair system.

  6. All changes makes sense to me.
    ———–
    “Names of Particle Systems
    spaces, periods, and colons in particle system names will also be replaced with underscores.”

    The above change will increase interoperability with other software a lot.

    Maya has a lot of limitations regarding special characters. Periods are converted to a long string of characters. Colons are reserved as suffix to namespaces.

    Houdini has less restrictions in object and node names AFAIK. I can have a look when the next time I’m front of a computer.
    ———–
    Object Instances

    Using “-” is a good idea, as it clearly defines the object as an instance.

  7. It’d be great to be able to export custom attributes. I was using blender to setup some test assets for katana the other day and had to switch to maya because I couldn’t export the custom attributes.

    • I agree that alembic should able to export custom attributes. Another issue is that currently alembic exported files from Blender, have their transformation matrix locked in other apps like Maya or Katana. This does not work this way with alembic exported from the other DCCs (3ds Max, Houdini, Maya) making the need for additional steps to be taken.
      Thanks for the great work and development of USD!

      • Martin, if you can provide more concrete information about these differences, please do!

    • I know this is an oft-desired feature, which is why it’s on the roadmap for Alembic. This blog post is about features that were already there before Blender 2.90, and how they will change, as such changes could break people’s workflow.

  8. The main issue I have with alembic export in Blender is that if you export a cache where either the vertex count or the vertex color changes from frame to frame, any vertex color is not correctly respected in the export result. It will be fine for the first frame and then degrade from there.

    This is a major bug for my needs, and is something handled correctly in any other app I’ve used that supports the Alembic format. Any chance that in these updates to the exporter, this can be addressed?

  1. Leave a Reply

    Your email address will not be published. Required fields are marked *

     

share this story on