Equation Of Elastic Collision

Why Elastic Collision Math Doesn't Work The Way You Expect

The standard textbook treatment of elastic collisions assumes two things that rarely hold up in the real world: perfectly rigid bodies and perfectly head-on impacts. When you're actually working with this stuff—whether it's particle simulation, physics problems for class, or engineering validation—the equations look clean on paper and fall apart the moment you try to apply them to anything with angular momentum or off-center geometry. I spent about three years doing molecular dynamics simulations where I kept getting weird results and couldn't figure out why until I stopped treating collisions as scalar events and started thinking about them as vector interactions with a restitution coefficient that actually varies by impact angle. That was the turning point for me.

Equation Of Elastic Collision

The basic formula most people memorize is this: for two masses m and m moving at velocities u and u along a line, the final velocities v and v after an elastic collision are: v = (m - m)/(m + m) × u + 2m/(m + m) × u v = 2m/(m + m) × u + (m - m)/(m + m) × u

That's the one-dimensional case. It's derived from simultaneous application of conservation of momentum and conservation of kinetic energy. The algebra is straightforward but tedious. You get two equations: mu + mu = mv + mv (momentum) (1/2)mu² + (1/2)mu² = (1/2)mv² + (1/2)mv² (energy)

Solve those simultaneously and you arrive at the result above. Standard stuff. Here's what nobody tells you about using these equations: they only work when the velocity change happens along a single line connecting the two objects at the moment of impact. That line is called the collision normal, and in 2D or 3D you have to resolve velocities into components parallel and perpendicular to it. The perpendicular components don't change in an elastic collision. Only the parallel components swap and redistribute according to the mass ratios. So the actual procedure in practice is:

1. Find the collision normal n = (x - x)/|x - x| at the point of contact. 2. Project both velocities onto n: u = (u · n)n and u = (u · n)n. 3. Apply the 1D elastic collision formulas to those scalar projections.

4. Reassemble: v = u + v and v = u + v, where the perpendicular components stay untouched. This decomposition step is where most people mess up. They apply the scalar formula directly to vector magnitudes, which gives garbage results whenever there's any tangential component to the impact. I remember working on a ballistics modeling project where we were tracking steel spheres bouncing off steel plates, and I kept getting the post-impact trajectories wrong by about 15 to 20 degrees depending on the angle of incidence. The issue was that I was treating the impact normal as fixed at the initial contact point, but the spheres were rotating, and the surface velocity at the point of contact had a tangential component from spin that shifted the effective collision normal slightly. The fix was to compute the relative velocity at the contact point including rotational contribution, then re-derive the normal from that adjusted vector. It added about four lines of code and cut the angular error down to under one degree. That's the kind of detail that separates something that looks right from something that actually predicts what's going to happen.

Another thing that comes up and people don't expect: when m = m, the equations simplify to v = u and v = u. In one dimension, equal-mass elastic collisions just exchange velocities. It's elegant, but it's also dangerously counter-intuitive if you're thinking about it in higher dimensions. In 2D with equal masses at an oblique angle, they don't simply swap velocities. The component exchange only happens along the collision normal. The perpendicular components pass through unchanged. This distinction matters if you're building anything that needs to look or behave correctly. There's also the issue of coefficient of restitution. The equations above assume e = 1.0 exactly. Real materials never achieve that. Steel on steel might hit 0.95. Rubber can be higher depending on temperature. Once e drops below 1.0, you're no longer dealing with elastic collisions, you're dealing with inelastic ones, and the energy equation changes to include the restitution factor. The modified formulas become: v = [(m - em)u + (1+e)mu] / (m + m)

v = [(m - em)u + (1+e)mu] / (m + m) When e = 1 you recover the elastic version. When e = 0 you get perfectly inelastic, where the objects stick together and move at a common velocity. The intermediate range is where most real-world simulation work actually lives, and it's worth knowing all three endpoints because you'll interpolate between them constantly. The biggest practical limitation I run into is what happens when collision detection fails. In discrete time-step simulations, two fast-moving objects can pass through each other between frames. The equations assume they made contact at some point, but if your timestep is too large, the objects are already overlapping or completely separated when you check. No collision normal exists at a valid contact point. I use continuous collision detection in those cases, which involves solving a quadratic for the exact time of first contact within the timestep. It adds computation but prevents objects from teleporting through walls, which is the alternative if you skip it.

For most homework problems, the 1D formulas are enough. If you're building a physics engine or running actual simulations, the vector decomposition approach is non-negotiable. Start with the normal, split the velocities, apply the scalar math, reassemble. That's the pattern that actually works.