Negative Value in Texture using GL_SHORT

There are some ambiguities in your post that should be cleared up. First, a GL_SHORT type can hold negative values. It is not restricted to positive values. However, when converting an integer color value to a color of type GLclamp (the normal [0, 1] range for low dynamic range color), it maps integer 0 to 0.0, and the maximum possible integer value to 1.0. So a GL_SHORT can only represent low dynamic range coor values in the range [0, 32k]. It can store negative values, but they are all mapped to color value 0.

So don't confuse clamped color values and GL_SHORT and its ability to store negative values.

The key here is to store color values in a format that is not clamped. I am not sure at the moment, but I think it is enought o change the internal format to either an integer format or a floating point format. For example, the internal format GL_RGBA32F should make a non-clamped RGBA floating point texture, or GL_RGBA16I for a 16-bit signed integer texture.

To Brother Bob,

Thanks for clarification. It is very helpful.

For GL_SHORT, although it can store negative value, if these values are clamped, it will become meaningless, right? I just wonder whether there are some reasons for GL_SHORT's existence, or we can just leave it there for future support.

GL_RGBA32F may cost too much memory for me. I try GL_RGB16I, but it output nothing. Is there something wrong about my usage. I use like this:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB16I, _dim[0], _dim[1], 0, GL_RGB, GL_SHORT, _vel);

Again, Thanks

The values are clamped if they are converted to a clamped color format. So you have to go a route that doesn't clamp the color values. The existance of GL_SHORT is simply so that you can pass 16-bit signed values to various functions.

If you use an integer format or a floating point format, you have to treat the values as such as well. For example, if you write a floating point color value as the output fom the fragment shader, it will be clamped to [0, 1], and an integer format may have to be normalized to the [0, 1] range (divide by 2[sup]15[/sup]) since they are read as integers and not clamped low dynamic range color values in a shader.

Thanks very much. I think I get the idea.