Thanks for that, sorry for my impoliteness in response. HN is sometimes frustrating in its density of people with Dunning Kruger problems. I am sometimes one of

Thanks for that, sorry for my impoliteness in response. HN is sometimes frustrating in its density of people with Dunning Kruger problems. I am sometimes one of them. You bring up a slightly different issue now, which I'm not sure if you are suggesting the problem is with the unbounded loop or with the serial strategy for resolution. On the former, I agree with in the narrow (interpenetration resolution isn't usually guaranteed to converge), but taking while (has_interpenetration()) { resolve_interpenetration(); } and adding a limit for (int i = relaxation_steps; i > 0 && has_interpenetration(); --i) { resolve_interpenetration(); } gives you code that is in most game physics engines, in some form. On the latter, modern game engines do some steps globally, rather than just running through each rigid body (often collision detection, interpenetration resolution, resting contact resolution, but not normally collision resolution or integration). But the OP approach of running everything in series wasn't unusual 15 years ago when game physics systems started to become ubiquitous. Before companies like Mathengine and Havok perfected LCP approaches, folks like Ipion and FastCar were doing impulse-based calculations that were heavily serial. So for a very simple JS experiment, it didn't strike me as a problem. I'd have written it that way too, if it were me.