Game Development Reference
graphics engine, and vice versa. It also means that we can have invisible physics
objects (such as force fields), or graphical objects that don't need a physical presen-
ce (such as particle effects).
It is not uncommon for a game engine to separate these components entirely
with three different libraries, resulting in the three different sets of Vector3 / Mat-
rix4x4 / Quaternion classes in the lowest levels; one set for the physics, one
set for the graphics, and one set for general game logic.
As an example of extending Bullet, we will be creating our own motion state class
called OpenGLMotionState . This class will extend Bullet's btDefaultMo-
tionState to provide a useful helper function that simplifies the process of extract-
ing the objects transform data into a format our rendering system can use.
The collision object
Collision objects are the essential building blocks of our physics objects, since they
maintain the object's physical properties, and give us a hook from which to alter the
object's velocity, acceleration, apply a force upon it, and so on. When we query the
motion state for the transform, it actually comes to this object to obtain it.
The simplest and most commonly used type of collision object is a btRigidBody .
Rigid bodies are physics objects that do not deform as a result of collisions, as op-
posed to soft bodies which do. Rigid bodies are the easiest collision objects to deal
with because their behavior is consistent, and doesn't require extravagant mathem-
atics to handle basic collisions, unlike soft bodies which are far more difficult and
expensive to simulate.
Rigid bodies also require a btRigidBodyConstructionInfo object to be passed
through their constructor. This object stores data of important physical properties for
the rigid body, such as mass, friction, restitution, and so on.