Original subtitles

Another thing that always looks cool is having some cracked bricks!

For that, a good starting point is a Voronoi Texture.

Specifically, we want to use the distance to edge mode.

This works similarly to the distance field that we set up in Chapter 2.

But here, instead of giving the distance to the boundaries of a rectangle, it gives the

distance to the boundaries of a randomized Voronoi tile.

Note that the texture is a bit stretched, and that's because by default it's using Generated

coordinates, which map to the object's bounding box.

But it doesn't matter, we want to use the offset brick coordinates, so that each brick

has a unique disconnected cracking pattern.

Now we can see that some tiles look really dark, and that's because we're using a 3D

Voronoi, which means that the tiles are actually volumes in space, and sometimes a tile can

have a boundary that is very close to our plane.

So let's switch to 2D.

Then we can add a Map Range, and reduce the max input, until we see lines of the desired

width for our cracks.

Since we want to displace the cracks inwards and keep the rest of the brick surface at

the same level, we'll want to invert the output range, so that the surface is zero, and the

cracks are at a higher value, so that when we subtract it from the displacement, only

the cracks get moved.

This pattern seems a bit too dense, so let's make the Voronoi tiles a bit bigger.

Now we can use our handy Distort2D node, to distort this texture, and make the cracks

look more natural.

Let's make the distortion a bit finer, more detailed, and more rough.

Then we can also increase the intensity a bit.

Now, we don't want every brick to be cracked, so we'll need a random value to randomly select

bricks to be cracked.

Currently, from the Random output of the Bricks group, we are using the X channel here for

the rotation.

The Z channel isn't used directly here, as we are just using it as a seed to generate

different random values over here.

But all the way at the color setup, we are actually using the Y and Z channels of the

random brick output directly.

It seems like it's time to generate another set of random values, as we've run out of

channels again.

So let's add a White Noise, and set it to 1D.

Then let's connect it to one of the original random channels.

Keep in mind that we don't want to use the Z channel, as that's already used by another

White Noise node, and we don't want to generate the same values again.

But the Y channel, for example, will work fine.

Then let's make a nice connection here, with a couple of Reroutes.

And now we have some new random channels.

This is a good moment to rework part of our setup.

The thing is that back in Chapter 9, when we randomized the brick colors, we added another

Separate XYZ node, connected to the same random output of the Bricks group, in addition to

the Separate XYZ in the beginning of the tree.

This is pretty bad practice, and becomes very difficult to maintain as the tree grows.

The issue is that with the two Separate XYZ nodes, it becomes very difficult to follow

which channels are in use, as we need to check multiple nodes at completely different parts

of the tree.

So a good rule is to only separate the channels once for each Noise node, and have the Separate

node right next to the Noise, that way we can immediately see which channels are in

use.

Since we are adding a new White Noise now anyway, this gives us the opportunity to rectify

the situation.

So let's bring this Noise node over to the color setup.

And now we can plug its output into the Separate XYZ instead of the Random output from the

Bricks group.

And let's make the path neat.

Then, just for consistency, let's replace this Separate XYZ with a Separate RGB, using

Shift+S, as the White Noise outputs a color.

Though this is not really necessary, as Separate XYZ and Separate RGB do exactly the same thing,

since colors and vectors are almost always interchangeable.

Then let's delete this floating Reroute, as we no longer need to carry this link all the

way to the other side of the tree.

And now we can see all the used channels in a single place here right next to the source

of the random vector.

Now, if we follow this link from the Y channel, making it neater along the way, we see that

it is only connected to the White Noise input, meaning that we are only using it as a seed

for new random values, but are not using it directly anywhere, So it's free to use for

the cracks setup, which is convenient, as the connection is already passing right next

to where we need.

So let's add a Reroute here, so that we can intercept this random value.

And now, with a Math node set to Less Than, we can create a binary mask of random bricks,

where the threshold represents the ratio of bricks that will be selected.

We covered this technique for selecting a random subset of bricks in more detail in

Chapter 5.

Now we can just multiply our crack mask, by the random brick mask, and only the amount

of bricks defined by the threshold will have cracks.

So far, every time we added some displacement component to the bricks, we've combined it

here, before merging with the mortar, so let's try that again, and see what happens.

So duplicating one of these nodes, setting it to subtract, since we want the cracks to

go deeper, and connecting it to our crack texture, as well as to the rest of the setup,

let's see what this does to our texture.

So let's switch to Cycles, and look at the shader output.

Well, it seems to work, as we are seeing some cracks, but let's take a closer look.

We can start seeing that there is a bit of mortar inside some of the cracks, this is

especially evident in Eevee.

And if we increase the depth of the cracks in the Map Range, which we probably want to

do anyway, we see that they get completely filled with mortar.

Actually, that makes sense, since we are computing the cracks before combining the mortar, and

any part of the bricks that is deeper than the mortar, gets filled with mortar when we

combine them.

But we don't really want this, as the bricks would have cracked after being in the wall,

so it wouldn't make sense for the cracks to be filled with mortar.

So let's fix this.

The most straight forward thing to do at this point, is to just move the subtraction to

the height map after we combine the bricks and mortar.

So let's insert it after the Maximum node, and reconnect the cracks.

Now the cracks are no longer filled with mortar, but we have a new issue.

The cracks are extending beyond the edge of the bricks and appearing in the mortar as

well.

This is because we are calculating the cracks within each tile, and the tiles extend beyond

the bricks, while the mortar is used to conveniently cover up the seam between the tiles.

But now this seam can be seen where the cracks sharply end in the middle of the mortar.

Luckily, this has an easy fix as well.

Just above the height map, we have this Greater Than node, which computes a mask of the bricks,

using the exact boundary where they meet the mortar.

So this is perfect for us to mask the cracks.

Let's simply multiply the cracks texture by this mask, which erases the parts outside

the bricks.

And if we look at the output now, we're getting exactly the effect we wanted.

And we can also check it out in Cycles, where the cracks look extra good, especially if

we bump the subdivisions up to seven.

Let's lower the subdivisions again, and switch back to Eevee.

This is a good moment to frame the nodes, and organize them a bit.

Then we can name the Frame Cracks, and give it a distinctive color.

We can actually make the tree a bit more compact, moving this Frame and reorganizing the routes.

These nodes are adding the cracks onto the displacement texture, so let's frame them

as well, and call it Crack Displacement.

Then we can copy the color over from the other Frame.

And finally, do this last bit of untangling the connections.