Output mesh from one Kangaroo engine to provide input collision mesh for second engine?

Dear all,

this is my first post, please be kind.

I think I've read most of Daniel's comments about the limitations of collision meshes in Kangaroo (i.e. one has to be a passive Rhino object). In the attached file, I've tried to stitch two examples together such that the output mesh of an inflated cushion defines the input mesh for the CollideMesh for a second drape routine. Naturally, the attempt has failed. I suspect that it is down to the limitations as have already been described and documented.

I'd be ever so grateful if someone could let me know in principal whether at all this should be possible in Kangaroo. From what I've read and from people I've spoken to it seems not, but I could be wrong? I'm just looking for an expert opinion on the feasibility.

Many thanks in advance!

Greg

Attachments:

cushion+drape.3dm, 118 KB
cushion+drape.gh, 26 KB

Replies to This Discussion

Permalink Reply by Anders Holden Deleuran on September 7, 2015 at 7:49am

Hi Greg, Just jumping in here regarding the instabilities you've been experiencing. I've noticed this occur myself whenever the discretized bending member has one or several "very short" segments. A workaround has been to lower the bending strength (or Angle goal strength assuming that's what you're using) till this behaviour stops. I'm not sure if this is a question of numerical instability/floating points, or, a fundamental aspect of defining a bending rod using the Length/Spring and Angle/Spring goals in combination. Best, Anders

PS. Looks awesome :)

Permalink Reply by Gregory Quinn on September 7, 2015 at 8:30am

Hey Anders,

thanks a lot! Yes, we saw similar behaviour to this when you were here. Hmm... ok then I will need to check my segment length variations. But I wonder if the threshold is known...

While reducing the angle strength (bending stiffness) for stability is fine for a test, I can't do this later because values will be based on real properties. If I've understood the units correctly, then I will need to input a bending stiffness value of around 5625 [Nm2] - which is clearly comparatively much higher than other "strength" values in the system.

Also, just for fun... this THING grew when some of the beam elements got caught by the floor - bleurgh: http://makeagif.com/i/OBftHv

Best,

Greg

Permalink Reply by Gregory Quinn on September 8, 2015 at 3:07am

Right,

I've cleaned up my polylines such that the smallest-to-largest element ratio is now about 1:8.

This has clearly stabilized the dancing beam ends. Check out this smooth operation (calculation time just over an hour):

http://makeagif.com/i/EQiV6a

But as soon as I increase the bending stiffness to more than 2 Nm2, the system becomes unstable (bending angles constantly fluctuate and adopt a zig-zag pattern). I wonder what is causing this? If it is indeed the relative weighting factor compared with other goals, then calibrating Kangaroo to real world properties may become quite tricky. I'm sure Daniel will jump in any time now with a helpful explanation and suggested solution! :)

Regards,

Greg

Permalink Reply by Eike Schling on November 27, 2015 at 2:47am

Hi Greg,

Great to see your progress from this post, to your presentation at the Membranes, Barcelona in October!

I would like to join your question about material properties:

"For the sake of carrying out further experiments, I will need to be able to calibrate the performance of materials with real mechanical properties. I look forward to seeing to what extent this is possible. The Kangaroo documentation explains what units and inputs are used and so I think some level of calibration should be feasible."

Have you had any further insights? What is the current most detailed documentation of material properties and units for kangaroo 2?

Cheers,

Eike

Permalink Reply by Gregory Quinn on November 27, 2015 at 3:50am

Dear Eike,

thank you! Yes in fact we are making good progress on this front! Kangaroo 2 goals can indeed (and usually are) scripted such that they are based on real-world mechanical properties. Daniel does list most of the input units in the K2 documentation. I have been carrying out some extensive calibration checks which validate the mechanical accuracy of K2. I hope to share these soon (either on the forum or with a publication if suitable). Bending and axial stiffness are both working accurately.

But basically, yes K2 is proving to have a lot of potential for engineering applications. Watch this space! :)

Greg