V-HACD vs CoACD vs manual hulls
The collision mesh you ship is the single biggest knob on simulator speed and contact fidelity. V-HACD is the workhorse; CoACD produces fewer, smarter hulls; manual still wins for hero assets. Here is how the three approaches compare and when each is the right choice.
Updated June 5, 2026 · by Ugur Yekta
The short answer
V-HACD (2014) is fast, well-tooled, and the default in most pipelines, but produces many hulls. CoACD (2022) is collision-aware: it preserves concavity where it matters and emits fewer hulls, so simulation runs faster despite the slower decomposition. Manual hulls (primitives or hand-modelled approximations) still win on hero assets where human judgment beats either algorithm.
Side-by-side comparison
| V-HACD Volumetric HACD, the workhorse | CoACD Collision-aware ACD, 2022 | Manual hulls Hand-authored primitives | |
|---|---|---|---|
| Origin | Khaled Mamou, 2014 | Wei et al., SIGGRAPH 2022 | Authored by hand |
| Algorithm class | Volumetric voxel-based ACD | Collision-aware ACD with concavity metric | N/A, designer-authored |
| Typical hull count | 10-64 per asset | 4-24 per asset | 1-8 per asset (often primitives) |
| Decomposition time | Seconds per asset | Tens of seconds per asset | Minutes to hours per asset (engineer time) |
| Sim performance | Slower (more hulls per contact pair) | Faster (fewer hulls, fewer contact pairs) | Fastest (lowest hull count, often primitives) |
| Concavity preservation | Voxel-resolution dependent, can over-split concave features | Preserves concavity where it affects collision | Exact, designer-controlled |
| Tooling availability | Built into Bullet, NVIDIA PhysX, Unreal, Unity, Blender, Houdini | Open-source on GitHub (SarahWeiii/CoACD); plugins maturing | Authoring tools you already use (Blender, Maya, Houdini) |
| Repeatability | Deterministic given parameters | Deterministic given parameters | Subject to designer judgment |
| Best fit | Fast automated baselines, dynamic objects, catalog scale | Production simulation, contact-rich tasks, concave geometry | Hero assets, known-shape primitives, navigation obstacles |
V-HACD: the workhorse, with caveats
V-HACD (Volumetric Hierarchical Approximate Convex Decomposition) is the algorithm most physics pipelines reach for first. It voxelises the input mesh, then merges voxel groups into convex hulls until a concavity threshold is satisfied. Strengths: it is fast (seconds per asset), deterministic given parameters, and shipped in nearly every physics-adjacent tool (Bullet, NVIDIA PhysX, Unreal Engine, Unity, Blender, Houdini, NVIDIA Omniverse). Weakness: at default settings it tends to over-split concave geometry into many small hulls, which slows simulation because each contact pair gets evaluated against more hulls. Tuning the maximum-hull-count and concavity-threshold parameters can compensate, but the floor is the algorithm: V-HACD is not concavity-aware.
CoACD: collision-aware ACD, the 2022 follow-up
CoACD (Collision-Aware Approximate Convex Decomposition) was published at SIGGRAPH 2022 (Wei, Liu, Jiang, Tu, and Pan). Its key idea: instead of decomposing to satisfy a generic concavity threshold, decompose to preserve concavity where it matters for collision. Practically, CoACD emits fewer hulls than V-HACD for the same fidelity, typically 4-24 versus V-HACD's 10-64, so simulation runs faster despite CoACD taking longer to decompose. The open-source implementation (SarahWeiii/CoACD on GitHub) is mature; pipeline integration is maturing (PhysX, Unreal, Unity plugins are adopting it gradually). For production simulation where per-step physics cost matters, CoACD is increasingly the right answer.
Manual hulls: when human judgment wins
For hero assets, the small set of objects your scenario depends on, neither V-HACD nor CoACD beats a designer who understands the task. A manipulation task with a specific cup needs a thin-walled, concave collision hull that matches the visual mesh; an automated algorithm will approximate, a designer will model exactly. Navigation obstacles often work best as simple primitives (boxes, capsules, spheres) chosen by hand, even when the visual mesh is complex. The cost is engineer time: minutes to hours per asset, versus seconds for V-HACD or tens of seconds for CoACD. The practical pattern is hybrid: automated decomposition for the catalog, manual hulls for the dozen hero assets that drive task outcomes.
When to choose each
V-HACD
Fast automated baselines, catalog-scale processing where simulation cost is dominated by other factors, and any pipeline that already integrates V-HACD through PhysX, Unreal, or Unity tooling.
CoACD
Production simulation with concave geometry, contact-rich tasks, RL training where per-step physics cost matters, and any asset where V-HACD's hull count is the simulation bottleneck.
Manual hulls
Hero assets in the critical path of a task, navigation obstacles where simple primitives suffice, and any case where designer judgment beats algorithmic approximation on outcome metrics.
Where Rigyd fits
Rigyd generates collision meshes automatically as part of the SimReady asset pipeline. The default decomposition is tuned for contact-rich simulation (closer to CoACD's behaviour than V-HACD's); hull count and concavity tolerance are tunable for teams who want to push toward V-HACD-style speed or manual-style precision.
Frequently asked questions
Which algorithm decomposes faster?
V-HACD is faster to compute, typically seconds per asset versus tens of seconds for CoACD. The trade-off is that V-HACD emits more hulls, so time saved at decomposition can be lost again at simulation runtime when the higher hull count slows contact resolution.
Which produces faster simulation?
CoACD generally, because the lower hull count reduces the number of contact pairs the physics solver has to evaluate per step. For dynamic objects in contact-rich scenes, manipulation tasks, cloth-and-rigid interactions, dense pick-and-place, this matters. For navigation-only assets where collision is mostly distance queries, the difference is smaller.
Where do I get each tool?
V-HACD is built into most physics-adjacent tools: Bullet, NVIDIA PhysX, Unreal Engine, Unity, Blender (as an add-on), Houdini, and NVIDIA Omniverse all expose it directly. CoACD is open-source on GitHub (SarahWeiii/CoACD); it is being integrated into PhysX, Unreal, and Unity gradually, but for now the CLI is the most reliable way to use it.
Does Rigyd use V-HACD or CoACD?
Rigyd uses a collision-aware decomposition closer to CoACD's behaviour by default, preferring fewer, more accurate hulls over V-HACD's many-small-hulls bias. The default targets contact-rich production simulation; for navigation-only or pure-rendering use cases, the decomposition parameters are tunable in the export step.
Generate your own catalog to SimReady
Upload any 3D model and get a physics-enabled OpenUSD asset in minutes, exports to MJCF, URDF, and FBX too.
Related reading
Synthetic data generation for computer vision in robotics
Real-world labeled robotics data is expensive and slow to capture. Synthetic data is fast and unlimited, but only useful if the underlying simulation has correct physics, semantic labels, and domain randomization. Here's the complete pipeline.
Digital twin creation pipeline for manufacturing
A factory digital twin needs every object to behave physically, not just render. This is the end-to-end pipeline: CAD intake, BIM merge, physics layer, semantic labeling, simulation runtime, at the asset volumes (10K+ unique SKUs) real factories actually contain.
How to set up mass, friction, and joint properties for robot training
The three pillars of robot physics setup, mass, friction, joints, determine whether your trained policy transfers to real hardware. Here's the calibration target for each, the schemas, and the common mistakes that quietly break training.