2017.2 physics broken

Upgraded our game to 2017.2 and experienced a lot of problems. Certain colliders didn't register collisions, collisions on certain colliders when using a raycast from screen space were totally inaccurate. We rolled back to 2017.1. Anyone else experience weirdness with physics?

 

Are you using the same physic fixed time?
Edite>ProjectSettings>Time>Fixed Timestep

 

We didn't change any settings. Also I'm not sure if that would make a difference if it was changed because the collisions are never accurate. Its not like sometimes they are and sometimes they aren't. For example I have a BoxCollider that is not moving and when I raycast using ScreenPointToRay the data I get back is completely wrong.

Thinking more about the problem, the only thing slightly unconventional about our collider setup is that we have multiple BoxColliders on each gameobject with only the active ones enabled. This is part of a generic pooling system required for the game we are making. It would seem that the physics system is identifying colliders that are disabled in some cases and missing the enabled ones in other cases. Just a guess though...

 

Hmm. I updated and tested my scenes, they seem to behave normally. However I don't do any on/off stuff with colliders. Maybe build a simple repro scene and try to duplicate the issue.

 

Physics collision between default Fixed Timestep 0.02 and for example 0.005 is completely different. Double check that and what is better for your game.
From where are you passing from? Unity 2017.1? Because physics was updated to 3.3.3 in Unity 5.5.
Isolate the problem: Try to take out all except for the problem and compare it in the 2 Unity Vr. If you notice differences, then download Unity 2017.3 beta compare one more time and make a bug report there.

 

Physics also "broke" in our game when updating to 2017.2 . In a nutshell, the same force is "stronger" now, so the force values we were applying are completely off now and we'll have to reconfigure everything. This cannot be seen on small forces, but the higher the force amount, the bigger the difference.

 

If you're sure this is happening it must be a bug in Unity. I'd recommend you to roll back to the previous version, but not to reconfigure everything. If the bug gets fixed later, you'd have to reconfigure everything once again.

A force is a very simple and defined effect, with very little room for mistakes other than the tiny numeric inaccuracies. Maybe the physics is not simulated accurately with respect to the fixed time step, which would be definitely a bug.

 

Unity Technologies did some (major) changes to their physics system, see the physics document here. I did encounter various issues during the beta cycle as well.

It's very likely they didn't test your use-case and thus don't know it's broken. I highly recommend to submit a bug-report, following the advice given in this document.

If you don't submit a bug-report, don't assume they're going to fix this issue.

Using the bug-reporter seems to be an important step, because it makes sure the report is in Unity Technologies bug-tracking pipeline and has to be processed at some point. Using the forum is often used to add to a little more attention to a bug-report, but does not replace submitting the bug-report.

It's from advantage to attach a project to the bug-report that UT can use to reproduce the issue and test their fix against. The easier an issue can be reproduced by QA, the more likely it is to get forwarded to a developer, who might or might not work on a bug-fix for that at some point.

After you submitted the bug-report, you receive a confirmation email with a Case number. UT often asks us to post the Case number in the forum thread, which allows them to find that bug-report if they look at your post.

Following these steps will increase the chance that UT is looking at your issue tremendously.

 

Following what Peter77 and Edy wrote, I will file a proper bug-report on Monday.
I confirm that physics forces seem to be roughly 10% stronger than they used to be.
Which is why strong forces/velocities, say a cannonball being fired to hit a target, are completely different, while small ones are barely different compared to before.

 

100% broken Tilemap Collider 2D on mobile builds.

 

I recommend to submit a bug-report, see here:
https://forum.unity.com/threads/2017-2-physics-broken.499886/#post-3253577

 

It's already submitted by another users. They know about that since September and now it's fixed, but will be available only in 1st 2017.2 patch.

I don't know the exact date.

 

Physics is broken on my end with the new update too. I'm working on a top-down 3rd person game with rigidbody.moveposition moving a capsulecollider along a plane surface. The movement grinds to a halt when making turns before starting again and if gravity is enabled, I can't move in the z-axis for some reason. Rolling back to 2017.1.2 resolves the issue so I'll be waiting for the devs to get their S*** together and release a patch.

 

