I often hear about FBX being compared to Alembic. I will try in this post to clarify this comparison and share some insights.
FBX, a 3D file exchange format, was first published by Kaydara and stands for FiLMBox exchange. FiLMBox has since been renamed MotionBuilder and Kaydara has been acquired by Autodesk… FBX`s mission came in 3 points :
- To allow 3ds Max, Maya and Softimage 3D (before XSI) to receive motion capture data made with FiLMBox.
- Exporters were then developed to allow the export of rigs and geometry into FiLMBox.
- Exchange 3D information across DCCs (without stopping by MotionBuilder)
FBX supports geometry (vertices, NURBS and patch), materials, texture, deformation, animation, constraints and IK and is extendable by 3rd party.
Is a format similar in purpose, use and feature set to FBX. It was developed by Feeling Software (now Fortem) and is now supported by the Khronos group. Anything I say about FBX in this post only is also good for Collada.
Alembic is a point cache format. It bakes any rig, constraints, deformation to the vertices and save them as is. It has a mechanism to instantiate copies and minimizes memory spending.
“ALEMBIC is an open source exchange format that is becoming the industry standard for exchanging animated computer graphics between content creation software packages.”
OK. That’s a bold and misleading statement! The standard for which industry?
It has to be the “Computer graphics for the film industry”. The key to understand is right in the “What is Alembic” section.
Alembic Is Not…
- …A dependency graph, nor a procedural data transformation tool
- …A replacement for native application scene file formats
- …An asset management application
- …A general rigging storage solution
However, FBX and Collada are attempting to support the above. This explains the introductory apple to orange metaphor.
Alembic is Not… FBX or Collada!
For the record, FBX/Collada do an honest job at supporting everything as much as possible. This bring them a lot of undeserved anger – I’m going to talk about that soon.
I figured I could explain a little bit how the industries using DCCs work differently.
The artist creates assets, levels in a DCC and these are used in the game engine. Because the development process is iterative and that everyone’s work is put together on the test environment, the visuals in the DCC viewport are preferably the same as the game engine, including the deformation, constraints, IK, etc.
architecture visualization industry
render: Delta Tracing
The artist needs to produce imagery in the DCC based on imported assets from architectural software such as AutoCAD, Revit, SketchUp, etc. The architect tends to keep updating their assets and the visualization artist tend to try to keep their pipeline simple in order to accommodate (manual) change. Alembic could be used for one-shot high-end visualization (à la Neoscape) requiring the data to be tossed to another tool for lighting and rendering .
Alembic will do a fine job provided that no one else need to play with the rig, constraints and animation. Game cinematics can benefits from Alembic as well.
Bottom line, Allembic is
- A well suited interop format when you can separate the rig works from the other processes of a production, like in movie making.
- Not replacing general purpose interop formats such as FBX or Collada.