Graphics Project
Voxel Constraints for Parallel XPBD Simulation
GPU-first soft-body simulation using voxel primitives for stable parallel constraint solving and LoD long-range stiffness.
TL;DR
A GPU-oriented XPBD soft-body pipeline that uses voxels as the simulation primitive. This makes constraint scheduling more regular and enables LoD long-range constraints for stiffness and faster convergence.
Focus
Purpose: scalable GPU XPBD
Method: voxel constraints + LoD
Outcome: improved stiffness and practical authoring
Stack
Compute shaders, GPU memory model, XPBD constraint solving
Voxelization + partition scheduling
Purpose
Problem
Parallel XPBD on the GPU runs into two common issues:
- Race conditions: constraints can update the same particle concurrently.
- Brittle preprocessing: tetrahedralization often requires mesh cleanup and yields irregular constraint graphs.
- Stiffness/convergence cost: global motion propagates slowly without long-range constraints.
Goal
Design a pipeline that is:
- GPU-friendly (predictable scheduling, good memory behavior)
- practical for real meshes (less fragile preprocessing)
- stiff with fewer iterations (LoD long-range constraints)
Methodology
Baseline pipeline (comparison): tetrahedralization -> XPBD constraints
Step 1: tetrahedralize mesh
- Convert triangle surface mesh into tetrahedra (often requires cleanup).
Step 2: build constraints
- Volume constraints per tetrahedron
- Distance constraints along edges
Step 3: partition constraints
- Schedule constraint sets so no two constraints in the same set write to the same particle.
Step 4: XPBD solve
- Iterate partitions per substep.
Proposed pipeline (primary): voxelization -> voxel particles -> voxel constraints
Step 1: voxelize mesh on GPU
- Project triangles to a dominant axis
- Conservative rasterization to avoid missing voxels
- Atomics to resolve overlapping writes
Step 2: generate particles from occupied voxels
- Regular grid positions simplify neighborhood queries.
Step 3: deterministic partitioning
- Grid structure makes scheduling more stable than irregular tetra graphs.
Voxel constraint primitive (the core idea)
Instead of treating “edge distance constraint” as the primitive, I treat a voxel cell neighborhood as the primitive.
A single voxel constraint aggregates multiple sub-constraints:
- several local volume constraints
- several axis-aligned distance constraints
This increases arithmetic intensity (more math per memory fetch) and maps well to GPU workgroups.
LoD long-range constraints
Local constraints alone converge slowly for global stiffness. Voxels support multi-resolution structure naturally.
LoD helps by:
- adding longer-range constraints for stiffness
- reducing the number of iterations required for global effects
Results
Qualitative results (stiffness / behavior)
Show side-by-side captures or short clips:
- without LoD: droops/collapses more
- with LoD: holds shape better
Key metrics to report (use your slides/tables):
- constraint solving time per frame
- partition count / number of phases
- cost breakdown: voxelization vs solve
Takeaways
- Regular voxel structure makes parallel scheduling simpler and more predictable.
- Voxel constraints are a GPU-friendly work unit (fixed neighborhood, shared memory potential).
- LoD long-range constraints provide stiffness without relying purely on high iteration counts.
Limitations
- Resolution-dependent detail loss (voxel grid tradeoff).
- Extreme deformation can introduce self-collision / over-constraint challenges.
- Best suited for deformable soft-body behavior (scope-defined).
What I would do next
- Adaptive resolution (octree / sparse structures) for scale
- Better self-collision handling
- Authoring tools: interactive editing + profiling view for constraints