Jump to content
The Dark Mod Forums

Soft r_gamma


duzenko

Recommended Posts

Ambient would have been brighter for you.

Why so low? Are you trying to add contrast this way? Can you see the ambient at all?

 

I would expect 1 to be the average value, so I don't see .9 as very low. Perhaps it would be useful to find out what other people have set.

 

For me, I want the screen fairly dark in dark areas, but with enough contrast that I can still make things out. Approx .9 brightness and .9 gamma is my usual settings, though I occasionally go to .85 when the room is at its darkest.

 

Can we see some screenshots comparing the traditional gamma to the new one?

Link to comment
Share on other sites

I actually just checked, and my settings are currently Brightness=8.6, Gamma=8.5.

I don't have the 2.06 installation to compare with but if you have one then let's do it.


I do have several installations of different versions, but I don't have the recent soft_gamma changes. If you don't have an earlier build to compare to, how are you establishing the difference between the two systems?

However current gamma < 1 won't behave similarly at all I can tell you that much.


Isn't that a bit of a concern? Any significant change to how the game looks, unless it's an obvious improvement, should be something we try awfully hard to avoid.

Link to comment
Share on other sites

I actually just checked, and my settings are currently Brightness=8.6, Gamma=8.5.

That does not look right

 

I do have several installations of different versions, but I don't have the recent soft_gamma changes. If you don't have an earlier build to compare to, how are you establishing the difference between the two systems?

From the old source code, presume it should look similar because the formula is similar

 

Isn't that a bit of a concern? Any significant change to how the game looks, unless it's an obvious improvement, should be something we try awfully hard to avoid.

I believe the linear formula looks prettier that the exponential one but it's a matter of taste. Then we have a way to have both controlled by a cvar.

Link to comment
Share on other sites

  • 3 weeks later...

I wonder where this discussion ended?

 

It seems that now the ordinary exponential formula is also implemented in ambient shader, so it should look rather similar to the original gamma correction.

However, the new gamma will never affect light sources, it can only affect ambient.

On dark scenes it is probably almost the same, on the bright ones it can differ.

 

Maybe make some way to have both the old and the new gamma correction alongside (with yet another cvar :o --- just don't forget to kill it before release :D), and then ask team members (at least) to test stuff by switching back and forth?

I agree that making gamma correction "correct" instead of just one way to adjust contract/brightness/... is very unlikely to happen ever in TDM, since it depends a lot on the assets.

Maybe the new way is just "good enough" or "better" subjectively, so everyone would screw the old gamma.

Link to comment
Share on other sites

I wonder where this discussion ended?

 

It seems that now the ordinary exponential formula is also implemented in ambient shader, so it should look rather similar to the original gamma correction.

However, the new gamma will never affect light sources, it can only affect ambient.

On dark scenes it is probably almost the same, on the bright ones it can differ.

 

Maybe make some way to have both the old and the new gamma correction alongside (with yet another cvar :o --- just don't forget to kill it before release :D), and then ask team members (at least) to test stuff by switching back and forth?

I agree that making gamma correction "correct" instead of just one way to adjust contract/brightness/... is very unlikely to happen ever in TDM, since it depends a lot on the assets.

Maybe the new way is just "good enough" or "better" subjectively, so everyone would screw the old gamma.

The brighter the light, the less it was affected by the old gamma. So for bright lights little changed.

For dim lights, meh. They might look more diluted in ambient.

Will anyone notice/complain? That's basically the question. So far the unofficial @NB's releases have been met with zero feedback towards gamma, except it was "too dark" in earlier versions. After I defaulted to old gamma for values > 1 nobody has brought it up.

Now there's also the multi-light shader and what it does is processes both ambient and point "regular" lights. The custom-projection lights, post processing surfaces, fog/blend still go unaffected.

Not sure what you meant by old/new gamma. The current svn will use logarithmic formula for gamma > 1 and linear formula for gamma < 1. Or you're talking about restoring the device gamma ramp?

Now there's one last issue with few folks who unexpectedly reported using r_gamma < 1. I guess I'd have to make the linear formula kick in for gamma < 0, extending the cvar range.

Link to comment
Share on other sites

Will anyone notice/complain? That's basically the question. So far the unofficial @NB's releases have been met with zero feedback towards gamma, except it was "too dark" in earlier versions. After I defaulted to old gamma for values > 1 nobody has brought it up.

 

 

Whether anyone will notice is the question, but that can only be answered by having a clear way to compare. Screenshots was my suggestion. A cvar is another way (though more work I presume). Relying on the few people who are testing unofficial releases is probably not a very reliable sample.

  • Like 1
Link to comment
Share on other sites

 

Whether anyone will notice is the question, but that can only be answered by having a clear way to compare. Screenshots was my suggestion. A cvar is another way (though more work I presume). Relying on the few people who are testing unofficial releases is probably not a very reliable sample.

Device gamma ramp won't show on screenshots. It is applied on the video card output stage.
Link to comment
Share on other sites

I have restored the old gamma correction and moved the new gamma correction to two new cvars.

It would be great if some of these cvars die out by 2.07 release, but for testing purposes all the options are available now.

 

The new version is committed in svn rev 15320, only TDM developers have access to it as of now.

If you are TDM developer and the fate of gamma correction is important to you, please spend some time testing all these cvars in the near future.

 

 

So in this new version we have:

 

1) r_gamma and r_brightness work exactly as before.

They are configured when you move sliders in main menu.

They affect the very-very final picture, even affect the main menu itself.

They work via modifying the device gamma ramp, which is i) quite annoying if TDM crashes, and ii) can easily lead to color banding.

