How to inflate tetrahedrons and pack them inside box

Hello Everyone,

I am currently working on an architectural project. I am trying to inflate tetrahedron inflatables inside a box and once they are inflated i would like them to pack in the most effiecient way.

I have downloaded a script and tweaked it so that instead of spheres i can inflate tetrahedrons - or practically any mesh i want. However there are a couple issues.

  1. The process takes ages - maybe because the meshes are too heavy?
  2. the meshes start protruding inside each other instead of colliding
  3. With growing pressure the meshes do not pack naturally as they would in reality. I tried to connect the gravity button to draw the inflatables to the bottom of the box, but the script stopped working. So the only way to organise the inflatables was manually using the grab tool.
  4. the script also does not work well with inflating meshes of various sizes - the small once end up being “absorbed” by the bigger ones and that is a shame.

If you please have any ideas on how to help me with the points above i would extremely grateful. I attach some images and script below.
Thank you
Niki


200409 rhino file.3dm (117.6 KB)200409 tetrahedrons inflated inside box.gh (19.7 KB)

For collissions you would need to use RTree search or OctreeTree Search in Point Collide goal.
It also depends on you tetrahedron resolution, maybe you can use less points for k2, and then subdivide the k2 output.

@DanielPiker does point collission goal already have a closest point search method?

I remember @dave_stasiuk had a version for colliding spheres in a custom kangaroo goal.

Hi Nikca and welcome,

I’ll look at this some more, but one of the first changes that occurs to me would be to start with the meshes inside the box, and gradually increase their size/pressure. Alternatively if they have to start outside, start with the goal pulling them to inside the box very low strength then gradually increase it.

At the moment they start quite far outside, so at the first iteration they are suddenly being pulled a long way in one go, which can easily lead to them folding through themselves, or passing through each other.

I see you are using SolidPointCollide for interaction between the tetrahedra, which keeps the points of one mesh outside the other mesh. If the 2 meshes that are colliding have similar edge lengths this can often be enough, but if one has much shorter edges you can get a situation where some of the points of MeshA are on the interior of MeshB but not vice-versa. In this case it might help to switch the data matching in the cross-reference component to ‘Diagonal’ so that it applies this collision both ways between each pair of meshes.

Alternatively using the SphereCollide component could be a way to approach this, as I think @Petras_Vestartas is referring to, so instead of checking for mesh collisions directly, you treat each vertex as a solid sphere with a radius somewhere around half the length of the connected edges. One issue with this is that you end up with a slight offset between the meshes instead of them exactly touching, but you can usually just apply an outwards offset to counteract this.
It does work best for meshes which all have similar edge lengths, so you would probably need to apply different levels of subdivision to each of your tetrahedra depending on their size.

Petras - to answer your question, the SphereCollide and Collider goals do use some spatial sorting to avoid checking distances all-to-all. It’s a basic sweep and prune though, not RTree or Octree. I keep meaning to have another look at this and see if one of those would be faster. You were doing some with RTree right? how were you finding the performance compared to the existing goal?

1 Like

I tried both RTree and Spatial Grid. Spatial Grid seems to be a bit faster, but honestly just slightly.
Rtree would be easy to add from RhinoCommon.

And for spatial grid this is original publication:
https://www.researchgate.net/publication/2909661_Optimized_Spatial_Hashing_for_Collision_Detection_of_Deformable_Objects

2 Likes

Thank you both, i will try and translate your advice and then get back :slight_smile:

I adapted the mesh point collide goal by @DanielPiker some time ago to accept a list of meshes that should collide with one another. It’s not doing anything very sophisticated other than doing bounding box testing to help speed it a bit, but it makes for an easy setup.

I’ve adapted your definition with it…also implemented Daniel’s advice to manage your constraint box differently. Here it starts outside the bounds of your initial tet collection, and then you “shrink” it while the simulation is running.

Hopefully this is helpful!

200410 tetrahedrons inflated inside box.gh (39.1 KB)

4 Likes

Hi All, Thank you so much for your tips @DanielPiker @Petras_Vestartas. and for the script @dave_stasiuk . First i tried to translate all your tips - such as starting inside the box and smoothening the meshes after going through the solver - which helped. The biggest difference was when i changed the cross reference to diagonal. Then the objects stopped protruding into each other.

I am just looking deeping into the script you have sent me @dave_stasiuk to understand it. I am not an experienced Grasshopper user :grin: but it does wonders and it much quicker then before - i can actually be much more productive now. There is just one thing i was wondering how to do which is how to draw the tets to the bottom of the box to imitate gravity.

Thank you.

Use the Deconstruct Mesh component on your tetrahedrons and pass the vertices output into a Load component in Kangaroo. Set the directions and amplitude of your force vector, and you should be good to go.

1 Like