Search Unity

  1. Are you interested in providing feedback directly to Unity teams? Sign up to become a member of Unity Pulse, our new product feedback and research community.
    Dismiss Notice

Bug NavMeshModifier influence navmesh far above them

Discussion in 'Navigation' started by MiFrilke, Jun 18, 2021.

  1. MiFrilke

    MiFrilke

    Joined:
    Dec 14, 2016
    Posts:
    32
    I'm creating this post for posterity and in hope a Unity dev comes across it, since the bug report I submitted over a week ago did not get looked at by Unity QA so far.
    For reference: (Case 1342586) [Navmesh] Navmesh modifier influence areas far above them

    We have been encountering similar issues with navmesh baking for several years now, but only now have I been able to reproduce it clearly in a separate project.

    Issue:
    When using the Navmesh modifier feature (either with built-in Navigation Static settings or with Navmesh Components package), the modifiers sometimes influence navmesh surfaces they are far away from (usually below).

    Detailed description:
    • All screenshots and descriptions below reference scene "modifier_issue" in attached project
    • Using the latest version of NavMeshComponent repository (with some modifications to support debug data building and display)
    • Tested with Unity 2020.3.11

    Example 1
    navmesh_issue_samples.png
    • The white meshes are marked walkable
    • The yellow boxes hold a NavMeshModifier component that is set to "override area" with another area (A) and with "not walkable" (B)
    • Observe the orange stripes of navmesh where the ramp connects to the platform when using a different navmesh area on the underlying modifier (A1-A4)
    • Observe the discontinuity of the navmesh where the ramp connects to the platform when using the "not walkable" area on the underlying modifier (B1-B4)
    • The yellow modifier boxes have different y-axis offsets to the walkable surfaces above it, to show the extent of this issue

    Example 2
    navmesh_issue_voxel_view_01.PNG
    • This is the "voxel" debug view, available through the modified NavMeshSurface script (built-in NavMeshBuilder functionality)
    • Generated voxels are colored for a specific navmesh area they will later generate into
    • We can see the top of the modifier boxes (violet) are colored differently than the walkable areas (light blue)
    • At the top edge of the ramp we see a single row of voxels that share color with the modifier box way below, this seems to be the origin of the issue as far as I could track it down
    • Dark grey voxels indicate both world space navmesh grid separators and not walkable navmesh edges (the outermost voxels of the shapes being generated as dark grey)
    • For reference, the focused example is A4 in previous image

    Example 3
    navmesh_issue_voxel_view_00.PNG
    • More voxel debug view, same views as first image
    • The generated voxels are the same across A and B cases (besides the coloring) even though the resulting navmesh (A vs B) looks quite different. This is because "not walkable" areas cant be integrated into the resulting navmesh like simple area changes
    • We can also identify the world space grid separators in the top-down view (vertical lines in A1/B1, A4/B4, A5/B5; horizontal lines across all A and B)
    • The "not walkable" areas created by the modifier in the B cases look just like all the other edge voxels

    Additional notes
    • Behavior described above can be influenced slightly by choosing different voxel and tile sizes on the NavMeshSurface, but the underlying voxel generation issue stays present
    • NavMeshAgent settings also influence the NavMeshBuild process, but not the shown voxel generation issue
    • It seems this behaviour is heavily dependent on some specific combination of geometry, which is why it happens randomly across our scenes, usually without any discernible reason for it. Each case needs a manual workaround by moving or deleting nearby navmesh modifiers
     

    Attached Files:

    hippocoder and Lurking-Ninja like this.
  2. nsxdavid

    nsxdavid

    Joined:
    Apr 6, 2009
    Posts:
    473
  3. MiFrilke

    MiFrilke

    Joined:
    Dec 14, 2016
    Posts:
    32
    Yeah we did take a look at that not too long ago. Though after the evaluation we decided not to go for it, since we already have so much tech built around Unity's built-in NavMesh system.

    From model creation (creating separate meshes for navmesh baking), over custom import pipeline steps, saving and modifying navmesh area weights dynamically, optimized navmesh queries via Jobs for NPCs, and much more, it's quite a lot that we would need to rewrite and learn from scratch.

    From a performance consideration the A* Pathfinding asset also didn't seem to give us much of a benefit, since as mentioned before we use jobified navmesh queries quite a lot and they are pretty fast already.

    Hoping to finally get the navmesh baking fixed by reporting issues like this, and we would actually be quite content with the built-in system.
     
  4. nsxdavid

    nsxdavid

    Joined:
    Apr 6, 2009
    Posts:
    473
    You missed the best part of A* Pathfinding: You have the source. Oh, and actual support.

    What's that worth compared to waiting for Unity to maybe care about your specific issue?
     
  5. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    7,227
    MiFrilke likes this.
  6. MiFrilke

    MiFrilke

    Joined:
    Dec 14, 2016
    Posts:
    32
    Thanks for pointing that out @Lurking-Ninja
    It doesn't look that "next gen" to me though, since it builds upon the already existing NavMesh Components. And also still uses the same black-box navmesh building system. It is basically just finally a "packaged" version of the Navmesh components, so transitioning to it doesn't seem to be much of an issue from what i've been able to check out.


    On another note, Unity QA finally entered this bug into the public issue tracker: https://issuetracker.unity3d.com/is...dges-when-using-notwalkable-or-water-modifier
     
    Seith likes this.
  7. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    7,227
    That's why I said it is the next generation, not "next gen". The later unfortunately is a very convoluted term. Next generation only means the new ones. They told, they will build on top of this, so going forward, this will be the base of any improvement.
    So I don't see the problem with my choice of words.
     
  8. MiFrilke

    MiFrilke

    Joined:
    Dec 14, 2016
    Posts:
    32
    First off: I never meant "next gen" as anything other than a commonly used abbreviation for "next generation".
    So, I was going to reply something here about different understandings of generations and such, but i guess we'd just be derailing the original topic, so lets leave it at that.
     
unityunity