# Connecting NodeSockets of differing types

If you check the docs, you can see under NodeSocket(bpy_struct):

type Data type Is

Type: enum in [‘CUSTOM’, ‘VALUE’, ‘INT’, ‘BOOLEAN’, ‘VECTOR’, ‘STRING’, ‘RGBA’, ‘SHADER’], default ‘VALUE’

What happens, if you connect sockets of differing types? In particular, RGBA connected to SHADER (Mix -> Material Output), and RGBA connected to VALUE (Image Texture -> ColorRamp)? Can someone tell how blender converts between the differing types?

• What are you asking about? These are simply types of sockets (the little dots on the sides of nodes), where usually you'll make connections between the same types (color > color, value > value...). May 24 '15 at 14:16
• I'm asking because I find it weird, that I can connect RGBA socket to SHADER socket. Why? They are of different type. May 24 '15 at 14:34
• blender assumes that you know enough to follow the color code at least May 24 '15 at 16:14
• You can connect any socket type to any other socket type and usually the conversion is done automatically - the exception is the SHADER type, where only a shader socket plugged into another shader socket will work (although there's nothing physically stopping you from trying) May 24 '15 at 18:05
• @GregZaal Can you enumerate how the conversions take place, i.e. how RGBA is converted to VALUE, for example. There are many possibilities, such as a weighted sum, taking only one of 4 values, etc... I'm also interested where in blender's code I could look up these conversions taking place. Also, you forget that I have RGBA plugged into the SHADER socket. It works, try it, though how? May 24 '15 at 18:29

## RGB(A) to Value

It is neither a weighted sum nor the max channel (as is the case for Value in HSV) - instead it's something I don't understand at all, something to do with the black magic of color management, but I'm happy to write it here anyway :)

In node_shader_valToTgb.c is the function node_shader_exec_rgbtobw, which calls IMB_colormanagement_get_luminance(col). Inside that function, we have dot_v3v3(luma_coefficients, rgb) - the dot product of the input color and some apparently random numbers at the top of that file: luma_coefficients[3] = { 0.2126f, 0.7152f, 0.0722f };

Recreating that as a node setup in blender gives the same result as you'd get from plugging the color into a Color Ramp node or RGB to BW node:

The cube render is black meaning the difference = 0

Shader nodes are always only RGB and never include an alpha channel. However, in the compositor they do. When converting RGBA to a Value in the compositor, the alpha channel is simply ignored - only the RGB values are used.

## RGB(A) to Vector

The alpha channel is simply discarded - Red becomes X, Green becomes Y, Blue becomes Z.

We can prove this by plugging a render into a Vector Curves node, and plugging that into a Viewer node - notice that the background becomes black (as the RGB values in that space were all 0):

## Vector to RGB(A)

It's simply the opposite of what's said above. X becomes Red, Y becomes Green, Z becomes Blue. The alpha is always assumed to be 1.0.

## Anything to Shader

This is the one exception - nothing is ever automatically converted to a shader, the result is always simply black, no matter what color or value you plug into it.

Personally I think this design is silly - if you plug a color straight into the material output (without going through any shaders first), you're expecting the result to be shadeless. But alas, this is not the case.

## Value to RGB(A)/Vector

This is pretty obvious I think, but just for completeness: Whatever the value is becomes the same for each channel/axis when converted to RGBA/Vector (though the alpha channel simply = 1)

Have I missed anything?

• About those "random" numbers, see Relative luminance and Luminosity function.
– user7952
May 24 '15 at 21:35
• The RGBA->Value conversion IS a weighted sum. I am positive, that conversion to SHADER are possible, after all the socket Material Output is of type SHADER and you can connect a RGBA socket to it. May 25 '15 at 11:09
• Are you saying you can connect an RGB socket to a shader socket and it renders something other than black? Need a screenshot to believe that... May 25 '15 at 14:32

node_socket_copy_default_value() seems to be responsible for moving data between node sockets, but it doesn't go along with the real behavior so I may be wrong, and here is some links further invistigation :