Jump to content
The Dark Mod Forums
duzenko

Gamma correction, re-revisited

Gamma poll  

9 members have voted

  1. 1. Is the 'dark' picture in post 4 too dark?

    • Yes
      5
    • No
      4
  2. 2. Is the 'bright' picture overbleached?

    • Yes
      5
    • No
      4


Recommended Posts

Is everyone happy with the current state of rendered picture frames?

There is an option to do our rendering in sRGB color space but it will probably lead to revisiting and tweaking default light intensity.

Anyone interested in some RnD?

It might even deprecate the need in ambient shader brightness override, global gamma ramp adjustment, bloom. Maybe reduce color banding and even get close to HDR.

On the other hands it's likely to shift light gradients in or out, and lead to light texture tweaking.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

That is a good question, I'm personally happy with the way TDM (and idtech 4 ) renders picture frames, i must say that the reason I still return to mess with idtech 4 after trying Unity, Esenthel and Unreal 4, not really in that order, is just that to me, its images look so clean and well constructed, compared with other engines (specially those based on deferred rendering) that make the render look slightly blurry and over bloomed/bright, but i'm not personally against trying any other color space and I would be happy to help in any way I can, even tho my time is limited. 

Share this post


Link to post
Share on other sites

As long as it doesn't change anything in how materials look, sure. Wouldn't go too far with HDR efforts though, such displays are still not a mainstream thing. IMO it would be great to do away with light textures for intensity at some point, switching to math formulas (locking the light resize box), and leaving texture slots only for projections.

  • Like 1

Share this post


Link to post
Share on other sites

Played some with this

It seems like a good replacement for shader-level ambient crutch-up like I did way before with r_ambientMinLevel

Untitled2.jpg

Untitled.jpg

Q: How is it better than r_gamma?

A: It only affects the 3D world. Other system windows, 2D and GUI remain un-bleached

Q: How is it better than r_ambientMinLevel?

A: The latter cvar only applies to ambient lights (and arguably makes small ambient lights ugly). This alternative works with all lights, and accurately does additive blending on them. We should probably drop r_ambientMinLevel completely as it's a worse option and clutters the shader code.

Q: What about color banding in shadows?

A: Regret it's still there, and it might be the only deterioration compared to r_ambientMinLevel. On the other hand we can now use extended range framebuffer formats (e.g. 10 bit per color channel vs. 8 bit) to work around that.

Q: What about non-light materials, such as environment cubemaps, emissives, etc?

A: It probably does not make sense to apply this color correction to them as it would break existing missions. Total assets rebuild is not something anyone wants.

Q: Lightgem?

A: Not affected.

Q: But r_gamma allows me to tweak the correction to the level I'm most comfortable with. Do I have the same options with sRGB?

A: No. The sRGB values are fixed and cannot be adjusted AFAIK.

Q: What is gamma again and why do I need to bother?

A: It's all about your monitor. All monitors produce different picture. You obviously run TDM on an LCD that, theoretically, has nothing to do with CRT's non-linear input/output curves. In the end, it all boils down to your own perception - is the picture too dark or bleached out? (See the attached pictures) Toggling this option should give you some control over that.

  • Like 1

Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

Done more web research and it gets frustrating.

Here's my thoughts at this point.

I take it for granted that everyone today is on digital-interface screens. I mean, there's exactly 256 grades of each color component that your screen can show, with any given backlight intensity. If your screen is cheap, you can get 64 instead of 256 (18-bit panels).

It should mean that any non-default (<>1) value for r_gamma and r_brightness will absolutely result in loss of color precision. Same applies to postprocessing, unless it squashes all low-range pixels to black.

I would like to hear from everybody interested

1. Why are people stuck with non-default gamma/brightness? Is the picture too dark for them? Why is it a bad idea to just give them control over r_lightScale instead  (lightgem excused)?

2. If you want to light up the dark areas without overbrightening what's already well lit, then what about crunching up the main ambient light?

Returning to sRGB feature I was playing with. The gamma compensation works well for me but it's not actually how it was supposed to be used. The idea behind it was, AFAI understand it, to give more precision in low-range (darker shades) which, if done properly would have effectively eliminated color banding. The shocking conclusion (unless I am wrong) is, there's no way to actually display this improved picture to the end-user because your digital screen still can only show the same fixed colors. Similarly, Windows DWM only knows about 8 bits per color in linear space. So even if we get better color range in video memory, we still need 1. a screen that understands more than just linear color space, 2. graphics driver that can communicate to that screen and can translate from OpenGL, and 3. Windows support if we want to see this HDR in a window, rather than exclusive fullscreen.

