Slow performance using gh series component

[MonkeyFace]

I have created the attached grasshopper graph that creates a stack of bricks kind of like a chimney.
I am using this simple concept to practice my grasshopper skills in the arena of patterns and repetition.
Brick,Chimney_v1.gh (91.4 KB)

I have sliders for the number of brick courses and dimensions etc.
The screenshot example shows 440 bricks and on my laptop this took approx 6.0 seconds to compute the graph. . . t u m b l e w e e d

The graph creates a pattern of bricks for a single course (vertical layer) and alternates the brick pattern for odd and even courses.
This computation is multiplied by number of courses via a ‘series’ component that turfs out an integer (1-10) for each course of brickwork in my example.

Is there some way that I could only compute the first course and the second course (alternate brick pattern) once each – and then reuse those results but shifted up to the correct elevation to create layers 3-10 ??

Any advice on this would be appreciated.
regards
dan

[cfee]

Sasquatch Utilities | Food4Rhino quick fix, didn’t look at reordering your code .. sorry

[MonkeyFace]

HeHeHe - that’s cheating !! It’s good though - i’m keeping it

And I appreciate such a quick helpful tip.

Using a faster boolean difference component sure helps but I still have the scalability performance problem that is what I am really interested in understanding how to solve. Even using that much faster component if I double the brick stack to 20 courses its gonna chug.

I’d like to think grasshopper has a strategy for this type of thing that I could be pointed to read up on.

[Joseph_Oster]

Your code seems to work without those plugins? I see a MASSIVE cluster used four times that has two SDiff components inside. I’ve done many brick models in GH and never used SDiff. Search the forum, many people have done bricks.

Simple brick joint pattern

Gridded Bricks, Gap Control

I purged a lot of extraneous and distracting parts of this GH file, to understand it better and make some changes. The reference ‘Simple Brep’ is internalized so no need for Rhino file. [bricks_2024Jan5b] bricks_2024Jan5b.gh (20.1 KB) P.S. You can adjust the ‘Min’ slider (white group) to increase density. Better yet, make ‘Min’ slider 0 to 1 and multiply it by the computed max value. When ‘Min’ is 1, all rows have the max number of bricks. [bricks_2024Jan5c] bricks_2024Jan5c.gh (14.7 …

[MonkeyFace]

Thanks I’ll take a look at this.

A few comments –

1. the missing plugins are indeed only cosmetic. They keep the canvas less cluttered.
2. I think you might be right that it is the SDiff component that is performed for every line of bricks x 4 sides x the 10 courses. I haven’t yet investigated the example you attached but I notice from the image that every brick appears full length - hence no trimming required and it is fast.

So on point 2 I am ultimately interpreting your advice to be : “avoid SDiff component” as much as possible. So in my case where I am currently trimming a rounded up line of bricks where it extends beyond the desired length I could change this to calculate a bespoke small brick that completes the line without any use of SDiff.

Although the above would be an acceptable solution in this example it doesn’t really shed any light on the scalability performance issue that I am curious about – in other words sometimes in life there WILL be an unavoidable expensive computation in a grasshopper script - how do we ‘cache’ and reuse that result n times without re-computing it n times?

[inno]

@MonkeyFace

“avoid SDiff component” as much as possible

generally speaking, any solid boolean operation might consume A LOT of time, so it’s very good practice to use them only if they are truly needed

I didn’t check your file yet -but I will in the coming hours/this weekend- but I just wanted to point out that in a situation where you are dealing with bricks (aka “perfect boxes”, perfect vertical extrusions of a contour curve) most of the times you can treat them as 2D curves in a 3D space, and extrude them to the final brick height only as the very very very last step

on this matter, as bricks are basically polylines, and you might need to deal with planar curve boolean operations in certain cases, I very much advocate for installing the plugin Clipper or Clipper2 (I think they are both available with PackageManager, for sure you can find both on food4rhino) which allows for -even super complex- polyline booleans in a matter of milliseconds

when dealing with bricks, the most time consuming component in your canvas should be the final extrusion to transform 2D brick-curve-contours into real 3D bricks

[Joseph_Oster]

@MonkeyFace

So on point 2 I am ultimately interpreting your advice to be : “avoid SDiff component” as much as possible. So in my case where I am currently trimming a rounded up line of bricks where it extends beyond the desired length I could change this to calculate a bespoke small brick that completes the line without any use of SDiff.

Yes. In addition to the 2D approach discussed by @inno, you can split and cap breps with relatively low overhead compared to SDiff, especially bricks. I don’t think I’ve ever tried to “turn corners” on a row of bricks. Ideally a full brick turned 90 degrees is the same (or better) than a half brick because it ties together around corners. I didn’t look closely at your code.

[MonkeyFace]

Brilliant advice - thank you I’ll go again with maximum use of 2d polyline work until the last moment. Thanks for the Clipper/2 suggestions.

[MonkeyFace]

Thank you for that suggestion about the turned 90 degree rather than my half brick! A much better idea.