Consecutive Galapagos optimisations

Hi everyone,

I have a mesh on which I draw geodesic curves with K2. I would like these curves to be separated by a certain distance one from another. The distance between curves is evaluated at curve midpoint.

As the distance of one curve from another only depends on the position of the previous one, the best way to optimise this problem would be to look for a first curve, then for the second one, and so on. I then end up with a stack of lots of galapagos solvers that I have to run manually if want to change any input.


Optimisation stacked.gh (78.0 KB)

Of course, I can also feed all curves to Galapagos directly, but as the solver looks for all solutions at once, the problem has much more variables than needed, and Galapagos tends to not be able to find a really precise solution.


Optimisation multiple.gh (60.6 KB)

This brings a problem which I find interesting to solve : is there a way, I guess through coding, to stack otpimisation solvers ? There would be the question of when to decide the solvers have reach a solution, but a tolerance input might work well for this case.

I’ve found some threads about Galapagos inside loops but they don’t really end up with solutions and are quite old, any update if this is possible ?

Are the curves that come after the initial, geodesic one still geodesic, if you mess with them to keep a certain offset to adjacent curves?

Yes, you could do the Kangaroo simulation and optimisation with a script, if you know how to implement a genetic algorithm. Kangaroo can be used in both C# and Python, however Galapagos isn’t available, as far as I know.

Good idea! Looking at adjacent curves would make output curves loose their geodesic properties, but maybe not so much and it could be the price for having curves with the exact desired distance. Though I do not really how I would find those adjacent curves, as geodesic curves are only defined with ending points.

I could however look at a certain amount of adjacent starting points and select the best outcome ; and then loop until a certain threshold. This would be doable without using Galapagos !

I was actually hoping that Galapagos would be available in C# :frowning:

Yes, I imagined it as a compromise between being geodesic and offset correctly, too. I wonder if strips between adjacent curves would still be unrollable, if they’re not totally geodesic?

Another idea could potentially be to check for sphere collisions with the appropriate radius during the Kangaroo simulation that also computes the geodesics on the mesh?

I’m not 100% certain, but I don’t think it’s available. It wouldn’t be too difficult to implement your own minimizing or maximizing algorithm though.

Well not necessarily, but neither with geodesic curves! The geodesic property mainly ensures that the strip will have the straighest naked edges possible.

Neat idea ! It needs a bit of tweaking regarding the params, but once there it is by far the fastest method so far.


Optimisation sphere collide.gh (70.2 KB)

Conclusion : always try to look at a problem from a K2-goals perspective

PS :

I don’t really know where I would start this, would you have any litterature to recommand ?

1 Like

I see. I always thought that when you have two geodesic curves on a mesh and redraw/reconstruct a new mesh between the two - much like a straight loft - it would be guaranteed to be unroll-able.

True, for me it’s one of the greatest features of Rhino/Grasshopper and so much fun!

Daniel Shiffman’s introduction to genetic algorithms on YouTube (cf. The Coding Train) is a super nice start. He programs mostly in Java (or Javascript), but it’s easily understandable - especially if you’re accustomed to C-like languages -, and he explains the concepts really well. There’s also a chapter about genetic algorithms in his book “The Nature of Code” (cf. Chapter 9, The Evolution of Code), which is available online for free.