How to add physics properties to 3D models for simulation

If a 3D model only contains geometry and textures, a simulator cannot pick it up, drop it, or run a robot policy against it. Physics properties — mass, friction, collision geometry, inertia — are what turn a static asset into a simulation-ready one. Adding them is the single biggest bottleneck in scaling robotics simulation environments.

This guide explains exactly which physics properties matter, why each one affects simulation accuracy, the traditional manual workflow (about 4 hours per asset), and the AI-automated alternative that takes about 5 minutes.

What “physics properties” actually means

In simulators like NVIDIA Isaac Sim, MuJoCo, Gazebo, and Unreal Engine, a rigid-body simulation needs the following per-asset metadata:

• Mass — total weight in kilograms. Determines how much force is needed to move the object.
• Center of mass (COM) — the point at which mass is concentrated. Asymmetric objects (tools, bottles, electronics) have off-center COMs that affect tipping, grasping, and stacking.
• Inertia tensor — a 3×3 matrix describing how mass is distributed around the COM. Determines rotational dynamics under torque.
• Friction coefficients — static (resistance to starting motion) and dynamic (resistance once moving). Material-dependent: steel-on-steel ≈ 0.6, rubber-on-concrete ≈ 0.9, ice-on-ice ≈ 0.03.
• Restitution — bounciness on impact, from 0 (clay) to 1 (perfect rubber ball). Most real objects sit between 0.1 and 0.5.
• Collision geometry — a separate, simulator-friendly mesh that approximates the visual geometry. Almost never identical to the visual mesh.

Different simulators expect this metadata in different formats. Isaac Sim and Omniverse use OpenUSD with PhysicsRigidBodyAPI, PhysicsMassAPI, PhysicsCollisionAPI. Gazebo uses SDF or URDF. MuJoCo uses MJCF XML. Unreal Engine uses physics asset files. The information is the same; the schema is different.

Why each property matters for sim-to-real transfer

A common assumption: “good visual fidelity is enough for simulation.” It isn’t. The sim-to-real gap — the performance drop when a policy trained in simulation is deployed on real hardware — is overwhelmingly a physics problem, not a rendering problem.

Three concrete examples:

• Wrong mass → failed grasp. A robotic arm trained on a 100g object that’s actually 500g will repeatedly drop it.
• Wrong friction → failed manipulation. Stacking objects with friction = 0.3 in sim and 0.8 in reality means simulated stacks topple while real ones hold (or vice versa).
• Wrong collision mesh → unrealistic contacts. A teapot whose collision mesh ignores the spout and handle will simulate impossibly clean grasps. Policies trained this way fail when they encounter real teapots with real handles.

Research validates this. NVIDIA’s GR00T N1 benchmark (2025) found 40% better real-world performance when training combined synthetic and real data with physics-accurate assets vs. visual-only synthetic data. Princeton and CMU’s NeRF2Physics (CVPR 2024) showed that mass and friction estimates within 15-20% of measured values are sufficient for robust policy transfer; outside that range, transfer collapses.

The manual workflow (~4 hours per asset)

Here’s the standard pipeline a technical artist or simulation engineer follows for each new asset:

1. Geometry cleanup (15-45 minutes)

Visual meshes from CAD or scans are usually wrong for simulation. They have:

• Non-manifold geometry (holes, T-junctions, internal faces)
• Wildly varying triangle counts (50k for a hero asset, 200 for a background prop)
• Inverted normals
• Hidden interior geometry

In Blender, Maya, or Houdini you remesh, decimate, fix normals, and export to a clean format (.glb or .fbx are typical).

2. Collision mesh generation (30-90 minutes)

The visual mesh is rarely usable as collision geometry. Two strategies:

• Primitives for static or navigation-only obstacles — boxes, cylinders, spheres. Fast to author, fast to simulate.
• Convex decomposition for dynamic objects that need accurate contact — usually using V-HACD (Volumetric Hierarchical Approximate Convex Decomposition). The high-poly visual mesh becomes a small number of overlapping convex hulls.

Tuning V-HACD takes time. Too many hulls = slow simulation. Too few = missed features (handles, slots). Most engineers iterate 3-5 times to find a workable balance.

3. Mass and inertia estimation (20-60 minutes)

Three ways:

• Look up by category. “It’s a coffee mug, so ~300g.” Fast, often wrong.
• Compute from volume × density. Measure mesh volume, look up the material’s density, multiply. Better, but requires identifying the material — and most real objects are composites.
• Measure a real exemplar. Best accuracy, but only works if you have the physical object.

Inertia tensors are then computed from mesh volume and the assumed mass distribution. Most workflows assume uniform density, which is wrong for hollow objects, tools, and electronics.

4. Friction and restitution assignment (10-30 minutes)

You assign per-material friction values from a reference table. The simulator usually wants both static (μ_s) and dynamic (μ_d) coefficients; getting these wrong by 0.3 produces visibly unrealistic behavior.

5. Authoring in the simulator’s format (30-90 minutes)

