Runtime Loading / Saving Navmesh Data??? Lol?

You are describing an approach that works for a very narrow range of scenarios. Good it works for you, it will absolutely fail in others.

The binary tile data isn't of much use to you. If you want to read it you can probably do so using this as a starting point. Unity might have modified a few things but I doubt by much, this works with default recast tiles.

https://github.com/gamemachine/ainav/blob/master/Assets/AiNavCore/NavMeshTile.cs

But Unity already provides the triangulation. You can't load the tile data into the navmesh at runtime, Unity doesn't provide api's to do that. So other then triangulation there is nothing you can do with the data.

 

Kind of sounds like black magic to me, I'd be very happy if there's something I missed out on though. I'll check out the example scenes in the morning. What I'm doing now is generating solitary navmeshes to the tune of something like 150m squared. Players move freely, so this only for monster/animal pathfinding, so only the server is making them. If a player enters an area a navmesh has not been generated a new navmesh is rendered to cover that area. So I end up with slightly overlapping tiles covering everything. This supports multiple storied buildings, etc.

My problem is that those individual instances aren't aware of one another. You're suggesting you can add volumes onto a single instance? ie: I could be adding tiles to a "global" navmesh as needed? 'Cuz tha'd be awesome. I honestly don't need to save/load the data, the rendering is actually very fast and off thread. I'd be happy to test writing and reading as an alternative though.

 

I know. Hence serialize the generated MESH, (in binary will work fine, since it is just a float[] 3 times longer than the Vector3[]) then build a NAVMESH from it at runtime.

Right now, I hardly even need to serialize the terrain, as run time generation of both the terrain and navmesh is like 500 MS for a 200 x 200 mesh. I am used to games taking at least 10 seconds to load a map, so...

The NavMeshComponents high level API has 7 different unique examples of runtime navmesh updates.

For future readers, you can either believe snacktime that all is lost, Unity sucks, and its high level API is garbage and will not provide any solution for your problem.... or you can download the NavMeshComponents and see for yourself if just one of the seven provided ways of rebuilding a navmesh will work for you, or provide a foundation to build off of.


https://github.com/Unity-Technologies/NavMeshComponents
consult the FAQ on this website, then check out the examples.

I am not monkeying around with 2019.3, so perhaps terrain holes will cause difficulties. I personally am generating my own maps meshes, so the how terrain does their thing is quite irrelevant to me.

 

None of the solutions shown in the examples provides the goal of what we want in this thread. I've gone through every single one of them, and none of them work for me. I'm glad you found a solution that works for you though.

 

I never said there was a solution.
This is what I said:

 

I went through the sample projects again, and none of those are as useful as you make them sound. I'm not sure if you think there's more going on there than there is or what, but in most of the scenes they are simply recreating the navmesh as fast as they can nonstop. There is no merging or joining going on. That's fine for a simple game with a very tiny field of play, but when you have multiple players spread out across tens of thousands of kilometers, you can't just spam navmesh refreshes out constantly, and even if you did two "areas" can still never attach unless you were to broaden a single navmesh to encompass multiple areas, making updates all that more intense.
They literally use the same script in every scene which is just

Code (CSharp):

1. UpdateNavMesh(true);
2. yield return m_Operation;

So I say again, for small areas of navmesh, yes the async operations work well. Beyond that it's a very incomplete system.

"NavMesh Modifier Volume marks a defined area as a certain type (for example, Lava or Door)". That has nothing to do with changing the navmesh itself or adding new area to a navmesh.

??

 

You were suggesting there is some way to attach new data to a navmesh or connect dynamic navmeshes generated on a terrain. That is incorrect, and there are no examples of that in the Unity provided project.

All that's happening in scene 2 is they spawn a rectangle, then they rebuild the entire NavMesh. It's not saving performance by "adding" to it, or incorporating any new space. There is a predefined volume that the NavMeshBuilder is set to render, and when you add something inside of that volume and rebuild, it accounts for the added GameObject. That's the whole point of the async operation, but again, has nothing to do with "adding", "melding", or "connecting" NavMeshes. They're rebuilding the entire NavMesh.

This is not true. All the NavMeshModifierVolume does is specify the "area" (what type of area for agent AI) for a specific space within a NavMesh. It has nothing to do with the actual generation of the NavMesh nor the objects that are taken into account during that generation. As you can see in example #5 where there are not NavMeshModifierVolumes being used. They're just rebuilding the NavMesh over and over, updating the "center" to follow the player object. Open up and look at the script, there is no mention or use of Modifiers or ModifierVolumes. The only difference of a Modifier and a ModifierVolume is that one operates off of the mesh of a GameObject (Modifier) and another will change the area within any NavMesh that is generated within the specified volume.

