96 lines
6 KiB
Markdown
96 lines
6 KiB
Markdown
------------------------ --------------------------------- --------------------
|
||
[Previous](50-07.html) [Table of Contents](index.html) [Next](51-02.html)
|
||
------------------------ --------------------------------- --------------------
|
||
|
||
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*.
|
||
|
||
------------------------ --------------------------------- --------------------
|
||
[Previous](50-07.html) [Table of Contents](index.html) [Next](51-02.html)
|
||
------------------------ --------------------------------- --------------------
|
||
|
||
* * * * *
|
||
|
||
Graphics Programming Black Book © 2001 Michael Abrash
|