I seem to have no trouble using a sphere imported from Maya or Blender, even highly deformed. But it seems that my procedural sphere causes significant problems. It regularly fails, and when it doesn’t fail, I get results like this:
Clearly something about the geometry is causing this horrific path, any ideas what it is?
I am just wondering if it’s time to cut my losses and wait for a new version that addresses procedural spheres directly.
Just posting notes and thoughts.
I’m able to get a mesh from blender to break if it’s deformed too much. Thinking about large protrusions, as A* walks that, they behave almost like blackholes of nodes (compressed in the graph in a sphere). So I am now generating perfectly spherical geo with no bumps, but separate meshes for each level. The idea is that the controller will sample the path on the sphere but then raycast to the actual bumpy geometry. Then, adjust speed from last frame by the distance travelled in world space (not on grid). The idea being it will slow down as it goes up and down slopes because the spherical result won’t account for the normals of bumps and valleys. Going to get started on this and report back. Any thoughts on the above though would be helpful.
Hi
Hmm. I think the graph already does this, but can you make sure you have smooth normals everywhere on the mesh? Non-smooth normals might cause vertices to be duplicated and possibly break the navmesh.
Yes I have smooth normals, my algo welds and averages all face normals as the last part of it’s calculation.
Here’s where I’m at.
The proc gen now generates a color array that I use to set tags on an internal, perfectly smooth, spherical surface within the planet. The agents are going to navigate around on this; then use that navigation (position and direction) as inputs for a higher-level controller that is negotiating the obstacles, slopes, etc. up on the real, bumpy planet surface above.
Will continue to update the thread and report
Hey not bad:
So what you are seeing is the agent with a class that extends AIPath, which does all of the pathfinding calculations, then in it’s Finalize() method, sticks the transform down to the planet surface with a simple raycast. They move around avoiding tags that they cannot walk on perfectly, which just so happens to make them avoid walls and holes, and no more pathfinding errors anymore that were the result of the bumpy terrain.
I have some work to do now to fix rotation a bit, and I have to put the slopes back in, but I believe the latter will be easy, as I can just tag them accordingly and making them walkable will allow agents that can walk on the low ground and the high ground avoid the cliffs by using the sloped-tagged areas to access the others. Also need to do my speed adjustment because the actual slope attenuated speed needs to be based on the planet surface not the navmesh.
We’re getting super close.
It’s really weird that the slopes of your planet affect the pathfinding so much. It really shouldn’t if you are just deforming an icosphere… Maybe I could have a look at that mesh/scene?
I’m not deforming an icosphere, it’s marching cubes. There are dramatic areas of stretch and compression if viewed in normalized space. Sheer walls and valleys with even geometry, which algorithmically plays out as very distorted, as far as I understand the algo.
If the triangles are sufficiently distorted, it can cause suboptimal paths to be calculated. You can find a note about that here: Using navmeshes - A* Pathfinding Project
However, it didn’t look that distorted in your screenshot. But maybe it actually is if you zoom in?
