simready-foundation: SimReady Foundation: NVIDIA’s Compiler for Physical Reality
How a USD-based standard turns 3D assets into simulation-ready contracts, catches physics bugs before runtime, and tries to end the chaos of incompatible units, joints, and runtimes.
- SimReady treats 3D assets like code, enforcing simulation correctness before anything reaches a runtime.
- Its real innovation is not just validation, but a layered contract system built from capabilities, requirements, and tags.
- The repository also includes transformation logic, which means it can rewrite assets for a target simulator instead of only rejecting them.
- SimReady sits above file formats and below physics engines, trying to define what it means for an asset to be safe to simulate.
The compiler metaphor is not hype
Most 3D pipelines still ask a simple question: does it look right? SimReady asks a harsher one: will this asset survive physics, robotics, and sensor simulation without breaking the stack? That is why the repo feels less like a toolkit and more like a compiler for physical reality.
The shift matters because simulation bugs are expensive in a way visual bugs are not. A bad texture is annoying. A bad root prim, a wrong unit scale, or a non-tree articulation can poison an entire training run or make a robot model collapse the moment a solver touches it.
Simulation-ready, or “SimReady,” refers to a standard and ecosystem for physically accurate 3D assets and digital twins that incorporate real-world properties, behaviors, and data bindings (e.g., physics).
Why simulation assets need a contract
The repo is built around failure modes that 3D interchange formats usually leave to humans. Units disagree. Axes disagree. Joint graphs stop being trees. Physics metadata is missing or inconsistent. Each of those problems can be tolerated in a modeling tool and then explode later in a simulator.
{
"capabilities": ["geometry", "physics-rigid-bodies", "units"],
"requirements": ["UN.002", "DJ.011"],
"tags": ["essential", "performance", "high-quality"]
}That structure matters because it lets the standard express levels of compliance instead of one blunt verdict. A model can be acceptable for one use case and still fail a stricter tier. In other words, SimReady is trying to turn simulation readiness into something measurable, not subjective.
Inside the spec layer
The source of truth lives in JSON configs under nv_core/sr_specs/config/. Those files define requirements and capabilities outside the validator code, which means policy is data, not hard-coded behavior. That is a quietly powerful choice because it lets the standard evolve without rewriting the whole engine.
The tags are especially revealing. They let NVIDIA distinguish essential rules from performance-oriented or high-quality ones. That gives the standard a kind of grading system, which is exactly what a simulation ecosystem needs if it wants assets to move across tools without collapsing into one lowest-common-denominator format.
A useful way to think about the layers
| Layer | What it defines | Why it matters |
|---|---|---|
| Capabilities | What kind of asset behavior is being governed | Keeps rules grouped by domain instead of scattered across code |
| Requirements | Atomic checks such as units or articulation constraints | Makes compliance machine-readable |
| Tags | Tiering such as essential, performance, or high-quality | Lets the same asset be judged at different strictness levels |
| Validation code | How the checks are executed | Separates enforcement from policy |
The validator does more than say pass or fail
The validation engine is where the contract becomes real. The repository uses a decorator-based registration pattern, so checks can be attached as named rules rather than buried inside one monolithic function. That design keeps the validator extensible, which matters when the spec itself is expected to grow.
One example stands out: the root-prim check. The code walks the stage and verifies that the hierarchy has exactly one root prim. That sounds almost trivial until you remember what it protects against. For robotics and articulation, a scattered hierarchy is not just messy. It is mathematically awkward or outright invalid.
The repo also leans on a registration pattern that makes validation logic feel modular rather than centralized. That is the right shape for a standards project. You want rules that can be added, versioned, and tiered without turning the whole system into a brittle script.
@omni.asset_validator.core.registerRule("Hierarchy")
class HierarchyHasRootChecker:
def validate(self, stage):
# ensure exactly one root prim exists
...The transformation layer is the real surprise
This is where SimReady stops looking like a linter and starts looking like a compiler. Under nv_core/cip_specs/asset_handler_modules/, the repo contains transformation logic that can move an asset from a neutral state toward a runtime-specific one. That means the system does not only police assets. It can prepare them.
That distinction is huge. A validator says no. A transformer says, not yet, then rewrites the input until it meets the target contract. For simulation pipelines, that is the difference between a gatekeeper and an operator.
In practical terms, this is how a generic USD asset can become something Isaac Sim can actually use. The pipeline injects schemas, applies rules, and normalizes assumptions so the asset arrives with the right physics and runtime semantics attached.
SimReady is not in the same category as glTF or MuJoCo
The cleanest way to position the project is by category. glTF and FBX are asset interchange formats. MuJoCo and Bullet are simulation engines or physics frameworks. SimReady sits above both of those layers as a contract system for physically faithful assets.
| Project | Category | Primary job | Where SimReady differs |
|---|---|---|---|
| glTF | Interchange format | Moves assets between tools | Does not define simulation contracts |
| FBX | Interchange format | Carries 3D content across applications | Focuses on exchange, not physics validity |
| MuJoCo | Simulation engine | Runs physics and control | Consumes assets, but does not standardize them |
| Bullet | Physics framework | Simulates dynamics and collisions | Is a runtime, not an asset standard |
| SimReady | Contract layer | Defines and validates simulation-ready assets | Standardizes the rules before execution |
That is the dividing line. SimReady is not trying to replace the renderer, the simulator, or the file format. It is trying to define the conditions under which a model is safe to hand off to them.
What this standard is really trying to become
The big ambition is bigger than one repo. SimReady is trying to become a common language for digital twins, robotics training, and physically grounded AI workflows. If it works, the value is not just cleaner assets. It is fewer hidden assumptions between tools, teams, and runtimes.
That makes the project feel foundational rather than finished. It is an early standard, not a turnkey product. But that is also why it matters: standards become important when they start defining what everyone else has to agree on.