All language subtitles for 03 DataTypesAndConversions

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.