Grasshopper

algorithmic modeling for Rhino

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)

Views: 11064

Attachments:

Replies to This Discussion

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:

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.

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.

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:

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:

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.

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.

Attachments:

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.

Sorry!

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

Attachments:

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.

Doing 1 set at a time is a brilliant idea!

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