Asset Validation

Tool Reference

Isaac Sim validates USD assets against the shared SimReady requirements. The validation rules that were previously built into the isaacsim.asset.validation extension have been migrated to the SimReady foundation validation tiers and are now the single source of truth.

While some of the rules cover recommended guidelines, such as the Asset Structure, many are fundamental to the asset working properly in Isaac Sim.

SimReady Foundation

The authoritative specifications — capabilities, features, profiles, and per-requirement documentation — live in the SimReady Foundation open-source repository:

https://github.com/NVIDIA/simready-foundation

The full specifications are under nv_core/sr_specs/docs/ in that repository. Relevant entry points:

• Getting Started: nv_core/sr_specs/docs/guides/getting_started.md — who SimReady is for, how to choose a profile, and where to go next.

• Validation Workflow: nv_core/sr_specs/docs/guides/validate_workflow.md — running simready-validate, expected output, and troubleshooting.

• Capabilities & Requirements: nv_core/sr_specs/docs/capabilities/ — per-requirement documentation (e.g. RB.008 rigid-body detailed mass, DJ.004 joint has drive or mimic API, RC.005 physics attributes authored in the physics layer).

Where the rules live

The rules are split across two SimReady foundation tiers, each published as a Python package:

Validation tiers

Tier package	Contents
simready-foundation-tier-core	General physics and geometry rules: rigid bodies, colliders, driven joints (drives, joint state, mimic, transforms), and articulation.
simready-foundation-tier-isaac	Isaac-specific rules: robot core (naming, folder cleanliness, robot schema, physics-layer authoring, thumbnails) and robot materials (nested materials, top-level Looks).

How validation runs

The isaacsim.asset.validation extension prebundles the two tier wheels and imports their capability hubs during startup. The tier decorators register their rules with the shared usd_validation_nvidia registry used by omni.asset_validator.core. You can run the rules from the SimReady Asset Validation window, the Asset Validator window, or through the simready-validate framework.

The extension comes enabled by default. If it is ever disabled, it can be re-enabled from the Extension Manager by searching for isaacsim.asset.validation.

To open the profile-driven workflow, navigate to Window > SimReady Asset Validation. For fine-grained rule selection, navigate to Window > Asset Validator. For more information on the Asset Validator window, refer to Asset Validator.

Note

Some checks — notably the non-adjacent collision-mesh check — run a live PhysX simulation step and therefore require the Isaac/Kit physics runtime. In a standalone USD-only environment, those checks report no results rather than failing.

Running the Validation Rules

Isaac Sim provides two complementary ways to run SimReady validation:

• Window > SimReady Asset Validation — profile-driven workflow for robot and prop assets. Prefer this for day-to-day robot asset QA.

• Window > Asset Validator — category and rule checkboxes for fine-grained rule selection. Prefer this when you need to enable or disable individual rules across mixed categories.

The remainder of this section documents the SimReady Asset Validation window.

SimReady Asset Validation Window

Open the window from Window > SimReady Asset Validation. It docks to the left of the viewport.

The extension comes enabled by default with isaacsim.exp.full. If it is disabled, enable both isaacsim.asset.validation and isaacsim.asset.validation.ui from the Extension Manager.

Validate a Robot Asset with the Robot Assets Profile

1. Open or create the USD stage that contains the robot you want to validate.

2. Navigate to Window > SimReady Asset Validation.

3. In the Asset section, select Use Current Stage so the validator includes unsaved edits on the open stage. Alternatively, select Browse USD… or enter a path and select Use Path to validate a file without loading it as the current stage.

4. In the SimReady profile section, open the Profile combo box and select Robot Assets.

   The selector shows readable labels. Robot Assets is the display name for the bundled Robot-Body-Isaac profile. Props is the display name for Prop-Robotics-Isaac.

5. Confirm the Version value. The newest bundled version is selected by default.

6. Review the required and optional feature counts under the profile controls. Enable any optional features you want included before validation.

7. Select Validate.

When validation finishes, the summary bar reports counts for Pass, Fail, Warning, Error, and Not implemented. Expand a feature group in the results tree to inspect individual requirements and findings.

Example: reviewing a failure

The screenshot above shows a typical Robot Assets run against the bundled Robotiq 2F-85 gripper:

• Summary: Pass: 33 | Fail: 14 | Warning: 1

• Feature group Minimal Editor contains a failed AA.001 requirement (anchored-asset-paths) with 13 findings

• Each finding row lists the message, severity, and the layer or prim it applies to

• The Selected result panel shows the affected location, feature, category, validator class, guidance text, and whether an auto fix is available

Enable Failures only to hide passing requirements and focus on remediation:

