Hi Ray,

Choosing which outputs to show can be done using the Entwine/Explode components and turning preview off for the objects you donâ€™t want to see by right clicking the components:

Itâ€™s an interesting thought of a generalised goal, but perhaps a bit of explanation of how Kangaroo works makes it clearer why this would be tricky.

For each goal, the code inside describes how to move the set of points it acts on in order to satisfy that goal (which can also be seen as projecting onto that constraint set, or zeroing that energy), a set of vectors which usually depends in some way on the positions of those points at that iteration.

For something like a length goal, finding these vectors is very easy - given the current length of the line, we can calculate how much shorter or longer it needs to get, and move the start point along the direction of the line by half this amount, and the end point by the opposite vector.

For some of the other goals finding these vectors gets much more complex though, and it isnâ€™t an automatic process. Even when the geometric property we are after is clearly described, the set of vectors we need to move the points by to satisfy this is sometimes far from obvious, and a big part of creating Kangaroo has been figuring out these calculations for all the different goals.

You donâ€™t actually always need to know how to calculate the vectors to exactly satisfy the goal in one step - if you do the goal will converge quicker, but as long as you can always calculate a set of vectors which reduces the error by some positive amount it should converge eventually.

If you have some new goal in mind, you can script it in C#/VB/Python if you know enough about the structure of the problem to describe how to calculate these vectors.

Something I have also thought about which should also be possible in theory would be to have a way to define a goal by wiring components together, without scripting - so youâ€™d create a sort of cluster with some points as input, and some vectors as output, and this cluster would get called with new inputs from inside the Kangaroo solver every time it was needed. Youâ€™d still need that understanding of the problem structure though.

Maybe you are thinking of something that would work more like how Galapagos does - where you can simply set the value to minimize, and the values it depends on, regardless of what calculations happen in between.

I have sometimes thought about a way to do this by testing the result of small changes to each of the inputs to estimate a gradient.

There are also various other plugins that have a setup similar to Galapagos, but use other methods for minimisation that are faster for many problem types - such as Goat and Octopus. You can even put a Kangaroo solver *inside* the optimisation loop of any of these.

Doing it the other way round (putting some kind of automatic gradient estimator *inside* Kangaroo to act like another goal) isnâ€™t currently possible, but could be interesting to think about more.