There's a new Navigation package in town!

Unity Engine
, ,
1

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

25 Likes
2

Very nice news, looking for the JobSystem integration!

Happy to see that you are working on the AI Navigation package as well :slight_smile:

3

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

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.

2 Likes
5

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

5 Likes
6

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

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.

3 Likes
8

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

1 Like
9

Will this version allow agents to use simultaneously the same NavMeshLink?

10

just uncheck this one…
8700213--1174440--upload_2023-1-2_21-46-15.png

1 Like
11

Will the new implementation also be open sourced?

12

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!

1 Like
13

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

@UnityChinny - Are there are updates to NavMesh planned to fix the issues mentioned here :frowning: Issues with NavMeshAgent.SetDestination Stopping Agents )?
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…

2 Likes
15

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

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

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:

  • 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.
  • 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.
  • 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.
  • 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://discussions.unity.com/t/900985/13
6 Likes
18

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.

2 Likes
19

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

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.

2 Likes