Hi Werner and Robert
Thanks for the answers.
Clamping to 0.0 to 1.0 range is standard for OpenGL texturing. I
believe this now a new GL extension for a float format that isn't
clamped to the 0.0 to 1.0 range, so have a look on OpenGL .org and
other places online for further info.
In ARB_texture_float
(http://www.opengl.org/registry/specs/ARB/texture_float.txt) the
overview says:
"Floating-point components are clamped to the limits of the range
representable by their format."
And issue 7:
"Are floating-point values clamped for the fixed-function GL?
[...] For the programmable pipelines, no clamping occurs."
If it has been changed, I understand from the revision log that
user-controlled clamping was added in 2004, but only for fragment
operations (which I don't care because I'm reading the texture, not
writing to it). The only transformation should be for fixed point
formats (like the typical GL_RGBA, not integer texture formats) that are
normalized to [0..1].
As I understand, the current osg::Texture class is already aware of the
differences between fixed point, integer and float formats. However, I
have found neither code inside Texture.cpp nor specific wording in the
spec for user control of color component clamping/normalization during
texturing. It seems that there isn't such a thing and the GL
implementation just chooses the correct behaviour depending on the
texture format.
GL_R32F comes from ARB_texture_rg for GL 2.1 and it's in GL 3.0 core.
I've used these and GL_RG32F formats before as target formats for FBOs,
and by default the results are written and read by the shaders without
clamping as expected.
My best guess is that the driver is clamping GL_R32F when glTexImage1D
is called, hence I'd dare to say it's a driver bug. That osg::Texture
doesn't compute the correct InternalFormatType for these relatively new
formats is inconsistent but should be harmless.
By the way, I'm using the NVIDIA linux driver version 256.44 with a 2.0
context in case someone is curious enough to try other setups.
Nevertheless, I've realized my problem is easily solved using
GL_LUMINANCE32F_ARB instead of the more bizarre GL_R32F.
Regards,
Juan
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
