Proposal for overbright cvars

[slipher]

I suggest (1) to change the overbright cvar semantics to facilitate testing, and (2) to retain overbright clamping behavior on by default. I don't expect (1) to be controversial, but we may endlessly argue (2) as it is a matter of taste.

1. Change cvars so that all overbright settings can easily be tested.

The current overbright-related cvars have a wonky asymmetric design that can make it impossible to test a setting without editing the map. We should fix that. Something like r_overbrightDefaultExponent (0-3) and r_overbrightDefaultClamp (on/off) to control the default settings when the map doesn't say anything, and one more cvar r_overbrightIgnoreMapSettings to make those cvar values override the worldspawn values even if present. In the worldspawn entity mapOverBrightBits can stay as is, but forceLegacyOverBrightClamping should drop the "force" (since it is no longer a one-way switch) and rename to just overbrightClamping or something.

2. Set overbright clamping on by default.

If nothing else we should be true to the intentions of the authors of our own official maps, who were definitely targeting a renderer with clamping. For older maps, the .ent file may be used in restoration efforts if non-default settings look better. See the discussion below for more arguments on this topic.

IRC discussion

<perturbed>	yeah well atcshd will be the only map which looks good with the new overbright capability :D
<Sweet>	it is unclear if the shall make the new overbright settings the default
<Sweet>	i argued against that
<Sweet>	reason: new maps can easily enable the new settings
<Sweet>	old maps are about 250, and cannot
<Sweet>	if * we* ahall
<Sweet>	jfc
<Sweet>	if *we* shall
<perturbed>	currently it's on by default
<Sweet>	that is not a final thing
<perturbed>	i think maybe 60-70% of maps look preferable with the overbright on
<Sweet>	focus on the open source maps
<perturbed>	i guess illwieckz thinks it is 90% lol
<Sweet>	he does
<Sweet>	but people are tweaking the lighting all the time
<Sweet>	even right now, probably
<Sweet>	we should be conservative with big lighting changes
<Sweet>	at least in the default settings
<Sweet>	for the hundreds of old maps without license and source: who has seen them all
<Sweet>	i certainly have not
<perturbed>	right
<perturbed>	good news is the .ent file can be used to tweak it, regardless of which way becomes the default
<Sweet>	the overbright thing is actually 6 different settings, afaik
<Sweet>	you can switch it on/off
<Sweet>	and then you can set the exponent to 0,1,2
<Sweet>	yes we can fix this for every map
<Sweet>	probably in a legal way
<perturbed>	3 is also allowed apparently
<Sweet>	i am still not sure if the exponent does something if the overbright is off
<Sweet>	i once started to believe it does
<Sweet>	ofc, one gets lost easily
<perturbed>	yes it does
<Sweet>	so we have 8 settings
<Sweet>	this is very good news
<perturbed>	but if the exponent is 0, it does not matter whether there is clamping, so that gives you 7
<Sweet>	given 300 maps, we have 300^7 settings
<Sweet>	that is about 10^17
<perturbed>	it seems we don't have any maps that set a custom exponent
<perturbed>	no hits on overbright on https://users.unvanquished.net/~slipher/map-entity-directory.txt
<Sweet>	we have no map that sets the overbright setting either
<Sweet>	this is a serious problem
<Sweet>	one that i am not able to resolve
<dretch>	<_xreaperx_> > given 300 maps, we have 300^7 settings
<dretch>	<_xreaperx_> We can probably do it automatically
<Sweet>	so i propose to set the legacy setting as default
<Sweet>	at least for now
<Sweet>	> We can probably do it automatically
<Sweet>	how
<dretch>	<_xreaperx_> Either based on lightmaps and shaders used on a given map or taking some average brightness around the map
<Sweet>	oh that would be awesome
<dretch>	<_xreaperx_> I have a branch that takes average brightness of the screen (before any UI and such), and that part can probably be combined with something similar to reflection cubemaps, that render the map in 6 cardinal directions at a bunch of points across the map
<Sweet>	as always, the devil is concerned with details
<perturbed>	ok, let's suppose you have the average brightness, then what?
<Sweet>	we would have to visit, say, 20 random places
<Sweet>	and then look at the brightness
<perturbed>	i don't get how that indicates whether overbright clamp shoudl be used
<Sweet>	it does not lol
<Sweet>	it might help us to select 2 or 3 of the 7 possible settings
<Sweet>	in the end, we can only judge by ourselves
<Sweet>	let me start
<dretch>	<_xreaperx_> > i don't get how that indicates whether overbright clamp shoudl be used
<dretch>	<_xreaperx_> Can be used to choose settings that would avoid having places that are e. g. too bright
<dretch>	<_xreaperx_> Well, would probably need something more like a histogram for that rather than just an average
<dretch>	<sweet235> this is map frax, before and after manual overbright settings
<dretch>	<sweet235> https://cdn.discordapp.com/attachments/353835068139241483/1276966194691313746/unvanquished_2024-08-24_200613_000.jpg?ex=66cb72f1&is=66ca2171&hm=adf6d157fad5a74c22594c0d8d539d5413f8f66c728c723704fc0e7af6c68cb3&
<dretch>	<sweet235> https://cdn.discordapp.com/attachments/353835068139241483/1276966194997624926/unvanquished_2024-08-24_200714_000.jpg?ex=66cb72f1&is=66ca2171&hm=de7bc1ac68d37974d31950417dbce6be34796f154e4abe10d7462ce194244ef9&
<Sweet>	it is a notoriously dark map
<Sweet>	this is what made be buy into the overbright thing
<Sweet>	but i think current atcshd looks better with the legacy settings
<Sweet>	and i think this is true for for than 50% of all maps
<Sweet>	but how do i even show you screenshots
<Sweet>	i would have to upload 7 screenshots for each screenshot i choose to take
<perturbed>	why bother with trying exponent other than 2
<perturbed>	no one was ever designing against that, unless maybe the map was ported from a different game
<perturbed>	the real wildcard is r_gamma, you never know which one they were designing for :D
<Sweet>	if a map was targeting r_gamma >= 5, we have good chances with an exponent of 3
<Sweet>	>= 1.5
<Sweet>	somewhat unrelated: i belive we should edit maps if we find that neccessary
<Sweet>	atcs(hd) wins over plat32 because of its geometry
<Sweet>	> why bother with trying exponent other than 2
<Sweet>	in fact, the screenshot of map frax used 3 as exponent
<Sweet>	let us conduct a survey
<Sweet>	i propose setting the legacy overbright thing as default
<Sweet>	that is: r_forcelegacyoverbrightclamping 0; r_mapoverbrightbits 2
<Sweet>	what do you think?
<Sweet>	(if someone can make it automatic, go for it)
<Sweet>	r_forcelegacyoverbrightclamping 1; r_mapoverbrightbits 2
<Sweet>	^ this
<Sweet>	my reason is simple: currently, all mappers are targeting these settings
<Sweet>	we cannot expect each mapper to use our up to date development branches
<perturbed>	keeping the old default makes sense to me
<perturbed>	the cvar and worldspawn stuff would need to be rejiggered a bit beyond just changing the default value since they work in an asymmetric way
<perturbed>	like clamping is decided by ORing the cvar and worldspawn values
<Sweet>	oh
<Sweet>	so that is the reason
<Sweet>	that is clearly a bad idea
<perturbed>	alternate design proposal: r_defaultOverbrightExponent + r_defaultOverbrightClamping + r_ignoreWorldspawnOverbrightConfig
<perturbed>	so you can test any combination despite what the worldspawn says
<cu-kai>	many maps do look better with r_forceLegacy... enabled, and i mostly play with these settings enabled too.
<cu-kai>	we need a way for the map to tell the client not to use that cvar
<cu-kai>	as has been previously proposed/discussed here
<Sweet>	> alternate design proposal: r_defaultOverbrightExponent + r_defaultOverbrightClamping + r_ignoreWorldspawnOverbrightConfig
<Sweet>	either this
<Sweet>	or hijack some unused value to mean "use the worldspawn settings"
<Sweet>	could use -1
<Sweet>	> many maps do look better with r_forceLegacy... enabled
<Sweet>	i guess the public opinion tends to use the old settings as default
<Sweet>	using

[DolceTriade]

I think both proposals are sensible.

[VReaperV]

This has been fixed by #1364. Clamping wasn't enabled there by default, but the commit claims that it fixes this issue, so..