What's coming next

The SimReady Foundation specification is itself young — the team’s stated position is that it “currently covers basic static props (ones that don’t move or articulate)”, with the broader profile set being filled in as the foundation grows. Rigyd’s coverage moves with it.

Where we are

Rigid and articulated conversions target the whole prop family — Prop-Robotics-Neutral, -Physx and -Isaac — and current output passes all three. Everything below is what it would take to claim the next profile: named requirements, not aspirations.

Profile family	Foundation profiles	Rigyd
Props	Prop-Robotics-Neutral	Live — targeted and passing
	Prop-Robotics-Physx	Live — targeted and passing, since August 2026
	Prop-Robotics-Isaac	Live — targeted and passing, since August 2026
Robot bodies	Robot-Body-Neutral · -Runnable · -Isaac	Further out — needs driven joints; see below
Packaging	Package · -NoBOM · -Candidate	Scored, reported INCOMPLETE. These describe a distribution package rather than a single asset file

The two requirements that used to block PhysX and Isaac

Both shipped in August 2026. They are recorded here because reports issued before then name them as failures, and because the shape of what changed matters if you built against the old output.

• SDF collision approximation. We authored convex-hull colliders only. The USD now carries a collision_mode variantSet on /Root — sdf selected by default, convexHull still present and still authored outside the variantSet so a plain viewer can draw the hulls. Nothing was taken away; a second answer was added, and it is the one the PhysX and Isaac profiles ask for.

  At spec release 2026.06.0 the code that asked for this, COL.001, was dropped from every prop profile in favour of the structural pair PHYSX.COL.001 / PHYSX.COL.002. We still author SDF regardless — the requirement still exists, is still tagged essential, and Isaac’s own prose still instructs physics:approximation = "sdf" under a heading marked (required).

• ISA.001 — Isaac composition layout. We shipped one flattened USD. The asset is now a kind = "component" entry point composing payloads/<name>_base.usd → <name>_meshes.usd, with physics deferred behind payloads/<name>_physics.usd. Collision geometry and the collision variantSet live in the physics layer, so a render-only consumer can skip them.

If you address a single USD file, that changed

Before the composition work, usd/<name>.usd was the whole asset. It is now an entry point that composes its payloads/ siblings, and opening it on its own yields an empty stage. Consume the directory, not the file — Download result shows the tree your archive contains.

Articulation

The pipeline builds articulated assets — ArticulationRootAPI, UsdPhysics revolute and prismatic joints with real limits, per-link mass and inertia — and scores them exactly like rigid props. Request one with POST /api/compositions/generate by setting asset_class: "articulated"; set auto_submit: true to continue directly into SimReady conversion.

Articulated assets are scored with the same requirement set as everything else. There is no separate articulated profile in the specification and no separate family of codes on our side; joint and articulation requirements are simply part of the registry, and an asset either meets them or does not:

	Status
JT.001–JT.003, JT.ART.001–JT.ART.004 (joints, articulation roots)	Checked
BA.001 (at least one ArticulationRootAPI)	Checked
BA.002 (non-adjacent colliders don’t clash at the default pose)	Planned — needs a simulation step a structural validator doesn’t run
HI.009 (hierarchy reflects the kinematic chain)	Planned

A correction, if you built against an earlier version of this page

This page previously described articulation support in terms of an AR.* family of codes and a profile called Articulated-Robotics-Neutral. Neither exists in the SimReady specification. They were ours: sixteen invented codes under a profile name that was never published, and routing articulated assets to them meant those assets skipped every naming, packaging, material, texture and path check in the real registry. They are gone, and articulated assets are now scored against NVIDIA’s requirements like everything else.

Robot bodies

The Robot-Body-* profiles are a further step rather than a flag flip. They require driven joints — FET022_DRIVEN_JOINTS_NEUTRAL and FET024_BASE_ARTICULATION — meaning actuated joints carrying drive specifications and joint-state APIs. Rigyd’s joints are passive: damping and friction sourced from real mechanism profiles, with no target or motor. A manipulable prop and a commandable robot body are different products.

The gap is concrete, and smaller than it was. Against Robot-Body-Neutral’s 37 requirements a delivered prop leaves four unwritten — DJ.001, DJ.002, DJ.003, DJ.011, all driven-joint rules — which is why it reports INCOMPLETE rather than being quietly rounded up to a pass. Robot-Body-Runnable leaves 13 unwritten of 48, and Robot-Body-Isaac 20 of 48, adding the eight RC.* robot-core requirements on top.

Robot-Body-Isaac additionally reports a FAIL on VG.001. That one is our own check misfiring under the default sdf collision variant, not something the asset is missing — see What’s covered today.

Tracking the specification itself

We validate against spec release 2026.06.0, the current SimReady Foundation release, and we run NVIDIA’s own validator at the matching wheel version (simready-validate 2026.6.4) so every verdict of ours can be checked against theirs. The pin moved from 2026.04.1 in August 2026, once a working wheel for 2026.06.0 was published — validating against a release we cannot run their tool on would mean we could no longer check our answers.

Moving the pin is a deliberate act with a checklist: re-vendor their metadata, diff the requirement set, re-run both verification assets through our validator and theirs. 2026.06.0 added four requirement codes (140, up from 136), swapped COL.001 for the PHYSX.COL.* pair in the prop profiles, and turned the “optional feature” marker from a TOML comment into a real field. A new requirement we fail is a report change, not an emergency, because conformance never fails a job.

report.validation.spec_release always names the release a given verdict was scored against, so a report never has to be guessed at after the fact.

When the foundation publishes additional profiles — vehicles, characters, environments, all signposted as future work in the SimReady overview — our coverage tracks them. The profile map is joined from their metadata rather than transcribed, so adding a profile means adding a target, not rewriting the engine.