What is a SimReady asset and why does it matter for robot learning and evaluation

If you are building a robot learning or evaluation pipeline in 2026, the term you will run into more than almost any other is SimReady. It describes the difference between a 3D model that merely looks like an object and a 3D model a physics simulator can actually use. This guide explains what a SimReady asset is, the specific metadata that makes it simulation-ready, and why the supply of SimReady assets, rather than compute or the simulator itself, is usually the real bottleneck for training and evaluating robot policies.

Quick answer: A SimReady asset is a 3D model that carries the physics metadata a simulator needs to use it directly, including mass, friction, restitution, collision geometry, material properties, and semantic labels, packaged in a validated format such as OpenUSD or MJCF. A standard 3D model carries only visual geometry, so it has to be annotated by hand before a robot can interact with it in simulation. The gap between the small number of ready-made SimReady assets and the volume a real training run needs is the central problem in scaling robot learning.

What “SimReady” actually means

The term comes from NVIDIA, which defined a SimReady asset specification for Omniverse and Isaac Sim. The AIF Pipeline Samples documentation describes the standard in detail. The core idea is simple: a SimReady asset is built so a simulator can load it and immediately run physics on it, with no manual cleanup.

A standard 3D model, the kind you download from an asset store or export from a CAD tool, describes only how an object looks. It has a mesh, maybe textures and materials for rendering, and nothing else. Drop it into a physics simulator and the simulator has no idea how heavy it is, how its surface behaves on contact, or where its collision boundary sits. The object will fall through the floor, pass through other objects, or behave in ways that have nothing to do with the real world.

A SimReady asset closes that gap by carrying a second layer of information on top of the visual geometry: the physics.

The anatomy of a SimReady asset

A well-formed SimReady asset includes the following, each of which a simulator reads directly.

Mass and inertia

Mass, center of mass, and the inertia tensor determine how the object responds to forces and torques. A coffee mug and a steel weight of the same shape behave completely differently, and the difference is entirely in these values. In OpenUSD these live in the PhysicsMassAPI schema.

Friction and restitution

Static and dynamic friction govern whether a gripper can hold an object or whether it slides. Restitution governs how the object bounces. These are surface properties, expressed through a physics material such as PhysicsMaterialAPI. Get them wrong and a manipulation policy trained in simulation will fail the moment it touches a real object.

Collision geometry

The visual mesh is usually too detailed and too irregular for a physics solver to handle efficiently. A SimReady asset carries a separate collision mesh, often a set of convex hulls computed by convex decomposition, that approximates the shape for fast, stable contact resolution. This is one of the most error-prone parts to author by hand, and one of the most important to get right. For a deeper look, see our guide on collision mesh best practices.

Semantic labels

For perception training, each object needs a class label so the simulator can generate ground-truth segmentation and bounding boxes automatically. In OpenUSD this is the SemanticsAPI. This is what lets a single rendered frame double as a labeled training example.

A validated, structured format

Finally, all of this has to be packaged in a format the downstream tools accept, with a known coordinate convention (Z-up, metric units) and a structure that passes validation. The most common target is OpenUSD with USDPhysics schemas, which is native to Isaac Sim and Omniverse. For more on the format itself, see what is OpenUSD and why it matters for robotics and the OpenUSD vs SDF vs URDF vs MJCF comparison.

A minimal SimReady definition in OpenUSD looks like this:

def Cube "box" (
    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)
    token physics:approximation = "convexHull"
    rel physics:material = </World/Materials/RubberLike>
}

The same object as a plain .glb or .obj would carry the cube mesh and nothing in that physics block. That block is the entire difference between a 3D model and a SimReady asset.

Why it matters for robot learning

Training a robot policy in simulation means running the robot through millions of interactions: grasping, pushing, stacking, navigating. Every one of those interactions is a physics calculation, and that calculation is only as accurate as the assets involved.

If the mass is wrong, the policy learns the wrong force to apply. If the friction is wrong, it learns a grasp that slips in the real world. If the collision mesh is a loose box around a complex shape, the policy learns to grasp empty air. This is the core of the sim-to-real problem: a policy trained on inaccurate physics transfers poorly to a real robot. We cover this in detail in sim-to-real transfer and physics accuracy.

There is a second reason SimReady assets matter for learning: domain randomization. Robust policies are trained not on one version of an object but on thousands of variations, different masses, frictions, sizes, and appearances, so the policy generalizes rather than overfitting to one exact scene. That technique only works if you can generate that variety of physically accurate assets at scale. Without scalable SimReady asset generation, domain randomization is gated by how many assets your team can author by hand.

Why it matters for evaluation

