Hi everyone,
I’d like to start an open discussion around standards (or lack thereof) for using class prims and inherit arcs in OpenUSD assets, specifically patterns involving /_class* prim hierarchies.
I want to be very clear upfront:
I don’t consider any of the ideas below to be sacred.
The goal here is to surface tradeoffs, learn from existing practices, and hopefully converge on better shared conventions, especially for assets that are expected to move across teams, companies, and industries.
Context
For background, I primarily work in robotics simulation, but for this discussion I’d like to assume a broader constraint:
OpenUSD assets should be shareable across departments, companies, and industries, and should survive composition in large, heterogeneous assemblies.
One very common and useful pattern we see in USD assets is broadcasting shared opinions using inherit arcs on model-kind prims, often via some form of /_class* hierarchy.
This pattern is discussed or implied in multiple ecosystems today, for example:
SideFX
/__class__/rubbertoy
/rubbertoy (Default Prim)
(Inherits: "/__class__/rubbertoy")
Moana Island (Disney)
/_class_<Model>
/<Model>
(Inherits: "/_class_<Model>")
NVIDIA
NVIDIA documents a similar idea here.
although in practice the pattern seems inconsistently applied.
Why This Pattern Is Attractive (Especially in Simulation)
In robotics and real-time simulation workflows, the same logical asset often needs to exist in multiple runtimes with different requirements.
For example, a single runtime-agnostic conveyor asset may need to be extended with:
-
Unreal Engine-specific data
-
Isaac Sim-specific schemas or physics settings
-
Other engine/platform-specific metadata
All of this is possible without using inherits, but using a class + inherit pattern often feels significantly cleaner and more scalable, particularly when broadcasting shared opinions to many instances.
Problems Observed
1. Lack of Shared Conventions
There is currently no widely agreed-upon standard for:
-
Naming
/_class*prims -
Where they live in the namespace
-
How they should be referenced or composed
This is understandable, as each organization has evolved its own internal conventions, but it does make cross-company asset composition harder than it needs to be.
2. Inherit Conflicts (Main Concern)
The more serious issue I’d like to discuss is what I’ll call inherit conflicts.
By this, I mean situations where two unrelated assets from different sources define the same inherited prim path, making it impossible to independently override their behavior in a shared assembly (just by using inherits).
For example, imagine two conveyor assets from different vendors:
Company A
/_class_conveyor
/conveyor (Default Prim)
(Inherits: "/_class_conveyor")
Company B
/_class_conveyor
/conveyor (Default Prim)
(Inherits: "/_class_conveyor")
If both assets are brought into the same stage or assembly, there is no obvious way to author distinct inherited opinions for Company A versus Company B using inherits alone, since the paths collide.
A Possible Direction (Looking for Feedback)
One idea that seems obvious to me, but which I am very open to being challenged on, is namespacing class prims, similar to how most programming languages avoid symbol collisions.
For example:
Company A
/_class_companyA/conveyor
/conveyor
(Inherits: "/_class_companyA/conveyor")
Company B
/_class_companyB/conveyor
/conveyor
(Inherits: "/_class_companyB/conveyor")
This avoids inherit conflicts entirely and allows downstream assemblies to selectively override or extend behavior per asset source.
Open Questions for the Group
-
Is this a reasonable approach, or am I over-engineering the problem?
-
Are there simpler or more idiomatic USD-native solutions I’m missing?
-
Do people rely on other composition strategies to avoid this issue in practice, when cosuming assets from different sources?
-
If namespacing is useful, should this be a guideline for publicly distributed assets, rather than something each consumer fixes downstream?
For example, should reusable assets that rely on inherits follow conventions like:
/_class_pxr/<Model>
/_class_amzn/<Model>
/_class_nvidia/<Model>
/_class_turbosquid/<Model>
Or does this push assets in the wrong direction, making them feel less “universal” rather than more interoperable?
Should departments/subsidiaries have their own namespace? For example: /_class_amzn/robotics, /_class_amzn/games, /_class_amzn/imaging etc? I assume this would vary per studio/company.