NVIDIA / NVIDIA/simready-foundation
Request: Scene / Environment profile for multi-asset scene datasets
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 88
- Forks
- 18
- PR merge metrics
- No merged PRs in 30d
Description
Use case
Customer partners are publishing scene-style datasets to HuggingFace (e.g. imagineio/PhysicalAI-SimReady-Kitchens-v1) that don't fit cleanly into any existing profile family:
| Existing family | Why it doesn't fit |
|---|---|
Prop-Robotics-* |
These profiles validate single rigid prop assets. Scene datasets have many top-level Xforms (appliances, furniture, decorations) composed together, not single props. |
Robot-Body-* |
No articulation / no skeleton — these aren't robots. |
Package* |
Closest existing match, but packaging-level checks (BOM presence, manifest hash, conformance signatures) aren't what scene authors care about. Their content goal is "is this scene well-organized, does it compose, are the references resolvable" — orthogonal to packaging. |
We've been routing kitchen-style datasets to Package-Candidate as a least-wrong fallback, which surfaces a lot of "missing BOM" / "missing manifest" findings that are technically correct per the rules but operationally not useful for scene content.
What a Scene (or Environment) profile should probably cover
Rough sketch — open to refinement:
- Composition validity: every reference / sublayer resolves, no broken arcs.
- Top-level organization: scene root has a recognizable
World/SceneXform parent for top-level content (not naked geometry at /). - No overlapping bounding volumes at top level (or at least: warn when present).
- Asset bundle convention for each top-level component (own dir, own USD entry point, textures co-located).
- Layout & extent: scene content is positioned within sensible bounds (no assets at 10^15 in world coordinates).
- Material resolution: MDL / UsdPreviewSurface references all resolve.
- No unit-conversion landmines: stage
metersPerUnitandupAxisare set explicitly.
Things this profile probably should NOT do:
- Per-asset rigid-body / articulation validation (handled by existing Prop / Robot profiles when individual assets are validated in isolation).
- Packaging-level conformance (handled by Package family).
- Runtime kit-only checks (PhysX, Isaac actuator setup).
Reference dataset
imagineio/PhysicalAI-SimReady-Kitchens-v1 is a canonical example — 800 kitchen-scene zips, each containing assembled props (appliances, plants, mugs, etc.) arranged into a coherent scene. Currently fails to validate cleanly against any existing profile.
Surfaced by
The internal SimReady validator dashboard at simready-oem-library-pm — auto-detect heuristic flags scene content as Package-Candidate because no Scene profile exists in the foundation. Filing this so the foundation team can scope a proper profile.
Happy to contribute the spec PR once the foundation team is ready to design rule families for this — bandwidth's there.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing Prop-Robotics, Robot-Body, and Package-Candidate profile definitions and the auto-detect heuristic described in the issue. Compare them with the referenced PhysicalAI-SimReady-Kitchens-v1 dataset; done means an agreed Scene/Environment profile scope and rule-family specification that avoids unrelated packaging, robot, and runtime checks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100