[Feature Request] Different gamma/brightness for UI/readables/maps

[Daft Mugi]

Would it be possible to add a setting to adjust the gamma/brightness when a UI page (especially a readable) is on the screen?

Some readables can be quite bright or blinding. Thief (NewDark) has a setting for this:

;; From Thief's cam_ext.cfg

; enabling this option allows the UI (menus, map/objectives, readables) screens to have its own gamma setting
; useful if you get blinded everytime you open the map or read a book
gamma_ui 1.0

The main issue I see with implementing this is that readables within a mission can vary greatly in brightness. One mission that comes to mind is Iris. The newspapers are nearly white, so they can be very bright, but other readables in that mission can be fine. I've attached two screenshots to show the difference given the same gamma/brightness settings. Given that variation within a mission, I'm not sure if this feature could actually be implemented.

Maybe there is a way to have a threshold for brightness. For example, if the threshold is set to 0.7 and a readable is at 0.5, don't reduce its brightness. However, if the readable is at 0.9, reduce its brightness to 0.7. I'm no graphics programmer, so I'm not sure if something like that can be done.

I thought I'd request this feature anyway with the hope that someone with the right knowledge may provide more insight or a solution.

[stgatilov]

Are you asking as a mapper or as a player?

I think the current intent is: mappers draw GUI texture as they want players to see it.
Players see it more or less is it was intended.

[Obsttorte]

I'd say so, too. It is an aesthetical and therefore a mappers choice primary. Although I can see that it can be annoying, especially when playing at night/in a dark room, so I would suggest that you first give this feedback in the respective fms thread. Maybe the mission authors aren't aware of this.

If it turns out that there is no specific intention behind it and that the mission authors don't care, it should in principle be possible to cap the brightness. But I am pretty sure you can do this in either your monitor or your graphics card settings. (Personally I use f.lux which tones down brightness and shifts the color towards a orange/brownish tone at night. That would make the first readable pretty much look like the second one).

[Daft Mugi]

I'm asking as a player.

I imagine that mappers may not intend for their readables to be that bright given certain brightness/gamma settings.

[Daft Mugi]

Here's another example.

The Painter's Wife map given brightness of 0.5 vs 2.0. The game world mostly looks fine even at 2.0 brightness, but the map is washed out, too bright, and blinding. (The blinding part comes from being in a dark room and the monitor's own brightness. By the way, my monitor's brightness is set to 0 and it's still too bright.)

So, it would be of great help to have a way to cap the brightness of the UI within the game settings or a cvar.

EDIT: I've clarified about the 2.0 brightness below in another comment, since folks are getting the wrong impression. Y'all, I don't play with 2.0 brightness. This is to demonstrate a range and variation. The focus is on the comparison between the UI and game world. In this example, the "game world mostly looks fine" means it's still tolerable whereas the map becomes overly bright, harder to read, and loses details. The closer the brightness setting gets to 2.0, the more blinding the UI overlays become. The problem we are trying to solve here is how to get a better balance of brightness and gamma between the game world and the UI overlays, so the player isn't blinded by some overlays no matter their brightness and gamma settings. For example, the player may find that 1.2 brightness for the game world and 0.8 brightness for the UI overlay works well for their setup. I should have made that more clear before, but I didn't foresee that folks would get the impression that I play with 2.0 brightness and that I think its look is absolutely fine.  I do not.

Edited October 26, 2022 by Daft Mugi

[stgatilov]

There is no technical possibility to apply separate gamma, because gamma correction is done on the whole contents of the screen, including all GUI.
Initially @cabalistic tried to do it before GUI, but we soon discovered that underwater overlays are also GUI, and probably something else too, so we decide to simply return the old behavior.

That said, it is probably possible to apply second gamma correction on the GUI itself, but I imagine that would be quite a hack.

[datiswous]

Is it possible to apply a dark semi transparant gui over the gui view on certain gui's? I mean for example the x-ray glasses look darker on the side. Added as a plugin.

[Daft Mugi]

Another idea, and not saying any of the previous are not good. Just throwing this out there. What about something like the following pseudo-code?

if (readable || map || inventory || objectives) // is displayed
  gamma = r_postprocess_gamma_ui
  brightness = r_postprocess_brightness_ui
else
  gamma = r_postprocess_gamma
  brightness = r_postprocess_brightness

So, when a readable, map, objectives, or inventory screen is shown, it changes to the UI gamma/brightness settings. On close, it changes back to the game gamma/brightness settings.

[Obsttorte]

10 hours ago, Daft Mugi said:

The Painter's Wife map given brightness of 0.5 vs 2.0. The game world mostly looks fine even at 2.0 brightness, but the map is washed out, too bright, and blinding. (The blinding part comes from being in a dark room and the monitor's own brightness. By the way, my monitor's brightness is set to 0 and it's still too bright.)

