Re: Per axis filtering would be cool.

Hi Steve...

Can you do this with fragment shaders in the meantime?

I know you said it would be a pain in the ass at the
moment, but by having a nearest filter in each dimension,
and manually filtering the texels on the fly in the S/T
axes could do what you want?

Just asking here, as I haven't actually worried about
using 3D atlases (atlii? :) at all...

I can see where it would be useful, but I would probably
just use manual lookups myself, so haven't looked at any
implementations or associated problems.

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
>

-- 
Leath Muller
Application Developer, Spatial Data Centre
Science, Technology and Information Group
Great Barrier Reef Marine Park Authority
Phone:  +61 7 4750 0858
Fax:    +61 7 4772 6093
Mobile: +61 0409 260 267
eMail:  [email protected]

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

-- 
Author: Leath Muller
  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).