Grasshopper

algorithmic modeling for Rhino

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?

Views: 3703

Attachments:

Replies to This Discussion

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

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.

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.

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:

Thanks a lot David, this works like a charm.

I'll try and find out how it scales back into what I already got.

When I have some more issues with it, I'll know how to find you.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service