merge/union on multiple surfaces

I have a grid of circles, and I offset a smaller circle from each circle. Grafting the two boundaries, I create a set of surfaces using boundary surface. I am now struggling on how to make all of these a single surface so that I can extrude it into a solid.

What do you think is the best course of action? Any suggestions very much appreciated, thank you so much.

PS: I don't think solid union on all the produced solids is a good idea (too expensive computing wise), and solid union says that the boolean set is empty (probably due to overlappign surfaces)

Attachments:

screenshot.1490226203.png, 56 KB
pattern for question.gh, 7 KB

Replies to This Discussion

Permalink Reply by 0ddw589ypu3jv on March 23, 2017 at 9:24pm

The only difference is that the loop time can be changed,if your computer hardware is very good and run fast,you can set the loop interval by 0.001s otherwise setting by such as 1s in case of your computer crashed!

As to the cluster,if you have a confirmation file then you can open it.The only purpose

that i encapsulate the cluster is that i want the cluster just look like a gha component!

Permalink Reply by Joseph Oster on March 23, 2017 at 10:49am

Benchmarking is difficult because there seems to be parts of the process (Rhino rendering?) that aren't measured by the profiler. However, it's crystal clear to me that the two step process is MUCH FASTER than iterating through a larger list of Breps to get the same result. Simply because there are far fewer 'SUnion' operations - even though the unions are more complex (and slower) in phase two.

Same code but organized a little better, with separate X & Y controls so the grids in both phases don't have to be square. This is 3 X 3 in phase one and again in phase two; 81 "points" in ~17 seconds. That compares to 49 seconds using a single 'suLoop' or standard 'SUnion' (they are the same, though 'suLoop' appears able to handle a far larger number of Breps).

Attachments:

patternforquestion_2017Mar23a.gh, 17 KB

Permalink Reply by Joseph Oster on March 23, 2017 at 12:12pm

That is a marvelous bit of code (two C# components) to obtain curves without intersections, based on circles and their offsets - though it doesn't match the original pattern? And of course, it doesn't generate a surface that can be extruded to match the "solid" (Closed Brep) 3D result of interlocked rings from the original post. On close inspection, I see the list of radii being passed to the circle component are NOT all identical!? That's weird.

Permalink Reply by kv1 on March 23, 2017 at 4:46pm

This is the best approach I think. I will study this and try and post a solution. This is the fastest, cleanest-logic way of doing this in my opinion.

Permalink Reply by Joseph Oster on March 23, 2017 at 5:57pm

The theory of joining all the 2D circle/offset boundary ring surfaces into a single surface and then extruding it sounds good but no one has yet demonstrated a working version that matches your pattern. 'SUnion' is the "cleanest-logic way of doing this", it just happens to be slow when the number of rings is large.

Permalink Reply by kv1 on March 23, 2017 at 6:05pm

Thank you so much for the work you put into this, your solution is perhaps the most robust, and in the future when I need to boolean a lot of stuff I will be definitely use it. A couple years ago, I built the grasshopper definition for the olympic stadium in Beijing (Herzog and Ai Wei Wei). The 3d print for it came out terribly because I didn't have a way of boolean-unioning it together. This would have come in handy.

Tom Jankowski's definition is the best for the circle thing however. I applied it to my problem and it worked beautifully. The logic is bulletproof - he deletes the segments within the concentric circles. This is me applying it to my use case (more complex definition):

What is most valuable perhaps is that I can now see the code and how to use trees in loops in grasshopper....

Thank you Tom and Joseph!

Permalink Reply by Joseph Oster on March 23, 2017 at 6:56pm

How did you get a surface from Tom's code? I didn't see that. And what about the radii varying between 4 and 5? Is that a deliberate effect? It doesn't match your example pattern in important ways. What did I miss?

How about sharing some code for your ultimate best solution please?

FYI, here's one based on the 'SUnion' of boundary surfaces in Marcus Strube's code; if it had been a snake it would have bit me! 400 rings in 3 minutes, plus another minute to extrude the merged surface - no Anemone loop:

Attachments:

patternforquestion_2017Mar23b.gh, 10 KB

Permalink Reply by Joseph Oster on March 24, 2017 at 9:16am

Thanks for elaborating on your thinking process. Obviously, working in C# (or VB or Python) allows for a wider range of programming methods (more conventional for those with a programming background) and access to core Rhino features that may not be accessible in GH. By choice, I limit myself to standard GH components (except for Anemone).

I believe there are ways to obtain the outlines of the pattern using standard GH, but regardless of how you get it (C# or GH), how do you get a surface suitable for extrusion from it?

Permalink Reply by Joseph Oster on March 24, 2017 at 11:16am

Ah, so you baked the curves to Rhino to get the surface for extruding! I missed that part.

I've been programming for ~50 years(!) so scripting would be a relief from GH constraints, in some ways. I would choose Python and have dabbled with it a little bit, but I've enjoyed the challenge of doing things "the GH way".

Cheers.

Permalink Reply by kv1 on March 24, 2017 at 1:43pm

You don't need to bake the curves to rhino. I just join the curves, and use boundary surface to get the single surface from extrusion.

This is the final script that I'm using to produce the pattern. The boolean difference and extrusion takes forever on the clean curves still, but not as long I don't think as on the solids.

I've always had difficulty with grasshopper because I do not know how to handle data trees and data organization yet. I understand it at a superficial level. I also have a programming background (5, not 50 years haha), and I hope that I get started writing in C# soon.

Attachments:

Permalink Reply by Joseph Oster on March 24, 2017 at 2:33pm

I don't have "Hexagon Cells" pattern so can't use your code, kv1.

'Boundary' fails miserably when the pattern is large, as in Tom's patternforquestion2.gh code, which already has 'Join Curves' at the end (1433 curves!). I've tried it with smaller patterns that I obtained in GH and it works with 3 X 3 cells but fails at 4 X 4 and above. Useless!

Attachments:

patternforquestion_2017Mar24b.gh, 18 KB

Permalink Reply by Joseph Oster on March 23, 2017 at 12:29pm

FYI, some benchmarks of code posted earlier (patternforquestion_2017Mar23a.gh), using Profiler values rather than a stopwatch. All three get the same geometry result: a single Closed Brep consisting of 400 interlocked rings in a 20 X 20 grid.

V1 - A single 'suLoop' component doing 400 'SUnion' operations (20 X 20): 11.6 minutes

V2 - Two phases: 5 X 10 in phase one and 2 X 4 in phase 2, 58 'SUnions' total: ~88 seconds combined

V3 - Two phases: 4 X 5 in phase one and 4 X 5 in phase 2, 40 'SUnions' total: ~104 seconds combined

Again, these Profiler benchmarks don't reflect the whole picture, and might be affected by other things I was doing on the laptop while the code was running.