Boolean / Solid Difference = unresponsive Grasshopper

So, I'm building this template file, which should be easily adapted to any type of surface, shape, curvature and object.

The file starts with a solid surface, on top of which is a target surface (used as a mask). By inputting the # of grid points in the Y direction, it calculates # of grid points in the X direction, trying to create as close as possible a square grid division.

Hovering over the surfaces are 2 curves. By calculating the distance between the curves' points and grid points, an attractor pattern is created.

The source object is scaled based on the attractor curves, flipped upside down and adapted to the surface normal. Finally a solid difference is applied resulting in the indented surface pattern.

(Also, there is some more detailed input regarding object size, rotation and location.)

While running this on a machine with enough processing power to fly me to Mars, Grasshopper still becomes really slow and unresponsive ever since I've added the sDiff component. The same goes for utilizing the Trim component instead of the sDiff (I assume they do the same in this scenario?).

Am I missing something here? Is it somehow calculating large amounts of unnecessary data? Am I doing things overly-complex?

Attached the Rhino & Grasshopper files. Please play with the "# Objects in Y direction" slider, to (hopefully) experience what I mean. I am looking at a preferred # Object in the Y direction upwards of 50 at least. Changing the "3D Object" BRep to something else (in the hidden layers) might also influence performance.

So, what do you guys think?

Attachments:

3D Surface Pattern Template - Rhino.3dm, 446 KB
3D Surface Pattern Template - Grasshopper.gh, 17 KB

Replies to This Discussion

Permalink Reply by David Rutten on September 24, 2012 at 12:53pm

Solid Booleans are complicated operations and you're performing a lot of them. If you bake the shapes and run the BooleanDifference command in Rhino it takes the same amount of time. It is unresponsive because the entire SolidDifference is a single operation. I unfortunately can't test the state of the Escape key while it is running because all processor cycles are used by the component, leaving none for me to do anything whatsoever. If it were 210 consecutive operations it would be somewhat more responsive to cancellation, though it would not be any faster.

"...enough processing power to fly me to Mars"

I'm not sure what that means. It takes roughly 3.5 minutes on my laptop which high-end but not excessively so.

I think you'll have to talk to the main Rhino guys about speeding up the operation, but I don't think there's much anyone can do. Improving and speeding up the solid boolean operations is an ongoing effort.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Pete Bell on September 25, 2012 at 1:34am

8x i7 3,4Ghz - 32GB RAM - NVIDIA Quadro 5000; so, yes, it should be able to fly me to Mars ;)

With the "# Objects in Y direction" slider set to 20, it's doable. However, when I set it to 50 Rhino and Grasshopper become unresponsive and after an hour nothing has happened. For me this feels like something is wrong.

Maybe I have some settings the wrong way? I run in wireframe mode, both R & GH. Is there some kind of tolerance or mesh level settings that I'm forgetting about?

If I enter a setting where the sDiff does not work, it will calculate the result pretty fast btw.

Permalink Reply by Raul Matagringo on September 25, 2012 at 1:53am

Hi Pete,

i also run into this problem. Not with GH but with Rhino plug in. R4 was very slow , R5 was better but still slow. Both versions arent able to finish massive boolean operations with solids.

The best solution for me was to use AutoCAD for massive boolean operations. Works fine and its very fast.

Permalink Reply by David Rutten on September 25, 2012 at 5:02am

Grasshopper and Rhino will only use 1 core for boolean operations, so it doesn't matter that you have 8 of them.

It does take a long time, longer than I would have guessed. The booleans are reasonably simple as they do not intersect. However I don't know anywhere near enough about the algorithms involved to make a useful remark.

One thing that could perhaps be done to speed things up is to not use solid booleans at all. It seems you're punching holes into a planar surface, so you might be able to get away with getting all the edges as curves and then creating a single Planar Surface out of all of them.

I attached a file which attempts to do just this.

David Rutten

david@mcneel.com

Poprad, Slovakia

Attachments: