Watch a cloak billow in a modern game, a rope bridge sag under a hero's boots, or a sandbag squash when it lands — the odds are overwhelming that none of it was simulated with textbook physics. The textbook way is to sum up forces, turn them into accelerations, and integrate them forward in time. That is honest Newtonian mechanics, and for stiff things like cloth it is a nightmare: crank the stiffness up and the simulation explodes — particles fling off to infinity in a single frame unless you take absurdly tiny timesteps or solve a big linear system every frame.

In 2007 Müller and colleagues published a gloriously pragmatic escape hatch called Position-Based Dynamics (PBD). Its trick: stop reasoning about forces altogether. Work directly with positions. Guess where each particle wants to go, then simply move the positions until they satisfy the rules you care about ("stay this far apart", "keep this volume") — nudging each one the smallest distance it takes. The result is unconditionally stable, fast, and endlessly controllable, which is exactly why it, and its refinement XPBD, now runs the cloth, ropes, soft bodies, sand and even fluids in a huge slice of real-time graphics.

The one idea: predict, then project

A PBD step for a system of particles has three beats. First predict: ignore all the constraints for a moment and let each particle fly under gravity alone, giving a tentative predicted position \mathbf{p}_i. Then project: repeatedly shove those predicted positions around so the constraints hold. Finally, derive the velocity from how far each particle actually ended up moving.

Notice what is missing: nowhere do we compute a spring force, a stiffness matrix, or an acceleration due to a constraint. The constraints act by editing positions, and the velocities are inferred afterwards. That inversion — positions first, velocities as a consequence — is the whole philosophy, and the reason the method behaves so calmly.

Worked example: the distance constraint

The single most useful constraint stitches two particles together at a fixed rest length d — chain enough of them and you have a rope; weave a grid of them and you have cloth. Write it as a function that should equal zero:

Right now the two predicted positions are some distance \lVert \mathbf{p}_1 - \mathbf{p}_2 \rVert apart, so C is nonzero. We want to move both particles the minimum total amount to make C = 0. The correction must lie along the line joining them — call that unit direction \mathbf{n} = \frac{\mathbf{p}_1 - \mathbf{p}_2}{\lVert \mathbf{p}_1 - \mathbf{p}_2 \rVert}. Moving along \mathbf{n} is the cheapest way to change the length. The combined move must close the whole gap C, and we split it between the two particles in proportion to their inverse masses w_i = 1/m_i, so a heavy particle (small w) barely budges and a light one does most of the moving:

Sanity-check the split. The two corrections point opposite ways along \mathbf{n}, and their sizes add to exactly |C|, so after the move the length becomes precisely d. If particle 2 is nailed in place (infinite mass, w_2 = 0) the fractions collapse to \Delta \mathbf{x}_1 = -C\,\mathbf{n} and \Delta \mathbf{x}_2 = 0: the free particle does all the work and the pinned one never moves. That single formula, applied to every edge, over and over, is a PBD cloth solver.

Stiffness = iterations (and why that's a problem)

One projection sweep rarely satisfies every constraint at once — fixing edge A slightly breaks edge B its particle also belongs to. So PBD just repeats the sweep. Solving all the constraints one after another, reusing the freshly-updated positions as you go, is exactly Gauss–Seidel iteration. The more sweeps you run per frame, the more thoroughly the constraints are enforced, and the stiffer the material feels: two iterations give a loose, stretchy cloth; twenty give a taut, canvas-like one.

That is a wonderfully simple stiffness dial — but it is also PBD's original sin. "Stiffness = number of iterations" is not a physical quantity. The same cloth with the same iteration count feels different if you change the timestep or the mesh resolution, because each of those changes how much a single sweep accomplishes. Your art director tunes a beautiful drape at 30 fps; someone bumps the game to 60 fps and the cloth mysteriously goes limp. The stiffness was never really a property of the fabric — it was an artefact of the solver.

XPBD: making stiffness physical

XPBD keeps the entire predict–project–update loop but rewrites the correction so it remembers a real stiffness. Each constraint carries a compliance \alpha = 1/k (the inverse of stiffness — an infinitely stiff constraint has \alpha = 0 and reduces exactly to ordinary PBD). The per-iteration position change gains a denominator term that scales with compliance over the squared timestep:

The \Delta t^2 living inside \tilde\alpha is the magic: it precisely cancels the timestep-dependence that plagued plain PBD, so a chosen k yields the same physical stiffness whatever the frame rate. Extra iterations now buy you a more accurate solution of the same physics rather than a stiffer material. It is a small code change over PBD for a big correctness win, which is why XPBD is the version most engines actually ship.

Feel it: a swinging rope of constraints

Below is a live PBD rope: a chain of particles, the top one pinned, each joined to its neighbour by a distance constraint, all falling under gravity and settling into a hanging curve. Drag the iterations slider. At one iteration the constraints are barely enforced — the rope stretches long and rubbery, sagging well past its rest length. Crank the iterations up and each frame does many more Gauss–Seidel sweeps, the links snap toward their true lengths, and the rope stiffens into a taut, nearly inextensible cord. Same particles, same masses, same gravity — the only change is how hard the solver works.

This is precisely the effect the "Watch out!" warns about, made tangible: stiffness you can turn with an iteration knob. It is fast and stable and looks great — it just isn't a physical constant, which is the gap XPBD closes.

Why it never blows up — and what you trade for that

A force-based integrator can inject energy: a stiff spring stretched a hair produces a huge force, which over a finite timestep can overshoot to a larger stretch, a bigger force, and a runaway blow-up. PBD structurally cannot do this. Projection only ever moves a position toward satisfying a constraint — it pulls the configuration onto the valid set, never flinging it further out. It cannot add unbounded energy, so no matter how stiff the material or how large the timestep, the simulation stays bounded.

The catch, and it is an honest one: PBD is not physically accurate. It gives you motion that is plausible and controllable, not a faithful solution of the equations of motion. The effective stiffness in plain PBD isn't a real material constant; damping is implicit and a bit fuzzy; energy is not conserved exactly. For a film-quality engineering simulation you would reach for a proper implicit solver. For a game that must run 60 times a second and never explode, PBD's bargain — give up exactness, gain rock-solid stability and speed — is almost always the right trade. That is why it is everywhere.