Remove experimental constrain_avoidance
from NavigationRegion2D
#90747
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.
Removes experimental
constrain_avoidance
feature fromNavigationRegion2D
.This was added in Godot 4.1 with the avoidance rework in an attempt to automate the placement of static avoidance obstacles around NavigationRegion2D.
This feature already had a strong experimental tag so removing it should not come unexpected for users. It clearly told everyone to not use or rely on it for a real project because a lot of its issues where already known back then.
experimental="When enabled, agents are known to get stuck on the navigation polygon corners and edges, especially at a high frame rate. Not recommended for use in production at this stage."
The reason why it was even added is, at that time it looked like some of the issues could be reasonably solved in the future and that the general userbase could manage the limitations better. Both did not happen.
There are multiple reasons why this experimental feature failed and / or why it should be removed.
Main reason, the feature never worked, it gets agents stuck on the navmesh edges easily.
Attempting to mitigate this would require adding edge margins. Basically to implement a custom version of navmesh baking just for this feature, not at all worth the effort.
Main reason, the feature never worked, navmesh outline order is just too brittle and unreliable.
Because the avoidance pushback was based on the (hand-drawn) navmesh outlines a single wrong interpreted outline caused the entire user world to break. Happened way to often on more complex navmeshes.
Even if the feature worked, it could only work with a single region.
Having more than just a single region is common for nearly all projects but the constrain made it impossible for agents to cross into other regions. So basically any more evolved project had to auto-stop using this feature and / or start to juggle avoidance layers which was horrendous.
Even if the feature worked, it had unscaleable bad performance.
The typical 2D navmesh in user projects is badly optimized and the feature added an obstacle point for every single navmesh vertex. This was just too much, a static avoidance obstacle edge is far more costly than a navmesh edge. Attempting to mitigate this would require adding an edge simplification just for this feature, again, not at all worth the effort.
Even if the feature worked, it only existed in 2D and only on a node with no actual server support.
It also created the wrong user expectations that navmesh and avoidance are connected and violated the separation of concerns between them.
Even if the feature worked, it makes the required refactors for the navmap and the avoidance spaces extra difficult because a region is stuck with both.
Even if the feature worked, it adds a lot of boilerplate code and properties on the NavigationRegion2D for a niche feature.