Now and then I'll just dig up some old standard creative coding technique, make a solid, reusable function for it, and add it to my libraries. Circle packing was not in there yet. It is now.
most of my code libraries are contained in two modules. blcairo, which is all rendering code. It's got the cairographics bindings. And bitlib, which is pretty much everything else, but knows nothing about rendering. The biggest part of that is probably geom, which has points, lines, circles, rectangles, polygons, all kinds of shapes - but only as models of shapes. blcairo knows how to render them all.
This circle packing just returns lists of circles, which makes it very flexible.
@bit101@mstdn.social All lovely 🤩
Curious, what algorithm does it use? What kind of configuration? I haven't written this kind of code in a long time, but I recall many of my efforts at reuse were resisted, even something as simple as a particle often wanted a shape or api specific to a project, and it didn't feel right to create uberclasses.
@ipsquiggle@sunny.garden I write everything in Go, as part of a couple of custom frameworks I built that use Cairographics C bindings. I think it's pretty standard circle packing. Find a random point that's not in an existing circle, what's the largest circle you can create from there that doesn't overlap another circles. With a few other constraints and parameters.
@bit101@mstdn.social Do you get one circle at a time, feeding the existing ones back in, or do you provide the inital constraints and get a whole bunch out?
Is the circle a Very Standard thing in your framework? Is it an abstract circle or does it know about drawing?
Heh, I'm suddenly very curious about this.
I'm just think about how back when I was using processing, everything was "draw" oriented, and so maybe I had no data to reuse against. I think my approach would be so different now!
I really gotta get back to it sometime...