Navigation mesh baking needs to warn that visual Meshes are bad for runtime performance

[smix8]

Tested versions

4.3dev

System information

Windows 10

Issue description

Parsing source geometry from rendering meshes for the navigation mesh baking is a significant performance hazard.

What is ok for easy setup and performs ok inside the Editor makes runtime (re)baking of navigation meshes basically impossible without frame rate issues.

The issue with visual meshes is that their geometry data needs to be received from the GPU which blocks the rendering every time the parsing needs to read the mesh arrays.

Most users are not aware that the majority of their runtime (re)bake performance issues are caused by this (and nodes) and expect just the entire navigation mesh baking process to be the issue.

The navigation mesh baking should print a performance warning when at runtime a MeshInstance2D/3D, MultiMeshInstance2D/3D, GridMap mesh or CSG mesh, or any Mesh really, ... gets parsed by the navigation mesh baking process or added to a NavigationSourceGeometryData object.

The warning also should inform users to switch the parsing to use collision shapes as they do not have the same issues as rendering meshes and are far better optimized for their role as source geometry.

Ideally the default geometry parsing would also be switched to collision instead of parsing visual meshes but since Godot does not store defaults this would break existing projects.

Steps to reproduce

Bake navigation meshes with visual meshes as source geometry at runtime. Expect significant performance issues.

Minimal reproduction project (MRP)

N/A