How to convert GLTF/FBX/OBJ to OpenUSD for simulation

If you’re standing up a robotics simulation in 2026, your assets probably arrive as GLTF, FBX, or OBJ from a CAD pipeline, scan output, or 3D content marketplace. Your simulator — almost certainly NVIDIA Isaac Sim, Omniverse, or any USD-native runtime — expects OpenUSD. The conversion step in between is where most asset pipelines lose time, fidelity, or physics metadata.

This guide explains exactly what each format carries, the four practical conversion paths (Omniverse, Blender, command-line, AI-automated), and what to validate before you commit to a training pipeline.

What each format actually carries

The conversion question is really four sub-questions: geometry, materials, hierarchy, and animation. Each format handles them differently.

Capability	GLTF (.glb / .gltf)	FBX	OBJ
Geometry (mesh)	✅ Triangles + UVs	✅ Triangles or polygons	✅ Triangles or polygons
PBR materials	✅ Native (PBR core)	⚠️ Vendor-specific extensions	❌ Lambert/Phong only
Texture maps	✅ Embedded or external	✅ External	✅ External
Skeletal animation	✅ Native	✅ Native	❌ Not supported
Morph targets	✅ Supported	✅ Supported	❌ Not supported
Cameras, lights	✅ Supported	✅ Supported	❌ Not supported
Physics metadata	⚠️ Via extensions only	❌ Not standard	❌ Not supported
Scene hierarchy	✅ Native	✅ Native	⚠️ Flat by default
File size	Compact (binary)	Bloated (verbose binary)	Large (text)

The practical implication: GLTF (.glb) is the cleanest source format. FBX is widely supported but its proprietary nature makes non-Autodesk conversions lossy. OBJ is fine for raw geometry but loses everything else.

What OpenUSD adds that source formats don’t

USD isn’t just another mesh format. It carries categories of information that GLTF/FBX/OBJ don’t:

• Layered composition — multiple files contributing or overriding each other (animation, physics, variants)
• References and instancing — one master asset reused thousands of times with flat file size
• Variants — multiple versions of a prim selectable at runtime
• Schema-typed metadata — physics, semantics, materials all attached via well-defined APIs
• USDPhysics — PhysicsRigidBodyAPI, PhysicsMassAPI, PhysicsCollisionAPI, articulation joints
• SemanticsAPI — per-prim class labels for perception training

Conversion to USD is usually the first step. The harder work is adding the physics, semantics, and material physics on top.

The four conversion paths

1. NVIDIA Omniverse (USD Composer)

The reference path for converting into USD destined for Isaac Sim or Omniverse Replicator.

How it works:

• Open USD Composer (formerly Create)
• File → Import → choose your .glb, .fbx, or .obj
• The CAD/3D Importer extension converts to USD layers in your stage
• Save the stage as .usd or .usdc

Strengths:

• Best-in-class FBX → USD conversion (Autodesk and NVIDIA collaborate on this)
• Handles textures, materials, hierarchy correctly
• After conversion, you can apply USDPhysics schemas interactively in the Property Editor

Limits:

• Manual physics work after conversion (typically 30-90 minutes per asset for full SimReady authoring)
• Heavy GUI workflow — hard to script for thousands of assets
• Requires an RTX-class GPU for the full Composer experience

2. Blender (USD export)

A free, scriptable path.

How it works:

• File → Import → bring in .glb, .fbx, or .obj
• Verify materials and hierarchy
• File → Export → Universal Scene Description (.usd)
• Optionally add custom physics via Blender’s USD hooks (advanced)

Strengths:

• Free, open source, runs anywhere
• Python-scriptable for batch conversion
• Handles geometry and basic materials cleanly

Limits:

• USD export quality has improved a lot but lags Omniverse for complex materials
• No physics authoring — purely a format converter
• Material conversion sometimes drops PBR maps into Blender’s principled shader, which doesn’t always round-trip cleanly to USD

3. Command-line tools (USD CLI, gltf2usd, etc.)

For automated pipelines.

• usdcat — convert between USD ASCII (.usda), binary (.usdc), and packaged (.usdz).
• gltf2usd (GitHub) — direct GLTF → USD converter, originally from Apple’s tooling.
• fbx2usd — part of Pixar’s USD distribution, good for FBX-only inputs.
• obj2usd — minimal converter; for clean OBJ → USD.

Strengths:

• Headless, scriptable, fits CI pipelines
• Predictable output, good for reproducible builds

Limits:

• Material conversion is often weaker than GUI tools
• No physics or semantics — purely format translation
• Setup and dependency management can be finicky (USD library version, Python bindings)

4. AI-automated (Rigyd)

A hosted pipeline that combines conversion with physics estimation, semantic labeling, and validation.

How it works:

