All language subtitles for 02 NodesAndNodeTreeEvaluation

Now that we know the general gist of path
tracing, let's take a look at how the node

tree evaluation happens.

Keep in mind that the node tree is evaluated
each time a ray hits a mesh.

First we need to understand what a node is.

A node is a basically just a function.

It takes some inputs, processes them in some
way, and gives some outputs.

There are some exceptional nodes that we'll
look at, but for the most part that's it.

The key point to remember is that except for
some special nodes, the output of a node depends

only on its inputs.

Given the same inputs, it will always give
the exact same output.

So for instance, here we have a Math node.

In the Add mode, it takes two inputs and generates
one output.

The output is simply the result of adding
the two inputs together.

Here, it should be pretty obvious that given
the same inputs we always get the same output,

but we'll look at some less obvious examples
later.

Let's take a look at a simple node tree.

Here we are adding the values one and two
together.

Then, the output, which should be three is
being fed into a multiplication, and multiplied

with .5, resulting in 1.5.

Then we are making a color, using the output
of the addition for the Red channel, and the

output of the multiplication for the green
and blue channels.

So at this point red should be three, and
green and blue should be 1.5.

This then goes into an Emission shader.

A shader is a somewhat special type of node,
which determines the surface behavior, so

basically a shader decides what happens to
a ray that hits the surface.

For now it's enough to know that an Emission
shader causes the ray to stop and simply return

its color value, without bouncing further.

So an Emission behaves as a light source,
just as if the ray had reached an actual lamp.

Lastly the shader is fed into the Surface
socket of the Material Output.

The Material Output is what tells the render
engine what to actually compute.

The render engine will look for the Material
Output node, and then evaluate all the nodes

connected to it.

The Surface socket just tells the render engine
that we want to use this shader for the actual

surface of the object, while the Volume socket
is for shaders that are evaluated inside an

object's volume, which is useful for things
like clouds and smoke, but we won't be looking

into those in this course.

Now, since we are using only fixed values
and no variable inputs in our computation,

we should get the same result on the whole
object, and since we're using an Emission

shader, the rendered color should directly
reflect the result of our computation.

I applied this material to a cube, so let's
take a look at the result.

Indeed, we got a single color, and we can't
even differentiate the faces of the cube,

as no external lighting is being applied,
since all rays coming from the camera terminate

immediately once they hit the cube.

Now to check that the color is actually what
we computed, we can right click on the cube.

Then at the very bottom, Blender gives us
some information about the pixel we are clicking

on, and here we see that indeed the red value
is three, and the blue and green values are

both 1.5.

To the right, we also see different values
for red green and blue.

Those are the values after color management
is applied, as indicated by the CM.

We'll look at color management in a separate
chapter.

For now, we are only interested in the raw
values computed directly from our shader.

Going back to the node tree, we've looked
at it from left to right, as that's the direction

of data flow.

If we are only looking at a set of sequential
operations, this makes sense, but when we

start looking at more complex trees, with
several branches, it's difficult to know on

which branch to start, so it actually makes
more sense to read from right to left, as

every tree ends with a Material Output.

So in this case we would look at the output,
and see that it's using an Emission shader,

that's already a lot of useful information,
and then we can follow the connections to

see where the color is coming from, and so
on.

This gives us the most important information
first, and let's us make informed decisions

on which branches of the tree to inspect next.

I've mentioned a few times that there are
some special nodes, so let's look at those.

The special nodes are those in the input and
output categories.

From the output category we already talked
about the Material Output node, which must

exist in every material, and it's the only
output node that we'll cover in this course.

The output nodes are special because they
are the only nodes that don't have any output

sockets, and they don't actually process anything,
they just tell the render engine where to

look to find the relevant parts of our tree
and start the node tree evaluation.

But more interesting than the output nodes,
are the input nodes.

For the most part, these nodes also don't
do any processing, though there are some exceptions,

and most of them don't have any input sockets.

We already looked at the simplest input node,
the Value node, which just lets us input values

into our tree.

These are pretty boring, and mostly unnecessary,
as we can just type values in the other nodes

directly, but they are handy when we need
to input the same value into multiple nodes.

The really interesting thing about input nodes,
which was hinted at in the path tracing basics

video, is that many of them allow us to access
crucial information about the object, mesh,

and ray that are being processed, as well
as some other more specialized things like

hair and particle meta-data, but we won't
be looking at those in this course.

Here are some of the most common input nodes.

The Geometry node gives us a bunch of information
about the mesh, like the world space coordinate

at which the current ray hit the mesh, the
normal at that same point, and whether the

face is pointing towards the ray direction
or away form it.

The Texture Coordinate node gives us things
like the UV coordinates of the point at which

the current ray hit the mesh, as well as other
useful coordinates.

We'll look more at these in a dedicated chapter.

The Light Path node gives us some information
about the current ray, like if it came directly

from the camera, or if it got reflected or
refracted in different ways before reaching

the current point.

It also tells us how many times the the path
bounced to reach this point, and how far it

traveled through space.

Note that I kept saying that things refer
to the point at which the current ray hit

the mesh.

That's because it's important to understand
that (with very few exceptions) whenever the

node tree is evaluated, it doesn't have any
knowledge of the surroundings.

The node tree is evaluated each time a ray
hits a surface, and it only has information

about that single point in space.

When a ray hits a surface, all these different
attributes are computed for that one point,

and we can access them with the input nodes.

The input nodes are also the only nodes that
depend on data from the scene, and therefore

are the only nodes that can give different
outputs when given the same inputs, in fact,

these nodes we are looking at don't take any
input at all.

Every single other node that is not an input
or output node takes some kind of input, and

processes it into some kind of output, without
any awareness of the scene context.

Given a constant input, they will always give
the same output for every ray, everywhere,

every time.

Now, if you've done a bit of procedural texturing
in Blender before, this last point may seem

to be false, as there is a whole class of
nodes that doesn't seem output the same values

everywhere.

I'm talking about the texture nodes.

For instance, here we have a Noise Texture
node, with a certain set of inputs, and we

don't seem to be feeding it any input values
that vary throughout space, yet it clearly

does not output the same color everywhere.

It's as if it is aware of where it is in space.

That is because it is actually being fed spacial
coordinates.

For all the texture nodes, when we leave the
Vector input disconnected, Blender sneakily

feeds them Generated texture coordinates,
except for image textures, which get UV coordinates

instead.

Blender does this to make our lives easier,
as we usually do want textures to vary throughout

space, and it would probably seem weird if
the default output of a texture node was just

a solid color.

That means that this setup with only the Noise
node, is exactly equivalent to this one where

we explicitly feed it Generated texture coordinates.

And if we look at the Generated coordinates
themselves, they do indeed vary throughout

space.

So it turns out that the variable data in
the texture nodes is actually the same that

comes from an input node, it's just that it's
being passed in implicitly.

To show that when feeding constant data into
a texture node, we always get a consistent

output, just like with any other normal node,
we can actually feed a constant vector to

the Noise, and then we see that indeed it
outputs the same color every time.

This consistent behavior of the nodes is a
really important point to understand, in order

to master procedural texturing.