NavigationMesh creates nav mesh from bodies qued to be freed (when group-with-chilren option is selected)

[RonYanDaik]

Tested versions

• 4.3

System information

• win 10

Issue description

When you queue free a level that has geometry, and instantiate new one, call bake_nav_mesh, the nav mesh will bake new mesh using geometry from nodes that were marked to be deleted. Calling it with "call_deferred" also does not help. you have to wait more then couple of frames to rebake it again properly (probably one physical frame tick instead of main frame tick). Group_With_Children needs to be selected.

https://github.com/user-attachments/assets/8e16de1d-2233-4e0a-9393-cfb7ca94482a

Steps to reproduce

See attached project.

• Set nav mesh baking to group wtih children
• Queue Free a node that contributes to baking
• Instantiate new one and call rebaking of navmesh
• try to call rebaking in call_deferred (should be same result)

Minimal reproduction project (MRP)

navigation.zip

[AThousandShips]

The part about call_deferred is documented here:

Note: The node will only be freed after all other deferred calls are finished. Using this method is not always the same as calling Object.free through Object.call_deferred.

[AThousandShips]

I'd say this is to be expected, queue_freed nodes are still there, if you want to make sure they don't affect anything you should also remove them from the tree, I don't think we should add additional checks to the navigation code to exclude nodes that are waiting to be freed

[smix8]

I am not sure what even creates the assumption that there could be an update link between nodes and something that bakes things based on parse geometry, does not matter if it is navmesh baking, lightmap baking, particle baking, xyz baking.

The navmesh baking is indifferent what the origin of the geometry data is that is used by the baking. It does not even acknowledge the existence of something like a Node or a SceneTree.