Short answer
A simulation-ready object asset is geometry plus everything a physics engine needs: units and orientation, a collision shape separate from the visual mesh, mass, center of mass and inertia, friction and contact parameters, and joints for articulated parts. Manufacturer CAD can supply design geometry and part identity, but physics properties usually have to be added, measured or documented.
Why geometry alone is not enough
A mesh file opens in a viewer and looks right. Dropped into a physics simulator, it may fall through the floor, explode on contact, weigh nothing or slide like ice. A viewer needs vertices and materials; a simulator needs to know how the object responds to forces. Buyers who license 3D models expecting simulation-ready output are often given the first and have to build the second.
This page specifies the second. For what manufacturers hold and the rights around it, see manufacturer 3D models and CAD. For the question of rendering images from such models, see synthetic renders vs real images.
Formats and where physics lives
Several formats are in common use, and they carry physics differently.
- OpenUSD is a platform for building and composing 3D scenes, with schemas for geometry, shading, lighting and physics (Pixar and the Alliance for OpenUSD). NVIDIA's Isaac Sim imports CAD and URDF into USD for simulation and synthetic data generation (NVIDIA).
- glTF is an API-neutral runtime delivery format: a JSON scene description with binary buffers and images, or a single GLB container. glTF 2.0 added PBR materials and the format is also ISO/IEC 12113:2022 (Khronos Group). It is designed for appearance and delivery, so check what physics information a given export retains.
- MJCF is the native XML model format of MuJoCo, a free and open-source physics engine; MuJoCo also loads URDF and simulates in generalized coordinates with convex-optimization-based contact (Google DeepMind).
The practical consequence is that no single file serves every engine. A supplier should be able to say which formats are delivered, and whether the physics fields survive conversion between them. Ask for a conversion test on one asset before buying a catalog.
What simulation-ready requires
| Component | Why the simulator needs it | Source in practice |
|---|---|---|
| Units, scale, up-axis, origin | Prevents objects at the wrong size or orientation | Export settings; verify against known dimensions |
| Visual mesh and materials | Rendering and perception | CAD export, textures |
| Collision geometry | Fast, stable contact | Simplified shapes or convex pieces, separate from the visual mesh |
| Mass | Dynamics, grasp stability | Product spec or measurement |
| Center of mass and inertia | Rotation and tipping | Computed from geometry plus density, or measured |
| Friction and contact parameters | Slip and grasp outcomes | Ask whether measured or estimated, for which surface pair and under what test |
| Articulation | Doors, lids, hinges | Joint types, axes and limits |
| Identity | Links asset to catalog and part | SKU or part number |
Collision shapes deserve special attention. Ask how the engine you use handles concave meshes; assets often carry a simplified or decomposed collision representation next to the detailed visual one. Whether a given decomposition is good enough for grasping tasks should be tested in the buyer's own engine.
Illustrative asset specification
# Illustrative only - placeholder values and field names
asset_id: sku_00417_v2
identity: {catalog_id: sku_00417, cad_revision: C}
units: meters, kilograms
up_axis: Z
origin: "bottom center"
visual:
mesh: sku_00417_visual.usd
textures: pbr_basecolor, normal, roughness
collision:
representation: convex_decomposition
pieces: "set by buyer; supplier reports count"
max_penetration_test: "pass under 1 N loads in buyer engine"
physics:
mass_kg: 0.512 # source: measured | spec | estimated
mass_source: measured
com_m: [0.0, 0.0, 0.071]
inertia: computed_from_density_and_geometry
friction: {static: 0.55, dynamic: 0.45, source: estimated, surface: "dry steel"}
restitution: 0.1
articulation: none # or joint list with axes and limits
contents_state: sealed_full # liquid or loose contents are not modeled
formats: [usd, mjcf, urdf]
provenance: {license_scope: "training and simulation", derived_from_cad: true}
Each physics value carries a source tag. Without it a buyer cannot tell a measured mass from a guessed one, and that difference affects whether the asset can be used for grasp evaluation or only for perception.
Choosing which assets to build first
Not every product needs a physics model. Rank candidates by how much the task depends on contact: items a robot will grasp, stack, pour or insert deserve measured values, while items that only appear in the background can carry estimates. Mass and dimensions are usually the easiest to obtain; see product dimensions and weights for what catalogs record and what they miss. Articulated products need joint definitions before any physics value matters; see articulated object models.
A mixed route is typical: licensed manufacturer geometry and identity, plus physics added by the buyer, the manufacturer or a specialist who can weigh and test samples. Which party measures should be settled in the contract, along with who owns the added values.
Acceptance tests
- Drop test. Place the asset on a plane in the buyer's engine; it should come to rest without jitter, in a plausible pose.
- Dimension and mass check. Bounding box and mass should match the product specification within a tolerance the buyer sets.
- Collision fidelity. Compare contact against the visual mesh at points where a gripper would touch.
- Articulation range. Joint limits match the physical product.
- Format round trip. Convert between delivered formats and compare mass, inertia and collision.
- Identity. Every asset links to a catalog or part identifier.
Limitations and additional preparation
Sim-ready does not mean real-world accurate. Geometry from manufacturer CAD describes the design, but it does not carry real-world appearance, wear, deformation, or the way contents shift inside packaging. Ask how friction and restitution were obtained and for which contact pair; because they depend on both surfaces, a single value is an approximation. Deformable, granular and liquid-filled items are poorly represented by rigid assets; see deformable product properties.
A simulated object cannot show how a real one behaves when handled by the robot's gripper, and results in simulation need validation against real trials. Assets also do not replace real images or demonstrations. Preparation work is substantial: export to neutral formats, remove proprietary features from the model, add physics, test in the target engine. Physical annotations are covered in physical property annotations and handling attributes in material attributes for manipulation.
Rights
Manufacturer CAD is design intellectual property, and customer-owned designs may be embedded in it. A manufacturer may license a simplified external model but not the engineering model with internal features. Ask what is stripped, who holds rights in derived physics data, and whether simulation or synthetic image generation is within scope. This is not legal advice.
Questions to ask suppliers
- Which formats do you deliver, and have you tested import into more than one engine?
- Are collision meshes provided, and how were they produced?
- Which physics values are measured, which are specification values and which are estimates?
- How were mass, center of mass and inertia obtained?
- Are friction values given, for which surfaces and under what test?
- Do articulated products include joint axes and limits?
- Which internal or proprietary geometry was removed, and does it affect contact or mass?
- Are assets linked to catalog identifiers and revisions?
- Who owns the CAD and any customer-derived design, and does the license cover simulation and synthetic image generation?
- Can we test one asset in our engine before committing to a set?
Discuss your requirements
If you need sim-ready assets for specific products, describe the products, formats and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery; physics annotation can be arranged case by case. A request does not guarantee a match; SourceX follows up about potential sources. Start at the humanoid training data guide or the objects hub, and see the site's page on CAD and engineering drawings.
Discuss your humanoid training-data requirements with SourceX
Sources
- OpenUSD (Universal Scene Description) — scene composition with geometry, shading and physics schemas.
- glTF - Runtime 3D Asset Delivery — runtime asset format with PBR materials.
- MuJoCo — Advanced Physics Simulation (MJCF) — physics engine, MJCF and URDF loading.
- Isaac Sim - Robotics Simulation and Synthetic Data Generation (with Isaac Lab) — CAD and URDF import into USD.