What is OpenUSD and why does it matter for robotics

If you’re building a robotics simulation in 2026, you have a choice between several scene description formats — SDF, URDF, MJCF, and OpenUSD. Increasingly, the answer is OpenUSD, especially anywhere NVIDIA Isaac Sim, Omniverse, or large-scale digital twins are involved. This guide explains what OpenUSD actually is, the architecture that makes it different from older formats, and the specific reasons it has taken over robotics simulation pipelines.

OpenUSD: a one-paragraph history

OpenUSD (“Universal Scene Description”) was created by Pixar as the internal 3D scene format for Finding Dory (2016) and every Pixar film since. It was open-sourced the same year. The problem Pixar was solving: how do you let dozens of artists work concurrently on a scene with millions of primitives, with non-destructive overrides, asset references, and lossless asset reuse across films?

In 2018, NVIDIA adopted USD as the foundation of Omniverse, eventually extending it with USDPhysics schemas for rigid-body, articulation, and contact simulation. Apple adopted USD as the canonical content format for Vision Pro and ARKit. Adobe, Autodesk, Foundry, and others joined.

In 2023, the Alliance for OpenUSD (AOUSD) was formed under the Linux Foundation to govern the spec, with Pixar, NVIDIA, Apple, Adobe, and Autodesk as founding members. USD now has the same open-governance posture as glTF or X3D, with substantially more industry backing.

The architecture: what makes USD different

Older 3D formats — OBJ, FBX, glTF — describe a single static scene. URDF and SDF describe a robot and an environment with limited extensibility. MJCF describes a MuJoCo XML model.

USD is structured fundamentally differently. The primitives:

Prims (primitives)

Every “thing” in a USD scene is a prim. A prim has a path (/World/Warehouse/Pallet_001), a type (Mesh, Xform, Camera, RigidBody), and arbitrary attributes. Prims form a tree.

Layers

A USD scene is a stack of layers. Each layer can contribute or override prims and attributes. Layers compose like CSS: top wins. Use cases:

• Animation layer — overrides positions over time
• Variation layer — swaps in damaged-vs-clean variants of an asset
• Physics layer — adds physics properties without modifying the visual master
• Per-engineer working layer — your local edits, separate from teammates’

This is the killer feature for collaborative pipelines and for digital twins, where the as-built layer, the as-operated layer, and the simulation layer can co-exist.

References and payloads

Any prim can reference another USD file. Want a thousand pallets in a warehouse scene? Reference the master pallet asset a thousand times — the file size and editing complexity stay flat. Payload references are the same idea but lazy-loaded for huge scenes.

Variants

A prim can have multiple variants (different geometry, materials, or physics) selectable at runtime. A drone asset might have low-detail-flight and high-detail-inspection variants in the same file.

Schemas

USD attributes belong to schemas — typed groups of attributes. The most important ones for robotics:

• PhysicsRigidBodyAPI — applies rigid-body physics to a prim
• PhysicsMassAPI — mass, center of mass, inertia tensor
• PhysicsCollisionAPI — marks the prim as a collider; specifies whether to use the visual mesh, a convex hull, or a custom collision mesh
• PhysicsArticulationRootAPI — root of an articulated mechanism (a robot arm)
• PhysicsRevoluteJoint, PhysicsPrismaticJoint — joint types
• PhysicsMaterialAPI — friction, restitution, density
• SemanticsAPI — object class labels for perception training

Schemas are extensible — vendors can ship custom schemas for their needs. This is how NVIDIA layers Isaac-specific extensions on top of the open USDPhysics core.

A concrete USDPhysics example

Here’s the minimum USD code to make a 3D model /World/box simulation-ready:

#usda 1.0

def Xform "World"
{
    def Cube "box" (
        prepend apiSchemas = ["PhysicsRigidBodyAPI", "PhysicsMassAPI", "PhysicsCollisionAPI"]
    )
    {
        float physics:mass = 0.5
        vector3f physics:centerOfMass = (0, 0, 0)
        vector3f physics:diagonalInertia = (0.001, 0.001, 0.001)

        token physics:approximation = "convexHull"
        bool physics:collisionEnabled = true
        rel physics:material = </World/Materials/RubberLike>
    }

    def PhysicsScene "physicsScene"
    {
        vector3f physics:gravityDirection = (0, 0, -1)
        float physics:gravityMagnitude = 9.81
    }

    def Material "RubberLike" (
        prepend apiSchemas = ["PhysicsMaterialAPI"]
    )
    {
        float physics:dynamicFriction = 0.7
        float physics:staticFriction = 0.8
        float physics:restitution = 0.4
        float physics:density = 1100
    }
}

