How to generate seamless tiled navmeshes

[jankrassnigg]

I'm currently trying to build a system where my engine dynamically builds the navmesh for the areas that are needed.
Basically it just splits the world into chunks and generates the navmesh for each chunk on demand and then is supposed to use dtNavMesh::addTile to add that area.

As far as I've seen from the code, dtNavMesh::addTile somehow tries to link neighboring tiles, and I guess it looks at shared edges.

I haven't gotten that far, but I'm pretty sure what I'm doing won't work, because my results look like this:

At sector boundaries the polyongs have a significant gap. I wouldn't expect this to magically work. One reason this gap appears is because of rcErodeWalkableArea, which obviously makes the mesh smaller in all directions, but even without it, I don't get perfectly aligned edges (also in general the mesh becomes useless).

So what is the expected solution to this ? I could maybe generate the meshes with an expanded border region and then cut it down to the bounding box myself afterwards, in hopes that dtNavMesh::addTile will then be able to stitch together the shared edges?

I've also run into dtTileCache which seems to be related, but I don't know how yet. Any pointers how to achieve this would be very much appreciated.

[Srekel]

This is definitely related to what I want to do relatively soon, so would appreciate hearing about anything you learn.

[grahamboree]

I also agree we should have much simpler examples for common situations like this. The demo is code trying to do a lot at once and is not that easy to follow. I'd love to have "Quickstart" docs and maybe a few smaller more focused example programs alongside RecastDemo.

[Srekel]

That would be great :) I'm still working on making my Zig bindings auto-generate properly so it may takes some time until I get to it.

[grahamboree]

Out of curiosity, how are you generating those bindings? Recast is pretty C++-focused and doesn't have an official C API (this is on our roadmap). Are you writing your own C-API to generate bindings to?

[Srekel]

Good question 😅 I'm using a library called c2z that via clang AST generation allows for some C++isms to be translated to zig. It's WIP so I'm submitting PRs in my process of making the Recast headers ziggified. I haven't gotten very far, but Recast.h and RecastAssert.h seem to translate/transpile correctly now. I'm now at RecastAlloc and failing on the overload usage. I might need to make some changes to Recast to make it compatible with zig, which would inevitably make my repo and the original Recast repo start to differ, which would be unfortunate. Would anyone on the Recast team be willing to chat about finding some middle ground - I would be happy to provide some PRs to make Recast a little bit more binding-friendly.

You can see the bindings in the Recast/include folder, see Recast.zig and Recast_glue.cpp

[grahamboree]

Neat! In general I'm very much in favor of making an official C api. We've also considered porting the entire thing to C since it's not really using a ton of C++isms already. Sounds like the work you're doing could be a good starting point for the API at least. Happy to help with that if you'd like.