3D Scenes - Game Coding Complete - page 528

The first two data members, m_ActorId and m_Name , help to relate the scene node
to an object in your game logic and identify the scene node or the scene node type.
Just as you learned in Chapter 6,

“ Game Actors and Component Architecture, ” game

engines typically assign unique identifiers to objects in the game.
The Mat4x4 data members, m_ToWorld and m_FromWorld ,definethetransform
matrices. Transform() copies the member variables into memory you pass in. Gener-
ally, you don t want to just allow direct access to the transform matrices because chang-

ing them directly might break something. Various inherited classes of SceneNode or
ISceneNode might filter or otherwise set the transforms themselves.
The next data member, m_Radius , defines the radius of a sphere that includes the
visible geometry of a scene node. Spheres are really efficient for various tests, such
as visibility tests or ray-intersection tests. The only problem with spheres is that
they don ' t closely match most geometry, so you can ' t use them alone. Some commer-
cial games actually do this, though, and you can tell when you play. An easy way to
tell is if gunshots seem to hit, even though you aimed too far to the left or right.
Better games will use the sphere as a first pass test, since it is so fast, and go to
other more expensive tests if needed.

'

Instead of Bounding Spheres, Use Axis-Aligned Bounding Boxes

A great optimization to this simple idea would be to replace the sphere with
something called an axis-aligned boundingbox, or AABB. This is a shape that
is a rectangular solid, but its faces are always aligned parallel to the X-, Y-,
and Z-axes. As objects move and rotate, the dimensions of the AABB change
to make sure the visible geometry is always inside the smallest possible AABB.
They aren ' t hard to code, but they do take a little more work than a simple

sphere. I ' ll leave that to you as an exercise.

When a scene graph is traversed, like most tree-like data structures, it is traversed in
a particular order. This order, when combined with various render state settings, cre-
ates different effects or enables an efficient rendering of the entire scene. Every node
of your scene graph belongs to one of a few different possible render passes — one for

static objects, one for dynamic objects, one for the sky, and perhaps others.
The reason you want to do this is mainly for efficiency. The goal is to minimize re-
drawing pixels on the screen each frame. It makes sense to draw your scenery,
objects, and sky in whatever order approaches this goal, hoping to draw things
mostly from front to back to get all your closest objects drawn first. With any luck,
by the time you get to your sky, you won

t have to render hardly any pixels from it at
all. After everything, you run through your transparent objects from back to front to
make sure they look right. The m_RenderPass data member keeps track of which

'