Just for my understanding: Why do you set your monitor brightness to the lowest possible value while on the other hand increasing the in game brightness to such an absurd value? I mean the screenshot looks almost like you are playing a daytime mission.

As I see it, at least from your example, you are simple hitting some technical limitations. The brightness can't be increased indefinetly without encountering issues at some point, as the pixel colors are capped (they don't exceed a specific value). So upon increasing the brightness you hit a point sooner or later where the colors start to wash out and everything turns into white noise. When this happens depends on several aspects and the range in which you can alter the brightness is probably set a bit randomly, but obviously you cannot expect things to work well if you are choosing settings that far from the default. If you consider the game too dark I would suggest that you keep the ingame brightness close to the default value and increase the screen brightness instead, as this may yield better results.

[Xolvix]

I had a similar problem a long time ago back when I was a bit of a gamma/brightness nut (see my older posts). I was obsessed with getting the best level of contrast between shadows and lights, however given it was also adjusting all elements of the interface it was overblowing maps and readables, the background to the inventory screen and even the menu. Some of it was tolerable, but other times it looked like I was staring into the sun.

The solution was to basically give up and remain with the defaults. Not only did the stop my obsessive-compulsiveness but it was better because it made missions look more or less the way that the mapper likely intended it to look.

[Daft Mugi]

8 hours ago, Obsttorte said:

Just for my understanding: Why do you set your monitor brightness to the lowest possible value while on the other hand increasing the in game brightness to such an absurd value? I mean the screenshot looks almost like you are playing a daytime mission.

I should have explained this a bit more. The screenshots show the range of brightness, not my settings. The point was to show that if someone sets the game world brightness to the level that looks good to them, the UI elements may be too bright. Even a value of 1.2 brightness can be too bright for some readables, etc. My current brightness setting is 1.0, which can also be too bright for some readables, etc.

My monitor is too bright for me even with its brightness set to 0. It doesn't look dim or dark at all. The reason I wrote that was to point out that there really aren't more adjustments I can do outside of the game, at least with the monitor. Anyway, talking about my monitor will probably just add confusion to this issue, so let's leave that out from now on.

Edited October 25, 2022 by Daft Mugi

[Daft Mugi]

I'm not the only one who gets blinded sometimes. I've heard streamers comment about the brightness when they open some readables.

For example, "Oh, it's so bright. Ugh, it hurts my eyes." (See YouTube video at 30:52, the link has the start-at timestamp.)

 

[Obsttorte]

Well, in regards to the core assets it is probably worth a consideration to tune down some of the brighter gui backgrounds. (The gui in the video is the same as in your first post, so it is probably a core asset.) This would additionally result in a more consistent look, which isn't the worst thing imho.

But regarding guis specific to certain fms I still think you should address this in the respective mission threads. Personally I never had an issue with this matter (although I can see that it can be one), which leads me to believe that this is heavely depending on factors like the monitor used for example which may could cause mappers not beeing aware of that effect.

Maybe you can list the guis in question so we can see whether they are stock assets or mission specific?! That would be a good starting point.

[Daft Mugi]

22 minutes ago, Obsttorte said:

Maybe you can list the guis in question so we can see whether they are stock assets or mission specific?! That would be a good starting point.

Sure, I've listed three so far:

1. Iris
2. Painter's Wife
3. Written in Stone

[Obsttorte]

@Daft MugiThe guis!

[Daft Mugi]

37 minutes ago, Obsttorte said:

The guis!

How would that help? I'm having trouble understanding your request. I could give you a list of readables and maps, but that doesn't make sense to me.

My understanding is that this is a general problem with UI overlays, such as the inventory, objectives, map, and readable overlays, in all missions. Some map and readable assets could have their brightness reduced, but that doesn't make sense to me, because they usually look fine. It's the game world gamma/brightness that doesn't match or conflicts with the UI overlay. Though, reducing the brightness can help with some readables and maps. Is that how we really want to solve this? Wouldn't code that automatically adjusts the brightness be more effective at solving this for any mission?

Edited October 25, 2022 by Daft Mugi

[stgatilov]

Some time ago @duzenko implemented automatic gamma adjustment depending on what player sees.
The idea was met without enthusiasm.

Maybe it can be applied in this case?
If a considerable part of the screen is overly bright, then automatically lower the gamma.
But never raise it in darkness... since most people agreed it somewhat defeats the whole light/darkness feel.

[Oktokolo]

I totally get the eyehurt of that streamer. But it isn't the brightness of the guis in general. It is the contrast between the environment and the GUI. GUIs have the same brightness regardless whether you look at them in the shadows or in electric light. The result is that the newspapers actually hurts a bit when frobbing one in a dark environment because of the sudden brightness change.

