Isaac Sim asset requirements and best practices

NVIDIA Isaac Sim is the most widely deployed robotics simulator built on OpenUSD. Getting an asset to actually work well in Isaac Sim — not just load, but simulate physics correctly, support perception training, and run fast in million-step training loops — requires meeting a specific set of structural and physical requirements.

This guide is the practical checklist: what Isaac Sim expects, what breaks if you ignore each requirement, and how to validate before you commit thousands of training hours.

Format requirements

Isaac Sim is OpenUSD-native. The acceptable formats:

• .usd, .usda, .usdc, .usdz — preferred. All variants of OpenUSD; .usda is text/human-readable, .usdc is binary, .usdz is a packaged archive.
• .glb, .gltf, .fbx, .obj, .dae — these import via NVIDIA’s importer extensions. They convert to USD on import. You lose physics metadata in the conversion — the imported asset will have visual geometry but no USDPhysics schemas. You must then apply schemas manually or via the Property Editor.
• .urdf, .mjcf — via the URDF Importer and MJCF Importer extensions. Physics metadata transfers, but you’ll typically need to validate the converted USD for correctness.

Best practice: author or convert to USD upstream, with USDPhysics schemas already applied. Don’t rely on Isaac Sim’s import-time conversion to also handle physics setup.

Required USDPhysics schemas

Every dynamic (movable) prim in Isaac Sim needs three API schemas applied:

PhysicsRigidBodyAPI

Marks the prim as a rigid body. Without this, Isaac Sim treats the prim as a static mesh — gravity won’t pull it, forces won’t move it.

Key attributes:

• physics:rigidBodyEnabled — should be true for dynamic objects.
• physics:kinematicEnabled — true only if you’ll move the body via animation (not physics).
• physics:startsAsleep — true for objects that should rest still until disturbed (saves CPU).

PhysicsMassAPI

Carries mass, center of mass, and inertia. Without correct values, the body falls and reacts unrealistically.

Key attributes:

• physics:mass — total mass in kilograms. Critical: zero or unset means Isaac Sim infers from density × volume, which often goes wrong.
• physics:density — used only if physics:mass is unset; in practice, set mass directly and ignore density.
• physics:centerOfMass — local-space offset from the prim origin. Default zero is wrong for asymmetric objects.
• physics:diagonalInertia — principal moments of inertia. Default zero causes Isaac Sim to compute from geometry assuming uniform density, which is wrong for hollow or composite objects.

PhysicsCollisionAPI

Tells Isaac Sim that the prim participates in collisions, and how to compute its collision shape.

Key attributes:

• physics:collisionEnabled — must be true.
• physics:approximation — the most important attribute on the schema. Options:
  • "none" (use the visual mesh — slow, often broken)
  • "convexHull" (single convex hull — fast but loses concave features)
  • "convexDecomposition" (multiple convex hulls via V-HACD — best for dynamic graspables)
  • "meshSimplification" (decimated mesh — good for static obstacles)
  • "boundingCube" / "boundingSphere" (primitives — fastest, lowest fidelity)
• physics:material — relationship to a PhysicsMaterialAPI-tagged material defining friction and restitution.

Articulated mechanisms

For multi-link mechanisms (robot arms, manipulators, articulated objects), Isaac Sim expects:

• PhysicsArticulationRootAPI on the root prim of the articulated chain.
• Joint prims between links: PhysicsRevoluteJoint, PhysicsPrismaticJoint, PhysicsSphericalJoint, PhysicsFixedJoint.
• Drive APIs on actuated joints: PhysicsDriveAPI defining target position, velocity, stiffness, and damping.
• Joint limits via physics:lowerLimit and physics:upperLimit to prevent unrealistic poses.

Importing a robot from URDF gets most of this right. Authoring articulations by hand in USD is harder; most teams either start from URDF or use Isaac Lab’s robot definition tooling.

Material physics

PhysicsMaterialAPI-tagged materials carry the contact properties:

• physics:dynamicFriction — typical range 0.0–1.5.
• physics:staticFriction — typically slightly higher than dynamic.
• physics:restitution — bounciness, 0.0 (clay) to 1.0 (perfect rubber). Most real objects: 0.1–0.4.
• physics:density — only used by PhysicsMassAPI if mass is unset.

