236 CHAPTER 7: Well-Rendered Miscellany^
Nothing special here in line 1, but instead of describing the square in
the x-y plane as we’ve done before, it is in the x-z plane and y=0. Oh,
wait! There is something special. Notice the y coordinates. Instead of
being a sane value like 0.0, they are a slight negative value, of -0.01.
That is a quick hack to fix a problem called ‘‘z fighting,’’ in which pixels
from co-planer objects may or may not share the same depth value.
The result is two faces flickering at one moment; face A is the
frontmost, and the next, the pixels of face B, now think they are
frontmost. (Note that it shows only on hardware. It will look fine in the
simulator.) If you look hard enough in almost any real-time 3D
software, you will likely see some z’s fighting in the background.
Figure 7-12.
In this case, the fix is to drop the y of the platform down just a tad, to
be below the shadow. This fix doesn’t always work, because it
depends on the environment, the scale of things you’re dealing with,
and so on. Another workaround is to use the call glPolygonOffset().
But that again is no assurance of success. Sometimes you just have to
try to see what works.
Since the platform’s coordinates are normalized, we need to scale
them up a bit to make it usable, as in line 2.
Line 3 turns off face culling. The reason is that since the platform is a
single square and we could go under it easily enough, we need to see
both sides of the same faces.
Line 4 is the same here as elsewhere; it merely rotates the platform
into world space.
Line 5 does the actual scaling; place it as the first transformation to be
executed. (Remember, the transformation stack can be thought of as a
FIFO: the first transformation in is the first to be executed. If the
scaling was after another transformation, it would scale things off-
center from the desired result.)