hdr Tone mapping

[Arcturus]

Currently Darkmod does not utilize the full potential of its high dynamic range rendering. When light gets bright colors get clipped. As I mentioned before, this makes highlights hard to manage and makes bloom option less useful (in my opinion). At least that's what I see on my old ass monitor that doesn't support HDR.

I'll preface this with a disclaimer, that I have no idea what I'm doing. I also do not claim, that this code is ideal, or even good. I simply asked MS Copilot to modify the tonemap.frag.glsl file for me. It added a new color curve, that can be modified:

Spoiler

/*****************************************************************************
The Dark Mod GPL Source Code

This file is part of the The Dark Mod Source Code, originally based
on the Doom 3 GPL Source Code as published in 2011.

The Dark Mod Source Code is free software: you can redistribute it
and/or modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 3 of the License,
or (at your option) any later version. For details, see LICENSE.TXT.

Project: The Dark Mod (http://www.thedarkmod.com/)

******************************************************************************/
#version 330
in vec2 var_TexCoord;
out vec4 draw_Color;
uniform sampler2D u_texture;
uniform float u_gamma;
uniform float u_brightness;
uniform float u_desaturation;
uniform float u_colorCurveBias;
uniform float u_colorCorrection, u_colorCorrectBias;
uniform int u_sharpen;
uniform float u_sharpness;
uniform float u_ditherInput;
uniform float u_ditherOutput;
uniform sampler2D u_noiseImage;

/**
 * Contrast-adaptive sharpening from AMD's FidelityFX.
 * Adapted from Marty McFly's port for Reshade:
 * https://gist.github.com/martymcmodding/30304c4bffa6e2bd2eb59ff8bb09d135
 * Note this is only the most basic form of CAS. The AMD original
 * can do more, including up- and downscaling. As that's harder to implement,
 * we're keeping it simple here.
 */
vec3 sharpen(vec2 texcoord) {
    vec3 a = textureOffset(u_texture, texcoord, ivec2(-1, -1)).rgb;
    vec3 b = textureOffset(u_texture, texcoord, ivec2(0, -1)).rgb;
    vec3 c = textureOffset(u_texture, texcoord, ivec2(1, -1)).rgb;
    vec3 d = textureOffset(u_texture, texcoord, ivec2(-1, 0)).rgb;
    vec3 e = textureOffset(u_texture, texcoord, ivec2(0, 0)).rgb;
    vec3 f = textureOffset(u_texture, texcoord, ivec2(1, 0)).rgb;
    vec3 g = textureOffset(u_texture, texcoord, ivec2(-1, 1)).rgb;
    vec3 h = textureOffset(u_texture, texcoord, ivec2(0, 1)).rgb;
    vec3 i = textureOffset(u_texture, texcoord, ivec2(1, 1)).rgb;

    vec3 mnRGB = min(min(min(d, e), min(f, b)), h);
    vec3 mnRGB2 = min(mnRGB, min(min(a, c), min(g, i)));
    mnRGB += mnRGB2;
    vec3 mxRGB = max(max(max(d, e), max(f, b)), h);
    vec3 mxRGB2 = max(mxRGB, max(max(a, c), max(g, i)));
    mxRGB += mxRGB2;

    vec3 rcpMRGB = vec3(1) / mxRGB;
    vec3 ampRGB = clamp(min(mnRGB, 2.0 - mxRGB) * rcpMRGB, 0, 1);
    ampRGB = inversesqrt(ampRGB);
    float peak = 8.0 - 3.0 * u_sharpness;
    vec3 wRGB = -vec3(1) / (ampRGB * peak);
    vec3 rcpWeightRGB = vec3(1) / (1.0 + 4.0 * wRGB);
    vec3 window = (b + d) + (f + h);
    vec3 outColor = clamp((window * wRGB + e) * rcpWeightRGB, 0, 1);

    return outColor;
}

float mapColorComponent(float value) {
    float color = max(value, 0.0);
    color = pow(color, 1.0 / (u_gamma * 0.7)); // Increase gamma correction to make the image brighter
    color *= (u_brightness * 8); // Increase brightness to make the image brighter

    if (u_colorCurveBias != 0.0) {
        float reduced1 = 1.0 - pow(2.718282, -3.0 * color * color);
        color = mix(color, reduced1, u_colorCurveBias);
    }
    if (u_colorCorrectBias != 0.0) {
        float reduced2 = 1.0 - pow(2.718282, -u_colorCorrection * color);
        color = mix(color, reduced2, u_colorCorrectBias);
    }
    return color;
}

