koobas.hobune.stream
Navmesh Pathing: Is there any way to loosen the path?
So i'm working on a physical pathing system that layers ontop of unity's. And i'm noticing some odd results, which ive traced to the fact that the paths are absurdly tight. They wrap around obstacles right to the edge as if expecting my character to be a robot on rails.
However it is not, it's a physical being which moves with forces, and like any such thing, it can't simply change direction on a dime, that's deliberate. This is causing some odd behaviour on tight corners (especially hairpin turns) where after skidding out to the side, my character doesn't proceed straight onwards down the path, but first doubles back to the edge of the hairpin to hit the path corner.
The best solution to this i feel, would be a better path. One that takes corners with a sufficient amount of leeway (adjustable presumably).
How can i loosen up the path and make it not hug corners so tightly?
I can't help you directly, but I know that the Astar Pathfinding Proejct, available on the Asset Store for free, has such a feture, I think it's called Path $$anonymous$$odifiers. It can make a patch not go too close to walls and make nice smooth curves ins$$anonymous$$d of sharp turns. You could doanload it and take a look at the code. There's also an extended API on Aron Granberg's APP website.
Could you use a waypoint system and loosen the movement on that?
You could try increasing the Agent Radius property.This property controls how close to walls the nav mesh exists.
i was really hoping to not have to delve into external systems. I'll take a look at A*
Increasing the agent radius is a hack which has knock-on effects on other things, i'd rather not.
The solution i've eventually opted for is a rather obtuse coded solution, whereby if the angle to the next pathnode is small enough, and we're close enough to the current one, then i abandon the current and move to next.
I attempted to find Nav$$anonymous$$eshObstacle radii that allowed tight fits but then plan at a larger radii, shrinking each radius down to its predesignated value when no path is found at the larger radii:
float[] radiusParams;
float[] radiusGrowthFactors = { 1.5f, 1.1f, 1.0f, 0.9f };
private void CalcPath (Transform start, Transform end)
{
// get starting radius params
radiusParams = new float[nav$$anonymous$$eshObstacles.Length];
for (int j = 0; j < nav$$anonymous$$eshObstacles.Length; j++) { // set radius for each obstacle
radiusParams [j] = nav$$anonymous$$eshObstacles [j].radius;
}
// iteratively try to find paths from larger obstacle expansions to smaller ones
foreach (float radiusGrowthFactor in radiusGrowthFactors) {
Debug.Log("Pathfinding with radius growth factor of " + radiusGrowthFactor);
for (int i = 0; i < nav$$anonymous$$eshObstacles.Length; i++) { // set radius for each obstacle
nav$$anonymous$$eshObstacles [i].radius = radiusParams [i] * radiusGrowthFactor;
}
// try finding a path
UnityEngine.AI.Nav$$anonymous$$esh.CalculatePath (start.position, end.position, UnityEngine.AI.Nav$$anonymous$$esh.AllAreas, path);
// if path was found, break
if (path.status == UnityEngine.AI.Nav$$anonymous$$eshPathStatus.PathComplete) {
Debug.Log("Path found with radius factor: " + radiusGrowthFactor);
break;
}
}
// reset obstacle radii
for (int i = 0; i < nav$$anonymous$$eshObstacles.Length; i++) { // set radius for each obstacle
nav$$anonymous$$eshObstacles [i].radius = radiusParams [i];
}
}
There are some variables initialized elsewhere. Feel free to ask for more info.
Unfortunately, in the actual pathfinding results, it seems that the different radii are never used in pathfinding. The results seem to only reflect the predeter$$anonymous$$ed radii.
$$anonymous$$y guess is that the radii changes take too long to get carved (or maybe carving isn't even triggered by a radius change). If someone can figure out how to force immediate carving, I think we'd have a solution, albeit one that may not be computational efficient enough for all use cases.
