Implement partial overbright clamping like Q3

[slipher]

Fixes #1542. Adds r_overbrightBits which works similar to the one in Quake 3. With the default value of 1, there is one "clamped" bit and one "unclamped" bit of overbright. With map overbright bits = 2 and tr.overbrightBits = 1, A lightmap value of x is treated like min(x * 4, 2) except that if some color channel exceeded 2, all the channels are scaled down together.

Comparison of map mxl-school viewpos 1983 -838 353 130 24:

r_overbrightBits 0 (like old Q3 in non-fullscreen mode, Tremfusion, most versions of Unvanquished until recently): A sickly light. Needs more brightness.

r_overbrightBits 2 (like Unvanquished 0.55+): Too much! Now it's saturated.

r_overbrightBits 1 (like full-screen Windows 9x Q3, ioq3 with GL2 renderer, Tremulous 1.1.0): Just right.

Here's a screenshot with ioq3's GL1 renderer for comparison. Also I verified that setting r_overbrightBits to 0 or 2 has a similar effect in ioq3's renderers and this PR.

Draft PR because:

• Still need to update the code comments explaining this stuff.
• We need to decide if a replacement for overbrightClamping in the worldspawn is needed. For now I deleted r_overbrightDefaultClamp/overbrightClamping since you can do the same clamping by setting r_overbrightBits 0, but that doesn't offer a way for a map to force it.

[illwieckz]

Thanks a lot!

[VReaperV]

• We need to decide if a replacement for overbrightClamping in the worldspawn is needed. For now I deleted r_overbrightDefaultClamp/overbrightClamping since you can do the same clamping by setting r_overbrightBits 0, but that doesn't offer a way for a map to force it.

Some servers use this in multiple maps.

[illwieckz]

We see some window in background are still a bit brighter on this branch.

Maybe we have to re-introduce IDENTITY_LIGHTING. It was removed because with the original default values of Dæmon, there was no difference with IDENTITY (it ended up doing the same), but now we know those default values were wrong.

If I understand it correctly, surfaces with IDENTITY_LIGHTING are not overbright but I may be wrong.

[slipher]

