OpenUSD Frequently Asked Questions#

What is Universal Scene Description?#

Pixar’s Universal Scene Description is a core technology of NVIDIA Omniverse™. The open-source 3D scene description, file format, and API are easily extensible, originally developed to simplify content creation and interchange of assets between different industry software tools. OpenUSD began in the visual effects industry to simplify collaboration across large teams. Today, OpenUSD is becoming widely adopted across many more industries, including architecture and engineering, manufacturing, product design, and robotics.

What is OpenUSD used for?#

OpenUSD is used for developing and managing large-scale 3D scenes and assets in the film, animation, gaming, AECO and digital twin industries.

What are some benefits of using OpenUSD?#

Benefits of using OpenUSD include improved collaboration, reduced data duplication, and enhanced flexibility in workflow and pipeline design.

What programming languages can be used to develop with OpenUSD?#

You can develop with OpenUSD using C++ and Python. OpenUSD is written in C++ with Python binding for most of its APIs.

What’s the difference between USD, OpenUSD, and AOUSD?#

In short: USD is the technology, OpenUSD is the open-source project and primary implementation of USD, and AOUSD is the governing body standardizing USD.

USD (Universal Scene Description)

USD is the core technology originally developed by Pixar Animation Studios for describing, composing, simulating, and collaborating within 3D worlds. It was created for Pixar’s internal film production pipeline and provides:

  • An open-source 3D scene description and interchange framework

  • A composition engine for layering and overriding data

  • APIs for reading, writing, and manipulating scenes

  • Support for complex workflows like asset referencing, variants, and time-sampled data

OpenUSD

OpenUSD is the open-source release of USD. Pixar made the technology publicly available starting in 2016. OpenUSD is the primary implementation of USD. USD and OpenUSD are often used interchangeably in conversation and technically refer to the same underlying technology—OpenUSD is just the branding used when referring to the open-source project.

AOUSD (Alliance for OpenUSD)

AOUSD is the Alliance for OpenUSD—a standards organization formed in 2023 under the Linux Foundation’s Joint Development Foundation. It’s not a technology itself, but rather a governance body whose members include:

  • Apple

  • Pixar (Disney)

  • Adobe

  • Autodesk

  • NVIDIA

The Alliance’s goals are to:

  • Standardize OpenUSD’s data models and runtime behaviors in normative, implementation-agnostic specifications.

  • Ensure interoperability across tools and platforms.

  • Guide the long-term development roadmap.

  • Provide official certification programs.

Do USD, MDL, and MaterialX files support encryption?#

USD, MDL, and MaterialX do not have built-in encryption support at the file format level. All three are designed as interchange formats prioritizing openness and interoperability. Encryption would conflict with their core purpose of enabling collaboration across tools and pipelines. Asset protection is typically handled at a different layer (pipeline security, licensing systems, or container-level encryption).

If you need to protect your assets:

  • Pipeline/resolver layer — Custom USD ArResolver that fetches encrypted assets from a secure server and decrypts in-memory before passing to USD

  • Transport layer — Encrypted connections (HTTPS, VPN) when transferring assets between systems

  • Storage layer — Encrypted filesystems, cloud storage encryption (S3 server-side encryption, encrypted volumes)

  • Container layer — Wrap assets in encrypted archives; decrypt to a secure temp location before loading

  • DRM systems — Enterprise solutions that control access at the application or OS level

How do I control access to or prevent export of sensitive information in my USD content?#

If you need to protect sensitive information in your USD content, consider one of the following approaches:

Preventing Export of Sensitive Information

  • DCC Plugin Controls

    • Most export pipelines go through custom plugins. Add checks there:

      • Allowlist/denylist specific prim paths, attributes, or metadata.

      • Strip proprietary custom schemas before export.

      • Remove or redact specific namespaced attributes (for example, myStudio:internal:*).

      • Remove asset paths pointing to internal servers.

  • Post-Export Sanitization

    • Run a validation/sanitization pass on exported USD.

  • Pipeline-Level Controls

    • Export profiles: Different export configs for internal vs. external delivery

    • Approval workflows: Automated scanning before assets leave secure systems

    • Watermarking: Embed tracking metadata in exported assets

