CuACD: A Fully GPU-Resident Approximate Convex Decomposition

Abstract: Approximate convex decomposition (ACD) converts triangle meshes into small sets of convex parts and is a standard preprocessing step for physics simulation, collision detection, and large-scale robot learning. The majority of modern ACD methods produce high-quality decompositions through an expensive search over candidate cutting planes, with per-mesh runtimes of tens of seconds that force game pipelines into overnight bakes and keep articulated-object datasets on CPU clusters for days. Prior work has accelerated isolated stages, most recently VisACD's GPU-based visibility metric, yet the dominant costs -- search, mesh cutting, and convex hull construction -- have remained on the CPU because their natural decomposition into many small homogeneous phases trails off in a fading last wave at every kernel boundary, and the variable-sized output of each phase forces a host round trip simply to allocate the next launch's input. We address these obstacles by adopting the warp, rather than the thread or thread block, as the unit of algorithm design, an idea introduced in the graph-processing community for a different pathology and which we adapt here to fuse the many heterogeneous phases of a computational-geometry pipeline into single warp-resident kernels, paired with a device-side heap allocator that lets the buffers between fused phases be sized and allocated on the device. Building on this template, we present CuACD (CUDA ACD), the first fully GPU-resident ACD system, together with a suite of reusable GPU components, released as open-source standalone CUDA modules that drop into any search-based ACD pipeline. On the V-HACD benchmark, PartNet-Mobility, and an Objaverse subset, CuACD achieves more than an order of magnitude of speedup over CoACD at matched or better quality.

• The paper introduces CuACD, a fully GPU-resident approach to approximate convex decomposition (ACD), accelerateing the process by 78- to 104-fold compared to CoACD and 40- to 64-fold compared to VisACD on key benchmarks, with concavity measures remaining comparable or better and with no increase in part count.
• CuACD enhances performance by using a warp-centric execution model, which efficiently handles irregular geometric operations and leverages co-operative reduction and symmetric paired work to optimize GPU utilization. At the same time, it improves memory management with custom GPU-side caching acceptable for most applications purposes.
• Key contributions include accelerated mesh cutting, cheaper evaluations, and optimal memory management. It maintains concavity metrics of residual volume and bidirectional Hausdorff distance while using warf-based clamping of surface boundaries and significantly cuts time when compared to cpu implementations.

Approximate convex decomposition (ACD) is a preprocessing operation that replaces a triangle mesh with a collection of convex polyhedra suitable for collision detection. The practical importance of ACD follows from the efficiency of convex–convex proximity and intersection algorithms, whereas direct collision queries on arbitrary triangle meshes are substantially more expensive and less predictable. Exact convex decomposition is computationally intractable in general and commonly produces too many pieces for simulation, so modern systems optimize an approximate concavity objective under an implicit or explicit part-count constraint.

CuACD addresses the dominant cost of search-based ACD: the repeated evaluation of candidate cutting planes. Its central claim is that ACD is sufficiently coarse-grained across active parts, but sufficiently irregular within each candidate evaluation, to benefit from a warp-centric rather than thread-centric GPU design. The resulting system retains the search formulation and collision-aware concavity metric of CoACD while moving candidate generation, look-ahead search, mesh clipping, convex-hull construction, Hausdorff evaluation, connected-component analysis, and hull merging into GPU-resident execution (2609.28731).

Problem formulation and system objective

CuACD follows the recursive structure of CoACD. A worklist initially contains the input mesh. Parts whose concavity exceeds a threshold $\tau$ are selected for further subdivision. For each selected part, the algorithm proposes cutting planes, evaluates them with a bounded look-ahead search, accepts the lowest-cost cut, and reinserts the resulting sub-parts. Once all parts satisfy the termination criterion, a greedy post-processing pass merges pairs whose joint hull remains below the threshold.

The concavity measure combines residual volume and bidirectional Hausdorff distance:

$$\mathrm{cost}(P)=\max\left(kR_v(P),d_H(P,H(P))\right),$$

where $H(P)$ is the convex hull of part $P$, $R_v$ is the radius of a sphere having the residual volume between $P$ and its hull, and $k$ calibrates the volume term. CuACD uses the cheaper residual-volume surrogate during look-ahead and evaluates the full metric for termination. This preserves the collision-aware motivation of CoACD: residual volume captures volumetric deviation, while Hausdorff distance penalizes large local surface errors.

