Warn that navigation mesh baking from Meshes is bad for runtime performance #90921
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds a one-time warning when a visual Mesh is added to the source geometry at runtime to make users more aware about this problem.
Resolves #90607
At runtime this poses a significant performance issues as visual meshes store geometry data on the GPU and transferring this data back to the CPU blocks the rendering.
So baking navigation mesh when parsing from e.g. MeshInstance3D or MultiMeshInstance3D nodes is really only viable inside the Editor where frame rate is less of an issue.
For runtime (re)baking navigation meshes use and parse collision shapes as source geometry or create geometry data procedural in scripts.