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?
1 Like
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.
Hey!
Could you guys please provide repro cases for the issues you’re having? You may upload the projects to this thread, or use the Unity Bug Reporter then link the case number here. In particular I’m interested in the collisions/rays returning wrong results ( @JohnTomorrow ) and the forces being stronger ( @zapposh ) issues.
Cheers!
1 Like
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.
2 Likes
100% broken Tilemap Collider 2D on mobile builds.
I recommend to submit a bug-report, see here:
https://discussions.unity.com/t/679667/8
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 shit together and release a patch.
1 Like
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.
1 Like
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
Supposedly, it has been fixed in a beta build of 2017.3