The system proposes both axis-aligned planes and planes associated with concave edges. At the default configuration, a part receives 30 axis-aligned root candidates and up to 16 sampled concave edges, with four planes generated per edge. Thus, the nominal root pool contains up to 94 candidates. Deeper search uses a branching factor of five and depth two. This candidate enrichment is important when interpreting the quality results: part of CuACD's advantage over stock CoACD comes from a broader proposal distribution rather than GPU execution alone.

Warp-centric execution

The paper's main systems contribution is to make a warp—the 32 lanes executing in SIMT lockstep—the primary algorithmic unit. Conventional GPU implementations often assign individual threads or blocks to geometric operations and divide the pipeline into successive kernel launches. CuACD argues that this mapping is poorly matched to ACD for two reasons.

First, ACD exposes hundreds or thousands of independent parts and candidate evaluations, but individual tasks have highly variable workloads. A phase therefore ends with a long tail of underutilized threads and warps. Second, intermediate structures such as clipped vertices, boundary edges, hull faces, and BVH scratch buffers have data-dependent sizes. A phase-by-phase implementation must determine those sizes before launching the next phase, commonly forcing synchronization and host intervention.

CuACD instead uses two concurrency levels. At the coarse level, independent parts or candidate evaluations are assigned to resident warps. At the fine level, each warp cooperatively processes one irregular operation using warp votes, shuffles, reductions, filtering, and compact data structures. The paper's premise is that ACD's active worklist naturally supplies roughly the $10^2$ independent tasks needed to occupy a GPU at warp granularity, whereas a thread-granular design would require approximately $10^4$ independent units of work.

The warp-centric programming model is instantiated through four recurring patterns:

• Cooperative traversal and reduction: lanes scan arrays at stride 32 and combine results using shuffle-based reductions.
• Sorting and set construction: warp-level quick-sort supports dynamically sized arrays, deduplication, and membership operations.
• Symmetric paired work: 16 two-lane groups process related entities such as edge endpoints or linked-list neighbors.
• Divide and conquer: lanes or lane pairs independently process subproblems before warp-level merging.

This design does not eliminate irregular control flow. Rather, it confines irregular operations to a warp and exploits SIMD cooperation around them. The paper's approach is consequently most effective when there are many independent small or medium-sized geometry tasks, not when a single operation exposes little parallelism.

Device-resident memory management

The second enabling mechanism is a device-side heap allocator for variable-size intermediate buffers. CUDA's built-in device allocation primitives are unsuitable for CuACD because global allocation serialization becomes dominant at the allocation rate induced by repeated clipping and hull construction. Existing GPU allocators are also not sufficient for the system's variable-size mesh buffers because fragmentation and coalescing behavior are important.

CuACD divides the heap into 64 independent arenas. A warp is assigned to an arena according to its identifier, reducing contention among concurrent tasks. Each arena maintains power-of-two bins subdivided into 64 sub-bins, with a bitmap identifying nonempty lists. Boundary tags permit constant-time coalescing on free. The allocator therefore supports dynamic intermediate structures without requiring the host to inspect output sizes or relaunch kernels with newly computed capacities.

In the reported stress test, the allocator is approximately five times faster than CUDA allocation under contention-free conditions and 10–11 times faster when arenas are oversubscribed. These measurements support the claim that allocation is not merely an implementation detail: without a scalable device allocator, the fully resident pipeline would transfer its synchronization bottleneck into memory management.

The design also imposes a practical constraint. CuACD reserves 70% of free VRAM as a persistent heap pool at context creation. This simplifies allocation and stabilizes repeated workloads, but it reduces flexibility for applications sharing the GPU with other consumers. The heap does not compact memory across arenas or return freed memory to the system allocator, leaving fragmentation behavior under long-lived or heterogeneous workloads as an unresolved systems issue.

GPU mesh cutting and convex hull construction