Window Controls

Asset

Control	Description
Use Current Stage	Validate the open USD stage, including unsaved edits.
Browse USD…	Choose a .usd, .usda, .usdc, or .usdz file from disk.
Path field / Use Path	Type or paste an asset URI or absolute path, then apply it as the validation target.

SimReady profile

Control	Description
Profile	Selects the SimReady profile. Default filtered labels include Robot Assets and Props.
Version	Selects a version of the chosen profile. Versions are listed newest first.
Optional feature checkboxes	Appear when a profile declares optional features. Enabled optional features are included in the next run.

Command bar

Control	Description
Validate	Starts an asynchronous profile validation run. Disabled until an asset and profile are selected.
Cancel	Appears only while a run is active. Cancels the in-flight validation task.
Progress bar	Shows completion percentage for the active run.
Status text	Reports stage or path selection, progress, completion, and error messages.
Export Report…	Writes every requirement result and finding to a JSON file after a completed run.

Results and filters

Control	Description
Summary bar	Aggregated Pass, Fail, Warning, Error, and Not implemented counts.
Filter	Case-insensitive search across requirement codes, names, guidance, categories, rules, and finding messages.
Failures only	Hides requirements that passed.
Actionable only	Shows only requirements that have at least one finding with a validator-provided fix.
Results tree	Groups results by feature, then requirement, then finding. Columns show status and rule or USD location.

Selected result

Select a requirement or finding to populate the details panel.

Control	Description
Location banner	Highlights the affected USD path or prim, plus whether an auto fix is available.
Guidance and finding text	Requirement guidance, severity, validator message, and suggested action when present.
Open requirement docs	Opens the published SimReady requirement page for the selected code.
Copy details	Copies the selected requirement and finding details to the clipboard.
Select affected prim	Selects the reported prim on the current stage when a prim path is available.
Apply fix	Enabled only when the finding provides a fix callback and a valid edit target on the current stage. Shows a confirmation dialog, applies the fix without saving the stage, and re-runs validation.

Note

Fixes are not available for assets validated only by file path. The stage is never saved automatically after an applied fix.

Export Report… writes every requirement result and finding to a JSON file, including the profile, selected features, status summary, validator rule, severity, USD location, and repair suggestion for each finding.

Validation Rules Reference

The tables below enumerate every rule registered by the SimReady foundation tiers (plus the Isaac runtime collision check) as it appears in the Asset Validator, grouped by its registered category. The canonical, per-requirement documentation lives in the SimReady Foundation repository under nv_core/sr_specs/docs/capabilities/.

Rule categories

Category	Focus	Rules
AtomicAsset	Asset reference portability (anchored paths, supported file types).	2
BaseArticulation	Articulation root presence and collision-mesh clash checks.	2
BomStructure	Bill-of-materials presence and structural integrity.	1
ColliderApproximations	Mesh collider approximation requirements.	1
ConformanceMetadata	Conformance metadata packaging requirements.	1
Geometry	Mesh topology, normals, extents, positioning, and pivots.	12
HashObjectFormat	Hash object packaging conformance.	1
Hierarchy	Prim hierarchy, default prim, and Xform grouping rules.	8
IsaacComposition	Isaac Sim payload/reference composition structure.	1
MetadataFiles	Metadata file format packaging requirements.	1
NamingPaths	Prim, file, directory naming and path resolution rules.	8
PackageStructure	Package definition validity.	1
PhysicsDrivenJoints	Drives, joint state, mimic APIs, transforms, and articulation topology.	11
PhysicsGraspable	Graspable-asset annotation requirements.	1
PhysicsGrippers	Gripper site API (Isaac format).	1
PhysicsJoints	Joint connectivity and articulation nesting.	3
PhysicsMaterials	Physics material binding on colliders.	1
PhysicsRigidBodies	Rigid bodies, mass, and collider configuration.	15
RobotCore	Robot naming, folder cleanliness, schema, physics-layer authoring, thumbnails.	9
RobotMaterials	Robot material nesting and top-level Looks placement.	2
SimReady	SimReady capability and thumbnail requirements.	2
Units	Stage metadata: up axis, meters/kilograms per unit, time codes.	6

AtomicAsset

AtomicAsset

Requirement	Rule Name	Description
AA.001	AnchoredAssetPathsChecker	Asset references should use anchored paths
AA.002	SupportedFileTypesChecker	Asset must use only supported file types

BaseArticulation

BaseArticulation

