Skip to content

Overview

View Markdown llms-full.txt

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

Section titled “Conformance is reported, never enforced”

A conformance failure does not fail your job and does not refund your credit. 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 jobWhy
USD/MJCF parity disagreementThe two files we hand you must describe one asset
An internal invariant violatione.g. the centre of mass does not resolve to the point we declared for it
A missing or unwritable exportThere is no asset to deliver
A rejected input manifestThe description does not match the mesh

When one of those trips, the job goes to failed, error is populated, and the credit is auto-refunded in the normal way. A completed job always has a downloadable asset, whatever its conformance verdict.

What we conform to

Section titled “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.

Reading the result

Section titled “Reading the result”

Scoring is per profile, and the same requirement can be a different answer under each one. COL.001 (SDF collision approximation) is not part of Prop-Robotics-Neutral at all, but it is required by Prop-Robotics-Physx and Prop-Robotics-Isaac — so a single asset reports N/A for it under the first and FAIL under the other two. 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"]


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. Prefer profiles_passing, or report.validation.profiles['<name>'].status for a single red/amber/green.

Where a Rigyd asset lands today

Section titled “Where a Rigyd asset lands today”

Every conversion available on this API produces a rigid-body prop, targets Prop-Robotics-Neutral, and passes it. Prop-Robotics-Physx and Prop-Robotics-Isaac fail on exactly two requirements, COL.001 and ISA.001, and both are scheduled work rather than defects — see What’s covered today.

Where to go next

Section titled “Where to go next”