Copyright © 1992, Dr. Dobb's Journal

This article contains the following executables: XSHRP21.ZIP

Michael Abrash

Pleasing the eye with real-time computer animation is something less than a science, at least at the PC level, where there's no time for antialiasing and a limited color palette; in fact, sometimes it can be more than a little frustrating. For example, last month I implemented texture mapping in X-Sharp, the 3-D animation package that's an ongoing project in this column. My first implementation was disappointing; the texture maps shimmied and sheared badly, like a loosely affiliated flock of pixels, each marching to its own drummer. Then I added a control key to speed up the rotation; what a difference! The aliasing problems were still there, but with the faster rotation, the pixels moved too quickly for the eye to pick up on the aliasing; the rotating texture maps, and the rotating ball as a whole, crossed the threshold into being accepted by the eye as a viewed object, rather than a collection of pixels.

The obvious lesson here is that adequate speed is important to convincing animation. There's another, less obvious side to this lesson though. I'd been running the texture-mapping demo on a 20-MHz 386 with a slow VGA when I discovered the beneficial effects of greater speed. When, some time later, I ran the demo on a 33-MHz 486 with a fast VGA, I found that the faster rotation was too fast! The ball spun so rapidly that the eye couldn't blend successive images together into continuous motion, much like watching a badly flickering movie.

So the second lesson is that either too little or too much speed can destroy the illusion. Unless you're antialiasing, you need to tune the shifting of your images so that they're in the "sweet spot" of apparent motion, in which the eye is willing to ignore the jumping and aliasing, and blend the images together into continuous motion. Only experience can give you a feel for that sweet spot.

Last month, I added texture mapping to X-Sharp, but lacked space to explain some of the finer points. This month, I'll cover some of those points, and discuss the visual and performance enhancements I've added since last month.

In the very first installment of this column, I spent a good bit of time explaining exactly which pixels were inside a polygon and which were outside, and how to draw those pixels accordingly. This was important, I said, because only with a precise, consistent way of defining inside and outside would it be possible to draw adjacent polygons without either overlap or gaps between them.

As a corollary, I added that only an all-integer, edge-stepping approach would do for polygon filling. Fixed-point arithmetic, although alluring for speed and ease of use, would be unacceptable because round-off error would result in imprecise pixel placement.

More than a year then passed, during which time my long-term memory apparently suffered at least partial failure. When I went to implement texture mapping last month, I decided that since transformed destination vertices can fall at fractional pixel locations, the cleanest way to do the texture mapping would be to use fixed-point coordinates for both the source texture and the destination screen polygon. That way, there would a minimum of distortion as the polygon rotated and moved. Theoretically, that made sense; but there was one small problem: gaps between polygons.

Last month's double-DDA texture-mapping code worked adequately, but there were two things about it that left me less than satisfied. One flaw was performance; that's addressed shortly. The other flaw was the way textures shifted noticeably as the orientations of the polygons they were mapped onto changed.

Last month's code followed the standard polygon inside/outside rule for determining which pixels in the source texture map were to be mapped: Pixels that mapped exactly to the left and top destination edges were considered to be inside, and pixels that mapped exactly to the right and bottom destination edges were considered to be outside. That's fine for filling polygons, but when copying texture maps, it causes different edges of the texture map to be omitted, depending on the destination orientation, because different edges of the texture map correspond to the right and bottom destination edges, depending on the current rotation. Also, last month's code truncated to get integer source coordinates. This, together with the orientation problem, meant that when a texture turned upside down, it gained one extra row and one extra column of pixels from the next row and column of the texture map. This asymmetry was quite visible, and not at all the desired effect.

One of the truly nifty things about double-DDA texture mapping is that it is not limited to mapping a texture onto a single polygon. A single texture can be mapped across any number of adjacent polygons simply by having polygons that share vertices in 3-space also share vertices in the texture map. In fact, the demonstration program DEMO1 in the X-Sharp archive maps a single texture across two polygons; this is the blue-on-green pattern that stretches across two panels of the spinning ball. This capability makes it easy to produce polygon-based objects with complex surfaces (such as banding and insignia on a spaceship). Just map the desired texture onto the underlying polygonal framework of an object, and let double-DDA texture mapping do the rest.

Of course, there's a problem with mapping a texture across many polygons: Texture mapping is slow. If you run DEMO1 and move the ball up close to the screen, you'll see that the ball slows considerably whenever a texture swings around into view. To some extent that can't be helped, because each pixel of a texture-mapped polygon has to be calculated and drawn independently. Nonetheless, we can certainly improve the performance of texture mapping a good deal over last month.

The full source for X-Sharp is available in the file XSHRPn.ZIP in the DDJ Forum on CompuServe, and as XSHARPn.ZIP in the programming/graphics conference on M&T Online and the graphic.disp conference on Bix. (XSHARP21 is the first version that includes fast, assembly language texture mapping.) Alternatively, you can send me a 360K or 720K formatted diskette and an addressed, stamped diskette mailer, care of DDJ, 411 Borel Ave., San Mateo, CA 94402; and I'll send you the latest copy of X-Sharp. There's no charge, but it'd be very much appreciated if you'd slip in a dollar or so to help out the folks at the Vermont Association for the Blind and Visually Impaired.

I'm available on a daily basis to discuss X-Sharp on M&T Online and Bix; my user name is mabrash in both cases. There is no truth to the rumor that I can be reached under the alias "sheep-shearer," at least not for another 9999 sheep.

Copyright © 1992, Dr. Dobb's Journal