Requirement	Rule Name	Description
BA.001	HasArticulationRoot	An articulated USD stage must contain exactly one prim with the UsdPhysicsArticulationRootAPI applied.
BA.002	NonAdjacentCollisionMeshesDoNotClash	Validates that non-adjacent collision meshes do not intersect. Runs a live PhysX simulation step and therefore requires the Isaac/Kit physics runtime.

BomStructure

BomStructure

Requirement	Rule Name	Description
PKG.BOM.001	BomStructureChecker	The BOM is a metadata file identified by the name com.nvidia.simready.packaging.bom.json. It MUST list all content files in the package with per-item fields, using forward-slash relative paths with no duplicates.

ColliderApproximations

ColliderApproximations

Requirement	Rule Name	Description
COL.001	ColliderApproximationsCapabilityChecker	Every mesh collider (Mesh prim with USDPhysics.CollisionAPI and USDPhysics.MeshCollisionAPI) must have an SDF (Signed Distance Field) approximation for efficient collision detection.

ConformanceMetadata

ConformanceMetadata

Requirement	Rule Name	Description
PKG.CONF.001	ConformanceMetadataChecker	Packages MAY include conformance metadata files recording SimReady Foundations validation results, following defined naming and JSON schema conventions

Geometry

Geometry

Requirement	Rule Name	Description
VG.001	ImageableGeometryChecker	Assets must contain at least one Imageable Geometry
VG.002	UsdGeomExtentChecker	Boundable geometry primitives must have valid extent values.
VG.007	ManifoldChecker	Mesh geometry must be manifold
VG.008	CoincidentMeshChecker	Meshes should not share the exact same space
VG.014	ValidateTopologyChecker	Mesh topology must be valid
VG.023	MeshXformPositioningChecker	Meshes should be positioned with xform ops rather than by “baking” transformations into point positions.
VG.025	AssetOriginPositioningChecker	Geometry shall be defined such that the asset is correctly positioned and oriented at the origin (0,0,0).
VG.026	AssetPivotPlacementChecker	The pivot point of an asset should be positioned logically: at the center of the object’s base for ground plane objects, and at the center of rotation for objects that rotate around specific points.
VG.027	NormalsExistChecker	All non-subdivided meshes must have normals.
VG.028	NormalsShouldBeCorrectChecker	Mesh normal values must be valid to produce correct shading.
VG.029	NormalsWindingsChecker	The winding order of faces in a mesh must correctly represent the orientation (front/back) of the face.
VG.MESH.001	GeomShallBeMeshChecker	All geometry shall be represented as non-subdivided mesh primitives using the UsdGeomMesh schema.

HashObjectFormat

HashObjectFormat

Requirement	Rule Name	Description
PKG.HASH.001	HashObjectFormatChecker	Hash fields MUST be objects containing at least a sha256 key with lowercase hexadecimal value. Implementations SHOULD also include blake3 and/or blake2b when available, for performance. When content_hash or package_hash are present, their sha256 values MUST be computed using the deterministic algorithms defined in this requirement.

Hierarchy

Hierarchy

Requirement	Rule Name	Description
HI.001	HierarchyHasRootChecker	All prims in the hierarchy must be direct or indirect descendants of a single root prim, preventing scattered or disconnected Xform hierarchies.
HI.002	ExclusiveXFormParentChecker	Every UsdGeomGprim must have a parent Xform with specific transform operations and hierarchy constraints.
HI.003	RootPrimXformableChecker	The root prim of a hierarchy must be transformable, meaning its prim type must inherit from UsdGeomXformable and be capable of receiving transform operations.
HI.004	StageHasDefaultPrimChecker	Stage must specify a default prim to define the root entry point.
HI.006	PlaceablePosableXformableChecker	All prims representing distinct objects or groups that require placement, posing, or animation shall inherit from UsdGeomXformable.
HI.008	LogicalGeometryGroupingChecker	Geometry should be grouped under parent Xforms in a way that is logical for the object’s structure and intended use in layouts or simulations.
HI.009	KinematicChainHierarchyChecker	For assets (e.g., a robot with multiple articulated joints), the hierarchy should reflect the kinematic chain, with appropriate Xforms for each transformable link.
HI.010	UndefinedPrimsChecker	Assets must not contain undefined prims (overs)

IsaacComposition

IsaacComposition

Requirement	Rule Name	Description
ISA.001	IsaacCompositionCapabilityChecker	The asset must be composed correctly for Isaac Sim using a structured payload and reference system with proper file organization.

MetadataFiles

MetadataFiles

Requirement	Rule Name	Description
PKG.META.001	MetadataFilesChecker	Metadata files MUST be JSON with UTF-8 encoding, use reverse domain naming, and follow write-once semantics

NamingPaths

NamingPaths

