News | Forum | People | FAQ | Links | Search | Register | Log in
Optimal Lighting And Brightness / Darkness Settings In Quake
This has come up a couple of times either as direct questions or regarding specific map releases, and probably warrants a discussion thread to offer a guideline or reference point.

How is Quake supposed to look in terms of brightness / darkness / contrast?

While it wasn't so much a problem in the past, it seems that nowadays, with practically everyone using LCD/flatscreens, it can be tricky to determine how to calibrate them for Quake and in consequence how to light a map in a way that works for everybody.

For example, a map that looks fine on one setup may appear very dark on another; or the opposite.
Obviously a good starting point to base lighting off would be the id maps. Although perhaps they are a bit too well lit in places. Also, with all the new options that modern light compilers provide, additional consideration is necessary.

I think in most of recent cases where a map looked overly or too dark for me, the reason was their use of colored lighting. Colored lighting is pretty much always darker than regular (white) lights, and it strongly depends on the color tone used. I find that maps that make heavy use of colored lights to light entire areas, quite often suffer from it as a consequence, especially if dark tones are used. More often than not the map will look fine if played without the .lit extension; although sometimes this can make them too bright even.

Fog is another factor that influences how a map looks, obviously. It can make dark maps more visible by highlighting the shapes of things in the distance, whereas without the fog the map would be very dark or even unplayable.

Both of these things are relevant since players use different source ports and those without support for .lit or fog may produce vastly different results. 
I Think 
coloured lights should only be used for accents/hotspots. I.E. it's fine to have little red lights dotted around the place, but they shouldn't be the primary source of illumination. 
Don't Fully Agree 
Really depends on the color and the light source. A corridor with a single torch would be ideally all lit in a shade of orange. Making it white with color only at the hotspot (like that garbage light generating program) will look awkward.

Look up Zendar or Sepulcher using r_lightmap 1 and you'll notice that even the "normal" looking areas are actually subtly colored. 
According to sock, pastel colors work well with the Quake textures. Like a warm yellow. Probably because they are closer to white so they don't swallow as much brightness but still tint the area. It's also important to create a certain "hotness" around torches and flames.

While not perfect, I thought the way the flames look in my RJ6 map was fine (on my setup anyway), but when I just checked with r_lightmap 1, there's very little color around them. The contrast seemed right. May not have been the same for others; in case my monitor has a stronger saturation set... 
Coloured Lights 
It highly depends on how they used, like with any other tool at our disposal, there are cases where they make things too dark and others where they don't pose a problem in the slightest.

For example, i don't think that the outside of my jam map 2 map (warm yellow) looks too dark, neither , even thought i mixed white lights with the coloured ones in the coves, my sm176 map.

I think that that the recent issue comes more from what has been written in the header, the TFT monitors and their configurations messing with the looks, and i am highly interested in reading how others approach this, so some people's monitor don't show the maps like crap.

In my case, so far the only thing i have done to prevent lighting issues for other people is map with the brightness to the minimum or a point or two higher, and making the maps slightly brighter than what i would like them to be, under the assumption that it is better to be too bright than too dark. 
The OP should be considered a call to action. CRTs really didn't have this issue when the game came out and the better the flat panel the more profile options and ways this can go wrong.

I map for gamma 1 and often check my maps brightest areas against the start map. The issue is that I LIKE darker spookier maps overall so many of my areas will be darker than the original game. There were maybe 2 people that commented on the map being too dark and one of those people probably didn't even play it. But I want people to enjoy themselves.

Perhaps a survey is in order. Make and model and color profile used and how diff source ports can affect what you are seeing. 
I have the brightness set in Quakespasm almost all the way down; when it's too dark for a certain map I just turn it up, if I remember to.

On my second map (excluding my Retrojam 6 entry), the only one with decent lighting, I calibrated the lighting based on my own default settings, and used colored lighting as accents. An issue I didn't notice until after release was that, in a few areas, I had structures that were meant to appear as if they extended indefinitely upward, as if hanging in the void--but the darkness doesn't fully cut off the tops of these structures if the brightness is tuned much higher than the middle, however. I kind of like that trick and plan to reuse it in the future, so the only way I can see around the high-brightness issue is by raising the ceiling and advising people to tune the brightness down. 
Using "mid brightness" settings is a mistake.

"gamma 1" is not mid brightness. It's the lowest menu setting in both vanilla Quake and Quakespasm.

Play E4M2, E4M4 and E4M7 with gamma 1. That's the darkest that your map should be. And this is not according to my personal tastes; to me, those maps could be less dark without affecting the intended experience. 
to solve that issue with void maps, you can compile using the gate xx command, where xx is the lowest brightness permitted, and that way you'll save time on vis. I suppose that TyrUtils have it too(i use Bjptools_xt). 
Gamma = 1 Is Not Always Gamma = 1 
Well, even if we say "gamma = 1 is the default and thus maps should look decent with that" the problem remains that this is not the only variable at play here. For instance, after switching displays, I find that with the same settings, maps look much darker and with less contrast. In this case tweaking the gamma is only a means to compensate for deficiencies somewhere else in the pipeline.

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.

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. 
How gamma 1 (and contrast 1 if applicable to the engine) looks depends a lot on whether you are fullscreen and how bright your room is.

Not fullscreen, or during the day, it will look dull and too dark.
In the dark and fullscreen, it should look vibrant and good. start.bsp looks to me like Shambler's "how quake should look" screenshot.

This is what I find anyway with my monitor:
It's reasonably correct as far as gamma and sRGB, and looks good with everything, so I know I'm not adjusting the settings specifically for Quake.

Checking your maps under conditions where the base game looks good is a good idea. Check reviews of your monitor and see if it can be adjusted to match sRGB / gamma 2.2 if possible. 
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! 
You Are Welcome 
next topic: what is the correct volume to watch a movie?

There's an industry standard, and it's 7. No joke. 
Wanted To Talk About This For Quite A While 
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.


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.


vanilla Q2 brightness/gamma:
vanilla gamma behavior if upped:
increased intensity:

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. 
I'm Confused 
Everyone keeps talking about 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. 
Lets Make It Happen ? 
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. 
1 post not shown on this page because it was spam
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.