From BlenderWiki

Alembic stuff

Alembic-related info / links

Here's what I've gathered from various sources.

• Alembic homepage
• The Alembic Python documentation is actually better than the documentation on Alembic itself.
• Alembic Github; Python examples were removed for some reason in commit 098e968c6657de00a90c637663966b9913aab07a, so check out 098e968c6657de00a90c637663966b9913aab07a~1 to read through them.
• Blender 2.8 data flow overview.
• We're going to keep Y=up for Blender-generated Alembic files for now, and add user-specified up/forward axes later.
• D1783 - the original patch introducing Alembic support.
• Blender Artists discussion about Alembic support.
• Simple Alembic pipeline
• "xform" is short for "transform"
• Alembic requires C++11, unless you pass -DALEMBIC_LIB_USES_BOOST=ON or -DALEMBIC_LIB_USES_TR1=ON to CMake.
• The Alembic Exporter seems to handle modifiers as if it's rendering, so only modifiers that are render-enabled will be exported.
• There is a Google wiki with more info about Alembic.

Other stuff

• Blender 2.8 Scene layer data model

Kévin Dietrich

• Did a lot of work on Alembic support in Blender.
• Private branches on Github contain more work which he might merge in the coming months.
• Says "Alembic::IMaterial is [...] not for materials but for lights", which is good to know.

Alembic in 2.79

To make Alembic import/export usable in 2.79, I focus on major issues with animated meshes, which are likely to pop up in an animation studio pipeline. Estimated time to finish is rounded up to half days and indicate best-case scenarios.

Progress	Problem	Description	Estimated time to finish
done	Bugs in coordinate transformation	Fixed Y-up in Alembic vs. Z-up in Blender
done	Bugs in transformation import/export	Fixed world vs. local matrix bugs; fixed writing proper "inherits transform from parent" properties.
done	Importer guessing too much, too fragile.	Fixed by simplifying code.
done	Don't crash on importing Alembic files with unknown data	Is now logged and otherwise ignored.
done	Export shared object data as Alembic instances.	Implemented for mesh & camera data. We may want to automatically switch this off if different objects have different deformation modifiers.	½ day to switch off in case of modifiers
done	Support dupli-groups	Dupli-groups are exported (limited: see note 1 below), import needs work. T50688	1 day to handle grouped objects also in the scene; 2 days to support import; ½ day to not write group at all when it's only duplicated once.
done	Location issue	T50403	½ day rough estimate
in progress 0%	Velocity / motion blur	Imported Alembic geometry doesn't do motion blur T49234. Kévin is working on this in D2388	Not for Sybren at the moment
to do	Don't store custom bone shapes	Bone shapes are exported as geometry when they are part of a dupli-group (the entire group is stored in Alembic).	½ day to not export group contents on invisible layer
in progress 0%	Read & write custom properties	It's technically possible to store ID properties in Alembic files, but we need to determine proper way to do this T50725	1 day rough estimate
to do	Material issue	It should be straight forward (for the artist) to reconnect Blender materials after importing an Alembic file, especially if that file was produced by Blender T50757	2 days
done	UV map issue	UV maps seem to get lost on import T50227	2 days
done	Hair very slow	Writing and loading hair systems is very slow, since all (parent + child) hairs are converted to curves.	needs more research
to do	Be able to export/import animated Agent 327	Needs work, see below

Notes: 1. Dupli-group export assumes group contents are not in the scene, i.e. only the dupli-objects are. If the group contents themselves are also in the scene, at the moment they are written twice. Import is not supported yet.

TODO for Agent 327 export:

• Don't export dupli-object as instance + dupli-group when it's only instanced once in the scene; just treat as normal object.
• Address Material, UV-map, and hair performance issues.

Alembic in 2.8

Integration with the 2.8 branch implies that we can use Collections to define a mapping between objects in Blender and information in an Alembic file. Until collections are fully implemented, we use the active SceneLayer to define this mapping. Since this collection is saved in the blendfile it should be easy (for an artist) to re-export changed data to Alembic, or to switch between showing "real" data and loading from Alembic.

Possible features

• Set of objects to export to / import from a file == collection
• Export multiple collections in parallel, so that the timeline only needs to be iterated once (idea by Jason Schleifer).

User Stories

