Jump to content


Photo

Soft r_gamma


87 replies to this topic

#26 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 19 December 2017 - 09:26 AM

By "brighten up" in OP I meant pixels on the screen only. The only place it could affect gameplay is lightgem because it reads pixels back to engine. In the followup patch I fixed that by skipping shader gamma for lightgem views.

 

 

I'll test that tonight.

Also see if r_gamma 1 fixes it.


  • Bikerdude likes this

#27 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 9101 posts

Posted 19 December 2017 - 11:52 PM

r_gamma 1 does not fix it but setting ambient to simple does.


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

#28 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 20 December 2017 - 07:16 AM

r_gamma 1 does not fix it but setting ambient to simple does.

Try now



#29 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 9101 posts

Posted 21 December 2017 - 01:14 PM

Try now


Working. No side effects seen.
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...)

#30 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 17 August 2018 - 03:47 AM

Do we want to add this to the simple ambient? Or remove the simple ambient option (I'd prefer the latter)?



#31 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37446 posts

Posted 17 August 2018 - 07:26 AM

The simple ambient was originally for low performance machines.  I wonder how many users are using it anymore.


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

#32 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1119 posts

Posted 01 September 2018 - 12:43 PM

By the way, do I understand right that the only effect of gamma settings now is brightening ambient light?

And the formula is this:

color.rgb *= 1 + u_gamma*(1 - dot(color.rgb, vec3(1./3)));

I might be saying obvious things, but

 1) this formula is not a gamma correction (which should be using power function)

 2) correcting only ambient light without changing interaction light is not how gamma correction should work

Indeed, the new way probably works as yet another way of making screen brighter, but calling it gamma is wrong.

 

And the right way of implementing gamma is a postprocessing pass with power function (which may be approximated/precomputed with texture lookup).

 

P.S. The way I used simple ambient was to isolate some bugs in shaders  :D



#33 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 01 September 2018 - 02:22 PM

By the way, do I understand right that the only effect of gamma settings now is brightening ambient light?

And the formula is this:

color.rgb *= 1 + u_gamma*(1 - dot(color.rgb, vec3(1./3)));

I might be saying obvious things, but

 1) this formula is not a gamma correction (which should be using power function)

 2) correcting only ambient light without changing interaction light is not how gamma correction should work

Indeed, the new way probably works as yet another way of making screen brighter, but calling it gamma is wrong.

 

And the right way of implementing gamma is a postprocessing pass with power function (which may be approximated/precomputed with texture lookup).

 

P.S. The way I used simple ambient was to isolate some bugs in shaders  :D

1. Right.

The next question. Do people "want" the power function? I.e. does the power function "looks better" than simpler methods? I am reluctant to apply costly full-screen postprocessing or shader stages because of their FPS impact. We should at least offer a low-end option for this. I don't object in principle for implementing slower alternatives for high-end systems.

2. Right.

Again, do the users "want" a crutch up for non-ambient lights even if it makes sense? I'm considering universal post-process for the multi-light shader. Adding this to the single-light shader probably does not make sense.

Particles/postprocessing surfaces? Matter of taste, discussion and vote.

 

Politics wise, I don't want internet reviews from new users like this "wow this game graphics looks like 10 years old and still only NN fps on my GTX 1080" (with SS/AA/PP maxed out)



#34 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37446 posts

Posted 01 September 2018 - 03:36 PM

I don't understand what is being discussed.  It sounds like the regular gamma correcting controls we've used until now are being replaced by ones that don't do the same thing?

 

correcting only ambient light without changing interaction light is not how gamma correction should work

 

 

So in a scene with only regular lights, not ambient ones, changing gamma settings in the menu won't actually do anything now?


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

#35 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 01 September 2018 - 06:21 PM

I don't understand what is being discussed.  It sounds like the regular gamma correcting controls we've used until now are being replaced by ones that don't do the same thing?

 

 

So in a scene with only regular lights, not ambient ones, changing gamma settings in the menu won't actually do anything now?

Yes and yes



#36 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37446 posts

Posted 01 September 2018 - 07:58 PM

Yes and yes

 

What is the rationale for replacing gamma correction with something that works completely differently?


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

#37 New Horizon

New Horizon

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 13853 posts

Posted 01 September 2018 - 08:30 PM

Maybe I don't understand what is being done but isn't that kind of a bad thing?

#38 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1119 posts

Posted 02 September 2018 - 12:21 AM

What is the rationale for replacing gamma correction with something that works completely differently?

One reason to change gamma was #4160 (well, Duzenko probably has another idea?).

The old version changed gamma setting directly in Windows, and then reverted this change back when the engine shut down.

It means that if you change gamma setting in windowed TDM, then all the other windows and desktop also become brighter/darker.

Even worse, if the game crashes, then the desktop is left in the brighter state until the user reboots machine.

I personally hated this concept much during development, and eventually had to set gamma to 1 on developement installation just to make sure that TDM does not mess my desktop when I stop execution.

 

Maybe I don't understand what is being done but isn't that kind of a bad thing?

I think it is a good thing if done right, but the current implementation is not right.

 

Do people "want" the power function? I.e. does the power function "looks better" than simpler methods? I am reluctant to apply costly full-screen postprocessing or shader stages because of their FPS impact. We should at least offer a low-end option for this. I don't object in principle for implementing slower alternatives for high-end systems.

I think yes, people want power function.

In fact, the best solution is to restore old behavior (I mean only the visible result, not the means of doing it), unless everyone agrees that the new one is better.

 

By the way, TDM already has bloom for a long time, which is most likely a fullscreen postprocessing. So if you are worrying about performance of fullscreen gamma-correction, you can just add gamma-correction to the end of the bloom shader, thus avoiding additional pass.

 

