Best practices for collision meshes in robotics sim

The collision mesh is the most-tuned property in any robotics simulation — and the one most teams get wrong on the first attempt. Wrong choice produces either phantom interpenetration (objects pass through each other) or unusable simulation performance (5 Hz instead of 60). This guide walks through the four practical strategies, when each fits, and concrete defaults you can reuse across asset classes.

Why visual mesh ≠ collision mesh

A common starting point: “the visual mesh is the geometry, why do I need a separate collision mesh?” Three reasons:

1. Visual meshes are high-poly. A modern PBR-rendered mug might have 10,000–50,000 triangles for visual fidelity. Running collision detection on that polycount, against thousands of other objects, at 60 Hz, in a million-step training loop — your physics budget evaporates.

2. Visual meshes are usually non-convex. Concave shapes (teapots, chairs, anything with a handle or hole) require decomposition or piecewise approximation. Most physics solvers work natively only on convex shapes.

3. Visual meshes are often not watertight. Holes, T-junctions, inverted normals, and internal geometry are common in artist-authored meshes. Physics solvers misbehave on non-manifold geometry — interpenetration, wrong contact normals, lost contacts.

The collision mesh is a separate, physics-friendly approximation: lower poly count, watertight, often convex, and tuned for the simulation’s contact resolution.

The four strategies

1. Primitive shapes (box, sphere, capsule, cylinder)

Wrap the object in a basic geometric primitive.

When to use:

• Static obstacles where exact shape doesn’t affect contact (walls, floors, simple machinery)
• Navigation-only obstacles (robot avoids them, doesn’t manipulate)
• Spherical or boxy graspables (balls, dice, regular cuboids)

Pros:

• Fastest possible collision detection
• Trivial to author
• No tuning required

Cons:

• Lossy for any non-primitive shape
• Phantom interpenetration in concavities
• Wrong contact normals for non-aligned geometry

Concrete defaults: Floor → infinite plane. Walls → boxes. Pillars → cylinders. Most rigid graspables → start with bounding box and upgrade if needed.

2. Convex hull

Wrap the object in a single convex polytope — the smallest convex shape containing all vertices.

When to use:

• Static furniture and machinery where bounding-box is too lossy
• Graspables that are roughly convex (cubes, books, smartphones, bottles without handles)
• Initial pass before deciding whether decomposition is needed

Pros:

• Fast collision detection (specialized algorithms for convex-convex)
• Captures overall shape better than primitives
• One-shot author — no parameters to tune

Cons:

• Loses any concavity (teapot handle, chair seat, fork tines)
• Wrong physics for contact-with-concavity scenarios

Concrete defaults: Most rigid furniture (tables, shelves) → convex hull is good enough. Avoid for any asset that needs to be grasped via a concave feature.

3. Convex decomposition (V-HACD)

Break the object into multiple convex hulls that together approximate the full shape, including concave features.

When to use:

• Dynamic graspables where concave features matter (teapots, mugs with handles, tools, bottles with grippable necks)
• Articulated mechanism links — per-link decomposition captures joint clearances
• Any object where manipulation policy training depends on contact accuracy

Pros:

• Captures concave features
• Physics solver still operates on convex pieces (fast)
• Tunable trade-off between accuracy and performance

Cons:

• Slower than single hull (more pairs to check per object-object collision)
• Requires parameter tuning (concavity threshold, max hulls, resolution)
• Can produce visible artifacts in tight contact (extra hull edges)

V-HACD parameter tuning (reference implementation):

Parameter	Manipulation-grade	Furniture-grade
resolution	100,000	50,000
maxConvexHulls	16-32	4-8
concavity (threshold)	0.001	0.01
planeDownsampling	4	4
convexHullDownsampling	4	4
pca	0	0

Manipulation-grade settings produce more, smaller hulls — better for grasp accuracy. Furniture-grade settings produce fewer, larger hulls — fast enough for environment-scale objects.

4. Mesh simplification

A decimated version of the visual mesh — still a mesh, just with fewer triangles.

When to use:

• Cluttered terrain (rocks, debris, scatter objects) where individual primitives or convex pieces don’t capture the shape
• Static environments with concave geometry that doesn’t need to be manipulated
• Path-planning collision (robot avoids the mesh, doesn’t grasp it)

Pros:

• Preserves complex shapes that decomposition would over-fragment
• One-step automatic with mesh decimation tools
• Works for non-convex static geometry

Cons:

• Slower than convex shapes
• Should not be used for dynamic objects (most physics solvers handle mesh-mesh contact poorly)
• Requires watertightness post-processing

Concrete defaults: Terrain meshes → simplify to ~5-10% of visual triangle count. Cluttered debris → decimate aggressively. Use only for static collision; replace with primitives or hulls for any dynamic object.

