Original subtitles

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.