• Upload .glb, .fbx, or .obj
• AI handles geometry analysis, material identification, mass and friction estimation, collision-mesh generation, semantic labeling
• Output is a SimReady OpenUSD file in 3-6 minutes

Strengths:

• Single-step: format conversion and physics setup
• Calibrated mass within 15-20% of measured, friction within ±0.1
• Output passes the NVIDIA SimReady validator
• Bulk-processable via Enterprise API for entire asset catalogs

Limits:

• Hosted (network upload required)
• AI estimates, not measurements — overrides available when you have ground truth
• Not yet supporting custom shaders or unusual material types

Step-by-step: GLTF → USD (the cleanest path)

Worked example with Omniverse, the reference workflow:

1. Verify the source. Open the .glb in any GLTF viewer (e.g., gltf-viewer.donmccurdy.com) to confirm geometry, materials, and texture maps render correctly.
2. Import into USD Composer. File → Import → select the file. Composer creates a new USD stage with imported prims.
3. Inspect the prim hierarchy. A clean GLTF usually produces /Root/MeshNode/... with separate prims for each mesh part. Watch for unnamed prims or merged meshes that should be separate.
4. Apply USDPhysics schemas. Select the dynamic prim → Property Editor → Add → Physics → Rigid Body API. Repeat for Mass API and Collision API.
5. Set physics parameters. Mass (kg), friction coefficients via material binding, collision approximation (convexDecomposition for graspables, convexHull for static).
6. Export the USD. File → Save As → .usd or .usdc. The latter is binary and faster to load at runtime.
7. Validate. Run NVIDIA’s SimReady validator extension. Fix any flagged issues (missing collision approximation, invalid inertia, broken material bindings).

The same workflow in Blender drops steps 4-5 (no physics authoring) and you’d add physics in a downstream USD editor or via scripting. The same in Rigyd collapses steps 1-7 into a single upload-and-download.

What gets lost (and how to recover it)

FBX → USD typical losses:

• Custom material shaders. Convert to PBR before exporting from your DCC.
• Maya/Max-specific attributes. Re-author in USD if needed.
• Animation curves with non-linear interpolation. Bake to keyframes before export.

GLTF → USD typical losses:

• GLTF KHR extensions that don’t map to USD primitives. Most are non-essential (lights extension is the most common loss).
• Embedded animation timing precision — can shift by a few ms in conversion.

OBJ → USD typical losses:

• Everything except triangles and basic materials. Treat OBJ as “geometry only” and reauthor materials downstream.

Adding physics: USDPhysics layered on top

Once you have a clean USD asset, the physics layer is added on top — usually in a separate USD layer for clean separation. The minimum schemas:

def Xform "Asset" (
    prepend apiSchemas = ["PhysicsRigidBodyAPI", "PhysicsMassAPI", "PhysicsCollisionAPI"]
)
{
    float physics:mass = 0.5
    vector3f physics:centerOfMass = (0, 0, 0)
    vector3f physics:diagonalInertia = (0.001, 0.001, 0.001)
    bool physics:collisionEnabled = true
    token physics:approximation = "convexDecomposition"
    rel physics:material = </Materials/RubberLike>
}

The values for mass, friction, and inertia are where the manual workflow gets slow. Material identification and density lookup gets you to ±20% accuracy quickly; tighter calibration takes lab measurement.

Validation checklist before training

Before any converted asset enters a training pipeline, verify:

• ✅ USD prim hierarchy is well-formed (no unnamed prims, no orphans)
• ✅ Materials render correctly in the target simulator (not just in the converter)
• ✅ Physics schemas applied to dynamic prims with non-default values
• ✅ Collision approximation set (not "none" for dynamic objects)
• ✅ Inertia tensor is non-zero and physically plausible
• ✅ Asset passes the NVIDIA SimReady validator
• ✅ Asset loads and falls correctly under gravity in the target simulator

A green pass on all of these means the asset is training-ready. A failure on any one means the conversion or physics step needs to be redone.

Practical recommendations

For most robotics simulation teams in 2026:

• Source assets in GLTF when you can. It’s the cleanest path through any conversion tool.
• Use Omniverse for hero assets that warrant the manual physics authoring time (5-20 mission-critical objects).
• Use AI-automated conversion (Rigyd or similar) for the long tail — anything beyond ~50 assets where the per-asset accuracy band of ±20% mass and ±0.1 friction is acceptable.
• Keep physics in a separate USD layer from visual geometry. This makes overrides, validation, and updates clean.
• Validate every asset before it enters the training pipeline. The cost of a bad asset compounds across millions of training steps.

The conversion step itself isn’t the hard part anymore — modern tooling handles the geometry and material translation well. The hard part is the physics that gets layered on top, and getting it right at the asset diversity training pipelines actually need.