4 ms·

You're right, there's a gradation of compromise, and I wasn't fully polite in my comment (nor did I think to attempt to determine OPs sex... then again, I'm a g

You're right, there's a gradation of compromise, and I wasn't fully polite in my comment (nor did I think to attempt to determine OPs sex... then again, I'm a guy with a "girl's name", so who's to say "Mary" is necessarily a girl? aaaanyway...). I'm not suggesting that all software must compute integrals in order to have convincing physics. However, when I see code like this I involuntarily get itchy: while (trig.isLineIntersectingCircle(circle, line)) { physics.moveCircle(circle); }

sago 12y ago
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.

sago 12y ago

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.