I’m trying to get a Character to move to a goal actor on a navmesh, using the MoveToActor function in AIController to move the character. At the start and end of the character’s movement, the character moves to the side, when I expected the character to take a straight path. Depending on the position of the two actors, it sometimes even goes behind the goal actor.
I’ve also tried using just a Pawn with UFloatingPawnMovement, rather than a full Character, and got the same results. I think I must have something set up wrong with my navmesh, but I’m not sure what the problem could be. I’ve tried changing some of the settings (like the tile size) in Project Settings → Navigation Mesh, but haven’t had any success there. Any ideas on what I’ve done wrong?
Going behind can be explained by the AI not being able to reach it’s destination, therefore does a little circle around it. Yes, it should also be able to reach going straight if it can by going around it but because it foresees that it cannot, it starts traversing around while getting closer and at some point it passes the nav mesh bound due to it keeping it’s existing velocity, making it reach the acceptable radius. This can be fixed by either decreasing the cell size from the details window that opens when your recast nav mesh is selected, or increasing the acceptable radius of your Move To Actor function.
About the off movement at the start, the only thing I can think of is the pathfinding algorithm detecting a shorter path and doing a little detour. It seems illogical upon observing your GIF, but maybe there’s something we’re missing. Maybe try placing the AI on different parts of the map.
To provide some guidance on your debugging process, you can project it’s navigation via the function to get some clues on what’s happening (also open the AI debugger during runtime), you can try using the Move To Location function instead and plug the target actor’s location into the destination pin, and you can try doing this exact experiment in a completely flat surface.
Thanks for the tips! I’ve tried increasing the acceptance radius and using MoveToLocation, and it’s still moving off to the side of the target. I’ll do some more debugging using your other suggestions and see if I can make some progress
Good call, this was the issue with the movement at the start. The sphere that I put on the character had CanEverAffectNavigation set to true. I didn’t think it would be an issue since I wanted characters moving around to avoid each other, but after digging into it more, I should be using avoidance algorithms for that rather than having characters affect the nav mesh. Thanks!
Still having issues with this, hoping for some more help. I switched from using MoveToActor to using MoveToLocation (all default parameters) with a point that should be on the navmesh. It’s still taking the wrong path around obstacles for some positions.
With the destination to the left of the obstacle, I would expect the pawn to move to the left side as well, but it goes around the long way to the right.
Here’s a top-down view of the visual logger’s output, showing the path that was calculated
I think its just how the Recast graph handles pathfinding - in large open areas the path is not always the shortest path because I think it goes by the polygon centre, not the edges (something like that). If you put an Actor near the path so that the large open area is broken up I bet it would generate a shorter path.
A navigation mesh is a (deliberately) crude approximation to your actual geometry (crude approximation => smaller graph => faster pathfinding). When you request a path it determines the polygons the start and end locations are on, and does an A* from one to the other, in your case that is the blue lines I have drawn here,
The red line is where you actually wanted the path to go (after the first step) to get the actual best path for you actual geometry, but as you can see this is not the shortest path on the graph that is being searched.
From there, it has a ‘channel’ (defined by the edges the blue line crosses) which it runs a ‘string pulling algorithm’ on to give you the path it did.
Hard to fix well, smaller polygons may help but can lead to more problems and the big polygons are generally considered good (again, it gives you a smaller graph). Polygonal shape adjustments might also help, to create a more interconnected graph (but again… graph size, and also I think UE’s implementation only supports quads). Most importantly though, whatever tweaks you make to get it to generate the path you want here will lead to it generating bad paths for other origin/destination pairs.
If you need perfect shortest paths, navigation meshes are not the solution.
@silnarm any suggestions? I need perfect shortest paths with natural feel a la Baldur’s Gate 3. Unity has the A* pathfinding project but Fab doesn’t have anything.
(I think its not off topic as I found the post due to the same issue as the poster)
I don’t know of any plugins that may provide this sorry, but I have had very good results using a kind of Visibility Graph (all my code, and the geometry I am path-finding on is not run of the mill, so would be of no use to anyone else even if I were willing to share it).
The graph required is highly interconnected and not small, so it may well have performance issues on large levels or with lots of requests. But maybe worth looking into if you are comfortable rolling your own (in C++).
(and yes, perfectly on-topic and this thread may have been a bit old but was unresolved, so no issue with your bump!)
