Last Siggraph (2010 LA), a news conference was called to announce a new interchange format. SPI and ILM took to the stage to launch a modeling format that wasn’t FBX, wasn’t OBJ and wasn’t yet released. Now some 6 months later we speak to Rob Bredow, CTO of SPI, to find out what happened to it.
Alembic is an open interchange framework for passing models around at a certain key stage in production. Alembic distills complex, animated scenes into non-procedural, application-independent, baked geometric results. This distillation of scenes into baked geometry is very much like a snapshot container that holds say simulation results but not the simulations themselves. This is not a replacement for FBX which would allow the modeling and animation to move from place to place, but rather an interchange format to allow the animation done thus far to move down the pipeline – even if that is someone else’s completely different pipeline from your own.
Say you wanted to make a tidal wave animation between two offices of a large company halfway around the other side of the world from each other. The Californian facility could run the simulations and store all the sim data, while just passing a much smaller but fully valid computed simulation to the team in Singapore to light and shade. Or perhaps you have developed a complex facial rigging system and want to hand the animation onto someone else to include in their animation. Alembic in both cases does that seamlessly, but without having to export all the sim or animation rigs, and in one well maintained container – rather than hundreds of individual files.
Alembic is focused on efficiently storing the computed results of complex constructions. It is very specifically NOT concerned with storing the complex dependency graph of procedural tools used to create the computed results. For example, Alembic will efficiently store the animated vertex positions and animated transforms that result from an arbitrarily complex animation and simulation process, one which could involve volume-preserving simulations, cloth and/or flesh simulations, and so on. Alembic will not attempt to store a representation of the network of computations (rigs, basically) which were required to produce the final, animated vertex positions and animated transforms.
Alembic does not fight other formats, rather ILM and SPI both simultaneously got themselves to a point of realising that this was needed, and figured “it was going to happen”, so they joined forces to make it happen in a way that was of the most use to the industry and as standardized and extensible as possible. The closest thing to Alembic so far is OBJ. While an Alembic could contain an OBJ of your character – as it does at SPI – it is not designed to swap character rigging. But if you have finished the character (baked the rig & animation), you have done the cloth sim and you want to pass on multiple models per frame (for motion blur), Alembic is the container you would place those baked character, cloth and/or fluid simulation animations in.
Alembic is to OBJ what DPX is to Cineon. It is a more robust, yet extensible and flexible container, but it is a lossy format – it is designed to be that, it is designed to be a snap shot that can be passed along and not a data asset management system of everything, or a dependency graph, nor a procedural data transformation tool, or a replacement for native application scene file formats.
Richard Kerris, CTO Lucasfilm, and Rob Bredow, CTO Sony Pictures Imageworks, lead the charge but Autodesk, The Foundry, Luxology, NVIDIA, RenderMan at Pixar and Side Effects all joined Kerris and Bredow at the press conference to give the new format their blessing and support. ILM has long committed to open source as OpenEXR demonstrates and SPI has really dramatically extended its commitment since Bredow took over as CTO.
So what happened to it?
Alembic is completely alive and well. It is just taking a little longer to get right than anyone expected, but this is because both ILM and SPI are aiming to get it right. Actually the work between SPI and ILM is quite transparent, there is a Google group and the team is keen to be as open as possible, yet Bredow knows only too well that for many users they are looking to see this move from specification and in-house testing to the application vendors so that the everyday users and other facilities can deploy it, in their own respective pipelines.
“…but we have not heard anyone complaining yet that we should do it faster and less good”
The software is now at version 0.9. Bredow says: “The delay has not been with the partner companies (ed: such as Autodesk/Foundry/etc). Right after Siggraph we started putting all the hard work that had been done at ILM and SPI with our respectively baked geometry formats. We started putting that together and it turned out that we each liked some of the work that the other had completed, but it wasn’t just a simple matter of putting the two pieces together and out it came a month later, it took a lot more work than that, more work than we had anticipated. We all thought we would be at 1.0 release by now, but we have not heard anyone complaining yet that we should do it faster and less good! I think it is important to get this right especially if this does what we all think it will and becomes a nice interchange format not only between say two departments within one building, but two departments in different countries or two different companies.”
Alembic, like OpenEXR, is extensible and allows a host of data to pass along with the baked animation. “Alembic is very extensible”, says Bredow. “In fact, of a lot of the work of the last few months has been designed around making sure that the basics are well covered, so everyone treats a point the same way, and everyone treats a normal the same way in every piece of geometry. So that part is well defined, the basics are well defined, but the Alembic API has several different levels and at the low level you can create an entirely new geometric privatives, you can add arbitrary attributes, you can add as many UV sets as you want, you can have velocity, temperature, you can make up new parameter types at will which makes it a very useful format for going from say an effects pipeline, where temperature might be important for your particle system, to be able to pass that information on to your renderer inside your Alembic.”
The Alembic team has been working closely not only with ILM and SPI, but most of the major facilities including the London houses, and many others. Version 1.0 has no concrete release date, but it is expected to be released well before Siggraph this year. “We are working really hard to get the 1.0 release out,” says Bredow. “We have the Nov. 0.9 release on the web site and we are working hard to do performance testing, meeting our performance metrics, et cetera. Anyone who wants to see what is going on – you can go to www.alembic.io. ”
fxinsider full interview