Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 5 of 5

Thread: texelFetch() ...but with interpolation?

  1. #1
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,126

    texelFetch() ...but with interpolation?

    Does GLSL have something like this? If so I haven't found it.


    • texelFetch() has the nice property that you can specify texel coordinates directly, but it disables interpolation.
    • texture() supports interpolation, but you have to give it normalized 0..1 values not texel coordinates.


    I'm using a texture to store/sample a piecewise-linear interpolation function here, and I really want something where you specify texel coordinates directly AND you get the free interpolation supported by the texture sampler. Basically a texelFetch() function that, instead of accepting ivec3 texel coordinates, accepts vec3 texel coordinates (allowing coordinates between texel centers to be specified -- e.g. 15.4).

    As a work-around, I need to implement my own "textureFetch()" which mixes the two, calling texture() under-the-hood. But the disadvantage to this being you have to do this ugly texcoord math to map to 0..1 input values, and then map those 0..1 values to texcoords for proper sampling (because the linear function starts at the first texel's center and ends at the last used texel's center):

    Code :
    /**  texcoordToLinFunct() - Converts a 0..1 texcoord to a 0.5/N..(M-1)/N 
     *     texcoord used to lookup into a texture with normalized texcoords
     *     used to store a linear function.
     *
     *     \param N - width of texture (in texels)
     *     \param M - "used" width of texture (set to N if using full width)
     */
     
    vec3 texcoordToLinFunct( vec3 tc, ivec3 N, ivec3 M )
    {
       return tc * (M-1)/float(N) + 0.5/N ;
    }
     
    ivec3 res                = textureSize( tex, 0 );
    vec3 texel_coords = vec3( val1, val2, val3 );     // Texels units I "really" want to provide to a texture function...
    vec3 texel_coords_0_to_1 = texel_coords / res;
    vec3 tc = texcoordToLinFunct( texel_coords_0_to_1, res, res );
    vec4 = texture( tex, tc );
    Last edited by Dark Photon; 05-18-2012 at 08:36 AM.

  2. #2
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Currently, the only way you can achieve what you want is by using rectangular textures. When accessing those through texture() you actually pass non-normalized texture coordinates and you can also use linear filtering for them. The only downside is that you cannot have mipmaps with rectangular textures, but I suppose this is an acceptable limitation for your particular use case.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  3. #3
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,126
    Thanks! Had forgotten about those. Have seen them in reading long ago but never used them.

    Unfortunately that doesn't work easily here because there's no sampler2DRectArray. Would have to flip to 2D atlasing just to avoid the extra texcoord math above...
    Last edited by Dark Photon; 05-18-2012 at 09:09 AM.

  4. #4
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    985
    Yes, unfortunately rectangular textures don't have array versions.

    Quote Originally Posted by Dark Photon View Post
    Would have to flip to 2D atlasing just to avoid the extra texcoord math above...
    Wouldn't you have then the same problem, but this case with the atlas texcoord math?

    Btw, probably the best way would be if there was some sampler parameter for configuring whether you want to use normalized or non-normalized texture coordinates. Unfortunately, no such mechanism exists today...
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  5. #5
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,126
    Quote Originally Posted by aqnuep View Post
    Wouldn't you have then the same problem [with atlasing], but this case with the atlas texcoord math?
    No. With 2D RECT atlases, I wouldn't have to do the "map to 0..1 then shift/squeeze to 0.5/N..(M-1)/N mapping" business. But I would have to apply an XY atlas offset per inset texture to get to the right starting texel -- just an ivec2 add. But I don't want to constrain my data (modeler-generated) to fit within a single 2D atlas slice nor deal with atlas packing, so I probably won't go there.

    Really, I guess I don't appreciate the need for 2D RECT textures. If we just had another arg to the standard GLSL 2D/2D ARRAY texture sampling function textureLod() (e.g. normalized_coords = true), then we could tell GLSL not to do the 0..1 texcoord -> texel indices mapping internally (normalized_coords = false) and to just use our texel coords directly before sampling/interpolation.

    Btw, probably the best way would be if there was some sampler parameter for configuring whether you want to use normalized or non-normalized texture coordinates. Unfortunately, no such mechanism exists today...
    Agreed! We're thinking along the same lines here.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •