67 lines
3.9 KiB
Markdown
67 lines
3.9 KiB
Markdown
#### Notes on the 3-D Animation Example {#Heading9}
|
|
|
|
The sample program transforms the polygon's vertices from object space
|
|
to world space to view space to the screen, as described earlier. In
|
|
this case, world space and view space are congruent—we're looking right
|
|
down the negative Z axis of world space—so the transformation matrix
|
|
from world to view is the identity matrix; you might want to experiment
|
|
with changing this matrix to change the viewpoint. The sample program
|
|
uses 4x4 homogeneous coordinate matrices to perform transformations, as
|
|
described above. Floating-point arithmetic is used for all 3-D
|
|
calculations. Setting the translation from object space to world space
|
|
is a simple matter of changing the appropriate entry in the fourth
|
|
column of the object-to-world transformation matrix. Setting the
|
|
rotation around the Y axis is almost as simple, requiring only the
|
|
setting of the four matrix entries that control the Y rotation to the
|
|
sines and cosines of the desired rotation. However, rotations involving
|
|
more than one axis require multiple rotation matrices, one for each axis
|
|
rotated around; those matrices are then concatenated together to produce
|
|
the object-to-world transformation. This area is trickier than it might
|
|
initially appear to be; more in the near future.
|
|
|
|
The maximum translation along the Z axis is limited to -40; this keeps
|
|
the polygon from extending past the viewpoint to positive Z coordinates.
|
|
This would wreak havoc with the projection and 2-D clipping, and would
|
|
require 3-D clipping, which is far more complicated than 2-D. We'll get
|
|
to 3-D clipping at some point, but, for now, it's much simpler just to
|
|
limit all vertices to negative Z coordinates. The polygon does get
|
|
mighty close to the viewpoint, though; run the program and use the "T"
|
|
key to move the polygon as close as possible—the near vertex swinging
|
|
past provides a striking sense of perspective.
|
|
|
|
The performance of Listing 50.5 is, perhaps, surprisingly good, clocking
|
|
in at 16 frames per second on a 20 MHz 386 with a VGA of average speed
|
|
and no 387, although there is, of course, only one polygon being drawn,
|
|
rather than the hundreds or thousands we'd ultimately like. What's far
|
|
more interesting is where the execution time goes. Even though the
|
|
program is working with only one polygon, 73 percent of the time goes
|
|
for transformation and projection. An additional 7 percent is spent
|
|
waiting to flip the screen. Only 20 percent of the total time is spent
|
|
in all other activity—and only 2 percent is spent actually drawing
|
|
polygons. Clearly, we'll want to tackle transformation and projection
|
|
first when we look to speed things up. (Note, however, that a math
|
|
coprocessor would considerably decrease the time taken by floating-point
|
|
calculations.)
|
|
|
|
In Listing 50.3, when the extent of the bounding rectangle is calculated
|
|
for later erasure purposes, that extent is clipped to the screen. This
|
|
is due to the lack of clipping in the rectangle fill code from Listing
|
|
47.5 in Chapter 47; the problem would more appropriately be addressed by
|
|
putting clipping into the fill code, but, unfortunately, I lack the
|
|
space to do that here.
|
|
|
|
Finally, observe the jaggies crawling along the edges of the polygon as
|
|
it rotates. This is temporal aliasing at its finest! We won't address
|
|
antialiasing further, realtime antialiasing being decidedly nontrivial,
|
|
but this should give you an idea of why antialiasing is so desirable.
|
|
|
|
### An Ongoing Journey {#Heading10}
|
|
|
|
In the next chapter, we'll assign fronts and backs to polygons, and
|
|
start drawing only those that are facing the viewer. That will enable us
|
|
to handle convex polyhedrons, such as tetrahedrons and cubes. We'll also
|
|
look at interactively controllable rotation, and at more complex
|
|
rotations than the simple rotation around the Y axis that we did this
|
|
time. In time, we'll use fixed-point arithmetic to speed things up, and
|
|
do some shading and texture mapping. The journey has only begun; we'll
|
|
get to all that and more soon.
|