2d: A "Weighty" issue. Boxes pressing down on each other

Unity Engine
1

Hi

I’m using 2D physics to control some boxes that fall from above to the ground and on top of each other. I didn’t want them to rotate on land, so for the box prefabs I have the following settings on its Rigidbody2D:

“Fixed Angle” checked. Mass of 0.0001, Linear drag 0.7, Angular drag 0, Gravity scale 0.05 and continuous detection, interpolate set to ‘interpolate’

When the first few boxes hit, they are fine and sit nice and still. However, the more boxes fall and it builds up (on top of each other) they start weighing down on each other and pushing the ones below them off to the sides (don’t want this to happen - i need them to remain still).

I tried switching on isKinematic once they had stopped moving, by tracking their speed via rigidbody2D.velocity.magnitude, however, if a box is removed from the bottom of the pile and I turn the isKinematic back on for all the boxes, my code is very buggy in ensuring that they stay false for isKinematic until they’ve resettled. (Sometimes a box ends up hovering above the others, with its isKinematic set to true too early (according to its speed).

So I would prefer to use the physics without using isKinematic, but i can’t find a solution to stop the weight of the boxes from pushing lower ones out.

Oh, I also have a material on the collider with friction set to 200 (is that right??) and bounciness to zero.

Would it be something to do with my projects Physics2D settings?

Thanks for any advice or direction!

Cheers

2

If you ever tried to implement your own physics simulation, stacking rigidbodies is where things start to get complicated really fast. This is actually very computationally intensive, I mean, stabilizing multiple boxes stacked on each other.

You can improve it by increasing the position and velocity iterations (Edit → Project Settings → Physics2D). But there is only so much that Box2D or Physx can handle.

3

OK, thanks Manny. Looks like I’m gonna have to keep with the isKinematic on method then? Or is that still computationally expensive?