Jump to content
The Dark Mod Forums

Soft r_gamma


duzenko

Recommended Posts

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.

Link to comment
Share on other sites

  • 7 months later...

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

Link to comment
Share on other sites

  • 3 weeks later...

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Yes and yes

 

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)?
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

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

      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
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...