NavMeshBuilder.BuildNavMeshAsync() where is it ?

According to the documentation:

https://docs.unity3d.com/ScriptReference/AI.NavMeshBuilder.BuildNavMeshAsync.html

This method exists. But i can't seem to access it ? It simply is not something that exists when i try to access it.

I am really confused why unity is half-assing the navmesh component systems. Is it abandon ware? Whats going on here, why is this stuff so poorly documented, and only available on git hub not even the package manager? It's really annoying me because its almost forcing me to buy an expensive asset or just use unreal at this point.

Has any one been able to use it ? I don't know why i can't access it.

 

Well i wanted to use NavMeshSurface but it doesn't call the async build version. So its not really the way to go.

This isn't true though ? The only place it seems to exist is under the editor only code.

See here:


Under UnityEngine.AI.NavMeshBuilder, it does not have an async method.

See here:


This is what i am saying about the way Unity is handling these components, it's so confusing and the documentation isn't even correct. It all seems a bit of a mess. I am really confused by it all since it was announced in unity 5 but its almost like you guys have abandoned it half completed.

 

Okay thank you for clarifying.

Will you guys be able to add Async for navMeshSurface.BuildNavMesh() because that seems to call the non async version:

Code (CSharp):

1.  
2. // NavMeshSurface.cs
3. // Method : BuildNavMesh();
4. // Line: 157
5. var data = NavMeshBuilder.BuildNavMeshData(GetBuildSettings(),
6.                     sources, sourcesBounds, transform.position, transform.rotation);

Unless build async is deliberately only available for editor due to the namespace, which if so, is an unusual decision since async is quite useful for run time.

 

Hey guys, did this ever happen? Even with relatively small areas, BuildNavMesh causes my game to stutter badly on the frame that it happens. I'd love to be able to BuildNavMeshAsync at runtime. I'm sure there are ways I can do it myself, but please understand that I'm trying to make a game without having to understand how every component works under the covers.

 

Can you just add this, please? It's so silly not to have it and having a convenience method for the most valuable runtime use case that is maintained as part of the project is extremely reasonable. Why have the default offer bad performance?

 

+1. Can you please add this method??? If we need to hack together a bunch of methods to do this, why not just add it?

 

@Jakob_Unity Could you or someone else working on the navigation provide an example of how to do this?

 

Yeah, still another request to just build this in, or at least provide a modern example. It's been almost half a decade, and the NavMesh Components stuff has all been long since abandoned--but we still need to actually make nav meshes at runtime without locking up the main thread. It may be possible to reverse engineer all that antediluvian component code to "let the developers write their own implementation," but just looking at it gives me a headache. I can't believe the current, non-async runtime code would be acceptable to almost anybody, right? It takes significant fractions of a second even on simple cases.

 

So I beat my way through this.

Short answer:
In a Co-routine:
...CollectSources, get build settings, as usual, then:
NavMeshData data = new NavMeshData()
AsyncOperation operation = NavMeshBuilder.UpdateNavMeshDataAsync(data...)
while (!operation.done) yield return null;
NavMesh.AddNavMeshData(data);

If that's not enough, I wrote up the (very) long answer here: https://ckempke.github.io/Blog/blog/runtime_navmesh/

That gives pretty much all the background, as well as some actual cut-and-pastable code at the end. Hopefully it helps out the next person who needs to do this...

 

@ckempke I was hoping to optimize your answer by leveraging a yield return on (pseudocode) WaitUntil NavBuldMesh.IsRunning != true but I didn't have much luck. Your answer still stands!

 

just want to say thanks to @ckempke for your blog post. Very helpful.
also, the mind boggles at quite how confusing and multiply-half baked the unity nav mesh system is.
There is something like four or five different attempts at what is essentially exactly the same actually very useful system with marginal improvements / changes in functionality, different namespaces / integrated / not integrated with Editor, github, package. the list goes on. Kafka would have a field day.