Expose navmesh bake function to scripting

[Zireael07]

Godot version:
3.1. alpha 1

OS/device including version:
Win 7 x64

Issue description:
Please expose navmesh baking to scripting. It would be immensely useful for procedural maps.

Steps to reproduce:
N/A

Minimal reproduction project:

[TheSHEEEP]

I was about to suggest the same. Good that it already exists!
I really hope that 3.2 will get the absolutely necessary navigation overhaul as planned. At the moment, navigation in 3D projects with procedural generation of almost any kind that is downright impossible with Godot. Or would require extreme workarounds to the point of rolling your own navigation.

If we could just give any mesh at runtime to a function, and receive a navmesh fitting that mesh as a result, things would look brighter.

[dodacode]

This issue is more than a year old but is not marked for any upcoming release version nor was it closed. Is there anything I am missing or did this just go unnoticed?

[ScyDev]

The PR referenced above sounds like it would solve this.

[dodacode]

@ScyDev As I understand this it is only for gridmaps and neither at runtime? I made a quick hacky test yesterday, which creates a navmesh from a CSG plane with holes in it (subtracted CSG cubes) at runtime (shown in image). But this is still would not replace the "Bake NavMesh" function needed for runtime.

The usecase is e.g. having a plane ground with baked navmesh, then the user places a rock onto the ground and the navmesh needs an update due to the new obstacle...

[ScyDev]

@FrischerHering If you succeeded in updating a NavMesh at runtime (in 3D space or only on a plane?) I'd like very much to see how you did it :) Back when I commented on this issue, I couldn't do it and couldn't find a solution online, only people with the same problem, as in this issue.

Being able to bake the NavMesh from script at runtime would seem to be an elegant solution, since all the necessary code already exists.
However, if a NavMesh can be edited at runtime now, then exposing the baking function would not be strictly necessary, but still probably much more elegant and user friendly than handling vertex arrays manually.

And yes, that is exactly the use case that I have, new or dynamic obstacles that need to be respected in pathfinding.

[dodacode]

@ScyDev Important to note that it is a solution, but not a good solution! I basically used CSG meshes to form what the navmesh should look like. Then, using get_meshes() doc you can retrieve all the faces that are generated from the combining of CSG meshes (called on the root mesh). Ultimately, just use set_vertices() and add_polygon() on a navmesh doc.

The problem here is, that the navmesh is overcomplicated (many and mostly unnecessary edges). Despite that fact, navmeshes in Godot (at least the 3d ones) are entirely unusable, because pathfinding is simply broken. I could post lots of calculated paths, that are simply wrong. E.g. instead of a straight line the generated path is a 6+ waypoints curve... I concluded, that even if this is a dynamic navmesh solution, I would rather stick to A* and try to workaround navmeshes completely...

As some side facts, the mesh in the image above is a CSG plane with around 10 CSG cubes subtracting and creating the holes. The navmesh creation from CSG took 2ms and pathfinding is 0.2ms on average.

[ScyDev]

@FrischerHering Can't comment on that as I don't really understand it that well.

I can say that on manually arranged geometry and manually baked NavMesh it seemed to work well for me. Just had no way to update it at runtime.

[dodacode]

@ScyDev I think that for flat grounds navmeshes work pretty well, as they do in 2D. As already mentioned, my method of creating navmeshes in runtime is both overcomplicated and faulty. Exposing the baking tool to runtime and script still sounds like an easy adjustment for the engine.

To add to the feature proposal, it should be up to the developer on how to deal with the time the baking takes. I.e. the engine should not try to run its own baking thread or anything like that.

[Dwahgon]

I will be attempting to expose the function.
#29118 made things a bit easier by exposing the EditorNavigationMeshGenerator, but trying to call bake() in-game will result in a crash.

[Dwahgon]

4.0 already allows in-game navmesh baking. I guess this issue can be closed now?

[TheSHEEEP]

I'd also say so.
Also, just FYI, I created a navigation GDNative module for 3.2 a bit ago which also allows baking at runtime - well, it actually only supports it at runtime ;) :
https://github.com/TheSHEEEP/godotdetour

[Calinou]

Closing, as this was implemented by #34776.

[tylerecouture]

@ScyDev Important to note that it is a solution, but not a good solution! I basically used CSG meshes to form what the navmesh should look like. Then, using get_meshes() doc you can retrieve all the faces that are generated from the combining of CSG meshes (called on the root mesh). Ultimately, just use set_vertices() and add_polygon() on a navmesh doc.

The problem here is, that the navmesh is overcomplicated (many and mostly unnecessary edges). Despite that fact, navmeshes in Godot (at least the 3d ones) are entirely unusable, because pathfinding is simply broken. I could post lots of calculated paths, that are simply wrong. E.g. instead of a straight line the generated path is a 6+ waypoints curve... I concluded, that even if this is a dynamic navmesh solution, I would rather stick to A* and try to workaround navmeshes completely...

As some side facts, the mesh in the image above is a CSG plane with around 10 CSG cubes subtracting and creating the holes. The navmesh creation from CSG took 2ms and pathfinding is 0.2ms on average.

@dodafish Would you mind explaining how you got your CSGPlane's mesh into the navmesh? The docs are all empty so I'm not sure how to set/replace the navmesh of a NavMeshInstance.

What do I do with the mesh: var new_mesh = $CSGMesh.get_meshes()[1] once I have it? I can't figure out how to set_vertices() or add_polygon() as you suggest to try.

This is all I could come up with:

var nmi = $Navigation/NavigationMeshInstance
var navmesh = nmi.get_navigation_mesh()
navmesh.create_from_mesh(new_mesh)
nmi.set_navigation_mesh(navmesh)

But no luck with that...

Thanks for any (more) insight you can provide.