Back to color banding. Is it an issue? Do people here want to see it fixed?


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

Even tho i'm not using HDMI i'm using DVI so i'm using a digital interface. 

1- I personally don't mess with gamma on games unless the game itself asks me to do that at init.

2- If you are talking to main users (not mission makers) IMO unfortunately the intuitive thing to do for many users, is to bright a game using the monitor/game gamma option, if the team wants to change that, perhaps a hint should be shown at game load saying to use the main ambient light?

3- Color banding doesn't seem to be a problem to me, at least never got distracted by it, but that is me. If I want to see it fixed? If is not hard and doesn't change the game looks to much, imo go for it. 

Share this post


Link to post
Share on other sites

I like it, it perhaps could be used to help optimization? I'm asking cause the outside view of a well lit room would be totally dark (at night) and so many things could be culled out of view (even if the visportal is open and things apparently should be visible to the player), the run time cost of doing the testing for visibility, would needed to be evaluated tho. 

Edited by HMart

Share this post


Link to post
Share on other sites

So the intended effect is for things to change brightness when you turn your head?  Given that so much of the game revolves around being able to identify dark/light areas, I'm not sold on that as a good idea.

Share this post


Link to post
Share on other sites
29 minutes ago, Springheel said:

So the intended effect is for things to change brightness when you turn your head?  Given that so much of the game revolves around being able to identify dark/light areas, I'm not sold on that as a good idea.

I see what you mean. Player remembers how dark a hideout must be to avoid AI and develops a skill to deduce location safety from screen darkness.

I could argue about needing to play with constant monitor brightness and (real life) ambient lighting for that to happen.

About lightgem being the actual indicator.

About game being too dark in general forcing people to crank up gamma that causes color banding and greenish color noise.

About mappers deliberately leaving chain of dark spots so that there's often exactly one dark spot to hide on a route.

But most often there's ambient 'dark' - that's where you hide, and 'light spots' - danger zones. You can easily identify them with any exposure. Anything of ambient brightness is safe.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites
8 minutes ago, duzenko said:

 

About game being too dark in general forcing people to crank up gamma that causes color banding and greenish color noise.

Did the game get darker recently?  I'm unaware of any history of complaints of greenish color noise caused by the game being too dark.

 

8 minutes ago, duzenko said:

But most often there's ambient 'dark' - that's where you hide, and 'light spots' - danger zones. You can easily identify them with any exposure. Anything of ambient brightness is safe.

Ambient brightness isn't necessarily safe.  It depends how bright the mapper chooses to make it.  The ambient brightness of an outdoor, moonlit scene might be significantly different than that of a deep cave.  The difference between being totally invisible and being able to be seen by AI a few feet away can be fairly subtle. 

Share this post


Link to post
Share on other sites
1 hour ago, Springheel said:

So the intended effect is for things to change brightness when you turn your head?  Given that so much of the game revolves around being able to identify dark/light areas, I'm not sold on that as a good idea.

If the effect is subtle (that based in the video seems to be) imo it doesn't effect the identification of dark/light areas, personally I could very well see where was dark and where was not, this is like a person being in a dark spot and his eyes adjust to the darkness and imo that looks cool.

I also think this would not affect gameplay at all, besides making it easier to see in the dark, imo is no different from people bringing gama up but at the same time seems to look better and to me is more realistic.  

Share this post


Link to post
Share on other sites
9 hours ago, Springheel said:

I'm unaware of any history of complaints of greenish color noise caused by the game being too dark.

    On 9/19/2019 at 11:28 PM, Dragofer said:

    There's a pattern of subtle green and red banding that increases in intensity towards the far end of the water.

    On 9/21/2019 at 1:17 PM, Dragofer said:

    My gamma is set to 1.172 and my brightness to 1.016.

Quote

Ambient brightness isn't necessarily safe.  It depends how bright the mapper chooses to make it.  The ambient brightness of an outdoor, moonlit scene might be significantly different than that of a deep cave.  The difference between being totally invisible and being able to be seen by AI a few feet away can be fairly subtle. 

