Help needed with texture mapping images ...

[Bob Drebin]

In article <91May3.173736edt.8286 at orasis.vis.toronto.edu>, culhane at vis.toronto.edu (Sean Culhane) writes:
|> 
|> Hello, all.
|> 
|> A *BIG* thanks to all those who replied to my previous posting about
|> transforming images.  I seems that the overwhelming majority would
|> use texture mapping to do the job (given that one has a VGX).
|> 
|> Now, I am faced with another problem, and have banged my head for just
|> several hours and I am very dizzy.  Here's my situation:
|> 
|> I have an image (in the format that lrectwrite expects), and I do a
|> 
|> 
|>    texdef2d( 1, 2, ImageSize, ImageSize, Image, 5, texprops);
|>    texbind(TX_TEXTURE_0, 1);
|> 
|> 
|> The result is that I only get ONE CORNER of a 256x256 image mapped onto the

Assuming you've also made a tevbind() call, and your texture coordinates
cover the range 0.0 - 1.0, you should see the whole image regardless of
the resolution of the image.  The textured image may appear fuzzier
than the original image, but you should see the whole image. The gl shrinks 
the image down to the maximum resolution the hardware can support (on a 
VGX: 256x256 for a non-mipmapped, non-clamped texture, and 128x128 for 
all other textures).  

I suspect your image is not packed correctly or your t2f() calls
do not cover the range [0.0,1.0].  I notice that you are using a 
two component texture - which is intensity-alpha, not RGBA.  Did 
you intend to do this?  If so, the texdef2d call expects the pixels 
packed two pixels to a long in the format AIAI,AIAI,etc. 


|> polygon.  So I look to the manual, and I read that the TX_TILE texture
|> property will support mapping of high-resolution images with multiple
|> rendering passes.  So, I've set up the following:
|> 
|> 
|>    float texprops1[] = {TX_MINFILTER, TX_BILINEAR,
|>    	 	     TX_MAGFILTER, TX_BILINEAR,
|>    		     TX_TILE, 0.0, 0.0, 0.5, 0.5,
|>    		     TX_NULL};
|>    float texprops2[] = {TX_MINFILTER, TX_BILINEAR,
|>    	 	     TX_MAGFILTER, TX_BILINEAR,
|>    		     TX_TILE, 0.5, 0.0, 1., 0.5,
|>    		     TX_NULL};
|>    float texprops3[] = {TX_MINFILTER, TX_BILINEAR,
|>    	 	     TX_MAGFILTER, TX_BILINEAR,
|>    		     TX_TILE, 0.0, 0.5, 0.5, 1.,
|>    		     TX_NULL};
|>    float texprops4[] = {TX_MINFILTER, TX_BILINEAR,
|>    	 	     TX_MAGFILTER, TX_BILINEAR,
|>    		     TX_TILE, 0.5, 0.5, 1., 1.,
|>    		     TX_NULL};
|> 
|> 
|> and the four texture definitions:
|> 
|>    texdef2d( 1, 2, ImageSize, ImageSize, Image, 10, texprops1); 
|>    texdef2d( 2, 2, ImageSize, ImageSize, Image, 10, texprops2); 
|>    texdef2d( 3, 2, ImageSize, ImageSize, Image, 10, texprops3); 
|>    texdef2d( 4, 2, ImageSize, ImageSize, Image, 10, texprops4); 
|> 
|> 

This is our error, the parameters for TX_TILE were supposed to be
virtual (0.0 to 1.0) regions as described in the texdef2d man page;
however the gl implementation incorrectly expects integer texel addresses 
in the range [0,ImageSize-1].  This bug is fixed in gl release 4.0 
(both ranges will be supported for backwards compatibility). So to get 
tiling to work, change your TX_TILE parameters from:

	TX_TILE, 0.0, 0.0, 0.5, 0.5,	
	TX_TILE, 0.5, 0.0, 1.0, 0.5,	
	TX_TILE, 0.0, 0.5, 0.5, 1.0,	
	TX_TILE, 0.5, 0.5, 1.0, 1.0,	

to:

	TX_TILE, 0.,0.,ImageSize/2.-1.,ImageSize/2.-1,
	TX_TILE, ImageSize/2.,0.,ImageSize-1.,ImageSize/2.-1,
	TX_TILE, 0.,ImageSize/2.,ImageSize/2.-1.,ImageSize-1,
	TX_TILE, ImageSize/2.,ImageSize/2.,ImageSize-1.,ImageSize-1,



|> and I draw the polygon like so:
|> 
|> 
|>    for( i=1; i<=4; i++ ) {
|>       texbind(TX_TEXTURE_0, i);
|> 
|>       bgnpolygon();
|>          t2f(t0);  v3f(v0);
|>          t2f(t1);  v3f(v1);
|>          t2f(t2);  v3f(v2);
|>          t2f(t3);  v3f(v3);
|>       endpolygon();
|> 
|>    } /* for */
|> 

Here are some additional tiling tips for your troubles:

1) It is wasteful to draw the entire rectangle for each tile --
   when possible it is better to draw only the portion of the 
   rectangle which the tile will actually cover.

2) It is best to bind textures in ascending, then descending order
   (ex: 1,2,3,4,4,3,2,1,1,2,3,...) to maximize texture memory usage.

3) A 2x2 tiling of an image is sometimes wasteful.  The maximum 
   internal tile texture size on a VGX is 128x128. The
   maximum internal texture size for a non-mipmapped, non-clamped 
   texture (which is the case in your example) is 256x256. So in
   your example the non-tiled textured image will be just as sharp as
   the tiled image.


|> 
|> I am obviously mis-interpreting something here, since making these changes
|> causes the texture to be BLACK! (or non-existant ... who's to say).
|> 
|> Once again, and and all help/comments are greatly appreciated.
|> 
|> Sean.
|> --
|> Sean Culhane, Computer Vision Lab,  |"I know not with what weapons World War
|> Dept. of Computer Science,          | III will be fought, but World War IV
|> University of Toronto               | will be fought with sticks and stones."
|> culhane@{vis|ai|cs}.toronto.edu     |          -- Albert Einstein



Hope this helps,

Bob Drebin
ASD