Basically I’m trying to use the vertex color to separate a set of 10 LEDs with a common material that are part of the same mesh object. This way I can feed from the attribute node in Cycles to a less-than math operator node, and it should sequentially illuminate the LEDs by changing the other value. Problem is, despite being pretty certain each vertex colored part of the mesh is stepped by 0.1 in value, the behavior is not linear. Tried both color and factor output from the attribute node, and there doesn’t seem to be much difference. Instead of following the value steps, it ramps up in a non-linear manner.
So anybody know how to get vertex color from the attribute node to behave linearly? (I want it to behave similar to the data output setting on the image texture node.)
Ok… Did some more experimenting… Ended up putting the attribute output through an RGB-curves node. From the shape of the corrective curve I made (seems to be working), I’m suspecting there’s a logarithmic function that may be more accurate. (Could be handy in the future.) Any ideas?
It is linear, but your display is not a linear device and linear values will not produce a visualy linear gradient.
Apply sRGB gamma curve to your color. You can either build it with math nodes or approximate it with a 2.2 gamma (use power function in math node).
In linear gradient the middle value is 0.5 but to have a perceptually linear appearance it should be 0.18 (middle gray in scene linear values). So by applying a gamma curve of 2.2 you get 0.5^2.2=~0.21 It is not exact but close enough approximation for whole curve.
The whole topic is a bit complicated, because the perception of the image depends not only on display, but also viewing environment and there is always an end to end gamma greater than 1.0 and is for compensation of contrast reduction in dimly lit environment. For dim surround it is about 1.1 and 0.21^1.1=~0.18 which is exactly what we want.
It wasn’t just visual appearances, the output from the attribute node wasn’t triggering the steps of the math nodes. (Which would return a boolean I/O once past the threshold.) Again the (non-linear) scene colorspace is affecting the output before it hits the math nodes. (Seems like the same reason why a data mode was added to the image nodes. I remember seeing some big thread about it before that handy fix was tossed in. However had trouble finding it again.) If that wasn’t the case, then 0.100 would light one bar in the test file, 0.200 would be two, etc. So it does need correction before the math nodes.
Still figured out something that works, so it’s good enough and I’ve managed to be able to animate some materials with some clever use of vertex color. Thanks for the input on it regardless. I’ll try the 2.2 gamma later on and see how that handles it.