Solid Union fails with some piped lines

So I am trying to create some patterns from lines and need to use Solid Union and Solid Intersection and both seem to fail with some breps for no apparent reason.

I have a bunch of lines (from the Substrate algorithm in this case) and an outline that is the sort of frame. I use pipe to give the lines some thickness and make a solid out of the frame.

Then I need to union together all the pipe elements, but this fails on one set for no reason at all.

If I try to do it the other way round and use intersection with the seperate pipe elements then Solid intersection discards all elements that are completely inside the outer frame.

Both seem to be really weird, because I have no idea why union would fail and intersection just seems plain wrong to me that it would discard those.

Tried baking and doing it in Rhino and it also fails, but I guess GH uses the same union and intersection code as Rhino.

Converting everything to Meshes and using the Mesh Union and Mesh Intersection is even worse - they dont even produce remotely acceptable results.

Thanks for any hints.

ps: Does anyone know of a plugin for Boolean Operations in GH that is more reliable?

Attachments:

union_intersection.gh, 34 KB

Replies to This Discussion

Permalink Reply by Armin Seltz on October 28, 2015 at 9:44am

Just noticed that doing the Boolean Intersection on the seperate elements in Rhino DOES NOT discard the elements completely inside as in GH.

Interestingly when I did the one that is missing from the intersection as seen in the image above, Rhino told me "had to double precision for boolean to work" - I have never seen that before and not sure why that comes up!?

Permalink Reply by Nik Willmore on October 29, 2015 at 12:15am

You are learning the hard way, the best way to grok this very singular issue in Rhino.

Yes, it's an issue. It's not a bug. It's the exact opposite. It's Rhino being too academic in how it does things.

With a given N number of objects to Boolean union Rhino will always fail.

Consider using the new Cocoon plugin to start with lines and end up with a mesh built around each line that will indeed 100% every time join successfully with its overlapping neighbors.

Here is one of my many tirades about this sort-of-a-bug:

http://www.grasshopper3d.com/forum/topics/boolean-ball-collisions?c...

It's great that you have a hungry empirical outlook to solving problems. Learn to program and get a job at McNeel please.

Permalink Reply by Armin Seltz on October 29, 2015 at 3:32am

Wow, thanks for explaining things a little bit, also had a look at your long post in the other thread. It actually kind of makes sense now. Regarding the tolerance issue I actually did all the steps in Rhino with the baked geometry and it gave me a message like "had to double accuracy to succeed with boolean operation". Varying the radii seems like good enough workaround and I'll try that.

I'll have a look at Cocoon as well - sounds promising.

Thanks!

Permalink Reply by Armin Seltz on October 29, 2015 at 3:36am

As for programming. Well I do a bit of that. Nothing high-level, just some basic JS, PHP, a bit of Mel and Python. For me the graphical programming languages are much more attractive though. I prefer making ridicolously large patches in vvvv and grasshopper. The one I am working on right now is in the making for over a year now and i'm lucky enough to get paid messing around in GH full-time :D

Permalink Reply by martyn hogg on October 29, 2015 at 3:13am

That was close! You almost got Nik started on Boolean operations again! :)

It is frustrating, I've lost a few hours in the past to wondering how to get pipes to union properly. A hack fix, if you need something quickly and don't want to work with meshes, is to vary the radii of the pipes by a small, unnoticeable amount. This helps Rhino solve it's issue with having perfectly overlapping surfaces and very thin slivers of surfaces where the pipes meet.

The Cocoon plugin is awesome though and easy to use.

Permalink Reply by Armin Seltz on October 29, 2015 at 3:38am

Hey thanks for your answer. Oh, sorry I falsely credited Nik with the varying radii workaround. I will try that right now as it seems much quicker than getting to know a new plugin. But I will check it out too!

RSS