Issue link: http://digital.copcomm.com/i/1144162
52 cgw s u m m e r 2 0 1 9 multiple time samples as well as many different objects. An example of this is a complex truck as- set – four or more wheel shapes most likely will be very close to the same. They may share the same UVs and mesh topology, but have different point positions. The data doesn't even have to be of the same type to be shared; the sharing will automatically happen as long as the byte level represen- tation is the same. This data sharing greatly reduces the file sizes compared to tradition- al file formats. Another fairly unique feature of Alembic is that you only actually read data when you request it. This makes it very fast to open the file and sparsely traverse a large hierarchy within it, reading only objects and time samples as requested. This allows you to very cheaply open the file and read just the asset's bounds at a particular frame, without needing to read anything else about the file. Another popular example is finding out what cameras have been written to your Alembic file without needing to read any heavy geometry. Skipping over entire hierarchies is also possible, like in cases where you may not want to load certain shapes making up a character's costume. As Alembic was mainly created as a geometry interchange format, defining a solid list of primitive types and what properties make up those primitive types was very important. Equally important was making sure additional properties could be created on those primitives to support custom workflows. Examples include extra UV sets that you may want to feed to a custom shader at render time, or spe- cial custom pipeline data, such as what version of a content creation application wrote this Alembic file. CONTINUING THE PROGRESS Aer the official 1.0 release of Alembic in 2011, support by many of the content creation and rendering vendors grew fairly quickly, and today support is nearly univer- sal. Several of the popular game engines, such as Unity and Epic's Unreal, have also added support. This vendor support has helped Alembic grow beyond the initial film VFX industry in which it was first created and into other related industries, including television and games. Since the 1.0 release, Alembic has been continuously updated and supported. Many new features and bug fixes have been add- ed, with input from our open-source com- munity. The Google group alembic discus- sion (alembic-discussion@googlegroups. com) is the primary place to ask questions. With several hundred members, it is made up of a wide variety of artists, engineers, and other professionals in the computer graph- ics community. ALEMBIC MILESTONES There have been three major milestones that have added important functionality to Alembic. In the 1.1 release, schemas for materials were added. Although interchanging mate- rials between different packages is not yet a solved problem, there has been a lot of great work over the last few years toward this ef- fort. Alembic's customizable data definition will be able to represent whatever the com- munity eventually agrees on. Even without a universal solution, Alembic can still be used to store materials in a way that those appli- cations, which support the specified target, can load it; those that don't support it can just skip it but still load everything else. In Alembic 1.5, a new data backend named Ogawa was released. This was initial- ly created to address issues that had been found with Alembic's read performance across multiple threads. It actually helped all aspects of Alembic, as it led to smaller file sizes, moderately faster writes, and much faster reads. Finally, in Alembic 1.7, layering was intro- duced. Layering was developed collabora- tively between Blizzard Entertainment and Sony Pictures Imageworks and is a way for users to make sparse changes to an Alembic file by writing those changes into any number of other Alembic files, and then combining them all on read. This is useful for creating lightweight output from multiple departments and combining them together at render time. Modelers may create the initial static asset posed in a particular way. Texture painters may then need a specific set of UVs for the asset, and could create a sparse archive with just those UVs. Animators can create just the animated points and transforms without needing to rewrite anything else. Look de- velopment can create a layer containing the materials and assignments for the asset. All these layers can be combined at render time to create the final complete performance. Alembic has been an important com- ponent in modern visual effects pipelines, making it easier to share geometry be- tween departments and between compa- nies. Its read performance and scalability has eliminated a bottleneck and enabled the latest generation of tools to meet the complexity challenges of the latest anima- tion and visual effects films. n Lucas Miller is a soware engine at Sony Pictures Imageworks and is one of the co-founders of Alembic.