Search Unity

Box collider issues and autoSyncTransforms

Discussion in 'Physics' started by xmarleauFFG, Oct 22, 2021.

  1. xmarleauFFG

    xmarleauFFG

    Joined:
    Mar 28, 2017
    Posts:
    6
    Hello fellow Unity developers,

    This is an informational post for anyone who would have issues with box colliders following a Unity upgrade.

    I'm currently updating an older project from Unity 2017.4.33f1 to Unity 2020.3.20f1 and it seems something changed with box collider in Unity versions post 2017. The particular issue I had was that most UI buttons/widgets couldn't be clicked anymore or clicking some elements would select others instead. I discovered that box colliders were the culprits, because disabling and reenabling them in the Editor would temporarily fix my issue.

    For this project, we are using a combination of NGUI and ITween to animate and display the UI elements. When animating UI elements (for instance when displaying a new screen) the buttons would translate from any of the 4 sides of the screen to lock in their respective place. But most boxcolliders attached to buttons wouldn't follow their respective widget translations.

    After days of research and trying out different fixes, the solution was to check a simple checkbox.
    Checking Project Settings -> Physics -> Auto Sync Transforms solved all my UI issues.

    Be aware that checking this box will have a performance impact on your game, because every time a "Physics" element (Collider, Rigid Body) is moved around, it will resync with the associated Transform.

    More on the subject:
     
    xmarleauFFG, Oct 22, 2021
    #1

  2. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,497
    Nothing changed with BoxCollider and sync-transforms has nothing to do with that specifically.

    When you modify a transform, it only modifies the transform. It doesn't updated ANYTHING else on the GameObject because there is no notification of the change behind the scenes in Unity. This changed a long time ago to remove side-effects when changing transforms in the job-system.

    This meant that legacy behaviour of expecting everything to be updated when you changed the Transform had to be maintained by any system that required it and that includes both 2D and 3D physics. With that option on, anytime you performed a read operation on the physics system, it'll ensure that all those manual Transform changes (that you should not be doing anyway) write back to the physics system but it can be an expensive check because it's done after ANY read operation on any physics component.

    With it off, it doesn't so that and sync is only done prior to the simulation step.

    If it moves in physics it should be a Rigidbody(2D) moving. You should not be modifying the Transform as that is bypassing the component in control of the Transform i.e. the Rigidbody(2D).

    Your statement of moving a body means it needs to be sync'd isn't correct. It's about Transform -> Physics components, not the other way around.
     
    MelvMay, Oct 22, 2021
    #2
    Edy likes this.

  3. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,510
    Thank you for the wonderful explanation! This is not mentioned in the manual, and definitely clears it up a lot.
     
    Edy, Oct 22, 2021
    #3
    MelvMay likes this.