Hello! I’m trying to achieve a similar effect of circle packing as this pavilion. I have a separate circle packing script I am trying to connect to the hexagonal grid, but it doesn’t seem to want to collect the data?
If possible, I would appreciate a different method of circle packing as well since the one I’ve tried does not allow the initial circle curve to change size. The files are attached below.
In order to get your data trees to match, you need to graft the ‘Curve’ input to Point In Curve, and then graft the ‘Mesh’ and ‘Curves’ inputs to ImageCircles.
After that, I don’t know why the Kangaroo Solver component freezes GH/Rhino? Or how you account for the limited subset of hexagons (and partial hexagons) that are contained within the circular perimeter?
Thank you for your response! I will try to keep troubleshooting the rest.
Thank you Joseph for your response–I will try to keep troubleshooting the rest!
Actually, it’s not freezing at the first Kangaroo Solver after all. The code works through the Circle CNR component and freezes somewhere after that… 
There appears to be some redundancy in this code, as the group that follows looks very similar… Got it! Don’t know why but after disabling the components that follow and re-enabling them one at a time, it’s the second TriRemesh with circles as input that causes GH/Rhino to freeze.
OH!!! There are 16023 circles coming out of Circle CNR! Due to a mis-match of the two inputs - either ‘Center’ needs to be grafted or ‘Radius’ needs to be flattened. I flattened the ‘Radius’ input but then enabling the second TriRemesh still causes the freeze (for 28 seconds).
An on and on it goes, grafting inputs to match data streams, until the second Solver returns an error: “1. Solution exception:One or more errors occurred.”
Wow!! Thank you–I temporarily disregarded the hexagonal grid and worked within the larger circle curve for the circle packing. Circle CNR seems to work well when not connected to Image Circles’ output and just its Vertices.
Will definitely come back to this and work it out through your process.
Thank you!
I’ll post what I got and leave it to you. Data trees must always match and make sense. Temporary text panels work best for me to examine them.
P.S. On a hunch, I replaced the Random ‘Min’ input to ImageCircles with a slider value of ‘11’ and it works. Maybe not what you want but at least it works. Seems odd to me that the ‘Max’ value (1) is less than the ‘Min’ value?
12162 circles is quite a lot, again with no culling of points outside the round perimeter circle (cylinder)? Code would be faster if you trimmed those points as early as possible in the process.
This version adds two yellow groups to cull points outside the clipping cylinder:
Thank you infinitely for this!
Is it possible to use attractor points with this script for the circle clusters to vary in length, similar to that of the pavilion photos at the beginning of this thread?
Possible, yes (of course!). But it doesn’t look easy at first glance, in part because I flattened data trees twice, losing the groups of points in the process. I have some ideas and am playing with it but frankly, it requires a level of expertise about data trees…
OK, I got something working, though I don’t understand what the Kangaroo solvers are doing, if anything? Data tree management is rather complex. Good luck understanding it, modifying it and explaining it. You could apply a Graph Mapper to ReMap, for example.
I probably did more on this than I should have.
P.S. I see mistakes now that I missed before… oops.
After substantial modifications to my code this morning, I belatedly discovered that the anomalies I saw in yesterday’s version ‘d’ go away if you reset the second Solver component. 
I still don’t understand what the Kangaroo solvers are doing or how they are supposed to work; it’s very possible that I broke them in my efforts to resolve data tree issues? One of the data tree issues I had to resolve was the Kangaroo solvers ‘V’ output (center points) not matching the ‘O’ output (radii).
Still, I like the code revisions I made this morning.
Resetting the second solver appears to be unnecessary in this version.
Scratch that. In some cases, the extruded rods appear to be doubled and overlap until you click the button to reset the second solver (bottom group). I don’t know why? Perhaps the long (20 sec.) time for the second TriRemesh component? I don’t know…
NOTE: The second solver takes much longer to reach a “Converged” state if you increase the ImgCircles ‘Min’ input slider value from 20 to 30.
Right, I noticed a problem with the solver there too. I tried disregarding the O output and connected a separate circle component for the radii, but it was not the most efficient in terms of creating an adjustable script.
Thank you for all your responses–I appreciate everything you’ve done despite the speed of the file!
I thought the solver was supposed to vary the radius of circles to make them fit but the ‘O’ output is always the same as the ‘Min’ input. Apparently only the center points are moved. I don’t get it?
