clamping with linear filter on float textures broken?

I have floating point textures that represent elevation data. I’m trying to stitch them together into a target float texture in FBO. I use clamp to edge, and they join seamlessly, when I’m using nearest filtering, but when I change the filtering to linear, the values at the edge of the source texture jump (the vaules in the middle of the texture are filtered correctly)…

This happens on an nVidia GF6600 with 84.21 drivers on WinXP.

If you’re from nVidia, I can send you some screenshots, where the problem is easily seen.



What filtering do you want to achieve at the edges when “stitching textures together” with linear filtering?
Sounds like you would need texture border texels with the border data filled from the adjacent textures.

Yes, borders would be the best, but unfortunately I don’t have those… :frowning: Still, just clamping to the edge would work OK for me. But with float textures it doesn’t repeat the edge values, but jumps instead to a seemingly random value (not totally random, but I couldn’t recognize a formula). I have the same stitching mechanism working with regular (non-float) RGBA textures, and there it works fine. Sure, it’s not perfect, because I don’t have borders, but it’s pretty darn good, zooming in, I can see that the pixel values at the edge are clamped to the edge texel…

borders would be the best, but unfortunately I don’t have those

Ok enough crap how you possibly can NOT have the borders ??? just take the left most column of the texture on the right etc.
One day I will do this tutorial on borders … too much booze this evening :stuck_out_tongue:

No really, borders are the single best thing before GLSL, do yourself a favour, use them !

Dude, I know what borders are, and how to use them, that was not the question. Trust me, in my case, getting the border pixels is not that simple as you imagine. So, again, I want to clamp to edge, whether you like it or not, and it seems to be broken… Does anyone care??

what youre asking for is impossible cause the filtering method has to sample from 2 textures (perhaps u could write a shader that does the sampling from 2+ textures but that seems a PITA)
A/ use texture borders
B/ fake the borders manually yourself by skrinking the texture by a 1 pixel pixel and filling this border with the pixels from the neighbouring textures (prolly a better method than a cause its supported on all hardware)

both are difficult + timeconsuming

C/ easy method (what u have now) increase the texture resolution as much as possible (eg 4096x4096) + use clamp_to_edge, thus the error is less visable but its still there

Let me try again, and please(!) read more carefully!:

I know that what I’m doing is not the correct way to stitch textures. But let’s just forget about what I want to achieve, and focus on the part, that when using clamp_to_edge, texels outside the texture do not equal the texels of the edge.

file a bug to nvidia

How do I do that?


Yeah, I can’t see any means to report a bug there. I assume I would have to be a registered developer (I’ve tried to register a long time ago, but they never got back to me…). Why can’t they just have a public email address, or some web interface where anyone could send in bug reports??

Hi, i have the same problem. My issue does require clamp to edge with float textures because it is a single 3D texture being volume rendered. The volume has distance field information and thus around the edges of the volume values are likely to be -100 or so. (this is a floating point texture)

if iso-surfacing this volume for example, i cast rays into it (on hardware) to detect values that are larger than a given iso value (e.g -5 or so), thus if there is no iso surface along a ray (usually near the edges) and i get to the back of the volume, the clamp to edge should ensure that i get a value in the region of -100, however it appears to give back 0

this is true for all drivers i have tested with float textures and also FBO’s. if the iso value being used is below 0 the algorithm does not display the correct result, if it is above 0 it does, thus i believe it will give back 0.

Did you file a bug report ? and was there any resolution ?,

I also tried to use clamp to border and provide a unclamped value (e.g -100) however this does not work either as no rendering takes place after the call to define the border, the clamp to border spec suggests that you can use unclampted border values, however i have tested several drivers and cant get this to work !

Any comments would be appreciated !

What internal format are you using?

NVIDIA’s hardware support for floating-point texture filtering is limited. In particular, our current hardware does not support filtering of 32-bit floating-point components. If you are using the ARB_texture_float 32-bit components, you are likely hitting a software fallback path. Perhaps there is a bug there somewhere. I know I fixed a couple float texture software rasterizer bugs since 84.21 shipped, but I can’t remember if any of these would affect you.

I’m not aware of any hardware issues for 16-bit floating-point texture filtering support. If you’re using fp32, you might want to try the equivalent fp16 format for comparison.

In some cases, it’s possible to fake fp32 filtering in a shader by displacing the coordinates and doing multiple point samples. That is not at all easy (or even possible) in the general case when mipmapping is involved.

Feel free to send me an image or a repro case. My email address is pbrown -at-

Yes, i am using fp16, additionally i have removed the FBO and the same results occur. So my assumption is still that clamp to edge does not work correctly for floating point textures (at least ones with -ve values)