Navmesh compatibility

[pietru2004]

When I generate terrain mesh is significantly slows scene saving so would there be possibility to make HTerrain node able to work with NavMesh? By work I mean could there be support for navmesh detecting of TerrainMesh or Terrain Collision.

I have building system and npcs and whenever player builds a new object NavMesh needs to be regenerated so npcs don't colide with placed objects.

[Calinou]

When I generate terrain mesh is significantly slows scene saving

You should save the terrain mesh to a separate .res file by clicking the resource dropdown arrow and choosing Save As…. This way, it won't be serialized as Base64 in a .tscn scene (which is what makes saving and loading it slow).

[pietru2004]

ok, but still would it be possible to generate Navmesh from HTerrain directly?

[MGilleronFJ]

Also you should not need to keep that mesh in the scene at all. When the navmesh is generated, you can get rid of the temporary mesh.
And no, Godot does not provide any means of generating this navmesh out of the heightmap directly. That's why the mesh tool exists. Eventually there could be some automation that creates the mesh, somehow generates the navmesh (API?) and cleans up afterward, but that might hinder control over the configuration/generation process (there is also usually more than just the terrain to account for in a navmesh)

[Calinou]

godotengine/godot#63932 may help address this issue (it was backported for 3.6 too).

[pietru2004]

guess this gona have to wait

[MGilleronFJ]

godotengine/godot#63932 may help address this issue (it was backported for 3.6 too).

There is some inconvenience with this PR: it requires the shape to be used in a CollisionShape node. This plugin uses servers directly. I believe Godot should stop doing that and query the physic server when it comes to generating navmeshes. This is one of the root reasons why such limitation exists in the first place (another example, GridMap and CSG nodes are still hardcoded in the navmesh generator, but they have nothing to do here IMO). And if that is not enough, there should be at least an API in the navigation server to register baker plugins providing the geometry, so that navigation won't have to hardcode all these things and any module or plugin will be able to support it.

[smix8]

If you already have you geometry data created with e.g. scripts or from a plugin you can create navigationmeshes from meshdata with the NavigationMeshGenerator singleton and upload it directly to the NavigationServer regions by using the API.

The reason why Godot stopped using the PhysicsServer or VisualServer directly for the navigationmesh geometry parsing is because both servers would stall when used with threads.

[Zylann]

I'm currently writing a proposal to customize NavigationMeshGenerator because I still believe it has unjustified dependencies. Surely being able to register custom providers is doable.

If you already have you geometry data created with e.g. scripts or from a plugin you can create navigationmeshes from meshdata with the NavigationMeshGenerator singleton and upload it directly to the NavigationServer regions by using the API.

That's the issue though, this plugin does not hold on to any geometry. It uses a completely different rendering approach. It's always better if it doesn't have to generate a full mesh, because it is huge. Such kind of geometry would only have to exist to be fed just once to the navigation generator, most often only in the editor when the user presses "Bake" in the navmesh generator. Is it possible to register that at this time? Because otherwise there are no nice times to do it (it is an expensive operation, and it is expected to have it occur when pressing Bake). Which is why I'm writing a proposal for an alternative.

The reason why Godot stopped using the PhysicsServer or VisualServer directly for the navigationmesh geometry parsing is because both servers would stall when used with threads.

That sounds like a design problem going on with physics server. And AFAIK it doesnt actually support proper threading (I opened another proposal which is however not mentionning navigation). But using nodes is not threaded anyways... still, I understood quickly that querying physics isn't always an option (might even be off), which is why I lean more towards a registration API to do this.