Real-time Cloth Simulation on the GPU

Cloth Simulation Cloth simulations usually model textiles as a grid of mass points (vertices) held together by invisible connections. The goal is to represent physical influences like gravity, wind, and collisions in real time without the material tearing or stretching unnaturally like rubber. Wikipedia

XPBD (Extended Position-Based Dynamics) XPBD (Extended Position-Based Dynamics) is a modern algorithm that manipulates point positions directly to satisfy distance conditions (constraints) instead of calculating accelerations. The 'Extended' means that true physical stiffness is simulated independently of the framerate. Advantage: Absolutely stable, does not explode, and topological changes (like cutting cloth) are trivial. Disadvantage: It is an iterative approximation method and slightly less physically accurate than complex matrix solvers. PDF

GPU Parallelization To calculate tens of thousands of points in parallel on the graphics card, one must prevent 'race conditions' – i.e., two processing cores shifting the same node at the exact same time. The solution is called 'Independent Sets' (or Graph Coloring): The connections are divided into isolated groups (here 8 phases: 2 horizontal, 2 vertical, 4 diagonal) in which not a single point overlaps. This allows the GPU to process each group blindly and at maximum speed. Wikipedia

Data Structures For maximum GPU performance, data must be memory-aligned (16-byte alignment). Instead of using many individual variables, information is cleverly packed into blocks of four (vec4). A vertex stores, for example, [X, Y, Z, Inverse_Mass]. If a point has an inverse mass of 0.0, the algorithm ignores it, and it floats motionlessly in the air – an elegant trick for pinning cloth without extra if/then statements. Wikipedia

Original work

• Miles Macklin, Matthias Müller, Nuttapong Chentanez (2016): XPBD: Position-Based Simulation of Compliant Constrained Dynamics
• Matthias Müller, Bruno Heidelberger, Marcus Hennix, John Ratcliff (2007): Position Based Dynamics

How it works

The cloth is a grid of 100 × 100 = 10,000 particles. Each particle is a vec4 [x, y, z, 1/mass]; the top row has inverse mass 0 and is pinned. 39,402 distance constraints hold the particles together: horizontal, vertical and two diagonals against shearing. Per frame: integration (gravity, wind, position prediction), then 15 substeps in which every constraint is solved once (XPBD), finally the velocity from the position change.

• XPBD: per constraint the error C = |pA − pB| − rest length is computed and both particles are moved by λ = −C / (wA + wB + α) along the connection, weighted by inverse mass. α = compliance / dt² makes the stiffness independent of the time step. The elongation slider scales the rest length.
• GPU (WebGPU): three compute shaders (integrate, solve, velocity) with 64 threads per workgroup. All data stays in storage buffers on the GPU; the vertex shader reads the positions straight from the buffer. Nothing goes back to the CPU.
• Graph coloring: two threads must never write the same particle. So the constraints are sorted into 8 phases (even and odd columns, even and odd rows, two per diagonal). Within one phase no particle has two constraints, so each phase runs without locks. That is 15 · 8 = 120 solver dispatches per frame (plus one each for integrate and velocity).
• Without WebGPU: the same three steps in TypeScript on the CPU with the identical memory layout (Float32Array). The positions are copied into the mesh's vertex buffer every frame. 39,402 · 15 = 591,030 constraint solves per frame is a lot for a CPU; the frame rate drops clearly.
• Wind: fixed direction (5, 0, 15) plus a sine flutter from position and time. The flutter part also adds a slight lift (y: flutter · 2).

Source code:cloth.shader.tscloth-gpu.strategy.tscloth-cpu-physics.ts

Note XPBD vs. Mass-Spring Systems: In physical simulations, there are fundamental architectural differences when solving equations:

• Classical Mass-Spring Systems: Here, forces (Hooke's Law) are calculated, leading to accelerations and ultimately new positions. There are two ways to mathematically project these into the future (integration):
• Explicit Solvers (e.g., Forward Euler): These rigidly calculate the next step solely from the current state. They are easy to program but extremely unstable for stiff cloths. Forces can escalate and the simulation 'explodes' unless tiny, very performance-heavy time steps are chosen.
• Implicit Solvers (e.g., Backward Euler): These calculate the next step based on the future state. This is mathematically highly stable but requires solving massive global matrix equation systems in every frame. This is harder to parallelize on the GPU and breaks down if the structure changes (e.g., when the cloth is cut).
• The XPBD Compromise: XPBD completely bypasses this complex matrix problem by acting as a local solver. It combines the absolute stability of an implicit solver with the enormous speed, parallelizability, and dynamic adaptability of an explicit system.