I take you point. Even though the difference in ambient brightness between cage and and moonlit lawn should be pretty straightforward (and even more pronounced with AE on).

Let's have automatic exposure off by default so as not to frustrate players who don't use lightgem to keep track of ambient intensity.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

To be honest, I don't use default gamma and brightness for ages by now. They are OK for players only until they get the first TDM crash, after which they are left with overbrightened desktop until reboot. They are definitely unusable for developers, who frequently switch between TDM and Visual Studio. And most likely they are hardly usable for mappers for the same reason of frequent switches.

In my opinion, postprocessing is a much better option. Simply enable it (r_postprocess 1) and reduce gamma a bit (r_postprocess_sceneGamma 0.65) to make stuff better visible. This does not break the desktop. But since TDM renders everything in 8-bit colors (i.e. no true HDR), color banding is inevitable, as Duzenko said. But to me personally, this is not a problem because I don't crank it high. I wonder why we can't switch menu settings GUI to changing this instead of old-fashioned gamma/brightness. Of course, it requires a postprocessing pass.

As for r_ambientMinLevel and r_ambientGamma, I have mixed feelings. They definitely allow me to see dark places, which is OK for development, but they make lights weaker. I'm afraid overbright lights in overly dark streets is the visual signature of TDM game. Ironically, it is actually the direct consequence of D3 renderer being gamma-incorrect 😀

Share this post


Link to post
Share on other sites

Since gamma 1.2 was set as default long time ago, I'm taking it into account while doing lighting, textures and materials. Postprocess increases contrast and overblows specular highlights. While I am testing it too, the most important thing for me is correct material look without postprocessing.

Share this post


Link to post
Share on other sites
8 hours ago, peter_spy said:

Since gamma 1.2 was set as default long time ago, I'm taking it into account while doing lighting, textures and materials. Postprocess increases contrast and overblows specular highlights. While I am testing it too, the most important thing for me is correct material look without postprocessing.

It is possible to make postprocessing work exactly as the old gamma correction.

In fact, I won't be surprised if it is possible right now with proper values. There are so many variables.

  • Like 1

Share this post


Link to post
Share on other sites
17 hours ago, peter_spy said:

Since gamma 1.2 was set as default long time ago, I'm taking it into account while doing lighting, textures and materials. Postprocess increases contrast and overblows specular highlights. While I am testing it too, the most important thing for me is correct material look without postprocessing.

Yet the training mission (and I think options GUI) explicitly suggest users to set their own gamma/brightness.

But what's more confusing for me personally, is why have non-linear gamma//brightness by default when you can simply adjust ambient light intensity for the same purpose without suffering these terrible side effects.

  • Like 1

Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites

What if we add presets to postprocessing, and apply r_gamma/r_brightness and bloom amount on top of preset?

So, we can have "Null" preset which does nothing. People can use it if they don't like how postprocess looks now. The r_gamma and r_brightness values will be passed to postprocessing.

Also, we can have "JCDenton" preset, which works as it does now. But still, if you have non-default r_gamma and/or r_brightness, then they modify the preset values. So adjusting gamma/brightness still have desired effect.

Over time, someone may probably add other presets...

Share this post


Link to post
Share on other sites
1 hour ago, stgatilov said:

What if we add presets to postprocessing, and apply r_gamma/r_brightness and bloom amount on top of preset?

So, we can have "Null" preset which does nothing. People can use it if they don't like how postprocess looks now. The r_gamma and r_brightness values will be passed to postprocessing.

Also, we can have "JCDenton" preset, which works as it does now. But still, if you have non-default r_gamma and/or r_brightness, then they modify the preset values. So adjusting gamma/brightness still have desired effect.

Over time, someone may probably add other presets...

Like

But I suppose we'll hear voices that will want gamma and JCDenton's PP working at the same time.

Also, we have soft gamma in ambient shader, so we kinda already have this?


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites
4 hours ago, duzenko said:

But I suppose we'll hear voices that will want gamma and JCDenton's PP working at the same time.

I wrote that they can add up. Values of r_gamma and r_brightness influence some parameters of postprocessing, so the visual effect of increasing gamma/brightness would be very similar with JCDenton settings and without.

Share this post


Link to post
Share on other sites
On 10/19/2019 at 2:01 PM, Springheel said:

