texelFetch() ...but with interpolation?

[Dark Photon]

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):

/**  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 );

[aqnuep]

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.

[Dark Photon]

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...

[aqnuep]

Yes, unfortunately rectangular textures don't have array versions.

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...

[Dark Photon]

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.