Navigation On Walls, Ceiling

[Kim Watson]

Hi,

I have a general question regarding how you might approach generating navigation on walls, and ceilings. Our agents must be able to move freely from any plane (ground to ceiling  ceiling to wall, etc - with normal pathfinding abilities along these planes) . Is this concept completely incompatible with how the recast pipeline functions? I would really value your thoughts on what direction / if any exists - that I could take. 

I've considered an option (not sure how viable it is in reality, it's just shallow thinking at this stage). And more than anything probably reflects my lack of full insight, and understanding of the steps involved in deriving walkable surfaces from the voxels/triangles fed into recast. 

I've considered having 6 separate meshes (tile based), representing each plane (floor, four walls, ceiling). Transforming the input data so that it emulates being on the ground plane. And then transforming the final navigation mesh back to the correct transform. Obviously queries between individual meshes would be a minor issue. 

With the full insight you have into the constraints of your system, I would really value some direction. Anything I might further research / consider. Also, if you think my option to be unworkable - please let me know.

Thanks heaps for any time taken to respond. Also, this is my first post. So, just an expression of thanks - your contribution to AI development is great. I've learnt a great deal about navigation in the small amount of time I've worked with your system.

Kind Regards,

Kim

[Charles Prévot]

Hi,

I see a problem with your idea, if you have a 45 degree wall, depending on your max slope settings it will probably be excluded from x projection and from z projection also. But i think you would want it to be walkable.

Sorry I do not have more insight to give you as I don't know much about recast internals, good luck with this.

2012/11/6 Kim Watson <kimw...@gmail.com>

[Mikko Mononen]

Hi,

Recast is build with the assumption that the character is always
walking on ground affected by gravity. This has allowed to me to
simplify anything from the data structures for voxelization to some
queries on runtime. I think Climbing on walls is such a complicated
problem that it is outside the scope of Recast.

Then to the speculation for the sake of interesting problem :) The
first thing you should define for a navigation system is how the
character collides with the world. That in turn defines what kind of
tests you need to do to figure out walkable surfaces. For example
Recast assumes that the character is an upright cylinder. Recast finds
walkable areas by testing if such collider can be placed on top of
every surface. In practice this is very different, but that is the
core idea behind the voxelization, low area filtering and border
dilation.

Making the collider upright simplifies these tests a lot. If your
character is able to climb walls, maybe the collider should be places
aligned to the normal of the surface? This complicates the processing
quite a lot. The more complicated your collision model is the more
complicated the navigation data is.

Building a navmesh from arbitrary voxel surface is not trivial either.
It is more or less a polygon mesh simplification problem, with a huge
polymesh. Assuming gravity, or projection from one direction,
everything is so much simpler :)

On the other hand, of your character can climb any surface, is there
any need for navigation mesh at all?


--mikko

[johan]

I think you have the right idea since my transform i used from game engine to recast
requiered x z swap i just swapped my geometry
inputs x z vertice values and swapped my output from recast back again so its possible
in my way of imagining whats going on provided
you know on which navmesh you are and feeding your paths xyz values in and out based
on the plane of that navmesh aswell but i wont know if it will work ...best to answer is mico after all im just a user like yourself but in the quest for knowledge i answer out of curiosity