Sometimes the position that my agents are pathfinding to can be unreachable, which results in a very long process time (to my assumptions, because its trying every single possible combination on the navigation mesh to try and find a path to that position)
i’ve been trying to optimize the 3D navigation as much as i could for a large world + lots of simple logic navagents, i have a global singleton node to handle assignment of all the agent’s target_position, one (or more, depending on the amount of agents instantiated) agent per frame. I have decided to split my world geometry into chunks because that would optimize raycasts that i use and i hoped perhaps if i use multiple smaller navigation regions than one large region it would do some magic behind the scenes for unreachable target_positions, however it didn’t. To deal with this what i’ve done is when there is a target_position that is unreachable, throttle the rate of target_position updates and have only one agent try to find a path once like every .5 seconds, and when it does, it assumes that the new target_position is now reachable and switches back to its nominal update rate, that did improve the perfomance but even when a single agent is trying out all the paths even at a lower update rate it still creates a visible lag spike. So the question stands, is there a way to forcefully cancel searching for a path to the target_position if it took more than some set amount of attempts? Or, perhaps, set a max limit to the count of navigation regions that the agent is trying out, so it will always try to find a path that uses less than, for example, 8 navigation regions.
So the question stands, is there a way to forcefully cancel searching for a path to the target_position if it took more than some set amount of attempts? Or, perhaps, set a max limit to the count of navigation regions that the agent is trying out, so it will always try to find a path that uses less than, for example, 8 navigation regions.
No, there isn’t right now. Experiencing such a performance hits on a single query hints at a more serious map layout problem with just way too many polygons. You can see the actual number in the debug navigation monitor. Performance problems from a polygon excess can be hidden a long time behind the astar early-exit when it finds a path but hits full force the moment it can’t do that.
i don’t really need those polys on the roofs of the buildings, because agents will never be able to get on top of one, it would optimize the pathfinding if i rid of those roof polys, but if the player happens to be mid air right above that building, the target_position would be unreachable which would mean a higher chance of getting unreachable target_position lag spikes ¯_(ツ)_/¯
what if i had a navigation agent in each one of the navigation regions, limited by navigation only inside that one navigation region only? when assigning target_position of my pathfinding enemies i would first prompt the agent inside that navigation region the player is currently in, and since its only using that one navigation region to find paths it will take substantionally less time to see if the target is reachable or not, and if its is, then its all good and pathfinding happens, but if its not then it doesnt? for reference: here i’ve marked one of the unreachable-by-agent areas ive discovered
For the unreachable navmesh that you do not want/need you can either block the parts that you dont want navmesh to appear by adding dummy bake geometry or use a NavigationObstacle3D with vertices and affect_navigation_mesh=true and avoidance_enabled=false and bake it with the navmesh. The obstacle will discard any navmesh inside its vertices defined shape.