A common mistake: applying physics on the prim without binding it to a material. The body simulates with default friction (typically 0.5/0.5), which is rarely correct.

Semantic labels for perception

For perception model training, Isaac Sim needs object class labels via SemanticsAPI:

def Cube "box" (
    prepend apiSchemas = ["SemanticsAPI:class"]
)
{
    string semantic:class:label = "box"
    string semantic:class:type = "class"
}

The SemanticsAPI schema family also supports instance labels and segmentation masks. Without these, Isaac Sim’s Replicator framework can’t generate labeled synthetic training data.

Collision mesh best practices

Collision shape choice has the largest single impact on Isaac Sim performance:

Asset class	Recommended approximation	Reasoning
Static walls, floors, ceilings	meshSimplification or none (low-poly)	Static — minimal cost, exact shape
Static obstacles (shelving, machinery)	convexHull	Fast collision queries, accurate enough
Dynamic graspables (boxes, bottles, tools)	convexDecomposition	Captures concave features needed for grasp planning
Articulated mechanism links	convexDecomposition per link	Per-link decomposition captures joint clearances
Cluttered terrain (rocks, debris)	meshSimplification	Decimated mesh balances accuracy and speed

V-HACD parameters worth tuning:

• Resolution — higher = more accurate decomposition, slower at runtime. 100,000 is a reasonable default.
• Max convex hulls — typically 16–32 per object for graspables, 4–8 for furniture.
• Concavity threshold — lower = more hulls. 0.001 for manipulation-grade, 0.01 for navigation.

Iterating on V-HACD by hand is the part of manual SimReady authoring that’s most worth automating.

Validation: the SimReady checker

NVIDIA ships a SimReady validator as an Omniverse extension. Run it on every asset before it enters your training pipeline. The validator checks:

• USD prim hierarchy is well-formed
• All PhysicsRigidBodyAPI, PhysicsMassAPI, PhysicsCollisionAPI schemas applied where needed
• Mass and inertia values within plausible ranges
• Collision approximation set (not "none" for dynamic objects)
• Material bindings present and valid
• Semantic labels present

A green SimReady validation is a hard prerequisite for production deployment. Most asset bugs that show up at training time would have been caught by validation.

Common pitfalls

Specific failure modes I see repeatedly in robotics teams adopting Isaac Sim:

1. Importing FBX or glTF and forgetting to apply USDPhysics schemas. The asset loads, looks correct, but doesn’t simulate. Easy to miss in a visual review.
2. Using physics:approximation = "none" on a high-poly visual mesh as a “shortcut.” Crashes the physics solver under heavy contact, or runs at 5 Hz instead of 60.
3. Setting physics:mass = 0. Isaac Sim falls back to density × volume, which is often wildly wrong. Always set mass explicitly.
4. Default identity inertia on tall or thin objects. A 2m-tall robot with default inertia will tip implausibly. Compute inertia from geometry.
5. Missing semantic labels on training assets. Replicator generates images but no segmentation masks. Discovered after a training run.
6. Material bindings that point at materials without PhysicsMaterialAPI. Visual rendering works; physics uses defaults. Drops show up in policy performance, not in inspection.
7. Authoring articulations with the wrong drive parameters. Joint stiffness/damping that’s correct in MuJoCo translates poorly to Isaac Sim’s solver. Tune in-sim, not from documentation.

A pragmatic adoption sequence

If you’re a robotics team adopting Isaac Sim today:

1. Pilot with hero assets — author 5–10 SimReady assets manually so you understand the schema details and Isaac Sim’s behavior.
2. Validate every asset with the SimReady checker before it enters your training pipeline.
3. Automate the long tail — for any project beyond ~50 assets, AI-driven SimReady generation (including Rigyd) outpaces manual authoring by ~50× and produces validator-passing OpenUSD with reasonable physics defaults.
4. Override specific values where you have measured ground truth — known masses for catalog SKUs, lab-measured friction coefficients for your specific surfaces.
5. Invest in domain randomization rather than 1% physics accuracy on every asset. Calibrated estimates inside DR variance bands transfer about as well as measured values, at a fraction of the engineering cost.

Isaac Sim rewards teams that treat asset preparation as a pipeline, not a per-asset task. The teams running 10,000+ object simulations productively are universally automating SimReady generation, applying validators in CI, and reserving human attention for policy work — not asset cleanup.