84 lines
5.4 KiB
Markdown
84 lines
5.4 KiB
Markdown
Chapter 51\
|
|
Sneakers in Space {#Heading1}
|
|
------------------
|
|
|
|
### Using Backface Removal to Eliminate Hidden Surfaces {#Heading2}
|
|
|
|
As I'm fond of pointing out, computer animation isn't a matter of
|
|
mathematically exact modeling or raw technical prowess, but rather of
|
|
fooling the eye and the mind. That's especially true for 3-D animation,
|
|
where we're not only trying to convince viewers that they're seeing
|
|
objects on a screen—when in truth that screen contains no objects at
|
|
all, only gaggles of pixels—but we're also trying to create the illusion
|
|
that the objects exist in three-space, possessing four dimensions
|
|
(counting movement over time as a fourth dimension) of their own. To
|
|
make this magic happen, we must provide cues for the eye not only to
|
|
pick out boundaries, but also to detect depth, orientation, and motion.
|
|
This involves perspective, shading, proper handling of hidden surfaces,
|
|
and rapid and smooth screen updates; the whole deal is considerably more
|
|
difficult to pull off on a PC than 2-D animation.
|
|
|
|
------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
 *In some senses, however, 3-D animation is easier than 2-D. Because there's more going on in 3-D animation, the eye and brain tend to make more assumptions, and so are more apt to see what they expect to see, rather than what's actually there.*
|
|
------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
|
|
|
If you're piloting a (virtual) ship through a field of thousands of
|
|
asteroids at high speed, you're unlikely to notice if the more distant
|
|
asteroids occasionally seem to go right through each other, or if the
|
|
topographic detail on the asteroids' surfaces sometimes shifts about a
|
|
bit. You'll be busy viewing the asteroids in their primary role, as
|
|
objects to be navigated around, and the mere presence of topographic
|
|
detail will suffice; without being aware of it, you'll fill in the
|
|
blanks. Your mind will see the topography peripherally, recognize it for
|
|
what it is supposed to be, and, unless the landscape does something
|
|
really obtrusive such as vanishing altogether or suddenly shooting a
|
|
spike miles into space, you will see what you expect to see: a bunch of
|
|
nicely detailed asteroids tumbling around you.
|
|
|
|
To what extent can you rely on the eye and mind to make up for
|
|
imperfections in the 3-D animation process? In some areas, hardly at
|
|
all; for example, jaggies crawling along edges stick out like red flags,
|
|
and likewise for flicker. In other areas, though, the human perceptual
|
|
system is more forgiving than you'd think. Consider this: At the end of
|
|
*Return of the Jedi*, in the battle to end all battles around the Death
|
|
Star, there is a sequence of about five seconds in which several
|
|
spaceships are visible in the background. One of those spaceships (and
|
|
it's not very far in the background, either) looks a bit unusual. What
|
|
it looks like is a sneaker. In fact, it *is* a sneaker—but unless you
|
|
know to look for it, you'll never notice it, because your mind is busy
|
|
making simplifying assumptions about the complex scene it's seeing—and
|
|
one of those assumptions is that medium-sized objects floating in space
|
|
are spaceships, unless proven otherwise. (Thanks to Chris Hecker for
|
|
pointing this out. I'd never have noticed the sneaker, myself, without
|
|
being tipped off—which is, of course, the whole point.)
|
|
|
|
If it's good enough for George Lucas, it's good enough for us. And with
|
|
that, let's resume our quest for realtime 3-D animation on the PC.
|
|
|
|
### One-sided Polygons: Backface Removal {#Heading3}
|
|
|
|
In the previous chapter, we implemented the basic polygon drawing
|
|
pipeline, transforming a polygon all the way from its basic definition
|
|
in object space, through the shared 3-D world space, and into the 3-D
|
|
space as seen from the viewpoint, called *view space*. From view space,
|
|
we performed a perspective projection to convert the polygon into screen
|
|
space, then mapped the transformed and projected vertices to the nearest
|
|
screen coordinates and filled the polygon. Armed with code that
|
|
implemented this pipeline, we were able to watch as a polygon rotated
|
|
about its Y axis, and were able to move the polygon around in space
|
|
freely.
|
|
|
|
One of the drawbacks of the previous chapter's approach was that the
|
|
polygon had two visible sides. Why is that a drawback? It isn't,
|
|
necessarily, but in our case we want to use polygons to build solid
|
|
objects with continuous surfaces, and in that context, only one side of
|
|
a polygon is visible; the other side always faces the inside of the
|
|
object, and can never be seen. It would save time and simplify the
|
|
process of hidden surface removal if we could quickly and easily
|
|
determine whether the inside or outside face of each polygon was facing
|
|
us, so that we could draw each polygon only if it were visible (that is,
|
|
had the outside face pointing toward the viewer). On average, half the
|
|
polygons in an object could be instantly rejected by a test of this
|
|
sort. Such testing of polygon visibility goes by a number of names in
|
|
the literature, including backplane culling, backface removal, and
|
|
assorted variations thereon; I'll refer to it as *backface removal*.
|