Hello,
I am currently researching to see if this tool will fit my use case, which is a 2D roguelike top-down shooter game with 3D physics component (i.e., 3D Rigidbody/Collider). The reason why I use 3D physics instead of 2D is because 3D physics has more functionalities than 2D in Unity (e.g., RaycastCommand for job system).
Currently I am using Unity’s built-in system to generate Navmesh dynamically along XY plane (rotation set to -90, 0, 0). However the API is very limited and it doesn’t even have an async function for generation path from the NavMesh.
I know A* pathfinding project pro 5.0 has Recast graph generation on 2D game (XY plane with 2D physics components), but I can’t find anywhere that says it allows you to rotate the generation plane to XY plane (i.e., up vector is (0, 0, -1)) but still uses 3D physics components.
Can you confirm that it’s possible for this purpose?
Thank you!
–
I replied to this post originally (A* in 2D open world - #4 by aron_granberg) since the latest reply seems to fit my topic.
But then I realize it doesn’t really fit the title of the OP, so i made a new topic now.
Okay, I tested it and it’s doable.
But for some reasons, sometimes some tiles are not being generated with navmesh when using Recast scan. I am not really sure why.
Like entire tiles just don’t generate? Can you post a screenshot of that? Also your graph settings if you can 
Yes, some tiles are just empty, without any nodes.
However, I can’t reproduce the exact issue again, but while I was trying to reproduce, this happened:
And here are the settings:
I am on version 5.2.5.
–
On a different topic, i noticed the code in Path.Reset()
allocates a lot of heap memory if used extensively.
I fixed it myself for now by adding a reset function to reset the constraint to the default value like this instead of creating a new walkable default constraint instance every time (PathNNConstraint.Walkable
):
public void ResetToWalkableDefault()
{
if (s_DefaultWalkableInstance == null)
{
s_DefaultWalkableInstance = Walkable;
}
graphMask = s_DefaultWalkableInstance.graphMask;
constrainArea = s_DefaultWalkableInstance.constrainArea;
area = s_DefaultWalkableInstance.area;
distanceMetric = s_DefaultWalkableInstance.distanceMetric;
constrainWalkability = s_DefaultWalkableInstance.constrainWalkability;
walkable = s_DefaultWalkableInstance.walkable;
distanceXZ = s_DefaultWalkableInstance.distanceXZ;
constrainTags = s_DefaultWalkableInstance.constrainTags;
tags = s_DefaultWalkableInstance.tags;
constrainDistance = s_DefaultWalkableInstance.constrainDistance;
}
Not sure if this is fixed in the newer version, I’d have to ask our other programmer to upgrade it to see since they were the one who bought the package originally.
I would recommend having a slightly higher max slope than 0. That might make some surface unwalkable just because they have a tiiiiny slope (or just floating point errors).
Ahhh thanks. That actually fixed it.
Changing the max slope angle to 0.1 fixes the entirely missing tile issue in the screenshot I posted above.
And changing the max step height to 0.01 resolves the weird artifact as well.
So that was definitely due to floating point error.
1 Like