Game Engine Architecture

(Ben Green) #1
665

Let’s take a look fi rst at how a constraint solver works in the trivial case
of a single pair of bodies connected by a single constraint. During each step of
the physics simulation, the numerical integrator will fi nd new tentative trans-
forms for the two bodies. The constraint solver then evaluates their relative
positions and calculates the error between the positions and orientations of
their shared axis of rotation. If any error is detected, the solver moves the
bodies in such a way as to minimize or eliminate it. Since there are no other
bodies in the system, the second iteration of the step should discover no new
contacts, and the constraint solver will fi nd that the one hinge constraint is
now satisfi ed. Hence the loop can exit without further iterations.
When more than one constraint must be satisfi ed simultaneously, more
iterations may be required. During each iteration, the numerical integrator
will sometimes tend to move the bodies out of alignment with their con-
straints, while the constraint solver tends to put them back into alignment.
With luck, and a carefully designed approach to minimizing error in the con-
straint solver, this feedback loop should eventually sett le into a valid solution.
However, the solution may not always be exact. This is why, in games with
physics engines, you sometimes witness seemingly impossible behaviors, like
chains that stretch (opening up litt le gaps between the links), objects that in-
terpenetrate briefl y, or hinges that momentarily move beyond their allowable
ranges. The goal of the constraint solver is to minimize error—it’s not always
possible to eliminate it completely.


12.4.10.2. Variations between Engines


The description given above is of course an over-simplifi cation of what re-
ally goes on in a physics/collision engine every frame. The way in which the
various phases of computation are performed, and their order relative to one
another, may vary from physics SDK to physics SDK. For example, some
kinds of constraints are modeled as forces and torques that are taken care
of by the numerical integration step rather than being resolved by the con-
straint solver. Collision may be run before the integration step rather than
aft er. Collisions may be resolved in any number of diff erent ways. Our goal
here is merely to give you a taste of how these systems work. For a detailed
understanding of how any one SDK operates, you’ll want to read its docu-
mentation and probably also inspect its source code (presuming the relevant
bits are available for you to read!). The curious and industrious reader can
get a good start by downloading and experimenting with ODE and/or PhysX,
as these two SDKs are available for free. You can also learn a great deal from
ODE’s wiki, which is available at htt p://opende.sourceforge.net/wiki/index.
php/Main_Page.


12.4. Rigid Body Dynamics

Free download pdf