Several general questions about Kangaroo System

[xarthurx]

Hi Daniel,

Thanks for the great plugin, truly great work.

I'm a PhD in computer graphics and recently discovered the Kangaroo system and found it super interesting and helpful for fast prototyping of geometry related optimization problems.

After reading the source code of this repo, I have several general questions about the setup under the surface, which I think most of the designer will touch, so I'll put it here.

1. As far as I understand, the whole Kangaroo system is an optimization solver and each goal is an objective for a minimization problem. So are these objective combined linearly with weights and fed to the solver?

2. Since we are not supposed to feed in gradient/hessian, how does the algorithm search for directions? Finite difference? Is it possible to improve the performance by providing inputs for gradients?

3. A technical question, for the goalObject, it seems to me that the Calculate(List<KangarooSolver.Particle> p) is the essential part in which two arrays of Move[n] and Weight[n] is necessary, acting as the objective and the weight. Anything else missing? So everything we're formulating will finally be a KangarooSolver Particle, correct?

4. Can we parallel the solving process, utilizing the multi-core of modern computers, or are we locked by the "single-thread nightmare" of Rhino?

5. apologise to such many questions and is there any available material that explains the setup of Kangaroo behind the scene developers? That'll be really helpful.

Thanks.

[Dan-Piker]

Hi xarthurx,

Yes - the solver minimises the (weighted) sum of the squared lengths of all the move vectors. Essentially it does this by repeatedly moving each particle by the weighted average of all the move vectors acting on it (it also uses a momentum-like term, where a part of the amount moved in the previous step is added, to accelerate convergence over simple gradient descent, like Nesterov's method).

So (for each particle a goal acts on) the move vector should be how much it needs to be moved by to make the energy for that goal zero. It can be seen as a projection onto that constraint.

There is not currently any way for a goal to include information about higher derivatives. It is something I'm still considering, but only if I can also keep the option for defining goals in the current simple way.

Yes - the Calculate method of goalObject just needs to calculate a set of Move vectors and scalar Weighting values, one for each particle it acts on. There is also the option of including a corresponding set of vectors for Torque and scalars TorqueWeighting, which act similarly on the orientation of the particle.

The Calculate method for all the goals is called in parallel.

I hope this is helpful. I'd be interested to hear more about how you want to use it, and happy to try and answer any more questions. I'm still working on better documentation.

[xarthurx]

Hi Daniel,

Thank you for the clear explanation and sorry for getting back to this late as I was working on other things.

I agree that keeping it simple is more important for Rhino/GH users than computational efficiency as higher order derivatives are often hard to be computed automatically.

Additional question of the system:

1. It seems PPos and PIndex need to be defined to make the system work, as I also read from other threads on the forum. However, I was wondering if the dimension of each Kangaroo.Particle (which seems to be defined as a Point3d can be changed -- higher/lower dimension particles?

2. Can additional regularizers be added to the global objectives easily? I can add additional goals for this, but wondering if can be coded. Since goals are separately imported to the solver, I guess this may need to also write the solver in c# instead of using the standard solver?

I'll share things once they are meaningful for Kangaroo users, but currently, the tools are mainly used as a proof of concept for larger optimization questions coded in c++.