Unreliable Physics2D in Unity 5

So I've upgraded to 5.0 and everything seems to be working fine in my project except for one major thing - my edge colliders (or box colliders) aren't accurate anymore. My player regularly falls right through the ground or gets stuck on slopes. I've changed absolutely nothing relating to the physics, and it was rock solid in 4.x.

My character is a BoxCollider2D, moved by forces and majority of my grounds are EdgeCollider2Ds. Is anyone else experience behavior like this?

 

I've been having to make a lot of workaround since upgrading from 4.6.2 to 4.6.3p2 as well... A lot of interpenetration errors as well. I'm having to add invisible walls and setting some RigidBody2Ds to continuous because it's causing me a lot of issues as well. I'm assuming your and my issues are coming from the same source, since they are the same symptoms.

Another thing that is really bothering me ( Though this was the same case for me since 2D Physics were introduced in Unity ) is that they seem to be non-deterministic. I can run the same inputs towards a sequence and I get slightly different results each time... why? This is terribly unreliable. I would love to know if there's any configuration parameter I'm missing that might at least give me deterministic results.

 

Hi, thanks for the awesome reply!

I had thought the Box2D implementation in Unity was altered since I moved actors and levels from my own engine with the same settings and got different results form the beginning. When I reload levels in Unity, that is, Destroy ( I even wait some frames before spawning the new one ) a root game object with all the actors, then instantiate it the prefab, I get different responses even without doing anything. For example, a stack my fall in one reload of a level, in another time I reload it, it stands upright. What could possibly be causing this break in determinism? I'm not looking for deterministic results across processors, but rather the issues I explained. This happens right within the editor even. When I had these levels in my engine Box2D would always without a hitch cause the same simulation given the same input. Which is why I am very confused as to what might be causing the issue in Unity... Any thoughts?

 

