Game Development Reference
In-Depth Information
The
render()
method is where it gets interesting. The first thing we do is push the current TOS
of the model-view matrix, which will be set active outside of the object. Since this method is
recursive, we will save the parent's transformations by this.
Next, we apply the transformations that rotate the object around the parent and place it relative
to the parent's center. Remember that transformations are executed in reverse order, so we
actually first place the object relative to the parent and then rotate it around the parent. The
rotation is executed only if the object actually has a parent. The sun crate doesn't have a parent,
so we don't rotate it. These are transformations that are relative to the parent of the object and
will also apply to the children of the object. Moving the planet crate around the sun crate also
moves the “attached� moon crate.
The next thing we do is push the TOS again. Up until this point, it has contained the parent's
transformation and the object's transformation relative to the parent. We need to save this matrix
since it's also going to be applied to the object's children. The self-rotation of the object and its
scaling do not apply to the children, and that's why we perform this operation on a copy of the
TOS (which we created by pushing the TOS). After applying the self-rotation and the scaling
transformation, we can render this object with the crate mesh to which it stores a reference.
Let's think about what will happen to the vertices given in model space due to the TOS matrix.
Remember the order in which transformations are applied: last to first.
The crate will be scaled to the appropriate size first. The next transformation that gets applied
is the self-rotation. These two transformations are applied to the vertices in model space. Next
the vertices will be translated to the position relative to the object's parent. If this object has
no parent, we'll effectively translate the vertices to the world space. If it has a parent, we'll
translate the vertices to the parent's space, with the parent being at the origin. We will also
rotate the object around the parent, if it has one, in parent space. If you unroll the recursion, you
will see that we also apply the transformations of this object's parent, and so on. Through this
mechanism, a moon crate will first be placed into a parent's coordinate system, and then into the
sun crate's coordinate system, which is equivalent to world space.
After we are done rendering the current object, we pop the TOS so that the new TOS only
contains the transformation and rotation of the object relative to its parent. We don't want the
children to also have the “local� transformations of the object applied to them (that is, rotation
around the object's y axis and object scale). All that's left is recursing into the children.
Note
We should actually encode the position of the
HierarchicalObject
instance in the form
of a vector so that we can work with it more easily. However, we have yet to write a
Vector3
class. We will do that in the next chapter.
Putting It All Together
Let's use this
HierarchicalObject
class in a proper program. For this, simply copy over the code
from the
CubeTest
class in Listing 10-6, which also contains the
createCube()
method that we'll
reuse. Rename the class
HierarchyTest
and also rename the
CubeScreen
to
HierarchyScreen
.
All we need to do is create our object hierarchy and call the
HierarchicalObject.update()
and
HierarchicalObject.render()
methods in the appropriate place. Listing 10-8 shows the portions
of
HierarchyTest
that are relevant.
