polycount - User contributions [en]

Blending functions

2015-10-14T12:03:33Z

Millennium: /* Category 3 (Complex) */

Here are all the Photoshop Blending Modes, in easy to use functions for various languages.

==HLSL==
===Category 1 (Darker)===
<pre>float4 Darken (float4 cBase, float4 cBlend)
{
float4 cNew;
cNew.rgb = min(cBase.rgb, cBlend.rgb);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 Multiply (float4 cBase, float4 cBlend)
{
return (cBase * cBlend);
}</pre>

<pre>float4 ColorBurn (float4 cBase, float4 cBlend)
{
return (1 - (1 - cBase) / cBlend);
}</pre>

<pre>float4 LinearBurn (float4 cBase, float4 CBlend)
{
return (cBase + cBlend - 1);
}</pre>

===Category 2 (Lighter)===
<pre>float4 Lighten (float4 cBase, float4 cBlend)
{
float4 cNew;
cNew.rgb = max(cBase.rgb, cBlend.rgb);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 Screen (float4 cBase, float4 cBlend)
{
return (1 - (1 - cBase) * (1 - cBlend));
}</pre>

<pre>float4 ColorDodge (float4 cBase, float4 cBlend)
{
return (cBase / (1 - cBlend));
}</pre>

<pre>float4 LinearDodge (float4 cBase, float4 cBlend)
{
return (cBase + cBlend);
}</pre>

===Category 3 (Complex)===

==== Condintional statements in shaders ====
[http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html GPUs hate branching], so it's better to avoid '''if..else''' in your shaders. The promblem here is that GPU will execute both blocks of code anyway - for then and else respectively - eventually a part of calculations will be thrown away (the more unnecessary instructions executed, the lower shader performance will be). In most of the cases conditional statements could be substituted with a help of [https://msdn.microsoft.com/en-us/library/windows/desktop/ff471376(v=vs.85).aspx HLSL's intrinsic functions].

Let's optimize the following piece of code:
<pre>
float4 cNew;
if (cBase.r > .5) { cNew.r = 1 - (1 - 2 * (cBase.r - .5)) * (1 - cBlend.r); }
else { cNew.r = (2 * cBase.r) * cBlend.r; }

if (cBase.g > .5) { cNew.g = 1 - (1 - 2 * (cBase.g - .5)) * (1 - cBlend.g); }
else { cNew.g = (2 * cBase.g) * cBlend.g; }

if (cBase.b > .5) { cNew.b = 1 - (1 - 2 * (cBase.b - .5)) * (1 - cBlend.b); }
else { cNew.b = (2 * cBase.b) * cBlend.b; }
</pre>

As we see the result values of R, G and B components (except for alpha) for this blending mode depend on it's base layer initial values
<pre>
if (baseColor > .5) then {
resultColor = A;
} else {
resultColor = B;
}
</pre>

Using of [https://msdn.microsoft.com/en-us/library/windows/desktop/bb509618(v=vs.85).aspx lerp(A, B, interpolation_value)] - linear interpolation - function makes it simpler to switch between two branches.
<pre>
float4 newColor = lerp(A, B, interpolation_value); // = A*(1 - interpolation_value) + B*interpolation_value
</pre>

Actually we don't want newColor to gradually change between A and B, but only switch A <-> B, so interpolation_value must be strictly equal to 0 or 1. And here is where the [https://msdn.microsoft.com/en-us/library/windows/desktop/bb509665(v=vs.85).aspx step(x, y)] function comes in. The equivalent for '''step''' functionality is:
<pre>
float step(x, y) {
if (x > y) then {
return 0;
} else {
return 1;
}
}
</pre>

Apparently, if it's required to invert output values, we just should change the order of '''step''' input arguments. Let's assembly all the information we've found out and re-write our shader:
<pre>
float isLessOrEq = step(cBase, 0.5);
float4 cNew = lerp(1. - (1. - 2.*(cBase - .5))*(1. - cBlend), 2*cBase*cBlend, isLessOrEq); // get rid of per component calculations and using vectorization
// for performance optimization sake
cNew.a = 1.; // restore alpha
</pre>

P.S. In a special case, when one of the possible values of '''cNew''' is 0, there is no more need in '''lerp'''
<pre>
float isLessOrEq = step(cBase, 0.5);
float4 cNew = isLessOrEq * 2*cBase*cBlend; // = (x <= 0.5) ? 2*cBase*cBlend : 0;
</pre>

P.P.S. Although compiler will do this work for you at the optimization stage, keep in mind that explicit variables declaration as '''float''' (1.0, 1. or 1.f insted of 1) is more preferable then writing expressions with variables of different types and, in result, mixing '''float''' with '''int'''. It causes implicit type conversion, which sometimes leads to [http://media.moddb.com/images/members/1/691/690410/G-Mans_Ghost.jpg unforeseen consequences].

==== Shaders implementation ====
<pre>float4 Overlay (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBase, .5);
float4 cNew = lerp(2*cBlend*cBase, 1 - (1 - 2*(Base - .5))*(1 - Blend), isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 SoftLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(1 - (1 - cBase)*(1 - 2*cBlend*cBase), cBase*(1 - (1 - cBase)*(1 - 2*cBlend)), isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 HardLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(1 - (1 - cBase)*(1 - 2*cBlend), 2*cBlend*cBase, isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 VividLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(1 - (1 - cBase)/(2*(cBlend - .5)), cBase/(1 - 2*cBlend), isGreaterThen);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 LinearLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(cBase + 2*(cBlend - .5), cBase + 2*cBlend - 1., isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 PinLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(max(cBase, 2*(cBlend - .5)), min(cBase, 2*cBlend), isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

===Category 4 (Comparison)===
<pre>float4 Difference (float4 cBase, float4 cBlend)
{
return (abs(cBase - cBlend));
}</pre>

<pre>float4 Exclusion (float4 cBase, float4 cBlend)
{
return (.5 - 2 * (cBase - .5) * (cBlend - .5));
}</pre>

[[Category:HLSL]][[Category:Shaders]][[Category:Rendering]][[Category:Code]][[Category:Functions]]

Blending functions

2015-09-10T18:22:22Z

Millennium: /* Category 3 (Complex) */

Here are all the Photoshop Blending Modes, in easy to use functions for various languages.

==HLSL==
===Category 1 (Darker)===
<pre>float4 Darken (float4 cBase, float4 cBlend)
{
float4 cNew;
cNew.rgb = min(cBase.rgb, cBlend.rgb);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 Multiply (float4 cBase, float4 cBlend)
{
return (cBase * cBlend);
}</pre>

<pre>float4 ColorBurn (float4 cBase, float4 cBlend)
{
return (1 - (1 - cBase) / cBlend);
}</pre>

<pre>float4 LinearBurn (float4 cBase, float4 CBlend)
{
return (cBase + cBlend - 1);
}</pre>

===Category 2 (Lighter)===
<pre>float4 Lighten (float4 cBase, float4 cBlend)
{
float4 cNew;
cNew.rgb = max(cBase.rgb, cBlend.rgb);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 Screen (float4 cBase, float4 cBlend)
{
return (1 - (1 - cBase) * (1 - cBlend));
}</pre>

<pre>float4 ColorDodge (float4 cBase, float4 cBlend)
{
return (cBase / (1 - cBlend));
}</pre>

<pre>float4 LinearDodge (float4 cBase, float4 cBlend)
{
return (cBase + cBlend);
}</pre>

===Category 3 (Complex)===

==== Condintional statements in shaders ====
[http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter34.html GPUs hate branching], so it's better to avoid '''if..else''' in your shaders. The promblem here is that GPU will execute both blocks of code anyway - for then and else respectively - eventually a part of calculations will be thrown away (the more unnecessary instructions executed, the lower shader performance will be). In most of the cases conditional statements could be substituted with a help of [https://msdn.microsoft.com/en-us/library/windows/desktop/ff471376(v=vs.85).aspx HLSL's intrinsic functions].

Let's optimize the following piece of code:
<pre>
float4 cNew;
if (cBase.r > .5) { cNew.r = 1 - (1 - 2 * (cBase.r - .5)) * (1 - cBlend.r); }
else { cNew.r = (2 * cBase.r) * cBlend.r; }

if (cBase.g > .5) { cNew.g = 1 - (1 - 2 * (cBase.g - .5)) * (1 - cBlend.g); }
else { cNew.g = (2 * cBase.g) * cBlend.g; }

if (cBase.b > .5) { cNew.b = 1 - (1 - 2 * (cBase.b - .5)) * (1 - cBlend.b); }
else { cNew.b = (2 * cBase.b) * cBlend.b; }
</pre>

As we see the result values of R, G and B components (except for alpha) for this blending mode depends on it's base layer initial values
<pre>
if (baseColor > .5) then {
resultColor = A;
} else {
resultColor = B;
}
</pre>

Using of [https://msdn.microsoft.com/en-us/library/windows/desktop/bb509618(v=vs.85).aspx lerp(A, B, interpolation_value)] - linear interpolation - function makes it simpler to switch between two branches.
<pre>
float4 newColor = lerp(A, B, interpolation_value); // = A*(1 - interpolation_value) + B*interpolation_value
</pre>

Actually we don't want newColor to gradually change between A and B, but only switch A <-> B, so interpolation_value should be strictly equal to 0 or 1. And here is where the [https://msdn.microsoft.com/en-us/library/windows/desktop/bb509665(v=vs.85).aspx step(x, y)] function come in. The equivalent for '''step''' functionality is:
<pre>
float step(x, y) {
if (x > y) then {
return 0;
} else {
return 1;
}
}
</pre>

Apparently, if it's required to invert output values, just change the order of '''step''' input arguments. Let's assembly all the information we've found out and re-write our shader:
<pre>
float isLessOrEq = step(cBase, 0.5);
float4 cNew = lerp(1. - (1. - 2.*(cBase - .5))*(1. - cBlend), 2*cBase*cBlend, isLessOrEq); // get rid of per component calculations and using vectorization
// for performance optimization sake
cNew.a = 1.; // restore alpha
</pre>

P.S. In a special case, when one of the possible values of '''cNew''' is 0, there is no more need in '''lerp'''
<pre>
float isLessOrEq = step(cBase, 0.5);
float4 cNew = isLessOrEq * 2*cBase*cBlend; // = (x <= 0.5) ? 2*cBase*cBlend : 0;
</pre>

P.P.S. Although compiler will do this work for you at the optimization stage, keep in mind that explicit declaration variables as '''float''' (1.0, 1. or 1.f insted of 1) is more preferable then writing expressions with variables of different types and, in result, mixing '''float''' with '''int'''. It causes implicit type conversion, which sometimes leads to [http://media.moddb.com/images/members/1/691/690410/G-Mans_Ghost.jpg unforeseen consequences].

==== Shaders implementation ====
<pre>float4 Overlay (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBase, .5);
float4 cNew = lerp(2*cBlend*cBase, 1 - (1 - 2*(Base - .5))*(1 - Blend), isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 SoftLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(1 - (1 - cBase)*(1 - 2*cBlend*cBase), cBase*(1 - (1 - cBase)*(1 - 2*cBlend)), isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 HardLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(1 - (1 - cBase)*(1 - 2*cBlend), 2*cBlend*cBase, isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 VividLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(1 - (1 - cBase)/(2*(cBlend - .5)), cBase/(1 - 2*cBlend), isGreaterThen);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 LinearLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(cBase + 2*(cBlend - .5), cBase + 2*cBlend - 1., isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

<pre>float4 PinLight (float4 cBase, float4 cBlend)
{
float isLessOrEq = step(cBlend, .5);
float4 cNew = lerp(max(cBase, 2*(cBlend - .5)), min(cBase, 2*cBlend), isLessOrEq);
cNew.a = 1.0;
return cNew;
}</pre>

===Category 4 (Comparison)===
<pre>float4 Difference (float4 cBase, float4 cBlend)
{
return (abs(cBase - cBlend));
}</pre>

<pre>float4 Exclusion (float4 cBase, float4 cBlend)
{
return (.5 - 2 * (cBase - .5) * (cBlend - .5));
}</pre>

[[Category:HLSL]][[Category:Shaders]][[Category:Rendering]][[Category:Code]][[Category:Functions]]