vec3 ditherColor(vec3 value, float strength) {
    vec2 tc = gl_FragCoord.xy / textureSize(u_noiseImage, 0);
    vec3 noiseColor = textureLod(u_noiseImage, tc, 0).rgb;
    value += (noiseColor - vec3(0.5)) * strength;
    return value;
}

vec3 applyTonemapping(vec3 color) {
    float A = 0.15;
    float B = 0.4;
    float C = 0.2;
    float D = 0.45;
    float E = 0.;
    float F = 0.6;

    return ((color * (A * color + C * + D * E) / (color * (A * color + + D * F)) - E / F;
}

void main() {
    vec3 color;
    if (u_sharpen != 0) {
        color = sharpen(var_TexCoord);
    } else {
        color = texture(u_texture, var_TexCoord).rgb;
    }

    if (u_ditherInput > 0) {
        color = ditherColor(color, -u_ditherInput);
    }

    color.r = mapColorComponent(color.r);
    color.g = mapColorComponent(color.g);
    color.b = mapColorComponent(color.b);

    color = applyTonemapping(color);

    if (u_desaturation != 0.0) {
        float luma = clamp(dot(vec3(0.2125, 0.7154, 0.0721), color.rgb), 0.0, 1.0);
        color = mix(color, vec3(luma), u_desaturation);
    }

    if (u_ditherOutput > 0) {
        color = ditherColor(color, u_ditherOutput);
    }

    draw_Color = vec4(color, 1);
}

Alternative set of ABCDEF values, should give slightly more contrast:

Spoiler

    float A = 0.5;
    float B = 1.;
    float C = 0.2;
    float D = 1;
    float E = 0.;
    float F = 1;

All the footage and screenshots below were done with bloom set to the max.

Spoiler

Spoiler

Spoiler

Spoiler

Spoiler

Spoiler

Spoiler

Spoiler

Spoiler

 

[peter_spy]

IIUC, the problem isn't that much with bloom itself, it's more about the specular response. I remember there are lines that makes specularity stronger than usual, reducing effective texture intensity range to something like 0-192 instead of 0-255. (If you turn postprocessing off and use specular map with values above RGB 192, the specular hotspot will get overblown, while it shouldn't.) Also I believe there's either some fresnel term there as well, or a code that increases specular intensity at grazing angles. IMO all of that should be removed first, before we fiddle with bloom.

Also, when it comes to bloom, maybe we could have better controls over it? Right now, we can control bloom only by going over RGB 1 in emissive textures (10 seems like a good starter value). But that makes the whole surface glow like a neon lamp:

While in engines like UE3/UDK you can set up bloom to be stronger without loosing surface details that much, something more like this (top right example):

There are some cvars related to bloom, so maybe we just have to play with them more:

seta r_bloom_blursteps "2"
seta r_bloom_downsample_limit "128"
seta r_bloom_weight "0.3"
seta r_bloom_detailblend "0.5"
seta r_bloom_threshold_falloff "8"
seta r_bloom_threshold "0.7"
seta r_bloom "1"

Edit: the UDK docs mention something like bloom kernel size, that's what we're probably missing in our cvars.

https://docs.unrealengine.com/udk/Three/Bloom.html

Edited November 21 by peter_spy

[nbohr1more]

As of TDM 2.08 I believe we set most of the r_postprocess cvars to 0 but there are already tonemapping features in there if you wanna tinker. I think that the decision to stick with 0 was to prevent the GUI menus from being over-bloomed.

As for specular?

We need to ensure that specular and diffuse response always adds to 1:

https://cientistavuador.github.io/articles/1_en-us.html

[Arcturus]

Neither the carpet nor the white plaster panel use specular maps. Most textures don't use specularmaps. You don't need specularmaps to blowup the image easily.

You also don't need bloom to blow up the image easily. There's is no bloom in this image.

Spoiler

It's just a stock darkmod torch, not even super bright, default settings, no bloom. Whites on the carpet are clipping too. You can use less bright textures, or move the light away, or turn down the light. But there's no real reason why the artist should do that, other than a technical limitation that you have to work around.

Having nice postprocessing is a just a bonus of high dynamic range. Having HDR just for bloom would be pointless, cause you can fake it in other ways. HDR and tonemapping are not just some gimmick used for for bloom. It's an important tool for making an overall nicer looking images. Bloom is not the only or main purpose of HDR.

When around 2017 Filmic tonemapper was introduced to Blender, it was a big facepalm moment for a lot of people, cause they realized that Blender offers super high bit depth, but a lot of that potential is simply thrown away. The Standard "view tranform" in Blender today is what was the default before Filmic:

Spoiler

This is pretty much what Darkmod is currently doing.

Here's Filmic:

Spoiler

Here's AgX that aims at fixing some of the problems of Filmic:

Spoiler

Here's Khronos PBR neutral that keeps details in the highlights while also maintaining saturation:

Spoiler

Those are renders from Eevee engine.

Of course once you have dynamic range under control you can shape colors further by adding or reducing contrast, adding postprocessing, whatever you like.

Spoiler

[Arcturus]

Btw, current fire particle uses:

Quote

    {
        blend        add
        map            textures/particles/arcturus_fire.tga
        vertexColor
    }

You can make it brighter by using

    {
        blend        add
        map            textures/particles/arcturus_fire.tga
        rgb 1
    }

But that doesn't look very good and animation is a bit choppy too.

I found this weird combination that gives big saturated bloom while also keeping the detail of the fire relatively unobscured:

	{
		blend		diffusemap
		map		_white
		rgb 0
	}
	{
		blend		add
		map		textures/particles/arcturus_fire.tga
		vertexColor
	}
	{
		blend		gl_dst_color , gl_one
		map		textures/particles/arcturus_fire.tga
		rgb 1
	}

 

It interferes with my negative clouds a little. Of course it's blown out with current color management.

It's still a little choppy. On bright backgrounds doesn't fade as gracefully. Maybe it would require changes to the particle animation.

[nbohr1more]

@stgatilov I think the newer postprocess shader is an improvement.

Since the impact only occurs when the r_postprocess cvars are active, it should be safe to replace no?

Thoughts \ objections?

[Arcturus]

17 hours ago, nbohr1more said:

I believe we set most of the r_postprocess cvars to 0 but there are already tonemapping features in there if you wanna tinker.

I haven't looked at those yet, but for now I asked Copilot to make a modification to make highlights slightly more saturated. So the result is something that is between the current look, and the one from the 1st post. This way the bright parts are perhaps a little less washed out.

Spoiler

/*****************************************************************************
The Dark Mod GPL Source Code

This file is part of the The Dark Mod Source Code, originally based
on the Doom 3 GPL Source Code as published in 2011.

The Dark Mod Source Code is free software: you can redistribute it
and/or modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 3 of the License,
or (at your option) any later version. For details, see LICENSE.TXT.

Project: The Dark Mod (http://www.thedarkmod.com/)

******************************************************************************/
#version 330
in vec2 var_TexCoord;
out vec4 draw_Color;
uniform sampler2D u_texture;
uniform float u_gamma;
uniform float u_brightness;
uniform float u_desaturation;
uniform float u_colorCurveBias;
uniform float u_colorCorrection, u_colorCorrectBias;
uniform int u_sharpen;
uniform float u_sharpness;
uniform float u_ditherInput;
uniform float u_ditherOutput;
uniform sampler2D u_noiseImage;

/**
 * Contrast-adaptive sharpening from AMD's FidelityFX.
 * Adapted from Marty McFly's port for Reshade:
 * https://gist.github.com/martymcmodding/30304c4bffa6e2bd2eb59ff8bb09d135
 * Note this is only the most basic form of CAS. The AMD original
 * can do more, including up- and downscaling. As that's harder to implement,
 * we're keeping it simple here.
 */
vec3 sharpen(vec2 texcoord) {
    vec3 a = textureOffset(u_texture, texcoord, ivec2(-1, -1)).rgb;
    vec3 b = textureOffset(u_texture, texcoord, ivec2(0, -1)).rgb;
    vec3 c = textureOffset(u_texture, texcoord, ivec2(1, -1)).rgb;
    vec3 d = textureOffset(u_texture, texcoord, ivec2(-1, 0)).rgb;
    vec3 e = textureOffset(u_texture, texcoord, ivec2(0, 0)).rgb;
    vec3 f = textureOffset(u_texture, texcoord, ivec2(1, 0)).rgb;
    vec3 g = textureOffset(u_texture, texcoord, ivec2(-1, 1)).rgb;
    vec3 h = textureOffset(u_texture, texcoord, ivec2(0, 1)).rgb;
    vec3 i = textureOffset(u_texture, texcoord, ivec2(1, 1)).rgb;

    vec3 mnRGB = min(min(min(d, e), min(f, b)), h);
    vec3 mnRGB2 = min(mnRGB, min(min(a, c), min(g, i)));
    mnRGB += mnRGB2;
    vec3 mxRGB = max(max(max(d, e), max(f, b)), h);
    vec3 mxRGB2 = max(mxRGB, max(max(a, c), max(g, i)));
    mxRGB += mxRGB2;

    vec3 rcpMRGB = vec3(1) / mxRGB;
    vec3 ampRGB = clamp(min(mnRGB, 2.0 - mxRGB) * rcpMRGB, 0, 1);
    ampRGB = inversesqrt(ampRGB);
    float peak = 8.0 - 3.0 * u_sharpness;
    vec3 wRGB = -vec3(1) / (ampRGB * peak);
    vec3 rcpWeightRGB = vec3(1) / (1.0 + 4.0 * wRGB);
    vec3 window = (b + d) + (f + h);
    vec3 outColor = clamp((window * wRGB + e) * rcpWeightRGB, 0, 1);

    return outColor;
}

float mapColorComponent(float value) {
    float color = max(value, 0.0);
    color = pow(color, 1.0 / (u_gamma * 0.75)); // Increase gamma correction to make the image brighter
    color *= (u_brightness * 8); // Increase brightness to make the image brighter

    if (u_colorCurveBias != 0.0) {
        float reduced1 = 1.0 - pow(2.718282, -3.0 * color * color);
        color = mix(color, reduced1, u_colorCurveBias);
    }
    if (u_colorCorrectBias != 0.0) {
        float reduced2 = 1.0 - pow(2.718282, -u_colorCorrection * color);
        color = mix(color, reduced2, u_colorCorrectBias);
    }
    return color;
}

vec3 ditherColor(vec3 value, float strength) {
    vec2 tc = gl_FragCoord.xy / textureSize(u_noiseImage, 0);
    vec3 noiseColor = textureLod(u_noiseImage, tc, 0).rgb;
    value += (noiseColor - vec3(0.5)) * strength;
    return value;
}

vec3 applyTonemapping(vec3 color) {
    float A = 0.15;
    float B = 0.4;
    float C = 0.2;
    float D = 0.45;
    float E = 0.;
    float F = 0.6;

    return ((color * (A * color + C * + D * E) / (color * (A * color + + D * F)) - E / F;
}

vec3 adjustHighlightsSaturation(vec3 color) {
    vec3 highlightBoost = vec3(1.2); // Adjust this value to control the highlight saturation
    vec3 midtones = vec3(1.0); // Adjust midtones saturation here
    vec3 shadows = vec3(0.8); // Adjust shadows saturation here

    vec3 adjusted = mix(color * shadows, color * midtones, smoothstep(0.2, 0.7, color));
    return mix(adjusted, color * highlightBoost, smoothstep(0.7, 1.0, color));
}

void main() {
    vec3 color;
    if (u_sharpen != 0) {
        color = sharpen(var_TexCoord);
    } else {
        color = texture(u_texture, var_TexCoord).rgb;
    }

    if (u_ditherInput > 0) {
        color = ditherColor(color, -u_ditherInput);
    }

    color.r = mapColorComponent(color.r);
    color.g = mapColorComponent(color.g);
    color.b = mapColorComponent(color.b);

    color = applyTonemapping(color);

    color = adjustHighlightsSaturation(color);

    if (u_desaturation != 0.0) {
        float luma = clamp(dot(vec3(0.2125, 0.7154, 0.0721), color.rgb), 0.0, 1.0);
        color = mix(color, vec3(luma), u_desaturation);
    }

    if (u_ditherOutput > 0) {
        color = ditherColor(color, u_ditherOutput);
    }

    draw_Color = vec4(color, 1);
}

Grouped into no bloom / bloom pairs.

Currently:

Spoiler

v01 from the previous post:

Spoiler

v02 with more saturated highlights; fire is a little more blown out:

Spoiler

currently:

Spoiler

v01 from the first post:

Spoiler

v02, difference is subtle, but bloom doesn't turn faces as white as v01:

Spoiler

 

[peter_spy]

6 hours ago, Arcturus said:

Neither the carpet nor the white plaster panel use specular maps. Most textures don't use specularmaps. You don't need specularmaps to blowup the image easily.

Of course not, since in non-pbr engines specularity is both diffuse and specular-driven. It's basically a ratio between those. That tonemapper changes the look of the game quite a bit btw. The contrast is much lower.

[Arcturus]

@peter_spy I'm interested in changing how brightest parts of the image are rendered, the rest can stay the same for all I care (within reason). The contrast can be lower in one area, but higher in the other, so it's tricky. Problem is, tinkering with values in a text file, reloading the file using game console and looking how the image changed is very time consuming.

[Arcturus]

There's an interesting difference between intensities of each RGB color.

 

Spoiler

table tonemaptable_01 { { 0, .1, .2, .3, .4, .5, .6, .7, .8, 0.9, 1, .9, .8, .7, .6, .5, .4, .3, .2, .1, 0 } }

tonemap_emission_red
{
    noShadows
    nonsolid
    {
        blend        add
        forceHighQuality
        map            _white
        red        tonemaptable_01[time*0.15]*10
        green    0
        blue    0
    }
}

tonemap_emission_green
{
    noShadows
    nonsolid
    {
        blend        add
        forceHighQuality
        map            _white
        red        0
        green    tonemaptable_01[time*0.15]*10
        blue    0
    }
}

tonemap_emission_blue
{
    noShadows
    nonsolid
    {
        blend        add
        forceHighQuality
        map            _white
        red        0
        green    0
        blue    tonemaptable_01[time*0.15]*10
    }
}

 

[peter_spy]

Btw. @cabalistic was working on the new bloom, maybe he could share some insight too?

[Arcturus]

In Blender in "standard" view transform if you take a pure red, green or blue emission color then it doesn't matter how big the strength of that light will be, after certain threshold it will stay the same color.

This works the same way in Darkmod. If you set a light or a 'shadeles' material to pure red, green or blue, when increased in brightness, after certain point it will not change at all.

In this example at high light values, details in the carpet start to disappear.

Newest view transform in Blender - AgX does something different. It will start to desaturate the color after certain point to compensate for the increased brightness:

This is how bright lights are typically rendered, with a white core and colorful bloom around:

 

The code that chatbot generated for me does not do that. Primary colors stay saturated at high values. But the details in the carpet are better preserved:

There is a simple workaround, though. Just add a little bit of other primary colors to the mix:
 

table tonemaptable_01 { { 0, .1, .2, .3, .4, .5, .6, .7, .8, 0.9, 1, .9, .8, .7, .6, .5, .4, .3, .2, .1, 0 } }

lights/tonemap_light_red
{   
    {
        forceHighQuality
        map    lights/biground1
        colored
        zeroClamp
        red        tonemaptable_01[time*0.15]*10
        green    tonemaptable_01[time*0.15]
        blue    tonemaptable_01[time*0.15]
    }
}

tonemap_emission_red
{
    noShadows
    nonsolid
    {
        blend        add
        forceHighQuality
        map            _white
        red        tonemaptable_01[time*0.15]*10
        green    tonemaptable_01[time*0.15]
        blue    tonemaptable_01[time*0.15]
    }
}

How it looks right now:

With custom GLSL:

Currently:

Custom:

 

[stgatilov]

I'm certainly against including any AI-generated code.
Remember: we don't change shaders just because they look more beautiful, there should be reasoning for a change and explanation of the math going on.

As far as I understand, the main complaint is that colors over 1.0 are simply clamped to 1.0, right?
And bloom is the only thing which depends on the values above 1.0.

This is usually fixed by using "c / (1 + c)" function with some coefficients.
There are a lot of existing tonemap formulas around this principle, we can probably choose some.

The current tonemap consists of:

1. gamma correction: C := C ^ (1 / gamma)     (gamma = 1.2)
2. brightness: C := C * brightness    (brightness = 1)
3. something: C := 1 - exp(-5 C)

The first two came from original Doom 3, the last one is remnant of "HDR lite" that was an ancient attempt to make TDM look "HDR-ish" without even any extra precision.
There are a few other corrections, but I believe they are disabled by default.
Also, there are some technical stuff (dithering, sharpening) which are unrelated to the tonemapping itself.

It is possible to look through existing popular tonemap shaders for games, and replace what we have with some of them.

[Arcturus]

1 hour ago, stgatilov said:

I'm certainly against including any AI-generated code.

It's just a mockup. I don't advocate for any particular code as I know nothing about coding.

As I understand, other than compressing high dynamic range into low dynamic range, tonemappers like the Blender's "filmic" or Unreal's "filmic" try to shape the image in a way similar to traditional film emulsion. Hence the 'filmic' moniker. They come with look up tables.

Here's for example Blender's AgX implemenation in Unity. Its advertised feature is that by desaturating highlights even earlier than 'Filmic', the image is perceived as having more detail. That's advanced, esoteric stuff. Right now it's too easy to blow out the image in Darkmod and it can be improved in my opinion.

[Ralle321]

If you are interested in the AgX display view transform, i have cobbled up the full round trip from various sources a while ago, the main one being https://github.com/bWFuanVzYWth/AgX (uses MIT license).

Huge thanks go to bWFuanVzYWth aka linlin for creating an optimized exact version perfectly suited for realtime usage.

Before that, i used an approximation from shadertoy, which was fine except for some erratic pixels on the lightgem, so i am happy to say this is no longer the case with the exact version.

Also included are Blender AgX matrices. You can switch between original and Blender AgX by commenting/uncommenting the matrices lines in the file.

Additionally there are Looks to choose from by setting #define AGX_LOOK 0  to 1 or 2.

Or you can edit a look to your liking by playing with the CDL settings in the Look section.

One important thing to note is that AgX is meant for realistic rendering, there is no creative intent and you get a very neutral image by default. Typically color grading needs to be applied in addition to the display transform to create an effect, which can be achieved to a certain extent with the Looks, but that might not be enough depending on ones needs.

For non-photorealistic games other display transforms might be a better choice, like Tony McMapface for example.

But i don't know how to implement that.

Having played a few missions with AgX and a sensible custom look, i can say seeing no more burnt out highlights and no more clipping are a huge improvement. Other than that, it's perceptually not much different from standard darkmod 64bit.

Proper image formation is so important, as this article describes very well: https://alextardif.com/Tonemapping.html

Screenshots:

Spoiler

Original AgX:

https://s20.directupload.net/images/241123/zwsrrn4e.jpg

https://s20.directupload.net/images/241123/ymwuqbt2.jpg

Blender AgX:

https://s20.directupload.net/images/241123/za7tr5i3.jpg

https://s20.directupload.net/images/241123/cyafw3tb.jpg

My Custom Look (10% more contrast, 20% more saturation):

https://s20.directupload.net/images/241123/qhlmy7cl.jpg

https://s20.directupload.net/images/241123/55pmsuv4.jpg

Standard Darkmod 64bit:

https://s20.directupload.net/images/241123/ajfp96kx.jpg

https://s20.directupload.net/images/241123/m5jktno8.jpg

Attributions and Licenses are in the file (MIT-licenses for AgX and Looks). If that needs correction, please tell me.

Performance:

On my old and trusty GTX1080 there is basically no difference compared with standard darkmod 64bit, tested in 4k resolution.

And that is even with an added more precise srgb conversion when gamma is at 2.2 instead of the standard gamma conversion.

How to use:

Drop the attached modified tonemap.frag.glsl in the darkmod/glprogs/stages/tonemap folder and you are good to go. Happy testing!

tonemap.frag.glsl

[Arcturus]

Existing missions were not built with something like AgX in mind, but with it you could be a lot more bold with your lights. This just looks more right.

[Arcturus]

You can push lights to extreme and they just refuse to break. These are pure red, green and blue colors.

In 32bits you loose some texture...

 

[Arcturus]

With these settings it looks closer to what's currently in darkmod while also fixing the problem of garish highlights:

slope = vec3(1.15);
power = vec3(1.3, 1.3, 1.3);
sat = 1.1;

 

[stgatilov]

Get we try something simpler than AgX, please?

Undoubtedly, the tonemap must have some tweakable coefficients, but 30 of them is too much.
Of course someone make a research paper and tried to approximate filming response, and of course it will produce neutral filmic look if you put proper input. But we don't have proper input, TDM rendering is not even in linear space.

UPDATE: Okay, I'll try to look at the AgX integration, maybe it is not that complex at all, and has simple explanations. Well, aside from that specific curve, you know.

[stgatilov]

Here is some simplistic approach.

It multiplies the whole image by alpha = 0.7, making is darker.
But if the original color is brighter than 1 in any component, then the max color component is transformed as:

• x -> 1 - A / (B+x)

The proportion between RGB components is saved.

You can try to tweak alpha in shader, but it is a compromise between darkening normal images (e.g. color < 1 ones) and making overly high colors more distinguishable (color > 1 case).

Note that you can run reloadGLSLPrograms in console after editing shader, no need to restart game.

tonemap.frag.glsl

[peter_spy]

3 hours ago, Arcturus said:

With these settings it looks closer to what's currently in darkmod while also fixing the problem of garish highlights:

slope = vec3(1.15);
power = vec3(1.3, 1.3, 1.3);
sat = 1.1;

 

Are you using default bloom settings? I don't remember Gemcutter being that overblown in highlights. These are the defaults:
seta r_bloom_blursteps "2"
seta r_bloom_downsample_limit "128"
seta r_bloom_weight "0.3"
seta r_bloom_detailblend "0.5"
seta r_bloom_threshold_falloff "8"
seta r_bloom_threshold "0.7"

[stgatilov]

Does anyone know the paper explaining AgX?

I can only find a repo with function values (aka LUT), and another repo with same function converted analytic form (from some paper which I can't find).
The code also contains colorspace conversion (no comment which one), and switching to logarithmic scale with clamping, then the curve is called sigmoid while it is not (in fact, logarithmic conversion is sigmoid here).

[Arcturus]

14 hours ago, peter_spy said:

Are you using default bloom settings? I don't remember Gemcutter being that overblown in highlights. These are the defaults:
seta r_bloom_blursteps "2"
seta r_bloom_downsample_limit "128"
seta r_bloom_weight "0.3"
seta r_bloom_detailblend "0.5"
seta r_bloom_threshold_falloff "8"
seta r_bloom_threshold "0.7"

r_bloom_weight is set to "0.7" both in my 2.12 installation and in main repository. I never touched those values which means the default must be 0.7.

8 hours ago, stgatilov said:

Does anyone know the paper explaining AgX?

I can only find a repo with function values (aka LUT), and another repo with same function converted analytic form (from some paper which I can't find).
The code also contains colorspace conversion (no comment which one), and switching to logarithmic scale with clamping, then the curve is called sigmoid while it is not (in fact, logarithmic conversion is sigmoid here).

Troy Sobotka is the original creator of AgX. He was active on Blender forums where he had long philosophical arguments about color with people. Also on Blender developer forums. I don't know if there's much more beyond those and his github page: https://github.com/sobotka

Edit @stgatilov AgX however is a direct continuation of Sobotka's earlier 'Filmic', so there may be more about that: https://github.com/sobotka/filmic-blender

https://blender.stackexchange.com/questions/164991/are-the-technical-details-of-filmic-available

[peter_spy]

51 minutes ago, Arcturus said:

r_bloom_weight is set to "0.7" both in my 2.12 installation and in main repository. I never touched those values which means the default must be 0.7.

Try deleting darkmod.cfg and restarting the game. In both TDM versions I currently use, 2.10 & 2.12, the defaults are as above, and the bloom slider is always in this position:

[Arcturus]

@peter_spy As I mentioned before in the videos I put bloom on maximum.