VisualShader: Add LinearToSRGB and SRGBToLinear to ColorFunc node

[tetrapod00]

Implements and closes godotengine/godot-proposals#10818.

Adds LinearToSRGB and SRGBToLinear conversions to the visual shader node ColorFunc.

Implementation:
This node automatically switches it's conversion function depending on which renderer is used.

The RenderingDevice (Forward+ and Mobile Renderer) conversion functions:

godot/servers/rendering/renderer_rd/shaders/effects/copy_to_fb.glsl

Lines 121 to 130 in 4254946

	vec3 linear_to_srgb(vec3 color) {
	//if going to srgb, clamp from 0 to 1.
	color = clamp(color, vec3(0.0), vec3(1.0));
	const vec3 a = vec3(0.055f);
	return mix((vec3(1.0f) + a) * pow(color.rgb, vec3(1.0f / 2.4f)) - a, 12.92f * color.rgb, lessThan(color.rgb, vec3(0.0031308f)));
	}
	vec3 srgb_to_linear(vec3 color) {
	return mix(pow((color.rgb + vec3(0.055)) * (1.0 / (1.0 + 0.055)), vec3(2.4)), color.rgb * (1.0 / 12.92), lessThan(color.rgb, vec3(0.04045)));
	}

The Compatibility renderer uses slightly different functions:

godot/drivers/gles3/shaders/tonemap_inc.glsl

Lines 13 to 26 in 4254946

	// This expects 0-1 range input.
	vec3 linear_to_srgb(vec3 color) {
	//color = clamp(color, vec3(0.0), vec3(1.0));
	//const vec3 a = vec3(0.055f);
	//return mix((vec3(1.0f) + a) * pow(color.rgb, vec3(1.0f / 2.4f)) - a, 12.92f * color.rgb, lessThan(color.rgb, vec3(0.0031308f)));
	// Approximation from http://chilliant.blogspot.com/2012/08/srgb-approximations-for-hlsl.html
	return max(vec3(1.055) * pow(color, vec3(0.416666667)) - vec3(0.055), vec3(0.0));
	}
	// This expects 0-1 range input, outside that range it behaves poorly.
	vec3 srgb_to_linear(vec3 color) {
	// Approximation from http://chilliant.blogspot.com/2012/08/srgb-approximations-for-hlsl.html
	return color * (color * (color * 0.305306011 + 0.682171111) + 0.012522878);
	}

If #90187 is merged, and the change in that PR is also made to the GLSL version of the linear_to_srgb and srgb_to_linear functions, then this visual shader node will need to be updated.

[Geometror]

Originally, I wanted to suggest switching the computation based on the current renderer, but after looking at the referenced blog article, I think it would be fine to just use the compatibility version (since it's a very good approximation). Maybe it can be used for RD renderers as well. CC @clayjohn

[tetrapod00]

All else being equal, the visual shader node should be accurate to whatever computation is used in the current renderer (or, if it must make assumptions, favor the Forward+ and Mobile renderers).
But if the Compatibility approximation is both much faster and still very accurate, then it makes sense to use it for visual shdaer nodes, where you might be converting between color spaces repeatedly (if a node is there, it will be used!).

[tetrapod00]

The computation now depends on the renderer, exactly matching whichever computation is used internally.

[Mickeon]

Assuming accuracy, the docs are completely fine.

[Repiteo]

Thanks!

[allenwp]

I have been working on the HDR output PR, which requires the use of HDR buffers. This PR is useful because it allows simulation of traditional blending with nonlinear sRGB-encoded values, while still using HDR buffers. This approach involves performing a linear to sRGB conversion, applying blending or other shader operations, and then converting back to linear.

Especially when using HDR output it is important that all HDR values are maintained (values above 1.0). This PR clamps these values so that colour information is lost if it is above 1.0, but only in the Mobile and Forward+ rendering methods that most need this colour information.

I understand that "this is the way it was previously done in many shader files in Godot", but in these previous cases it wouldn't have an impact because the colour value was immediately written to a buffer that clamps to [0, 1]. The use case for this node is different: it is expected that the user may be converting to and from nonlinear-sRGB encoding to achieve different effects. If they want to clamp, they can do so with the Clamp visual node.

Is there a reason that the clamp function was included in this node for Mobile and Forward+?

[allenwp]

Is there a reason that the clamp function was included in this node for Mobile and Forward+?

Since I haven't heard back after a few weeks, I've opened an issue and PR to remove clamping from the LinearToSRGB visual shader node.