Part of the reason this one isn't more widely known is certainly because there's already a lot of good tutorials. (And even more bad ones).
For every article like this one, there's quite a few people posting "here's another awesome tutorial!" -- and yes, guilty as charged.
Also, this is much closer to a textbook in scope & depth, which (a) turns a lot of people away, despite being a fantastic resource and (b) makes it less blog-able.
Even if your physics algorithms are wholly fake, you need quality contact resolution, or strange behavior will appear in collision responses, since any collision response is predicated on having correct contact information. (The consequence of bad contact quality, seen in lesser physics engines, is major errors where shapes can "squeeze through" other shapes or jitter against each other, gaining energy and eventually exploding.)
Here's another great game physics reference by Glenn Fiedler. It's a must-read for beginner (and not-so-beginner) game programmers and has helped me immensely.
Excellent. This is the kind of stuff that I'd love to see return to HN more often. Take a look at the rest of his blog, it's excellent too: http://www.wildbunny.co.uk/blog/
If I remember correctly from when I read about this 10 years ago, enforcing constraints by adding restoring forces/impulses is a bad way of doing it, because it gives very stiff equations. It works decently for soft constraints, like springs, but if you want to rigidly enforce a constraint, you need very large forces which are applied very suddenly, and to integrate such a system you need a very small time step. My impression was that it was much better to design your constraints into the equations of motion such that you reduce the number of degrees of freedom of the system and solve directly for the "constrained" motion. But that was research papers. Do real game engines use the method described here? Maybe the difference is the degree of "realism" required.
Games engines have these problems too. But instead of solving it mathematically which is hard (and still result in a pretty inefficient algorithm, as game worlds usually consist of complex geometry, not simple shapes), it is usually hacked around in some pragmatic way that still looks good.
Another excellent resource is the archive of Erin Catto's GDC presentations (Erin is the author of Box2D). Box2D was first presented in 2006; the 2005 presentation is about an iterative method for constraint solving in 3D.
Does anybody know how to calculate torque? Like if two billard balls collide, I suppose part of the impact translates into new velocities, and part into spin. How much spin, that is the question.
Another example: in the C64 game Thrust, a rocket drags a ball which is attached with a stick. The ball is like a pendulum, hanging from the rocket. Now if the rocket accelerates, how will the pendulum swing, and where will it pull the rocket? Another way to view this is a big ball with a rocket on it's skin, that can accelerate in any direction. How much of the acceleration will turn into velocity and how much into spin?
Maybe I should be able to figure out the latter case by simply drawing vectors, but last time I tried my knowledge of physics was insufficient.
http://www.digitalrune.com/Portals/0/Documents/A%20Unified%2...
(Had to google for a fresh link; unfortunately this doesn't seem to be nearly as widely mirrored as I believe it deserves.)
Things I liked about it:
- The author continually explains, compares, & contrasts alternative approaches throughout.
- It builds up a full actual system, including a lot of discussion of what other references may dismiss as mere software engineering.
- The author starts with the fundamentals and goes from there, usually fairly thoroughly.