Hi all and hi @DanielPiker,
I’d like to ask some clarifications about Kangaroo2.
-
I used Kangaroo for a while and I have noticed that there is a recurrent problem which is the fact that with particular strengths values and goal conditions some moving points are overshot in the motion direction which may generate a perpetual motion or the explosion of the whole system.
I attach a file as reference:
fold overshooting.gh (15.8 KB)
Why does it happens? And since Kangaroo tries to minimize the error how am I able to generate a perpetiual motion generating motion from nowhere?
-
I would like to know if it is possible to have some constraints that are 100 accurate. For example the anchor points. Is there any way to fix it univocally in a specific place without making them move at all? I think this is not possible at the moment but maybe there is a way to implement the solver formulation to make it processing only some specific goal nodes as springs and consider others as fixed starting points that do not behave like springs.
-
Sometimes I have troubles to split the output results.
For example, if I input two different lists of segments in two different goal nodes, and let say that I need to re-use them preserving the original order after processed them with kangaroo, how can I do it efficiently? Maybe it would be useful to have an additional node that takes as input one or more “Show” nodes and the Kangaroo solver which would return the list of the same elements input in the “Show” node after processing them with the solver preserving the order of the original elements.
Thanks, Riccardo
Hi Riccardo,
I’ll address these in reverse order
The ‘O’ Output of the solver preserves the order and tree structure of the input to goal data. To more easily separate these outputs it can also be useful to use ‘Entwine’ and ‘Explode Tree’ components like this:
Regarding absolute constraints - the simplest case is when the goals do not conflict, and there is a solution which achieves zero energy for all of them, so they can all be satisfied absolutely. In many applications however this will not be the case. One way of ensuring some goals are satisfied absolutely is to take the strength of any other goals which conflict with them to zero.
For instance, if you want to make the faces of a mesh perfectly planar, and also have it meet some boundary exactly, while also keeping a smooth shape and close to some guide surface. These last 2 goals conflict with the first 2, so what I would do is get close to the result I want with moderate strength ratios, then reduce these ‘fairing’ goals to zero (or equivalently increase the strength of the ‘constraint’ goals to be effectively infinite - something like 10^15).
This is what is shown in this video: https://vimeo.com/122463847
The reason for not setting the constraint strengths too high from the start is that it would slow down convergence too much. However, this is not an issue when it is just anchors you want to make absolute, as they do not need to move at all - you can set the strength of these as high as you like.
I should also mention that I’ve been testing out a new version of the solver component for the next release that lets you separate goals into hard and soft inputs, to make this easier - applying the hard goals at the end and letting them override the soft ones.
I’ll take a look at your hinge file now and get back to you on that next.
2 Likes
So for the hinge example - one factor here is that this goal uses the signed angle in the plane perpendicular to the hinge axis.
This is important so you can distinguish between mountain and valley folds in origami for example, or to distinguish between convex and concave configurations for a shell. Sometimes you need to control not just the angle the hinge ends up in, but which way around it goes to get there.
It does mean though that in the special case where the rest state of the hinge has an angle of pi between the adjacent face normals, if the momentum carries it even slightly past equilibrium, it will suddenly be in a far from rest state, and will try and go all the way around again. The NoFoldThrough goal is one current way of addressing this (in your example adding this goal to the same points as the hinge with a high strength stabilises it). I’ll think though if there is any better way the hinge goal could be modified to avoid this issue while still allowing control of direction.
There are some of the goals for which the energy is not strictly convex - ConstantTension is one that comes to mind, there are probably others. These can potentially lead to spurious energy increases when used in certain ways, but I still considered them worth including, since there are ways to use them that avoid these issues.
Another goal I realised could lead to instabilities in certain cases was the angle goal, because of some strange scale dependent behaviour, and I’ve fixed this for the next release.
About the separation of the outputs: great thanks a lot! this is very useful! it’s exactly what I wanted!
But apparently it doesn’t work for the bouncy solver
About the solution to the second issue: it’s exactly how I did it, but this solves only the equilibrium state, and during the simulation, the anchor points (for example) would still move a little bit in a certain tolerance dependent to their strength, anyway it’s nice to know that you are working on a simplification of the hard and soft constraints, this is certainly isefull!
About the signed angle problem: exacly I suspected that when I firstly saw its behaviour.
If I may suggest a solution, instead of inputting a new node that limits the angle before reaching Pi, which may or may not work depending on their strenghts, I would suggest instead to make the fold angle goal node to become “signless” when it reaches for the first time the input angle, may it work? maybe could be simply added a boolean switch to that node to make it behave like it does now or like I suggested.
Another solution may be to make the fold angle goal node keeping track of the number of complete rotation and instead of trasforming Pi into -Pi after one turn, it should instead add to Pi the new angle, but maybe this behaviour is much more heavi in terms of calculation time and ram used.
I do recognise that conceptually it might seem a little unsatisfactory to use a finite value, but for the anchors, you can set the strength up to the maximum allowable double in .net (around 1e300). This is many orders of magnitude greater than needed to make it stationary for all practical purposes.
Bear in mind that due to the use of finite precision calculations you will always have deviations far greater than this in any Rhino model, even from very simple constructions not involving Kangaroo.
For instance, here’s a simple comparison -
checking the length of a diagonal against what you’d expect via Pythagoras, and anchoring the ends of a cable
accuracy_comparison.gh (16.3 KB)
The simple geometric calculation has an error 10^283 times greater than the movement of the anchors.
…and about the tree structure on the output of the bouncy solver - I didn’t yet include the same data treatment as for the regular one - I’ll fix this for a future release. In the meantime you can just use the ‘Unflatten Tree’ component to reconstruct the tree from the flattened output list (using the input to GoalObjects as the Guide tree).
