Game Development Reference
In-Depth Information
The forces and torques generated are never represented in an explicit data struc-
ture. They are applied directly to the appropriate rigid body as soon as they
are calculated.
Contacts are generated by the collision detector and stored together, before
being sent as a group to the collision resolver.
To represent objects in the game we need three kinds of data:
Rendering geometry and materials are used to display the object on screen.
This is normally not used at all by the physics engine, although it can take the
place of the collision geometry for very simple objects.
Collision geometry is a simplified set of shapes that represents an object. It is
used to speed up collision detection. In some engines the collision geometry
is made up of a polygonal mesh, just like the rendering geometry. In other
engines objects are made up of sets of primitive shapes such as ellipsoids and
boxes. In both cases a comprehensive collision detection system will typically
need more than one level of collision geometry: the lowest level will be en-
closed in one or more bounding volumes.
Rigid-body data contains information about the physical characteristics of the
object. It includes things like mass and inertia tensor, as well as position and
velocity. In our engine most of this is encapsulated in the rigid body class. In
pairs of surfaces and their restitution.
These three kinds of data, along with the four parts of the engine and the two internal
lines of communication, work together to provide the physics simulation. Figure 17.1
shows how the data passes through the system.
This is the basic design of most physics engines, although there are some varia-
tions. In particular it is possible to add additional components to the pipeline, such as
a batch processing algorithm to divide the set of contacts into unconnected batches.
Some engines also have another stage of rigid-body update at the end of the pipeline,
especially if the result of the collision resolution system is a set of forces to apply.
The whole physics pipeline is typically contained within a single call in the game
loop. We could easily create a black-box physics system that keeps track of everything
needed to run the physics simulation. In this topic, as well as in real game develop-
ment, I avoid doing this. In real game development physics isn't happening for its
own sake; it is just part of the whole game, and the data that the physics system needs
overlaps with data needed elsewhere. A black-box system can easily duplicate work
and cause a nightmare trying, for example, to make sure that all copies of an object's
position are synchronized.
In a real game different objects will also need different additional data. Some
objects may be active and so require data for the AI. Other objects may be player-
controlled and require network data for synchronization. Any objects can require
game-specific data such as hit points or value. Such complexities can make it difficult
to ensure that the physics data is correctly initialized and represents realistic objects
(the inertia tensor is notoriously easy to get wrong).