For instance, after switching displays, I find that with the same settings, maps look much darker and with less contrast. [...]

Sadly, posting screenshots on "how things should look" does not help there - as the author of the screenshots is not in control of the display setup on the receiving end.

And this is exactly why gamma 1 should be used when creating maps. Users tends to adjust the gamma based on how the vanilla maps look.

If you created your map using gamma 0.5 in the engine when adjusting the lighting, your map will look twice as darker for the users that uses gamma 1.0, despite only looking a bit darker than the vanilla maps for users using gamma 0.5. The gamma brightness curve is not linear.

If you care about the users, you will adjust the lighting using the default gamma value and let the users adjust the gamma on their end, as they already do. 

What may help may be some kind of a test map that includes, e.g., a wall with a brightness ramp... on one end "this should be black", "this should ever slightly be not black", ... "this should be not quite white" up to "this should be white" - similar to display calibration pictures. Not sure how such a thing can be created.

A bunch of func_walls lined up next to each other sharing the same neutral texture, with the increasing brightness done by making them ignore the map's lights (_lightignore 1 in tyrutils) and increasing _minlight gradually for each wall? Would need a lot of fiddling though, especially at the lower end as the 'this should be black' level (zero light) always shows pure black even if you crank up (lower) the gamma far enough that everything else turns eye-searing, like this (gamma 0.1, walls increasing in minlight by 25 each from left to right, ending at 250).

Would obviously be very rudimentary and not account for the newer features of compilers like bounce lighting and baked in ambient occlusion (dirt), though. 

next topic: what is the correct volume to watch a movie? 

Another guideline I've set for me is: When mapping, try to make the map look good without lighting (aka fullbright). This way, when adding lights, the lighting will be a true improvement to the map's visuals, rather than just a fix.

I find it really odd when a map that looks great with lighting looks bad without lighting.

My reasoning for this is also because vanilla Doom maps have almost no lighting (only sector lights) and still looks good. Mapping for fullbright helps us perceive better some texture choices and geometry decisions. 

I'm with metl on this - there is no "optimal" lighting level. What with different monitor types, different gamma ramps, then you've got everything set up just the way you like it and you go on battery power and the screen darkens, ruining it all on you all over again.

So some degree of tweaking is to be expected, and engines had better expose this tweakability to users. 

Rephrased: How to light a map so it looks suitably fine for everyone?

Of course every player can increase gamma if he comes across a map that's too dark on their screen, or decrease it if it's too bright. But the idea is that maybe it can't hurt to follow some guidelines as a middle way. 

gate xx is perfect, thanks for the tip! 

 

next topic: what is the correct volume to watch a movie?

There's an industry standard, and it's 7. No joke. 

All the textures and model skins in the game were made with gamma 1 in mind, it's the only setting that keeps the original colors intact. Increase it just a bit, and the colors start getting washed out. Increase it some more and you get color burn artifacts, push it even further, and you've got ugly ass hard edges on all shadows.

It's a shit setting and you're better off just tweaking your display's brightness.

However.

Quake 2 faced a similar challenge in how the game was too dark for normal people on a non-CRT monitor in a not pitch black room. But the awesome Yamagi source port fixes this by making the whole scene brighter, so you don't lose any color gradations.

Observe:

vanilla Q2 brightness/gamma:
https://i.imgur.com/1renRlA.png
vanilla gamma behavior if upped:
https://i.imgur.com/zHz5ZgE.jpg
increased intensity:
https://i.imgur.com/mQM51O6.jpg

Technical info about what Yamagi does:

* **gl3_intensity**: Sets the color intensity used for 3D rendering.
Similar to GL1 `intensity`, but more flexible: can be any value between
0.0 (completely dark) and 256.0 (very bright).
Good values are between `1.0` and `2.0`, default is `1.5`.
Applied in realtime via shader, so it does *not* need a `vid_restart`.

* **gl3_intensity_2D**: The same for 2D rendering (HUD, menu, console, videos)

* **gl3_overbrightbits**: Enables overbright bits, brightness scaling of
lightmaps and models. Higher values make shadows less dark.
Similar to GL1's `gl_overbrightbits`, but allows any floating point number.
Default is `1.3`. In the OpenGL3.2 renderer, no lighting fixes for water
are needed, so `1.0` has no special meaning. 

It looks like yquake2's "gl3_intensity" cvar is the same as the "contrast" cvar in MarkV and Quakespasm, it's just a scale factor (multiplier) before applying gamma: reference
Agree it is useful. 

Everyone keeps talking about gamma...is that the "brightness" setting in the options menu? And what is 1? Center of the slider bar? Far left?

If it is I'd like to submit a bug report for having the wrong name. Gamma is not brightness. 

yeah, the "brightness" slider in the options menu controls the "gamma" cvar. "gamma 1" is when the slider is all the way to the left; the darkest setting. 

If it is I'd like to submit a bug report for having the wrong name. Gamma is not brightness.

That's just terminology, but unfortunately it's terminology that dates back to the original software Quake, so it's probably too late to change it now.

Change the menu text from "brightness" to "gamma" and you'll get complaints that there is no longer a gamma option.

Change the cvar name and behaviour and you get complaints from the other perspective.

Accept it as a quirk of Quake and - of course - the name in the menu is all wrong, but given 20 years of legacy it's probably the least invasive option.

Similarly, what certain engines call "contrast" isn't actually contrast at all either. 

Whatabaout a test map/mod to set the lighting right so as to standardise things a bit ?
A la adjust your slider until you barely see X etc but in a purpouse built map with prompts ? 

That’s not such a bad idea 

By the way, the darkest shades of darkness in the software renderer are darker than in the hardware renderers. The software renderer clamps the last non-black level of darkness to full black, and some colors in the palette goes black before others.

I'd highly recommend testing the maps in the Mark V WinQuake engine, as AFAIK it's the software-rendered engine that's most faithful to vanilla Quake while also supporting most extended limits. 

So, lets do it :D

A map with a set of rooms and prompts to help adjust ones settings to something sane and close enough to what everyone else is using

Like "adjust your whatever until you faintly see the zombie on the wall at the end of the room" etc..

This would be the most flexible approach to a "standardization" of brightness/darkness settings. If everyone designs with similar settings.

Seems to the only way that could work across different engines/sourceports etc. 

I'm pretty sure that won't work across different monitors and lighting scenarios as ericw and others have alluded to. Since your monitor could be darker or lighter than mine you will get different results no matter what.

If you use the start map as a reference when you are lighting levels you should be okay. However, don't do what I did last time and rely on screenshots. You need to "eyeball" it "live" in-game. 

This could be used just to get the display in the ballpark. 

If i raise the brightness to the maximum while on a pitch dark room i begin to guess something, but i use a CRT here. Is there so much of a difference with TFT one? 

I don't see any symbol on my S7 screen at max brightness? The dang text hurt my eyes tho. 

I am talking about one standardised map with a half/dozen differently lit / fogged etc rooms - with an indicated / enforced viewpoint of the room (eg teleport player to immobilised space)
There you proceed room by room to adjust your own settings to be able see what the prompts indicate you should be seeing for that particular room (in this room 1 you should adjust brightness/contrast until the ammo box disapears in the shadown but the zombie on the wall remains visible) etc...

If then mappers + players go through this setup we have a standardized setting that should be quite resilient to different engines and monitors.

It would also invalidate some engines that fuck too much with lighting etc.


It should at the very least be an interesting experiment no ? 

I'd be down for this if it was more involved as you describe but not sure you could do different fogs in the same map unless it was a mod like AD.