Controlling Access to Sensitive USD Content

  • Custom Asset Resolver (ArResolver)

    • USD’s asset resolution system is the primary control point.

    • A custom resolver can:

      • Check user permissions before resolving paths.

      • Return empty/placeholder assets for unauthorized users.

      • Log access attempts.

      • Decrypt on-the-fly from secure storage.

      • Your ArResolver intercepts every asset fetch and enforces your access rules.

  • Layer-Based Access Control

    • Structure your scenes so sensitive data lives in separate layers:

      • asset.usd (public root)

      • geometry.usd (public)

      • materials.usd (public)

      • proprietary_rigging.usd (restricted layer; served only to authorized users)

      • Your resolver or asset server can then serve or deny specific layers based on credentials.

Should I use metadata or properties for my custom data?#

Use properties when:

Scenario

Example

Data changes over time

Animation, simulation caches

Needs to be renderable/composable

Materials, transforms, visibility

Part of a schema

Physics mass, extent, purpose

Needs connections

Material bindings, relationships

Should participate in composition

Overrides in stronger layers

prim.CreateAttribute("myNamespace:temperature", Sdf.ValueTypeNames.Float).Set(98.6)

Use metadata when:

Scenario

Example

Non-time-varying bookkeeping

Asset version, author, export date

Pipeline/tooling hints

Source file path, DCC origin

Doesn’t need composition

Internal notes, processing flags

Lightweight key-value storage

Tags, categories, status

prim.SetCustomDataByKey("myPipeline:exportedBy", "Maya 2024")
prim.SetAssetInfoByKey("version", "1.2.3")

Custom properties are often recommended instead of metadata or customData metadata for prototyping because the former requires plugin-based schema development (which is less portable) and the latter is more costly for composition because it is a composable dictionary data type.

More information: Beyond the Basics: Custom Properties.

Does Kit use stock OpenUSD?#

NVIDIA previously used customized build of OpenUSD called NVUSD. There has been a continual effort to converge back to stock OpenUSD.

Kit 107-109 had some Hydra specific modifications we termed NVHYDRA. Kit 110 is ABI/API compatible but has a small patch to enable skeletal deformation of normals.

What is Omniverse Fabric? What is USDRT?#

A library that provides fast access, modification, topology editing and change notification for a composed USD stage, gpu-cpu interoperability, and replication support for multi-node clients. USDRT Scenegraph API is an Omniverse API that mirrors the USD API, but reads and writes data to and from Fabric instead of USD.

How They Relate

+----------------------+
|  Your Application    |
+----------------------+
           |
           ▼
+--------------------------------+
|         USDRT API              |  ← Familiar USD-style interface
+--------------------------------+
           |                |
           ▼                ▼
+----------------+  +----------------+
|      USD       |  |     Fabric     |  ← Data model
|                |  |  (high-perf)   |
+----------------+  +----------------+

Comparison

USD

Fabric

USDRT

Developer

Pixar

NVIDIA

NVIDIA

Data view

Pre- and post-composition

Post-composition only

Post-composition only

API Languages

C++, Python

C++

C++, Python

Vectorized APIs

No

Yes

Not yet

GPU data synchronization

No

Yes

Partial

Data persistence

File-based storage

Transient, in-memory only

Transient, in-memory only

Data write speed

Slow

Fastest

Fast

When to Use What

  • USDRT: When you want USD-familiar code that can run fast or need to gradually migrate USD code to use Fabric.

  • Fabric directly: When you need maximum performance for simulation/rendering and don’t need USD composition.

  • Traditional USD: When authoring, interchange, or file-based workflows are the priority.

You have an overview of OpenUSD concepts, security options, and Fabric/USDRT. For more on USD with Fabric and USDRT, see USD, Fabric, and USDRT.