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

Every conversion available on this API produces a single rigid-body prop and targets Prop-Robotics-Neutral, which it passes. 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 — every conversion targets it and passes
	Prop-Robotics-Physx	Next — one requirement short: COL.001
	Prop-Robotics-Isaac	Next — two requirements short: COL.001, ISA.001
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 between us and PhysX / Isaac

Prop-Robotics-Physx and Prop-Robotics-Isaac are Prop-Robotics-Neutral plus COL.001 and ISA.001. Both are reported as genuine failures on every conversion today rather than deferred to “validated at runtime” — that phrasing was a way of not answering.

• COL.001 — SDF collision approximation. We author convex-hull colliders. SDF changes contact behaviour for every asset already delivered, so it needs an acceptance run of its own.
• ISA.001 — Isaac composition layout. We ship one flattened USD. Isaac composition is a packaging architecture — kind='component', a payloads/ tree, the asset split into _base.usd + _physics.usd.

Both are exporter work with a known shape. Neither is blocked on the specification.

Articulation

The pipeline already builds articulated assets — ArticulationRootAPI, UsdPhysics revolute and prismatic joints with real limits, per-link mass and inertia — and they pass Prop-Robotics-Neutral alongside the rigid props. What is not yet here is the API surface to ask for one: every endpoint on this site produces a rigid prop today.

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 (exactly 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. Against Robot-Body-Neutral’s 30 requirements we have rules for 26; the eleven DJ.* driven-joint requirements, the eight RC.* robot-core ones and the two RM.* robot-material ones are all unwritten, which is why those profiles report INCOMPLETE or FAIL rather than being quietly rounded up.

Tracking the specification itself

We validate against spec release 2026.04.1 while the specification has moved on to 2026.06.0. That gap is a decision, not neglect: 2026.04.1 is the newest release with a working published validator wheel, and validating against a release we cannot run their tool on would mean we could no longer check our answers against theirs.

Moving the pin means re-vendoring their metadata, diffing the requirement set, and re-running both verification assets through our validator and theirs — 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.