Multiple Attractors with Points / Circles & Cutting Circles out of a Surface

Two more improvements:

  1. That A/B thing wasn’t sitting right with my way of thinking so I ditched it.
  2. Added a ‘min radius’ slider (blue group) to set the smallest circle size.


attractors_circles_2018Feb21c.gh (16.9 KB)

Yes, that will work.


attractors_circles_2018Feb21d.gh (18.1 KB)

Note that I disabled Boundary at the end because it’s rather slow. It’s more fun to play with the ‘Seed’ and ‘Count’ slider inputs to PopGeo when the model is fast.

Thank you again. I reconstructed your definition to trace your logic and it works perfectly.

I have two other questions –

  1. I would like to apply this to a curved surface. I tried replacing the ‘Circle’ elements with ‘CircleCNR’ to find the surface normal; it worked on the original surface (it oriented them vertically) but had some problems with the curved one (photo below).

  2. If I wanted to control the attractor points, rather than create random ones, do you have any suggestions? I know you recommended ‘PopGeo’ to create multiple points, but in this case it will be important to control the points of greatest material density.

attractors_circles_normals.gh (18.2 KB)

On #1, it’s not difficult to restore that Circle CNR… Here it is:


attractors_circles_2018Feb21e.gh (23.6 KB)

On #2, you can choose the points any way you like, just replace the ones generated by PopGeo.

1 Like

Perfect, got it –

attractors_circles_manualpoints.gh (15.2 KB)

Thanks again!

One more – any suggestions for trimming the circles from the surface? Everything I’ve tried so far crashes.

I reduced the “resolution” (grid point count) because this is SLOW and might not work at all with thousands of holes. Even so, this took nearly ten minutes, so I disabled the yellow group on the attached file:


attractors_circles_2018Feb22a.gh (22.5 KB)

To get around the performance issue, the surface can be split up to reduce the number of holes per surface. More here:

The split is very slow because that method uses all the cutters as once - it is like surface.Face.Split(listOfCutters, splitTolerance); So it evaluates all the cutters and makes some split.

I have found in a lot of cases that just using anemone to split with one splitter at a time really improves the performance. So keep looping the next cutter with the previously cut surface.

3 Likes

Never would have thought that that approach would improve performance… must try it someday.

It still can be slow (but not as slow), but at least it always seems to finish rather than hang up.

1 Like

Here with Anemone fast loop. 75 seconds to finish. Without Anemone, I am still here waiting going on 8 minutes now… @DavidRutten can split be improved for Gh2? It’s just one of those things most everybody needs.

attractors_circles_Anemone.gh (18.6 KB)

4 Likes

It’s not a Grasshopper thing, Split (like almost all geometric operations short of Delaunay, Voronoi and Bi-Arcs) are a Rhino thing. I can put it on the list for Future Rhino, but it’ll carry more weight if users request this instead of me.

Understood

Hi @Michael_Pryor,

I tried to translate that to C#, but it doesnt work.I think I need to feed everytime the surface back in?
Not for comparing splitting time, I just see it as exercise

Maybe you could help me?

SplitLoop.gh (12.5 KB)

Something like this is the same thought behind the Anemone way.

Basically using one curve at a time as a list (since split requires a list).

And actually you get the same speed advantage of the Anemone way even a bit faster. Here I cut about 2000 circles out in 86 seconds:

The Gh split took 244 seconds for the same 2000 circles:

@DavidRutten seems a simple change like that can greatly improve the performance for whatever reason.

SplitLoop2.gh (15.0 KB)

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:

attractors_circles_surface_2018Feb23a

You could do this:

attractors_circles_surface_2018Feb23a2

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).

attractors_circles_surface_2018Feb23a3

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)