OpenUSD is an open, extensible framework that provides a common scene description language for physical AI. It enables teams to bring CAD data, simulation assets, and real-world telemetry into a shared, physically accurate view of the world.
Until now, building a USD implementation has typically required adapting a large existing codebase— even for teams that need a specific memory footprint, a different application binary interface (ABI), or different performance characteristics. nanousd-labs offers another path: generating a runtime directly from the standard.
This approach is possible because USD is defined by a formal and machine-readable specification. Developed by the Alliance for OpenUSD (AOUSD), the USD Core Specification is the versioned standard defining how USD data models are composed and resolved across layer stacks.
Because the specification serves as a precise contract for both humans and agents, developers can direct agents to generate what a specific workload requires. This approach complements adapting an existing codebase or implementing the spec by hand, enabling faster implementation cycles and end users’ physical AI products suited to their deployment environment.Â
nanousd-labs is published as part of NVIDIA Omniverse Labs, a collection of open, experimental projects. Built during an internal hackathon, it gives developers a lightweight way to generate USD runtimes directly from the USD Core Specification using AI agents. This post walks through how developers can use AI agents and the USD Core Specification to generate a working USD implementation, presents nanousd-labs as a real-world example of that approach, and provides two entry points for developers to try it on their own physical AI projects.
How do AI agents build against the USD Core Specification?
The nanousd-labs methodology rests on the single idea of treating the USD Core Specification as the contract. The specification defines the behavior a compliant runtime must produce, not how it is built. Rather than adapting an existing codebase, agents read the specification directly, write code that must satisfy that behavior, and validate the output against a test suite derived from the specification. The standard is durable, and the generated code is elastic. It is meant to be regenerated against different constraints, such as memory, performance, or language, without losing compliance.
Working under a developer’s direction, agents consume the specification section by section, generate the code that implements each behavior, and run it against a test suite derived from the same standard, iterating until the output matches the spec requirements. The rules that govern how scene data is structured, resolved, and overridden are all expressed as text the agents apply and check work against. This is what makes the approach practical. The spec becomes a contract developers direct agents to build and validate against, not documentation that someone reads once and interprets manually.
Because the implementation is generated against the spec, compliance is built into the methodology, not tied to any single implementation. The aim is for developers to regenerate the runtime for different constraints, tailoring it to their workload without sacrificing compliance with the standard.
In practice, this methodology has clear boundaries. The spec is the input and compliance with the standard is the measure of success. This doesn’t mean fully automated generation, and it doesn’t mean the entire specification is covered today. In building nanousd-labs, agents handled the mechanical spec-to-code work, including parsing, scene composition, and how scene values are resolved across layers, while engineers owned performance, tradeoffs, and architectural decisions. A written standard means every implementation task has a clear definition of correct that can be tested.
import nanousd
RACK_ASSET = "./assets/shelving_unit.usd" # your part on disk (referenced, not copied)
FORKLIFT_ASSET = "./assets/forklift.usd"
# 1) New stage with warehouse conventions (Z-up, meters)
stage = nanousd.Stage.create()
stage.set_metadata_token("upAxis", "Z")
stage.set_metadata_double("metersPerUnit", 1.0)
stage.set_metadata_token("defaultPrim", "World")
stage.define_prim("/World", "Xform")
# 2) ASSEMBLE: reference an external part into place, once per grid cell.
# add_reference(asset_path, prim_path="") pulls the part in without copying it.
for row in range(3):
for col in range(5):
rack = stage.define_prim(f"/World/Racks/Rack_{row}_{col}", "Xform")
rack.add_reference(RACK_ASSET) # <- assembly via reference
rack.create_attribute("xformOp:translate", "double3")
rack.set_vec3d("xformOp:translate", (col * 3.0, row * 6.0, 0.0))
order.append("xformOp:translate")
# 3) Built-in geometry so the file is non-empty even without external assets:
floor = stage.define_prim("/World/Floor", "Cube")
floor.create_attribute("size", "double")
floor.set_double("size", 1.0)
place(floor, translate=(6.0, 6.0, -0.05), scale=(30.0, 40.0, 0.1))
# 4) MOVE: animate a forklift with a time-sampled translate op (this "moves" geometry).
stage.set_metadata_double("startTimeCode", 0.0)
stage.set_metadata_double("endTimeCode", 96.0)
stage.set_metadata_double("timeCodesPerSecond", 24.0)
forklift = stage.define_prim("/World/Forklift", "Xform")
forklift.add_reference(FORKLIFT_ASSET)
forklift.create_attribute("xformOp:translate", "double3")
waypoints = [(0.0, (0.0, 0.0, 0.0)),
(48.0, (12.0, 0.0, 0.0)),
(72.0, (12.0, 18.0, 0.0)),
(96.0, (0.0, 18.0, 0.0))]
for t, pos in waypoints:
forklift.set_sample_vec3d("xformOp:translate", t, list(pos)) # keyframe at time t
forklift.create_attribute("xformOpOrder", "token[]")
forklift.set_token_array("xformOpOrder", ["xformOp:translate"])
# 5) Save
stage.write_usda("warehouse.usda")
print("Wrote warehouse.usda")
What is nanousd-labs?
nanousd is an independent implementation of the USD runtime data model (the rules that govern how a USD scene behaves when loaded and queried), derived directly from the USD Core Specification and exposed through a stable C ABI. The implementation is written in C++ with a public C API that any language can call directly.
nanousd is a data layer, not a renderer. It parses, composes, queries, and writes, and stops at the point where pixels begin. Agents implement the Core Specification’s runtime data model, and nanousd carries only what a specific workload requires, exposed through a stable C ABI. Existing OpenUSD stacks keep working untouched. The methodology is what is worth adopting. The implementation is the proof.
The USD Core Specification defines what a runtime must do and leaves open how memory, threading, ABI, and language are implementation choices, not requirements. For nanousd, the primary choice so far is a stable C ABI. The memory and performance specifics behind it are still being explored. Client code compiles against a fixed C API and loads its implementation at runtime, so the backend can change while the calling code stays constant. The backend can be swapped—OpenUSD under an Omniverse library, or nanousd dropped in—without touching the client.Â
It also keeps measurements accurate. One script runs against the common API while the backend swaps underneath. The point isn’t that one implementation is faster than another. It’s that a standard plus a stable ABI makes it possible to direct agents to iterate toward what fits the workload.
Two ways to build with USD Core Specification and AI agents
Developers building physical AI pipelines and applications who need a lightweight, purpose-built USD runtime have two ways to get started with nanousd-labs. The first is for teams who want a working implementation they can use today. The second is for teams who want to understand the methodology and apply it to their own stack.
The first entry point is to clone and build nanousd directly. This is a compiled implementation with a C API that any programming language can call, ready to point at existing USD stages today. Most physical AI developers will start with nanousd-python, the Python package built on the nanousd C API, which requires no GPU and runs headlessly on any machine. It can easily be installed with:
python -m pip install -e ./nanousd-python
Opening a stage and walking its prims (the individual elements that make up a USD scene) looks like this:
import nanousd
stage = nanousd.Stage.open("scene.usda")
for prim in stage.traverse():
print(prim.path, prim.type_name, prim.attribute_names())
cube = stage.get_prim_at_path("/World/Cube")
if cube is not None and cube.has_attribute("size"):
print(cube.read_double("size"))
From there, an agent grounded in the USD Core Specification handles authoring and validation. Building an asset looks like this:
Author a USD stage for a warehouse AMR: a base transform, a lidar sensor prim, and two wheel meshes brought in as instanceable references to one shared wheel asset.
Follow the USD Core Spec.
When you're done, compose it back and show me the resolved prim tree, and flag anything you had to correct to stay spec-compliant.
The agent authors the stage, composes it back through nanousd-labs to confirm it resolves correctly, and returns the composed scene structure plus a note on anything it fixed.
The following output shows each element in the scene, its type, and how it was assembled:
/World/Lidar Cube (sensor placeholder)
/World/WheelL Xform [instanceable → /_assets/Wheel]
/World/WheelR Xform [instanceable → /_assets/Wheel]
note: your first draft referenced the wheel without marking the
prims instanceable, so each wheel composed as a full unique copy.
Per the Core Spec that defeats scene-graph instancing — set
instanceable = true on both, re-composed, both now share one prototype.
Instanceable means the two wheels share one definition in the scene rather than each carrying a full separate copy. This is how USD handles repeated elements efficiently.
Validating an existing asset works the same way:
Here's robot.usda straight from our exporter.
Check whether it's Core-Spec-compliant: compose it, walk the result, and tell me exactly where it diverges from what the spec says should resolve.
Don't guess from the text — open it and read the composed values.
The agent composes the file, checks the resolved result against the spec’s rules, and returns a specific answer: exactly which part of the scene diverges, why, and what the correct result should be. Developers get a clear compliance signal rather than having to interpret tool-specific behavior.
The second way in gets at the heart of the method and is hands-on. The first time direct agents build against the Core Specification, every instruction is hand-written. The skillgraph is where human directions are codified into reusable skills. Structured recipes, prompts, and tests capture how to produce spec-compliant behavior.
A roughly 10-minute tutorial walks through it. Run the skills that generate a USD ASCII (USDA) parser meeting the Core Specification and finish with a working understanding of the methodology and a starting point for implementation. It doesn’t generate everything yet. The graph is growing, and multi-part cohesion is the frontier, but it’s the durable layer. The standard is the contract; the skill graph makes the workflow reusable rather than reinvented for each implementation.
Get started
Building a purpose-built USD runtime is now possible without starting from scratch. The USD Core Specification gives agents a precise foundation to build from, and nanousd-labs shows what that looks like in practice. The methodology is open, the standard is public, and there is more to build.
Developers can contribute new skills, language support, and physical AI use cases on GitHub today. Organizations that are AOUSD members can help shape the standard itself through the Core Spec Working Group. The Core Spec is the durable foundation, and nanousd-labs is one example of what becomes possible when agents and open standards work together.
- Explore the OpenUSD standard USD Core Spec.
- Experiment with the nanousd-labs project.
- Get involved and contribute to the Core Spec Working Group.
- Start with the free open-source Learn OpenUSD learning path designed to help master the skills for building efficient 3D workflows with OpenUSD.
- Learn more about OpenUSD during Physical AI Day at SIGGRAPH 2026