Here are the quotes from the manual:
"NavMesh Modifiers adjust how a specific GameObject behaves during NavMesh baking at runtime."
"NavMesh Modifier Volume marks a defined area as a certain type (for example, Lava or Door). Whereas NavMesh Modifier marks certain GameObjects with an area type. NavMesh Modifier Volume allows you to change an area type locally based on a specific volume."

You make it sound like there is something special going on, and you point to the example scenes, but there is nothing special going on. They are rebuilding the NavMesh every Update(), only yielding to the builder coroutine itself.
There is no neighbor connection possible, nor shown in any of the examples.
There is no "adding" to a NavMesh without simply rebuilding the entire NavMesh, nor is that shown in any of the examples.

 

Sorry, are you saying that if you dynamically instantiate a NavMeshModifierVolume it will regenerate any NavMeshSurface's in it's area to accommodate new geometry in a way that is faster than simply regenerating the whole surface?

So for example, If I had flat terrain with some trees on it and a NavMeshSurface pre-baked in the editor, then at runtime instantiate a 2 story building with a NavMeshModifierVolume around it, the building floor plan would be generated and added to the scenes NavMeshSurface?

Its not really what the docs suggest the volume is for, though they do say that the surface must be updated.

"The NavMesh Modifier Volume affects the NavMesh generation process, this means the NavMesh has to be updated to reflect changes to NavMesh Modifier Volumes."

But it's not clear that they would do it any faster than simply rebuilding the entire scene.

I guess I will set up a test.

 

