thanks!
In order to keep the original patterns, everything suggested took entirely too long or didn’t complete at all. I ended up adding a ‘Surface’ component to either ‘Cull’ or ‘CircleCNR’, baking that and using it to Split the original surface in Rhino. It may sound heretical but it was the fastest way to see the result.
1 Like
Can you post the definition or a screenshot?
Are you saying that you baked the pulled circles and used them to split the surface in Rhino?
Pull still took too long, especially in keeping the original “resolution” of UV count and the attractor points. I took output of ‘CircleCNR’ and converted it to a surface, and baked that to split the surface in Rhino. A couple more steps but took only a few minutes -
attractors_circles_surface.gh (11.8 KB)
Baked and split surface shown below. I also changed to making the wavy surface by flowing the split surface along the curve in the background -
OK, I want to get this straight because it’s really good to know. I’ve replicated your steps and have some comments.
You don’t need the Srf param at the end, you can bake the circles and use them as the “cutters” in the Rhino “Split” command.
Unless you use Pull, your method works only on flat surfaces so you don’t need Circle CNR, as long as you know the plane being used for the flat surface, which in this case is XZ. Instead of this:
You could do this:
After baking the circles (cutters), you split the flat surface in Rhino (3388 holes in ~45 seconds?) and then turn the flat holed surface into a wavy holed surface using the Rhino ‘Flow’ command (which requires that you draw a “Base curve” line along the bottom edge of the flat surface).
Thanks, this is very good to know. What is so deeply wrong with GH SrfSplit that it can’t handle that many “cutters” just as well as Rhino??? (a rhetorical question for you, a valid one for @DavidRutten)
What is so deeply wrong with GH SrfSplit that it can’t handle that many “cutters” just as well as Rhino???
It is a Rhinocommon problem with this method:http://developer.rhino3d.com/api/RhinoCommonWin/html/M_Rhino_Geometry_BrepFace_Split.htm
But Rhinocommon is not Rhino, it is just code that is available to developers. My bet is it has been improved probably over years in rhino and maybe not revisited in rhinocommon. You will find usually Rhino commands are more robust than rhinocommon.
That’s why David suggested above to request it with the Rhino guys.
Yeah, thanks Michael, I don’t see why any of us need to do any more than we already have by bringing it up here over and over again? This code/thread is a perfect example for “the Rhino guys” to study - and fix Rhinocommon!
Pull of 3388 circles to the wavy surface takes only 5.4 seconds, according to the profiler. so there’s really no reason to skip it. Might as well do the Rhino split on the wavy surface and skip the unroll and flow steps.
Got it – didn’t understand the use of ‘Pull’ at first but now I see. I’ve retraced your steps and it was a faster, smoother process. Point taken re: CNR; once the exercise shifted to working on a flat surface, your edit makes perfect sense. I’ve saved both definitions for future use as they’ll be useful in different scenarios.
Many thanks to you and to everyone for your time and insight, this has been extremely helpful.
Yeah, but the code is more flexible (so to speak) leaving Circle CNR and Pull in place, since it works with both flat and wavy surfaces, leaving only the split to do in Rhino. I learned something here too.