OpenUSD

More Than a File Format

OpenUSD (Universal Scene Description) gets described as a file format often enough that the label sticks, but it undersells what it actually is. Where FBX or OBJ are containers for data, USD is a complete architecture: a data specification, a set of open-source software libraries, and an open ecosystem governed by an industry alliance.

The data format is a standardized specification for describing 3D scenes hierarchically - interoperability comes from the specification itself, not from ad hoc conventions between studios. The libraries are a full C++ API with Python bindings, plus tools for inspecting, validating and manipulating USD data, all open source. The ecosystem is the Alliance for OpenUSD, founded by Pixar, Adobe, Apple, Autodesk and NVIDIA, which governs the standard and coordinates its development.

USD was built at Pixar for internal production needs - scenes at a scale and complexity existing formats couldn't handle. It was open-sourced in 2016 after being proven on some of the industry's most complex productions, and adoption has been accelerating across the 3D industry since.

Prims, Stages and Layers

USD's architecture rests on three concepts that form a clear hierarchy.

Prim

The Prim (primitive) is USD's basic unit - any scene element: geometry, camera, light, material. Prims organize into a hierarchy with unique paths, similar to file paths: /World/Characters/Hero/Geometry/Body. Every Prim is typed against a defined schema (UsdGeomMesh, UsdLuxLight, UsdShadeMaterial), which is what lets any USD-aware application know how to interpret it.

Attributes are the typed properties attached to a Prim - they can be animated over time and hold simple values (float, string, matrix) or complex ones (arrays, relationships). Relationships express connections between Prims: material bindings, skeleton hierarchies, dependencies between elements.

Stage

The Stage is the unified view of the complete scene - the main entry point for reading USD data. It resolves and composes every layer into one coherent view, ready for viewing or rendering. The Stage doesn't store data itself; it's the result of composing all the layers that feed it.

Layer

A Layer is an individual USD file holding a set of opinions about Prims. The opinion concept is central: several layers can hold opinions about the same Prim, and USD's composition system resolves the conflicts by defined priority rules. Edits in one layer are non-destructive to the others - that's the mechanism that makes simultaneous multi-artist collaboration possible without stepping on each other's work.

Composition Arcs

Composition Arcs are how USD combines layers into a coherent Stage - they define how opinions from different layers merge and override each other.

References

A Reference pulls an external USD asset into the current scene. The source asset stays untouched; the Reference keeps a live link to it, and local overrides can sit on top without modifying the source. This is the core asset-reuse mechanism in USD: Character.usd defines a full character, Shot001.usd references it and adds shot-specific position, rotation and material overrides. When the modeling team updates Character.usd, every shot referencing it picks up the change automatically.

Payloads

Payloads work like References with one critical difference: loading is deferred until explicitly requested. A Payload isn't loaded into memory until something asks for it. For massive scenes, this is essential - distant or off-screen areas can be declared as Payloads and only cost memory when they're actually needed.

Variants

Variants define several alternate versions of the same Prim - LODs, seasonal variations, alternate states - without duplicating data. Selecting a variant is dynamic and can be driven by the pipeline.

Inherits and Specializes

Inherit lets a Prim pull properties from a separately defined asset class; changes to the class propagate automatically to everything that inherits it, which suits asset templates well. Specialize is a weaker form of inheritance, allowing selective overrides at lower composition priority.

File Formats: USDA, USDC, USDZ

USD ships in three file formats, each suited to a different job.

.usda (ASCII) is human-readable and editable in any text editor - the natural choice for debugging, learning the format, Git-based versioning and prototyping. Its cost is file size and read performance, which makes it a poor fit for production on large scenes.

.usdc (binary Crate) is USD's optimized binary format: fast to read and write, compact, not human-readable. It's the standard for production and runtime, and the format to reach for in any automated pipeline handling complex scenes.

