All language subtitles for 05 WorkingWithTheNodeGraph

Let's have a basic look at how we can work
with the node editor.

This will be a very brief introduction, and
for the rest, I'll mention important shortcuts

throughout the course.

You can also see all the keys I'm pressing
in the bottom right corner, in case you want

to know some shortcut that I didn't mention.

The result of this node tree is not important,
it's just a random setup to demonstrate how

we can interact with the node editor.

The node editor supports the same basic keys
as the 3D viewport.

We can add nodes with Shift+A. This menu has
all the nodes organized in categories, and

also gives us a convenient search feature,
for when we want to quickly add a node without

knowing which category it belongs to.

We can also delete nodes with the standard
X key, and if we want to delete a node, while

preserving the connection that goes through
it, we can use Ctrl+X.

The standard G, R, and S transformation keys
are also all supported.

Since we enabled the Node Wrangler add-on
in the Setup Chapter, we can look at the output

of a specific node by Ctrl+Shift+clicking
it.

And if we do that several times, it will cycle
through its outputs.

One very useful feature for organizing the
node tree, is the Reroute, which we can create

by Shift+right clicking and dragging across
a node link.

This allows us to shape the path of our node
links.

If we do this while dragging across several
links that are connected to the same socket,

it will group them, allowing us to have fewer
links crossing all over our node tree.

A good tip when organizing the node links,
is to avoid almost parallel links crossing

over each other.

This makes it very hard to see which link
goes to where.

Here we could avoid this crossing altogether,
but when a crossing is inevitable, it's preferable

to have links crossing at more perpendicular
angles, which makes the crossing more obvious,

and therefore easier to follow.

Also avoid links that cross over a socket,
as it can make it seem like its connected

to the socket, when it's not.

Generally, I would just avoid having connections
crossing over nodes altogether.

Another thing that is hard to read, is having
a link connected to a socket at a very vertical

angle.

This can make it hard to see which socket
the link is connected to, so it can be worth

adding some Reroutes, just to make it more
readable.

These tips are not really critical for the
end result of your shaders, but they can make

your life much easier when working with large
and complex node trees.

The extra effort will pay off by making your
work much faster down the line.

Frames are another useful organizational tool.

We can frame the selected nodes by pressing
Ctrl+J. This allows use to have a visual indication

of which nodes are related to a specific part
of the shader.

Dragging nodes within the Frame automatically
makes it readjust its size, and dragging the

Frame itself also drags all the nodes inside.

We can always add nodes to a Frame simply
by dragging them in, and we can remove them

from a Frame with Alt+P, just like unparenting
objects.

We can also rename a Frame with F2, and in
fact, we can use F2 to rename any node.

And in the Frame properties, we can enable
color, to add custom color coding.

Finally, we can group nodes, with Ctrl+G.

This puts them in a sort of sub-tree.

We can connect any socket inside the group
to the group inputs or outputs.

And we can name them in the properties panel.

When we exit the sub-tree, by pressing tab,
we see that in the main tree, it is represented

as a single node, and all the inputs and outputs
that we connected are available as sockets.

We can also rename the group in the name field.

Groups are very useful when we want to hide
a section of the tree into its own module,

but especially when we want to use the same
functionality several times.

Conveniently, the node group appears in the
add menu, in the group section.

So we can add several instances of the group
to our shader.

Note that each instance references the same
sub-tree, so if we tab into one of them, and

change something, the change is reflected
on all instances of the node group.

But if we want to make a variation of a node
group, we can always duplicate the sub-tree

by pressing the data-block counter, just like
with other data-blocks in Blender.

This will make that instance of the node group
a unique copy.

To demonstrate the importance of the these
organization practices, here is roughly what

our node tree should look like by the end
of this course.

It has clearly labeled sections, readable
node links, and groups for repeated snippets.

Meanwhile, the very same node tree would look
like this, if we hadn't taken care of any

of these things.

Basically, it's a mess, and it's much harder
to follow, or to find anything in it.

But don't worry if your node tree looks more
like this version while you're working.

It's totally normal to get in the flow and
start adding things while neglecting the layout.

Nobody can keep a node tree neat at all times,
so don't feel bad, just remember to periodically

take some time to reorganize your tree.

Also note that throughout this course, we
add more and more things, and they all seem

to magically fall into convenient places.

This is not generally how it goes, and I also
don't have any superhuman node organization

skills, that's just because I'm working off
of a reference tree that I already prepared

and cleaned up beforehand.

When implementing your own shaders, you don't
know all the nodes that you'll add beforehand,

so don't be discouraged if you have to reshuffle
your nodes around from time to time, to keep

your tree in good shape.