Re: Per axis filtering would be cool.

I don't think this is necessary. For your atlas program you could just 
write the images side by side in a extra wide 2D texture. That would be 
done when the atlas loads. Then your fragment program (or even vertex 
program) could easily sample the different images. The image you want to 
sample would be multiplied by the width of the image (not the gl 
texture) and added to the x texture coordinate. To handle wrap around 
the x texture coordinate would be calculated by taking the incoming 
texture coordinate and modding it by the image width. Handling filtering 
at the edges could be tricky but its worth a try.

Tyler

Stephen J Baker wrote:

> Something that's coming up more and more in our work with shaders is
> that we're using textures as general lookup tables - and especially,
> we find 3D textures vastly more useful than they were in the past.
>
> However, nearly every non-traditional application trips up with the
> problem of filtering.
>
> For example:  There are many cases where we'd like to pack multiple
> small 2D maps into a single 3D map so that the shader can choose which
> 2D map to use on a pixel-by-pixel basis depending on some other criteria
> without having to bind several dozen 2D maps at once.  It's also a great
> way to make a texture atlas without losing the ability to have maps that
> wrap around.
>
> What screws us for this (and many other) application of texture is
> that MIPmapping (and other forms of filtering) have to be applied
> uniformly in all axes of the texture.  So as my 3D texture 'atlas'
> drops down the MIP pyramid, I not only get (desirable) blurring between
> the S,T axis texels - but also a blurring of two completely unrelated
> maps caused by MIPmapping in the third dimension.  Argh!
>
> It would be spectacularly useful if you could choose to filter with
> GL_LINEAR in (say) S,T - and use GL_NEAREST on the third axis.
>
> Something like:
>
>    glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, 
> GL_LINEAR_S_EXT ) ;
>    glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, 
> GL_NEAREST_T_EXT ) ;
>
> ...analogous to the way clamping is allowed independently in either axis.
>
> It's really painful to fake this behavior - especially if you want 
> MIPmapping.
>
> For simple LINEAR and NEAREST filtering, it seems to me that existing 
> hardware
> might even be capable of doing this - if only the API had the hooks to 
> turn it
> on.  Things are perhaps trickier for MIPmapping because the map sizes get
> kinda strange.
>
> So - if any IHV's or ARB members are listening...pretty please?
>
> -----------------------------------------------------------------------
> The second law of Frisbee throwing states: "Never precede any maneuver
> by a comment more predictive than "Watch this!"...it turns out that
> this also applies to writing Fragment Shaders.
> -----------------------------------------------------------------------
> Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
> L3Com/Link Simulation & Training (817)619-2466 (Fax)
> Work: [email protected]           http://www.link.com
> Home: [email protected]       http://www.sjbaker.org
>
> ----- FAQ and OpenGL Resources at:
>  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL
>



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.1.0 - Release Date: 27/05/2005

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Roadkill
  INET: [email protected]

Fat City Hosting, San Diego, California -- http://www.fatcity.com
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [email protected] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).