Elastic Vs Inelastic Collision

Working with collision detection in practice

I run a physics simulation engine for game development, and collision handling is where most projects quietly fall apart. People treat elastic versus inelastic collisions as a textbook topic and move on, then spend three weeks debugging why their objects are either bouncing through walls or sticking together like glue. The actual difference between the two concepts is simple on paper but extremely finicky to implement correctly at scale. An elastic collision conserves both momentum and kinetic energy. An inelastic collision conserves momentum but not kinetic energy. That second point is the one people mess up. In a perfectly inelastic collision, the objects stick together after impact and move as a single combined mass. Real-world collisions live somewhere between those two extremes, which is why we use a coefficient of restitution to bridge the gap. The coefficient of restitution, usually denoted as e, ranges from 0 to 1. A value of 1 means perfectly elastic. A value of 0 means perfectly inelastic. Everything else is somewhere in between and depends entirely on the materials involved. Steel on steel might give you 0.95. A lump of clay would be closer to 0.1. But here is the part nobody tells you when they are just starting out: the coefficient of restitution is not a fixed property of materials in simulation. It changes with impact velocity, contact area, and whether you are dealing with large objects or small ones.

I ran into this problem head-on about two years ago while working on a vehicle simulation. The cars were bouncing around too much at low speeds and barely reacting at high speeds. The original implementation used a single restitution coefficient of 0.85 for all collisions, which looked fine at first glance. The issue was that at velocities below 5 meters per second, the restitution was causing the vehicles to jitter and oscillate instead of settling. At velocities above 30 meters per second, the same coefficient made impacts feel like hitting a wall made of rubber bands rather than metal. The fix was velocity-dependent restitution with a soft floor. I capped the restitution at low speeds to 0.3 and let it ramp up toward 0.75 at higher velocities. This eliminated the jitter without making high-speed impacts feel floaty. It also required adjusting the damping values on the rigid bodies, because reducing restitution at low speeds meant momentum was dissipating differently than the solver expected. Once I aligned the damping with the new restitution curve, the simulation settled within two to three frames instead of oscillating for dozens.

The mechanics behind the calculations

Momentum conservation is the foundation you build everything on. The total momentum before impact equals the total momentum after impact regardless of whether the collision is elastic or inelastic. The equation is straightforward: m1 times v1 initial plus m2 times v2 initial equals m1 times v1 final plus m2 times v2 final. This holds true for one-dimensional collisions and extends into two and three dimensions using vector components. For elastic collisions specifically, you also apply kinetic energy conservation. One-half m1 v1 squared plus one-half m2 v2 squared equals one-half m1 v1 final squared plus one-half m2 v2 final squared. When you solve these two equations together for a one-dimensional elastic collision, you get clean closed-form solutions for the final velocities. The formulas are well known and easy to find, but applying them correctly in code requires careful attention to reference frames. The standard approach in real-time simulation is to work in the center of mass frame. You subtract the center of mass velocity from both objects, reverse the relative velocity along the collision normal, then add the center of mass velocity back. This gives you the post-collision velocities in one pass without solving a system of equations. It works for elastic collisions and adapts to partially inelastic ones by scaling the relative velocity by the coefficient of restitution before reversing it.

For inelastic collisions where objects stick together, you skip the energy equation entirely. After the collision, both objects share the same velocity, which you calculate by dividing the total momentum by the combined mass. Simple. The mistake most people make here is not accounting for rotational effects. If the collision is off-center, even a perfectly inelastic stick should generate angular velocity. Ignoring that will make your simulations look wrong in ways that are hard to diagnose because the linear motion will still obey conservation of momentum.

Common pitfalls that waste time

The biggest source of bugs in collision systems is tunneling. When objects move fast enough, they can pass through each other between simulation frames. A 100 meter per second object moving in a single frame might skip entirely past a thin wall. The naive fix is to reduce the timestep, but that increases computational cost linearly and often creates new problems with stability. A better approach is continuous collision detection, which interpolates the trajectory between frames and finds the exact moment of impact. This adds roughly 20 to 40 percent overhead per collision check depending on your geometry, but it eliminates tunneling without requiring sub-stepping. Another pitfall is mixing restitution values with impulse-based solvers without recalculating the impulse correctly. The standard impulse formula for a collision between two objects uses the relative velocity along the collision normal, the masses, the coefficient of restitution, and the coefficient of friction. If you use a restitution value that is lower than what the solver expects, you can end up with negative energy in the system, which causes objects to slow down on their own or behave erratically. I have seen this happen when someone copied a restitution value from a material database without checking whether the rest of the solver assumed a different energy model. Penetration resolution is also a frequent problem. When objects overlap after a collision, pushing them apart along the collision normal is standard practice, but doing this incorrectly causes objects to slide apart unnaturally or gain energy from the correction itself. The workaround is to use a position correction that is scaled by a penetration depth factor and applied gradually over multiple frames rather than all at once. A penetration correction of around 80 percent per frame usually handles this without introducing instability. The remaining 20 percent gets corrected in the next frame, which prevents energy injection.

When the standard approach breaks down

The coefficient of restitution model works well for rigid bodies with simple shapes and moderate speeds. It breaks down when you introduce deformable objects, high-frequency vibrations, or scenarios where heat and sound dissipation matter. A suspension bridge swaying under wind load or a car crumpling in a crash cannot be modeled accurately with a single restitution value. In those cases, you need a material model that accounts for stress-strain relationships and energy absorption through plastic deformation. Even for rigid body simulations, very high restitution values can cause instability. If you set restitution above 0.9 for a chain of objects colliding in sequence, the energy can amplify through the chain due to numerical precision issues, causing objects to fly apart at unrealistic speeds. I dealt with this in a particle simulation where 500 steel spheres were colliding in a container. Above a restitution of 0.88, the total kinetic energy in the system started increasing over time due to solver inaccuracies compounding across contacts. Dropping the restitution to 0.85 and adding a small velocity-based damping term fixed the energy drift without noticeably changing the visual behavior. For most real-time applications like games and interactive simulations, the elastic and inelastic collision framework is sufficient if you pay attention to the details. The key is treating the coefficient of restitution as a tuning parameter rather than a physical constant, implementing velocity-dependent values to handle different impact regimes, and using continuous collision detection to prevent tunneling. The margin of error in a well-tuned system is usually under 5 percent for kinetic energy conservation in elastic collisions and under 10 percent for momentum conservation across all collision types, assuming you are using a timestep below 16 milliseconds.