Ashlar wall builder script

Below are two screen shots of a wall builder script’s panel. And below that is a screen shot of a wall rendered with the settings shown.

The upper SS shows the builder in standby mode. To build a wall begin by entering a name in the provided field, then click the [Define a new ashlar wall.] button. The Panel expands as shown in the lower SS. Below the name field is a list box from which one can select a material. At present “AshlarLimestone 1” is coded-in about line 505 of and which script must be manually run by pressing the [Run Script] button. This script depends on materials that have 4 inputs named, Texture, Hue, Saturation, and Roughness, The first three of these parameters are optimized for a value range of 0.0 to 1.0 but may have uses out side that range. The last parameter, Roughness must be kept in that range or something bad may happen (fatal exception etc.) if you go out side it. Ntft Roughness should affect the material so that at 0.0 the material is as simplified as practical so that the rendered material is optimized for producing embossed images suited to making bump maps.

Third item is a list box labeled Offsets Start Row. It has three options, None, Top Row and Second Row. Selecting Top Row offsets the blocks by their depth, allowing two walls with complementary offsets to form perfectly joined right angles. FillLeft, when checked fills the offsets on the left and contrawise FillRight fills offsets on the right.
Jitter specifies a range of absolute dimensional error. I don’t recall what the units are off hand :frowning: But 0.8 works well with a bevel of 0.01

Bevel sets the bevel width. It’s units are kinda like alcoholic proof: 0.02 Width Units evaluates to 1% of the width of the shortest block edge. Bevels have 7 facets coded in. Search for “mod.segments = 7”

Roughness has been explained and Bump Depth is reserved for future use.

Exact wall size is exactly that.

Approximate block size: Every course contains a integral number blocks of the same size. So the blocks are sized to fit that requirement while being as close to the approximate block size as that allows. If there is an offset then there will be gaps or fractional blocks for those gaps as specified by the FillLeft and FillRight check boxes described above.

Next comes three groups of four properties. The groups are labeled, ‘Texture…’, ‘Hue…’, and ‘Saturation…’ The four associated properties describe a “probability distribution of values” for each of the correspondingly named stone material properties. ‘Texture…’, etc… Below the label, the three grouped properties, ‘Low…’, ‘Mode…’, and ‘High…’, describe a triangular distribution of (randomly selected) values. If you are unfamiliar with this distribution, try this: The math is given in simplified algebraic expressions, and the graphics explain it better than a 1000 words and half that many equations.
The fourth parameter pans/segues between the specified triangular distribution and uniform distribution.
This is very much a work in progress though it will not have much automation at all. It’s really focused on being an aleatory brush with which to paint walls artfully. It has a way to go to achieve that and deficiencies are in both the stone materials and the script.

Worth noting, in the present implementation a unique material must be created for every block. Makes the materials list a real pain in the butt. That may or may not change in future versions. The present version represents phase one. When I get to the point that I can’t do without it I will extend the script to UV map the blocks, create bump and spec maps and bake the blocks. That feels like a tall order and if done will be done in parts.

This is my first script and first Python code and I’m a Blender noob. Been doing pure OOP so long I’m a bit flummoxed by Pythons half classedness. I’m sure I’ll get over it. So far I think the best clue I’ve picked up is: “In OOP the class is the basic unit of organization. In Python it is the Module.” In any case I’m writing this little module with no idea as to how it should actually be organized. Summing this up, if you see something that looks strangely stupid, it probably is and I would benefit from hearing about it.


Someone asked what an Ashlar wall was:


I’ve created a graphic to illustrate the effect of the Peak property on the triangular distribution…

Variable block widths and row heights options have been added. Both maintain structural plausibility. At the bottom a bug in the offsets algorithm illustrates structural implausibility Circular curvature is on my to do list.

Well done, thoughtful implementation. I can’t comment on the code, but the idea and results are excellent so far.

looking nice
is there a link or later on may be ?

happy bl

I will post access to the file when ‘Circular’ is implemented and two bugs are exterminated. Then will remain to do for this first phase, a script to join walls and issues with texture mapping.


like that expression
bugs are exterminated

your a bug exterminator now!

i will call you if i have bugs to exterminate !LOL


Just a suggestion on the materials: sometimes it is almost impossible to tell a block from it’s neighbor when they are from the same quarry. But there are some differences which must be there so the wall doesn’t look fake and CGish. So, add a parameter called “Number of unique materials” create that many using the constraints, then assign these materials randomly to blocks in the wall, rather than create a unique material for each block. The script user could then determine how many materials to use to get the level of realism they desire. You might also add a ‘seed’ parameter for the random assignment routine, so different material layouts could be generated.

Less pure but more pragmatic. At this point I feel that would be premature optimization. But soon after the first phase is completed and stable I will do that or something very much like it. I have issues with mapping of procedural textures to resolve first, however.

In any case, much thanks for the ideas.

Should have time to complete the circular walls this week. I prefer self documenting code augmented with embedded images. As that isn’t possible here with python I’m adding a doc for the only non-obvious part of the code. The radius the user specifies is from the center of the wall’s circle to the center of a trapezoidal block in the wall, while the width of the convex (wall) side of the block is a chord of the circle that would encompass the edges of the block.


This is damn impressive, but why would you want to create all that geometry when image textures can produce the same thing with nearly zero geometry? I’m not being contradictory. I honestly want to know the answer to the question.

Partly because artistic tools built on
parameterizable stochastic processes appeal to me. Partly because I
have a taste for art that is unified on multiple levels of
abstraction; by using only procedural textures the entire image is
closer to being a projection of a purely mathematical expression. That is
also a constraint, and I like creating within technical bounds. Also,
I’m new to blender and am hoping that multi-res baking can be done in
a way to finesse the geometry issue.

Oh! And the building I’m building this for
has to come down in an earth quake. LOL

I love math too so I get that. I’m considering doing something with Phi and the golden spiral. Its in the mental render stage so far. That is in my head not using Mental Ray. lol

The circular curved wall code is complete. It does not allow for random block widths, otherwise it has
all the features of flat walls. RickyBlender gets credit for prompting me to add curved walls. Now
back to materials.