I tried putting in 0.5 for CGEN_IDENTITY_LIGHTING and it does look closer, thought still not exactly the same. I'm not sure if it's right to do that though... Remember your first overbright reimplementation and all the workarounds for cancelling issues? I think Q3 also had these problems, since it worked in pretty much the same way with acting on the entire color buffer. But it seems that the solution used there was not heuristics in the renderer, but rather putting responsibility on the shaders for managing the canceling. (Of course you couldn't do that since there were already lots of assets that were made without observing the identity/identityLighting distinction.) So for example if you wanted a fullbright surface, you'd need to use identityLighting to cancel out the overbright. But our current overbright implementation works in a fundamentally different way; there is nothing that needs to be canceled.

[illwieckz]

Yes, that's my first opinion, but I still have doubts. So you coming to the same conclusion is actually a good sign.

[VReaperV]

Do these tiny differences even matter? We're trying to make things look better, not 100% reproduce how they looked 20 years ago.

[illwieckz]

Do these tiny differences even matter? We're trying to make things look better, not 100% reproduce how they looked 20 years ago.

Probably not. Currently this map looks bad with some surfaces (windows, gymnasium floor), it's possible that with those patches it's now “good enough”. On those screenshots the windows look fine even if a bit different. I would like to see a comparison with the gymnasium floor.

[slipher]

I added another cvar r_overbrightQ3 to test how it would look if brightening is applied to the entire color buffer like in Quake 3. In this mode the GLSL light factor is always 1 but CGEN_IDENTITY_LIGHTING becomes meaningful as the inverse of the brightening factor. This changes a lot of stuff so we would never use it for production. Here's the same scene with r_overbrightQ3 1:

The windows discussed above do seem ~correct with that. Though the trees in front of them which are right behind a streetlight look brighter. This may be due to Q3's distinction between two (shockingly poorly named) vertex lighting modes rgbgen vertex and rgbgen vertexExact. The former applies the tr.identityLight cancellation factor while the latter doesn't. The mapper may have mistakenly used vertex, instead of vertexExact which is needed with q3map2-generated vertex lighting. (In Daemon we choose between these things based on whether the vertexes come from a BSP so we don't have that problem.)

Now for the gym... it still looks pretty bad with the default settings of this branch:

But it looks good with r_overbrightQ3 1:

I can't provide an ioq3 comparison since my dummy gamelogic doesn't implement portal entities.

[illwieckz]

Well, that map was a quake3 map so you can load it with ioq3 directly (though, the setviewpos syntax may differ if it exists). But the look you get with r_overbrightQ3 looks like what I expect with Quake 3.

I guess we should not overbright this texture, we may need a special heuristic for this kind.

[slipher]

• We need to decide if a replacement for overbrightClamping in the worldspawn is needed. For now I deleted r_overbrightDefaultClamp/overbrightClamping since you can do the same clamping by setting r_overbrightBits 0, but that doesn't offer a way for a map to force it.

Some servers use this in multiple maps.

Where? I don't find any overbrightClamping in https://users.unvanquished.net/~slipher/map-entity-directory.txt.

This is ready now, except for one part of a comment that I'm considering deleting. @illwieckz Do you still endorse any of the following?

	Using a non-zero value for tr.mapOverBrightBits turns light
	non-linear and makes deluxe mapping buggy though.

	Mappers may port and fix maps by multiplying the lights by 2.5
	and set the mapOverBrightBits key to 0 in map entities lump.

	It will be possible to assume tr.mapOverBrightBits is 0 when
	loading maps compiled with sRGB lightmaps as there is no
	legacy map using sRGB lightmap yet, and then we will be
	able to avoid the need to explicitly set mapOverBrightBits
	to 0 in map entities. It will be required to assume that
	tr.mapOverBrightBits is 0 when loading maps compiled with
	sRGB lightmaps because otherwise the color shift computation
	will break the light computation, not only the deluxe one.

Setting mapOverbrightBits to 0 doesn't seem like good advice as then you can't have any bright areas. And judging by more recent sRGB discussions, it sounded like the lightmap files are still 8 bits ranging 0-1, and you still have to apply overbright factors to use them.

[VReaperV]

Where? I don't find any overbrightClamping in https://users.unvanquished.net/~slipher/map-entity-directory.txt.

Map&Bot Testing does this on frax, and I believe on a few other maps as well.

[VReaperV]

Actually, it might be using mapOverBrightBits.

[illwieckz]

The overbrightClamping key name only exists in Dæmon, it was only added when implementing full bright overbright in case we may want to force the disablement of it. I did not believe this cvar was useful but implementing this cvar made people less afraid of the future. We can drop that.

The key name mapOverBrightBits can be found in engines like ET-XreaL, ET-Legacy, OpenWolf (the one from 2012, not the Qio-based one) and Dæmon. So it's a kind of modern Wolf:ET thing.

We have mapOverBrightBits in our editor documentation since the beginning.

[illwieckz]

Do you still endorse any of the following?

@slipher you can delete all that quote.

[illwieckz]

// TODO is there any reason to set these before a map is loaded?

Actually, this can be moved elsewhere. Se my “bikeshedding” commit in:

• WIP: implement colorspace support (sRGB, etc.) #1543

Currently: 7185768

[slipher]

Thanks for the pointer, I added a commit consolidating those initial lighting parameter values.

[illwieckz]

I am under the impression that buildables look darker.

[slipher]

I am under the impression that buildables look darker.

Assuming the respective default settings of this branch and master, that's true when the light grid has values greater than 2.0. For example on nano, buildables/players are significantly darker (which is a good thing: on master they look as if under bright sunlight in many places, which makes no sense for the setting). In other settings such as plat23 or the Chasm alien base, light grid values are mostly less than 2 and things look the same.

You can get identical results to master by using r_overbrightBits 2, or identical results to master with clamping by r_overbrightBits 0.

[slipher]

Any objections to merging this?

[illwieckz]

None, can you rebase and fix merge conflict?

[slipher]

I think I already rebased this for trivial merge conflicts 3 times, so I will wait until I get an approval to do it again.

[illwieckz]

LGTM.