Journal: Dr. Dobb's Journal Sept 1992 v17 n9 p141(7) ----------------------------------------------------------------------------- Title: Pooh and the space station. (fast texture mapping) (Graphics Programming) (Tutorial) Author: Abrash, Michael. AttFile: Program: GP-SEP92.ASC Source code listing. Program: XSHARP21.ZIP X-Sharp library for 3-D graphics. Abstract: Texture mapping is accomplished by mapping an image into the surface of a polygon that has been transformed in the process of three-dimensional drawing. Rapid texture mapping can be accomplished by quickly identifying the value for each pixel in the destination polygon. The pixel values of the polygon are found by mapping each destination pixel in the transformed polygon back to its bitmapped image by using a reverse transformation. The backwards transformation is used in order to avoid gaps in the final image. If the destination polygon is rotated in two directions, each transformed vertex should be mapped to the corresponding vertex in the bitmap. The rapid texture mapping method uses a two-stage digital differential analyzer (DDA) approach. An example of the texture mapping method using the likeness of Winnie the Pooh is presented. ----------------------------------------------------------------------------- Descriptors.. Topic: Computer Graphics Program Development Techniques Tutorial Texture Color Bit-Mapped Graphics Methods. Feature: illustration program chart. ----------------------------------------------------------------------------- Full Text: So, here's where Winnie the Pooh lives: in a space station orbiting Saturn. No, really; I have it straight from my daughter, and a six year old wouldn't make up something that important, would she? One day she wondered aloud, "Where is the Hundred Acre Wood, exactly?" and before I could give one of those boring parental responses about how it was imaginary--but A.A. Milne probably imagined it to be somewhere near London--my daughter announced that the Hundred Acre Wood was in a space station orbiting Saturn, and there you have it. As it turns out, that's a very good location for the Hundred Acre Wood, leading to many exciting adventures for Pooh and Piglet. Consider the time they went down to the Jupiter gravity level (we're talking centrifugal force here; the station is spinning, of course) and nearly turned into pancakes of the Pooh and Piglet varieties, respectively. Or the time they drifted out into the free-fall area at the core and had to be rescued by humans with wings strapped on (a tip of the hat to Robert Heinlein here). Or the time they were caught up by the current in the river through the Wood and drifted for weeks around the circumference of the station, meeting many cultures and finding many adventures along the way. (Yes, Riverworld; no one said the stories you tell your children need to be purely original, just interesting.) (If you think Pooh and Piglet in a space station is a tad peculiar, then I won't even mention Karla, the woman who invented agriculture, medicine, sanitation, reading and writing, peace, and just about everything else while traveling the length of the Americas with her mountain lion during the last Ice Age; or the Mars Cats and their trip in suspended animation to the Lesser Magellenic Cloud and beyond; or most assuredly Little Whale, the baby Universe Whale that is naughty enough to eat inhabited universes. But I digress.) Anyway, I bring up Pooh and the space station because a great many people have asked me to discuss fast texture mapping. Texture mapping is the process of mapping an image (in our case, a bitmap) onto the surface of a polygon that's been transformed in the process of 3-D drawing. Up to this point, each polygon we've drawn in X-Sharp (the 3-D animation package we've been developing in this column) has been a single, solid color. Recently, we added the ability to shade polygons according to lighting, but each polygon was still a single color. Thus, in order to produce any sort of intricate design, a great many tiny polygons would have to be drawn. That would be very slow, so we need another approach. One such approach is texture mapping; that is, mapping the bitmap containing the desired image onto the pixels contained within the transformed polygon. Done properly, this should make it possible to change X-Sharp's output from a bland collection of monocolor facets to a lively, detailed, and much more realistic scene. "What sort of scene?" you may well ask. This is where Pooh and the space station come in. When I sat down to think of a sample texture-mapping application, it occurred to me that the shaded ball we added to X-Sharp recently looked at least a bit like a spinning, spherical space station, and that the single unshaded, yellow polygon looked somewhat like a window in the space station, and it might be a nice example if someone were standing in the window .... The rest is history. Principles of Quick-and-Dirty Texture Mapping The key to our texture-mapping approach will be quickly determining what pixel value to draw for each pixel in the transformed destination polygon. These polygon pixel values will be determined by mapping each destination pixel in the transformed polygon back to the image bitmap, via a reverse transformation, and seeing what color resides at the corresponding location in the image bitmap, as shown in Figure 1. It might seem more intuitive to map pixels the other way, from the image bitmap to the transformed polygon, but in fact it's crucial that the mapping proceed backward from the destination, in order to avoid gaps in the final image. With the approach of finding the right value for each destination pixel in turn, via a backward mapping, there's no way we can miss any destination pixels. On the other hand, with the forward-mapping method, some destination pixels may be skipped or double-drawn, because this is not necessarily a one-to-one or onto mapping. Although we're not going to take advantage of it now, mapping back to the source makes it possible to average several neighboring image pixels together to calculate the value for each destination pixel; that is, to antialias the image. This can greatly improve texture quality, although it is slower. Mapping Textures Made Easy To understand how we're going to map textures, consider Figure 2, which maps a bitmapped image directly onto an untransformed polygon. Here, we simply map the origin of the polygon's object coordinate system somewhere within the image, then map the vertices to the corresponding image pixels. (For simplicity, I'll assume in this discussion that the polygon's coordinate system--its object coordinate system--is in units of pixels, but scaling images to polygons is eminently doable. This will become clearer when we look at mapping images into transformed polygons, below.) Mapping the image to the polygon is then a simple matter of stepping one scan line at a time in both the image and the polygon, each time advancing the X coordinates of the edges according to the slopes of the lines, just as is normally done when filling a polygon. Since the polygon is untransformed, the stepping is identical in both the image and the polygon, and the pixel mapping is one-to-one, so the appropriate part of each scan line of the image can simply be block copied to the destination. Now matters get more complicated. What if the destination polygon is rotated in two dimensions? We no longer have a neat direct mapping from image scan lines to destination polygon scan lines. We still want to draw across each destination scan line, but the proper source pixels for each destination scan line may now track across the source bitmap at an angle, as shown in Figure 3. What to do? The solution is remarkably simple. We'll just map each transformed vertex to the corresponding vertex in the bitmap; this is easy, because the vertices are at the same indices in the original and transformed vertex lists. Each time we select a new edge to scan for the destination polygon, we'll select the corresponding edge in the source bitmap, as well. Then--and this is crucial--each time we step a destination edge one scan line, we'll step the corresponding source image edge an equivalent amount. Ah, but what is an "equivalent amount?" Think of it this way. If a destination edge is 100 scan lines high, so it will be stepped 100 times, then we'll divide the SourceXWidth and SourceYHeight lengths of the source edge by 100, and add those amounts to the source edge's coordinates each time the destination is stepped one scan line. Put another way, we have, as usual, arranged things so that in the destination polygon we step DestYHeight times, where DestYHeight is the height of the destination edge. The above approach arranges to step the source image edge DestYHeight times too, to match what the destination is doing, as shown in Figure 4. Now we're able to track the coordinates of the polygon edges through the source image in tandem with the destination edges. Stepping across each destination scan line uses precisely the same technique. In the destination, we step DestXWidth times across each scan line of the polygon, once for each pixel on the scan line. (DestXWidth is the horizontal distance between the two edges being scanned on any given scan line.) To match this, we divide SourceXWidth and SourceYHeight (the lengths of the scan line in the source image, as determined by the source edge points we've been tracking, as described above) by the width of the destination scan line, DestXWidth, to produce SourceXStep and SourceYStep. Then, we just step DestXWidth times, adding SourceXStep and SourceYStep to SourceX and SourceY each time, and choose the nearest image pixel to (SourceX,SourceY) to copy to (DestX,DestY). (Note that the names used above, such as "SourceXWidth," are used for descriptive purposes, and don't necessarily correspond to the actual variable names used in Listing Two.) That's a workable approach for 2-D rotated polygons--but what about 3-D rotated polygons, where the visible dimensions of the polygon can vary with 3-D rotation and perspective projection? First, I'd like to make it clear that texture mapping takes place from the source image to the destination polygon after the destination polygon is projected to the screen. That is, the image will be mapped after the destination polygon is in its final, drawable form. Given that, it should be apparent that the above approach automatically compensates for all changes in the dimensions of a polygon. You see, this approach divides source edges and scan lines into however many steps the destination polygon requires. If the destination polygon is much narrower than the source polygon, as a result of 3-D rotation and perspective projection, we just end up taking bigger steps through the source image and skipping a lot of source image pixels, as shown in Figure 5. The upshot is that the above approach handles all transformations and projections effortlessly. It could also be used to scale source images up to fit in larger polygons; all that's needed is a list of where the polygon's untransformed vertices map into the source image, and everything else happens automatically. In fact, mapping from any polygonal area of a bitmap to any destination polygon will work, given only that the two polygons have the same number of vertices. Notes on DDA Texture Mapping That's all there is to quick-and-dirty texture mapping. This technique basically uses a two-stage digital differential analyzer (DDA) approach to step through the appropriate part of the source image in tandem with the normal scan-line stepping through the destination polygon, so I'll call it "DDA texture mapping." It's worth noting that there is no need for any trigonometric functions at all, and only two divides are required per scan line. This isn't a perfect approach, of course. For one thing, it isn't anywhere near as fast as drawing solid polygons; the speed is more comparable to drawing each polygon as a series of lines. Also, the DDA approach results in far from perfect image quality, since source pixels may be skipped or selected twice. I trust, however, that you can see how easy it would be to improve image quality by antialiasing with the DDA approach. For example, we could simply average the four surrounding pixels as we did for simple, unweighted antialiasing in this column last year. Or, we could take a Wu antialiasing approach (see my June column) and average the two bracketing pixels along each axis according to proximity. If we had cycles to waste (which, given that this is real-time animation on a PC, we don't), we could improve image quality by putting the source pixels through a low-pass filter sized in X and Y according to the ratio of the source and destination dimensions (that is, how much the destination is scaled up or down from the source). Finally, I'd like to point out that this sort of DDA texture mapping is display-hardware dependent, because the bitmap for each image must be compatible with the number of bits per pixel in the destination. That's actually a fairly serious issue. One of the nice things about X-Sharp's polygon orientation is that, until now, the only display dependent part of X-Sharp has been the transformation from RGB color space to the adapter's color space. Compensation for aspect ratio, resolution, and the like all happens automatically in the course of projection. Still, we need the ability to display detailed surfaces, and it's hard to conceive of a fast way to do so that's totally hardware independent. (If you know of one, drop me a line.) For now, all we need is fast texture mapping of adequate quality, which the straightforward, non-antialiased DDA approach supplies. I'm sure there are many other fast approaches, and, as I've said, there are certainly better-looking approaches, but DDA texture mapping works well, given the constraints of the PC's horsepower. Next, we'll look at code that performs DDA texture mapping. First, though, I'd like to take a moment to thank Jim Kent, author of Autodesk Animator and a frequent contributor to this column, for getting me started with the DDA approach. Fast Texture Mapping: An Implementation As you might expect, I've implemented DDA texture mapping in X-Sharp. Listing One (page 164) shows the new header files and defines, and Listing Two (page 164) shows the actual texture-mapped polygon drawer. The set-pixel routine that Listing Two calls is a slight modification of the mode X set-pixel routine from my June 1991 column. In addition, INITBALL. C has been modified to create three texture-mapped polygons and define the texture bitmaps, and modifications have been made to allow the user to flip the axis of rotation. In short, you will need the complete X-Sharp archive (available as described below) to see texture mapping in action, but Listings One and Two are the actual texture mapping code in its entirety. There's a lot I'd like to say about DDA texture mapping, and about the use of it in the DEMO1 program in X-Sharp, but I'll have to save most of it for next month because I'm running out of space. Here's the big thing: DDA texture mapping looks best on fast-moving surfaces, where the eye doesn't have time to pick nits with the shearing and aliasing that's an inevitable by-product of such a crude approach. Get the X-Sharp archive, compile DEMO1, and run it. The initial display looks okay, but certainly not great, because the rotational speed is so slow. Now press the S key a few times to speed up the rotation and flip between different rotation axes. I think you'll be amazed at how much better DDA texture mapping looks at high speed. This technique would be great for mapping textures onto hurtling asteroids or jets, but would come up short for slow, finely detailed movements. No matter how you slice it, DDA texture mapping beats boring, single-color polygons nine ways to Sunday. The big downside is that it's much slower than a normal polygon fill; move the ball close to the screen in DEMO1, and watch things slow down when one of those big texture maps comes around. Of course, that's partly because the code is all in C; if I get a chance, I'll convert to assembler and turbocharge the DDA texture mapping for next time, and maybe speed up the general polygon- and rectangle-fill code, too. I'll try to get to that next month, along with a further discussion of texture mapping and attending to some rough spots that remain in the DDA texture mapping implementation, most notably in the area of exactly which texture pixels map to which destination pixels as a polygon rotates. And, in case you're curious, yes, there is a bear in DEMO1. I wouldn't say he looks much like a Pooh-type bear, but he's a bear nonetheless. He does tend to look a little startled when you flip the ball around so that he's zipping by on his head, but, heck, you would too in the same situation. And remember, when you buy the next VGA megahit, Bears in Space, you saw it here first. Where to Get X-Sharp The full source for X-Sharp is available in the file XSHRP n.ZIP in the DDJ Forum on CompuServe and XSHARP n.ZIP in the programming/graphics conference on M&T Online and the graphic.disp conference on Bix. (XSHARP20 is the first version that includes 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 (user name mabrash in both cases). By the way, folks, I very much appreciate both your generous contributions to the Vermont Association for the Blind and your letters. However, I can't--honest-to-god, can't--write back to all of you. Not if I ever want to get any work done, anyway, and I have a family to feed. When I have time, I try to answer those of you who have written with questions, but there are no guarantees, especially given the flood of letters that have materialized in the wake of X-Sharp. You'll stand a lot better chance of getting a reply on MCI Mail, Bix, or M&T Online. Mind you, I do enjoy getting your letters, and the feedback and suggestions are great; it's just the responding part that's a problem. So keep those cards and letters (and e-mail messages) coming!