You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new thread guards added with the recent SceneTree thread groups from pr #75901 break the runtime baking of navigation meshes on a thread in debug builds.
The navigation mesh baking process first parses the child nodes recursive to gather source geometry for the baking. This process is now entirely blocked by the thread guards in debug builds. The guards make the SceneTree nodes inaccessible from threads. The navigation mesh baking process now suddenly has zero data to work with.
Workaround is to use NavigationRegion3D.bake_navigation_mesh(false) or use the NavigationMeshGenerator.bake() directly with the NavigationMesh or to do as suggested by the error msg and call deferred so everything is done single-threaded on the main thread.
This is not really a solution that works for a release cause having the navigation mesh baking forced to single-thread will cause unavoidable and heavy performance issues for projects that change navigation meshes at runtime.
Steps to reproduce
Try to bake a navigation mesh at runtime with a background thread in a debug build.
Minimal reproduction project
see steps
The text was updated successfully, but these errors were encountered:
Godot version
da21cb7
System information
Windows 10
Issue description
The new thread guards added with the recent SceneTree thread groups from pr #75901 break the runtime baking of navigation meshes on a thread in debug builds.
The navigation mesh baking process first parses the child nodes recursive to gather source geometry for the baking. This process is now entirely blocked by the thread guards in debug builds. The guards make the SceneTree nodes inaccessible from threads. The navigation mesh baking process now suddenly has zero data to work with.
Workaround is to use
NavigationRegion3D.bake_navigation_mesh(false)
or use theNavigationMeshGenerator.bake()
directly with the NavigationMesh or to do as suggested by the error msg and call deferred so everything is done single-threaded on the main thread.This is not really a solution that works for a release cause having the navigation mesh baking forced to single-thread will cause unavoidable and heavy performance issues for projects that change navigation meshes at runtime.
Steps to reproduce
Try to bake a navigation mesh at runtime with a background thread in a debug build.
Minimal reproduction project
see steps
The text was updated successfully, but these errors were encountered: