# Normalize mix shader fac to .75 as midpoint instead of .5

(I'm not really sure of the proper way to title this question, so feel free to edit.)

I am mixing 4 shaders together: 1 diffuse and 3 toon diffuse, as seen in the image. By default, I want them all to have equal weight, hence the current mix factors. However, I want to use input factors on this group, such as facing or pointiness, to mix between Diffuse and Toon Diffuse. These input factors are all values of 0-1. If I plug them into the mix node between the diffuse and 3 toons, then the weighting will be skewed, as the average value is .5, not .75 I need either some math that would translate the incoming factor to have a new midpoint, or a different way to mix these shaders that will not be unbalanced at the average value of .5

If the group input value is .5, the mix factor should be .75. If the group input value is 1, it should be 1, and 0, should be 0. If it were .25, the mix fac should be .375, and .75 should be .875.

What math would give me this translation, or is there another way to setup the mix nodes that avoids needing to do this?

## ColorRamp (or RGBCurve) as Value Remapping Tool

While the transformation could be certainly achieved with several math nodes, I would suggest to take advantage of the ColorRamp node:

The ColorRamp Node is used for mapping values to colors [and so to other values] with the use of a gradient.

The transformation you want to achieve is linear, with a different slope depending on which side of the range you fall into, but in any case is linear. We'll set up a Linear gradient for the node, then add a slider in corrispondece to the input value midpoint

• Pos = 0,5 in this case

and then set the value you would like to be mapped to

• V = 0,75

This means that we are asking Blender to make a linear remap of the incoming value from black to white (0-1) with a midpoint (0,5) with a value of 0,75. Note how this kind of set up should be done without Color Management models transforming your scene data. After that, you should be allowed to set it up like you want and everything should works fine. It's just an easy way to avoid being confused while seetting up the remapper.

Same thing can be done, and perhaps is visually more clear, with the RGBCurve node: Values before the 0,5 point are change "faster" than the values that comes after. The midpoint has a new value of 0.75. You can change the handle type to Vector in the menu that appears once the wrench icon is clicked.

Here's a try with the values proposed at the end of the question: • Perfect, I knew there had to be an easier solution I was missing. Can you elaborate on why the color model management matters? I understand what color models are, but I didn't realize they could interfere with this sort of math? I thought they changed how things look, not the actual numbers? – Drudge Jul 18 '16 at 1:06
• It' doesn't interfere with the math of the operation, but it change the corrispondence between RGB values and the resulting color Value in HSV. So it becomes harder to calculate the right Value for the new midpoint (in sRGB Display Device becomes 0.881 instead of 0.75). – Carlo Jul 18 '16 at 21:44