# Erindale Feedback on Procedural Wall

I (Dalai) asked Erindale to try to build a procedural wall inspired in the work by Marc Chevry. The goal was to identify any showstoppers and potential improvements for geometry nodes.

Here is the feedback:

Not 100% on what the curve tools Hans is working on covers but for this it would have been great to get the curve into the tree early and calculate its length to use for the wall length and then obviously at the end to conform the straight wall back to the curve similar to the curve modifier.
For me the ideal process would have been to make it flat and then extrude individual faces by a random amount. I think this would have made the booleans more robust as well.

I used my straight brick wall node and just removed random points from the top row and randomised the Y scale for bricks. That worked okay but it slowed everything up with the next lot of operations because it was having to make the bricks all real to get the uneven row heights. I was initially using a boolean straight after making the instances to trim the ends of the wall straight (because of the half brick offset between rows) but I worked out later that having any sort of operations after a boolean is practically unworkable. The performance just not production-ready with booleans at the moment. Luckily I was able to stick it at the end with the arch boolean without any issues in this case.

The arches themselves I just instanced a cylinder along the bottom using a narrow grid and a poisson disk distribution taking the max cylinder width for the minimum distance to prevent intersections. I would have prefered to interpolate curves from some generated points to get the arch and then mesh it for the boolean and in parallel, naturally parameterise for even space points and extrude it outwards and then extrude individual faces and bevel for the arched stone work. I had to instance bricks on the cyclinder boolean object which works from a distance but thereâ€™s very little control there and a lot of intersections.

I couldnâ€™t do the fancy castellations on the top as in the reference without more specific edit mode operations (extrude / inset / selections etc) and also Ivy generation is something I wouldnâ€™t like to try without loops and attribute processors / script nodes.
I ended up not needing the UV map definition steps at the end because itâ€™s the kind of thing you can totally get away with procedural textures or triplanar mapping image textures

So the wishlist:

• Boolean performance needs to be 30x better. With the boolean node earlier in the tree (just after the first point instance of the cubes) calculating any changes to the tree was taking 20-30 seconds.
• More analytics nodes - face size / edge length / angle / curve length / face centre etc
• Solidify / Extrude Separate Faces with the ability to use an attribute containing a value per face to define extrusion depth which I think would need -
• Attribute Randomize working with other domains
• Attribute Vector Rotate node - A lot of people donâ€™t know how to rotate a texture when itâ€™s not using a UV map and a lot of cases like this wonâ€™t have UV maps
• Loop nodes - lots of use cases for this like recursive block subdivisions. The reference has random height divisions within blocks which I wasnâ€™t able to imitate also could be used for packing different sized objects like the arches rather than only having 1 constant size to prevent intersections.
• Meshing points. Iâ€™ve seen the convex hull node task which is ace but we could really use some more deliberate meshing options as well. Iâ€™m not sure how that would work with the attribute workflow though. In Sverchok you have the UV connection node which will allow you to build surfaces based on list levels. With an attribute, if everythingâ€™s at the same level, how can it discern rows and columns?
• Simple operations like extruding by a LocRotScale matrix and into that comes point / edge / face selection
• Bevel node would be really handy too beveling but also creating support loops for subdiv

I know a bunch of that is in the works or planned but that was just what I came up against in this exercise!

45 Likes

Are there any plans to sort the Attribute names Alphabetically as its easier to read and maybe display 15 in the list ( Its 10 now ). Right now not sure its random / by creation time ? It takes a while to select an Attribute or you have to type it.

Hi, there are no specific plans for that. The result now depends on the fuzzy search own criteria.

I 100% agree on that the boolean is far too slow to be useable at the time being.

I cant even use it for simple semi-destructive modeling models beacause I cant see that real time feedback when moving my objects around.

Regarding Solidify/extrude I think it would be nice if we could get some â€śinsetâ€ť node to also get control over the X/Y offset (relative to the affected face).

Also I think this is a really nice use-case example <3

Would love to use geometry nodes for this kind of stuff myself once it got some mofe features packed in it

Two items from the wishlist got my attention as just recently Iâ€™ve been thinking about 2D boolean node(or having 2D mode on Boolean node). My point is that in some cases, instead of doing boolean operation on 3D objects, it could be computationally faster as well as more user friendly to do boolean in 2D(on planar mesh like plane or circle) and then extrude/solidify the result, but there are also other use cases when 2D boolean would come handy.
In my addon Iâ€™m using Shapely library to do 2D boolean(Sverchokâ€™s using it for this cause as well), mainly because Iâ€™m processing vector geo-data, typical use case is cutting road polygon through forest polygon. Something similar is showcased in this video,

but here I had to use 3D boolean of course(you can see it lagging).

In Boolean Improvements - #113 by Howard_Trickey Howard mentioned that â€śThe code for 2D intersection is thereâ€ť, maybe it could be a task for someone from community

3 Likes

2d Intersections would be very welcome. We should also have access to the old â€śfastâ€ť boolean algorithm in GN.

8 Likes

Thatâ€™s a great idea pretty sure itâ€™s orders of magnitude faster and come to think of it, most booleans I do could as well be 2D

1 Like

For procedural walls, a way to control material index would be usefull.
Also probably some uv unwraps methods.
Select by distance from surface too, but with signed distance, so you are able to select up or down.

You may achieve 2d boolean by 1st cutting geometry like â€ścookie cutterâ€ť (knife project). But at this time, knife project still is not precise enougth and does not always properly cut all geometry.
So the safest method so far is to rely on bmesh.bisect_plane for each segment of the boundary and then using optimized ray hit count algorithm to find out the polygon you want to remove.

The wall is a good example why i like to be able to reuse voronoi tex from the shader tree - take a voronoi 3D pattern, use a cloud texture to make the voro-cell-borders less straight and tell blender that every value under a certain threshold is mortar material and the values above are stone material (being all within one shader nodetree). Then use the same 3D voro-tex-coordinates to tell blender where to create vertices, skin them, decimate by distance etc etc. (Well, maybe you will want to create the voronoi-wall first and reuse the coordinates for the shader afterwards )