Suggested method for Initializing a multi-child Scene

[deya-0x]

First, thankyou for the awesome work on this so far.

In my scene I have a root node that has several children that form up my world geometry. At the moment the DetourNavigation.initialize function only accepts a single MeshInstance. But, of course my scene is made up of multiple MeshInstances and I cannot find a way to pass more than one. I have tried to merge the MeshInstances before passing in but I am running into trouble with capturing all the data. So I decided maybe I am going about this wrong and wanted to reach out and see if you have suggestions on how to proceed.

Here is what my scene tree looks like:

Here is the current output for my scene debug using the MeshInstance merge method, you can see the corners I am having trouble merging the MeshInstances as it is missing the data:

Now when I only pass in the first MeshInstance to the Initialize function I get a proper navmesh:

Ideally I would like to avoid trying to merge my MeshInstances, so I wanted to check with you if there is a better way to go about this so I can generate a navmesh for all children of my scene?

Should I actually create a new DetourNavigation instance for each child?

Thankyou for any information you can give!

[deya-0x]

I managed to fix my MeshInstance merging issue.

Along with that I have been working on a C# wrapper for your library.

[TheSHEEEP]

Out of interest: How did you fix your mesh merging issues?

Since I know I'll need this for my own project at some point, I had some plans for this: A) Using CSG, as CSG can not only create its own simple meshes (boxes, spheres, etc.) but also take done meshes as input. Godot's CSG is unfortunately somewhat error prone, though, so I'm not totally convinced that would work.

B) Finding a method to merge MeshInstances at runtime - hopefully there is a module, library, etc.

C) Changing godotdetour so it accepts an array of MeshInstances. Sounds simple at first since it basically only converts MeshInstance to arrays of indices and vertices, but if that was done for multiple meshes, I'd expect some errors where those meshes intersect - afaik, recast expects meshes passed on to it to be "clean" of intersections (e.g. one mesh passing right through another) or else it would create navigation that intersects as well. Not 100% sure of this, though, as I didn't try yet.

Hoping that A or B would end up working, because C sure sounds like a lot of potential work.

Creating multiple DetourNavigation instances sounds possible, but also like serious overkill (each one would have its own thread, etc.) and you would have to manually "connect" them with custom logic so agents could walk between them - similar to meshes that are not physically connected but need agents walking between them anyway and portals won't cut it in all cases.

C# wrapper sounds good. I know I won't have the time to work on that, so if someone else would, that would be very :ok_hand:

[deya-0x]

So far this is working, but it is not fully tested, I am almost expecting some issues in the future but will tackle those as they come. This is just a snippet of my merge code to take a look at. I will clean things up here soon.

Gist: https://gist.github.com/d3is/6bddc5b88570366cbf23afaf191577e2

This was inspired by https://github.com/lawnjelly/godot-splerger but modified to support multiple surfaces.

[TheSHEEEP]

Ah, well, good to know there are already some modules and libraries that try and tackle this problem.

If one of them turns out to work reliably, I might either include them or point people to them in the readme/demo.

[deya-0x]

Went ahead and forked the repo to add in some changes to help me along. My C++ is not great so be wary, hah.

[MJacred]

Mesh merging might come with Godot 3.5, see https://github.com/godotengine/godot/pull/57661

afaik, recast expects meshes passed on to it to be "clean" of intersections (e.g. one mesh passing right through another) or else it would create navigation that intersects as well. Not 100% sure of this, though, as I didn't try yet.

from what I saw, recast can handle that, see examples at bottom of this: https://9631ec60-a-62cb3a1a-s-sites.googlegroups.com/site/recastnavigation/MikkoMononen_RecastSlides.pdf

[lawnjelly]

Mesh merging might come with Godot 3.5, see godotengine/godot#57661

Note that the mesh merging purposefully doesn't do any cleanup.

I have some code to do the kind of cleanup that I expect the "clean" mesh refers to (things like de-duplicating verts if they are close enough, it also can do mesh simplification like LODs), but for the greatest flexibility I'm thinking this should be in a separate function from the mesh merging, even though it might be slightly less efficient not doing both at the same time.

Getting this stuff into core is slow politically, as things like processing meshes can be seen as "fringe cases". I managed to sneak the mesh merging in as part of the huge Portals PR so no one noticed hehe. :grin:

I'll see if we can get the above PR looked at in a PR meeting, as it is clear a lot of people would be interested in this.

[MJacred]

for the greatest flexibility I'm thinking this should be in a separate function from the mesh merging

In times like that, splitting into separate function and also one bigger function that does it all, quicker. Code duplication is a possibility - if rarely/carefully used

Getting this stuff into core is slow politically, as things like processing meshes can be seen as "fringe cases". I managed to sneak the mesh merging in as part of the huge Portals PR so no one noticed hehe. :grin:

Sweet that you managed :smile:
There are several other use cases, like character creators. Actually, any kind of tool/functionality using modular meshes, be it for assets or sth. like (dual graph) grid systems. Those tools can reduce a humongous amount of work. But… yeah, there are drawbacks, which can be fixed/elevated using mesh merging. So I'm definitely all for pursuing this matter further

Thank you for your great work!