UI: Player model looks very bright after reset to default values

[kai-li-wop]

After setting all values to default, the player model looks very bright, just like in the original Quake 3. However, r_gamma is set to 1 and ignore hardware gamma is turned off. The problem goes away when I turn it on, but actually it should be off so that you can always adjust the brightness yourself in the game. At least I think it was always off by default. Nevertheless, the model in the menu in the game itself was not so bright, even though r_gamma is set to 1.

[3aTmE]

I can confirm this.

I've got the same behavior when setting all values to default via settings -> defaults. Likewise i was only able to get the Playermodels rendered proper by setting r_ignorehwgamma to 1. Luckily only seems to affect the Playermenu tho. Everything is rendered fine Ingame.

Using WoP 1.6.2 on Windows 10, 64 bit here.

[kai-li-wop]

@mgerhardy: Please can you have a look a this issue. Maybe a default value is set wrong compared to prior WoP 1.6 or 1.5 releases?

[mgerhardy]

which renderer are you using?

[mgerhardy]

And the output of gfxinfo and/or the log file would be nice.

[3aTmE]

And the output of gfxinfo and/or the log file would be nice.

This issue occured using OpenGL1 after resetting all settings to thier default value via settings -> default.

The Models are appearing too bright no matter what when using the OpenGL2 Renderer.

Here is my gfxinfo output after resetting all settings and using the OpenGL1 renderer:

gfx_info_def.txt

[kai-li-wop]

The file reveals "GAMMA: hardware w/ 1 overbright bits". Shouldn't it be "GAMMA: hardware w/ 0 overbright bits"?

[3aTmE]

The file reveals "GAMMA: hardware w/ 1 overbright bits". Shouldn't it be "GAMMA: hardware w/ 0 overbright bits"?

r_overbrightbits is set to 1 by default according to the console. Setting it to 0 fixes the glowing issue tho. r_overbrightbits 0 also looks still bright enough ingame (tested on Trashmap with otherwise default settings on the OpenGL1 renderer).

So maybe setting r_overbrightbits to 0 by default is the quickest solution?

[kai-li-wop]

I think it should be set to zero by default for World of Padman. As far as I remember, it was the case since the standalone release. @mgerhardy: where are those default values set? Via default.cfg or directly in the code?

[kai-li-wop]

@mgerhardy: I could nail the issue down to tr_init.c of the opengl1 renderer, see r_Register. The old SVN code contains here something like:

` r_defaultChangedMarker = ri.Cvar_Get( "r_defaultChangedMarker", "", CVAR_ARCHIVE | CVAR_ROM );

define DEFAULTCHANGE071116 71116

if( r_defaultChangedMarker->integer<DEFAULTCHANGE071116 ) {
    ri.Cvar_Set("r_ignorehwgamma","0");
    ri.Cvar_Set("r_overBrightBits","0");    
    ri.Cvar_Set("r_defaultChangedMarker",va("%d",DEFAULTCHANGE071116));
}`

This is missing in the current code, please check the old SVN code. It makes sure that overbrightbits is set to 0 if ignore hwgamma is also set to 0, when setting values to default. I don't know why this was made in this way, but it is probably also relevant for the opengl2 and vulkan renderers.

[mgerhardy]

with that change I set r_overBrightBits to 0 if r_ignorehwgamma is 0 (each frame) - so it's basically impossible to set r_overBrightBits to 1 if r_ignorehwgamma is not 0. Is that fine? Or should this only be done at startup with the marker cvar hack from the svn?

[kai-li-wop]

I really cannot remember exactly why the cvar hack was done, but I still remember that it was done by Thilo. I think we had problems with a patch back in the days and we could not find another way to disable r_overBrightBits for existing installations with outdated configs in the user folder ... something like that. But in my point of view I don't see a reason for people not to enable r_overBrightBits if they want to. It could help people who cannot see the other players easily ... ok, I know we have the glowing playermodel feature to solve that ... but hey, they could then better the situation with enabling r_overBrightBits a little bit.

Usually r_overBrightBits should be disabled by default and that's why it would be enough simply to set the cvar to 0 as default value. As long as enabling/disabling r_ignorehwgamma does not cause also r_overBrightBits to be enabled achromatically we are safe. I see no reason any more to bundle both in this way.