Game Development Reference
As an interesting side note, spheres take a lot of polygons in order to generate an ac-
curate graphical representation of them. But, the physical representation of a sphere
is little more than a position and a radius, and calculating a sphere-to-sphere colli-
sion is very simple (check the distance between their centers against the sum of their
radii). Meanwhile, a box is the exact opposite; they're cheap to generate graphically
(only 12 triangles), but expensive to generate physically and requires much more
complex mathematics to resolve collisions between them. Because of this, spheres
are commonly used for the collision shape of an object, even if its graphical repres-
entation is not a sphere.
In addition, a newbie physics programmer would typically start out by using spheres
to represent the bounding volumes for objects to generate their very first broad
phase system. But, they will later graduate to using AABBs (similar to those de-
scribed previously) as they find that the spheres are not very good at representing
long, thin objects, and the mathematics aren't quite as efficient as AABB overlap
checks. Even though AABBs are technically boxes, they don't rotate (since the AA
stands for Axis-aligned), making the overlap math very simple—even simpler than
comparing two spheres for overlap.
The motion state
The motion state's job is to catalogue the object's current position and orientation.
This lets us to use it as a hook to grab the object's transformation matrix (also known
as a transform). We can then pass the object's transform into our rendering system
in order to update the graphical object to match that of the physics system.
This is an incredibly important point that cannot be ignored, forgotten, or otherwise
misplaced; Bullet does not know, nor does it care, how we render its objects. We
could add 100 physics objects into our application right now, and Bullet would move
them, detect collisions, and resolve them as we would expect a physics engine to do;
but unless we tell our OpenGL code to draw a graphical box object in the same loc-
ation, we will have no idea about what's going on (besides doing some step through
debugging and scanning the code, of course). Our physics and graphics engines are
completely isolated from one another, and they have different ways of representing
the same object.
Having no dependency between our graphics and physics is ideal because it means
that we could completely replace the physics engine without having to touch the