Kangaroo issue with multi-patch membrane form-finding

Replies to This Discussion

Permalink Reply by Hyungsoo Kim on October 4, 2017 at 9:25am

Hi.

I have no idea of your details of implementation, anyway Kangaroo is working just fine for me.

Attachments:

• Form-finding patches_re.gh, 176 KB

Permalink Reply by Olivier Suire on October 4, 2017 at 3:10pm

Hi Kim,

I can't join all the curves like you did, because there are two curves where patches have a common border.

One curve is in layer "Dessus" (Top) and the other is in the layer "Dessous" (Bottom).

They need to stay in their relevant patch, hence the use of groups.

Then, you feed the "Goal Objects" input a flat list of "Locator" (not sure what that is), then "Springs" and then "Anchors", each is a separate branch.

I can see how this is different from my way of organizing data because I feed branches which represent each patch, and those branches contain both springs and anchors.

My wish was to get outputs structured also by patch, but somehow Kangaroo does not like that...

Permalink Reply by Olivier Suire on October 5, 2017 at 3:11am

I organized my data like you did, with springs and anchors in separate branches.

The result is the same : Kangaroo doesn't solve some of my patches, and just moving them sometimes make them work for some reason.

Yet, if I fix all my boundaries like you did, it works fine, just like on your image.

So I guess that my flexible boundaries are the ones posing problem here.

If I give them too little strength, the nodes all collapse.

I tried to raise the stay length of my springs but that doesn't help.

 

Permalink Reply by Daniel Piker on October 5, 2017 at 3:39am

I don't have the other plugins installed on this machine, so couldn't open your definition, but one guess it that perhaps there is a tolerance issue and some points are not getting properly combined?

Permalink Reply by Olivier Suire on October 5, 2017 at 3:55am

Hi Daniel,

Thanks for chiming in.

I'm not sure what you mean by "not properly combined".

I noticed that if I set the strength of my edge cables ("Ralingue") to zero, the cable caves in so much that nodes start to merge and the net collapses to nothingness.

I tried to reduce to zero the tolerance input of the main Kangaroo component, but nothing works in that case.

So the question is perhaps : how do I prevent my nets from collapsing ?

Thanks for your help

PS : I attached the Human and Fabtools .gha files

Attachments:

• FabTools.gha, 35 KB
• Human.gha, 542 KB

Permalink Reply by Olivier Suire on October 5, 2017 at 3:58am

...and here is the latest version with a few de-bugs.

Attachments:

• Patch Form-Finding-02.gh, 156 KB

Permalink Reply by Daniel Piker on October 5, 2017 at 4:57am

The Kangaroo tolerance setting controls how close points need to be before they are considered the same node. Depending on how your upstream geometry is generated, there can sometimes be tiny differences in position between points which should actually be treated as one.

If the tolerance is too low, then points which should be combined might end up getting pulled apart by different goals, while if it is too high, then parts of the geometry which should be separate could end up getting collapsed into a single point.

You have created a number of line segments with near zero length around the boundaries of the patches. It looks like these are causing the issue. Their ends will get combined, and you will have lots of springs between a point and itself, which leads to problems.

Also - if you have 2 boundary points anchored, it doesn't make sense to also apply a length goal between them.

If the aim is just to choose some boundary points to anchor, and set a different stiffness for the boundary cables which are not anchored, the definition really shouldn't need all this curve rebuilding and simplifying and pulling.

(finally - for plugins I'd say it is better to link to the authors' download pages rather than redistributing directly like this)

Permalink Reply by Olivier Suire on October 5, 2017 at 6:41am

Daniel, I beg to differ :

Tolerance settings : what if I don't want the points to be merged no matter what ? In my case, I am in control of the input geometry, and I certainly don't want any merging to occur.

Near zero length segments : there can't be near-zero length curves as input for the "springs" for the simple reason that they are segments of the outer boundary of the meshes I build on each patch.

Each patch edge is divided in nearly equal length segments, and the number of divisions is driven by the "U count" slider.

There are no spring goals related to the fixed borders.

I have multiple "Ralingue" layers because I want to be able to set different "strength" values" to various edge cables.

Length goals between fixed points : If you look more closely, you will see that there are only length goals on segments related to border curves in layers "Ralingue-xx" (these are the various edge cables), those related to layer "Lien" (these are articulated rigid links), and of course the warp and weft curves ("Chaine" and "Trame").

I therefor still don't understand why this is not working properly.

Permalink Reply by Daniel Piker on October 5, 2017 at 7:09am

If no points are merged at all, then you just have a load of isolated springs, not interacting with each other.

If the input points are actually the same object in Grasshopper then a tolerance of zero will work, but if they come from geometric operations such as curve evaluations, intersections etc, then even if they are theoretically the same, there can still be floating point error.

You can confirm what I say about near zero length curves - just gather all the different curve inputs you have going into Length goals, flatten and sort them:

Permalink Reply by Olivier Suire on October 6, 2017 at 2:59am

Indeed !

I didn't think that the end points could generate tiny lines, but they did, in an erratic fashion due to tolerance.

I weeded these out and now the form-finding works flawlessly !

Thanks Daniel !

Permalink Reply by Matt Gaydon on October 6, 2017 at 4:02am

Been following this thread as interested how to solve multi object simulations.  

Slightly off main topic but you can remove the point at the start and the end using just Cull Index Component.

Permalink Reply by Daniel Piker on October 6, 2017 at 4:08am

Great. Glad we got to the bottom of it in the end!

This issue of extracting the boundary edges belonging to separate sides of a mesh is one I can't see a really nice solution for with existing tools.

I think though that a variation of the code used for Kangaroo's 'mesh corners' component could be used to actually output the edges between corners.

Also, I'll try and add some sort of checking either in the solver or the length component to avoid creating goals connecting points to themselves (or at least for it not to break things if they do).