Skip to main content

OpenUSD

What is OpenUSD ?​

OpenUSD is a framework and universal interchange for describing, simulating, and collaborating across tools. It is designed to interchange and augment 3D scenes composed of many component assets, facilitating the assembly and organization of these assets into virtual sets, scenes, shots, and worlds.

-- AOUSD

Core Features​

Composition Engine​

The composition engine enables sparse, non-destructive assembly data from numerous sources as individual layers.

Custom Schemas​

Custom schemas are fundamental aspect of USD developement and powerful tool for extending data to enable more complex and sophisticated portfolios.

Objects in scenes are represented with Prim, which serves as a data container where data is represented by properties (including attriubutes and relationships). Properties are often grouped into logical subsets.

To extend data available on a prim, custom schema can be provided that includes a contract dictating how extended data is structured.

It is then up to the runtime to interpret and use the data for functional purpose.

tip

Schema provides a structure of the data but does not dictate the behaviour at runtime. For instance, schema related to rigid body definition can be applied to a prim(data model), but the physics behavour of a rigid body such as collision is up to the physics engine and renderer to implement(runtime behaviour).

There are two types of schema:

  • IsA schema is for class inheritance usage, including:

    • Abstract schema: Base for related sets of concrete schemas, cannot be instantiated
    • Concrete schema: Instantiable in scene hierarchy with concrete type name.

  • API schema is analogous to class composition, including:

    • Non-applied: Ad-hoc schema that doesn't contribute to type
    • Applied: Can be applied to a prim as a single instance (single-apply) or applied multiple times on the same prim with each apply gets an unique instance name(multiple-apply).

Asset Resolver & Data Storage​

Asset resolvers plugins abstract storage backend from data represnted in USD format. In combination with file format plugins, which abstract the serialization of the data, enables complete decouple from file system.

External data can be designated with a reference field in the USD by assigning the path, either local files or remote provider through API.

File format plugins also support dynamic payload. Dynamic payload can be thought as a parameterized access to external source data, allowing dynamic expose to large external data that would be impractical to load within the USD all at once

Hydra​

Hydra is a generalized pipeline for custom renderers by providing interfaces to implement the bussiness logic to process data contained in USD as a customizable chain of runtime scene analysis. Its is not tightly coupled to any runtime data layer, allowing Hydra to compile USD into a deeply vectorized data layout, fabric.

File Formats​

OpenUSD uses four native formats (USD, USDA, USDC and USDZ) for storing and exchanging 3D scene data, which all are hierarchical and extensible based on layers and composition.

  • USDA

    • ASCII text files that encode scene descriptions that can be easily read and edited.
    • Human-readable, useful for tasks that involve manual editing or inspection of scene data.
    • Optimal for small files, such as a stage that is referencing external content.

  • USDC

    • A Crate Format(hence the C in USDC) is a compressed binary file format.
    • Designed to minimize load time and provide a more efficient representation of the scene data compared to USDA.
    • Uses various compression techniques to reduce the file size and improve loading performance, and mploys memory mapping for faster file access and loading times. * * File structure is organized in a way that allows for efficient parsing and retrieval of the scene data.
    • Extremely efficient for numerically-heavy data, like geometry.

  • USD?

    • A USD (.usd) file can be either ASCII or binary – the advantage of which is that we can change the underlying format at any point without breaking references.
    • Using USD is beneficial for debugging, because an asset that is in binary can easily be changed to ASCII to take a look at what might be causing the issue.
    • One can separate heavier data from more light weight data by using .usdc and .usda explicitly to avoid obfuscation and create large .usda files unintentionally.

  • USDZ?

    • An atomic, uncompressed, zipped archive for delivering all of the necessary assets together.
    • Don't use USDZ if asset-editing are still being made, but suitable to package and ship the asset when it is complete. For example, a mesh with its texture files can be delivered as one archive.
    • Generally intended as read-only and is optimal for XR experiences.

Each USD file format can be created as well as interacted with through Python bindings in the OpenUSD library.

Any other 3D file format can be loaded into OpenUSD Stages through plugins. It’s worth noting that any data provider can implement file format plugins to natively speak USD – even .usdc, .usd, .usda, and .usdz are file format plugins.

Important Basic Concepts​

Hydra​

Hydra is a rendering architecture within OpenUSD that provides a high-performance, scalable, and extensible solution for rendering large 3D scenes.

Hydra Architecture

Hydra has three main parts:

  • Scene Delegate: Provides the scene information.
  • Render Index: Keeps track of changes and manages the scene.
  • Render Delegate: Uses the render index and scene delegate to visualize scene information and create the final image.

This approach separates the scene data from the rendering backend, enabling flexibility and extensibility.

Hydra's operation can be summarized into the following steps:

  1. Hydra processes one or more scene delegates, which represent the scene data in a hierarchical structure.
  2. It transforms the scene delegates into an abstract renderable scene.
  3. The render delegates use this abstract scene to generate rendering instructions specific to the target rendering backend.

OpenUSD ships with HdStorm, the real-time OpenGL/Metal/Vulkan render delegate leveraged by usdview and many other tools. It also ships with HdTiny and HdEmbree, which can be used as examples of how to implement render delegates.

Stage​

A stage presents the scenegraph, which is a hierarhy of objects, called prims, that can be anything from geometry, to materials, to lights and other organizational elements. It enables non-destructive editing, layering, and referencing, making it ideal for complex projects involving multiple collaborators.

A stage could be made up entirely with just one USD file (like a robot), or it could be a USD file that includes many more USD files (like a factory with many robots). The stage is the composed result of the file or files that may contribute to a scenegraph.

Leveraging OpenUSD stages properly enables:

  • Modularity: Stages enable the modification of individual elements without altering the original files (“non-destructive” editing), fostering a flexible workflow upon modular scene elements.
  • Scalability: Stages can manage large datasets efficiently (e.g., via payloads, which we’ll learn more about when we dive deeper into composition).
# Create a new, empty USD stage where 3D scenes are assembled
Usd.Stage.CreateNew()
  
# Open an existing USD file as a stage
Usd.Stage.Open()
  
# Saves all layers in a USD stage
Usd.Stage.Save()

Layer​

Composition Arcs​

Namespace​

References​