Anyone knows how ‘overlighting’ is done in Q3?

As I see it, it is nececary to draw the triangle multiple times to achieve this effect, since we only can ‘darken’ things. Whether using lightmaps or gl-lights the problem is the same. Q1 and Q2 suffered from this problem.

It really should be possible to set a scale value to a texture (the lightmap). So its values eg. would range from 0 to 2, rather than 0 to 1.

And it should be possible to remove the clamping of the gl-lighting processing.

The problem is that the frame buffer only
goes to 1.0 (well, 255) – you can’t
physically rasterize to memory a value
greater than that, and then later scale it
down’ it’ll be clipped and scaled from 255.

There are some ways to acheve a similar
effect. One is to choose, say, 200 for the
“max brightness” (make that 0.8) and render
with that in mind, which will give you room
for some overshoot. People will have to turn
up their contrast :slight_smile: Another is to use the
accumulation buffer, but that’s usually
really slow. Another is to fake it with
extensions such as GL_ADD mode, which lets
you add values into the frame buffer, or
using alpha bending with an all-white texture
to make things wash towards white.

If you code a Q3Viewer the problem lies within the lightmaps…Just overbright the lightmaps(and the textures if it still looks too dark) manually before passing them to OpenGl…I had exactly the same problem with my Q3Clone…But I can´t remember if I overbrighted the lightmaps only or the textures and the lightmaps…


[This message has been edited by XBCT (edited 01-01-2001).]

The EXT_texture_env_combine, NV_texture_env_combine4, and NV_register_combiners extensions all provide a scale factor that you can apply in the texture environment. All three support 2x and 4x scale factors (register combiners also supports a 0.5x). So you can brighten things using that.

Be warned that brightening techniques like this will cost you color precision, and there are saturation problems – scaling (0.5,0.7,1.0) by 2x will give you (1,1,1).

  • Matt

You can also do additive (instead of multiplicative) blending – either in the combiners or in the frame buffer blend unit. This has the effect of only making things brighter.

Thank you for your comments!

I tried to scale the palette up somewhat, which ‘works’, but the colors suffered too much, so this does not work.

Overbrighting the lightmaps will not give this ‘overbrighting’ effect as in Q3, but will look like Q1/Q2.

Ok thanks this will work, if the extension is present. I tried to disable extensions in Q3 but the effect is still there. I guess they drawed the overbright triangles twice… It is annoying that the lighting walues are clamped before it is combined with the texture. Is there a way to do overbrightning with lightsources? (not using lightmaps)

Doing it the additive way, will make it look foggy. It must be multiplicative to control the contrast.

>Overbrighting the lightmaps will not give this ‘overbrighting’ effect as in Q3, but will look like Q1/Q2.<

Then your overbrighting code is wrong…
My own Q3Clone and Titan look exactly like Q3 with this method and I think using OpenGlExtensions or rnedering things twice too compensate for lightmaps extures which are not bright enough is a “very wrong” thing to do…
I can look into my code again if you´re interested but I´m pretty sure that I didn´t use any special blending modes\other stuff to achieve the overbrighting…

Greets, XBTC!

P.s.:If you have Q3 it would be very cool if you could mail me the ui-dll ´cause I unforunately deleted it…

[This message has been edited by XBCT (edited 01-02-2001).]

Why not do it the right way? This was pulled off of www.pseudonymz.demon.co.uk/gamma.txt
Thanks goes out to Nate for pointing me to this site

It has been noted that QuakeIII ramps the gamma values so that (0.5 0.5 0.5) is full bright and everything above is overbright.

That info can be found — http://www.gamers.org/dEngine/quake3/bwh_gdc99.txt
(see the section titled Overbrightening)
This doc even lists the Get/SetDeviceGammaRamp functions as the source of this effect.

On Windows the gamma ramp for cards with 2d / 3d hardware can
in general be set using the Win32 functions SetDeviceGammaRamp
and GetDeviceGammaRamp.

Some 3dfx cards, however, do not support these functions. As of
December 1999, this category includes Voodoo 1, 2 and Rush. The
current drivers for these cards export the WGL_3DFX_gamma_control
extension; see the documents section of the site for more details.

This code can be used to set gamma values using SetDeviceGammaRamp
or wglSetDeviceGammaRamp3DFX:

(Thanks to Pete Sebor for the original code for this. Any mistakes
in this version are mine.)

Gamma is a floating point number in the range (e.g.) 0.0f to 2.0f.

pEntry is a WORD* pointer to one of the component gamma arrays
(red, green or blue)

for (dcSint32 idx=0; idx<256; idx++)
*pEntry = min(65535, max(0, pow((idx+1) / 256.0, Gamma) * 65535 + 0.5));


[This message has been edited by BwB (edited 01-02-2001).]

Sorry…I knew I forgot something…
I implemented a overbrighted gamma-ramp half an year ago in my viewer…Yup that´s the way to go…

Greets, XBTC!

Ok very nice hack, but rather dirty too. It would be better using a true GL feature.

Does anyone know how to overbrighting using ordinary gl-lights? (they get clamped before combined with the texture)

>Ok very nice hack, but rather dirty too.<

Hey even Q3 does it this way…
And I don´t consider it a hack.
Read the second link BwB gave you carefully…
I think the reason why to do it this way is pointed out very good here…It´s no hack but a clever solution…

Greets, XBTC!

[This message has been edited by XBCT (edited 01-03-2001).]