Why r_overbrightbits 1 does not werk on unix?

[a13n]

Why?

[^misantropia^]

Because you need hardware gamma support for it to work. Scan the console for a message about the XF86 Gamma extension.

[a13n]

So XF86 gamma extension being enabled automatically makes the screen overbrightened, or do I have to set gamma value outside of q3?
I'll try digital vibrance though.
Thanks.

[EDIT]
My log said "X86 gamma extension initialized" or something like that.
And digital vibrance did not give me the ideal result.

[a13n]

I think this is what "r_overbrightbits 1" does to the images except ui.
Because "nvidia-setting" command on unix only supports brightness, contrast and gamma, it is impossilbe to set this setting or draw a line exactly like this.
Even if it is possible, it affects all the color on the screen, resulting in funky color.
It should only affect to the textures on geometries, not lightmaps?

original full range(gray scale)

applying tone curve or "r_overbrightbits 1"

resulting image


Below is a survey about r_mapoverbrightbits.

obb0:mobb0:lm1

obb0:mobb1:lm1

obb0:mobb2:lm1

There are no noticeable differences.

obb1:mobb0:lm0

obb1:mobb1:lm0

obb1:mobb2:lm0

There are no noticeable differences.

obb1:mobb0:lm1

obb1:mobb1:lm1

obb1:mobb2:lm1

There are no noticeable differences.

Conclusion:
"r_overbrightbits 1" should work on unix with software side support by shifting a color according to the tone curve as shown above.


I don't still understand how r_mapoverbrightbits affect the textures though.

[a13n]

O.K.
I now found out why overbrightbits allows greater color range at the expense of loss of a precision.
Below is a simplified example.
base texture with obb0


base texture with obb1


Apparently obb0 has greater color range which is contrary to the fact above.

Next, let's cast a shadow as shown below onto these base textures.


obb0 with shadw blended


obb1 with shadw blended


Now obb1 has greater color range, doesn't it?
So strictly speaking, shader manual should dictate like this.
overbrightbits allows greater color range with lightmap blending, and smaller color range by itself

[obsidian]

Your example above is flawed. You are filtering a gradient with another gradient and expecting the same results. Try filtering the two gradient textures with a flat 50% gray shadow and you will see that you in fact get the same range of colour, although scaled differently.

overbrightbits is virtual, it doesn't actually increase the range of colours produced, but simulates it. AFAIK, the only way of actually increasing colour range is with HDR, where you actually store colour information in a format that is greater than 8bits/channel (ie floating point).

[a13n]

@obsidian
I checked the renderer code and only to find that there were some color shift codes there.
I don't understand what they do at the moment but if they are simply shiffing colors, it should be possible to shift them outside of q3.exe in advacne, resulting in a faster rendering with better image quality.
Below is my experiment.

obb1:mobb2 (target image)


obb0:mobb2


pre-shifted textures by adjusting tone curve


Now baking a map with preshifted textures

preshift obb0:mobb2
Way2bright


preshift obb0:mobb1
Almost identical to the target image but not exactly and "clangdark" textures look darker overall.
Dark texture like this should need to be overbrightened one more time?


preshift obb0:mobb0
too dark


Now I decided to preshift lightmap, too

preshift + lm obb0:mobb2
This makes no sense.


preshift + lm obb0:mobb1
Still brighter.


preshift + lm obb0:mobb0
best result?
Center of green and cyan light source area are whiltened out, which seems to be the limitation of external shifting?


Conclusion:
By preshifting textures and lightmaps it seems to possible to emulate obb1 with obb0+mobb0 but it cannot be exact.

[EDIT]
I also pre-shifted lightmap one more time again.(in:255->out:64)
With obb0&mobb0, these lightmaps look really close to the one with obb1&mobb2 but again some highlight areas looked whitened out.

[a13n]

Now I come to guess, as its name indicates X-Window system always stays window mode even if it looks like fullscreen, right? :icon32:
So q3.exe always detect it as window mode and disable overbrightbits?

[^misantropia^]

So q3.exe always detect it as window mode and disable overbrightbits?

No. X doesn't (normally) allow direct access to the hardware gamma settings[1], thus Q3A disables overbrightbits.
[1] When Q3A crashes on Win32 and the desktop looks all washed out? That's hardware gamma.

[^misantropia^]

I should point out that X does have an extension that allows applications to get and set the overall hardware gamma. It does not however have anything resembling the Win32 SetDeviceGammaRamp function, which enables one to set the hardware gamma ramp.

[a13n]

@^misantropia^
Thank you for your information.
Yes, I'm often forced to see the washed out desktop when running q3 and radiant at the same time.
At last I see the problem lies in X.

By the way do you think my pre-shift approach work?
What's the difference between gammaramp shift and my manual shift?

[obsidian]

Same end result, but shifting the gamma lets the user determine how much. Doing a manual shift will very likely annoy people since you are forcing them to use your settings which may not be suitable for other people's monitors. In other words, don't do it.

You can however scale lightmap gamma quite well and produces some pretty good results using -gamma and -compensate.

[a13n]

Same end result, but shifting the gamma lets the user determine how much. Doing a manual shift will very likely annoy people since you are forcing them to use your settings which may not be suitable for other people's monitors. In other words, don't do it.

But with mod, isn't it possible to do so by defaulting to custom brightbits?
As a result it is possible to achieve faster rendering while keeping obb1:mobb2-like effects!
Anyway I now get it that q3 does not treat full color texutures as it is but as a gay internally.

You can however scale lightmap gamma quite well and produces some pretty good results using -gamma and -compensate.

IIRC, isn't it for the purpose of emulating an obb0-like lighting in an obb1 environment?
I need to survey what on hell the switch -compenstate does though.

[a13n]

O.K.
Finally I got the whole concept.
1stly,
Overbrightbits allows greater color range, strictly speaking, higher contrast, at the expense of loss of precision.


2ndly, to get the same result with windows fullscreen(obb1:mobb2),
Just as pre-shifted textures, lightmap should also be pre-shifted by the same amount(Overbrightbits for lightmap = mobb - obb), except it should be normalized based on the highest value of RGB to keep the relative range of each RGB, resulting in a colorful lightmap rather than pure white.
AFAIK it is impossible to achieve this kind of color shifting in gfx apps such as photoshop, q3map2 needs to support this shifting style and it shouldn't be so diffcult.

With all these preparation, obb0:mobb0 can be identical to obb1:mobb2 while keeping the benefit of obb0, say, faster rendering.

So mappers can release his map for linux seperately using full custom textures and customized compiler.

[a13n]

3rdly, what comes to my mind is the question why quake3.exe shift colors in real time?
If she shifts colors at different phase, such as map loading time, she does not have to do so necessarily in real time, doesn't she?
Or does this lead to much more amount of memory usage and longer loading time which did not meet the hardware requirements when q3 was initially released?
Faster rendering vs memory usage, and memory usage wins? .