merge/union on multiple surfaces

Replies to This Discussion

Permalink Reply by kv1 on March 22, 2017 at 7:54pm

I just edited the question with my definition. It works when I solid union boolean the berps (extrusions) together, but it does not work when I have many points. I am still looking on a novel way of doing this with curves or surfaces first, as solids are too expensive to compute.

Attachments:

• screenshot.1490233891.png, 70 KB
• pattern question.png, 50 KB
• pattern for question.gh, 7 KB

Permalink Reply by Joseph Oster on March 22, 2017 at 8:47pm

Posting your code helps a great deal.  How many points (extrusions) do you want to 'SUnion'?

I have an Anemone loop running now, doing 'SUnion' one at a time.  Working so far, though slowing down to ~1 sec. per extrusion.  Will try the 'Fast Loop' to see if it makes any difference.

Permalink Reply by kv1 on March 22, 2017 at 9:58pm

Hello Joseph, thanks so much! For the number of extrusions 163 and more, at which point solid union fails to collect data. Any idea how to get the shape first with surfaces or curves? They should be easier to compute. Anemone is an interesting way of preventing crashes haha.

Permalink Reply by Joseph Oster on March 22, 2017 at 11:14pm

I think I understand what you are suggesting (make a surface of "joined" concentric circles and extrude it?) but don't know how to do it.

Anemone has two modes: normal (legacy version, slow) and 'Fast Loop'.  The fun part of the slower version is that you can see what it's doing while it's running.  'Fast Loop' gives no indication that it's working, so you want to test it with small numbers and be sure it's coded properly before bumping the iteration count up.

The GH profiler running the slow version showed between 1 and 1.5 seconds per loop, but the reality was more like ~10 seconds per loop toward the end of an 11 X 11 grid, or ~20 minutes total.  It's easier to be patient because you know it's working.

The 'Fast Loop' finished the same grid in 1.6 minutes!  An impressive improvement.  I've been running it on a 30 X 30 grid (900 points) for ~23 minutes so far and see nothing yet.  Not the ~12 minutes I had hoped for...  Now 36 minutes on this loop for 900 points... hope it's not stuck.  Not fast!  Later - DONE!!  Profiler says 59 minutes for 900 points but it was more like an hour and twenty minutes total.  It succeeded, I have a single 'Closed Brep' from 900 extruded rings, baked to Rhino.

Another strategy to explore would be doing 'SUnion' on a smaller grid using the Anemone loop, then replicate it by moving it as needed to form a larger grid; then run the copies through another 'SUnion' loop.  I went ahead and implemented that while waiting.  It works and is fast!  Started with 3 X 3 and ran the result again as 5 X 5 (9 X 25 = 225 total) in barely ~70 seconds!?  Trying 36 X 36 now...  1,296 points appears to have succeeded in less than ten minutes!  Though it seems to take quite awhile after the loop ends before control is restored to GH/Rhino.  I'll let you do your own experiments and benchmarks.

I encapsulated the loop in a cluster called 'suLoop' (blue groups).

Internal of 'suLoop' cluster:

Attachments:

• patternforquestion_2017Mar22b.gh, 1.5 MB

Permalink Reply by Joseph Oster on March 22, 2017 at 11:30pm

This is a 36 X 36 grid, 1,296 points, "solid" 'Closed Brep' - a lot for Rhino to handle (185 MByte file!), aside from the strain on GH to create it:

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

Yes, I far prefer Python over the alternatives!  Without looking at the Python, though, I have some observations.  Puzzled to see 'SUnion' used on flat boundary surfaces (the rings) to get a single "Open Brep"; I didn't know it worked on flat surfaces.  And I think it's only fair to include in your benchmark the considerable time 'SUnion' takes in this example: 21.9 seconds for 121 rings and likely much more with 400 or 1,000+ rings.

Then I noticed the pattern doesn't match.  Checked the circles and they are the same.  The distance between them, however, is different: 7 instead of 6.  When I change that value to 6, the Python fails badly.  All the holes and gaps are gone, which destroys the pattern:

I can't do the "two phase" approach on an 11 X 11 grid, but I can do 6 X 6 and 2 X 2 to get a 12 X 12 grid (40 'SUnion' operations) in 28 seconds total.  That beats your benchmark of ~37 seconds for an 11 X 11 grid, if you include the 'SUnion' in your code.

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

Wait, what?  I ran your code and evaluated it.  It fails to reproduce the pattern and does NOT beat my benchmark, as I tried to explain in considerable detail.  Looking inside your Python component won't help, which is what I meant when I said "Without looking at the Python...".

Maybe we don't understand each other?  Oh well, thanks anyway.

Permalink Reply by 0ddw589ypu3jv on March 23, 2017 at 1:27am

Attachments:

• loop_solid_union.gh, 254 KB

Permalink Reply by Joseph Oster on March 23, 2017 at 6:25am

Explain please?  Unable to see what's inside your component.  Not a cluster and not a C#/Python code block that can be edited so, frankly, useless to me.  Your 'Breps' param appears to contain 10,000(!) null values, which is good because it would be very rude to open a GH file and have it stuck on a 10,000 element loop.

Permalink Reply by 0ddw589ypu3jv on March 23, 2017 at 7:48am

Sorry!

I have forgoten to interlis data.And the component is a encapsulated cluster!

Attachments:

• Loop Solid Union.ghuser, 18 KB
• loop_solid_union（internalise）.gh, 519 KB

Permalink Reply by Joseph Oster on March 23, 2017 at 8:21am

How do I open a ".ghuser" file?  Are you using C#/VB/Python or standard GH components?  How is this different (better?) than what I posted?  I could see the output as it was running and it didn't appear to be that fast.  Working on a smaller data set (9 X 9), it slows down noticeably by the ~20th iteration or so and freezes GH/Rhino completely for quite awhile until it finishes.  Seems far slower than my 'suLoop' cluster on the same data, using Anemone 'Fast Loop'.  Harder to benchmark though because the profiler shows the time for each iteration of your loop (847ms for the last one) instead of timing the complete loop.

My only other comment for now is that the idea I demonstrated of doing a 6 X 6 loop (for example), then making 36 copies of the result and running them through a second loop...  uses only a total of 72 'SUnion' operations instead of 1,296.  That's a major reduction, even though the unions in the second loop are more complex than in the first loop.  Would need to try different combinations to see what works fastest.  Like 10 X 10 followed by 2 X 5 (1000 total), for example, vs. 2 X 5 followed by 10 X 10.

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

Doing 1 set at a time is a brilliant idea!

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page