Connecting "chunks" of navmesh

Read topic name please, and some messages in it, then reply. NavMesh Components was released 5 years ago. Last message here at 2019. Your link not a news.

 

Here is my crude solution to this problem, if anyone is still insistent on using NavMesh surfaces. If we are baking the map in chunks, we can bake all chunks with even coordinates(the sum of x&y) different from odd coordinates. Then, whenever a navmesh agent reaches a point at which it might be able to cross chunks(this can be determined through [agent.remainingDistance <= agent.stoppingDistance] and the fact that the true coordinates aren't within the current chunk's navmesh bounds), we can sample the position from the current agent position but only with the opposite chunk's area mesh code(it's a bitmask parameter). Then we can check whether the distance between the current agent position and the sampled position is within an allowable distance, say 5 or 2(depends how far you want them to jump), and if it is, you can warp the agent to the sampled position, and then retry generating the path(SetDestination(prevDest)).

To allow for further pathfinding between meshes, you can then build a point nav-mesh link between the two points after warping the agent, such that future agents will not have to go through the process. This guarantees that agents will not try to go back and forth between meshes, but it won't have the most optimal paths between meshes.

 

hey, it might work, but i just made a script to place navmesh links across all unique edges, but i didnt test it yet, because im in process of making ai logic of my enemies.
https://github.com/SnaiperoG3D/NavMeshLinksPlacer

 

I tried

I tried to think through that solution, but in a case where the height of the navmesh varies, placing a set amount of navmesh links is bound to have some problems. If we place it like a general point and increase the width to the size of the chunk, I'm pretty sure it wouldn't work because there would be places where the link is under the mesh or way over the mesh. You could try to make a large number of point links between the edges by raycasting to the surfaces, but then you need some algorithm to make sure they're connected to navmeshes on both sides(or you could leave them floating), and it might cause other problems(I'm not sure but other people warned against it).

There are some flaws with my previous solution, so here's my current one.

Create 4 area maps(the minimum amount so that no corners and edges have the same color) and generate them in this pattern. X-coord Y-coord odd is a diff color, X-coord Y-coord even is a diff color, X-coord Y-coord odd even diff color, and X-coord Y-coord even odd is a diff color. This pattern makes it so that at any corner, there are four unique colors in all directions. Then, when filling the conditions to jump chunks, try to sample to closest position on all the area maps, and for all the positions closer than the allowable jump distance, take the one that is closest to the solution and jump there(if it is your current position, then fail the jump). You should be able to make a link between your previous position and your current position.






The reason we have to do this is because, in the previous solution, the agent is not able to jump more than one chunk per path. If it was allowed to do this, it may jump to another chunk, set its path to the same path but jump back to where it was before and make an infinite loop. My previous solution to that was to disallow multiple jumps even if it had not reached its desired chunk. I'm sure you could still use that solution, but I currently switched to what I'm doing now so I can squeeze the most out of this pathfinding.

 

I will test links and let you know how it was.

Interesting solution, thanks for idea

 

This "ancient topic" is really a "ancient problem that has yet to be solved without needless hacks". Runtime navmesh generation already existed before, this isn't new. Not being able to set/get the actual navmesh data itself is insane, and no, it is not yet supported in the package.

 

Allright. So how i solved that.
First of all, i have a multiplayer game, so i have a server and a client. And for server i need a full generated navmesh.

I found 2 solutions. First one to use NavMeshLinks with my script above. As you said there are problems with transition of agents, but i easyly solved that with custom offmeshlink travel. I just wrote my logic for my walking agents on links, and bump. I did some tests and everything is ok but i didnt go deep because i found another solution for me.

There is second one. It might not help for every situation but it works for me. As i said, i have a big map for my multiplayer game. It has 64 mesh terrains (terrains converted to meshes for optimisation). So i just made one root NavMeshSurface on main scene. Load all possible scene. And build it. Also my game is mobile, so i did a runtime NavMesh bake on server start to reduce apk size. So navmesh will be only in ram on the server.
Also i have another NavMeshSurfaces on each terrain or other object to local surface build, if i need to test navmesh without build entire map.

For people who cant use this method, i recomend to try my first solution or Blackmagic919 variant.
Also you can try to runtime build navmesh around the player like in this video. I got logic for my runtime build exacly here.

 

The best one can do is using NavMesh Links. I wish they could be splines besides just rectangles, but you can somewhat get away with using many of them on curved connections.

 

For me, an approach I went with was to place 1 off mesh link per agent instead of dynamically generating thousands. For height variation, you could probably do a ray cast up and down or sample nearest nav mesh point and place it.

 

I found a topic that might be useful to people still following this. It seems there's a way to (re)bake a portion of a NavMesh using a method called UpdateNavMeshDataAsync. Perhaps it would be possible to indeed have one NavMeshSurface for the whole thing and update it in chuncks.

 

Did this work? I'm digging into doing exactly this right now using my own version of LocalNavMeshBuilder and so far what I'm seeing is that two scripts trying to do an UpdateNavMeshDataAsync on the same NavMeshData doesn't seem to work. Instead of instantiating a new NavMeshData per LocalNavMeshBuilder (I called mine 'MultiplayerNavMeshBuilder' but it works almost exactly the same way) I instantiate one static NavMeshData and try to update that. It looks like only one UpdateNavMeshDataAsync() at a time can happen, though.

I'm curious if anybody has a good solution here? I'll have ~10 players in a top-down game with each player updating the nav near them at runtime, ideally with some runtime vertical-jump navlinks being generated.

So far I haven't found a solution that fits my needs...

 

Do you have need for a runtime updating navmesh because the terrain is changing? I do the same thing with just updating around players with something like a 50m radius. It's super fast and has been working fine. I used to do a chunk based system but there was never a way to setup links, so NPCs would always act really stupid on the seams.

 

Yes, I have terrain deformation and some player building stuff. I punted this for now, might get back to it down the road a bit but I have a solution that I can make work eventually. Hopefully navmesh stitching magically becomes a thing before then lol