Animator: Hjalti has finished animating the first revision of shot "07_03_B-gun_kick", consisting of two animated characters Agent and Boris, an animated camera, and some animated props. He wants to send it to Andy for shading & lighting. To make the file lighter for Andy to work with, he exports Boris, the Agent, and the animated props to 3 separate Alembic files. Each file is linked to a collection, so he performs the following actions:

• Hjalti selects the collection "Boris"
• He double-checks that the modifier stack is suitably set up
• He clicks on "Bake to Alembic".
• Blender exports the Alembic file, and switches the collection from "Live Animation" to "Loaded from Cache" after the export is complete.
• Hjalti repeat those steps for "Agent" and "Props".
• He can scrub through the currently open blend file to inspect the result of the caching.

Shading & Lighting artist: Andy gets poked by Hjalti that he has finished shot "07_03_B-gun_kick".

• Andy loads the lighting file for that shot.
• He imports the three Alembic files "Agent", "Boris", and "Props".
• Blender creates three collections for these files to record the relation between Blender objects and Alembic files.
• Since Alembic fiels do not contain Blender materials, Andy re-attaches the materials to the objects.

Issues with current Alembic export

Based on interview with Andy Goralczyc. Solutions could lie both in implementations / fixes for 2.79 as well as 2.8.

• Exporter options are unclear:
  • What does "Use Subdivision Schema" do? What effect does it have on the exported mesh?
  • Which subdivision modifiers are disabled when "Apply Subsurf" is turned off?
• Unclear what is taken into account by the exporter and what isn't:
  • Modifier stack (deformations, subdivisions, etc) -- up to which modifier is exported?
  • Modifier stack: are viewport-enabled or render-enabled modifiers used?
  • Simplify: are viewport or render settings used?
• It would be nice to be able to configure export options per group object / character / Blender 2.8 collection
  • What is exported (i.e. what is in the collection)
  • Which modifiers are baked to the modified mesh
  • Which modifiers have to be applied after importing the Alembic file
• Some things that need to be checked:
  • Shutter Open/Close options need clarification

Generic brainstomings

Regardless of 2.79 or 2.8.

Export mesh + deformations + hair/particle systems should work reliably and in a cross-software manner, i.e. adhere to the schemas defined by Alembic itself. This includes:

• The mesh itself
• Hair curves
• Particles
• Object transformations

All of the above information is stored per timekey, so the mesh isn't stored as "mesh + deformation per timekey", but actually as the full mesh per timekey.

The mesh export may contain Blender-specific information. This would thus not be understood by other software, unless they explicitly implement support for it.

• Multiple UV maps
• Vertex groups, including weights
• Material names, possibly as "//path/to/matlib.blend/Materials/Materialname"
• Property overrides? Maybe material names should also be implemented as property overrides?

Idempotence

Blender and Alembic structure data differently:

• Blender: object (contains transformation matrix) has explicit pointers to data (like mesh, hair systems, etc.)
• Alembic: Xform object (containts transformation matrix) simply has children. Such an Xform could have come from a single Blender object-with-data (including multiple children, like mesh + curve collection for each hair system), but it could also come from a parent relation (for example, an empty, or a rig that wasn't saved to Alembic itself).

How an Alembic Xform object is imported into Blender is dependent on its children, and cannot always be mapped to the same Blender concepts it was generated from. Here are two examples:

• Rigged mesh: once a mesh object that is parented to a rig is exported, the rig becomes an Xform, the object becomes an Xform, and the mesh becomes a PolyMesh. When importing, the former Xform becomes an empty, and the other becomes a mesh object.
• Hair systems: A single mesh object with two hair systems is exported as an Xform with three children (1x PolyMesh + 2x Curves). When importing, it may become an empty with three children (mesh object and two curve objects).

For these reasons, exporting to Alembic and then importing is not an idempotent operation, and will produce different results. Exporting and importing again will again produce different results.

Nice-to-have

Currently the Alembic file is always written with Y=up and X=forward, to be compatible with other software. In the future this may change, in which case the artist can choose different orientations. Profiling should show how important this is, as reading from a file that has the same coordinate system as Blender itself may be faster and thus preferable in a Blender-only pipeline. However, this should be weighed against the burden of additional choices, UI elements, and differences between files. Alembic does not store the used coordinate system (nor the used units) in the Alembic file; we can choose to define our own keys to store this information for ourselves, so that at least Blender can auto-detect the coordinate system and unit sizes of Blender-written files.