{"slug": "develop-lightweight-usd-runtimes-faster-with-ai-agents", "title": "Develop Lightweight USD Runtimes Faster with AI Agents", "summary": "NVIDIA released nanousd-labs, an open-source project that uses AI agents to generate lightweight USD runtimes directly from the USD Core Specification, enabling developers to create custom implementations for physical AI workloads. The approach treats the specification as a contract, allowing agents to produce compliant code tailored to specific memory, performance, or language constraints.", "body_md": "[OpenUSD](https://developer.nvidia.com/openusd?size=n_6_n&sort-field=featured&sort-direction=desc) 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.\n\nUntil 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.\n\nThis approach is possible because USD is defined by a formal and machine-readable specification. Developed by the [Alliance for OpenUSD](https://aousd.org/) (AOUSD), the[ USD Core Specification](https://github.com/aousd/specifications-public/tree/main/core) is the versioned standard defining how USD data models are composed and resolved across layer stacks.\n\nBecause 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.\n\n[nanousd-labs](https://github.com/NVIDIA-Omniverse/nanousd-labs) is published as part of NVIDIA [Omniverse Labs](https://github.com/NVIDIA-Omniverse/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.\n\n## How do AI agents build against the USD Core Specification?\n\nThe 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.\n\nWorking 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.\n\nBecause 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.\n\nIn 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.\n\n``` python\nimport nanousd\n\nRACK_ASSET = \"./assets/shelving_unit.usd\"   # your part on disk (referenced, not copied)\nFORKLIFT_ASSET = \"./assets/forklift.usd\"\n\n# 1) New stage with warehouse conventions (Z-up, meters)\nstage = nanousd.Stage.create()\nstage.set_metadata_token(\"upAxis\", \"Z\")\nstage.set_metadata_double(\"metersPerUnit\", 1.0)\nstage.set_metadata_token(\"defaultPrim\", \"World\")\nstage.define_prim(\"/World\", \"Xform\")\n\n# 2) ASSEMBLE: reference an external part into place, once per grid cell.\n#    add_reference(asset_path, prim_path=\"\") pulls the part in without copying it.\nfor row in range(3):\n    for col in range(5):\n        rack = stage.define_prim(f\"/World/Racks/Rack_{row}_{col}\", \"Xform\")\n        rack.add_reference(RACK_ASSET)                     # <- assembly via reference\n        rack.create_attribute(\"xformOp:translate\", \"double3\")\n        rack.set_vec3d(\"xformOp:translate\", (col * 3.0, row * 6.0, 0.0))\n        order.append(\"xformOp:translate\")\n\n# 3) Built-in geometry so the file is non-empty even without external assets:\nfloor = stage.define_prim(\"/World/Floor\", \"Cube\")\nfloor.create_attribute(\"size\", \"double\")\nfloor.set_double(\"size\", 1.0)\nplace(floor, translate=(6.0, 6.0, -0.05), scale=(30.0, 40.0, 0.1))\n\n# 4) MOVE: animate a forklift with a time-sampled translate op (this \"moves\" geometry).\nstage.set_metadata_double(\"startTimeCode\", 0.0)\nstage.set_metadata_double(\"endTimeCode\", 96.0)\nstage.set_metadata_double(\"timeCodesPerSecond\", 24.0)\n\nforklift = stage.define_prim(\"/World/Forklift\", \"Xform\")\nforklift.add_reference(FORKLIFT_ASSET)\nforklift.create_attribute(\"xformOp:translate\", \"double3\")\nwaypoints = [(0.0, (0.0, 0.0, 0.0)),\n             (48.0, (12.0, 0.0, 0.0)),\n             (72.0, (12.0, 18.0, 0.0)),\n             (96.0, (0.0, 18.0, 0.0))]\nfor t, pos in waypoints:\n    forklift.set_sample_vec3d(\"xformOp:translate\", t, list(pos))   # keyframe at time t\nforklift.create_attribute(\"xformOpOrder\", \"token[]\")\nforklift.set_token_array(\"xformOpOrder\", [\"xformOp:translate\"])\n\n# 5) Save\nstage.write_usda(\"warehouse.usda\")\nprint(\"Wrote warehouse.usda\")\n```\n\n## What is nanousd-labs?\n\nnanousd 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.\n\nnanousd 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.\n\nThe 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.\n\nIt 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.\n\n## Two ways to build with USD Core Specification and AI agents\n\nDevelopers 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.\n\nThe 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:\n\n```\npython -m pip install -e ./nanousd-python\n```\n\nOpening a stage and walking its prims (the individual elements that make up a USD scene) looks like this:\n\n``` python\nimport nanousd\n\nstage = nanousd.Stage.open(\"scene.usda\")\n\nfor prim in stage.traverse():\n    print(prim.path, prim.type_name, prim.attribute_names())\n\ncube = stage.get_prim_at_path(\"/World/Cube\")\nif cube is not None and cube.has_attribute(\"size\"):\n    print(cube.read_double(\"size\"))\n```\n\nFrom there, an agent grounded in the USD Core Specification handles authoring and validation. Building an asset looks like this:\n\n```\nAuthor 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. \nFollow the USD Core Spec. \nWhen you're done, compose it back and show me the resolved prim tree, and flag anything you had to correct to stay spec-compliant.\n```\n\nThe 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.\n\nThe following output shows each element in the scene, its type, and how it was assembled:\n\n```\n/World/Lidar           Cube          (sensor placeholder)\n/World/WheelL          Xform    [instanceable → /_assets/Wheel]\n/World/WheelR          Xform    [instanceable → /_assets/Wheel]\n\nnote: your first draft referenced the wheel without marking the\nprims instanceable, so each wheel composed as a full unique copy.\nPer the Core Spec that defeats scene-graph instancing — set\ninstanceable = true on both, re-composed, both now share one prototype.\n```\n\nInstanceable 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.\n\nValidating an existing asset works the same way:\n\n```\nHere's robot.usda straight from our exporter. \nCheck 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. \nDon't guess from the text — open it and read the composed values.\n```\n\nThe 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.\n\nThe 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.\n\nA roughly [10-minute tutorial](https://github.com/NVIDIA-Omniverse/omniverse-labs/tree/main/projects/nanousd-labs/usd-developer-skillgraph/docs/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.\n\n## Get started\n\nBuilding 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.\n\nDevelopers 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.\n\n- Explore the OpenUSD standard\n[USD Core Spec](https://github.com/aousd/specifications-public). - Experiment with the\n[nanousd-labs](https://github.com/NVIDIA-Omniverse/nanousd-labs)project. - Get involved and contribute to the\n[Core Spec Working Group](http://join.aousd.org). - Start with the free open-source\n[Learn OpenUSD](https://docs.nvidia.com/learn-openusd/latest/index.html)learning path designed to help master the skills for building efficient 3D workflows with OpenUSD. - Learn more about OpenUSD during\n[Physical AI Day](https://www.nvidia.com/en-us/events/siggraph/?type=physical-ai-day)at SIGGRAPH 2026", "url": "https://wpnews.pro/news/develop-lightweight-usd-runtimes-faster-with-ai-agents", "canonical_source": "https://developer.nvidia.com/blog/develop-lightweight-usd-runtimes-faster-with-ai-agents/", "published_at": "2026-07-15 21:57:23+00:00", "updated_at": "2026-07-15 22:29:12.822104+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["NVIDIA", "Alliance for OpenUSD", "OpenUSD", "nanousd-labs", "Omniverse Labs", "USD Core Specification"], "alternates": {"html": "https://wpnews.pro/news/develop-lightweight-usd-runtimes-faster-with-ai-agents", "markdown": "https://wpnews.pro/news/develop-lightweight-usd-runtimes-faster-with-ai-agents.md", "text": "https://wpnews.pro/news/develop-lightweight-usd-runtimes-faster-with-ai-agents.txt", "jsonld": "https://wpnews.pro/news/develop-lightweight-usd-runtimes-faster-with-ai-agents.jsonld"}}