Jump to content


Photo

Soft r_gamma


87 replies to this topic

#76 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37378 posts

Posted 15 September 2018 - 08:14 AM

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? 


TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#77 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 15 September 2018 - 12:50 PM

I see. You're using lower contrast to compensate for dark pixel going out of range.

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

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



#78 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37378 posts

Posted 15 September 2018 - 02:07 PM

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.


TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#79 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 15 September 2018 - 03:01 PM

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.



#80 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1024 posts

Posted 01 October 2018 - 11:16 AM

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.



#81 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 01 October 2018 - 12:55 PM

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.



#82 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37378 posts

Posted 01 October 2018 - 02:35 PM

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.


  • stgatilov likes this
TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#83 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 01 October 2018 - 03:12 PM

 
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.

#84 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1024 posts

Posted 03 October 2018 - 12:09 PM

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.

 


  • nbohr1more likes this

#85 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1623 posts

Posted 03 October 2018 - 12:59 PM

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.



#86 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8987 posts

Posted 03 October 2018 - 03:04 PM

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.c...ds/the-dark-mod

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

#87 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37378 posts

Posted 03 October 2018 - 04:13 PM

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?


TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#88 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1024 posts

Posted 04 October 2018 - 01:28 AM

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.





Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users