The formula is: color -> pow(brightness * color, 1 / gamma);

 

2) r_ambientMinLevel and r_ambientGamma are the new parameters for "soft gamma" discussed here.

They can only be configured by modifying the cvars in console yet (sliders to be discussed).

They affect only the ambient lighting, so they don't work in menu and they don't affect light sources behavior.

They work by applying conversion formula at the end of ambient shader, so they i) don't mess with your Windows settings, and ii) do not exhibit any color banding.

The formula is: color -> pow(minLevel + (1-minLevel) * color, 1 / gamma)

 

The r_ambientMinLevel cvar linearly transforms the colors so that everything which normally receives zero light will have color = minLevel.

The r_ambientGamma cvar has exactly the same mathemetical effect as the old r_gamma (but it affects only ambient lighting).

 

Note that most of these ways are not intended to be used together.

E.g. You should use gamma correction either global (r_gamma) or for ambient only (r_ambientGamma).

You probably should not combine r_ambientMinLevel and r_ambientGamma together.

So it is like: use r_gamma + r_brightness as before, use r_ambientGamma only, or use r_ambientMinLevel only.

But of course you can use several types of adjustment at the same time if you want, they'll combine rather nicely.

 

  • Like 1
Link to comment
Share on other sites

i) quite annoying if TDM crashes, and ii) can easily lead to color banding.

iii) affects all open windows when you run TDM windowed or Alt-tab

 

BTW the multi-light shader applies the correction formula to all "standard" lights, not just ambient.

Link to comment
Share on other sites

Ooh.

 

I am eager to tinker with this.

 

I have long wanted the ability to alter the ambient light level independent of other factors.

 

Now I can get my preferred gamma\bright look AND make missions look better by adjusting the ambient light. :wub:

 

Too bad we probably wont stick with all these options in the future... :unsure:

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...)

Link to comment
Share on other sites

I have restored the old gamma correction and moved the new gamma correction to two new cvars.

It would be great if some of these cvars die out by 2.07 release, but for testing purposes all the options are available now.

 

The new version is committed in svn rev 15320, only TDM developers have access to it as of now.

