Real-Time Plastic Deformation for Vehicle Crashes

A fully simulated body that bends, buckles, and keeps the new shape.

Modern games have become remarkably good at rendering believable worlds, yet vehicle damage often stays surprisingly static. Many titles still lean on rigid bodies swapped for a pre-authored damaged mesh: the car pops from clean to crumpled and drives on. I wanted to explore the opposite approach, a fully simulated vehicle body that bends, buckles, and permanently deforms in real time, while staying light enough to run on mobile hardware. This is the first of three articles on that system, and it covers the foundation: the deformable body itself.

Why a crash is hard in real time

A convincing crash sits between two extremes. A rigidbody holds the distance between every pair of points fixed, so it can never dent. A fluid has no shape memory at all. A car chassis lives in between: thin sheet metal folds, buckles, and then stays folded. The catch is the budget. The simulation runs at a fixed 100 Hz, about 10 milliseconds per step, and in that window the same body also has to resolve its collisions with the world and with other cars, on hardware that includes phones. Deformation gets a few of those milliseconds, not all of them, and whatever it does has to stay stable no matter how hard the player hits something.

Anatomy of the car

Before the deformation, it helps to see how a car is put together. It is not just a single rigid body and a mesh, it is a structure built from several interacting components:

Vehicle
 ├── Softbody nodes
 ├── Links
 ├── Joints
 ├── Parts
 ├── Suspension
 │   └── Wheels
 └── Skinned mesh

The nodes are mass points, a few hundred of them spread through the body. The links are the springs and dampers that connect them and give the body its stiffness. The joints are the hinges and latches that hold detachable parts, the subject of the next article. The suspension feeds the tyre forces in, the subject of the one after. And the skinned mesh is the visible car: every vertex is bound to its nearest four nodes and simply follows them, the same way skin follows bone in character animation. Nothing in the visible car is animated by hand, it is all driven by the node positions.

Making damage permanent

An ordinary spring is elastic: stretch it and it pulls straight back to where it started. That is the opposite of what a crashed car does. The insight is that permanence is not a property of the force, it is a property of the rest state. When a connection is strained past a yield point during a hard enough impact, its rest length is rebaked to the deformed length. The dent becomes the new neutral shape, and the spring is then perfectly content in its crushed position with no memory of the original. Rest lengths are only ever allowed to move in the crushing direction, never back out, which is how folded metal behaves and, as it turns out, also the key to not destroying the car by accident.

Where the first attempt went wrong

The first version of this was simpler, and wrong. Any connection that was strained on contact immediately rebaked its rest length. It looked great in a single spectacular crash and hid a slow failure everywhere else. Every curb, every gentle nudge, every small scrape moved a few rest lengths, and because those moves only ever accumulated, cars slowly sagged and folded in on themselves over a session with no real crash at all. The body was quietly digesting its own numerical error. The fix is to gate the whole process. Plastic yield only engages past an impact-energy threshold, it spreads outward from the contact point through a controlled propagation rather than firing on every strained link, and it holds for a brief window of about a second before it settles. Ordinary driving now leaves the shape untouched, and only a genuine impact leaves a mark. Keeping that gate honest is most of the difference between a crash that reads as damage and a car that simply rots.

Dynamic stiffness

A car is not uniformly soft, and it should not deform the same way for a gentle nudge as for a full speed impact into a wall. Both facts come down to stiffness that changes with the situation, so stiffness and damping are not constants: they respond to the energy of the impact. When a hit lands, the affected region softens, and the softening spreads from the contact point with a smooth falloff, so the deformation blends into the surrounding metal instead of leaving a sharp crater. The spread is biased slightly along the direction of the impact, so a hit pushes the surface inward the way a real dent forms rather than expanding as a neat sphere. This dynamic stiffness is the heart of the system, and it is where most of the tuning effort goes.

Real physics, plus a little pragmatism

It is tempting to reach for a proper continuum model, the finite element plasticity you would run offline in an engineering tool. In practice that is both too expensive for this budget and too twitchy once you add fast collisions and stacking. So the model is an honest hybrid: a physically motivated backbone of masses, springs, dampers, and energy, with a layer of engineered behaviour on top that exists purely to keep the result stable and controllable. One small example makes the flavour concrete. A heavy part hanging off a single stiff joint, think of a bonnet on one hinge, tends to buzz and oscillate, because its rotational spring frequency lands right at the edge of what the solver can integrate cleanly at 100 Hz. The pragmatic fix is to inflate that part's rotational inertia, roughly three times over the textbook value, which pushes the frequency back into the stable range at the cost of making the part feel a fraction heavier than physics says it should. It is not correct, but it is invisible to the player, and it is the difference between a part that sits still and one that vibrates. Being willing to make that trade, and being honest that it is a trade, is what keeps the whole thing shippable.

A native layer on top of Jolt

Collision detection and the rigidbody solve are handled by the Jolt physics engine, which is fast and robust and something I did not want to reinvent. Everything specific to the deformable car sits in a custom native C++ layer on top of it:

   vehicle description (data file)
             │
             ▼
   native C++ vehicle layer
     softbody solve, impact analysis,
     dynamic stiffness, parts and joints
             │
             ▼
   Jolt physics engine
     broadphase, collision, constraint solver

There are two reasons that middle layer has to be native. The first is throughput: one car is a few hundred mass points and close to a thousand connections, updated every step, next to a constraint solver already doing eight iterations per step, and that work does not belong in a scripting language. The second is control. Reading impact energy back out of the solver and pushing fresh stiffness and damping into individual constraints every frame is not something a stock engine exposes cheaply, and doing it well is most of the engineering. The key optimisation turns out to be restraint: only the constraints near an active impact are touched each frame, and an update short-circuits the instant nothing has actually changed, because the real cost is not the arithmetic, it is talking to the solver.

Cars as data, not code

None of the numbers above live in code. Each vehicle is described by a data file: how the mass is distributed, how stiff and how damped each region of the body is, how the parts connect, and how readily each region yields. That separation matters more than it sounds. A new car, or a retune of an existing one, becomes an authoring task rather than a programming task, and the same engine drives a flimsy hatchback and a heavy sedan purely by swapping data. It also turns the least glamorous part of physics work, the endless tuning, into something you can iterate on in seconds without a rebuild.

The result is a body that takes a hit, folds, and keeps the scar, at a cost small enough to leave room for the rest of the car. The next piece of the puzzle is what happens when the damage is severe enough that the car stops being a single object, when doors, bonnets, and bumpers tear away and go their own way. That is the subject of the next article.