Official There's a new Navigation package in town!

Very nice news, looking for the JobSystem integration!

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

 

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?

 

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.

 

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

 

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.

 

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.

 

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

 

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

 

just uncheck this one..

 

Will the new implementation also be open sourced?

 

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!

 

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

 

@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..

 

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

 

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...

 

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

 

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.

 

i like it

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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.

 

ETA on auto navmesh link?

 

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....

 

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

 

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.

 

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:

Spoiler: Comparison

With inflated area:

Without:


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

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

 

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.

 

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.

 

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

 

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.

 

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.

 

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.

 

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:

Older navmesh:

 

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 :-/

 

Seems to Works better as a package but now it’s always in the scene (blue), does a person have to add it at the end of making
The game, how does a person disable it without making it crash why doesn’t it go back to normal, even with other game objects selected it’s blue

 

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...

 

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.