Original subtitles

Nodes can process data of different types, and it's important to understand what they

mean, and how they relate to each other.

In Blender, types are indicated by the node socket colors.

So far, four data types are supported in Blender shading trees.

These are the Value type, the Vector type, the Color type, and the Shader type.

Here I'm showing an example of each data type, except for the Shader type, which is a bit

special.

The value type has a gray socket, and it simply holds a single numeric value.

This can be practically any value you can think of.

Values don't have a particular meaning or unit, you can interpret them as whatever you

want for any particular application, though some nodes will give a specific meaning to

values they take as input.

Vectors might sound complicated, but really they are just like the Value type, except

that it's a set of three values.

They are a convenient and efficient way to operate on three values at once.

These values can represent whatever you want as well, and we can do most of the same mathematical

operations with Vectors as we can with Values, as well as some special Vector-specific operations.

The reason Vectors contain three values is that they are most often used to encode 3D

coordinates or directions.

So the convention is that each value represents the same type of data but each for a different

axis, X, Y, and Z.

Though you can use vectors to encode just about anything you want, for instance, colors!

This brings us the Color type.

Colors are essentially the same as Vectors, they are just a set of three values.

And they behave exactly the same in almost every way, so in practice they are pretty

much interchangeable.

By convention, the color channels represent the red, green, and blue, but just like with

Vectors you could use them to represent anything you want.

This is neat, as it allows us to use Vector operations and Color operations interchangeably.

Now, Shaders are a bit more complicated.

Shaders don't carry any specific value, rather, just like a node, the shader data itself is

a function.

You can think of a shader as a description of what happens to a ray that hits the surface

of an object.

It basically carries information about how glossy, or transparent, or emissive the surface

is, as well as the surface color, and other information.

So Shaders are quite different from the other data types, which means they can't be readily

converted like the other types.

Most of the types can be converted into each other.

For instance, if we take a Value type, and plug it into a Color, the value gets fed into

all three Color channels.

This is neat as it allows us to visualize the value, by outputting it as a color.

This is only useful for a limited range of values, as negative colors always show up

black, and values above one either get clipped of become hard to distinguish, depending on

the color settings, but this is still a fantastic diagnostic tool.

There are also other cases where we might want to plug a value into a color socket,

like if we want to multiply all color channels by the same value.

Now, if we swap this Color socket for a Vector socket, exactly the same thing happens, feeding

a Value into a Vector makes all three channels take that value.

This is again useful whenever we want to drive all three channels with the same value at

once.

If we feed a Color into a Vector, absolutely no conversion happens, and the Vector just

takes the three channel values, since they use exactly the same data representation.

And as you'd expect, the same goes if we swap them around.

So we can always feed Colors into Vectors and back, without any conversion taking place.

Just like with Values, this is also a really useful diagnostic tool, which allows us to

visually inspect our vectors, as the X, Y, and Z channels get mapped directly onto the

R, G, and B channels, respectively

Now, if we feed a Vector into a Value, we must lose some data, as the Value can't hold

all three channels.

So what happens is that the three channels get averaged.

This is of limited use, and we'll rarely have a case where we actually want to use the average

of the Vector channels as a Value, and in most cases, when we need to extract data from

a Vector we'll be looking at other methods that we'll explore in a bit.

Now if we plug a Color into a Value, we find the only difference between Colors and Vectors.

Instead of averaging the channels, the relative luminance gets calculated.

So the distinction between Vectors and Colors, is purely in how the channels get interpreted

in this one situation, so literally the only time there is any difference in the behavior

of Vectors and Colors is when directly converting them into a Value.

This distinction is because we would usually interpret colors as a visual thing, and luminance

makes sense here, as it represents the perceived brightness of the colors.

The relative luminance is calculated as a weighted sum of the three channels, this is

very similar to averaging, except that the different channels have different amounts

of influence over the result.

This is because we don't perceive all the colors as having the same brightness.

For instance, let's take the three additive primaries, red, green, and blue.

Here we see each in it's pure form, and at maximum intensity.

If we look at the channel values, we see that each has a single channel with a value of

one, and two channels with a zero.

If these were vectors, they would all average to the same value of one third.

But these colors don't look like they have the same brightness.

Our eyes are tuned such that green looks the brightest, and blue looks the darkest, and

the relative luminance was designed to reflect our perception.

So when we plug each color into a value, we get a different result.

This the same kind of behavior as you'd usually see when turning a color into black and white.

Note that while this behavior makes sense for colors, in practice, we'll almost never

want to actually plug a color directly into a value like that.

This is really only if we want to interpret the color visually as a grayscale brightness.

