 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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 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 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.
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... 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).
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", 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: http://www.tftcentral.co.uk/reviews/benq_gw2450hm.htm 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",
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. 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. 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. |
|
|
|
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |