# Stacking 2d Box Colliders and similar

I am creating a game very inspired by the board game “Drop It”: Drop It | Board Game | BoardGameGeek

It is a super simple but fun game where you drop geometric shapes on top of each other.

I have tried to recreate it and it is very simple to get going but the physics really quickly get unstable. A typical example is just stacking 4-6 rectangles with 2D Box colliders on top of each other. Suddenly some piece start sliding. I cannot understand where the horizontal forces are even coming from?

I have played around with some of the physics settings but I am not getting better stability then the default settings. Is there some best practice to get as accurate as possible. Since at most I will have maybe 50 rigid bodies I assume it is a rather small system to the performance should still be ok?

Any tips or links to good reference material would be appreciated

Use continuous collision detection, ensure they all have the same or similar masses, increase the solver iterations, use an appropriate physics material, use correct scales (make sure these are not mountains) so the forces are not huge.

Take a look at my physics examples here. There’s basic stacking scenes testing stability for boxes, circles, capsules etc.

Thanks for quick response!

I did pull your excellent examples. Great summary!
But I can still see that you also have some horizontal movement on the squares in your examples. Not alot but some. Maybe it is unrealistic to expect none in a game engine ridgid body solver?

I don’t see any sideways movement myself unless you mean that the X value changes by fractions of a millimeter. Not sure.

That said, try dropping a block on another block in real life and not getting any sideways movement.

Yes that was the movement I was talking about
Checked you example again and the top box is at X-position: 4.400033 and the bottom one at 4.416188. Assuming the scale are in meters that is a diff of 16 mm.

Why would there be any forces in the X-direction at all in the example? Is it floating number rounding error or what do they come from?

Regarding the real-world example, if you have a 0 bounciness material with decent friction in “real world” I would be surprised to see any horizontal movement. But I might be incorrect.

Thanks again! I think I need to be realistic about the expectations.

Edit 2: Just did see that it seems to be the exact same slide distance for each column. So it does not seem to be random.

Likely what is happening is very tiny rotations due to float precision when the first set of boxes hit the ground.

Single step and when they hit, one of the corners likely causes a tiny rotation in Z. Subsequent boxes then hit a slightly rotated box (maybe thousands of a degree).

If you go to the prefab being spawned (“square”?) and constraint rotation (Z) on it and it’d likely stop those tiny movements because there’s zero rotation.

Alternately, depending on the effect you’re looking for, you can instead constrain the X position so even if there were a tiny rotation, the X position won’t really change.

Finally, although a tad more advanced, you can massively reduce this by reducing the global “Max Linear Correction” to “0.0001” (minimum) but if you do that, you’ll find that stacked shapes will compress into each other because you’re hindering the correction algorithm however, if you do this AND change the things that come to rest by changing the Rigidbody2D body-type to Static then the only things this’ll affect are the things falling and currently coming to rest.

Actually, doing this by changing to Static when its come to rest is a great way to get performance back because the things simulating are only those falling.

Without position correct on stacked dynamic bodies, you’d get the following less-than-useful effect but not so if the lower things are Static:

All that said, I don’t see how the tiny movement you see here would be any issue for the game example above.