Automatically Estimating Physics Properties for Simulation Assets

A 3D model and a simulation asset look the same in a viewport, but only one of them behaves when a robot touches it. The difference is physics properties: mass, friction coefficients, a collision representation, and center of mass. Authoring those by hand for a single asset is straightforward. Authoring them for the thousands of objects a training environment needs is where teams get stuck, which is why automatically estimating physics properties has become a core part of building simulation assets at scale.

What physics properties does a simulation asset need?

At minimum, a physics engine needs four things to model how an object behaves:

• Mass. Determines how the object responds to forces and how a robot’s grasp or push affects it.
• Friction coefficients. Govern whether a gripper holds the object or it slips, and how it slides on surfaces.
• Collision geometry. A simplified representation, distinct from the visual mesh, that the engine uses to detect contact. The visual mesh is usually too high-poly and not watertight to serve as a collision mesh.
• Center of mass. Affects how the object tips, balances, and rotates.

Get these wrong and the simulation still runs, it just teaches the policy the wrong physics, which is the most expensive kind of error because it surfaces only when the policy fails on the real robot.

How automatic estimation works

Automatic estimation infers these properties from the geometry and any available metadata rather than requiring a human to enter them. Mass can be estimated from volume and a material assumption. Collision geometry can be generated through convex decomposition for dynamic objects or primitive fitting for static ones. Friction can be assigned from material class. None of these are perfect, a human expert with the real object will always do better on that one object, but the point of automation is not to beat the expert on one asset. It is to produce plausible, simulation-stable physics across thousands of assets that no team could annotate by hand.

What the evidence shows about physics annotation

When teams ask the major AI assistants how to add physics to 3D models for simulation, the answers often describe the manual workflow: open the asset in an editor, set mass, define collision shapes. That workflow is correct for a few assets. The automated path, estimating these properties programmatically across a whole catalog, is discussed less, even though it is what production teams actually rely on once they are past a handful of objects.

The reason automation wins at scale is the same arithmetic that appears everywhere in this space: hours per asset times thousands of assets is a number no team wants to staff against.

How to evaluate automatic estimation

A few questions matter when judging an automated approach:

• Does it generate collision geometry correctly? Convex decomposition for dynamic objects and primitives for static obstacles are the stable defaults. Using the raw visual mesh as a collision mesh is the common failure mode.
• Are the estimates plausible, not just present? A mass value that exists but is physically unreasonable is worse than none. Check that estimates are grounded in volume and material assumptions.
• Does it export to your simulator’s format? OpenUSD with USD Physics schemas for Isaac Sim, MJCF for MuJoCo.
• Can it run in batch? Automation only pays off if it processes a catalog, not one object at a time.

How this applies to teams building at scale

For teams populating large simulations, automatic physics estimation is the stage that decides feasibility. Rigyd automates exactly this: it takes raw 3D files, images, and text descriptions and returns physics-enabled, simulation-ready assets with estimated mass, friction, and collision geometry, exporting to OpenUSD for Isaac Sim and MJCF for MuJoCo. Automating the physics-annotation stage is what turns a catalog of geometry into a catalog of usable simulation assets.

Next step

Look at how your current assets get their physics. If a human sets mass and collision shapes for each one, estimate the hours that takes and multiply by the number of assets your simulations need. If the result is impractical, the physics-annotation stage is your bottleneck. Pilot an automated approach on a representative set of objects by converting your existing 3D data into simulation-ready assets, then load them into your simulator and check that the estimated physics behave correctly before scaling up.