If you are TDM developer and the fate of gamma correction is important to you, please spend some time testing all these cvars in the near future.

 

 

So in this new version we have:

 

1) r_gamma and r_brightness work exactly as before.

They are configured when you move sliders in main menu.

They affect the very-very final picture, even affect the main menu itself.

They work via modifying the device gamma ramp, which is i) quite annoying if TDM crashes, and ii) can easily lead to color banding.

The formula is: color -> pow(brightness * color, 1 / gamma);

 

2) r_ambientMinLevel and r_ambientGamma are the new parameters for "soft gamma" discussed here.

They can only be configured by modifying the cvars in console yet (sliders to be discussed).

They affect only the ambient lighting, so they don't work in menu and they don't affect light sources behavior.

They work by applying conversion formula at the end of ambient shader, so they i) don't mess with your Windows settings, and ii) do not exhibit any color banding.

The formula is: color -> pow(minLevel + (1-minLevel) * color, 1 / gamma)

 

The r_ambientMinLevel cvar linearly transforms the colors so that everything which normally receives zero light will have color = minLevel.

The r_ambientGamma cvar has exactly the same mathemetical effect as the old r_gamma (but it affects only ambient lighting).

 

Note that most of these ways are not intended to be used together.

E.g. You should use gamma correction either global (r_gamma) or for ambient only (r_ambientGamma).

You probably should not combine r_ambientMinLevel and r_ambientGamma together.

So it is like: use r_gamma + r_brightness as before, use r_ambientGamma only, or use r_ambientMinLevel only.

But of course you can use several types of adjustment at the same time if you want, they'll combine rather nicely.

 

 

 

That was quite thorough but I'm still unclear on how to test this.

 

Currently I have regular brightness and gamma settings set from the main menu.

 

So if I want to test the new gamma, what do I do? If I put r_ambientgamma 1 in the console, does that override my current gamma settings? Or do I have to set r_gamma to zero first?

 

use r_gamma + r_brightness as before, use r_ambientGamma only,

 

 

Is r_ambientgamma meant to replace the menu brightness slider as well?

 

The r_ambientMinLevel cvar linearly transforms the colors so that everything which normally receives zero light will have color = minLevel.

 

 

So this takes a color value, like you would put on a light in DR?

Link to comment
Share on other sites

That was quite thorough but I'm still unclear on how to test this.

Well, me too =)

If you use the old gamma/brightness for something, try to achieve the same with the new ambient settings.

You can also compare the effect of r_gamma to the effect of very similar r_ambientGamma.

 

Currently I have regular brightness and gamma settings set from the main menu.

So if I want to test the new gamma, what do I do? If I put r_ambientgamma 1 in the console, does that override my current gamma settings? Or do I have to set r_gamma to zero first?

The new settings are not attached to any slider. So you'd better modify cvars in console.

Note that each cvar has default value, which efficiently means "no adjustment". It is 1.0 for everything except r_ambientMinLevel, which has the default of 0.0.

As it usually happens with cvars, changing one does not automatically affect any others. You have to reset cvars to defaults yourself.

 

For instance, to compare old (global) and new (ambient) gamma correction, you can switch between two commands:

  r_gamma 1; r_ambientGamma 1.4
  r_gamma 1.4; r_ambientGamma 1

The first one resets old gamma and sets new (soft) gamma, and the second does the opposite.

 

Is r_ambientgamma meant to replace the menu brightness slider as well?

I have no clear idea for myself.

One option is to remove brightness slider and switch the gamma slider from r_gamma to r_ambientGamma.

Another one is to leave gamma/brightness sliders as they are, but add one more slider for whatever of r_ambientGamma and r_ambientMinLevel seems more useful.

 

So r_ambientMinLevel takes a color value, like you would put on a light in DR?

Almost like this, but with two differences:

1) You can only specify grayscale color in range from 0.0 to 1.0. No way to set red/green/blue levels separately.

