How Pixar’s USD Sparked a Debate in AEC: What Can We Learn from Hollywood?

What is USD?

USD stands for “Universal Scene Description.” It is a set of libraries and tools developed at Pixar over the last 25 years to efficiently combine large amounts of time-sampled computer graphics data from multiple sources into a renderable scene description for animated movies.

The Legacy and Timeline of USD

USD is roughly the fourth generation of composed scene description developed at Pixar over 25 years (see official documentation).

1998 – Generation 1: Marionette

In Toy Story (1995), each shot was described by a single, linear program file. Afterward, Pixar’s R&D team began adding and evolving concepts for referencing, layering, editing, and variation in the context of its proprietary animation system, Marionette. This work started with A Bug’s Life (1998) and continued over the course of the next ten feature films.

2004 – Generation 2: Presto

By 2004, the studio committed to designing and developing a ground-up, second-generation animation system, now known as Presto, which was first used on Brave (2012) and all features since.

2008 – Generation 3: TidScene

In 2008–2009, the pipeline development team began building TidScene, a geometry schema backed by a binary database (Berkeley DB). A lightweight scene-graph served as the mechanism for authoring and reading time-sampled data.

2012 – Generation 4: USD

In 2012, the USD project officially began with the goal of merging Presto’s redesigned and improved composition engine and low-level data model with TidScene’s lazy-access, time-sampled data model and lightweight scene-graph.

2016 – USD Becomes Open-Source

USD was first published as open-source software in 2016, under a modified Apache license.

2017 – DreamWorks Adopts USD

“In spring of 2017, DreamWorks began using a new proprietary rendering software, MoonRay. It was then necessary to adopt a new scene description format in order to represent MoonRay scene objects (geometry, cameras, materials, etc.) that had no representation in the existing DreamWorks scene description format (ASG)… USD is also broadly extensible, making it a clear choice for a new scene description.” Source

Today

Today many different final-frame renderers support USD. Some popular examples include:

• Pixar's RenderMan

• Dreamwork's MoonRay

• Intel's OSPRay

• AMD's Radeon ProRender

• Autodesk's Arnold

• NVIDIA's Omniverse RTX Renderer

• Autodesk's Aurora Renderer

There is also limited support for USD in real-time engines:

• Unreal Engine

• Unity

Many different digital content creation (DCC) tools also support the generation of USD content, including 3ds Max, Maya, and Blender.

What is the USDZ File Format?

USDZ is an archive format for USD scenes. There is no formal USDZ specification, other than stating that it is an uncompressed ZIP package containing files consumable by the USD runtime.

The specification of data supported by USD is defined by the runtime.

A USDZ package can contain only file types whose data can be consumed by the USD runtime via , a pointer to memory, or threadsafe access to a . Allowable file types currently include:

• usda, usdc, usd files

• png, jpeg, OpenEXR, and AV1 Image (AVIF) files for images/textures

• M4A, MP3, WAV files for embedded audio

Note that there is no separate, written specification for USDA, USDC, and USD files. The source code is effectively the specification.

In other words, for developers to use USD, they must compile the official USD libraries from source or use prebuilt binary versions of the libraries. NVIDIA provides these binaries here.

What Is the Impact of No Formal Specification?

Without a formal specification, a developer must rely solely on the reference implementation and developer documentation which makes it difficult to develop additional compliant implementations of USD. It becomes a constantly moving target without a clear path to measure or verify compliance.

One major consequence is that adding support for new platforms and languages (e.g., WebAssembly or “WASM”) can be challenging because the entire toolchain must be ported. As a result, most tools that consume or produce USD data are built upon the same Pixar/OpenUSD source code.

There is at least one other active effort to create a standalone implementation: TinyUSDZ, which has a non-trivial amount of support for USD.

Looking Ahead: Hope on the Horizon

The Alliance for OpenUSD (AOUSD) recognizes the importance of well-defined, unambiguous specifications:

“Having well-defined, unambiguous specifications for the foundations of OpenUSD will empower AOUSD members and the entire ecosystem to interoperate with confidence and clarity.” – AOUSD Blog (July 25, 2024)

