Issue link: http://digital.copcomm.com/i/1277231
26 cgw e d i t i o n 2 , 2 0 2 0 matters is the investment in tools and features whose goal is to make working with USD data easier and transparent. USD contains, out of the box, a suite of tools for working with USD and the various external formats that may feed USD, including: Binary and ASCII encodings. Fast, powerful preview and debugging tools. Tools for creating more USD. OPEN SOURCE, OPEN ARCHITECTURE Pixar had experimented with open source through its first open-source project: OpenSubdiv. With OpenSubdiv, we wanted to make sure that our vendors were all using the same subdivision algorithms that Ren- derMan was, so that artists saw consistent and reliable results across the pipeline. We were starting to see the value in changing from proprietary, closed soware, to em- bracing open source as a way to strengthen our technology and increase its longevity by turning critical parts of our toolset into shareable, openly available libraries that we hoped would become industry standards. With USD, we wanted to bring that same consistency and reliability to the compo- sition of the whole scene. However, unlike OpenSubdiv, USD rests upon the lowest lev- els of Pixar's 3D soware foundations, but the studio strongly supported the project by allowing us to incorporate Pixar's proprietary soware stack into (what we hoped for originally, and then committed to in 2014) an open-source project. For USD to succeed in its "universal scene interchange" goals, it is import- ant that 3D vendors adopt support for it natively, and it was clear that a well-sup- ported open-source project was the only viable way to foster that kind of adoption. Additionally, as we will discuss more below, sponsoring an open-source project that literally targets entire pipelines has been a fantastic opportunity for productive and enjoyable collaboration with many studios and vendors in the industry. Because USD needs to plug in to most applications in any given pipeline, a critical factor for its success is the degree to which it can be customized, without impacting the "common definitions" that enable interchange. Out of the box, USD comes with reasonable defaults for all "pluggable" behaviors, but by writing a little code (and in some cases, even without any coding), one can: Teach USD how to ingest new data sources. Use your own asset management system and "asset resolver." Add new schemas. As an example of how flexible these (and other) plug-in points make USD, Google was able to provide Draco mesh compression for USD entirely as a plug-in, by combining the powers of USD references and file format plug-ins. With the various USD technologies roughed in, it was time to plan their rollout both internally to Pixar and to the broader community. ROLLING OUT USD INTERNALLY AND PUBLICLY Finding Dory was targeted as the first project to adopt USD at Pixar. We did hit that goal, and Finding Dory became the world's first feature-length film with a USD-based pipe- line. The production also took on a significant re-thinking of the back end of the pipeline, taking on a pathtracing-first version of RenderMan as well as new lighting workflows. Given the rest of the innovations happening on that show, USD's rollout was relatively uneventful, exactly as we had hoped. In order to achieve a quiet rollout, we had a couple of tricks up our sleeves. The first is that we generated USD files along with our old format, TidScene, the latter files being the ones used for actual early production. Our QA department also built a tool, bcsys- tem, that would render a given shot twice – once with USD files (not yet made visible to production) and once with TidScene files. The renders generated by the TidScene files were ground truth and against which the USD files were compared. As long as the two renders were differ- ent, we kept fixing bugs quietly behind the scenes. The bcsystem tool not only tested the renderer, but the whole pipeline that got us to the final picture. Along with bcsystem, a fairly big-hammer black-box tool, we also had started amassing a big suite of perfor- mance and regression tests. Our teams are fiendishly fond of regression and perfor- mance testing, keeping track of dozens of metrics across thousands of tests. We wanted to make sure that our new pipeline was going to be built on soware that could produce better performance than the old. And the best way to make sure your so- ware stays fast is to measure it continuously. As we started getting renders that match perfectly, we grew more confident that we could switch the show over without negative- ly impacting our users. With a flick of an en- vironment variable, we switched Finding Dory to start using USD and never looked back. While we were rolling out USD on Finding Dory, we started reaching out to trusted partners in the industry, to whom we gave early cuts of the soware. Early partners like Luma Pictures, DNeg, and Animal Logic, and a little later DreamWorks, MPC, Rodeo FX, Weta, and many others provided valuable insight and use cases beyond our beloved enclave that ultimately led to making USD useful to so many in the industry. We chose SIGGRAPH 2016 as the event where we would officially push the "make public" button on the USD repository hosted on GitHub. We all gathered around a round table set up for one of our USD Birds of a Feather-style meetup with our small community at the time. We pushed the button right as folks started streaming in for the meeting. Once everyone was seated, we announced that USD is now public on GitHub. It was the culmination of much hard work for many of us on the team, and it was overwhelming to see the support and the enthusiasm that had already been garnered by that time. As of 2020, all geometry, shading net- works and bindings, rigid-body, hair- and cloth-simulation, and large-scale skeletal crowd animation travel through Pixar's pipe- line in USD. These different kinds of data will generally be in different files, for workflow reasons (and there may oen be multiple shading USD files for a single asset, again for workflow). However, being able to encode them all as USD brings great simplifica- tion and amplification of the power of our toolset – not just for ease of interchange, but also for leveraging a common language and debugging suite between departments and artists. Given the advent of MaterialX and USD's ability to consume and encode MaterialX networks, there may be a future where our shaders themselves will be expressed by standardized nodes in USD vs. custom shading nodes driven by in-house OSL and GLSL code.