2) Setting r_ambientMinLevel to 0.2 is not just adding light value 0.2 to everything, but it is rather similar on low values.

Link to comment
Share on other sites

  • 2 months later...

This topic is very convoluted and needs clarification both for devs and players. From player perspective, I would want the following:

  • Traditional global brightness and gamma are a must have. Players know how to handle that. You tweak it such that you get a good general-use image quality, based on the gamma-room in the Training Mission.
  • Having a way to only increase ambient lighting is also nice. When starting to play, I always tweak r_gamma to accomodate for my current living room's lighting situation and the lighting properties of the individual FM, but what I actually want to achieve is just increasing the ambient light.
  • Players don't need full control over ambient gamma, though, I think. The linear adjustment suffices.
  • All methods should not affect brightness/gamma in windows.
  • All methods should not introduce color banding.

The current state is, that there are multiple ways to achieve the same or just a slightly different effect. There is r_gamma / r_brightness, r_postprocess_sceneGamma / r_postprocess_Exposure and finally r_ambientGamma / r_ambientMinLevel. Since not everybody has postprocessing enabled, the gamma correction in the postprocessing stage should probably be removed completely. When doing that, default values for r_gamma and r_brightness should be adjusted accordingly to maintain the look. In their current implementation, r_gamma and r_brightness still suffer from color banding and os brightness change, which would have to be fixed.

  • Like 1
Link to comment
Share on other sites

This topic is very convoluted and needs clarification both for devs and players. From player perspective, I would want the following:

  • Traditional global brightness and gamma are a must have. Players know how to handle that. You tweak it such that you get a good general-use image quality, based on the gamma-room in the Training Mission.
  • Having a way to only increase ambient lighting is also nice. When starting to play, I always tweak r_gamma to accomodate for my current living room's lighting situation and the lighting properties of the individual FM, but what I actually want to achieve is just increasing the ambient light.
  • Players don't need full control over ambient gamma, though, I think. The linear adjustment suffices.
  • All methods should not affect brightness/gamma in windows.
  • All methods should not introduce color banding

It is impossible to NOT suffer from color banding using any global gamma correction.

Because TDM has no real HDR yet: all intermediate colors are stored in 8-bit values.

The main reason why Duzenko did the correction for ambient light only is that inside a single shader you can avoid color banding since intermediate values are 32-bit floats.

 

The current state is, that there are multiple ways to achieve the same or just a slightly different effect. There is r_gamma / r_brightness, r_postprocess_sceneGamma / r_postprocess_Exposure and finally r_ambientGamma / r_ambientMinLevel. Since not everybody has postprocessing enabled, the gamma correction in the postprocessing stage should probably be removed completely. When doing that, default values for r_gamma and r_brightness should be adjusted accordingly to maintain the look. In their current implementation, r_gamma and r_brightness still suffer from color banding and os brightness change, which would have to be fixed.

Up to the latest moment I did not know that gamma/brightness correction can be done via postprocessing cvars.

If it is global and can fully substitute r_gamma/r_brightness (without affecting desktop), it would be great to switch to them in future. Then r_gamma/r_brightness can be forever left at their default values or even removed.

Link to comment
Share on other sites

If it is global and can fully substitute r_gamma/r_brightness (without affecting desktop), it would be great to switch to them in future. Then r_gamma/r_brightness can be forever left at their default values or even removed.

We still need a way to apply the min. ambient brightness when PP is off.

Link to comment
Share on other sites

Up to the latest moment I did not know that gamma/brightness correction can be done via postprocessing cvars.

If it is global and can fully substitute r_gamma/r_brightness (without affecting desktop), it would be great to switch to them in future. Then r_gamma/r_brightness can be forever left at their default values or even removed.

But then you'd force postprocessing on everyone. Is that a wise move? We need a general solution without decreasing performance.

 

Because TDM has no real HDR yet: all intermediate colors are stored in 8-bit values.

