Computer Graphics World

Edition 2 2020

Issue link:

Contents of this Issue


Page 25 of 67

24 cgw e d i t i o n 2 , 2 0 2 0 majority of commercial 3D vendors support Alembic import and/or export. Pixar did not adopt Alembic in its pipeline, primarily because from 2008-2010, we had been developing our own time-sampled interchange format, called TidScene, with a slightly different approach to the problem… but we're getting a little ahead of ourselves. REFINING WORKFLOW AND 'COMPOSITION' At around the time Ratatouille entered development, Pixar was growing hungry for revamping its toolset, which was beginning to show its age; not only was our anima- tion and lighting system nearly impossible to adapt to the multi-threaded future of performance, but our pipeline had also grown complicated. Any given shot relied on dozens of different file formats and data abstractions: We had one format for "primary" geometry, but another for UV sets and other primitive variables that were too big for the primary format, and a third for simulation-generated geometry overrides. We had one format and language for shad- ers, another for shading networks, and yet a third to describe how materials were bound to geometry. It was time to reconsider our tools, workflows, and pipeline. The Menv30 project was kicked off, later renamed Presto when released. Menv30 was an opportunity to take all the learnings of the earlier toolset and develop them into a cohesive and well-structured set of libraries. Perhaps most importantly, the project sought to represent all of our work- flows using a single file format, menva, in a single application that could easily allow artists to transition back and forth through a fluid and malleable pipeline. We started by targeting rigging, animation, and layout, later adding simulation workflows. To Presto's scene graph library, we added and refined all the features that were nec- essary to bring together all the disciplines and workflows that we had so far accumu- lated. The most fundamental feature was a layering system that is oen compared to Photoshop's image layering paradigm. Ref- erencing, inheritance, and variants complet- ed the initial set of composition operators that formed a robust composition engine, and which, unbeknownst to us at the time, began the underpinnings of the technology that would later become USD. We had initially targeted Toy Story 3 (and missed it) for early adoption of this brand-new ambitious system and knew it was going to be difficult to achieve. In order to make it more tenable, we stopped short of adding support for the back end of the pipeline: shading, lighting, rendering, and so on. That was going to be le to the existing systems. That meant: interchange. We now needed a way to translate data born in Presto to the existing back-end systems. In order to do that, we invented a new scene transportation system called Tid- Scene. TidScene was built using Berkeley DB and was primarily targeted toward efficient transport of time-sampled binary data and rapid preview imaging. As we began deploy- ing TidScene in more parts of the pipeline, we kept encountering the need to add more and more features to it, such as referencing and inheritance. Having TidScene meant that we were implementing things twice, as we kept wanting to add more features that we had already implemented in Presto. Worse, the implementations grew inconsistent and incompatible with one another. This became a significant enough prob- lem that a solution was indeed needed. The solution? USD. WHAT IS USD? USD began as an experiment in 2012 to see if we could take the low-level data model and "composition engine" at the heart of Presto, where it served a rich scene graph and anim curve-driven execution system, and build atop it instead a light, highly scal- able scene graph that practiced lazy data access, embraced time-sampled data, and facilitated the creation of "schemas" (think Mesh, Xform, Material, etc.) to foster robust scene interchange. Our proof-of-concept came very close to the performance of TidScene on equivalent large scenes, while opening the door to the full suite of Presto's composition operators (though we chose to leave out a few of USD for performance and/or complexity reasons). However, we believed we needed to be much more than an order of magnitude better than TidScene to satisfy the growing needs of the studio for the next 10-plus years. We made good progress toward that goal by making data structures thread-safe/ efficient and algorithms multi-threaded at all levels of the USD soware stack. The development of "native scene graph in- stancing" to augment schema-based point/ array instancing allowed us to load scenes containing millions of primitives in seconds on modern workstations. Performance has consistently been a top priority for USD, and we continue to make small and large improvements. But while performance is a key "wow factor" for USD that facilitates artists' ability to iterate, there are several other important reasons why USD has been so quickly and broadly embraced. COMPOSITION ALGEBRA If there is any magic in USD, it is the "com- position engine" that provides the ability to combine "layers" worth of scene description in many useful ways, and lets users make non-destructive edits. The rules by which this powerful combinatorial engine works have been refined over several different in- carnations, starting with work pioneered on A Bug's Life, and protected by more than a dozen patents that Pixar released for public use as part of open-sourcing USD. Understanding the full implications of the composition rules can be daunting, but Finding Dory became the first feature film with a USD-based pipeline.

Articles in this issue

Archives of this issue

view archives of Computer Graphics World - Edition 2 2020