Member-only story
Physics Engine Deep Dive: Part II
If you’re a non-premium user, click here to read the full article for free. Otherwise, continue reading.
This is part two of a series. Part one can be found here.
In the last article, we defined some terms: we learned what rigid bodies were, breezed through Newtonian kinematics, and developed some simple force models. We also explored the idea of physical stability using Linear Stability Theory (LST). This gave us an explicit method for determining how our force models and parameters affect the stability of the system.
In this article, we are going to deep dive numerical methods. We’re going to try to understand how they work and more importantly, why sometimes they don’t work.
Recap
In Part I, we briefly touched on the fact that numerical methods operate iteratively. That is, given the current state of a system, a numerical method approximates a future state (Why can’t we just figure out the exact solution to a complex system? Among other reasons, see Bonini’s Paradox.). These methods are generally given small time steps like 1/60th or 1/30th of a second where the smaller the time step, the closer the approximation will be to the actual solution.
Games are particularly fascinating bits of software because they need to operate in realtime. They need to do work many times a second, usually linked in some way to the refresh rate of a display. This means that, for a game trying to run at 60 fps, each frame we only have 1/60th of a second (probably less) to do processing. Add in a physics simulation that may take a few milliseconds every frame, and now we’ve got even less time to do any processing.
Because of this, it behooves a physics engine to maximize that time step without letting the difference between the approximation and the explicit solution grow. This is fairly simple to see: if we can achieve good results from running our physics engine only once every 1/15th of a second or every 1/10th — that is preferable to running it every 1/60th of a second.
