Concave Geometries With RBD

[noonoo]

Hi There,

 

I have a collection of objects that I drop from above so when they collide they are supposed to entangle with each other to some extent.

 

The shape of these objects are 3D plus signs but for some reason, they only touch each other as if what is simulated is not themselves but their bounding boxes.

 

How can I fix the file so that it simulates these geometries specifically but not some arbitrary boundaries around them?

 

I attach the file here

 

Thank you in advance

201104_RBD_Examples2.hiplc

[Alain2131]

Hello !

So, by default, Bullet creates a Convex Hull for each piece of connected geometry.
Because you Boolean'ed the plus model, it's a single piece, thus making a single Hull.

You can visualize this with "Show Geometry Representation" in the Visualize tab of the rbdbulletsolver node.

If we disable the boolean, the hull is replaced for something better-suited to your requirement.

But we now have a problem. The rbdconfigure creates a piece for each "connected components", or "geometry islands". In this case, instead of one piece per plus, it's 3.
You can see the Packed Fragment goes from 31 to 93 when we disable the boolean.

Thus, when simulating, we'll have plusses falling apart as individual cylinders. Not quite what we want..

The solution is a name attribute. The default behavior of the rbdconfigure is to create a piece for each connected component, but if there is a name attribute on the geometry, the rbdconfigure will use that to create the pieces.
We can (and will) use that feature to specify what cylinders refer to which plus.
It's actually quite easy, since you copy the plus on some points. You can copy an attribute from the points to the plusses. So, we can add a different name attribute on each copy points, and transfer that name on the plusses.
In an attribute wrangle, running over points → s@name = "piece_" + itoa(@ptnum);
You'll have to specify to your Copy Stamp to copy the name attribute.

After doing that, the rbdconfigure will go back to 31 pieces.
You'll notice that the collision stays around the individual cylinders.

Note, the "Show Geometry Representation" parameter slows down the viewport considerably, so only enable it when debugging stuff.

As a recap, because we know how the solver generates the collision (a convex hull around each geometry islands, even in packed geometry), we utilize that fact and keep the tubes separated in the plus models.
To "merge" them, instead of the boolean, we put a name attribute on them, leveraging the copy node as well as the rbdconfigure (since we know that it creates a piece for each name).
I hope that makes sense.

Sorry for the long-winded explanation.

201104_RBD_Examples2.hipnc

 

P.S. Concave geometry is a recurring issue. We have to resort to multiple hacks to get around it. One trick I used in the past is fracturing the geometry in complex areas to force the solver to create a better representation of the geometry. This is the same base concept as your case, to separate the geometry in chunks to give the appease the solver's demands.
There are multiple other possibilities as well. VDBtoSphere and use that as collision, providing a custom volume for the collision (when applicable)..

Edited November 5, 2021 by Alain2131

[noonoo]

Hi Alain,

 

Thank you very very much this is a crazy good explanation, really appreciate you took the time to explain in detail, I learnt beyond the question I asked.

 

If not too much to ask, could I ask how I could incorporate friction between these 3D plus signs as a parameter to play with so that based on different friction values I can test different architectural structures based on their assembly? So the more the friction, the bigger the spans..?

 

Thanks again!!!!!

 

 

 

 

[Alain2131]

Hey,

there is a friction parameter on the rbdconfigure

Alternatively, you can change the "Material" type, which gives you a nice default for different types of concrete, glass, wood or metal.

You can see the different values update as you change the preset.

Keep in mind that the Ground Friction is also a factor (but it looks like you've already played with that, so nothing new here).

You might want to increase the Solver Substeps at a certain point for more precision, if needed. 10 by default, I'd use 50 if I needed more precision (no need to go to 200 or whatever with this type of scene).
The Substeps amount is dependent on a lot of factors (including how long you're willing to wait =P).

[noonoo]

Hey Alain,

 

Thanks again for your reply. I wasnt aware of the material feature.

 

Though, I was aware of the friction parameters you mentioned but for some reason they seem to not create any difference despite what the parameters - I am talking about friction across different components not the ground one -

Is it about the polygon count of the geometry or basicaly just solver substeps?

 

Thanks!