View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004705||The Dark Mod||Graphics||public||20.12.2017 11:57||22.02.2020 14:02|
|Priority||normal||Severity||normal||Reproducibility||have not tried|
|Target Version||TDM 2.08||Fixed in Version||TDM 2.08|
|Summary||0004705: Soft gamma|
|Description||Report related issues here|
|Tags||No tags attached.|
|related to||0005163||new||Allow to configure gamma/brightness in menu with quick preview|
|related to||0004160||closed||duzenko||Gamma controls effecting desktop, rather than engine.|
|related to||0004545||acknowledged||Gamma and brightness controls have no effect on external monitor|
|related to||0004932||confirmed||Graphical Settings Menu Overhaul|
|child of||0003684||new||Investigate GPL Renderer Improvements|
invalid value in lightgem gamma uniform
I'm not sure what's left to do here.
As far as I can tell, there are no visual issues and this feature is complete?
Pending @stgatilov's review of the brightness formula.
It's giving what looks like a Thief2 effect to me, rather than classic gamma boost. (And personally I like it more this way)
Currently, the soft gamma settings are complementary to the old gamma/brightness settings.
They are controlled by two new cvars:
r_ambientMinLevel: linearly transforms the colors so that everything which normally receives zero light will have color = minLevel.
r_ambientGamma: has exactly the same mathemetical effect as the old r_gamma (but it affects only ambient lighting).
More details here:
P.S. Initially I thought that it would go through widespread testing and we will find out which settings we can drop.
However, as soon as I made all settings configurable, the "soft gamma" topic lost all interest =)
|2.07 beta testers can offer final feedback for this.|
|Softgamma is very good. I have just one suggestion to make. The r_ambient_MinLevel range from 0.0 to 1.0. Wouldn't it make more sense to have the same type of scaling as regular lights in DR, i.e., an integer value between 0 and 255?|
|IMHO the DR conventions should not apply to TDM cvars. We have e.g. r_gamma and r_lightscale both ranging 0-1|
I see an opportunity for a little cleanup.
Note that the r_postprocess cvars include gamma controlling shaders.
We are probably duplicating operations between these and the new soft gamma
While I haven't looked at the code, is the difference maybe that soft gamma is only applied to ambient light whereas the post-processing gamma and exposure (equivalent to soft gamma's linear correction) are applied globally? It sounds like that from the descriptions.
Still, we have three places where gamma is applied now. At least one of them should be removed, probably r_gamma.
|I have changed target version to 2.08, as there is still some stuff to do and to discuss. See related issues.|
|What's here to do ATM? Looks resolved to me.|
1) Offer Soft Gamma in the GUI
2) Eliminate redundant Soft Gamma from the Postprocess shader
Since these are sub-tasks, this tracker could be marked as closed.
"Technically", it could've been marked closed in TDM 1.03 when JC Denton
added soft gamma controls to the HDR-lite posprocess...
Nobody was aware of the implications\potential at the time.
There are legitimate reasons not to remove the gamma/brightness from post processing. It is the only way to adjust gamma/brightness without affecting the OS.
I recommended to have the brightness and gamma sliders change the post-processing gamma and brightness as long as post-processing is enabled. If it is disabled, the regular method should be used and a warning displayed that these settings affect the OS.
|Signing off on this for now|
|Will this get added in 2.08..?|
Here is the story.
In svn rev 8573, a new "tonemap" shader is introduced. It applies gamma+brightness adjustment to the whole screen instead of color tables which did it previously. The color tables are of course disabled. As a side effect, gamma and brightness 1) no longer affect main menu (not nice), 2) no longer affect the whole OS (good), 3) now affect screenshot (supposedly good). Postprocessing did not live good with this new shader. Moreover, postprocessing does its own gamma+brightness adjustment, so it redundant.
In svn rev 8581, I removed bloom completely and integrated all the other features of postprocessing into tonemap shader. So now there is only one shader with 6 cvars which perform final color adjustments (including gamma and brightness). The old postprocessing is removed completely. The cvars r_gamma nad r_brightness renamed to r_postprocess_gamma and r_postprocess_brightness to show that it is part of postprocessing, also set default gamma to 1.2 (not sure it is valid now, but probably a good starting point).
In svn revs 15787 and 15788 updated gamma/brightness cvars in GUI and removed postprocess/bloom menu settings.
Note that postprocessing can no longer be disabled, although setting the following cvars achieves the same effect:
I have created a related issue 0005163 for improving main menu in regards with postprocessing cvars.
Aside from that, I guess this issue is done: this implementation will work for everyone in 2.08, taking their gamma/brightness values into account.
|20.12.2017 11:57||duzenko||New Issue|
|20.12.2017 11:57||duzenko||Assigned To||=> duzenko|
|20.12.2017 11:57||duzenko||Status||new => assigned|
|20.12.2017 12:16||duzenko||Note Added: 0009851|
|29.12.2017 20:11||nbohr1more||Relationship added||related to 0004160|
|29.12.2017 20:12||nbohr1more||Relationship added||child of 0003684|
|29.12.2017 20:12||nbohr1more||Note Added: 0009928|
|29.12.2017 20:13||nbohr1more||Product Version||=> SVN|
|29.12.2017 20:13||nbohr1more||Target Version||=> TDM 2.07|
|25.06.2018 06:28||nbohr1more||Status||assigned => feedback|
|25.06.2018 06:29||nbohr1more||Note Added: 0010584|
|25.06.2018 07:23||duzenko||Note Added: 0010587|
|25.06.2018 07:23||duzenko||Status||feedback => assigned|
|25.06.2018 07:25||duzenko||Note Edited: 0010587||View Revisions|
|10.10.2018 04:17||stgatilov||Note Added: 0010785|
|12.12.2018 05:05||nbohr1more||Status||assigned => feedback|
|12.12.2018 05:05||nbohr1more||Note Added: 0010888|
|20.12.2018 16:54||nbohr1more||Relationship added||related to 0004545|
|22.12.2018 11:12||STiFU||Note Added: 0011047|
|22.12.2018 13:19||duzenko||Note Added: 0011051|
|22.12.2018 13:19||duzenko||Status||feedback => assigned|
|27.12.2018 03:47||nbohr1more||Note Added: 0011143|
|27.12.2018 10:05||STiFU||Note Added: 0011146|
|29.12.2018 08:51||STiFU||Relationship added||related to 0004932|
|30.12.2018 10:29||STiFU||Note Added: 0011191|
|30.12.2018 10:29||STiFU||Target Version||TDM 2.07 => TDM 2.08|
|16.02.2019 07:42||duzenko||Note Added: 0011605|
|16.02.2019 09:50||nbohr1more||Note Added: 0011608|
|17.02.2019 15:09||STiFU||Note Added: 0011613|
|05.05.2019 17:42||duzenko||Note Added: 0011785|
|05.05.2019 17:42||duzenko||Assigned To||duzenko =>|
|03.01.2020 13:31||Bikerdude||Note Added: 0012043|
|14.02.2020 16:51||stgatilov||Assigned To||=> stgatilov|
|14.02.2020 17:15||stgatilov||Note Added: 0012190|
|22.02.2020 14:00||stgatilov||Relationship added||related to 0005163|
|22.02.2020 14:02||stgatilov||Note Added: 0012236|
|22.02.2020 14:02||stgatilov||Status||assigned => resolved|
|22.02.2020 14:02||stgatilov||Resolution||open => fixed|
|22.02.2020 14:02||stgatilov||Fixed in Version||=> TDM 2.08|