The engineering reality
A rigid body carries 13 numbers of state. A deformable body carries state per node — often thousands. That difference, plus stiffness-limited timesteps, is why soft body simulation costs orders of magnitude more, and why faking it is usually the right engineering decision.
Soft body physics looks impressive in demos and is frequently the wrong thing to build. Understanding exactly where the cost comes from tells you when it is genuinely worth it.
What changes when bodies deform
| Rigid body | Soft body | |
|---|---|---|
| State per body | Position, orientation, velocities | Position and velocity per node |
| Shape | Fixed — computed once | Changes every step |
| Collision geometry | Static, can be precomputed | Must be updated continuously |
| Timestep limit | Set by contact and velocity | Set by material stiffness |
| Self-collision | Not applicable | Required, and expensive |
| Typical cost | Baseline | 10–1000× depending on fidelity |
The stiffness problem
This is the constraint that surprises teams most. With an explicit integrator, stability requires a timestep small enough to resolve the fastest oscillation in the system. Stiffer material means higher frequency means smaller timestep.
The consequence is counterintuitive: stiff soft bodies are far more expensive than floppy ones. Simulating rubber is manageable; simulating something nearly rigid but slightly deformable can require a timestep so small that a rigid body with a separate deformation effect is dramatically cheaper and looks the same.
The mitigations are implicit integration — unconditionally stable but requiring a linear solve every step — or position-based methods, which trade physical accuracy for stability at large timesteps.
The three main approaches
| Method | Accuracy | Cost | Good for |
|---|---|---|---|
| Mass-spring | Low — not physically meaningful | Low | Cloth, rope, visual jelly |
| Position-based dynamics | Approximate but stable | Low–medium | Games; robust at large timesteps |
| FEM continuum | Physically correct | High | Engineering, medical, film |
For games, position-based dynamics is usually the sweet spot — stable, controllable, and fast enough for real time. For anything where the numbers must mean something, FEM is the honest choice and the budget must reflect it.
Why mass-spring disappoints in engineering contexts
It is the easiest to implement and the easiest to misuse. The problems:
- Material parameters are not physical. Spring stiffness is not Young's modulus, so you cannot specify a real material.
- Behaviour depends on mesh topology. Re-mesh the object and it behaves differently.
- Volume is not preserved without additional constraints — objects squash unnaturally.
- It is anisotropic by accident, stiffer along spring directions than across them.
For visual effects none of that matters. For anything where the deformation must be trusted, all of it does.
Self-collision: the cost nobody budgets
A rigid body cannot intersect itself. A deformable one can, constantly — cloth folding, a character's limbs, a compressed object.
- Every part of the surface must be tested against every other part.
- Spatial acceleration structures must be rebuilt each step, because the geometry changed.
- Resolving self-contact without introducing jitter or tangling is genuinely difficult.
- Cloth in particular tangles readily, and untangling is harder than preventing.
Self-collision often costs more than the deformation solve itself. Any estimate that omits it is wrong by a large factor.
What to fake, and how
The question that saves most projects: does the deformation need to affect gameplay or produce a trustworthy number, or does it just need to look right? If it only needs to look right, simulate nothing — animate it.
- Skeletal animation with secondary motion — a few driven bones give convincing jiggle at almost no cost.
- Blend shapes for predictable deformation like impacts.
- Shape matching — a lightweight technique giving plausible deformation with rigid-body-like cost.
- Proxy simulation — simulate a handful of nodes and drive a detailed mesh from them.
- Vertex shader deformation for waving, rippling and bending that carries no physical consequence.
When soft body is genuinely required
- Deformation determines gameplay — squeezing through a gap, deformable terrain that changes navigation.
- Medical or engineering simulation where material response must be physically meaningful.
- Cloth or rope that must interact correctly with the environment rather than merely look right.
- Destruction where the deformation drives the fracture.
Scoping it
- Decide fidelity first — visual plausibility or physical correctness. This choice drives everything else.
- Count the nodes. Resolution is the primary cost driver; halving it is usually worth more than any optimisation.
- Decide whether self-collision is required. If not, you avoid a large share of the cost.
- Choose the integrator deliberately — implicit or position-based if the material is stiff.
- Prototype the worst case early. Soft body performance is dominated by the hardest scene, not the average one.
Weighing deformable simulation for a game or engineering tool? Tell us what has to deform and why — we will say so if faking it is the better engineering call. See our physics engine service and 2D vs 3D engines.