- Add low amplitude low frequency noise to the driving coordinates to uneven the lay.
- Those coords to drive initial mortarless (important) brick which is fed into a noise 42.5, 0, 42.5 node - this will give you some random colors which can be enhanced with a contrast node. Separate this into RGB and HSV and you have 6 random outputs you can manipulate further, as well as the full color itself which you can modify coordinates and normals with.
- Two more brick nodes - one with mortar whose color doesn’t matter, and one without mortar whose color is black to white. This is also fed into its own noise generator, similar settings as above. These two can have variation in brick settings where the inputs are driven with the various random outputs from the first one (such as mortar thickness and slope). Driving brick width from randomized values can be done, but it’s difficult to find a sweet spot where the randomization doesn’t cause too short bricks.
- Use the randomized output from the first one to lookup texture coordinates from a very high detail texture of a rock/stone (seamless, no mortar, preferably no directional information such as in wood). If nondirectional, you can rotate the texture lookup (need to make a rotate.z nodegroup) individually for each stone. I also prefer to scale (sometimes even skew) texture coordinates individually per axis. If you make nodegroups to do this, you can even feed it some noise. The main idea here is to have a brick wall that doesn’t have obvious repeats. The color info from the random can be used to modulate the color and intensity of the actual texture.
This is difficult stuff, hard to keep track of due to complexity, and hard to get “right”. There is also bricks&tricks, addon or nodegroup form, which may help you out if you don’t want to setup everything manually. I don’t think I ever chained them together though, to create random outputs that are used for the next ones inputs.
But yeah, my pet hate for the current brick generator is the way to ordered look. But at least with the mortar gradient it is fully usable.
If you want to control lay inaccuracy using normals, you have to create a node group that lets you convert any random color into a normal modification, in such a way that there is little chance to “overmodify the normal”, causing black artefacts when previewed on a sharp glossy node. The safest bet is obviously displacement (you have to convert the normal into a greyscale gradient), which also gives much better mortar, but for long walls I find this waaay to expensive wrt memory usage.
But even this hybrid approach - using procedurals to modify coordinate lookup and color changes to an image texture, to me doesn’t produce extremely good results. Although this is for a basic tile, this post may help you get started with the thought process.
This takes ages to setup in Cycles, especially since it is completely lacking utility nodes and you have to create your own node groups for basically everything. For something as complex as uneven bricks, I’m guessing Eevee probably can’t handle it.
Edit:
- Or just use the bricks in the post above mine. That looks pretty amazing - and that’s not something I say often
- Or use image textures. Bricks are some of the most frequently made and shared.
- Or create texture yourself using a proper design tool.
- Or model the wall and bake out the result.
My approach above may teach you how to do procedurals, but it also by far the most time consuming one, which may even stagnate your project 