Search Unity

  1. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Let us know a bit about your interests, and if you'd like to become more directly involved. Take our survey!
    Dismiss Notice
  4. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  5. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

2017.2 physics broken

Discussion in 'Physics' started by JohnTomorrow, Oct 12, 2017.

  1. JohnTomorrow

    JohnTomorrow

    Joined:
    Apr 19, 2013
    Posts:
    87
    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?
     
    symorian likes this.
  2. AlanMattano

    AlanMattano

    Joined:
    Aug 22, 2013
    Posts:
    884
    Are you using the same physic fixed time?
    Edite>ProjectSettings>Time>Fixed Timestep
     
    Last edited: Oct 13, 2017
  3. JohnTomorrow

    JohnTomorrow

    Joined:
    Apr 19, 2013
    Posts:
    87
    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...
     
  4. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    6,071
    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.
     
  5. AlanMattano

    AlanMattano

    Joined:
    Aug 22, 2013
    Posts:
    884
    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.
     
    Last edited: Oct 25, 2017
  6. zapposh

    zapposh

    Joined:
    Nov 12, 2016
    Posts:
    41
    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.
     
  7. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,212
    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.
     
  8. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    2,628
    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.
     
  9. CookieSalad

    CookieSalad

    Unity Technologies

    Joined:
    Dec 29, 2014
    Posts:
    7
    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!
     
    Peter77 likes this.
  10. zapposh

    zapposh

    Joined:
    Nov 12, 2016
    Posts:
    41
    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.
     
    AlanMattano and Peter77 like this.
  11. interpol_kun

    interpol_kun

    Joined:
    Jul 28, 2016
    Posts:
    58
    100% broken Tilemap Collider 2D on mobile builds.
     
  12. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    2,628
  13. interpol_kun

    interpol_kun

    Joined:
    Jul 28, 2016
    Posts:
    58
  14. AviSci

    AviSci

    Joined:
    Aug 17, 2017
    Posts:
    4
    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.
     
  15. Tiny-Tree

    Tiny-Tree

    Joined:
    Dec 26, 2012
    Posts:
    1,229
    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
     
  16. trudeaudm

    trudeaudm

    Joined:
    Apr 17, 2013
    Posts:
    115
    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.
     
  17. Sluggy

    Sluggy

    Joined:
    Nov 27, 2012
    Posts:
    261
    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.
     
    daxiongmao likes this.
  18. Sluggy

    Sluggy

    Joined:
    Nov 27, 2012
    Posts:
    261
    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.
     
    Last edited: Oct 25, 2017
  19. Mitnainartinarian

    Mitnainartinarian

    Joined:
    Jun 3, 2017
    Posts:
    16
    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.
     
  20. Sluggy

    Sluggy

    Joined:
    Nov 27, 2012
    Posts:
    261
  21. AlanMattano

    AlanMattano

    Joined:
    Aug 22, 2013
    Posts:
    884
    Can you expand this solution? did you change the scale of the model into 1:1? or what how?
     
  22. Mitnainartinarian

    Mitnainartinarian

    Joined:
    Jun 3, 2017
    Posts:
    16
    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.
     
  23. nielz2

    nielz2

    Joined:
    Aug 17, 2014
    Posts:
    2
    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
     
    Last edited: Oct 30, 2017
  24. daxiongmao

    daxiongmao

    Joined:
    Feb 2, 2016
    Posts:
    234
    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.
     
  25. thomas-weltenbauer

    thomas-weltenbauer

    Joined:
    Oct 23, 2013
    Posts:
    38
    We still have problems with physics in 2017.2.0p1, so this seems not to be fixed.
     
    nielz2 and daxiongmao like this.
  26. ram3ghz

    ram3ghz

    Joined:
    Jul 27, 2015
    Posts:
    1
    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!
     
    Last edited: Nov 22, 2017
    AlanMattano likes this.
  27. CoderPro

    CoderPro

    Joined:
    Feb 21, 2014
    Posts:
    281
    Unity should test before publish to the new version !
     
  28. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,212
    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.
     
    Dennis_eA likes this.
  29. ReneSerrato

    ReneSerrato

    Joined:
    Oct 3, 2016
    Posts:
    1
    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!
     
  30. alteredmatter

    alteredmatter

    Joined:
    Sep 14, 2016
    Posts:
    24
    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
     
    Last edited: Dec 18, 2017
  31. JohnTomorrow

    JohnTomorrow

    Joined:
    Apr 19, 2013
    Posts:
    87
    Updated to 2017.3. No issues :)
     
  32. Tiny-Tree

    Tiny-Tree

    Joined:
    Dec 26, 2012
    Posts:
    1,229
    updated to 2017.3 and still have broken collision on a 2d game, had to rollback to 2017.1 again
     
  33. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    6,071
    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.
     
    Vagabond_ and Edy like this.
  34. LaneFox

    LaneFox

    Joined:
    Jun 29, 2011
    Posts:
    6,071
    Tested on 2018.1b3 and has the same results.

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

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,747
    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.
     
  36. Vagabond_

    Vagabond_

    Joined:
    Aug 26, 2014
    Posts:
    648
    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 !
     
  37. thomas-weltenbauer

    thomas-weltenbauer

    Joined:
    Oct 23, 2013
    Posts:
    38
    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.
     
    Last edited: Jan 30, 2018
    newlife, AlanMattano and Edy like this.
  38. CapeGuyBen

    CapeGuyBen

    Joined:
    Mar 1, 2014
    Posts:
    5
    @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
     
  39. Safemilk

    Safemilk

    Joined:
    Dec 14, 2013
    Posts:
    11
    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
     
  40. kevingodoy

    kevingodoy

    Joined:
    Sep 15, 2015
    Posts:
    4
    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.
     
  41. zapposh

    zapposh

    Joined:
    Nov 12, 2016
    Posts:
    41
    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.
     
  42. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,436
    I'm pretty confused over this. There's not been any fundamental changes to 2D physics that would affect things like forces. Forces are applied at a low-level and changes there don't happen often. Are you sure you're applying forces in a time-independent way? When you talk about jittering, are you sure this is to do with 2D physics or just the rate at which fixed-update is called due to other issues in the engine?

    Do you have a simple project you could upload that clearly demonstrates such behaviour? Possibly submit it as a bug report and pass me the case. I'd be more than happy to dig into it and see what's going on.
     
  43. AlanMattano

    AlanMattano

    Joined:
    Aug 22, 2013
    Posts:
    884
    And if is trigger by a PhysX driver update since the introduction of DirectX12?
     
  44. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,436
    2D uses Box2D not physx.

    Unfortunately this thread is jumping between 2D & 3D physics.
     
    AlanMattano likes this.
  45. zapposh

    zapposh

    Joined:
    Nov 12, 2016
    Posts:
    41
    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.
     
  46. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,436
    We just don't update or modify Box2D very often. Indeed, I cannot remember the last time that any behavioural changes were made so this is very odd. Force is a very simple process too. You add a force, it is accumulated in Box2D until the simulation is run, then added to the velocity of the body * time-delta then the force is reset. This has never changed and is stock Box2D (as is most of the underlying 2D physics). In most of the cases, Unity is a thin wrapper around such functionality. For this to change then, either the time or the amount of force being added must be varying.

    Also, we have a whole bunch of runtime tests that check this kind of stuff so it's even more confusing.

    For 2018.1, we did implement multi-threading but that is in parallel to the old code-path and nothing really changed there, you can still run the old non-threaded code-path and it should behave identically.

    I'll help you get to the bottom of the issue.
     
    Last edited: May 5, 2018
  47. zapposh

    zapposh

    Joined:
    Nov 12, 2016
    Posts:
    41
    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
     
  48. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,436
    I have yet to see a single bug report on forces not being applied correctly so either they've not been produced or QA couldn't find an issue with the reports (so we don't see them).

    If you have the old bug report number I can still take a look at that even if it was closed etc.
     
    AlanMattano likes this.
  49. hensoup

    hensoup

    Joined:
    Jan 13, 2014
    Posts:
    31
    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
     
  50. Mairee

    Mairee

    Joined:
    Jun 27, 2018
    Posts:
    2
    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???