Not logged inOpenClonk Forum
Forum Home Help Search Watchlist Register Login
Up Topic General / Feedback and Ideas / Gamma, still
Post
- - By siedlerclonk [lv] Date 2014-12-30 13:48
To clarify what I already said before http://forum.openclonk.org/topic_show.pl?tid=2943

Gamma, specifically GDI32/SetDeviceGammaRamp is a display correction function and not something to ABUSE for special effects or change to any value other than what the end user explicitly asks for. I strongly recommend to remove all references to it in the source and never touch it again.

Anyway, I already edited my executable byte code to void the function call. Faster than doing anything with the source myself :p

Until next release.
Reply
Parent - - By Zapper [de] Date 2014-12-30 14:00
Don't we now have (global) shader support? What about solving this with shaders now?
Reply
Parent - - By Newton [de] Date 2014-12-30 15:52
SetGamma should be replaced by setting the light color of the ambient light and dynamic lights.
Reply
Parent - - By Zapper [de] Date 2014-12-30 19:15
Gamma correction is usually more than just changing the intensity (or color) of the image. I doubt you can achieve the same effects by simply modyfing the lights' colors
Reply
Parent - - By Clonk-Karl [de] Date 2014-12-30 23:24
But do we actually have to make a gamma correction for what SetGamma is typically used for, or would it be enough to just darken or brighten the whole scene by some factors?
Reply
Parent - - By Sven2 [de] Date 2014-12-31 01:02
At least colorization should also be possible. E.g. to get the blueish shade in Shiver Peak.
Reply
Parent - By Maikel Date 2014-12-31 08:18
That is not so important in my opinion, it is much nicer to have a good night versus day cycle which does not make things too dark so that you can't see anything anymore
Reply
Parent - - By Clonk-Karl [de] Date 2014-12-31 12:08
Yeah, we could darken/brighten the three color channels individually. One idea might be to have a 3x4 matrix M and the final color is then obtained by M * (r,g,b,1), where r, g and b are the source color components. This would allow to easily "stack" various gamma-like effects on top of each other by multiplying the matrices together with the Trans_* functions that we already have.
Reply
Parent - - By Sven2 [de] Date 2014-12-31 12:22
That's also a pretty large number of operations per pixel, isn't it?
Reply
Parent - By Clonk-Karl [de] Date 2014-12-31 12:41 Edited 2014-12-31 12:46
It's one additional multiplication of a matrix with a vector. I would imagine matrix multiplications are highly optimized in GLSL, maybe using the GPU equivalent to SIMD instructions? Probably much better than computing the gamma correction curve per pixel, and better than an additional texture fetch if we precompute the gamma curve and store it in a texture.

We already have several texture fetches and coordinate transformations in the pixel shader in the lights branch at the moment, and even with my onboard GPU things run mostly smoothly for a scenario such as Crash.ocs. So I'm not worried about one additional matrix multiplication.
Reply
Parent - By Sven2 [de] Date 2014-12-30 16:00
I have opened a request in the bug tracker: http://bugs.openclonk.org/view.php?id=1197
Reply
Parent - By siedlerclonk [lv] Date 2015-04-07 17:04 Edited 2015-04-07 17:54
New version,

The good thing is the the game restores gamma to previous value when it loses focus or exits - A step in the right direction, however small.
The bad thing is it still runs the game with it's own value and no way to change it. As if there's no good reason for a non-standard gamma setting...

Not that editing the bytes in the executable is difficult or anything, just saying. ;)

edit:
Noticed that there's a DisableGamma in the registry now (wonder if it was there all the time :?) . That should be enabled by default, and in game control for it should be added for those who trust games with their gamma settings. I'll find out if it works next version.
Reply
Parent - - By Anonymous [lv] Date 2015-06-20 17:37
Ok, version 6.1... the gamma behavior is a little buggy? It will still change gamma on startup/exit display mode changes, including switching windows from fullscreen. It will however "reset" to my system values when a mission is aborted if the DisableGamma is set in the registry... until next display mode change, at least.
Reply
Parent - - By PeterW [gb] Date 2015-06-22 14:32
If it helps, I have been working on a shader gamma replacement last week. "Just" need to fix all the bugs that I introduced along the way.
Reply
Parent - - By PeterW [gb] Date 2015-08-31 17:50
In repository now. Note that the new gamma implementation is not backwards compatible, and especially less powerful than what we had before. I hope I didn't break too much stuff.
Reply
Parent - - By Newton [de] Date 2015-08-31 18:05 Edited 2015-08-31 18:15
Wow, that is cool! Finally, someone got down to this :-D

Edit: Why SetGamma(r,g,b) with r, g and b being values between 1 and 100? It should be SetGamma(RGB(r,g,b)) with r,g,b being values between 0 and 255 in my opinion because it is more consistent with other functions and allows 16 times more color precision.

