glColor3f clamping to [0;1] with float buffer?


I’m using a float RGB texture with the ATI_texture_float extension applied with a modulate texture env mode which I modulate with the primary color. I set the primary color with glColor3f and I was wondering if the color components are clamped to the [0;1] range when drawing a quad on a float RGB pbuffer (WGL_ATI_pixel_format_float extension) with these settings? Both extension specs are unclear about that and the base OGL specs state the color is clamped when interpolated or written to the frame buffer…

The only difference between pbuffers and the standard framebuffer is that the OpenGL pipeline ends on a different target. I don’t see how other parts of the pipeline could change. So, there is no reason for the glColor command to clamp the values to [0,1] at a sooner stage.

Values would be clamped if you were sending colors as integers (eg glColor3ub) but since you seem to be using glColor3f it should not be a problem.

The primary color is an 8 bit interpolator so you can only send values in the [0,1] range. If you want to use unclamped values, send them through one of the texture coordinate interpolators then in the fragment program, do the texture lookup and multiply it with the value you stored in the free texcoord interpolator.