Overview

Every asset that comes out of a Rigyd conversion is scored against the SimReady Foundation specification, and the result ships with the asset in report.validation.

If you have ever opened a USD in Isaac Sim and watched it fall through the floor, intersect itself, or refuse to articulate, you already know what this is for. Validation is the line between “loads in a viewer” and “drops into a simulator and behaves.”

Conformance is reported, never enforced

A conformance failure does not fail your job or affect billing. The asset is delivered either way, with the report attached.

That is deliberate. A non-conformant asset is still a usable asset, and you are better served by getting it with a red report than by getting nothing. Conformance describes our output against someone else’s specification; it is a description, not a gate.

What does fail a conversion is a different class of problem entirely — a statement about our own correctness rather than about the spec:

Fails the job	Why
USD/MJCF parity disagreement	The two files we hand you must describe one asset
An internal invariant violation	e.g. the centre of mass does not resolve to the point we declared for it
A missing or unwritable export	There is no asset to deliver
A rejected input manifest	The description does not match the mesh

When one of those trips, the conversion goes to failed and error is populated. Conversion is currently free; if Asset Composer created the prototype, its earlier generation charge is separate and is not reversed by a later conversion failure. A completed job always has a downloadable asset, whatever its conformance verdict.

What we conform to

The SimReady Foundation is an open specification layer on top of OpenUSD that defines what a simulation-ready asset must contain — naming and folder structure, units, hierarchy, geometry, visual and non-visual materials, semantic labels, rigid-body and collision physics, joints and articulation, and runtime-specific requirements for PhysX and NVIDIA Isaac Sim.

The foundation groups requirements into features and rolls features up into profiles — concrete bundles you can target. Rigyd’s validator does not keep its own list of requirements: the profile → feature → requirement map is joined at runtime from NVIDIA’s published metadata, so a requirement that moves between features, or a profile that gains one, moves here without anybody transcribing it.

We are not an authority on SimReady — NVIDIA is. Every check traces to a requirement they define.

Scored against spec release 2026.06.0

report.validation.spec_release names the release every verdict is scored against. We are pinned to 2026.06.0, the current SimReady Foundation release, and we run NVIDIA’s own simready-validate wheel at the matching version (2026.6.4) to check our answers against theirs. Reports issued before 19 August 2026 name 2026.04.1; the field is on every report so an older verdict never has to be guessed at.

Reading the result

Scoring is per profile, and the same requirement is a different answer under each one. ISA.001 (Isaac payload composition) is not part of Prop-Robotics-Neutral or -Physx at all, so one asset reports N/A for it under those two — with na_reason: "not-in-profile" — and a real PASS under Prop-Robotics-Isaac. There is no single global verdict that means anything.

The field to badge is profiles_passing:

const passing = job.report.validation.profiles_passing;
// ["Prop-Robotics-Neutral", "Prop-Robotics-Physx", "Prop-Robotics-Isaac"]

badge = passing.length
  ? `SimReady: ${passing.join(', ')}`
  : 'SimReady: no profile';

report.validation.overall still exists, but it is scoped to the profiles we target and is not a conformance claim about any particular one. It can be WARN while every targeted profile is PASS, because advisory findings remain visible. Prefer profiles_passing, or report.validation.profiles['<name>'].status for a single red/amber/green.

Where a Rigyd asset lands today

Rigyd produces simulation props made from one or more rigid bodies. They may be rigid or articulated, and the automated composition endpoint supports both. Current output targets and passes all three prop profiles — Prop-Robotics-Neutral, Prop-Robotics-Physx and Prop-Robotics-Isaac — with zero errors. All three are targeted, and profiles_passing names all three.

That is a change. Until August 2026 only Prop-Robotics-Neutral passed, and the other two failed on exactly two requirements: SDF collision approximation and the Isaac payload composition layout. Both have shipped:

• Colliders. The USD carries a collision_mode variantSet on /Root with two variants — sdf (the default selection, a signed-distance field over the visual mesh, which is what the PhysX and Isaac profiles ask for) and convexHull (the convex decomposition, which is what a CPU-dynamics scene can actually run, since PhysX simulates SDF colliders on GPU only). The file states both; you pick.
• Composition. The asset is no longer one flattened file. usd/<name>.usd is kind = "component" and composes payloads/<name>_base.usd (which references <name>_meshes.usd) plus a deferred payloads/<name>_physics.usd. Load base + meshes for a render-only view; the payload brings the physics.

Keep the `usd/` directory together

usd/<name>/<name>.usd is an entry point, not the whole asset: opening it without its payloads/ siblings gives you an empty stage. Your download ships the complete tree — see Download result — so unzip it and point your loader at the root layer, don’t extract a single file.

skip_validation no longer does what its name suggests

The skip_validation field is still accepted on the 3D → SimReady request, but it no longer skips conformance scoring. Every conversion is scored and every completed job carries a report.validation block, whether you send it or not.

On this route it only stops invariant findings from rejecting the job. It does not bypass required exports, and the authored articulated path always enforces USD/MJCF parity and articulation invariants. Leave it unset unless Rigyd support asks you to use it.

Where to go next

• What’s covered today — the profiles we target, what a delivered asset scores against each, and the one place we read the specification differently from NVIDIA’s own tool.
• What’s coming next — how our coverage tracks the foundation’s published profile families.
• Full requirement coverage — all 140 requirement codes and our status against each.