PS : In my case ( as opposed to helios') the penetration issues began when I upgraded from 4.6.1f to 4.6.3p2. Not from 4.6.2 as I previously thought ( I just checked the older version I was working form ). So far they've happened with all kinds of colliders : circle, box and polygon. I use discrete collision detection normally, have worked around the issues by setting the culprits to use continuous. It happened in shapes which were working fine in 4.6.1f, went unchanged into 4.6.3p2 and started occurring.

 

Ah got it, I searched through the changes and I had read that, but I guess I read it incorrectly.

Any idea about the different output when instantiating the same prefab? Are the children of the prefab spawned in a non-deterministic order potentially causing the initial collisions to be "settled" differently? Would it be wise for me to take another approach at level loading?

 

Do you mean dynamically instantiating and stacking the objects individually as opposed as part of a prefab?

I remember doing different simple cases months ago, but all from prefabs ( since I save my levels as prefabs ), but promptly moved on from it after I assumed something had been changed from box2d that was causing it. Otherwise, I have not tested with individual instancing if that's what you mean.

But I'll give it a try today and report back.

 

Regards to the breaking through EdgeColliders2D - I am indeed using those, but I am not using continuous collision. Never had a problem before with discrete.

 

Hmm, that is interesting. I am also having the opposite issue where hitting the sides of an edge collider (that is, the actual end points of a straight horizontal line) sometimes registers a collision and prevents the other object from passing through. I would say it does this 30% of the time.

This happens if I am just using a simple platform effector, or even if I manually do a Physics2D.IgnoreLayerCollision() ..the object will sometimes be stopped by the corners of the EdgeCollider when it clearly shouldn't.

Could this possibly be related to the same thing?

 

Regarding the continuous collision detection fix that went in after Bennett's bug report: Shouldn't Unity just change the 2D physics defaults to collision detection in the UI, and then let people disable if they want? So update the visible defaults to match the actual behavior instead of the other way around...

 

I did a few tests today, to no avail. I still get random behaviors happening after each reload.

Here's an example of it :

Every time it flashes I'm reloading it the level on the fly. All it's doing is deleting the previous objects, waiting a ( FixedUpdate ) frame, then re-instancing the prefab.

I also tested instancing each object inside the level prefab individually but got the same results. I noticed that some of the scale vectors are being slightly altered in some of the objects for some reason when they are placed under the root level object, ( some objects randomly had 0.999 scale instead of 1 ), so I thought it had something to do with that and I instanced each object individually again and they remained at root level with no parent, I got the same non-deterministic behavior. This was done with a much simpler set-up, just 1 stack of the same object, all sharing the same physics properties. In each reload something different happened, but it was usually one of 2 exact outputs. Sometimes they either fell, sometimes they remained.

Don't know what else it could be. I'm not altering them in any way, just instancing them the same way each time.

 

I already tried not loading from the prefab and instead instantiating them by itself, like I mentioned in my previous post. I also tried not having them parented to avoid that random scaling issue I mentioned, same thing happened in every case.

I just tried setting up a stack manually, and simply going into play mode and not, several times, as you mentioned, I am getting non-deterministic behavior as well. Every time something different happens. The don't fall, or fall, and each time they fall, they fall differently as well. There are no scripts attached or running what so ever. I use 20 for both position and velocity iterations, so it should be pretty stable, though the main issue is the lack of determinism.

So in all cases getting the same problems, be it dynamically instanced or not.

 

Sure thing I have an isolated project already prepared.

 

Here's the case number : Case 682428

Thanks very much for your attention

 

Great, thanks! Do you think this will also resolve the issue of sometimes colliding with the edges of an edgeCollider with a one-way PlatformEffector? To clarify, say there is a single edgeCollider with 2 points that is perfectly horizontal with a PlatformEffector set to one-way. An object sometimes, but not always, collides and gets stuck against either corner of the platform. Many thanks.

 

I've made a small repro project and filed a bug report earlier today, but have yet to receive a confirmation email (not in spam folder). Is a delay common? Not sure if I should resend.

 

Hi MelvMay, I've submitted a bug report two times and have yet to receive a confirmation email/case number - Is there a bug with the Unity 5 bug reporter? I don't recall it ever taking this long in the past. Can I send you the package directly?

 

Thanks again for your attention!

This is certainly strange... I've been using Box2D for a few years and didn't come across any issues with determinism before without recreating the world ( I would destroy actors and recreate them as I am doing in Unity now ). Does this mean that this fix will still result in un-deterministic behavior when reloading actors in the same manner dynamically.

 

Hi MelvMay - Is there any way around the bug reporter? I've submitted it three times since Friday and the Bug Reporter tells me everything was sent successfully, but I get no confirmation email (nothing in spam folder) with any verification that it went through properly.

Is there another way to check if Unity received it? The bug is very easy to reproduce and I can send the package directly to you if possible.

 

Thanks again for your response and time! It's certainly appreciated. Please know that I'm not in a rush as I've done some workarounds around these issues so there's no sense of urgency on my part. But big thanks for your attention and help regarding the issue.

 

I've sent you a private message with a link to the test project. It appears to happen when the Y velocity of the colliding body is less than 0. There's also a quick movie file in the root Asset folder that demonstrates the issue.

Many thanks in advance for checking it out!

 

Also, I've managed to successfully submit an official bug report with Unity 5, case # 683964

Thanks again.

 

Hi Melv, unfortunately bad news. There seems to be a regression in patch 3. Bodies now snap/get pushed out again when going through one-way platforms (PlatformEffector2D). This was fixed in p1 (and I presume p2, though I never got that one), but it is happening again in p3.

 

Any update on this? Were you able to verify the bug returned? Thanks.

 

Any update on this? I didn't see anything in the change log for the latest patch release.

 

I'm also seeing the problem with 2D Colliders breaking through EdgeColliders. Unity 5.0.1.f1

My project was simple enough that I changed out the EdgeColliders for simple PolygonCollider2Ds and it seems to work. Also for any SpringJoint2Ds make sure that the EnableCollision is on if needed for colliding with connected Rigidbodies.

 

I can verify that the snapping/colliding midway through One Way platforms is fixed in the latest patch. Thanks!

Now the only major PlatformEffector bug left is case 683964
Do you know if this is actively being worked on, or put on the back burner? It's a pretty bad bug that really makes the OneWay option of PlatformEffectors pretty useless.

 

Yea, I didn't mean this very second

Thanks for the updates and prior fixes.

 

Sorry to be a bother, but any news on the PlatformEffector bug?

Thanks.

 

Hate to always be the bearer of bad news, but I noticed yet another terrible regression in the latest patch release (5.0.2p4). Confirming this also happens in 5.0.2f1. This only happens with Rigidbody2D, not Rigidbody.

Very bad and strange bug where the Rigidbody2D MovePosition function NEVER ceases to execute, even when disabling the script. This is only apparent with MovePosition. MoveRotation behaves normally. This is also a regression, my last known version where it was working correctly is 5.0.1p2.

I've filed a bug report, case #: 702390

You can easily test this though in a new project by creating any gameObject with a kinematic Rigidbody2D and attaching the following script:

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3.  
4. public class TestBug : MonoBehaviour {
5.  
6.     public bool allowMovement = true;
7.     public Vector2 speed = new Vector2( 0.5f, 0 );
8.     public float rotationSpeed = 20.0f;
9.  
10.     private Rigidbody2D _rigidbody;
11.  
12.     // Use this for initialization
13.     void Start () {
14.         _rigidbody = GetComponent<Rigidbody2D>();
15.     }
16.  
17.     void FixedUpdate ()
18.     {
19.         if( allowMovement )
20.         {
21.             _rigidbody.MovePosition( _rigidbody.position + speed * Time.deltaTime );
22.             _rigidbody.MoveRotation( _rigidbody.rotation + rotationSpeed * Time.deltaTime );
23.         }
24.     }
25. }

If you run the scene, you'll see the object moving and rotating as expected. If you uncheck the "allowMovement" flag, then you'd expect the movement and rotation to stop, but it doesn't - only the rotation does. The .MovePosition function somehow never stops being called. This is even apparent if you disable the script entirely. What gives?

Thanks.