Status and Health of NavMesh?

NavMesh components have been marooned on Github for a long time at GitHub - Unity-Technologies/NavMeshComponents: High Level API Components for Runtime NavMesh Building. The system still works very well but it’s alarming that it has never been converted to a proper package for package manager, doesn’t have a branch for every Unity version (for example, there is no Unity 2019.2 branch there), etc.

The issues page on that Github repository is a ghost town of unanswered questions.

Does Unity plan to continue supporting NavMesh? Will it become a regular package like other systems?

Thanks!

1 Like

We plan to move NavMesh component to the package manager early next year.
Support and extensions of NavMesh are currently on hold and will resume in December 2019.
Expect some news in the beginning of 2020.
Thank you!

11 Likes

Please make new NavMesh solution very extensible, right from navmesh population and additional info on navmesh node

Info that often is absent is edge type for each edge in each triangle e.g. inner, wall, cliff

Thanks for taking the time to share that status update, @NicoFXU ! We will wait to hear the news.

Good, I was beginning to think your agent got kicked out of the navmesh.

Hi! Any news on this?

Also the navmesh components are ignoring tree colliders. Any chance this will be solved soon?

1 Like

So … we’re ready! :wink:

5 Likes

Hi all, thank you for your patience.
The Navigation system and the NavMeshComponents repository have mostly been in maintenance mode in the last year or so, with us focusing on solving some of the more pressing issues first.
This year we plan to make improvements related to the generation of the NavMesh at runtime and to bring the NavMeshQuery class to completion and out of the Experimental state. Both goals aim to make the Navigation system more flexible and increase its compatibility with DOTS. Next after that we intend to use the new APIs to transition more and more of Navigation into DOTS systems.
As you can notice our efforts will focus first on low-level APIs and systems. While we will advance with our plans we might or might not make improvements to the NavMeshComponents code, but at least we will keep it compatible with the latest release of Unity or fix critical bugs. We haven’t decided yet when we’ll turn that code into a package but we are considering doing that move as soon as we’ll evaluate a good progress regarding the main goals that I’ve mentioned above.
I hope this update answers some of your questions.

1 Like

There are no branches for some versions because the branch for a previous version works just fine, without difficulties in auto-upgrading the scripts if necessary. For Unity 2019.2 the branch you would want to pull is 2018.3, as mentioned in the README.MD, and the code should auto-upgrade if I’m not mistaken.

Unfortunately this is correct, the reason being that it requires a lot of our attention which for now we have spent mostly on development.

To the best of my knowledge, a definite yes, with plans for more improvements in this area this year compared to the last years.

Yes, at some point in the future, which we haven’t settled upon yet.
With the NavMeshComponents code on Github not receiving many updates lately, may I ask, would it be that much better if it would come in the form of a package? How often do you stumble upon that code in your projects?

1 Like

Sorry to say, probably not any time soon, given the amount of work that we prioritize higher, but we would love to get to solve it at some point.

Thanks for all of that information, @adriant - it’s very helpful and appreciated!

Yes, primarily so that we would know we are on the latest, most correct version for our project. This probably becomes more relevant once you are shipping changes again.

Hi. It’s nearly half way through 2020, are there any further updates?

Are we closer to having NavMeshComponents in the package manager? Has real-time navmesh generation been improved? Has NavMeshQuery class been moved out of its experimental state? Are navmesh components going to recognise tree colliders any time soon?

In short, is there any reason at all for someone starting a project to use Unity’s built-in pathfinding solutions rather than the well-respected A* Pathfinding Project from the Asset Store?

4 Likes

“given the amount of work that we prioritize higher” … what exactly is that? It seems like nothing is moving on NavMesh at all. Can anyone share any progress? Thanks!

6 Likes

To quote @adriant :

This year we plan to make improvements related to the generation of the NavMesh at runtime and to bring the NavMeshQuery class to completion and out of the Experimental state. Both goals aim to make the Navigation system more flexible and increase its compatibility with DOTS. Next after that we intend to use the new APIs to transition more and more of Navigation into DOTS systems.

For perspective, I maintain what appears to be the most comprehensive and well-maintained (unofficial and open source) DOTS navigation package. Why? Performance, especially for simulations with thousands of agents. Plus, I needed auto-jumping; parenting agents to surfaces so said surfaces could translate while agents traversed them; etc. It is entirely dependent on the NavMeshQuery, the use of which I had to hack. You can read about some of my trials and tribulations in this blog post, but the point I want to make is this: re-working the low-level APIs for DOTS interoperability is and should be the highest priority so higher-level nav code uses idioms, not anti-patterns like what I’ve resorted to. My code is more like a hacky proof-of-concept compared to, what I suspect, is the ultimate goal.

That said, I conjecture the overall plan for navigation is this:

  • Lifting the NavMeshQuery out of its experimental state, which is, at least, months of intellectually-grueling labor by my estimate and, admittedly, I have underestimated things in the past. Pretty sure this effort started sometime in 2020 based on this thread . This is the kind of work that doesn’t see the light of day until it’s ready, because anything else will not inspire confidence and buy-in, despite the importance from a performance, readability and maintainability perspective. I’m sure interoperability with DOTS involved some re-work because the Entities API is not quite stable, although breaking changes are few and far between nowadays (it’s pretty mature at this point, IMO).

  • Building an official, higher-level DOTS navigation solution.

  • A campaign to transition folks from the legacy system to the “trendy” one, so I like to call it, leaning on the experience I had in the aerospace industry rewriting distributed systems.

Finally—if anybody from Unity is reading, I happen to be committed to both navigation and DOTS. I would love to help accelerate official development so the users have what they need ASAP. There’s a job posting for navigation and motion planning, although it seems restricted to Montreal, but I’m based in the Eastern US. Please let me know if there’s some way I can be of assistance.

8 Likes

@reesechultz, I’ll contact you privately.
Yes, we are hiring for NavMesh, and East Coast is OK.
Talk to you soon.

reeseschultz

2 Likes

We are in the process of designing and implementing a package for building the NavMesh from ECS data. It is highly experimental right now and not ready yet for public review.

We encourage anyone to rely in their projects only on the stable/non-experimental Navigation features, if these cover their needs. As of today, everything that we’re working on will take a long time to stabilize.

3 Likes

Are there any updates on this? As far as I can see, there’s no support for any 2020 version.
I’d like to have possibility to use baking in real time. Or are there any other possibilities?

Is “Nav Mesh Obstacle” and “Carve” the answer?

Not only there is no real development being done on this, no package, but also there is no compatibility with newer versions of Unity.
What are the Navmesh and AI teams doing at Unity since 2016? Just wondering…

Is there Experimental package out yet?

1 Like