Evaluation has the same dependency as training, with a sharper edge. When you evaluate a policy, you are trying to predict how it will perform in the real world before you deploy it on real hardware. If the evaluation scenes are built from assets with inaccurate physics, the evaluation number is misleading: a policy can score well against bad physics and fail in reality, or fail against bad physics and have been fine.

Reliable evaluation requires scenes that match the physics of the target environment, including the specific objects the robot will actually encounter. Generic objects from a small curated library cannot do that. This is why teams building serious evaluation harnesses need to generate SimReady versions of their own objects, not just download what already exists.

The coverage gap: why this is a bottleneck

Here is the structural problem. NVIDIA’s curated SimReady library holds roughly 1,000 assets. A single warehouse robotics deployment can involve 50,000 or more unique SKUs. A humanoid manipulation program needs every kind of household and industrial object it might touch. The supply of ready-made SimReady assets is orders of magnitude smaller than the demand.

Closing that gap by hand does not scale. Manually annotating a single 3D model with mass, friction, collision geometry, and semantic labels takes a skilled engineer on the order of hours. For tens of thousands of objects, that is a multi-year, multi-million-dollar effort before a single policy is trained. Asset preparation, not GPU time and not the choice of simulator, is the rate-limiting step in most simulation pipelines.

This is exactly the gap that automated, AI-driven asset preparation is built to fill. Instead of authoring physics by hand, a conversion pipeline estimates physics properties from the geometry and material, computes collision hulls automatically, and exports a validated SimReady file. For a walkthrough of that process, see how to convert 3D models to simulation-ready assets and how to create SimReady assets without manual modeling.

SimReady asset vs standard 3D model: a summary

Property	Standard 3D model	SimReady asset
Visual mesh and textures	Yes	Yes
Mass, center of mass, inertia	No	Yes
Friction and restitution	No	Yes
Collision geometry	No	Yes, distinct from visual mesh
Semantic labels	No	Yes
Loads into a physics simulator directly	No, needs manual annotation	Yes
Usable for robot learning and evaluation	No	Yes

Frequently asked questions

What is a SimReady asset in one sentence? A SimReady asset is a 3D model that carries the physics metadata a simulator needs to use it directly: mass, friction, restitution, collision geometry, material properties, and semantic labels, packaged in a validated format such as OpenUSD or MJCF. A standard 3D model carries only visual geometry and has to be annotated by hand before a robot can interact with it in simulation.

How is a SimReady asset different from a normal 3D model? A normal 3D model describes how an object looks: its mesh, textures, and materials for rendering. A SimReady asset adds how the object behaves: its mass and center of mass, friction and restitution, a separate collision mesh optimized for the physics solver, and semantic class labels for perception training. Without that physics layer, a simulator cannot model grasping, stacking, or contact, so the asset is not usable for robot learning.

Why are SimReady assets the bottleneck for robot learning? Training and evaluating a robot policy requires thousands of physically accurate objects across many scenes. NVIDIA’s curated SimReady library holds roughly 1,000 assets, while a single warehouse can contain 50,000 or more unique SKUs. Manually annotating each asset with physics properties takes hours of engineer time, so asset preparation, not compute or the simulator itself, is usually the rate-limiting step in scaling a simulation pipeline.

What physics properties does a SimReady asset include? A SimReady asset typically includes mass, center of mass, and inertia tensor; static and dynamic friction; restitution; a collision mesh distinct from the visual mesh; and material properties such as density. In OpenUSD these are expressed through USDPhysics schemas like PhysicsRigidBodyAPI, PhysicsMassAPI, PhysicsCollisionAPI, and PhysicsMaterialAPI. Semantic labels for perception are added through SemanticsAPI.

What formats are SimReady assets delivered in? The most common format is OpenUSD with USDPhysics schemas, which is native to NVIDIA Isaac Sim and Omniverse. MuJoCo uses MJCF, Gazebo uses SDF, and many ROS pipelines use URDF. Teams working across more than one simulator often need the same asset in more than one format, which is why conversion pipelines that export OpenUSD and MJCF from a single source are useful.

Key takeaways

1. A SimReady asset is a 3D model plus the physics metadata a simulator needs to use it directly: mass, friction, restitution, collision geometry, material properties, and semantic labels.
2. The physics layer, not the visual mesh, is what separates a SimReady asset from an ordinary 3D model and what makes it usable for robot learning.
3. Inaccurate asset physics is a direct cause of the sim-to-real gap. Both training and evaluation depend on the physics being right.
4. Domain randomization, which is essential for robust policies, only works if you can generate many physically accurate variations at scale.
5. The supply of ready-made SimReady assets is far smaller than what a real training run needs. Asset preparation is the bottleneck, and automated conversion is how teams close that gap.