Quote:

However, Point 3 is still valid; The PE has a static stepsize. Assuming the PE is doing some sort of ODE integration, every Physics simulation I have ever programmed takes an ADAPTIVE stepsize in order to better integrate the physics behaiviour and reduce error. For eg, (straight from "Numerical REcipies in C") 4th order static stepsize Runge-kutta has a error O(h^5). A naive adaptive routine, say Runge-Kutta-Felberg method have errors of O(h^6) and this error can be imporved upon further by more intelligent adaptive procedures (Richardson Extrapolation for eg). In my experience, a locked-in stepsize is asking for trouble no matter what stepsize you choose


Please keep in mind that Numerical Recipes (got it here in the office) was not written with game programming in mind. One of the design flaws Doug and I have been battling with regular A6 collision detection is that movement step sizes are scalable and not fixed. This makes it hard to have reproducable behavior (think game replay or consistent gliding) in certain situations. IMHO fixed step sizes with occasional frame skipping is the way to go. If I remember correctly there was a similar argument in Game Developer's Magazine concerning Havok about a year ago.

Your original criticism however is valid: if the framerate drops because of physics calculations being too slow then for the next frame it will be even slower, etc. until the system comes to a halt or whatever bottleneck exists (e.g. collision detection, constraint solving) is overcome. Currently no frame skipping is done because I have not run into this problem very often, but this is definitely something that I should add: if physics processing takes longer than a certain amount of time freeze the objects for a few milliseconds. That will lead to hickups in the objects' motion but keeps the system from stalling.