I'm considering universal post-process for the multi-light shader. Adding this to the single-light shader probably does not make sense.

Multi-light shader is a very experimental thing (shadow maps only, hard shadows only, etc), which is unlikely to become default in the near future. So the current default is the main thing everyone worries about.

The gamma correction should not be done in any intermediate shaders like ambient/interaction, it should be done as the very last full screen postprocessing.



#39 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1119 posts

Posted 02 September 2018 - 12:28 AM

Strangely, the current "soft gamma" implementation applies only to gamma setting, but not the brightness setting.

If user changes brightness, then the whole Windows desktop is affected via the same SetDeviceGammaRamp winapi call.

 

I think the easiest way to restore exactly the old look but without "it affects desktop" problem would be:

1) Remove the gamma setting in shaders.

2) Uncomment back r_gamma.GetFloat() in R_SetColorMappings.

3) Refactor a part from R_SetColorMappings which computes the 256-entry lookup table (aka palette) into a new function like R_ComputeColorMappings.

4) Use R_ComputeColorMappings and load the resulting table as 1D texture to OpenGL.

5) Change the TDM postprocessing shader so that it makes lookup in the 1D texture as its very last step.

In fact, by doing this we can easily retain the old way of calling SetDeviceGammaRamp under cvar, if anyone wants it.



#40 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 02 September 2018 - 01:36 AM

Strangely, the current "soft gamma" implementation applies only to gamma setting, but not the brightness setting.
If user changes brightness, then the whole Windows desktop is affected via the same SetDeviceGammaRamp winapi call.
 
I think the easiest way to restore exactly the old look but without "it affects desktop" problem would be:
1) Remove the gamma setting in shaders.
2) Uncomment back r_gamma.GetFloat() in R_SetColorMappings.
3) Refactor a part from R_SetColorMappings which computes the 256-entry lookup table (aka palette) into a new function like R_ComputeColorMappings.
4) Use R_ComputeColorMappings and load the resulting table as 1D texture to OpenGL.
5) Change the TDM postprocessing shader so that it makes lookup in the 1D texture as its very last step.
In fact, by doing this we can easily retain the old way of calling SetDeviceGammaRamp under cvar, if anyone wants it.

What about players with PP off (me included)?

#41 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1119 posts

Posted 02 September 2018 - 01:56 AM

What about players with PP off (me included)?

Hmm... various things ranging from using the old desktop-affecting way to having the hardcoded gamma/brightness ?

Does postprocessing really makes things so much slower, especially if you keep bloom to minimal ?



#42 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 02 September 2018 - 02:46 AM

Hmm... various things ranging from using the old desktop-affecting way to having the hardcoded gamma/brightness ?

Does postprocessing really makes things so much slower, especially if you keep bloom to minimal ?

In a quick test, 47 -> 42 fps, i.e. costs about 4 ms on my system.

IMO not worth it.

Now if we always had FBO on we could do it on the FBO -> screen stage practically for free. But in the current situation the ambient/passthrough shaders are the two most suiting places for it.



#43 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1119 posts

Posted 02 September 2018 - 03:05 AM

In a quick test, 47 -> 42 fps, i.e. costs about 4 ms on my system.

I got 2.5 ms with my calculator  :P

Now if we always had FBO on we could do it on the FBO -> screen stage practically for free.

Well, that's another option.

Do it in there when FBO is on, and fallback to monitor hacks if FBO is disabled.

But in the current situation the ambient/passthrough shaders are the two most suiting places for it.

Doing anything in ambient interaction shader will result in incorrect gamma correction.

 

UPDATE: In the end, I hope that bloom shaders will be converted to GLSL at some moment.

Right now I cannot even understand which of those 15-20 assembly shader files are used...



#44 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 02 September 2018 - 05:02 AM

I got 2.5 ms with my calculator  :P

Well, that's another option.

Do it in there when FBO is on, and fallback to monitor hacks if FBO is disabled.

That would also require on-the-fly monitor gamma toggle code



#45 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37446 posts

Posted 02 September 2018 - 07:22 AM

One reason to change gamma was #4160 (well, Duzenko probably has another idea?).

 

 

I understand wanting to fix that, but it I would think we would want the game to still look the way it did before.  Brightening only ambient lights is liable to wash out some scenes, and will reduce the overall contrast in scenes with both ambient and regular lights, which seems like the opposite of what gamma should do.


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

#46 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1119 posts

Posted 02 September 2018 - 07:27 AM

That would also require on-the-fly monitor gamma toggle code

It is already on-the-fly, just drag the brightness slider in video settings.



#47 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 02 September 2018 - 08:41 AM

It is already on-the-fly, just drag the brightness slider in video settings.

No, I mean set the monitor gamma when r_usefbo changes



#48 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1119 posts

Posted 02 September 2018 - 09:13 AM

No, I mean set the monitor gamma when r_usefbo changes

And is it a problem?

 

There is already R_CheckCvars function, which is called every frame, and the monitor gamma was/is set exactly there.

In fact, it checks if brightness/gamma was modified recently and computes + applies new palette to the monitor if it was.



#49 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1805 posts

Posted 03 September 2018 - 05:02 AM

And is it a problem?

 

There is already R_CheckCvars function, which is called every frame, and the monitor gamma was/is set exactly there.

In fact, it checks if brightness/gamma was modified recently and computes + applies new palette to the monitor if it was.

Just adds time to have that done



#50 stgatilov

stgatilov

    Lead Programmer

  • Active Developer
  • PipPipPip
  • 1119 posts

Posted 03 September 2018 - 09:30 AM

Are there other opinions on the problem?

 

I guess trying to avoid color banding was the reason to tweak ambient light.

Such tweak itself may be OK, but I think it cannot replace gamma correction.





Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users