@IronHelmet
If anything it would make the generation a tad slower, though I doubt it would even be a measurable amount. A NavMeshModifier (volume or not) does NOT affect the mesh itself. It assigns an "area" (that's the terminology Unity uses) within a navmesh, using either a specified Volume (NavMeshModifierVolume) or an object (NavMeshModifier). "Areas" are used to define things like lava, water, impassible, or slow, or fast terrain, for example. They don't actual do anything to the navmesh itself.

In order to add your buildings floor plans to the pre-baked navmesh you need to regenerate the navmesh in its entirety. Ne0mega made it sounds like there was magic going on, but I went through each of the scripts one by one and there is no such thing. All of the example scenes are simply regenerating the navmesh completely.

If you need to specify different types of areas within a single navmesh instead of generating links between different navmeshes to define areas, then NavMeshModifiers come into play.

 

Areas are recast terminology. They are actually built into navmesh tiles, every poly has an area id.. you have to rebuild a tile to assign a new area.

recast input looks a lot like the structure for a mesh. It takes vertices, triangles, and then areas are an additional array the same size as triangles. So one area per triangle. So modifier volumes are just that extra data.

Changing areas doesn't require having to regenerate the triangle/vert inputs but it does require rebuilding the tile. But rebuilding tiles when you have all the data is really fast. And Unity is likely caching that data. So they just pass the existing vert/tri data and the new area array.

 

Hello guys
i use navSurface for the runtime baking
Is there a way to save navmesh in a file at the runtime after runtime baking and then load it in the next execution instead of re-baking?

 

Nope =[

 

i found here one way to save navMesh on the disk
Just left only read and attach this file to the navmeshsurface

https://forum.unity.com/threads/accessing-navmesh-vertices.130883/

 

That's not the baked navmesh. The whole point of this thread is to be able to save the baked navmesh at runtime. And the point of that is so you can do incremental updates and only ever have to update the most recent changes.

The navmesh triangulation is not the same as the source data either. It won't have enough detail to reproduce the same navmesh as the original source in a lot of cases. Even if it retained enough detail all you could do with it is use it to rebuild the entire navmesh. Which is what you are trying to avoid to start with.

Unity could support this rather easily with two methods on NavMeshData.

Code (csharp):

1.  
2. NativeArray<byte> ToNativeArray(Allocator allocator);
3. FromNativeArray(NativeArray<byte> data);
4.  

No need to expose internal structures and trivial for them to map to the internal structures using NativeArray slices and re interpret.

 

Hello
In fact, I was disappointed from Unity's navigation capabilities and went to a star
Is it possible to save and load the baked navmesh with this code that you said so that it does not bake again in the next execution?
Note: Every time may the whole terrain changes and we want the terrain to be baked only once and the previously baked data to be used in the next executions.

 

Having said that. I still use Unity's NavMesh. I redraw based on a threshold of change in player position, only a large enough area to encompass any AI that might be enabled due to proximity to the player. It's asynchronous and takes less than half a second to update.

 

So you just give us false hope since 2017, 4 years of no progress

 

I haven't tried it yet, but isn't this made for this particular reason?

 

I believe that is nothing new. There is still no way to convert between the existing NavMeshData class and byte array.

 

Nope, it just internally generate navmesh in the same system. The navmeshsurface is just a helper wrapper to make it easier (you can see the source in github), but nothing about internal navmesh system was access. It just have better runtime generation

The whole point of this request is we want to serialize the generated navmesh and deserialize it when there is large and complex chunk of terrain, especially procedural one, so it could be loaded faster

 

Also Jakob_Unity hasn't been seen on the forums since 2017... so that entire team was most likely abandoned years ago... unfortunately... No clue if they're working on something "better" or ever plan on improving the current system with any of the many features it's still missing.

 

Just from recent tests, NavMeshData can be saved by declaring as a member of Monobehavior class.

 

Runtime ?

 

Not sure what you're mentioning off the top of my head, working on 2D atm, but even if you find a way to save sufficient data to be able to recreate the navmesh in its entirety in runtime, it's still useless without a method to import that data back into the system in runtime. We're not discussing editor tools, but the ability to bake, save, and load via the end user.

 

Up ! We need this feature. Any update ?

 

These are the features of the Unity Editor and are not available to the user

 

Might not be helpful, but just a bunch of ideas:
What about implementing pathfinding on a custom mesh? One can start with a regular NavMesh.CalculateTriangulation(). A-Star Algorithm on a (nav-)mesh is not too hard to implement, there are ressources on the web.. A custom mesh could be saved to file, loaded, built at runtime, everything.
Apart from pathfinding, the navigation system is mostly a logic to keep agents on the mesh, plus different zones. (Or am I missing something? Please tell me, I haven't used the navigation system much..) Re-implementing those, one would be completely independant of Unity's C++-side, depending on the implementation maybe with worse performance, but full control.
And as mentioned before, recast is open source, so if unity's runtime navmesh components don't work for you, you could call your own recast calculation from code. (Like Aron Granberg's A* Pathfinnding Project does)

 

Aaron Granberg's stuff is definitely decent, I own the Pro version, but I've never actually ended up using it in production. Generating navmeshes in runtime took way too long or was unsupported and other methods like recast don't really work when you're trying to guide mobs up staircases, etc. while still giving them gravity and physics, etc. They get stuck in loops on corners, etc. a lot. But yes, that's the ultimate goal. I just have 700 other things to do and don't want to spend several months perfecting my own custom system for something that already works really well. It could just be so much more useful with a little more open and available to the community.

I don't think they've done any work on the NavMesh components for years by now... It's just locked away in a box somewhere because their main money makers don't use procedural content, or just don't need it, or whatever, y'know. It's a business.

 

I agree, though I consider agents getting stuck more as an issue of the steering function (such as NavMeshAgent). In my scenes, Navmesh itself does not create issues like that. But it also depends on how scene colliders are setup of course..

I think if one does (open world style-) procedural generation, it is a better idea to spawn some kind of waypoints using the procedural system, instead of using a Navmesh. The thought of a whole terrain tile, which was just created being voxelized and raycast while the game is running kind of scares me. ;-)

 

I have been quietly following this thread for a couple of years. This has also been a blocker for me. However, I'm holding out faint hope based on the navigation roadmap.

https://unity.com/roadmap/unity-platform/navigation-game-ai

Specifically, these two topics currently listed as "planned":

• Navigation in Continuous Worlds
• Progressive Rearchitecture: Navmesh baking

"...we are considering reworking the entire baking process to make it more performant, and scale to the needs of large open world."

If anything on the roadmap sounds like it would solve your problems, I encourage you to provide feedback on it. (Click on the topic, and a modal pops up where you can explain your use case.) This appears to be their official feedback mechanism. Based on what I know of corporate business, this is more likely to get attention than commenting on forum threads. The product managers probably review the feedback periodically as they decide which projects to fund and prioritize. So, yeah... make your voice heard and maybe we can get some movement here.

 

While it's official it totally hard to use with bad UX flow

The feedback system should be github issue. And the system itself should be opensourced

 

Any progress on this or has it been abandoned?

 

as far as I know nothing new has changed