Cubes getting stuck "in" eachother

Hi and thanks for reading!

I am prototyping a game and have very quickly run into a problem. I have a bunch of cubes dropping onto each other. The cubes have rigid bodies attached, and I have constrained their movement and rotation so that they only drop and rotate like in a 2D game (removed the depth). Some of the cubes seem to get stuck in each other, where the some of the cubes penetrate another one. This is of course breaking the entire gameplay mechanic.

I tried to set the collision to "continuous" but that did not seem to do anything. I hope you have a good tip or two for me in cases like these

 

Short answer: If the game is grid-based, don't use the built-in physics system, but instead handle the collision detection yourself.

(If the game isn't grid-based, perhaps you could clarify how the gameplay mechanics work.)

 

The game is not grid based, but there is a bunch of cubes (and later other types of geometry) stacked in various combinations on top of solid geometry. Some of these geometry types can be removed by simply clicking on them. The idea is to get all of the X colored cubes to fall of the map, while the Y colored ones should not.



As you can see in this picture some of the cubes intersect, which yields the flickering texture problem (and of course breaks the gameplay).

 

Ok, gotcha. I don't have any suggestions/ideas off the top of my head, but I'm sure someone will. (Nice art, by the way

 

Thanks for the compliment, and thank you for trying at least

 

Does reducing the value for "Edit->Project Settings->Time->Fixed Timestep", or increasing "Edit->Project Settings->Physics->Solver Iteration Count" do anything to improve/fix this issue?

 

Solver Iteration Count made everything behave weird (lots of intersecting and weird bouncy movement), but setting the Fixed Timestep to 0.002 instead of 0.02 made it a LOT better! There are still a lot of intersecting cubes but they are not stuck as far into each other this time. Not sure if they stick together though, will have to test that after I add some more mechanics.

Thank you tomvds!

 

Note that increasing Fixed Timestep to that amount is probably not a long-term solution. A fixed timestep of .002 means that FixedUpdate runs 500x per second. When your games and game content become larger, maintaining such a high frequency is probably not possible, especially should you be targeting platforms like the iPhone.

If your cubes intersect and remain in that state, there is probably something else wrong (I would expect intersecting cubes to be pushed apart by the physics system). What is your exact physics setup (collider types and their settings, rigidbody settings, joint types and their settings)? Are you using scripts on the cubes that modify the transform.position, transform.rotation or transform.localScale of the cubes?

 

This is easy to reproduce;
1) Set up a bunch of cubes (Unity default cubes), set size to 1,1,0.1
2) Add rigidbody and set rotation/movement constraints: Freeze Position Z, Freeze Rotation X, Y
3) Set the collision detection to Continuous.
4) Position a bunch of them on top of each other and make them drop on top of each other.

That's about it, really. My scenes will be extremely simple though, with 10-20 cubes in total and a backgound. That's about it, and some VERY simple scripts running. No movement manipulation at all.

 

If it's 2d depth wont matter, so try making the depth larger. Also try making everything bigger (if the cubes are small).

 

Big and small are relative terms. I have now set up the cubes to be 1,1,1 (Unity units, which translates to meters I guess). It still happens. I have no added some flip-gravity functionality and the result is that some of the cubes simply doesn't move cause they are stuck. This seems pretty weird, since I am not doing -anything- extraordinary, and this is killing my game

 

Technically, Unity units are 'unitless'. That is, one world unit is just one world unit.

If you're really stuck on this, you might consider posting a minimal project (as a Unity package) that demonstrates the problem, so that others can check it out.

 

I'll do that Jesse. Unfortunately I only got 10 minutes and then I'm off for a short vacation, so I'll do it as soon as I get back over the weekend

 

Alrighty, I'm back and luckily(?) I was able to reproduce the problem. I'm not 100% sure how to make those Unity packages so that it exports everything you need, so instead I zipped the project folder. It's only 140kb, and available for download here.

How to use:
- The yellow button flips the gravity around.
- The green button resets the level (and gravity).

Let the cubes fall and land on the floor, then flip the gravity. In many cases some of the cubes will be stuck and unable to move.

Edit: I noticed that my cubes did not have "Continuous" set on collision detection. I changed that and it made little to no impact.

 

Isn't it the other way around?

I think the problem is that the cubes are going to sleep, and changing the gravity isn't something that prompts Unity or PhysX to wake them up. I changed the 'flip gravity' script to the following:

Code (csharp):

1. function OnMouseDown()
2. {
3.     Physics.gravity = Vector3 (0, 9.81, 0);
4.    
5.     var rigidBodies : Rigidbody[] = FindObjectsOfType(Rigidbody) as Rigidbody[];
6.     for (var rigidBody : Rigidbody in rigidBodies) {
7.         rigidBody.WakeUp();
8.     }
9. }

And that seemed to fix the problem.

Was that the only problem you were having? I didn't notice any interpenetration or anything like that.

 

You are 117% awesome, thanks alot Jesse! I had no idea you had to "poke" those rigidbodies to make them move, I always assumed that they were always active. Again, thank you very much, I'll include your name in the credits

 

Hehe, that's not necessary - I'm glad you were able to solve your problem though

 

Found this thread via search, and thought I'd share a solution for others who might stumble upon it.
This intersecting objects bug is still present in 3.4.2. I managed to fix it by using basic colliders instead of mesh collider. Might be a bit clunkier, but it is faster and it works