Original subtitles

Now that we're adding some bigger global variation to the wall,

let's also do something along these lines with the displacement.

In Chapter 18, we offset the depth of the individual bricks,

but another cool thing we can do is offset entire rows of bricks.

For this, we're gonna need a random value per row of bricks.

So to start, let's take the brick index,

and like we saw before, if we plug it into a White Noise, we get a random value for each brick.

But if we add a Separate XYZ, we see that the Y value encodes the row index,

and is constant for all bricks within a row. So that's the perfect input for our Noise.

Let's switch it to 1D and plug in the Y channel.

Now we have a random value for each row. Let's bring this closer to our

brick displacement. And make these connections a bit nicer.

Then we can use the value to offset the rows. So let's add a Math node,

to subtract 0.5, and center the values around zero as always.

And let's make some space so that we can add another node into this offset setup.

Let's duplicate one of these additions, and plug our values in there.

Then let's also add another Math node, and set it to multiply,

to set the intensity of the displacement.

If we increase this value, we can clearly see the effect it has on the displacement texture.

So let's take a look at the shader. The rows did indeed get offset,

but we can immediately see that the rows that got pushed in, are completely covered by the mortar.

This is not really what we're looking for. It would be nice to get the mortar

to follow the offset of the rows. Let's see how we might go about doing that.

We don't want to offset the mortar using the same texture, as it is discontinuous,

and would cause very jarring steps in the mortar. We need a smooth continuous texture that gently

follows the contours of the rows. For that we'll need a texture coordinate that is not stepped like

the index. So let's take the input coordinates from before we did the brick computations.

Let's add a Reroute to bring it to a more convenient spot.

And adding a White Noise, we get a noisy gray surface. This is because for each sample we're

getting a completely random value, which when averaged out over multiple samples,

converges to a value of 0.5, which is the average of all the possible values.

This is really not going to help us, and without having steps in the texture,

there is no way to get usable values from the White Noise.

So with Shift+s, let's replace it with it's continuous counterpart, the Noise node.

Again, we'll want to add a Separate XYZ node, to isolate the channels, and set the Noise to 1D.

Now, connecting the Y channel, we get the continuous variation we wanted.

This is a bit too small, as we don't want the texture

to vary much within the height of a single row, so let's make it bigger.

Now, if we bring this Noise to our setup, and compare it with the White Noise,

we see that they are completely different, and don't follow the same pattern at all.

This is to be expected, as they are two completely different noise algorithms, but

what we are looking for is basically two versions of the same noise, one continuous, and the other

discrete. So that we have the same pattern of highs and lows for the bricks and mortar.

For that we'll have to use the same noise algorithm in both cases. So let's replace

this White Noise by a plain Noise as well. And then we'll want to set it to 1D as well.

Now we're seeing a single gray color, and even changing the scale we still get the same thing.

This is because due to the algorithm used to generate the noise, it will always have the

same value at integer multiples of the scale, and since the input coordinates only contain integers,

as they were floored, setting any integer scale will cause us to only get this gray.

So let's set this to another value. And now we see that the texture is actually there. Let's reduce

the detail, as we don't want small variation, and that will also give us a wider range to work with.

Now, if we set the same parameters for the other Noise, and compare the two, we see

that they still don't match up. This means that beside the coordinates on the top being floored,

there must be another difference between the texture coordinates we are feeding them.

Let's take a look in the Bricks group to find out. Here is the Floor that we're using for

the index. And if we follow the links to see where the vector is coming from,

we see that there are two operations being applied to the coordinates before we Floor them.

The brick offset is just randomly offsetting the rows horizontally,

so it doesn't affect the Y channel, but this multiply is scaling the Y channel.

This explains the difference we were seeing, as we used the coordinates without this scaling.

So let's expose these coordinates with the scaling applied, but without the Floor. Let's call this

output something like BaseCoords, as we use it as the basis for all the other brick computations.

Now, tabbing out, we can plug this instead of the unscaled coordinates.

Now, if we compare the two, it looks like they are matching almost perfectly. The

only thing is that the texture seems to move up slightly when we switch to the discrete version.

If we take a look at the input values themselves, we see that this behavior is

present there as well. The discrete coordinates seem to be a bit higher than the continuous ones.

If we zoom in closer, we can analyze why that is. By definition, the Floor operation

gives the first integer value below any value. So that means that within a row,

we are getting the lowest value in that row, which is the value all the way at the bottom of the row.

This explains why the texture seems to move up,

as it effectively extends the lowest value until the top. But to fix this,

all we need to do is add a Math node, and add 0.5 to the discrete values. That way we are

offsetting them so that they have the value from the middle of the range instead of the bottom.

Now, if we compare the values, they don't seem to move anymore, the only difference is the

discontinuity in the floored version. And looking at the Noise outputs, we see the same thing.

Let's organize the nodes a bit. And let's duplicate the offset and scaling setup,

so that we have matching outputs from both Noises.

Now we can take this smooth row offset we calculated, and use it to displace the mortar

over here. As usual, we can just offset the values by adding the offset to the mortar height map.

Let's shift these nodes a bit, and create a nice path for this connection.

And then we can plug in the actual row offset.

If we take a look at this output, it's clear how this is affecting the mortar depth values.

Then, if we switch to Cycles, and look at the shader output,

the mortar is no longer overlapping a bunch of the bricks. But if we look from the side,

we see that the rows are still being offset, and now the mortar follows along nicely.

We can even increase the scaling values a lot, without getting undesirable behavior

from the mortar. But ten might be a bit too much, so let's lower it a bit.

And then let's just frame the new nodes, and call it Brick Row Offset.

Then let's move everything into place, and tidy up these connections.