Requirement	Rule Name	Description
NP.001	PrimNamingConventionChecker	Prims shall follow consistent naming conventions
NP.002	FileNamingConventionChecker	USD files shall follow consistent naming conventions
NP.003	DirectoryStructureChecker	Asset directories shall use consistent naming and logical organization
NP.004	PathLengthLimitsChecker	File and directory paths shall not exceed platform limits
NP.005	AssetFolderStructureChecker	Assets must follow a specific folder structure with the asset name as the root folder
NP.006	MetadataLocationChecker	Asset metadata must be stored in the USD file or a sidecar JSON file
NP.007	RelativePathsChecker	All references must use relative paths
NP.008	PathsExistChecker	All asset, reference, and payload paths must resolve to files that exist

PackageStructure

PackageStructure

Requirement	Rule Name	Description
PKG.DEF.001	PackageDefinitionChecker	Each package MUST have exactly one valid package definition with a globally unique, case-insensitive, immutable identity, placed at the package root alongside a .metadata/ folder

PhysicsDrivenJoints

PhysicsDrivenJoints

Requirement	Rule Name	Description
DJ.001	PhysicsDriveAndJointState	Validate that each driven joint has correct drive configuration and joint state, including required limits and consistency checks against the current joint state values.
DJ.002	JointHasJointStateAPI	Driven joints must implement proper joint state API for simulation state management.
DJ.003	JointHasCorrectTransformAndState	Driven joints must maintain correct transform relationships and state consistency.
DJ.004	PhysicsJointHasDriveOrMimicAPI	PhysX driven joints must implement drive API or mimic functionality for controlled motion.
DJ.005	PhysicsJointMaxVelocity	PhysX driven joints must have appropriate maximum velocity limits configured.
DJ.006	DriveJointValueReasonable	Drive joint parameters must be within reasonable ranges for stable simulation. The joint parameters should not be excessively large and should be natural numbers.
DJ.007	MimicAPICheck	Mimic API configuration must be properly validated for coordinated joint motion.
DJ.008	JointsExist	Robot schema joints must exist and be properly defined for Isaac Sim integration.
DJ.009	LinksExist	Robot schema links must exist and be properly connected to joints for kinematic chain definition.
DJ.010	CheckRobotRelationships	Robot joint and link relationships must be validated for proper kinematic tree structure.
DJ.011	ArticulationNoLoopsOrMultiJoint	The articulation must have no loops and at most one joint between any two bodies. Only joints that participate in the articulation are checked; joints with physics:excludeFromArticulation = true are ignored.

PhysicsGraspable

PhysicsGraspable

Requirement	Rule Name	Description
GSP.001	GraspableVectorLineChecker	For an asset to be considered graspable, it must have at least one line object defined within the asset. A line is at least two points in space, and this line must intersect the asset that needs to be grasped by the robotic grippers.

PhysicsGrippers

PhysicsGrippers

Requirement	Rule Name	Description
GR.ISA.001	GripperSiteAPI	Every gripper site prim must have IsaacSiteAPI applied and isaac:Description authored so Isaac Sim tooling can discover and configure it automatically.

PhysicsJoints

PhysicsJoints

Requirement	Rule Name	Description
JT.001	PhysicsJointCapabilityChecker	Rigid bodies that are not free-floating should be connected using joints.
JT.002	PhysicsJointChecker	Targets set to Body0 and Body1 relationships must exist.
JT.ART.002	ArticulationChecker	Articulation roots cannot be nested.

PhysicsMaterials

PhysicsMaterials

Requirement	Rule Name	Description
PMT.001	PhysicsMaterialsCapabilityChecker	Every collider (prim with PhysicsCollisionAPI) must have a material:binding:physics relationship to a physics material.

PhysicsRigidBodies

PhysicsRigidBodies

