When a textured 3D object is lit by a very bright diffuse light (let’s say RGB = 50, 50, 50) the object unfortunately doesn’t look white as the final color is computed as :
clamped_to_one(fragment_color) * texel
The correct way to lit a textured object should be :
clamped_to_one( fragment_color * texel).
Is there a way to avoid fragment clamping in order to correctly light a textured object ?
[This message has been edited by Darken (edited 11-02-2002).]
[This message has been edited by Darken (edited 11-02-2002).]
Fragment shader Humus? Really? I think you meant ARB_fragment_program, right?
Indeed, ARB_fragment_program, and the floating-point frame buffer formats that go with it, are the solution to many shortcomings of current fixed-point lighting problems.
I also recommend to use a high value for the constant term of the lighting equation, when you use a bright lighting value. That way, light fall-off is slower, but you still don’t get too far into over-bright territory.
Originally posted by jwatte: Indeed, ARB_fragment_program, and the floating-point frame buffer formats that go with it, are the solution to many shortcomings of current fixed-point lighting problems.
Yep, I downloaded the spec of the NV30 and stuff like NV_float_buffer seems interesting Too bad we have to use such an advanced GPU just to overcome a simple pipeline limitation Moreover we’ll need to wait some more years to expect to see such hardware on many PCs :-/
Meanwhile I am using this trick : if the 3D object has a texture, I set the diffuse material color to a dark grey : 0.25, 0.25, 0.25. Then I use GL_ARB_texture_env_combine to compute this equation : color_texel * color_fragment * 4.
I lose some precision but the result looks better than what I expected. Unfortunately I am still limited in the maximum light intensity : one light and a maximum intensity of 4, or, let’s say four lights with an intensity of 1.
Thx for your answers ! I hope to see a GL_ARB_lighting_no_clamp one day
[This message has been edited by Darken (edited 11-02-2002).]
Originally posted by Darken: I set the diffuse material color to a dark grey : 0.25, 0.25, 0.25. Then I use GL_ARB_texture_env_combine to compute this equation : color_texel * color_fragment * 4.
Oh no, the GeForce 1, 2 and 3 seems to store fragment colors components as bytes, so by doing a div by four and mult by four I lose 2 bits of precision ! On large dark surfaces the shading is ugly. Damn ! Is there hardware who provide more precision for fragment colors ? 10 bits per components, or better ? 16 bits ? :-9
The Radeon 9500 and 9700 supports floating point per component, with no clamping. I think the Wildcat VP does, too. The next nVIDIA card will, too, except you can’t buy it yet.
Meanwhile, the 9500 pro LISTS at $199; should be cheaper on the street. Interesting times indeed!
Originally posted by jwatte: The Radeon 9500 and 9700 supports floating point per component, with no clamping. I think the Wildcat VP does, too. The next nVIDIA card will, too, except you can’t buy it yet.
Sorry for making this old topic alive
Well, actually I’ve read some stuff about the Radeon 9700 and the NV30 lately. And you right ! It’s even a bit overkill : 24 bits for each color components ! Yahaa, I’m so happyyy
Well unfortunately the Radeon 9700 is the most expensive 3D card I’ve seen (well, for general consumers ;-)), but I hope the price of this generation of 3D card should decrease :o) (and it should !)
The Radeon 9500 seams like an obvious buy for anyone who don’t like spending $400 on video cards. $190 for the plain 9500 and $210 for 9500pro. They are even listed for those prices here in the normally quite expensive Sweden.
Too bad we have to use such an advanced GPU just to overcome a simple pipeline limitation 
Moreover we’ll need to wait some more years to expect to see such hardware on many PCs :-/
I hope to see a GL_ARB_lighting_no_clamp one day 