Search Unity

Official There's a new Navigation package in town!

Discussion in 'Navigation' started by UnityChinny, Dec 8, 2022.

  1. UnityChinny

    UnityChinny

    Unity Technologies

    Joined:
    Feb 17, 2021
    Posts:
    70
    For 2022.2 and beyond.

    There is a new(ish) Navigation package in town!

    You might already be aware of the NavMeshComponents GitHub repo, well we have migrated it to a new package, and given it some upgrades while we were at it.

    Why did we do this?
    Well, the legacy built-in system is rather limited. Today’s demands made it very difficult to simply update it, which is why NavMeshComponents was made. However, this was all done before the Package Manager was available, so we felt the timing was right to make the migration.

    Most noticeable changes?
    Given the current NavMesh system has been replaced by a new verified package, the first thing you will notice in 2022.2 (by its absence) is that the old menu items have been removed by default. This is because the new package is optional, so it now needs to be installed first. This will allow us to address fixes and improvements more quickly and easily than before, as well as reduce some overhead for projects not requiring any Navigation.

    Once you install the new “AI Navigation” package you’ll see the Component>Navigation menu has a few additions, and the Window>AI menu will display the old option, but now marked (Obsolete). Now If you happen to load an old 2020 or 2021 project built using the old system, you should get a prompt highlighting the new package will be installed (if not already done)

    Please note that we can’t respond to any new requests that rely on the legacy system, as we are all-in on making the new package as stable as possible for the foreseeable future. Given that the new AI Navigation delivers parity with the current built-in system, and much more of course, you can expect that one day we will completely remove the legacy one - as having two systems will likely cause some confusion.

    Now to make the transition as painless as possible, older projects can be converted to use the new package by running the included NavMesh Updater from the menu. However, during your transition, you might find some duplicates when searching “MeshLink”, or calling old APIs that no longer work in the new system. Just a heads up.

    What to expect in the new package?
    For starters, check out this “What’s New” section.
    At a high level, some of the key additions we know will be useful are the runtime baking, multi-agent types support, as well as breakdown baking on multiple surfaces, and enhanced NavMesh configuration.
    The new package also ships with a few samples, to help get you up to speed.

    More info
    Now that we are out of Preview, the Roadmap page has been updated, but please do keep the feedback rolling in.
    We will also update the forum pages too. As the package was in preview for quite a while, we will remove it from that part of the website, and have it live here from now on

    Bunch o’ useful links
    Whats New
    Upgrade Guide
    Docs
    Changelog
    Roadmap
    2022.2 blog

    Happy navigating!
    Chinny - Senior Product Manager
     
  2. Terraya

    Terraya

    Joined:
    Mar 8, 2018
    Posts:
    646
    Very nice news, looking for the JobSystem integration!

    Happy to see that you are working on the AI Navigation package as well :)
     
  3. FredTuna

    FredTuna

    Joined:
    Dec 28, 2016
    Posts:
    16
    Is there a way to keep using the old NavMeshComponents code from github? I had made some modifications to that code that I would like to keep but now I can't open Navigation window unless I get the new AI Navigation package which can't be installed from source. Is there a plan to allow installing that package from source like HDRP for example? Or else is there a way to keep using the old code without losing the window functionality?
     
  4. Onigiri

    Onigiri

    Joined:
    Aug 10, 2014
    Posts:
    479
    Please update your sample scenes to use URP materials. It's frustrating when some of the packages(like yours and cinemachine for example) still using built-in materials and I had to convert it.
     
    Razputin and Thaina like this.
  5. Terraya

    Terraya

    Joined:
    Mar 8, 2018
    Posts:
    646
    I dont see the reason for this to happen.

    Not everyone is using URP unless those sample scenes are specialy for URP.

    If not, its better to keep them in the built-in material so people who use HRDP or URP have an easy way to convert them
     
  6. WalterPalladino

    WalterPalladino

    Joined:
    Oct 24, 2016
    Posts:
    11
    The preview version downloaded from the PackageManager includes HORRIBLE Errors like sticking on surfaces even vertical ones.
    I think the issues related to that one should be fixed first because 2021 is the higher LTS version.
     
  7. Onigiri

    Onigiri

    Joined:
    Aug 10, 2014
    Posts:
    479
    The reason is because unity pushing SRPs to be the default renderers in unity. They should stop making materials for dead renderer and at least make them in shader graph with compatibility for all renderers. This is supported long time ago when unity added graph targets for shader graph.
     
  8. Vincent454

    Vincent454

    Joined:
    Oct 26, 2014
    Posts:
    167
    Is the navmesh supposed to be shown ALL the time? I cant get it to hide, before it only showed when selecting an object that had a navmesh related component on it. It only hides when I toggle gizmos in the scene view now
     
    TJHeuvel-net likes this.
  9. WalterPalladino

    WalterPalladino

    Joined:
    Oct 24, 2016
    Posts:
    11
    Will this version allow agents to use simultaneously the same NavMeshLink?
     
  10. Vaupell

    Vaupell

    Joined:
    Dec 2, 2013
    Posts:
    302
    just uncheck this one..
    upload_2023-1-2_21-46-15.png
     
    adriant likes this.
  11. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    5,025
    Will the new implementation also be open sourced?
     
  12. siepiau

    siepiau

    Joined:
    Jul 27, 2015
    Posts:
    1
    Hello, I have a few questions regarding the performance of the new Navigation package vs the legacy built-in system.

    1) So far I had been using the legacy baked NavMesh and experiencing almost instantaneous entry into play mode in the Editor using the "Enter Play Mode Options". However, after switching to the new NavMeshSurface under Unity 2022.2, the time taken to enter and exit play mode went up significantly. Since the NavMesh is already pre-baked in both cases, is there any reason why the new system should result in a degradation in Editor performance (and hence iteration time)?

    2) I'm using a floating origin setup, so the level geometry will shift occasionally. Naturally, the old NavMesh system won't be able to support this but the new Navigation system seems to allow for moveable NavMeshes. However, simply shifting the parent transform of the entire level with a NavMeshSurface component on it will cause a significant slowdown at runtime. Is there any way to achieve a reasonable performance with this kind of setup?

    Any insight would be most appreciated! Thanks!
     
    Dinamytes likes this.
  13. Vincent454

    Vincent454

    Joined:
    Oct 26, 2014
    Posts:
    167
    Thank you, that works
    Though it still shows the navigation links and navigation surface bounds and these are only toggleable through the gizmo settings, I hope they will put them in this menu as well as it takes too long to simply toggle everything navmesh related that way
     
  14. Ziflin

    Ziflin

    Joined:
    Mar 12, 2013
    Posts:
    132
    @ChinnyBJ - Are there are updates to NavMesh planned to fix the issues mentioned here :(https://forum.unity.com/threads/issues-with-navmeshagent-setdestination-stopping-agents.636769/)?
    I'm pretty sure I filed a bug report about this 4 years ago, but there still does not appear to be a way to update the agent's destination each frame without Unity stopping its movement. It would be fine if Unity used the previous path for movement (it could be a bool parameter to SetDestination ) while asynchronously resolving the new one, but the current behavior of stopping the agent until it resolves a path is not useful.

    We've been forced to set NavMesh.pathfindingIterationsPerFrame to a huge number and force all agents path resolving to complete in one frame which is less than ideal.

    Using NavMeshAgent.CalculatePath is also non-async and seems like a bad idea as it requires creation of a new Path instance each frame (per agent) or hoping that it's ok to re-use one that was replaced by a call to NavMeshAgent.SetPath (alternating between two Path instances). It also behaves a bit differently than just calling SetDestination as mentioned in the link..
     
    Sluggy and Vincent454 like this.
  15. Vincent454

    Vincent454

    Joined:
    Oct 26, 2014
    Posts:
    167
    I agree that would be very useful. I have a lot of bots moving at once and you can see them stutter for one third of a second every now and then, because their new path isnt completed yet. If you're just doing it for the player controls, I would update the player position manually, so agent.updatePosition is set to false. Then you can also save the old path and use that whilst the new one hasn't been calculated fully. You can also maybe calculate the path non-asynchronously and assign it with agent.SetPath. If it's just the player, I guess this would not be a performance problem and maybe even the best solution
     
  16. Ziflin

    Ziflin

    Joined:
    Mar 12, 2013
    Posts:
    132
    This is really for any player or friendly/enemy AI that end up needing to change their target position fairly often (the target is moving, etc.). But we need a way to avoid the agent stopping when pathPending is true or there's no point in it being async...
     
  17. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,293
    Finally some movement in this space. Good to see support for multi agent on the same mesh.

    Once you reach parity and move to the fun stuff, throw the roadmap to the trashcan, it's all wrong:
    Avoidance is fine as-is, same for workflow so don't waste time on these and we can adapt tools to our workflow anyway that's the Unity philosophy.

    Instead, tackle the real problems, real lacks which we have zero control over because it's on the C++ side of the engine: we can't set the navmesh geometry (only getter), everything is single threaded and finally it doesn't handle cyclical topology so there is no way to do planets.

    Here is a summary of what needs to be implemented ASAP before you start massaging quality of life:
    1. Setter for navmesh geometry with
      NavMeshSurface.Optimize()
      to massage mesh data into fast node graph (non blocking). Bonus point for allowing us to set penalties of vertex or face as an optional parameter when setting the custom navmesh.
    2. handle non planar topology from user generated mesh: cyclical topology like kettles, planets and toroids a must. The math for agent control isn't fun to deal with, so, also provide math helpers as well as smoothed normal and tangent.
    3. Multithread behind the scene, without us having to touch the job system. The legacy version was super fast but it was single threaded and a 13600k has 20 threads sitting idle.
    4. When you scale this to tens of thousands of agents, keep the syntax unity-like and handle the batching for us, so we don't have to contort our code into jobs. Example:
      agent.BatchPathTo(Vector3 target)
      and when all are submitted call
      AI.PathFinder.ComputeBatch()
      . You can read a great thread on simple, performant syntax here: https://forum.unity.com/threads/int...apis-arriving-in-2023-1.1364934/#post-8700462
     
    Last edited: Jan 29, 2023
  18. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,128
    If I understand correctly, official is trying to fix and improve current navigation system but I think official should start working on dots navigation with game object compatibility. I believe the current navigation also have a lot of unfixable and super hard to fix issues. So still keep all the currently available navigation graphical tooling but the navigation core is powered by dots/ecs under the hood.
    Another is dots utility AI I'm keep requesting for few years but nothing is happening yet until now. I really hope official will also prioritize and start investing resources for this area at this year since from past up until today there's no such ai tooling other than navigation.
     
    Last edited: Jan 25, 2023
    lclemens and Vincent454 like this.
  19. adriant

    adriant

    Unity Technologies

    Joined:
    Nov 1, 2016
    Posts:
    69
    The components in the AI Navigation package and the ones from the Github repo will conflict because they have a common history. To mitigate that I can suggest some steps to help you modify your components from the NavMeshComponents repo:
    - rename their namespace (e.g. from namespace UnityEditor.AI to namespace UnityEditor.AI.Custom) and update the code everywhere to use those new namespaces
    - delete any of their .meta files in order for Unity to regenerate new ones
    - rename the three entries of [MenuItem("...")] to something else
     
  20. adriant

    adriant

    Unity Technologies

    Joined:
    Nov 1, 2016
    Posts:
    69
    No, it won't be open sourced. That is in line with most of the packages developed at Unity. You can check out the license of the package here https://docs.unity3d.com/Packages/com.unity.ai.navigation@1.1/license/LICENSE.html

    To inspect and possibly modify the AI Navigation code inside your project you can have a look at instructions about embedded dependencies.
    If you enable the "Registry Packages" in the External Tools preferences then you will see the code of all the installed packages inside your C# project. You can find more info in the documentation for the Visual Studio and Rider IDE helpers.
     
    mbussidk and DevDunk like this.
  21. adriant

    adriant

    Unity Technologies

    Joined:
    Nov 1, 2016
    Posts:
    69
    I don't see an obvious reason why there would be a difference between loading the scene-owned NavMesh and the Surface-owned NavMesh because both methods execute a lot of the same code. It did not show up in our tests. We'll need to do an investigation before knowing more about what's causing this slowdown.
     
  22. adriant

    adriant

    Unity Technologies

    Joined:
    Nov 1, 2016
    Posts:
    69
    I can't suggest any improvement to this setup right now, but I'd like to mention that moving a NavMeshSurface to a new position consists of unloading the NavMesh from the old location and disconnecting it from the OffMeshLinks/NavMeshLinks it touches, and then instantiating the NavMesh in a new location in the scene and reconnecting all the links it now touches. Depending on the setup and the size of the data, this can take a longer-than-anticipated time to do. Unfortunately there is currently no "shortcut" method that would allow for the surface to just change its instantiation origin.
     
  23. asherfarris11

    asherfarris11

    Joined:
    Jan 26, 2023
    Posts:
    2
  24. VayneVerso

    VayneVerso

    Joined:
    Dec 5, 2022
    Posts:
    18
    This may be a bizarre question, but is there some way to create a NavMeshModifier Volume whose shape would be defined by a spline? If not, I guess that's a feature request.

    Yes, that would be related to a question I asked in another thread about how one would adjust the cost on the "road" section of a terrain object. I'm just thinking about how awesome it would be to sketch out the contours of the preferred path across a terrain and then be able to turn that into a shape that would only exist as a volume respected by the navmesh baker.
     
  25. clownhunter

    clownhunter

    Joined:
    May 26, 2013
    Posts:
    59
    I left a few suggestions on the roadmap (one of which I left in August of 2021 for the old GitHub component system, haha), but I figured I should bring them up here for visibility:

    Exposure Map
    The ability to generate a runtime exposure map and use that as something like an on-the-fly NavMeshModifierVolume would be amazing. This would make pathing to cover points consider if the player can see them while moving, so agents can choose better routes that limit how much they expose themselves while moving. For a great reference on exposure maps, this reference to the AI from The Last of Us does a great job: http://www.gameaipro.com/GameAIPro2/GameAIPro2_Chapter34_Human_Enemy_AI_in_The_Last_of_Us.pdf

    Alternate Routes
    When multiple agents are moving from the same area towards the same position, they can easily create "clown car" AI where they keep pouring in from the same point and the player doesn't need to move the crosshair to kill them all one at a time . It would be great if we can instead get multiple paths within some tolerance level instead of always getting the "best" path so some agents can move on alternate routes.

    Flanking
    I need the ability to generate better alternate paths or "flanking" routes. Some (probably really bad) ideas I had are:

    1) Alternate CalculatePath method where I can give it an array of vector3 positions that the agent tries their best to "path through" on their way to the destination.

    2) Alternate CalculatePath method where I can provide a list of NavMeshModifierVolume's that only apply to this specific agent's current calculation. This way, if I have two agents moving towards a position, the first one I can check for what modifier volumes are along the agent's path, and pass those in to the second agent's CaclulatePath call to avoid moving through the same are if there's another good route available.

    3) Create standardized NavMeshFlankRoute component that decorates that specific point in space. I can drop a few of these points, and have a new CalculatePath method that looks at nearby flanking points to see if pathing "through" them that has less overlap with a regular CalculatePath(). If this new path is substantially different enough, then it's a suitable flanking path.

    I know that Unity is a multipurpose game engine and adding "flanking" as a built in feature might not sound the best since it won't be useful in the majority of the games being created, but it's a really standard feature for AI to behave smarter in games, and without any other options to generate alternate routes, having a built in component handle this would be the next best thing.

    Improved Collision Avoidance
    Currently, setting all of your agents' "priority" to different values looks terrible with agents knocking other agents out of the way with no regards to their speed or anything else. This also looks bad because in a game where I use root motion movement, the priority pushing happens automatically so my characters slide across the ground. It also might be better if they try to path around slower moving agents with some kind of local avoidance instead of plowing directly through a group of them.

    It also would be nice if agents would understand how to queue up to walk through tight spaces natively instead of butting heads and not allowing either agent into a tight passage when they have the same priority.
     
  26. Gekigengar

    Gekigengar

    Joined:
    Jan 20, 2013
    Posts:
    738
    Need a way to fully disable/selectively push other agents, and ignore specific agent collision completely. Highly requested since 2013. Please just separate NavMeshAgent and ObstacleAvoidance as 2 different modular component.
     
    Last edited: Jan 31, 2023
  27. Neekhaulas

    Neekhaulas

    Joined:
    Jul 11, 2014
    Posts:
    5
    Hello, I am trying to use the new package and it's really painful to get started since documentation is incomplete or sending back to the deprecated navigation system. Plus I need to get some explanation on why a NavMeshAgent behaves like a car? I don't need steering, braking, velocity. Have you ever seen a character drifting while walking from A to B? I mean maybe some people may need this behavior but I just want to get straight from A to B without having to rewrite the whole NavMeshAgent movement.
     
  28. adriant

    adriant

    Unity Technologies

    Joined:
    Nov 1, 2016
    Posts:
    69
    We've been working on documentation and we'll publish an up-to-date version soon, in a few weeks. Thank you for your patience.

    The behavior of the NavMeshAgent has not changed with the release of this package. You can try increasing the
    angularSpeed
    and
    acceleration
    properties of the NavMeshAgent to high values in order to get a more instantaneous response that fits your use case. Also you can set
    autoBraking
    to "false" if you need to control through your code how the agent slows down before stopping.
     
    Last edited: Feb 1, 2023
  29. adriant

    adriant

    Unity Technologies

    Joined:
    Nov 1, 2016
    Posts:
    69
    No, the Modifier Volume has only a box shape currently. The solve the use case you've mentioned you can maybe devise a way to create a string of boxes that would follow the desired spline.
     
  30. Vincent454

    Vincent454

    Joined:
    Oct 26, 2014
    Posts:
    167
    When I disable a navmesh link (link.enabled = false) and then try to check if its enabled if(link.enabled) it returns true. Am I missing something?
    Also, changing link.bidirectional to false and then enabling the link after it was disabled causes an error. If you enable it, then change link.bidirectional it works.
     
  31. Gekigengar

    Gekigengar

    Joined:
    Jan 20, 2013
    Posts:
    738
    Will a fix for NavMeshObstacle be coming as well? Currently agent.isOnNavMesh returns true even if agents are standing on carved spot. And any agent unfortunate enough to be standing on a newly carved position also get stuck instead of re-positioning itself in an available spot of the NavMesh.

    There should also be a better way to create new agent type on runtime.
     
    Last edited: Feb 27, 2023
  32. VayneVerso

    VayneVerso

    Joined:
    Dec 5, 2022
    Posts:
    18
    Thanks for the response. Yeah, I was thinking something like that could work. I don't personally know how to do that at this point in time, but I know I've seen people link objects together on a spline before, so perhaps I could figure that out.
     
  33. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,293
    ETA on auto navmesh link?
     
    EWimsett likes this.
  34. AndrewCzarnietzki

    AndrewCzarnietzki

    Joined:
    Jul 23, 2013
    Posts:
    189
    For those of us who don't use Unity's AI Navigation, but do need to update Unity, how do we get rid of the AI Navigation panel always being visible in the scene view? I hide it, but it keeps coming back....

    upload_2023-2-12_21-30-30.png
     

    Attached Files:

    SF_FrankvHoof and Vincent454 like this.
  35. Vincent454

    Vincent454

    Joined:
    Oct 26, 2014
    Posts:
    167
    Right click it and select hide. If you want to bring it back, right click the scene view tab and select overlay menu
    Who approved these menus wtf??

    Furthermore, you cannot get the navmesh links OR the navmesh surface bounds to hide unless you toggle gizmos. Why is it not part of the overlay toggle. This is such terrible ux and this only became a thing with this new navigation package. WHY??? UNITYYY
     
  36. AndrewCzarnietzki

    AndrewCzarnietzki

    Joined:
    Jul 23, 2013
    Posts:
    189
    Right click it and select hide.

    Except every single time I open the editor? That is _really_ awful for a feature we don't use.
     
    Vincent454 likes this.
  37. Saniell

    Saniell

    Joined:
    Oct 24, 2015
    Posts:
    191
    I'd like to ask for ability to add what I would call "inflated" subareas into navmesh. Basic idea is to take NavMesh with your default agent radius, then rebake it, but using bigger radius. This allows for agent to prefer walking more in the middle of roads while still being able to traverse more narrow places
    Just compare these two paths:

    With inflated area:

    Without:


    To me it's obvious that first one is many times better :rolleyes:

    Same technique could also very well be used for roads, crouches markup, just allow to change agent height, max slope too

    Currently the way I did it is by using CalculateTriangulation, putting given mesh into MeshCollider and applying NavMeshModifier to that collider. This will not work as soon as collider starts intersecting other geometry in scene, mainly on slopes, since CalculateTriangulation returns only very simplified mesh.

    At the very least you could enable building such feature by providing Modifier Volumes that work with arbitary meshes or at least allowing to use custom geometry as a navmesh so I can generate all of it myself
     
    Vincent454 likes this.
  38. jamespa

    jamespa

    Unity Technologies

    Joined:
    May 3, 2018
    Posts:
    1
    It looks like if you create a new project in the latest versions of 2022.2 (e.g. 2022.2.6) the package is not added by default and therefore the window won't appear.

    For existing projects if you're not using the feature you can just remove the package and the result should be the same.
     
    AndrewCzarnietzki likes this.
  39. DwinTeimlon

    DwinTeimlon

    Joined:
    Feb 25, 2016
    Posts:
    300
    Have you looked into navigation cost settings? You could e.g. fill the middle of roads with navmesh modifiers and give them an area which has less navigation cost than the surroundings.
     
  40. bjornmp

    bjornmp

    Joined:
    Jul 26, 2022
    Posts:
    1
    I would like to have a layer mask for the NavMeshObstacle component. Let me explain my use-case.

    Setup
    - I have a plane (ground/terrain) with a NavMeshSurface component and a backed NavMesh.
    - I have a House prefab with its own NavMeshSurface component and a baked indoor NavMesh, and a NavMeshLink component at the entry, connecting the baked indoor NavMesh to whatever outdoor NavMesh the house is going to be spawned on.

    Problem
    When I spawn the house, the NavMeshLink correctly connects the indoor NavMesh of the house to the outdoor NavMesh of the plane. The problem is that the house does not carve the outdoor NavMesh, causing an overlap. I tried using a NavMeshObstacle component on the house prefab, but because there is no layer mask option in the NavMeshObstacle, it ends up carving the indoor NavMesh as well.

    Solution
    Add "Included Layers" option to the NavMeshObstacle component. This way it would be possible to add a NavMeshObstacle component to the house that carves "Outdoor" NavMeshes but doesn't carve "Indoor" NavMeshes.
     
    Last edited: Feb 16, 2023
    Vincent454 likes this.
  41. Kewlife

    Kewlife

    Joined:
    Apr 12, 2016
    Posts:
    6
     
  42. Kewlife

    Kewlife

    Joined:
    Apr 12, 2016
    Posts:
    6
    Your new package seems to make it unable to select objects in SceneView while in playmode, The packages not not contain an option to cut off its menu so that it is always interfering with the scene view. The only way I have found to is to toggle off Gizmos which makes my gizmos unusable in playmode, lest I deal with the nav almost always being selected, thus causing problems with unwanted terrain raises in playmode. Please fix this as the best bet would be to revert backwards to nav legacy
     
    TJHeuvel-net and Vincent454 like this.
  43. WakingDragon

    WakingDragon

    Joined:
    Mar 18, 2018
    Posts:
    41
    I figured out how to generate a navmesh at runtime, but the namespace for NavMeshSurface is Unity.AI.Navigation as opposed to UnityEngine.AI. Is there a reason for this? I wasted a lot of time trying to locate the access to the component.
     
    Last edited: Feb 24, 2023
    kvfreedom likes this.
  44. bonickhausen

    bonickhausen

    Joined:
    Jan 20, 2014
    Posts:
    115
    As usual, Unity's latest packages haven't been battle-tested and lack stability/essential features. Nothing new under the sun. You guys should try making a game first with your own tools before releasing half-baked solutions.
     
    Vincent454 and HenryTownshend like this.
  45. Sacryn

    Sacryn

    Joined:
    Jan 17, 2014
    Posts:
    6
    The only reason we're limited to a box shape is due to the implementation of NavMeshSurfaces and the modifiers in the package. The underlying API can handle other shapes, such as a mesh. Using my solution that exposes other shapes than the default box shape (see this post https://forum.unity.com/threads/nav-generating-inside-non-walkable-objects.445177/#post-8855482) you could potentially generate a mesh from a spline and use that mesh as the modifier volume.
     
    mbussidk and DwinTeimlon like this.
  46. SolumDA

    SolumDA

    Joined:
    Jun 3, 2021
    Posts:
    6
    When I put the navmesh surface inside a Terrain, they bake correct the terrain but, don't bake the trees, is this a bug or I missing something ? (the older navmesh work correct on second image)
    New navmesh:
    upload_2023-3-26_22-5-59.png
    Older navmesh:
    upload_2023-3-26_22-5-55.png
     
  47. vegardkv

    vegardkv

    Joined:
    Mar 18, 2022
    Posts:
    2
    I've run into the same, and I think this might be related to an older issue:
    https://answers.unity.com/questions/1876528/navmesh-not-working-with-terrain-trees.html
    https://issuetracker.unity3d.com/is...re-not-taken-into-account-when-baking-navmesh

    I guess this doesn't solve the problem, though :-/
     
  48. t-ley

    t-ley

    Joined:
    Mar 6, 2017
    Posts:
    77
    Might be a good thing or bad meaning it’s such a mess to figure out that not so many people will like. The updater window says NavmeshModifier but nothing about adding the NavMeshSurface but if use say it’s better
     
    Last edited: Aug 20, 2023
    Vincent454 likes this.
  49. Mashimaro7

    Mashimaro7

    Joined:
    Apr 10, 2020
    Posts:
    727
    I don't understand the new navmesh. Do we need to put a Navmesh surface on every surface? I tried the upgrade but it didn't work. My scene has a large amount of walkable objects, there's one large surface and many(several hundred) of walkable rocks/platforms. I tried putting a navmesh surface on just 50 of these, and it's taking 40 minutes to bake... it used to take 10-15 to bake the whole scene lol, not even sure if i'm doing it right to begin with.

    The old navmesh was so much easier to use, but now the gizmos from it are gone so i can't even see the navmesh when it is baked. I accidentally deleted my old bake and it won't let me bake the old mesh, it bakes but says all my navmesh agents need to be on navmeshes, even though i baked it previously and it works fine(heck, it even works on my other branch lol), and i can't really figure out the new one...

    Seriously considering downgrading the project to 2021 but it's such a pain to downgrade lol, i wish Unity wouldn't completely deprecate old features when new ones are made. Or at least make them function the same, without completely changing how everything needs to be done...
     
  50. impheris

    impheris

    Joined:
    Dec 30, 2009
    Posts:
    1,652
    in my humble opinion, i think it should be named in the editor even if is not installed, then when you click it it start to install, i'm saying this based on my experience with the package manager which for me is a bit annoying, most of the times the filters are useless, most of the times the search bar is useless even if i'm writing the name of the package, so having the option in windows>AI is more efficient even if is not installed, in my opinion.
     
    Fatima_Ressie likes this.