The white default newspaper assets obviously are the worst offenders.
But even the beige parchment readables (and also the objective screen using a similar background) can be way too bright when opened in the shadows while playing in a lowlight environment.

Considering the average value of the screen the user saw before opening the GUI might indeed work. The light gem value could also be a good enough indicator of environment brightness and is already calculated.

[Daft Mugi]

6 hours ago, Obsttorte said:

The guis!

Do "guis" refer to the ".gui" files in the pk4 files?

I'm looking through pk4 files now and just saw ".gui" files for the first time.

[Daft Mugi]

5 hours ago, stgatilov said:

Some time ago @duzenko implemented automatic gamma adjustment depending on what player sees.

That sounds promising.

[Obsttorte]

5 hours ago, Daft Mugi said:

Do "guis" refer to the ".gui" files in the pk4 files?

I'm looking through pk4 files now and just saw ".gui" files for the first time.

That's what I've meant. As far as I see it the problem is the contrast between bright guis opened in an otherwise dark environment, as @Oktokolopointed out already. So the idea would be to make those, like the above newspaper, darker.

11 hours ago, Daft Mugi said:

Wouldn't code that automatically adjusts the brightness be more effective at solving this for any mission?

Yes, and automated version is always preferable. And as @stgatilovsaid it appears that there was something like that been worked on in the past, which I didn't knew. The question is though how reliable it is. Typically such adjustments work gradually over time, but that wouldn't help much here as a bright gui would still be annoying, even if for a shorter amount of time. So the code would have to reduce the brightness immediately.

It has to be tested whether this doesn't create any unwanted side-effects and if we exchanging one annoyance with another. As said, I wasn't aware of the implementation and have therefore never seen it in action, so I can't judge on that.

[wesp5]

9 hours ago, Oktokolo said:

The light gem value could also be a good enough indicator of environment brightness and is already calculated.

That sounds like a promising approach, scale the brightness of the readables in connection with the light gem.

[chakkman]

On 10/24/2022 at 11:08 PM, Daft Mugi said:

Here's another example.

The Painter's Wife map given brightness of 0.5 vs 2.0. The game world mostly looks fine even at 2.0 brightness, but the map is washed out, too bright, and blinding. (The blinding part comes from being in a dark room and the monitor's own brightness. By the way, my monitor's brightness is set to 0 and it's still too bright.)

So, it would be of great help to have a way to cap the brightness of the UI within the game settings or a cvar.

I don't think the game world looks "fine" with a brightness of 2.0. It's way too bright, and, that's also not the way the game is intended to play (at least I don't see a compelling reason to play with such a high brightness. No monitors gamma and brightness is that way off, and, it will rob you of any atmosphere, and realism).

I'd stick with the "way the mapper intended things to look like" paradigm which @stgatilov pointed out, to be honest. Makes the most sense to me.

Edited October 26, 2022 by chakkman

[Obsttorte]

1 hour ago, wesp5 said:

That sounds like a promising approach, scale the brightness of the readables in connection with the light gem.

Not really. You could stand in the darkness but look at something bright in the back or vice versa. It doesn't depend on how well the player is lit, but how bright the scenery is compared to the gui. This however doesn't only depend on the light sources, but also the materials used on the surfaces.

Did anyone ever test the automated gamma adjustment mentioned earlier on?

[Daft Mugi]

8 hours ago, Obsttorte said:

So the idea would be to make those, like the above newspaper, darker.

I agree. I tried this by making newspaper_bridgeport01.dds, newspaper_bridgeport02.dds, and newspaper_bridgeport03.dds darker, and it worked well. The result was better than I originally thought it would be, so thank you for suggesting this.

8 hours ago, Obsttorte said:

Yes, and automated version is always preferable.

As an experiment, I'm working on some code that adds "r_postprocessing_gamma_ui" and "r_postprocessing_brightness_ui" cvars.

When the inventory, objectives, map, or readable overlay is shown, the values of "r_postprocessing_gamma_ui" and "r_postprocessing_brightness_ui" are used instead of "r_postprocessing_gamma" and "r_postprocessing_brightness".

When those overlays are closed, the values of "r_postprocessing_gamma" and "r_postprocessing_brightness" are restored.

The result works quite well and is predictable. I have this working already and need to clean up the code a bit before sharing it. An automatic way to set the gamma/brightness values would probably be better, but I imagine I would somehow need to sample the background texture ahead of time to get some kind of brightness value. That is something I don't know how to do or if it's even reasonable for this. I'm doing what I can. Maybe the code stgatilov mentioned can be used instead.

Overall, a combination of altering the background textures and using the new cvars gives a good result in my testing.