← BlogPhysical AI Basics· 2/5

OpenUSD Scene Composition — Assembling a World with Layers, References, and Payloads

USD is not a single 3D file format — it is a non-destructive layer-compositing system. How the same asset can be reused across many scenarios without conflicts, through layers, references, payloads, variants, and LIVRPS strength ordering.

~4 min
OpenUSDcompositionlayersLIVRPSscene

OpenUSD Scene Composition

In an earlier article on assembling a scene from USD we described pulling environments and robots in as references. But USD's real power runs deeper — USD is not one 3D file but a system that non-destructively composites multiple layers. Pixar built this structure so large animated productions could have many artists collaborating without conflicts, and it turned out to be a perfect fit for robot simulation.

The Composition Tools — Composition Arcs

USD stacks layers together through several "composition arcs."

  • sublayer — stack an entire layer on top of another (like Photoshop layers).
  • reference — embed another USD at a specific location (robot assets, environments).
  • payload — like a reference, but heavy portions are deferred until needed (lazy loading for large assets).
  • variant — multiple versions of a single prim (e.g., color or configuration variants of the same vehicle), switchable at runtime.
  • override — write only the changed values on top, leaving the original untouched.
Rendering diagram…

Who Wins — LIVRPS

When multiple layers define different values for the same prim, there is a conflict. USD resolves it with LIVRPS, a fixed strength ordering that determines which opinion wins.

Stronger →  Local · Inherits · Variants · References · Payloads · Specializes  → Weaker

The closest (Local) layer wins. That means you can leave the base asset untouched and place scenario-specific overrides on top — those overrides win because they are Local. The original is never modified.

💡 Non-destructive composition is the core value — Author a solid base environment USD once, then stack scenario opinions on top: "remove just this shelf, change only the lighting." The original is immutable; the variations are unlimited. Environments, robots, sensors, and scenarios each evolve independently and still compose into a single coherent stage.

Fitting an Army into Memory — Instancing

Duplicating the same asset (say, 1,000 identical containers) 1,000 times blows up memory. USD instancing keeps one copy of the prototype in memory and stores only 1,000 transforms, letting massive scenes load cheaply.

⚠️ Debugging is hard without understanding composition order — "I changed this value but it's not taking effect" almost always means a stronger layer in the LIVRPS ordering is overriding it. When a value is not applying, first check which composition arc is asserting a stronger opinion on that value.

In a nutshell

📌 USD is not a single file — it is a non-destructive system of layers, references, payloads, variants, and overrides, with conflicts resolved by the LIVRPS strength ordering. Base assets stay immutable; scenario variations are overrides. Instancing keeps large-scale scenes memory-efficient. If a value is not applying, start by examining the composition order.

See standard test results with videos and verdict evidence on the imSim Portal.

View public results →