Did the game get darker recently?  I'm unaware of any history of complaints of greenish color noise caused by the game being too dark.

For me it did. I got a new PC and thought it might be from that, but doubted it. Just did a forum search and found this thread instead. 

Indeed, ever since at least a few months ago, I have to crank the Brightness and Gamma to full values and it still seems pretty dark. TDM is now near-impossible to play in daytime or with lights on in room -- even half-dimmed ones. Actually, just tested now, and I do not feel Brightness/Gamma adjustments are changing anything at all; or if they are, it's incredibly minor.

In years past, I remember the Gamma/Brightness settings were very sensitive... where going from 0.8 to, say, 1.2 on the slider was a drastic difference, IIRC. And you could get much brighter,  I think. Now, it's not sensitive enough and you can't set brightness/gamma high enough.

I'm not sure what changed in TDM, but am hoping to be able to Gamma/Brighten it up more someday.

Also, the "Bloom" setting doesn't seem to work how I'd expect. Lights don't get a typical soft-glow and soft-edge like I'd expect. Instead, bloom mainly just bleaches out white canvas textures and such.

Share this post


Link to post
Share on other sites
54 minutes ago, Darkness_Falls said:

Indeed, ever since at least a few months ago, I have to crank the Brightness and Gamma to full values and it still seems pretty dark. TDM is now near-impossible to play in daytime or with lights on in room -- even half-dimmed ones. Actually, just tested now, and I do not feel Brightness/Gamma adjustments are changing anything at all; or if they are, it's incredibly minor.

This is a bug. They should work as usual. Perhaps you should write in Tech Support subforums.

Quote

Also, the "Bloom" setting doesn't seem to work how I'd expect. Lights don't get a typical soft-glow and soft-edge like I'd expect. Instead, bloom mainly just bleaches out white canvas textures and such.

Bloom is considered one of the HDR effects. I regularly say that having HDR necessarily means having increased precision of the framebuffer (like 16 bits, of 12 bits instead of 8 bits). TDM does not have HDR. That's why any implementation of bloom effect is a tricky balance between blurring light sources and bleaching bright parts of the screen. There is no way around it. Luckily, you can turn bloom off separately from the rest of postprocessing (?)

Share this post


Link to post
Share on other sites

@stgatilov

Do you remember what 2.07 shipped with? Was it soft gamma or ??

It's strange indeed from the description. Maybe some specific color ramp setting in system wide Graphics driver settings?

@Darkness_Falls

Do you want to try 2.08 alpha? It would make sense to post your problem report in the support forum.


Amnesty for Bikerdude!

Share this post


Link to post
Share on other sites
58 minutes ago, duzenko said:

Do you remember what 2.07 shipped with? Was it soft gamma or ??

I'm pretty sure it was monitor gamma settings (through WinAPI). The sliders in the main menu still work this way on SVN.

Which is why I suggested expanding postprocessing in such a way that it would look exactly as OS tables do, so that we could finally drop them.

I don't like the current postprocessing, since it is a huge black box with too many variables affecting the output. It also has a controversial bloom which many people dislike, and it does so many render passes that I won't be surprised if it really affects performance (it is great if these passes are disabled when bloom is off). But we should not drop it simply because we did not implement it... hence the idea of two presets: simple one (only gamma + brightness) and "HDR-lite" one with all the whistles.

Share this post


Link to post
Share on other sites

The original intention for Bloom in TDM was to soften the lighting model to give TDM a visual look that was closer to games with Global Illumination or Light mapping. JC Dentons additions were meant to be combined for this purpose:

1) Maha x's specular mod and light bounce mod add a single GI bounce and alter the way that specular reacts to it. Sometimes this results in overblown speculars but that is handled later

2) Ambient lighting is given more complex attributes to fake more bounce attributes (fresnel, directional sky lighting, etc)

3) Bloom softens all these effects, makes light sources glow, and makes bright speculars glow

4) Desaturation tones down the color distortion from bloom

 

If we have proper GI then these tricks become obsolete. The HL2 style ambientCubicLight could achieve much of this but it's currently an artist intensive process.

Currently, the GLSL shaders do not quite replicate the ambient light caustics and some of the softening has been toned down.

visually, we are still doing better since soft shadows also better mimic GI lighting and have more visual impact than all the tricks in JC Dentons system.

 


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...