Recast Graph stiching

Hi!

I’m looking for a good way to stitch several Recast Graphs together. We’ve got a setup where we have many separate scenes that are combined into one, large scene for when you play the game. We want to be able to edit these scenes separately, in order to prevent conflicts.

The problem is, we want a contiguous recast graph that covers the entire large scene. We can do this by loading in all the scenes, and then building the recast graph, but that’s cumbersome, and the bake takes a really long time.

What I want to do is for each scene to generate it’s own recast graph, and then when we build the game, we’ll find the borders between the graphs and combine them there. As far as I can tell, there’s nothing like that available in the project by default.

Another thing we’ll want to do, which would require stiching, is to hand-craft navmesh graphs for specific props (bridges, stairs, etc.), instead of having those be baked. That’ll give better, more predictable results. This means that those props must not be a part of the bake, but instead we add the prop’s navmesh to the baked recast graph after bake.

Is any kind of stitching like this a part of the core package? Are there any utilities that would help us achieve this?

Hi

This is not something that is possible out of the box, however it can be done.
The package supports replacing tiles one by one, as that is required for navmesh cutting to work. You might be able to use this functionality for you needs. It’s pretty tricky though, but I think I could help you do it if you want.

That however is not something that can be done with a recast graph. A similar thing that you can do is to use navmesh cutting to cut out a precise contour of your object. However this doesn’t work for bridges, only obstacles that remove parts of the navmesh. See https://arongranberg.com/astar/docs/navmeshcutting.php

Turns out you’re wrong about the second case! Bridges are certainly possible; you even wrote about it yourself! From the docs of NavmeshAdd:

  • This component has a few very specific use-cases.
  • For example if you have a tiled recast graph
  • this component could be used to add bridges
  • in that world.
  • You would create a NavmeshCut object cutting out a hole for the bridge.
  • then add a NavmeshAdd object which fills that space.
  • Make sure NavmeshCut.CutsAddedGeom is disabled on the NavmeshCut, otherwise it will
  • cut away the NavmeshAdd object.
  • Then you can add links between the added geometry and the rest of the world, preferably using NodeLink3.

And it works!
https://youtu.be/8bzdNOEZwLg

The only issue here is that NavmeshCut/NavmeshAdd is runtime-only, but that’s fixable from the things I posted in this thread: NavMesh cutting during bake, so I can get the above result to happen during bake, and then delete all the involved scripts on Play.

There’s a visible problem, though, and that’s that the stuff added by NavmeshAdd doesn’t hit the same areas. That’s due to them not overlapping exactly, and Pathfinding.Polygon.CompressMesh being very strict about when two vertices are the same one. I can handle this by making the entire mesh in blender, but I’d prefer to have the bits be a bit better at combining.
The top and bottom also doesn’t connect with the mesh there, as there’s no vertice overlap. So I think I’ll make a custom thing that deforms the mesh around the bridgehead, and then manually stiches the new meshes into the main mesh. Just jamming new TriangleMeshNodes into a Tile is pretty straight-forward, so I think I’ll be good to go.

This is what I like about this whole plugin; it’s very extendable, and for the most part the code is easy to understand when I really dig in there. And when the code’s a bit messy in places (TileHandler.CutPoly), you do say sorry in the comments :slight_smile:

1 Like

Ok. Fine… It is possible.
In fact I have used this in a game for a lot of things. We had levels that were pretty much constructed purely from NavmeshCut and NavmeshAdd components.
… However.
I cannot really recommend it. The reason is that you will end up with precision issues where vertices don’t line up perfectly and similar issues. It requires a lot of effort to keep that from happening. If it is working perfectly for you I suppose you can go ahead with it, but be wary of precision issues.