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.