.usdz (ZIP archive) packages a scene and every dependency - textures, materials, references - into a single uncompressed ZIP, chosen specifically because uncompressed ZIP allows fast random access to the files inside. USDZ is Apple's standard for AR on iOS, visionOS and Quick Look, and it makes distributing self-contained assets straightforward.

Advantages and Limitations

USD's advantages over traditional formats fall into three areas. Interoperability: as an open standard, data exchange between applications is standardized rather than convention-based - an asset built in Houdini and exported to USD opens in Maya, Unreal or Blender keeping hierarchy, materials and animation, within each application's own support level. Collaboration: the layer mechanism lets several artists work simultaneously on different aspects of the same scene without conflicts, each department on its own layer, composed automatically into one coherent view. Scale: deferred loading via Payloads, variants for LODs, and non-destructive composition through overrides let USD handle scenes that monolithic formats simply can't.

None of that comes free. The learning curve is real - Prims, Layers, Stages, Composition Arcs, Variants and Payloads are abstract concepts that take real training investment, and debugging a badly composed Stage can be difficult. Adopting USD in a studio isn't a software update: existing pipelines need adapting or rebuilding, custom tooling is often required, and migrating an established asset library has a real cost. Some parts of the standard are still maturing - skinning support in particular - and implementation varies between applications, so a workflow that works cleanly in Houdini can have gaps on import into Maya or Blender. For small, single-tool projects without a collaboration need, USD's overhead usually isn't justified.

Software Support

Houdini (SideFX) has the most complete USD support in the industry - the Solaris context is built entirely around manipulating USD Stages through LOP nodes, with a Hydra viewport that previews consistently with the final Karma render. NVIDIA Omniverse is built on USD from the ground up, adding real-time collaboration, RTX physics simulation and path-traced rendering with connectors for the major DCCs. Blender supports USD import/export for geometry, transform hierarchies, and basic cameras and lights, but material support stays limited and advanced Composition Arcs aren't exposed in the interface yet. Maya has an official USD plugin with progressively deepening integration, Unreal Engine imports USD Stages natively and interoperates with Omniverse, Apple's ecosystem treats USDZ as a native ARKit and Quick Look format, and Adobe Substance 3D exports materials to USD with MaterialX integration.

Houdini Solaris

Solaris is Houdini's dedicated USD context, built around LOP nodes (Layout Operators) that manipulate a USD Stage instead of raw geometry.

The typical Solaris workflow breaks into four stages: Import references assets or brings in SOP geometry through a SOP Import LOP, Layout positions and assembles the Prims, Look Dev assigns MaterialX materials, and Export produces the production USD files through a USD ROP. Combining Houdini's procedural workflow with USD's standardization is what makes it the default choice for complex VFX and animation pipelines.

MaterialX and USD

MaterialX is USD's natural complement for look development - where USD describes the scene, MaterialX describes materials in a way that's portable and renderer-independent. USD integrates it through the UsdShade schema: a material authored in MaterialX lives in an .mtlx file or directly in a USD layer, and gets bound to geometry through USD's standard binding mechanism. The result is look-dev portability that proprietary shading systems (VEX, RSL, OSL) can't offer on their own - a graph built in Substance or Houdini exports to .mtlx, gets linked to geometry via UsdShade, and renders correctly in any engine that supports MaterialX: Arnold, Karma, RenderMan.

USD vs FBX

USD makes sense for complex multi-tool productions, large-team collaboration, massive hierarchical scenes, and advanced MaterialX-based look dev. FBX still earns its place for simple, isolated assets, basic game exports, and legacy pipelines where backward compatibility is the constraint. USD is steadily displacing FBX in modern pipelines, but FBX isn't going away for simple exchange and legacy systems.

Resources

• OpenUSD documentation: openusd.org
• Alliance for OpenUSD: aousd.org
• PixarAnimationStudios/OpenUSD on GitHub: github.com
• MaterialX documentation: materialx.org
• SideFX Solaris product page: sidefx.com
• NVIDIA Omniverse: nvidia.com