Mesh-plane clipping is implemented as a sequence of warp-level filtering, sorting, deduplication, and traversal operations. The clipper classifies vertices by signed plane distance, identifies crossing edges, sorts edge keys, inserts unique intersection vertices, splits triangles into positive and negative submeshes, and reconstructs the cut boundary. The boundary is recovered from unpaired edge keys in the smaller output component. The cut is then capped using loop chaining, loop classification, hole bridging, and ear clipping.

The use of sorting to recover boundary edges is particularly appropriate for GPU execution. Interior edges appear twice in the edge multiset, while boundary edges appear once. Sorting transforms a topological boundary-identification problem into a local neighbor comparison. The subsequent cap construction remains more sequential: lane 0 maintains a cursor over a linked polygon representation, while the rest of the warp parallelizes point-in-triangle tests for candidate ears. This is a compromise between geometric correctness and SIMT efficiency rather than a fully parallel triangulation algorithm.

Convex hull construction is based on a warp-cooperative divide-and-conquer implementation of the Preparata–Hong algorithm using integer predicates. Input points are sorted along the longest bounding-box axis, partitioned into 16 chunks, and processed by two-lane hull groups. Partial hulls are merged through a gift-wrapping procedure in which the two lanes search from bridge endpoints and exchange state through shuffle operations.

For large point sets, CuACD adds a direction-extreme prefilter. Forty scans over directions sampled from a level-2 icosphere retain 80 extreme witnesses; a preliminary hull identifies points that cannot be extreme, after which the exact divide-and-conquer hull runs on the survivors. On V-HACD-style data with 65,536 points, this prefilter removes approximately 70% of points and produces more than a 12-fold speedup over the unfiltered GPU hull path. The prefilter is disabled below 1,024 points because its fixed scanning cost outweighs its savings.

The component benchmark reports substantial gains over Bullet's CPU hull implementation. For batches of 256 point sets with 65,536 points, the hybrid GPU method requires 20.53 ms for uniform-cube inputs and 17.61 ms for Gaussian inputs, compared with 6,839.78 ms and 5,561.01 ms for the CPU implementation. These results demonstrate that the relevant workload is not a single large hull but a large batch of independent hulls. That distinction separates CuACD from GPU hull algorithms optimized primarily for one large point cloud.

End-to-end performance

CuACD is evaluated on the 61-mesh V-HACD benchmark, 14,085 merged link meshes from PartNet-Mobility, and a 1,000-mesh Objaverse subset. Inputs are preprocessed using PaMO at a fixed configuration, and the preprocessing stage is excluded from timing. Baselines are threshold-swept to approximately match CoACD's default mean concavity of 0.05.

Benchmark	Method	Mean concavity	Parts	Time per mesh
V-HACD	CoACD	0.0495	40.5	18.03 s
V-HACD	VisACD	0.0604	37.5	9.60 s
V-HACD	CuACD	0.0488	33.6	0.23 s
PartNet-Mobility	CoACD	0.0465	21.1	12.82 s
PartNet-Mobility	VisACD	0.0511	22.8	7.42 s
PartNet-Mobility	CuACD	0.0458	21.0	0.16 s
Objaverse subset	CoACD	0.0540	59.0	25.93 s
Objaverse subset	VisACD	0.0702	59.9	15.92 s
Objaverse subset	CuACD	0.0496	48.9	0.25 s

Relative to CoACD, the reported speedups are 78 times on V-HACD, 80 times on PartNet-Mobility, and 104 times on the Objaverse subset. CuACD is also reported to be 40–64 times faster than VisACD, the fastest prior GPU-assisted baseline in the comparison. On an RTX 3080 Mobile, the V-HACD mean is 0.64 seconds per mesh, still more than an order of magnitude faster than the CPU baselines.

The quality comparison is favorable but requires careful attribution. CuACD produces fewer parts and equal or lower mean concavity than the baselines in the matched operating points. However, its candidate pool is richer than CoACD's: CuACD uses 94 root candidates, including concave-edge planes, whereas the original CoACD configuration uses 60 axis-aligned candidates. A CPU implementation incorporating CuACD's concave-edge proposals and related hyperparameters produces 33.7 parts at mean maximum concavity 0.0481 and takes 20.85 seconds per mesh. This closely matches CuACD's 33.6 parts, 0.0488 concavity, and 0.23-second runtime.