But with procedural shaders, in most cases, we're using colors from noise textures to

drive non-color related things, like displacement, in which case, plugging the color directly

into a value is almost certainly not actually what we wanted.

We'll look at some alternatives in a bit.

Just keep in mind that if you see a color plugged into a value, nine times out of ten

it was a mistake.

Finally, we get to the Shader type again.

This type cannot be converted into any of the other types.

It doesn't carry a value, so there is no reasonable conversion.

Though there is one thing that is kinda like converting a shader into a color, which is

Eevee's Shader to RGB node, but it doesn't really convert the shader itself into a color,

but rather the rendered result.

But this node is Eevee-specific and we won't be using it in this course.

Now, while we can't plug a shader into any of the other socket types, we can plug other

types into a shader socket.

If we plug a color into the shader, Blender just pretends that there is an Emission shader

in between.

So the color basically just gets output by the object directly.

If we plug a Vector into the shader, the same thing happens, the Vector just gets fed into

this imaginary Emission shader's color socket.

And the same thing if we plug a Value into a Shader socket.

There is an imaginary Emission shader, and the Value to Color conversion rules apply

to the Value being fed into the Emission color, which just means all three channels get the

same value.

Now let's take a look at some actual nodes.

If we want to input data directly into our node tree, we can do that with several nodes.

To input single values, there is the very simple Value Input node, which we already

looked at in the shader evaluation chapter.

For vectors, there is no input node, but we can use the Combine XYZ conversion node for

this purpose.

Here we can input three values, which become the three channels of a vector.

These three inputs also have sockets, which is convenient when we want to construct a

vector from values coming from other nodes.

For colors, there is the RGB input node, which has a convenient color picker.

There are also two relevant conversion nodes.

The Combine RGB node works exactly like the Combine XYZ node and just maps the three values

to the tree channels.

In fact, these two nodes are interchangeable.

The only difference is in the output socket type, and the channel labels, but as we already

covered, Vectors and Colors are perfectly compatible.

On the other hand, the Combine HSV node is a bit of a different story.

Don't let the apparent similarity fool you, this node doesn't just combine the input values

into the three output channels.

Rather, it actually does a conversion operation, namely, it converts from HSV to RGB, and those

resulting RGB values are what we get in the output channels.

When looking at different nodes, we might see inputs of different data types represented

in multiple ways.

For instance, a Value input can be shown as a simple text field, or a slider, or as the

slightly sneaky angle field.

The thing about angle fields, indicated by the degree symbol after the number, is that

they don't actually carry the value shown in the field.

Internally angles are processed in radians, and only converted into degrees for display

in the field.

Similarly, when we manually type in a value, it gets converted and stored in radians.

This gets confusing when we plug in a value coming from another node, as the value is

not converted, and simply interpreted as radians.

That's because the conversion happens at the input field level, and not at the socket level.

It's still just a value socket, so plugging a value in there doesn't trigger any conversion.

The degree conversion is just a UI feature for convenience.

Meanwhile a vector can be shown as a bare socket, or have three numeric input fields,

or even this weird shaded sphere.

But we don't have to worry about these input modes, each one is just to make inputting

data more convenient depending on the specific application, but they still carry the same

data.

The only thing that matters when connecting to a socket, is the socket color.

It doesn't matter what the input fields look like, they will all do the same thing.

Now as for the conversions, as we covered, plugging a value into a vector just replicates

the value into all the channels, which is exactly the same as plugging the same value

into all three sockets of a Combine XYZ node.

The advantage of the Combine XYZ node, is that we can build the vector from different

values if we need to.

Similarly, plugging a Value into a Color is identical to plugging the same value into

all channels of a Combine RGB node, and the same advantages as the Vector version apply

here.

Another useful conversion is using the value to drive a specific characteristic of a Color,

such as the hue, by using a Combine HSV node.

Now, plugging a Vector into a Value will average the channels, but if instead we want to extract

the value from a specific channel, without any modification, we can use a Separate XYZ

node.

Another conversion that is often useful, is extracting a specific characteristic of a

vector, like the length, also known as magnitude, which we can calculate with the Vector Math

node, but more on that in another chapter.

And finally, plugging a Color into a Value, behaves identically to the RGB to BW node,

which calculates the relative luminance.

We can also extract a specific channel, like with Vectors, by using the Separate RGB node,

which again, is interchangeable with the Separate XYZ node, as their only difference is in the

names of the labels, while they are functionally identical.

Lastly, we can also extract a specific characteristic of the color, such as the saturation, by using

a Separate HSV node.

That wraps up our overview of data handling, and should give you a pretty good idea of

the different types of data, and what kinds of conversions are available.