It is still early days for the Alliance, and several working groups are in the process of developing their charters (more info).

Web Support for USD

Because reading the USDZ format depends on the USD runtime, written in C++, and because WASM is not currently a supported build target, there is no official or reliable support for USD in web browsers.

Some existing efforts and options:

• Autodesk began a research project (now on hold) to add USD support in the browser.

• TinyUSDZ (in BETA) can be compiled to WASM, offering a limited USDZ loader in browsers.

• Converting USD to glTF via Google’s archived project. (Note: This is unsupported.)

• Unity has experimental USD support, which could be used in a web context.

• NVIDIA Omniverse bypasses the need for in-browser support by using pixel streaming.

Why Is USD of Interest to AEC Professionals?

Ultimately, the output of USD is focused on generating a scene-graph for a Hydra delegate—i.e., a renderer supporting the USD Hydra rendering API.

Pixar’s USD pipeline is designed around the needs of film production: geometry, animation, effects, lighting, materials, and shading.

In AEC, however, data needs differ significantly:

• Specifications, quantity take-offs, schedules, standards compliance, cost estimates, operating parameters, floor plans, construction documents, change orders, RFIs, safety logs, and billing are just a few examples.

Rendered visuals (e.g., high-end animations) play a relatively smaller role compared to the enormous amount of other project data.

Still, there are some parallels between AEC and film pipelines:

• Large, complex datasets

• Multiple data formats

• Different authoring tools

• Stakeholders working with different subsets of the data

• A desire to aggregate all of this data into a single, usable view

Composing and Layering of Data

USD’s strength lies in a hierarchical composition system, which expresses relationships between scene data in a flexible and extensible way and resolves complex datasets predictably.

I found that the following key terms (from the glossary) are helpful for understanding the value proposition of the USD scene composition engine, and the documentation that comes with it (which is very developer-centric).

• Assets – A file or group of files identified or located using a string identifier

• Assembly – A grouped model, usually identified as a published asset

• Attribute – A property type that can have a distinct value at any point in time

• Component – A leaf model

• Composition Operators (“Arcs”) – SubLayers, Inherits, VariantSets, References, Payloads, and Specializes, used to mix base scene description with overrides

• Group – Models that aggregate other models into meaningful collections; can contain subgroups

• Layer – The atomic container of scene primitives

• Model – A label for primitives that helps partition scenes into logical chunks

• Primitive (“Prim”) – A primary object in the hierarchy that may contain other Prims and properties

• Properties – Contain scene data for a Prim; can be an Attribute or a Relationship

• Relationship – A namespace pointer to one or more objects in the hierarchy, resolved by the USD runtime

• Stage – The USD abstraction for a scenegraph derived from a root USD file

Appeal of USD for AEC

The appeal of USD as a composition engine for AEC professionals, which is similar to artists in a film production pipeline, is:

• A common language for primitive objects and common concepts (e.g., meshes, transforms)

• A consistent way to express how data is grouped or overridden

• A toolset for quickly visualizing composed data as it changes

• The ability for multiple contributors to work independently on the same asset via layered overrides rather than duplicating or overwriting data

This last point, is I believe what resonates most strongly in AEC. The idea that engineers and architects can collaborate on “built assets” without duplicating data or stepping on each other’s changes is extremely compelling. A BIM model expressed in layers and composable data sources—rather than a single file passed around—could be transformative for design and construction workflows.

Final Words

Many AEC technologists look at film production pipelines with admiration. Studios like Pixar or DreamWorks can wrangle massive and complex datasets on tight schedules, largely because they control every tool, format, and platform in the workflow. As a software developer, that level of control and consistency is appealing.

However, the AEC industry is different. While film production outputs data (pixels on a screen), AEC outputs physical structures—timber, nails, bricks, mortar, and even the literal movement of soil. Coordinating thousands of individuals from dozens of professions, each using different tools, leads to complexities that go beyond data composition.

Still, USD’s approach to layered data and composable workflows offers insights. If you’re developing AEC software, there’s a lot to learn from how Hollywood solves large-scale data challenges—just don’t forget that what works seamlessly for movie pixels may need significant adaptation before it can drive real-world construction projects.