Combining Mapping nodes


I’m working on this procedural wood tiles material:

I would like to offset different tiles to break the continuity of the wood pattern between planks. What I’ve done, basically, is creating five Mapping nodes and mixing them using Greater Than nodes as factors. These nodes input from the same ColorRamp that divides the tiles from a Brick Texture node in five different shades of gray; thus, the Greater Than nodes go “splitting” the shades of gray from the ColorRamp two by two. For instance, for the key that is selected in the ColorRamp in the second image, which has a gray of (.2,.2,.2), matching its position in the colour ramp, we’d have a Greater Than node with a second input of .199999. Doing this sequentially with all the keys in the ColorRamp it is possible to, in theory at least, use a different offset to each shade of gray.

The mixing

The ColorRamp is connected to the first input of all Greater Than nodes

However, when I change the translation of a Mapping node nothing happens. Does someone know why this happens?



Very nice work,

1 Like

Thank you! I’ve just started to work with procedural materials :slight_smile:.

From the screenshot, and if you connect that Color ramp to the GT nodes, only the first input of the top mix node will come out. Values from the Color ramp are 0 to 1, but all your GT checks are above 2, which is always false.

1 Like

Yes! I had already noted that. I had to divide those values by 10. I’m working further on it, because it still doesn’t work. But I think I’m pretty much done! I’ll post something when finished.

one note here
this has already been done
see thread

there is one or 2 nodes setup for wood plansk

happy bl

The page does not exist or something :frowning:. Anyway, I know this has been done before. I only wanted to create my own procedural tileable wood.

Here’s what I’d suggest. You’re already using the Brick Texture to randomly color the wood tiles. Why not take advantage of those completely random colors to drive the offset as well?
Use a second Brick Texture with identical settings, but set Color1 and Color2 to white and black.

Yeah, that’s more or less what I’m already doing, ha, ha, ha. I already finished the material. Here you have it!

PS: Oh, now I see the difference between your setup and mine. I’ll give a try.

PS 2: I would like to ask… Is a colour changed somehow when connected to a vector input or viceversa? I sometimes get a little confused about that.

I am pretty certain that it is not changed and I´m not sure why there is a distinction a all. Perhaps it is just for cosmetic reasons.

If we could only ask Tom Roosendaal about it… :wink:

Could you make a brief explanation of your nodes, @cgCody?

The brick texture generates random bricks with different color values. These Values go from black to white or from 0 to 1.
He then adds these color values (which are treated like vectors) to the uv map. This means that every part of the uv map is moved to the amount of the color value.

You can observe this effect best if you set the mortar size to 0, and both colors to black. Then slowly increase the “red” portion of color 1 to full. You will see that your texture is transformed brick by brick on the x axis. That is because red is the first value in the color while x is the first value in the position vectors.

Then increase the green value of the color and you will observe the same thing in the y-axis.


Yes, I had already understood it, ha, ha, ha. The only thing that confused me was the UV Map node, since I’m using Generated UV coordinates. Here you have my final setup:

Oh, I guess that was just for quick demonstration purposes. You can of course use generated coordinates as well.

What @Lumpengnom said.

In this context,
Color | Generated | UV
R == X == U
G == Y == V
B == Z

Now If you REALLY want to get fancy, you could separate the RGB values from the brick texture and do all sorts of translating, scaling, and rotating trickery with math nodes. (Then recombine with a combineXYZ, which will satisfy the node color purists)

Another option is to use Brick-Tricks addon from LazyDodo… One of the nodes (‘uv_map_brick_wall’) produces exactly this uv map tile with cells_IDs…


The OSL source for the shaders in bricktricks is available here. I generally prototype in OSL give it’s much much faster making small adjustments in code than it is to bend a large nodegraph to your will. Once i’m happy with it, i either build the shader my self, or let oslpy do the work to have it run properly on the GPU.


Wow! It looks awesome! Just imagine how many procedural materials we could make with that :star_struck:.

I’ll definitely give it a shot, for sure! Thanks for linking it!!

Oh, @LazyDodo! Great work! You’re such a productive being to be part of an extinct species, and lazy!