Choosing strategy by asset class

A practical lookup table for default collision approximation:

Asset class	Strategy	Approximation
Walls, floors, ceilings	Primitive	Plane / box
Static furniture (chair, table, shelf)	Convex hull	Single hull
Graspable boxes / books / electronics	Convex hull	Single hull
Mugs, teapots, bottles with handles	Convex decomposition	16-32 hulls
Tools (hammers, wrenches)	Convex decomposition	16-24 hulls
Articulated robot links	Convex decomposition per link	8-16 per link
Vehicles	Convex decomposition	8-16 hulls
Cluttered terrain (rocks, debris)	Mesh simplification	5-10% of visual
Cloth, soft body	Specialized soft-body collision	n/a
Wires, cables	Capsule chains	Per-segment capsules

These are starting defaults — tune for your specific simulator and use case.

Performance implications

Collision-detection cost is the single biggest physics performance variable in a typical robotics simulation. Rough cost ratios on PhysX:

• Primitive-primitive collision: 1× (baseline)
• Primitive-convex hull: ~2-3×
• Convex-convex (single hull each): ~3-5×
• Convex decomposition (16 hulls vs 16 hulls): ~50-100×
• Mesh-mesh: ~500-1000× (and unstable for dynamic contact)

Practical rule: Use the simplest collision shape that still produces correct contact behavior for your task. Over-decomposition is the most common cause of “my simulation is too slow.”

Common pitfalls

1. Using physics:approximation = "none" (visual mesh as collision). Crashes the physics solver under heavy contact, or runs at single-digit Hz. Almost never the right choice.

2. Convex hull for objects with manipulation-relevant concavities. A coffee mug as a single convex hull cannot be grasped by the handle in simulation — the handle space is filled by the hull.

3. Over-decomposition with V-HACD. 100+ hulls per object slows physics 10-50× without improving simulation quality. If V-HACD is producing 100+ hulls, raise the concavity threshold.

4. Forgetting collision shape on articulated robot links. Each link needs its own collision geometry; the chain’s root collision doesn’t propagate.

5. Static physics:approximation on dynamic objects. Dynamic objects need separate collision shapes that move with the body. Using the static-mesh approximation type freezes contact.

6. Watertightness ignored on simplified meshes. Decimation can introduce holes that the physics solver doesn’t catch but produces unstable contact.

Validation: how to know your collision mesh is right

For each asset, run these checks:

• Drop test. Simulate the asset falling onto a flat plane. It should settle in a stable orientation matching the visual mesh’s natural rest pose. If it tips, slides, or interpenetrates, the collision mesh is wrong.
• Grasp test (for graspables). Try a basic grasp pose with a parallel gripper or 5-finger hand. If the gripper passes through the handle or grip surface, the collision mesh is missing concavities.
• Stack test. Stack two of the same asset. If they interpenetrate or topple unrealistically, the collision mesh is too coarse or too fine.
• Performance test. Run a 30-second simulation with 100 instances of the asset interacting. If physics drops below 30 Hz, the collision mesh is too detailed.
• Visual overlay. Render the collision mesh as wireframe over the visual mesh. Functional features (handles, grasping points, contact surfaces) should be present in both.

A green pass on all of these means the collision mesh is fit for simulation. A failure on any one means re-tune.

How automated tools handle this

Manual collision-mesh authoring is the most time-consuming part of SimReady asset preparation — 30-90 minutes per asset including V-HACD parameter tuning and validation.

AI-automated pipelines (including Rigyd) tune V-HACD parameters per object class automatically:

• Manipulation-grade decomposition for graspable objects
• Furniture-grade decomposition for environment items
• Primitive replacement when geometry fits a basic shape
• Validation that functional concavities are captured

The output for a graspable object lands in the 16-32 hull range with the right concavity preservation, ready for training without manual tuning. This collapses the per-asset collision-mesh authoring time from ~60 minutes to ~5.

Practical adoption

If you’re standing up a new simulation environment:

1. Default to convex decomposition for anything dynamic. Tune V-HACD per asset class once, then apply consistently.
2. Default to convex hull for static furniture. Upgrade to decomposition only if specific concavities matter.
3. Default to primitives for walls, floors, navigation-only obstacles.
4. Validate every asset with the drop test, grasp test (where applicable), and performance test before it enters training.
5. Iterate based on policy failures. If your trained policy fails on a real-world feature, check whether that feature is captured in the collision mesh first — collision mesh artifacts are the single most common cause of sim-to-real failures in manipulation.

Done well, the collision mesh is invisible to the policy designer and obvious to the physics solver. Done badly, it shows up as either unusable performance or unfixable sim-to-real gaps.