Simulating Rope Without Ever Blowing Up

Why games don't solve rope with forces

A rope or chain is, physically, a very long series of rigid or near-rigid links connected by joints, and simulating it by computing tension forces and integrating accelerations (as you would for a rigid body) tends to be numerically stiff: a taut segment resists stretching so strongly that a force-based solver needs a tiny time step or it explodes. Position-based dynamics (PBD), introduced by Müller et al. in 2007, sidesteps the problem by working directly with positions instead of forces: every constraint (like "these two points must stay a fixed distance apart") is satisfied by nudging positions directly, then velocity is recovered afterward from how far each point actually moved. The scheme is unconditionally stable in the sense that it can never diverge to infinity — a rope simulated this way stretches under too few iterations, but it never blows up.

The core loop

Each simulation step follows the same four-stage pattern, run once per frame:

1. predict:   p* = p + v·h + a·h²         (integrate as if unconstrained)
2. solve:     for each distance constraint (i, j):
                 Δp = correction that pulls |p*_i − p*_j| back to rest length L
                 apply Δp to p*_i and p*_j, weighted by inverse mass
              (repeat over all constraints, several iterations, Gauss–Seidel style)
3. update v:  v = (p* − p) / h
4. commit:    p = p*

The distance constraint between two adjacent chain points i and j, with inverse masses w_i and w_j, is corrected proportionally to how much each point is free to move:

Δp_i = − w_i/(w_i+w_j) · (|p_i − p_j| − L) · (p_i − p_j)/|p_i − p_j|
Δp_j = +w_j/(w_i+w_j) · (|p_i − p_j| − L) · (p_i − p_j)/|p_i − p_j|

Running this correction once per constraint per frame is cheap but only approximately satisfies every constraint at once, since fixing one link's length slightly disturbs its neighbours; running several Gauss-Seidel iterations per frame (sweeping through all constraints repeatedly) lets the corrections propagate along the chain and converge toward a globally consistent, nearly inextensible rope. More iterations mean a stiffer-looking rope at a proportionally higher cost per frame.

Why the catenary shape appears for free

A rope hanging under gravity between two fixed points settles into a catenary — the curve y = a·cosh(x/a) that minimises gravitational potential energy subject to the fixed total length — and the PBD solver reaches it naturally, without anyone coding the equation in: gravity pulls every free point predictor downward, and the distance constraints resist stretching, and the equilibrium of those two competing effects, iterated to convergence, is precisely the shape that a real hanging chain takes. It's the same reason a suspension bridge's main cable is close to a catenary (parabolic under a uniform horizontal load, to be precise, but the two are nearly indistinguishable for shallow sag) — the physics minimises energy, and the constraint solver is, in effect, doing that minimisation numerically, one small correction at a time.

Standing waves and self-collision

Because each link only talks to its immediate neighbours, a sharp perturbation at one end of the chain (a flick, a throw) propagates down the rope as a genuine transverse wave, and pinning both ends turns the rope into a natural standing-wave resonator, the same physics as a plucked string, with the fundamental and higher harmonics visible as the number of Gauss-Seidel iterations and simulated tension increase. Self-collision is added the same way as every other constraint: whenever two non-adjacent segments of the rope pass too close, an inequality constraint (rather than an equality one) pushes them apart only when violated, letting the rope coil and pile against itself without interpenetrating.

Frequently asked questions

Try it live

Everything above runs in your browser — open Chain and Rope and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.