The main reason why Duzenko did the correction for ambient light only is that inside a single shader you can avoid color banding since intermediate values are 32-bit floats.

Ok, I was under the impression we could just render the image in higher precision. Thanks for the clarification. So then I see the value of r_AmbientMinValue and r_AmbientGamma. The question still remains, though, how players should configure these tons of parameters.

  • Like 1
Link to comment
Share on other sites

But then you'd force postprocessing on everyone. Is that a wise move? We need a general solution without decreasing performance.

 

Ok, I was under the impression we could just render the image in higher precision. Thanks for the clarification. So then I see the value of r_AmbientMinValue and r_AmbientGamma. The question still remains, though, how players should configure these tons of parameters.

Leave to default values if they don't understand it or don't have a problem with it

  • Like 1
Link to comment
Share on other sites

But then you'd force postprocessing on everyone. Is that a wise move? We need a general solution without decreasing performance.

The need for it arises in different contexts: gamma correction, maybe SSAO, maybe FXAA.

We can resist it now, but fullscreen pass will eventually appear anyway :D

 

We have r_gamma/r_brightness as a general solution which does not decrease performance.

It you want to avoid messing with desktop, then you have to do the correction yourself. Which means you have to spend resources on it. Obviously, GPU resources.

Then you either add a separate pass for it (expensive), or concatenate it to existing pass (cheap).

For a global correction, you can only concatenate correction to full-screen final pass. So either you have one, or your introduce one.

 

Ok, I was under the impression we could just render the image in higher precision. Thanks for the clarification. So then I see the value of r_AmbientMinValue and r_AmbientGamma. The question still remains, though, how players should configure these tons of parameters.

"Just render on higher precision" is not so.

Format GL_R11F_G11F_B10F won't increase precision on low colors, and anything else means increasing size of all FBOs, meaning more bandwidth and noticeable performance loss.

 

One thing which is worth trying to a postprocessing shader which looks at neighboring pixels and tries to interpolate color after correction, so that those ugly isolines between flat zones got blurred. Of course, this thing means more performance loss compared to simple correction (something on par with FXAA).

Link to comment
Share on other sites

We have r_gamma/r_brightness as a general solution which does not decrease performance.

It you want to avoid messing with desktop, then you have to do the correction yourself. Which means you have to spend resources on it. Obviously, GPU resources.

Right, so, when post processing is enabled, the brightness and gamma sliders should adjust the postprocessing gamma and brightness cvars, otherwise, the should adjust r_gamma and r_brightness. If a person disables post processing, he should maybe get a warning that brightness and gamma sliders also affect the OS when alt+tabbing or on unexpected shutdowns.

 

We should make sure, though, that all brightness corrections do mathematically/perceptionally the same, which might not be the case in the current implementation. The ambientMinLevel algorithm seems very good, as it cannot introduce oversaturated areas, but that probably cannot implemented for r_brightness.

 

Furthermore, I suggest the addition of another slider "High quality (no color banding) ambient light increase" to tweak r_ambientMinLevel in sensible range.

 

A description of these techniques should be added to the gamma room, if possible also directly to the settings menu via small buttons labeled "(i)" (information) or "?" and respective messagebox-popups. Message popups like that would make sense for many settings that the average player might not understand.

 

One thing which is worth trying to a postprocessing shader which looks at neighboring pixels and tries to interpolate color after correction, so that those ugly isolines between flat zones got blurred. Of course, this thing means more performance loss compared to simple correction (something on par with FXAA).

Wouldn't that also introduce blurring of details? Instead of that, maybe we could use a dithering-like approach where noise is added (or subtracted depending on gamma value). The noise amplitude would be equaliy distributed between 0 and the expected height of the banding effect at the graylevel of the unprocessed pixel, effectively masking the banding effect. This very subtle noise might even have a positive effect on subjective image sharpness as it introduces some high frequency components.
Link to comment
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.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...