same in 2017.2 the collider appear broken on objects without renderer, event doing toggle enable of the collider does not fix it, only way to fix it is manually enabling and disabling the collider in the editor, so rolling back to 2017.1 until someone push a fix

 

After the update, Physics2D joints are almost completely unusable. Very very unstable, jittering most of the time. Tried fixing in a number of ways, but in each play session eventually the joints flip out.

 

Glad I'm not the only one... or maybe I'm not. Now I don't know.

Anyway, just wanted to add that when used pooled objects that are activated/deactivated frequently eventually Unity completely looses track of where the colliders are. They appear to be in the correct place in the gizmos view but auto-aim systems and collision events say otherwise. I have characters aiming at the completely wrong place, firing, and hitting their targets! I've tried fiddling with the new AutoSyncTransforms, timesteps, and collision detection modes. Nothing helps.

 

Still can't make a simple example case so I've filed a bug report with a stripped down project included. I actually sent one last night but my dumb self included the wrong email.
Case 962465

Basically, after some combination of parenting, unparenting, activating, and deactinvating a gameobject, its colliders stop following it and become stuck in the worldspace location where the gameobject became active. If you disable/enable the collider in the inspector it will snap to the current location of the gameobject and stay there. If you change any of the colliders properties in the inspector (script won't work) then the collider will begin working as normal. The collider gizmo will not reflect any of this - the only way you can tell what is happening is through collision callbacks and raycasts.

This basically makes physics useless in any real-world project.

EDIT:
I just noticed that this happens with my NPCs that have colliders attached to their root along with a navmesh agent. If I attach a rigidbody to them, the problem goes away. not sure if this works for nested colliders or not.

 

I also had problems with Physics2D joints when upgrading. It turns out that the joints were not properly adapting to the scaling that I was applying to the Rigidbody2Ds (I'm not sure if this was officially supported in previous versions, but the code did work in the past, so maybe I was just lucky). I fixed it by doing joint2D.enabled = false and then immediately setting joint2D.enabled = true whenever I change the scale. Everything works fine now. Previously I was not having problems related to this.

 

Got a reply back about the bug I submitted. It is apparently a duplicate of this
https://issuetracker.unity3d.com/is...if-it-was-disabled-on-start-and-enabled-after

Supposedly, it has been fixed in a beta build of 2017.3

 

Can you expand this solution? did you change the scale of the model into 1:1? or what how?

 

I was changing the scale on the Transform attached to the GameObject that has the Rigidbody2D (not sure if this applies to 3D).

So, for example, I would do something like this:

gameObject.transform.localScale = Vector3.Lerp(gameObject.transform.localScale, new Vector3(1,1,1), Time.deltaTime * k);

Where gameObject has a Rigidbody2D, a collider, and any Joint2D such as a FixedJoint2D. I would also usually try to update the Joint's information to take into account the change in scale. However, it seemed that the joint would maintain its old information, or possibly just get screwed up. The joint would highly distort everything, sometimes making things jump around. This did not happen in 2017.1 but does in 2017.2. However, if I simply disabled and re-enabled all the joints attached to the GameObject that was scaled the joints work fine (just two lines: joint.enabled = false immediately followed by joint.enabled = true). In order to be extra certain, I disable/enable any joint whose origin Rigidbody2D or whose connected (target) Rigidbody2D scales.

However, I'm not sure if scaling the Transform on a Rigidbody2D is something that should be done, because I know that messing around with the Transform (rather than going directly through the Rigidbody2D, such as using Rigidbody2D.MovePosition instead of Transform.position) often messes up the physics system, but I couldn't find any official way of doing it.

 

Something is definitely broken. After upgrading our project from 2017.1 to 2017.2, we had multiple issues with NGUI apparently not registering clicks on buttons on our test devices. Later we found out, that the hitbox of the broken buttons is set to an prior position where the object was last active after it got disabled, moved and activated again.

We thought that NGUI could be the issue - but after reproducing this in the editor, the editor itself showed the BoxCollider in the right position where definitely nothing triggers, but the area which actually did triggered the press, which is offset quite far away, had absolutely no hit colliders at all.
After disabling and enabling, moving or set other options on the component, the BoxCollider worked again as expected and was 1:1 in sync with the gizmo the editor showed us.

I would guess there is something fundamental broken in correlation with marking physic structures as dirty, when disabling colliders (and/or GameObjects) and moving them. I'll try to make a repro project without NGUI. Until then, we'll revert back to 2017.1 as we can't find a proper workaround for this.

edit: spelling

 

Anyone see if this is fixed with the new 2107.2 patch? The change notes didn't have anything I could directly connect to this.

 

We still have problems with physics in 2017.2.0p1, so this seems not to be fixed.

 

After moving to 2017.2 we had some problems with the physics : the forces seems to react weirdly.
As strange as it could seems, we solved our problem by changing for example :
transform.rotation = Quaternion.Euler(new Vector3(x,y,z));
to
RBody.MoveRotation(Quaternion.Euler(new Vector3(x,y,z)));
in all rigidbody (so no more direct assignment to transform.rotation)
I hope that it will help some of you!

 

Unity should test before publish to the new version !

 

They do, but it seems that QA is not as good as it used to be in early 5.x versions. Since Unity 5.5 almost every new Unity version shipped with at least one evident, show-stopper bug. I guess this is because new versions are now shipped on schedule rather than on completion (i.e. for some Unite event). So the .0 version is released as is, then they stabilize and patch it along the upcoming releases based on reports from users. Since Unity 5.5 I follow the rule of skipping the .0 releases as I think they're now the same as betas.

 

I was having issues with the physics after moving to 2017.2, but your comment was the solution! Applying the rotation to the Rigidbody component instead of the transform did the job (before was working just fine).

Thank you!

 

Thanks a lot for this comment, because that's exactly what was happening to me as well!
We're working on Unity 5.6.2 still, but we want to move soon to 2017 and I was doing some tests.

In all versions of 2017.2 I've tried I've seen the problem. I've tried the 2017.3.0.f2 and the results are the same.
Tested on 2017.1.0f3 and there was no problem, so I guess something changed from 2017.1 to 2017.2.

Changing "transform.rotation = xxxxx" to "rigidbody.MoveRotation(xxxxx)" fixed the issue.
For it to work correctly I've had to adjust a "time.deltaTime" around the rigidbody.MovePosition I was applying later, but now it's working the same as before.

I still haven't checked if there was a documented change on the physics on this versions, or if this is a bug. Anyway, I was planning on improving this particular code in the future in order to better handle the movement and physics, but seeing our basic movement break now was putting me in panic...


Edit: it seems there were some changes regarding Physics on 2017.2. Maybe some of these issues are related to this. One change, from the release notes:

https://unity3d.com/unity/whats-new/unity-2017.2.0
https://docs.unity3d.com/ScriptReference/Physics-autoSyncTransforms.html

 

Updated to 2017.3. No issues

 

updated to 2017.3 and still have broken collision on a 2d game, had to rollback to 2017.1 again

 

So on 2017.2.1f1 it seems to be significantly slower as the number of rigidbodies increases versus previous versions. A scene with some settings ran fine, around 60fps on 2017.1 (i think?) and on 2017.2 it's running at about 3fps. If I reduce the rb count it runs better, but it's clear that as I increase it the performance drops very rapidly when this was not an issue previously.

Didn't notice this previously because I was working in compartmentalized areas of the project. I would move to 2017.3 but its also broken with some kinda of new proxy issues that prevent it from running.

Can we just get a stable release that doesn't introduce a pile of show-stoppers? How about a branch that only fixes known bugs instead of adds new things and creates more bugs? It's getting really difficult to have any faith in new releases because so it introduces more problems than it fixes.

It's like some kind of entrapment where you get the new release to fix problems in the current one, but then the cycle just keeps going and you can never just stay on some release because it's always got some major issue you can't get around.

 

Tested on 2018.1b3 and has the same results.

It doesn't seem like these new physics system changes are getting thoroughly vetted.

 

Where does the profiler show the cpu going? I'm curious if it's related to this ticket I filed:
https://fogbugz.unity3d.com/default.asp?985751_b4fphdddse7lg5t4

Basically auto sync causes performance degradation.

In that case I hit a very obvious measurable threshold where it took a giant leap, but I also suspect the auto sync stuff degraded performance across the board.

 

Also in 2018.1 beta 3 AddForceAtPosition makes a rigidbody to jitter even though the code is working in 2017 and previous... And still, many times when a rigidbody collider hits a wall or another collider it jumps and pops !

 

I totally agree. Currently we are "trapped" on Untity 5.X because of different problems in following Unity 2017 versions (UI Bugs, Physics Bugs, ...). Most of them can be fixed by a workaround or with a patch release (not a satisfying solution, but okay).
The main reason we can't update is performance. We are able to build on all 2017 Unity versions so we could test our game in relation to the Unity 5 Version. The performance is significantly lower on most of our test devices (it's a highly optimzied mobile game).
We can't just update the game with a lower performance because some players then wouldn't be able to play anymore on there device.
We really don't know what to do right now instead of checking the circumstances of the performance loss without having a solution for it.
For my understanding Unity's goal is to let user update there project through multiple unity versions without the need of changing half of the project. Currently we are just waiting unitl a version fullfills our needs so we will skip multiple version (the whole 2017 family i guess).

Sorry, but this doesn't make things easier for developers right now.

 

@CookieSalad - I'm also seeing the issue with collisions happening with colliders which aren't actually touching, it seems to be iOS specific in my case (or at least, it doesn't happen in the editor, only the player?). I've managed to automate the steps up to the issue. I've uploaded a bug report (case 1005704). This issue did not happen prior to updating to Unity 2017.2 and it is still happening in Unity 2017.3.1f1

 

This might be related, but in 2018.2.0b2 if a rig has no root set and just uses animations the old way, the character blasts off to some unknown distant position and starts throwing out tons of "Invalid AABB a" error messages, when the animation stops the character comes back and the game settles down. If the animation persists, Unity has a hard crash to desktop.

I only mention because it's a rigidbody character that worked fine in 2018.1 and 2017.x

 

Hello Everyone, I am here to post my solution to physics problems. I ported my bullet hell shooter, UWP game from 5.6.3p2 to 2017.2.2p2 to be able to add xbox live functionality, but the movement of enemies and bullets got really weird after updating, sometimes it would be come faster or slower and there was an extreme perfomance hit.

in my case, I spent around 2 hours fiddling with the new settings, rigidbodies, and everything, but in the end it was the "Time To Sleep" parameter under Edit>Project Settings>Physics2D that appear in the editor. Changing it from the default 0.5 to 0.0001 Fixed it. Not to mention that the layer collision matrix got Reset.

 

Upgraded from 2017.1, and 2D physics got totally erratic, with massive jittering and other weird behavior, especially with adding forces.
Upgraded to 2018.1 Beta, and it was even much worse, not to say unusable, and all physics parameters would have to be changed and even then the jittering was all over the place.

Uninstalled 2018.1, installed 2017.3. Better, but still horrible compared to how smooth and performant it was in previous versions.
Then 2017.4 came out. Upgraded to that, and had to change all parameters, since forces again behave differently in this release.

Basically, every new Unity version breaks any game we have that uses 2D physics. For small teams this is not sustainable.

 

And if is trigger by a PhysX driver update since the introduction of DirectX12?

 

Thanks for offering to look into it.
I'll go through the backups and try to find the version I used, so you have the same starting point as me.

All physics calls are made in FixedUpdate, and I always tend to leave the project time settings at their default.
The problem is not new. About a year ago we ended up bypassing 2D physics entirely, as with every update forces were behaving differently, even if ever so slightly (parameters needed to be changed by 5-10%), but in a game where precision is important it was simply not safe to use.

I'll try and upload something for you.

 

Thanks Melv for all the explanations.
Maybe some other overhead influences the physics if nothing else has been changed. I'll run a couple of tests with the profiler.

I was looking for the posts concerning similar problems a while back, and it's actually at the top of this same thread (#6 & #10):
https://forum.unity.com/threads/2017-2-physics-broken.499886/#post-3253438

 

I changed my project to 2018.1 to 2018.2 and it was broke on my end as well when raycast and explosions hit it made me blocked at times and hardly moved

 

Shifting to Unity 2017.3.1 from 5.3.4 changes ball physics. It causes jerk in ball movement when added large force to the rigidbody ball. Any fixes???