That controlled comparison supports a narrower and stronger conclusion: the quality improvement is primarily attributable to candidate generation, while the large runtime improvement is primarily attributable to GPU-resident execution and warp-centric system design. The CPU port also shows that CuACD's search simplification does not inherently provide the speedup; the device implementation is the decisive factor.

Sensitivity, scaling, and application-level behavior

The search ablations indicate diminishing returns from deeper look-ahead. Increasing the depth from two to three lowers the mean part count from 33.57 to 32.89 but increases runtime from 0.23 to 0.41 seconds. Increasing the deeper branching factor from five to 15 raises runtime to 0.44 seconds while reducing the mean part count only to 33.07. Similarly, reducing the concave-edge iteration budget from 10 to three lowers runtime by approximately 17% but increases the mean part count from 33.57 to 35.20. These results justify the default operating point as a throughput-oriented compromise, although they do not establish that it is optimal for applications with a different cost function or part-count constraint.

Threshold sensitivity is comparatively favorable. Tightening $\tau$ from 0.05 to 0.01 increases the mean part count from approximately 34 to 194 and raises runtime from approximately 0.23 to 0.5 seconds, while peak memory increases only from 1.4 to 1.6 GiB. Thus, within the tested range, a substantially finer decomposition costs roughly twice the runtime rather than an order-of-magnitude increase. The result is useful for pipelines that need to trade collision fidelity against collider complexity at runtime or preprocessing time.

The paper also reports scaling to inputs approaching one million triangles, with runtimes remaining in the multi-second range and memory within the 24 GiB capacity of the RTX 4090. A scene-scale experiment decomposes the 1,043,077-triangle Amazon Lumberyard Bistro interior at $$\mathrm{cost}(P)=\max\left(kR_v(P),d_H(P,H(P))\right),$$0 in 18.73 seconds using 2,355.6 MiB of peak GPU memory. These measurements demonstrate that the implementation can process a complete large scene, but they should not be conflated with the per-mesh benchmark: the scene experiment uses a substantially tighter threshold and a different workload composition.

Limitations and open questions

CuACD retains hand-designed search heuristics inherited from the CoACD family. The paper explicitly concedes that some selected cuts may be suboptimal relative to learned proposal policies. The system therefore establishes a fast implementation of a classical search strategy, not a generally optimal decomposition procedure. Its comparison also excludes contemporary learning-based methods without released code, weights, or training data, so the reported quality and speed conclusions apply primarily to reproducible classical and GPU-assisted baselines.

The measured GPU occupancy is only 25–50%, limited by register pressure from intermediate geometric state. This does not prevent high throughput in the reported workloads, but it indicates that the implementation is not approaching hardware saturation in the usual occupancy sense. The paper leaves open whether lower register footprints, alternative state layouts, or more aggressive task scheduling would yield further gains without reducing geometric robustness.

The allocator's arena-local structure avoids global contention but does not compact memory across arenas. Long-running applications with changing mesh sizes could therefore exhibit fragmentation patterns not represented by the benchmark. The use of a persistent 70%-of-free-VRAM pool also presumes relatively exclusive GPU ownership. Finally, the experiments exclude PaMO preprocessing, despite its practical relevance in an end-to-end asset pipeline. Consequently, the reported speedups characterize decomposition after standardized preprocessing rather than total mesh-to-collider latency.

Conclusion

CuACD presents a fully GPU-resident implementation of search-based approximate convex decomposition. Its contribution is primarily architectural: warp-level task design handles irregular small-scale geometry operations, while a device-side coalescing allocator removes host synchronization caused by variable-size intermediate data. The resulting implementation reports 78–104-fold speedups over CoACD and 40–64-fold speedups over VisACD on three benchmarks, with comparable or better concavity and no increase in mean part count.

The controlled CPU comparison separates the system's contributions: enriched concave-edge proposals account for much of the quality improvement, whereas warp-centric fusion, GPU-resident allocation, and GPU implementations of clipping and hull construction account for the dominant performance gain. The remaining questions concern robustness under long-lived memory fragmentation, register-pressure reduction, end-to-end preprocessing cost, and the interaction between GPU-resident classical search and learned cut proposals.