The same scene in URDF would require a <robot> wrapper, can’t carry visual-only metadata cleanly, and doesn’t support the layered authoring workflow. In MJCF you’d write <worldbody> with embedded geom definitions. Both work — neither composes.

Why simulators are converging on USD

Five practical reasons production robotics teams are moving to USD as their canonical format:

1. Composition handles real-world complexity

A factory digital twin has thousands of unique objects, daily geometry changes, multiple simulation use cases (training, validation, what-if), and dozens of contributors. Layered USD handles this natively. URDF/SDF/MJCF can technically scale, but every team building a serious multi-thousand-object scene reinvents some flavor of layer system on top.

2. Physics, semantics, materials, rendering — one format

USD carries everything: visual geometry, materials, lighting, animation, physics, semantic labels, semantic segmentation maps for synthetic data, custom application data. URDF/SDF have to bolt on extensions for non-physics data; USD has it built into the schema model.

3. Cross-tool authoring

Blender, Maya, Houdini, Substance, Unreal, Unity, Omniverse, Isaac Sim — all read and write USD. You can author geometry in Blender, materials in Substance, physics in Rigyd, and simulate in Isaac Sim with the same file moving between tools. URDF/SDF tooling outside the ROS ecosystem is sparse.

4. NVIDIA gravity

Isaac Sim, Isaac Lab, Omniverse, GR00T, and Project DRIVE Sim are all USD-native. NVIDIA’s SimReady asset spec is built on USDPhysics. If your robotics roadmap touches any NVIDIA platform, USD is the path of least friction.

5. The conversion path is one-way clean

USD → URDF, USD → MJCF, USD → SDF are all well-supported conversions. The reverse — URDF → USD with physics, materials, semantics, and metadata preserved — is harder and lossy. Authoring in USD and converting outward is the asymmetric bet.

Trade-offs and downsides

USD is not strictly better at everything:

• Learning curve. Layers, references, variants, schemas — there are more concepts than URDF or MJCF. Engineers familiar with ROS often need a few weeks to feel fluent.
• Tooling weight. The USD runtime is significantly larger than the URDF or MJCF parsers. For embedded simulation or browser-based viewers, this can matter.
• Maturity gaps in some niches. MuJoCo’s contact solver is exceptional for fine manipulation. While USD → MJCF conversion exists, native USD physics in some simulators still lags MJCF for soft-body and contact-rich tasks.
• Spec churn. USD continues to evolve. Schemas like PhysicsTendonAPI are newer and less broadly supported. Pin your USD runtime version for production stability.

For most production robotics teams in 2026, the upsides outweigh the downsides — especially if the simulation roadmap involves digital twins, NVIDIA platforms, or scenes with more than ~100 unique objects.

The SimReady asset spec

NVIDIA’s SimReady specification is the closest thing to a “well-formed” definition for a USD asset that’s truly simulation-ready. A SimReady asset includes:

• Physics — PhysicsRigidBodyAPI, PhysicsMassAPI, PhysicsCollisionAPI correctly applied with reasonable values.
• Semantics — class labels via SemanticsAPI for perception training.
• Material physics — PhysicsMaterialAPI with friction and restitution.
• Collision geometry — distinct from visual geometry, optimized for the physics solver.
• Validated structure — passes NVIDIA’s automated SimReady validator.

Today, NVIDIA’s curated SimReady library has roughly 1,000 assets. A typical warehouse robotics simulation needs 50,000+ unique objects. This gap — between the small curated library and the demand for SKU-scale physics-enabled assets — is exactly what AI-driven asset preparation tools (including Rigyd) are built to fill.

What this means in practice

If you’re starting a new robotics simulation project today:

• Adopt USD as your canonical format unless you have a specific reason not to (deep ROS investment, MuJoCo-specific contact requirements).
• Author physics with USDPhysics schemas, not vendor extensions, so your assets remain portable across simulators.
• Use the SimReady spec as your acceptance criterion. If an asset passes the SimReady validator, it’ll work in Isaac Sim, Omniverse, and any USDPhysics-compliant downstream tool.
• Plan for layered workflows. Physics in one layer, visual updates in another, simulation overrides in a third. This makes daily collaboration possible at scale.

If you’re maintaining an existing URDF/SDF/MJCF pipeline, the migration question is timing, not direction. Most large robotics organizations are running parallel pipelines today — legacy URDF for existing robots, USD for new environments and assets — with a multi-year convergence path.

The format choice has become close to settled. The interesting question is no longer “which format?” but “how fast can we author SimReady-grade assets at the scale our simulation actually requires?” That’s the bottleneck worth solving.