Rigyd vs NVIDIA USD Composer
These tools solve different halves of the OpenUSD workflow. NVIDIA USD Composer is a scene-assembly app inside Omniverse. Rigyd is an AI asset-prep pipeline that outputs OpenUSD + MJCF. Most teams use both.
Updated June 5, 2026 · by Ugur Yekta
The short answer
NVIDIA USD Composer is the Omniverse app for assembling and previewing OpenUSD scenes interactively. Rigyd is an AI pipeline that converts raw 3D, images, or text into SimReady OpenUSD assets with physics. Composer assembles; Rigyd authors the assets that get assembled.
Side-by-side comparison
| NVIDIA USD Composer Scene assembly in Omniverse | Rigyd AI asset preparation | |
|---|---|---|
| Primary purpose | Assemble and preview USD scenes | Generate SimReady assets from raw inputs |
| Position in pipeline | Scene composition | Asset preparation upstream of composition |
| Output | Composed USD scenes | Per-asset OpenUSD + MJCF with physics |
| Physics authoring | Manual via the PhysX extension | AI-estimated, override-able |
| Asset source | Existing OpenUSD assets you bring in | Raw .glb / .fbx / .obj, images, or text |
| Setup | Install Omniverse + USD Composer (Linux/Windows, NVIDIA GPU recommended) | Browser-based, no install |
| Cost | Free for individuals; Enterprise via NVIDIA | Free trial credits; tiered pricing on request |
| Bulk / catalog processing | Interactive, scene-by-scene | API-driven bulk processing for enterprise catalogs |
| Best fit | Composing scenes from a curated asset library | Producing the asset library at scale |
NVIDIA USD Composer: scene assembly inside Omniverse
USD Composer (formerly NVIDIA Omniverse Create) is the canonical Omniverse application for authoring and previewing OpenUSD scenes. It is built on Omniverse Kit and offers scene composition with layers and references, drag-and-drop asset placement, real-time RTX preview rendering, and physics simulation via the PhysX extension. For physics, you apply USDPhysics schemas (PhysicsRigidBodyAPI, PhysicsMassAPI, PhysicsCollisionAPI) interactively, set mass and friction, generate collision meshes, and validate that the asset reacts correctly under gravity and contact. The output is a fully composed scene of physics-enabled assets that loads cleanly into Isaac Sim or other Omniverse-compatible runtimes. The friction sits upstream: every asset still has to arrive at USD Composer in a SimReady state to compose with it. Without good inputs, scene assembly stalls on per-asset physics authoring.
Rigyd: AI asset preparation that outputs OpenUSD + MJCF
Rigyd sits one step upstream of USD Composer. Input is a raw 3D model (.glb, .fbx, .obj), an image, or a text description. Output is a validated OpenUSD asset with USDPhysics schemas already applied, plus a MuJoCo MJCF export of the same asset. AI infers materials, estimates mass from volume times material density, computes friction from material classification, and generates the convex collision decomposition. The whole pipeline finishes in roughly five minutes per asset versus the four engineer-hours a manual workflow takes. Override values you have ground truth for (catalog masses, measured friction) so the AI estimate becomes a starting point, not a final answer.
They compose: Rigyd authors the assets, USD Composer assembles the scene
In practice, teams use both. Rigyd prepares the SimReady asset catalog at scale (hundreds to tens of thousands of SKUs) for the specific real environment being simulated. USD Composer pulls those assets into scenes, places them, composes layers, and previews the result. Output is then loaded into Isaac Sim or Isaac Lab for training. The decision is not "Rigyd or USD Composer"; it is "where does authoring happen and where does composition happen". For a small handful of hero assets, you can author end-to-end in USD Composer. Beyond that, the engineer-hours-per-asset cost of doing physics by hand makes AI asset prep the bottleneck breaker.
When to choose each
NVIDIA USD Composer
Composing OpenUSD scenes from a curated asset library, interactive previews, and authoring per-asset physics for small hero sets.
Rigyd
Producing the SimReady asset catalog itself, converting raw 3D, images, or text into validated OpenUSD + MJCF with AI-estimated physics at catalog scale.
Where Rigyd fits
Rigyd is designed to feed downstream composers and simulators, not to replace them. Outputs are validated OpenUSD; load them into USD Composer, Isaac Sim, Isaac Lab, MuJoCo, or Gazebo as-is.
Frequently asked questions
Does Rigyd output work in NVIDIA USD Composer?
Yes. Rigyd emits validated OpenUSD with USDPhysics schemas; USD Composer reads it as a standard USD asset, physics already applied. Drag, drop, and reference it like any other USD asset.
Can I add physics manually in USD Composer instead of using Rigyd?
Yes. USD Composer supports interactive physics authoring via the PhysX extension. The trade-off is engineer-hours per asset: about four hours for manual SimReady authoring versus about five minutes for AI-automated preparation. Manual still wins for hero assets with measured ground truth.
Which simulators consume the output of each tool?
USD Composer scenes load into NVIDIA Isaac Sim, Isaac Lab, and any Omniverse-compatible runtime. Rigyd outputs OpenUSD natively (for Isaac Sim, Omniverse, Unreal Engine, Unity, and Gazebo Sim USD imports) plus MJCF natively (for MuJoCo and MJX). URDF and SDF can be derived from the OpenUSD output via community converters when the downstream stack needs them.
Do I need both tools?
Common workflow: Rigyd handles asset preparation at catalog scale; USD Composer handles scene composition. For a few hero assets and small scenes, USD Composer alone is fine. For catalogs beyond a few dozen assets, doing physics by hand in USD Composer is the bottleneck Rigyd removes.
Generate your own catalog to SimReady
Upload any 3D model and get a physics-enabled OpenUSD asset in minutes, exports to MJCF, URDF, and FBX too.
Related reading
Synthetic data generation for computer vision in robotics
Real-world labeled robotics data is expensive and slow to capture. Synthetic data is fast and unlimited, but only useful if the underlying simulation has correct physics, semantic labels, and domain randomization. Here's the complete pipeline.
Digital twin creation pipeline for manufacturing
A factory digital twin needs every object to behave physically, not just render. This is the end-to-end pipeline: CAD intake, BIM merge, physics layer, semantic labeling, simulation runtime, at the asset volumes (10K+ unique SKUs) real factories actually contain.
How to set up mass, friction, and joint properties for robot training
The three pillars of robot physics setup, mass, friction, joints, determine whether your trained policy transfers to real hardware. Here's the calibration target for each, the schemas, and the common mistakes that quietly break training.