Now you write USDPhysics, URDF, or MJCF by hand or with a partial export tool. For OpenUSD this means applying PhysicsRigidBodyAPI, PhysicsMassAPI, and PhysicsCollisionAPI schemas to the right prims. For URDF, you write <inertial>, <collision>, <friction> elements. Each format has its own quirks.

6. Validation (20-45 minutes)

Drop the asset into the target simulator. Verify it falls correctly under gravity, settles realistically, doesn’t interpenetrate other objects, can be grasped without phasing through fingers. If anything is off — and something usually is — go back to step 2 or 3.

Total: roughly 4 hours per asset for an experienced engineer. For a 1,000-object simulation environment, that’s 4,000 engineer-hours. For a 50,000-SKU warehouse twin, it’s a year of full-time work.

The AI-automated workflow (~5 minutes per asset)

Modern AI-based asset preparation collapses this entire pipeline into a single upload-and-download interaction. The technical primitives:

1. Geometry analysis. Multi-view rendering plus mesh segmentation identifies parts, materials, and structural features.
2. Material identification. A vision model classifies surface materials per-region (steel, plastic, fabric, glass, ceramic) and looks up calibrated density and friction values from a physical-properties database.
3. Mass estimation. Volume × identified density, with corrections for hollowness inferred from geometry.
4. Inertia computation. Computed analytically from the geometric mass distribution.
5. Convex decomposition. Automatic V-HACD with parameters tuned per object class (manipulation-grade detail for graspables; coarser hulls for furniture).
6. Schema authoring. OpenUSD output with valid PhysicsRigidBodyAPI, PhysicsMassAPI, PhysicsCollisionAPI applied. Format conversion to MJCF, URDF, or SDF on demand.
7. Validation. Automated checks (no inverted normals, no interpenetration, valid inertia tensors, schema completeness).

Rigyd’s pipeline runs this end-to-end on .glb, .fbx, and .obj uploads, producing simulator-ready OpenUSD in approximately 5 minutes per asset. Mass estimates land within 15–20% of measured values and friction coefficients within ±0.1 — both inside the variance ranges that domain randomization typically targets.

Manual vs. AI-automated: side-by-side

Step	Manual workflow	AI-automated (Rigyd)
Geometry cleanup	15–45 min, in Blender/Maya	Automatic, <30s
Collision mesh	30–90 min, V-HACD tuning	Automatic V-HACD with tuned params
Mass estimation	20–60 min, lookup tables	AI material ID + volume × density
Inertia tensor	Computed assuming uniform density	Computed from inferred density distribution
Friction values	10–30 min, manual lookup	Per-region material classification
Format authoring	30–90 min, hand-written schemas	Direct OpenUSD output, MJCF/URDF/SDF on request
Validation	20–45 min, in-sim testing	Automated schema + geometry checks
Total	~4 hours	~5 minutes
Cost per 1,000 assets	~$370K	<$1K

Cost figures assume a $90/hour blended rate for technical-artist + simulation-engineer time, which is conservative for the US market.

Step-by-step: prepare an asset with Rigyd

1. Upload. Drop a .glb, .fbx, or .obj file into Rigyd. Multi-file batches are supported on the Enterprise API.
2. AI estimates physics. Rigyd identifies materials, generates collision meshes, estimates mass and inertia, and applies USDPhysics schemas. This usually takes 3–6 minutes depending on geometry complexity.
3. Review. Inspect the mass, friction, and collision-mesh visualization in the dashboard. Override any value if you have measured ground truth (mass for a known catalog item, for example).
4. Download. Export as OpenUSD (default) or convert on-the-fly to MJCF for MuJoCo, URDF for Gazebo/ROS 2, or FBX with physics metadata for Unity.
5. Drop into your simulator. No further authoring — physics components populate automatically on import.

When manual still wins

AI automation is the right default for any project beyond a handful of hero assets. Three cases where manual still makes sense:

• Bespoke high-fidelity simulation for a single critical asset — say, a surgical instrument where the inertia tensor must match a measured CAD model exactly.
• Soft-body or articulated mechanisms with constraints not yet supported by the auto-pipeline (specific joint configurations, deformable bodies).
• Unusual material identification — exotic alloys, custom composites, or fictional/decorative materials that don’t appear in calibration databases.

For everything else — and especially for any project that requires more than ~50 assets — automated physics estimation has become table stakes for production robotics teams.

Where to go next

If you’re standing up a new simulation environment, the practical sequence is:

1. Prototype with manual annotation on 5–10 hero assets to understand your simulator’s quirks and your accuracy requirements.
2. Switch to automated for the long tail. Use Rigyd’s free tier (3 credits) to test on your specific asset class before committing to a paid plan.
3. Validate with domain randomization rather than trying to chase 1% physics accuracy. Calibrated estimates within typical DR variance ranges (15–20% mass, 0.1 friction) transfer just as well as hand-measured values for most policies.

The 4-hours-per-asset workflow is no longer the right default for simulation teams. Fixing the bottleneck unlocks scenario diversity, scene scale, and pipeline velocity — all of which compound directly into better real-world robot performance.