Hello Navigators and Pathfinders,
I’m a dev at Unity who is currently being onboarded onto the Navigation team. As part of this process, I am curious to hear from you all what your perception is of the Navigation feature set.
Is it stable or is it buggy?
Is it performant or is it slow?
Does it contain the features you need to create what you want?
Does the documentation feel complete, or is it lacking in some areas?
Is the user experience of the tooling easy to work and iterate with?
In your response, do add which Unity and Navigation package version you are using, so that I know what you are basing your feedback on, also try to dig into the feedback a bit, so I know where you are coming from.
We use Navigation extensively with some of our games, typically in very sandbox environments, i.e. everything is built at runtime.
In general, we have found the Navigation system to be very powerful and mature once you figure out how to use it properly. We create all our own NavMeshBuildSources and send that to the NavMeshBuilder for an async build.
There are only 2 major drawbacks:
Agent groups
When multiple agents exist in the same world it get’s very messy very quick. Something we do is have a NavMeshObstacle on every agent and when the person stops, the Agent gets deactivated that Obstacle gets activated, just so other agents path around them properly.
Of course it leads to issues with agents blocking doors and staircases unnecessarily, but it’s way better than the alternative behaviour.
When agents move in a group, like RTS-style “you guys attack those guys”, it get’s really bad, even with 6 vs 6 agents already.
Destructible obstacles
Our worlds are sandbox and your enemies might try to tear down your base. So, enemy AI needs to find a path into the house through the walls. Our solution is to add an OffMeshLink to every single wall, so we have hundreds or thousands of them.
We have not noticed many performance problems with this yet, but it’s very awkward and it gets worse if we are not talking about walls, where there are clearly 2 sides to be connected by the link, but something like a big rock, where you can access it from multiple sides and you might unlock many different paths, then OffMeshLinks break down.
It might be possible to use super expensive NavMeshAreas for this purpose and the AI starts destroying the rock when they enter an expensive area, but the problem with this is that area cost depends on the distance through the area and we’d need a constant cost for passing through this one obstacle, so it doesn’t quite fit.
If anyone has other ideas or suggestions for these issues, I’m all ears, of course
Thank you @Ponzel for the feedback!
I’ll bring these two items back to the team, so we can discuss them further. Regarding the OffMeshLink issue you are noticing, we would love to receive a repro case if you have one lying around, as we are currently working on the NavMeshLink (which is the next iteration of OffMeshLink), you could send it in a DM whenever you have the time, thanks!
The current Navigation is buggy, bad performance and not scalable to open world scale. One of the biggest missing feature I think is able to generate navigation at runtime to solve the dynamic obstacle problem for the game environment that will always changing obstacle count, size and position. Currently I can’t do the open world scale multiplayer game project that needs to scale from mobile platform specially Android to console until high end pc platform. I think it’s better to rewrite a completely new Navigation system from scratch just like new Animation system with unity dots tech that the entire codebase is ships with full complete HPC# source code as a package that Navigation backend will get performance by default. Unity user can still using regular Game Object workflow to develop game or move to dots workflow if want to get even better performance. From what I know, official currently is working on streamlining both game object and dots workflow.
Thanks for chiming in @optimise . When you say “The current Navigation is buggy, bad performance”, could you be more specific on why you perceive this is the current state of Navigation? I recently heard the opposite claims from a number of users, so I want to understand if there is a special use case where the current navigation feature set fails you.
This seems like a bug. If you believe it is a bug, do file a bug report so that we can take a closer look.
One of the thread mentioned about the navigation system issues ( https://discussions.unity.com/t/896370 ). For me the thing that make the situation really worst is official deprecate experimental multithreading navigation API that has been at experimental stage for really long time without proper replacement yet. So I really hope official implements new navigation system powered by dots to become proper replacement very soon ships as full HPC# source code package to actually address all the navigation issues. It’s not just performance but also unity user can fix the issue without require waiting for official to roll out fix into unpredictable editor version which is just too slow. Another reason is to increase performance and slim down size for both editor and player runtime build if don’t need navigation system. Official can continue to patch current navigation system but I think some issues needs to full complete rewrite to address fundamental level issues.
I am currently working on a issue with the navigation system, it seems the Navigation has a hard cap on path complexity and will just return a partial path if the target is too far away (either in distance or pathfinding complexity).
Could neither find details on what is exactly this hard cap (to try to adapt our content), or how to increase that cap if I was willing to trade away performance to solve those paths.
I haven’t worked with Navigation in about a year, so my knowledge might be outdated. However, not running the (asynchronous) navigation code on the main thread is something I would have really appreciated seeing back then.
I think that’s because of the different interpretation of the word “performance”. For some, this means the FPS of the Game and the Navigation doesn’t change the FPS.
But for some it means the actual performance of the system, how fast it can deliver paths - and in this regard it’s super slow. When 100 Agents get a new destination at same time, the last one starts moving 2 seconds after the request. When they try to chase the player, the repathing is so slow, they will run past the player all the time. It’s just total chaos.
So impact on game FPS is fine but actual path-request-answer-time is really bad, game breaking bad.
I had the same problem, what I did was to create my own queue of path requests and I’m not allowing all agents to find a path at the same time but only about 10.
My suspicion is that system is searching for paths for all the agents at the “same time” but it is doing it partially for every agent. Something like search x nodes for Agent1 and search x nodes for Agent2 etc. and this is done over multiple frames. Instead of searching path for first agent and than for second.
I personally really don’t like everything about design of navmeshagent api and inability to customize default agent. API should be low level and everyone shoud be able to create an agent (transform or physical based) on top of it. Just like many character controllers built on top of low level physics api. Default agent should be just a sample provided to us as a reference. And also obstacle avoiding is very outdated at this point.
Thank you all for sharing your perspective of the state of Navigation. The Nav team and I will go through your responses, log the feedback and reach out to you if we need to clarify things further.
We will keep monitoring this thread, so if you have more feedback, don’t hesitate to write it here.
Hey Ted, first I want to thank you for starting a conversation with the community. Things like this help boost the community’s confidence and helps the entire community over all.
As a former member of the 2D Singapore team you probably heard this a lot, but 2D Navmesh would be a great thing.
There is the community package that people have been using from the forums, but an official system would be nice.
The following is for 3D and 2D benefits
I would like to propose the following for Navmesh because I think a lot of devs would find this to be super beneficial.
Create a foundational system for agents, nav mesh baking, navmesh grids/geomentry, avoidance obstacles, and links that can serve as a foundation to build on top of for custom functionality.
This would make things easier for the Unity devs working on the feature such as you by making a system that acts as a cornerstone that you can build features on top of without having to refactor a lot in the future. To do this I mean the following.
Seperate the logic of Agents and Navmesh. Agents should be a general system that just has a navigate command it can follow or execute. This can allow for making things like Splines act as an Agent path, the Navmesh Grid as an Agent Path, and allow for tool creators to customize their own pathing system if need be.
This could also make it easier for people to have an agent follow a spline during things for Timeline and Sequences which allows other Unity created tools to work with them easier. People would love to be able to have Agents follow a Spline for cutscenes, Highways on the road, and even following a predefined path for things like enemies to patrol around.
Have Agents be able to understand parameters to choose what Navigation logic it should follow. This could be used for obstacle avoidance, real time world updating of walkable paths, grid systems like Fire Emblem games, 2D Tile Map systems for using a Tile Layer as a harder to navigate through option, and even allow for things like Agents that can fly, swim, and so forth.
At the moment Agents is to tired to Navmesh. I think there should be an INavigate interface that Agents implement and allow it to be overidden or some how injected into the Agent class to allow for these customization.
This way now we not only have Agents that can follow Navigation patterns, but anything that implements INavigate. So other things outside of agents could follow Navmesh, Splines, or any custom tool that implements the new API.
The above is what I think would be the best step for allowing improvements to the Navmesh system. Creating a foundation for Agents or anything else that can navigate nav paths.
So the following.
Agents are seperate things out of the Nav Mesh baking system. They can follow anything via implementing the INavigate interface.
Seperate the idea of Navmesh being the only path that can be followed. Have something that acts like an IPath interface that can be used to implement any type of path following such as following on Navmesh geometry, Spline paths, or allow community devs to extend their own tooling from it.
Have a way to implement avoidance systems by marking any object such as a Tile, Sprite, Game Object, or Collider change the difficulty of any path following agent to make AI smart enough to avoid things like muddy terrain, ice terrain, and so forth.
Thanks for the write-down, @Jonathan-Westfall-8Bits . From the feedback I’ve read so far, and the discussions I’ve had, I think you are spot on. Being able to decouple the different navigation pieces, and allow for more custom implementation would greatly help both us and the community in creating better Navigation solutions.
Just Enabled nav mesh on small terrain and project became unresponsive. Never had such an experience before. Unity 2022 LTS. Calculations took 45 min ! When showing navmesh in editor its like 1-2 FPS and unresponsive. Opening the map takes 10 min ( before 10 sec ).
My main wishes are to do with the actual creation of the navmesh
In that the old system was so superior.
Heres an old post of mine (I’ve written here more than once, seeing if theres any hacks I could use)
Basically I want 2 things that was easily done with the old system
Designate meshes not-walkable, (uncheck nav-static) i.e. the navmesh will get created around them but not on top of them. Seems a huge oversight with the new system
Allow me to paint on a terrain where the navmesh will be created.
In the old system, I would create 2 terrains (I also made a script so if I change terrains heights both terrains would change)
-Terrain #1
-Terrain #2 Navmesh, I would paint on this with ‘paint holes’ and then click generate navmesh from this terrain.
During actual game #2 is hidden,
At the moment I’m still using the main terrain from > a year ago in my game, I would like to ‘fix’ things eg smooth heights, add new terrain features etc but in doing so I would be forced to rebuild the navmesh, which would be much worse due to #1 & 2
Along with most of the features and quirks everyone else has mentioned, one of my biggest pet peeve has always been how absolutely difficult it is to actually determine the current state of any given nav agent. Detecting stalls in their motion or whether or not they are actually currently making progress along their path is basically something that has to be hand-rolled and is fraught with so many edges cases that you always end up with something that is absolutely guaranteed to fail under specific conditions that are entirely possible if not outright common in most games. The most common cause of this sort of thing is simply due to obstacles that block the agent’s path but aren’t actually part of the nav system itself, causing the agents to run at walls indefinitely.
Along with that there are quite a few times where I’d love to be able to share a path between multiple agents. The current system unfortunately causes memory allocations which makes it impractical when dealing with many many agents - which is the most common reason you’d want to share paths in the first place!
And finally, the flexibility in range of motion for agents seems quite limited. As ab example, A* Pathfinding Project has many features that allow for very complex ranges of motion including moving agents along walls and ceilings as well as providing pathing solutions that go beyond merely choosing the most optimal one (As an example, being able to calculate multiple paths within a cost range so that agents can attempt to converge on a target from different directions rather than all running single-file in a line directly to the target). Agents that should behave as though they can fly is another issue I commonly dread dealing with in the current system. It’s always quite hack-ish and can often fail in spectacular ways.
1: To me the biggest thing I would like to see improved is performance.
When you need a lot of agents at once that also need to update their paths often the current system is extremely slow.
Making a grand scale strategy game perform well is near impossible.
As mentioned before repathing for very many agents can also be very slow and unresponsive even if the framerate is high enough.
2: One thing I have noticed are navmesh islands. You can see navmesh generating inside of objects very often. I dont know if these affect path calculation performance but it would be nice to have a way to clean them up. For example by setting up sample positions. If a navmesh island is not reachable from these positions, it is deleted. There are a few reasons this could be useful:
Editor clarity, you can easily see where your agents can and can not go which helps level designers.
Potential performance improvements, as you no longer need to do runtime checks if a point is valid when sampling navmesh positions. This also makes gameplay bugs less likely (AI stuck in walls)
Memory consumption will also be slightly lower as the navmesh is smaller
3: Moving navmesh support would be really useful. For example having a moving and rotating plane that agents can walk around on. They could leave and enter it by using navmesh links.
hi, i would like to point out that navmesh uses A* and it is stated to be always the shortest distance between corners between corridor polygons. however, a person doesnt walk like that. it will instead always find more comfortable avoid being too close to walls, thus prefer paths that are more centred towards the corridor and will smooth out at path corners.
when multi agents are present it is much more noticeable. a handful of the agent would always go along the same shortest path and line up perfectly. (not too many multi agents though, in that case like few dozens of agents or hundreds, we cant keep track of their paths and their local avoidance should be enough to squeeze them apart)
i am looking for more a solution of flow field path finding, where each of the agent would have their velocity in general direction towards the next corridor polygon (maybe centroid or edge?) instead of always picking closest visible corner.
