Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!epicb!david From: david@epicb.UUCP (David P. Cook) Newsgroups: comp.graphics Subject: Re: Texture Mapping Keywords: texture, polygons, raster scan, fill area Message-ID: <568@epicb.UUCP> Date: 7 Dec 88 13:46:37 GMT References: <1737@solo9.cs.vu.nl> Reply-To: david@epicb.UUCP (David P. Cook) Organization: Truevision Inc., Indianapolis, IN Lines: 110 In article <1737@solo9.cs.vu.nl> valke@cs.vu.nl (Peter Valkenburg) writes: > > Hello, > >I have the following problem: > I want to display surfaces (polygons) in 3-D scenes containing > user-defined textures/pictures (raster images). > The combination of Raster Imagery into 3D scenes is dependent on your paticular application. However, using simple 2D primitives you can easily place a Raster Image ANYWHERE within a 3D scene. This is called FAKING IT. > The questions I'd like to pose are the following: > > 1) In the definition of such a texture polygon the raster image (the > tree) should be associated with the polygon that bounds it (the > square). Given a raster image and an arbitrary polygon in 3-D > world coordinates, how does one link them up, i.e. how should one > specify the position of one relative to the other? Think of the Raster Image as being bounded by a polygon with four corners (rectangle). Mapping this 2D polygon into 3D space is very straight forward, and simply requires taking each and every point within the polygon and transforming it to the desired 3D point. This requires scaling and translation on a point by point basis. You should also utilize antialiasing/interpolation to deal with zoom up/down effects. Of course you can speed up the process by making use of the fact that the original image is in raster order. > > 2) What kind of operations should work on the special type of > polygon mentioned above? The standard transformations that > apply to simple polygons (such as transforming to viewport > coordinates or clipping) could be used, but computing the > transformation of every raster scan "pixel" might be a very > costly (i.e. inefficient) way of doing things. An alternative here is to write some form of "plastic" algorithm. This type of algorithm takes the points on the edge of the polygon and transforms them into the new space (simple). Next, it takes the scan- lines between two points on the source polygon and maps them to the same points on the destination polygon, thus taking care of scaling, translation, rotation, and perspective in one step... For example, consider the following CRUDE attempt: Source Polygon Destination Polygon Containing Raster To Contain Raster 0---------------1 0 2 3 2 \ 4 5 4 \ 6 7 6 1 8---------------9 8 3 \ 5 \ 7 \ 9 In the above example, the SOURCE polygon contains four endpoints (labeled 0, 1, 9 and 8). The other numbers indicate endpoints on the edge of scanlines (ie.. scanline 2 - 3, 4 - 5, 6 - 7 etc.. 0 - 1 and 8 - 9 are also endpont edges to scanlines). Now, simply map those scanlines to the SAME endpoints in the destination polygon (ie.. scanline 2 - 3, 4 - 5 etc.) To take care of situations where the edgelists are different in size, you should interpolate the in-between points. The same for scanline spreads in the destination polygon. Simply do an interpolative spread of the color values to fill in the "missing" points. To map this into "3D" space (which is an illusion to begin with) simply project the four original endponts (0, 1, 9 and 8) into the desired 3D space positions, and interpolate the Z axies for each of the scanline edgepoints in the destination polygon. This will provide the proper projection. Note... if you use a polygon with MORE than four points, you can also introduce distortion and warping into the image. With more than four points you can, for example, bend a raster image around a surface WITHOUT having to deal with complex real-space calculations! The interpolation step can be as simple or complex as desired.. At the simplest, use AVERAGING to combine pixels and SPREADING to create pixels. In AVERAGING... simply add all pixels which overlap (either ALL [crudely] or weighted based on coverage [better]) and divide by the # of pixels (or by the totaled weight). In SPREADING, write a simple routine which will generate N numbers between two other numbers. For example, take the following: N M N . . . . . . . . M 0 9 0 1 2 3 4 5 6 7 8 9 number_of_values_needed = 10 incrementer = (M - N + 1) / number_of_values_needed for (l = N, M, incrementer); use (l); end_for NOTE: THIS IS BUT ONE OF THE MANY MANY WAYS... There are also methods to do the texture mapping via strict polygon manipulation as well as clasic texture mapping techniques. I prefer "faking it" if possible because it is usually faster. Also... better antialiasing and interpolation methods exist than what I have demonstrated here, but these are fast and produce an "acceptable" result depending on your needs (and timeframe). Thats All Folks! -- | David P. Cook Net: uunet!epicb!david | | Truevision Inc. | "Sometimes I cover my mouth with | | Indianapolis, IN | my hand to tell if I'm breathing" | -----------------------------------------------------------