Also, what exactly does the gamma shader slice colorize? (hud elements, upper board, text etc as well?)
Reply
Parent - By PeterW [gb] Date 2015-08-31 18:34
Because we want to be able to set a gamma > 1.0? The value is not a colour - it's an exponent per channel. I feel it would be wrong to use it with RGB.

And yes, I think it colourises everything. The shaders apply very broadly.
Reply
Parent - - By Newton [de] Date 2015-08-31 18:05
That it is not backward compatible is good news, because then we have one reason more to actually replace SetGamma with SetAmbientLightColor() which more appropriately describes the function of this method. (Perhaps with a deprecated wrapper).
Did you follow the discussion(s) here and there?

It is unfortunate that you do not have a clonkspot account, the latter forum seems to be invisible. I will cite the second one here:

>Clonkonaut: Und @ck - wie sieht es damit aus, dass die Engine einen veränderlichen Sonnenvektor vorgibt?
>Matthias: Erstmal bin ich dafür! Ich glaube, dass das sehr stark zur Atmosphäre beitragen kann, besonders, wenn man Sonnenrichtung, Lichtfarbe und Intensität irgendwie an die Uhr- und Jahreszeit koppeln könnte. Etwas mehr damit zu experimentieren, um beispielsweise die "Flachheit" des Hochofens auszumerzen, steht dann natürlich noch aus.
>Newton: Das würde dann den SetGamma-Kram im ersetzen. Wenn ich mich nicht irre, ist es (noch) nicht möglich die Lichtfarbe des Umgebungslichtes zu setzen. Das war an der Diskussion erstickt, ob man nicht auch Lichtfarben für Materialien festlegen kann/möchte (Lava: rot), denn die rote Lava soll ja vom Sonnenuntergang nicht auch dunkler werden. Diese beiden Features (globale Umgebungslichtfarbe setzen, zwecks Tag/Nacht/Ambient vs Farben pro glühendes Material) scheinen sich gegenseitig auszuschließen.
>Clonk-Karl: Wie wäre es wenn man die globale Umgebungslichtfarbe einfach als "glühende" Farbe des Sky-Materials betrachtet?
>Newton: Wie ich es verstanden habe, wird zum Start einer Runde für die gesamte Landschaft eine "Ambient Light Map" generiert. Diese wird dann im Spiel nurnoch bei Landschaftsveränderungen punktuell neu berechnet. Zurzeit ist dies ein zweidimensionales 8bit-Array.
>Würde man nun eine SetAmbientLightColor Funktion hinzufügen, so würde diese so funktionieren dass jeder Pixel beim Anwenden der Lightmap im Shader in der angegebenen Farbe eingefärbt wird.
>Möchte man stattdessen verschiedene Farben in der Lightmap, so müsste man diese bei Rundenbeginn als zweidimensionales 32bit-Array erzeugen. Dann funktioniert jedoch nicht mehr die oben erwähnte einfache Lösung für SetAmbientLightColor, da sonst die gesamte Lightmap gleichzeitig eingefärbt werden würde. Stattdessen müsste bei jedem Aufruf von SetAmbientLightColor die Lightmap komplett neu erzeugt werden. Da SetAmbientLightColor beim Zeitobjekt bei Sonnenauf- und Untergang sehr oft, vielleicht sogar jeden Frame, aufgerufen werden würde, halte ich diese Lösung für nicht machbar.
>Matthias: Die komplette Lightmap müsste man nicht erzeugen, man könnte doch eher den Himmel und die Materialien seperat halten.
>Newton: Hm ja stimmt, das würde gehen. Das hätte sogar den Vorteil dass man die Himmel-Lightmap nur updaten müsste wenn jemand Material überschreibt (aus Erde mit Hintergrund Tunnel Erde mit Hintergrund Himmel macht).


Having implement a shader based replacement for SetGamma, what do you think about this plan? Does this play into your current implementation (=is this easy with how you realized SetGamma?)
Reply
Parent - - By PeterW [gb] Date 2015-08-31 18:41
Gamma is something very different from coloured lights - for example, using a gray coloured light would make no difference once your eyes get used to it. On the other hand, a gamma of (0.8,0.8,0.8) will make everything subjectively darker by pushing the "middle intensities" down.

So in my mind this is a completely different discussion. We will probably want both options - especially because they are both cheap.
Reply
Parent - - By Newton [de] Date 2015-08-31 19:05
Hmm interesting, but then wouldn't be that the exact effect one would want to achieve with "dark" ambient light?
Reply
Parent - - By PeterW [gb] Date 2015-08-31 20:44
Depends. Dark ambient light would indirectly make directional light sources appear brighter?
Reply
Parent - By Newton [de] Date 2015-08-31 22:19
I guess so, but that sounds logical as well.
Reply
Up Topic General / Feedback and Ideas / Gamma, still
Post

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill