Grasshopper

algorithmic modeling for Rhino

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

Views: 5619

Attachments:

Replies to This Discussion

Hi Greg,

Using the results from one simulation as the inputs to a second is possible. Of course this will be a strictly one-way interaction though.

The main issue I see though is that your definition contains some components from Kangaroo 2, and some from 0.099.

Kangaroo 2 uses a new solver, forces from versions before this cannot be input to it, or vice-versa.

I do still recommend keeping both installed, as this will allow opening definitions made with the earlier version, and also the mesh utilities from the old one still come in useful, but be careful not to mix forces/goals from the different tabs.

In your definition if I run then pause the first simulation, and connect the CollideMesh component (but not the SPC one) to the solver of the second simulation and run that it gives this result:

Dear Daniel,

thank you ever so much! Yes sorry about mixing up the components from 0.099 and 2.1 - I suspected as much.

Despite my many efforts to reproduce what you describe, I can't seem to get the interaction in your screenshot. Despite pausing the first engine, my drape is sailing right through the bubble... I'll keep trying.

But thank you for the answer, however if I have to pause the first engine then I'm not sure I can use it for my intended application (lifting objects up via inflation in a live simulation) ... unless there's another way (e.g. using the collision spheres)?

Again I'm just in search of an answer on feasibility, no more.

Gratefully,

Greg

Pausing the first engine is not actually necessary - you can also use a changing mesh in the collision component.

If you want the weight of the draped cloth to affect the geometry of the inflated form, one way might indeed be to use the SphereCollide and put small spheres on the vertices of each mesh. This does require that the edge lengths be fairly even though, and introduces an offset between the surfaces of the diameter of the spheres.

I'm still a little way off adding full mesh-mesh 2-way collisions, but should have 2-way mesh-point collision ready soon (this allows approximate mesh-mesh collision by stopping the vertices of one mesh going inside the other, but is only accurate for fairly smooth meshes)

Hello again!

So I've been experimenting and making some progress! ... and I would love to receive some input again.

In the attached routine:

- the grid shell works

- the inflation works

- the interaction and collision works

... but the self weight of the grid shell doesn't influence the cushion below because it's running on downstream (and subsequently passive) Kangaroo2 engine.

Can anyone think of any way to let the self weight of the grid influence the cushion below?! I can't figure out SphereCollide - but perhaps that might be the key. Or perhaps it just isn't possible yet?

With thanks and bated breath,

Greg

Attachments:

Good timing! - see the new release just this afternoon:

http://www.grasshopper3d.com/group/kangaroo/forum/topics/kangaroo-2...

in particular, the included example file MeshMeshCollision.gh

Wow, that demo looks fantastic! What a great addition to the repertoire!

I've tried to adapt your demo for the grid shell... but it just sails right through. I can't figure it out... I've tried several configurations :(

Would really appreciate you having a look.

Thanks and regards,

Greg

Hold that though!

I hadn't defined a "solid body" for the collide input, apologies. It's working now.

Incredible!!

I'll upload a decent routine in the spirit of sharing as soon as I've got a good version.


Best,

Greg


Hello again,


as promised, I'm uploading a clean and stable version of my little collisions experiment (strained beams + pinned connections + collisions + air-inflated balloon + floor).

I have to say, since only starting with Grasshopper and Kangaroo two weeks ago, I've had a lot of fun making this and it clearly works very well! I'm very impressed and can't wait to experiment some more.

The speed of the simulation clearly suffers at this level of complexity, but I suppose you could set up an timer-stepped routine to control the speed of iteration?

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. I imagine that the use of the word "strength" in Kangaroo was selected because to non-engineers it is more intuitive - but the engineer in me would prefer to see the word "stiffness" used where appropriate. Furthermore, the units of "I" for bending stiffness for the angle component described in the documentation I think should be [m^4] and not [m]. I wouldn't be mentioning this if I didn't get the impression that Kangaroo wants to embrace engineering analyses and projects?

Thank you again, Daniel for your great support!! I look forward to carrying out more engineering experiments in Kangaroo. This really feels like it could and should be the future of structural engineering simulations.

Regards,

Greg

P.S. I would like to know how the Volume component is working. Is it modifying pressure (force) on particles according to Boyle's law of proportionality? It certainly seems to be behaving as such. What then, is the "strength" input here?

GIF animation - click to open:

Attachments:

Hi Greg,

Thanks for sharing. Great to hear about your experience with this.

I think the collision is mainly what is slowing things down here. I have some ideas about ways of speeding this up, but they will take some time to implement.

The StepByStep and CustomIteration examples in the Scripting folder of the examples show a couple of ways of iterating without the timer that could be useful once the simulation complexity is much greater than what is possible in real-time.

A few minor things I noticed in the definition which will be slowing it down slightly - ClampLength is used in some places with the upper and lower limits set the same. This is just like using the simple Length goal, but introduces some unnecessary checks. Also, it doesn't look like the mesh is deforming enough for self-collision to be an issue in this example, so maybe this could be left out.

Also, piping curves for preview is quite heavy, as it generates NURBS. I recommend using Mateusz' handy mesh pipe for a lighter preview geometry.

Making this useful for engineering is absolutely the intention, and allowing the stiffness to be calibrated with real world units is a big part of this. The length and angle goals should already be, and for the other elasticity related ones (hinge, soapfilm, volume/pressure) it should be possible, but needs some thought. I'm also working on a write-up of all the methods used, which will hopefully make it easier for people to carry out their own checks and validations.

You are right about the units for I - it should indeed be m^4 as you say. I'll update it in the docs - thanks for pointing this out.

Dear Daniel,

 

thanks also for your reply! Thanks for the visualisation tips. This is a very interesting discussion for me so I hope I can sustain your interest too. A few comments/reactions... I’d be very keen to hear what you think:

 

- A write up of your methods would be great. It would be fantastic to understand a bit more about what is under the hood. When do you think this will become available?

- In particular, can you say how the volume function works? Does it relate pressure to volume (according to Boyle’s law?)

- If I am to use Kangaroo to perform simulations and tests for my research topic, I will need to be able to describe at least to a satisfactory level how the caluclation is being carried out. I’d be prepared to carry out some calibration tests to compare Kangaroo results with my FE model – perhaps there is mutual interest (and publication potential here). Maybe an off-forum topic?

- For the balloon I made use of the springs (with low stiffness) and the clamp length function because I don't want them to offer any resistance under compression, but I see your point. I still need to figure out the best approach here.

- The self-collision of the balloon will be important when I start to try to “lift up” the grid shell via inflation – although early tests seem to result in clipping issues between the deflated cushion and the lattice resting on the floor. Perhaps mesh density could solve clipping issues.

- Interestingly it seems that it’s not the collisions that is slowing the simulation. Instead there seems to be a strong correlation between bending stiffness and calculation speed (the higher the stiffness, the slower the speed). Bending is clearly computationally demanding.

 

Kind regards,

Greg

Dear Daniel,

I've been experimenting with the above a bit further...

The volume component is just great. It's quite comfortable with large and dense meshes, and simulating "inflation" works a treat, really impressive and fun: http://makeagif.com/i/bAFelo

The principles above (of bending beams interacting with an inflated cushion) can seemingly be successfully upscaled - see attached gh file.

However, if I want to increase the "strength" of the bending angle higher than "3", the whole system becomes unstable - energies seemingly not able to converge. Furthermore, some tips of my members are always jumping irregularly. I imagine this is due to their shorter lengths - but the differences in lengths are not huge, and so that surprised me a little.

I wonder if you have any ideas on how to stabilize this simulation? If it can be stabilized, I will attempt to calibrate its mechanical properties (for which I may need your help or documentation). Currently, each iteration takes between 10 and 30 seconds to complete - which I don't mind, especially if I can control each iteration step with an Anders-like script.

I hope you can find some time to feedback on this. It will be greatly appreciated, as ever!

See you in Copenhagen.

Greg

Attachments:

Hello again,

a little update.... Here's an animation showing the interaction working beautifully: http://makeagif.com/i/UfsyKA

Really incredible what can be achieved with Kangaroo with such small input setups. This simulation took about 1 hour in total to compute. So it's no quicky. But that's fine.

In this animation you can see the unstable beam ends twitching. Any ideas here? Also, as I mentioned I can't increase the bending stiffness. I'd love to discuss this further with you Daniel, if possible :)

Kind regards,

Greg

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service