Game Development Reference
In-Depth Information
data objects within a rigid body simulator: the dynamics bodies, collision
geometry data, and constraints. Let's examine each of these in turn.
Dynamics body state.
Perhaps the most fundamental type of data object
within a real-time rigid-body simulator is the dynamics body. You can
think of the dynamics body as the “soul” of a rigid body: it tells it where
to go, but it has no outward appearance, so you can see it only indirectly
via the effects it has. The collision geometry (to be discussed later) is
what gives a rigid body its “earthly form,” meaning its shape. The part
of a rigid body that we see is usually some sort of graphical model, which
doesn't have anything to do with the physics engine and is not discussed
here.
At this point, it's probably important to discuss the relationship be-
tween a dynamics body and an “object” in the nontechnical (and nonpro-
gramming) sense of the word. A simple rigid object, such as the ubiquitous
video game crates Old Man Murray was so fond of reporting sighting, can
be simulated by using a single dynamics body. A more complicated object
with moving parts, such as a car or human body, is not a rigid body and
thus cannot be simulated with a single dynamics body. Instead, the object
must be broken down into rigid parts, and then the dynamics bodies cor-
responding to those parts connected via joint constraints, to be discussed
later. Of course, the graphical representation for such a compound ob-
ject like this need not be “rigid,” but within the physics simulation, each
dynamics body is a rigid body.
Another way that a dynamics body is like a soul is that it's easier to
just list its properties rather that attempt a precise definition. So let's
enumerate the variables that comprise a dynamics body. We classify these
variables by their life cycle, meaning when those variables are initialized and
how often their values change. Certain properties are (mostly) constant,
some change continuously over the life of the object, and some are working
variables, coming into existence (or reset) at the start of a simulation time
step and being thrown away at the end of the time step.
The first class of properties are those that are initialized when the body
is instantiated by the application, and typically (but not necessarily) remain
constant during the simulation.
•
The mass and inertia tensor are certainly critical properties of a rigid
body, and often these do not change over the course of the simulation,
although there is no inherent reason why they cannot be changed by
the application over time, for example, to simulate a car burning
fuel. As stated earlier, it's frequently the inverse mass and tensor
that are actually needed by a simulation, so these are often kept on
hand as additional derived quantities so that they do not need to
Search WWH ::
Custom Search