Requirement	Rule Name	Description
PHYSX.COL.001	PhysxRigidBodyColliderCapabilityChecker	CollisionAPI may only be applied to a UsdGeom Gprim or to an Xform that has PhysxMeshMergeCollisionAPI and whose collisionmeshes collection includes at least one Gprim.
PHYSX.COL.002	PhysxRigidBodyColliderMeshChecker	MeshCollisionAPI may only be applied to a UsdGeom Mesh or to a prim that has PhysxMeshMergeCollisionAPI. CollisionAPI is required whenever MeshCollisionAPI is applied.
RB.001	RigidBodyCapabilityChecker	Assets must contain at least one rigid body
RB.003	RigidBodyChecker	Rigid bodies have to be UsdGeomXformable prims.
RB.007	RigidBodyMassChecker	Rigid bodies _or_ their descendant collision shapes must have a mass specification.
RB.008	RigidBodyHasMassAPI	Rigid bodies _or_ their descendant collision shapes may have detailed mass properties including density, center of mass, and inertia tensor. When authored, these detailed mass properties must be internally consistent (see [Validation](#validation)).
RB.010	InvisibleCollisionMeshHasPurposeGuide	Invisible collision meshes must have their purpose attribute set to ‘guide’ to be properly excluded from rendering.
RB.011	NestedRigidBodyMassChecker	Every rigid body must have a valid (positive) physics:mass on itself or on at least one of its child colliders. Nested rigid body subtrees are excluded from the traversal. Negative mass is always a failure.
RB.012	NoNestedRigidBodyWithoutJointChecker	Rigid bodies should not be nested unless they are connected by a joint.
RB.013	RigidBodyHasCollider	Enabled rigid bodies must have collision geometry.
RB.COL.001	RigidBodyColliderCapabilityChecker	Colliding Gprims must apply the Collision API.
RB.COL.002	RigidBodyColliderMeshChecker	UsdPhysicsMeshCollisionAPI may only be applied to UsdGeom.Mesh prims, and any prim with MeshCollisionAPI must also have UsdPhysicsCollisionAPI applied.
RB.COL.003	RigidBodyColliderNonUniformScaleChecker	The Mesh Collision API can only be assigned to Mesh Prims.
RB.COL.004	ColliderChecker	The collision shape scale must be uniform for the following geometries: Sphere, Capsule, Cylinder, Cone & Points.
RB.MB.001	MultibodyChecker	Assets must contain at least two rigid bodies

RobotCore

RobotCore

Requirement	Rule Name	Description
RC.001	CleanFolder	Robot asset folders contain only referenced, required files. No stray or unused content. At the main level of a robot asset, only the interface layer is present. All other required content is bundled in subfolders related to its specific usage.
RC.002	NoOverrides	Robot USDs avoid local override layers that mask upstream schemas or physics.
RC.003	RobotNaming	Canonical robot and prim naming conventions for stable references and tools.
RC.004	ThumbnailExists	The robot interface asset file should contain a thumbnail. The thumbnail should be representative of the robot.
RC.005	VerifyRobotPhysicsAttributesSourceLayer	Validates that physics attributes are authored in the physics layer.
RC.006	VerifyRobotPhysicsSchemaSourceLayer	Validates that physics schemas are authored in the physics layer.
RC.007	RobotSchema	Robot USDs declare and use the required schemas and physics attributes.
RC.008	RobotType	Robot assets must declare a valid robot type on the default prim. The isaac:robotType attribute must be present, must be one of the schema-defined allowed tokens, and must not be “Default”. Allowed values are: “End Effector”, “Manipulator”, “Humanoid”, “Wheeled”, “Holonomic”, “Quadruped”, “Mobile Manipulators”, “Aerial”.
RC.009	RootJointPinned	The root joint (the first target of isaac:physics:robotJoints) must be pinned for robot types that require a fixed base (e.g. Manipulator, End Effector) and must not be pinned for other robot types.

RobotMaterials

RobotMaterials

Requirement	Rule Name	Description
RM.001	NoNestedMaterialsChecker	Materials must not contain nested materials to avoid unexpected rendering behavior.
RM.002	MaterialsOnTopLevelOnlyChecker	Materials must only be defined in the top-level Looks prim following USD best practices for material organization.

SimReady

SimReady

Requirement	Rule Name	Description
SR.001	SimReadyCapabilityChecker	The asset stage must contain all required metadata fields
SR.002	ThumbnailExists	The SimReady asset file should contain a thumbnail that is representative of the asset.

Units

Units

Requirement	Rule Name	Description
UN.001	StageMetadataChecker	Stage must specify upAxis to define the orientation of the stage
UN.003	KilogramsPerUnitChecker	Stage must specify kilogramsPerUnit to define the mass unit scale, if physics objects are present in the stage.
UN.004	UnitsCorrectiveTransformChecker	Must apply corrective transforms for different units
UN.005	TimeCodesPerSecondChecker	Stage must specify timeCodesPerSecond if time samples are present in the stage.
UN.006	UpAxisZChecker	Stage must specify upAxis = “Z” to define the orientation of the stage
UN.007	MetersPerUnit1Checker	Stage must specify metersPerUnit = 1.0 to define the linear unit scale

Asset Validator Window

For direct rule selection, navigate to Window > Asset Validator, then select SimReady categories such as RobotCore, PhysicsRigidBodies, PhysicsDrivenJoints, or RobotMaterials. You can select individual rules or all rules in a category.

For more information on the Asset Validator window, refer to Asset Validator.