As part of my game logic I need to know if an agent has moved in:
A straight line
Around an object
To do this I planned to uses the calculated paths corner.length. My thinking was that if the path only has 2 corners then the agent has moved in a straight line. If there are more then 2 corners then it will have adjusted to move around an object.
…but on a flat surface with no obstacles, I can have 2, 3 or sometimes 4 corners.
I’ve plotted them and the agent only ever moves to the last corner.
“Also known as “waypoints”, the corners define the places along a path where it changes direction (ie, the path consists of a number of straight-line moves between corners).”
Has anyone else noticed this? or does anyone know another solution?
Hi hippocoder thanks for the reply
I’ve done a rebuild today using 2020.2.2f1 (the previous build was in 2020.1.0f1). First of all I thought that was it as the problem was greatly reduced, even with high tile density.
Then I adjusted the terrain and yeah then the problem surfaced again. Reducing the Tile density solved the problem.
But you should debug what you think is happening vs the data. Draw some gizmos or lines fo each corner point and also make it show up the blue navmesh overlay, then you can see the corners correlate with the navmesh topology.
I’ve done something similar.
I’ve written a methods to instantiate a sphere prefab, I loop the corners array from the path and make one sphere for each corner. Store them in a list, then destroy and clear the list with each new input.
Something I’ve noticed though and it must be a bug. If you calculate a path say from (1, 0, 1) to target (1,5,1). Then plot the corners in the path. Then all of the path will be plotted with a y value of 0.
How weird is that!!! it only works if the starting y value is 0 and the target point is greater then 0. To fix it I’ve had to raise the terrain by 1 on the y axis.
I am actually experiencing similar issue. I can’t really stadily reproduce it all the time though. Sometimes, the path is calculated correctly, just a straight line:
I wrote a script to export the generated navmesh into a .mesh file to get a better view of it, to check if there aren’t any holes or other geometry defects that I’m not seeing in the navmesh gizmo and that CalculatePath() tries to avoid, but the generated navmesh is perfectly solid.
Looks like a classic A* evaluation from those corners available to it. It looks like it’s functioning like it should. It doesn’t actually treat it like 3D space like you’re expecting, but corners on a grid.
It just so happens that it’s the agent’s responsibility to do something better with it’s path, such as taking corners more naturally at a natural distance, or walking to its destination if it doesn’t actually need to path find (you should do this to fix your issue) and so on.
The fact is Unity’s agent doesn’t have those capabilities. AAA games using recast (the navigation Unity uses) also experience the same results or similar but their agents would be vastly more capable.
You will probably get the most use with the least code by only using navigation where you actually need it and can’t just move there with regular code.
In the past I’ve also just disabled the agent but query it and apply my own velocity to my own object, and I’ve also more recently just not used the agent at all, but query the navmesh for corners to further process.
First of all, I forgot to mention I am not using NavMeshAgent, I implemented my own mover component and custom path class as I need dynamically change path corners on some occasions (custom local avoidance). I only use static method CalculatePath() to get corners.
Anyway, as far as I know (and I may be wrong), Unity’s navmesh uses funnel, or other similar algorithm to smooth paths and remove unnecessary corners. It actually seems to work this way if you look at the first screen I posted. If it was just standard A* evaluation, there would be corners snapped to every grid intersections/or navmesh edge connections, in path’s way. If you happened to use Astar Pathfinding Project, this is the behavior you could see with traversing navmeshes without any path smoothing modifier. With path smoothing algorithm, a path with just point A and B with no obstacle between them always results in straight line between start and end corner. And it seems to be working this way even with built-in navmesh system, but sometimes, it just doesn’t.
Edit:
I am, however, suspecting vertical changes to be the cause. If I traverse path only on the road (y=0), or only on the ground (y = -0.2), there usually aren’t any corners between start and end corner. If I try to traverse a path tha goes from road through ground to, say, sidewalk, it seems to pick closest grid point of the desired height every time it’s supposed to change along the path. But, again, not always, as shown in the pictures above.
Maybe I’ll try to put some meaningful report together tomorrow, might be worth of shot. Although the more I look at it, the more I get a feeling this is some kind of an intended behavior of the navmesh system, as I mentioned in the edit of my previous post, regarding navmesh height changes. And, knowing Unity, I don’t suppose there’s a possibility of having such feature exposed to be able to turn it off, so I’m probably gonna be better off trying to find a workaround… or a different system, which is something I wanted to avoid at all costs.
I also have the issue of what should be straight-line paths having extraneous corners.
Clicking around, I can reproduce issues navigating near (0,0,0). And when navigating near the corners of a modifier box (i.e. NavMeshBuildSourceShape.ModifierBox). In the box case the cost of the area inside and outside the box is identical so the path shouldn’t have been affected.
