Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Bug NavMeshObstacle broken in non-development builds since 2022.2

Discussion in 'Navigation' started by OndrejP, Feb 2, 2023.

  1. OndrejP

    OndrejP

    Joined:
    Jul 19, 2017
    Posts:
    278
    I'm working on a game Volcanoids, we have 2x2 km island in game, where enemies are walking.
    After upgrade to Unity 2022.2, agents are ignoring some of the NavMeshObstacles with carving.
    This happens only in non-development builds. Development builds work fine.

    Development vs. normal builds
    I was skeptical to the point where I made two builds and copied Volcanoids.exe and UnityPlayer.dll from development build to non-development build. And it worked, agents no longer ignored obstacles.
    This was confirmed by runtime visualization for NavMeshes we have (uses NavMeshTriangulation) - broken obstacles no longer cut NavMesh properly.

    More details
    After some more experimenting, it seems this happens only to Box obstacles and the way they are broken is that their cutout in local Z-axis is different than should be. Very small, maybe zero.

    Versions
    Unity 2022.1.17f1 - works fine
    Unity 2022.2.3f1 - broken
    Unity 2022.2.4f1 - broken
    Unity 2022.3.0b2 - broken

    What did not help
    Small NavMesh, build NavMesh
    Different carve settings
    Different NavMesh build settings

    Conclusion
    Is there any known issue related to this? If not, I'll try to reproduce it in empty project and submit bug report.
     

    Attached Files:

    Last edited: Feb 2, 2023
    MartinKauer and mzatopek like this.
  2. OndrejP

    OndrejP

    Joined:
    Jul 19, 2017
    Posts:
    278
    It truly seems that "size.z" of the NavMeshObstacle is always zero for the purposes of cutout in non-development build.

    Workaround
    • reorient obstacles to face z-up
    • set their size.z to 0.05
    • reposition them just above the surface (0.5m above works well for agents with height 1.9m)
    This gives consistent results in Editor, development build and final build.
    Since NavMesh cutouts "prolong" obstacle down by agent height and our surfaces are mostly flat, it's good enough for us.

    Possible cause
    NavMeshObstacle uses same fields for both box and capsule. Capsule radius is stored in size.x and Capsule height is stored in size.y. Size.z is unused for capsule.

    Could it happen that internal Unity implementation uses union to store these values and some optimization technique employed in release build optimizes away some loading or deserialization of size.z?
     
    mmsaabgroup and mzatopek like this.
  3. mzatopek

    mzatopek

    Joined:
    Nov 14, 2019
    Posts:
    1
    Hi, I am facing the same issue.
    The workaround suggested by OndrejP is working, but I need all the axis in the box collider.
    I hope it will be fixed soon. :)
     
    mmsaabgroup and MartinKauer like this.
  4. OndrejP

    OndrejP

    Joined:
    Jul 19, 2017
    Posts:
    278