Issue with connection between multiple nav mesh areas.

[GoogleCodeExporter]

There appears to be a problem where recast detects an obstacle at the 
intersection of 4 neighbouring nav mesh areas. Please see the following forum 
thread with screen shot illustrating the issue.

http://www.esenthel.com/community/showthread.php?tid=4470

Original issue reported on code.google.com by fatcod...@gmail.com on 10 Nov 2011 at 9:01

[GoogleCodeExporter]

I'm not able to view the picture. Can you please post it here?

--mikko

Original comment by memono...@gmail.com on 10 Nov 2011 at 6:37

[GoogleCodeExporter]

This is the image.

Original comment by mart2...@gmail.com on 11 Nov 2011 at 2:37

Attachments:

• screen.png

[GoogleCodeExporter]

This is by design. See this blog post how you can fix it:
http://digestingduck.blogspot.com/2010/11/path-corridor-optimizations.html

Original comment by memono...@gmail.com on 11 Nov 2011 at 5:01

• Changed state: WontFix

[GoogleCodeExporter]

I had a look at that blog post, but I'm not sure if that is related. I've done 
some more experimenting and have broken the problem down further.

The problem has to do with the border between two separate nav meshes. Forget 
about pathfinding between them, even just a simple ray test will often fail 
when it clearly should not.

My game world is broken up into multiple nav meshes (it is too big for one 
large nav mesh). Performing a ray test from one nav mesh to another randomly 
fails at the border between them. Sometimes it will work and sometimes not.

Is this "by design" and expected behaviour?

Original comment by fatcod...@gmail.com on 23 Nov 2011 at 8:14

[GoogleCodeExporter]

Hi, 

Things should not randomly fail, but pathfinding results may have extra 
vertices at tile corners. Raycasts along the mesh should work just fine.

Does the raycast stop at the edge or does it fail? Does it consistently stop at 
the same edges?

Detour debug draw function (when properly implemented) displays correctly 
connected border edges as in white, and unconnected in black. Does your debug 
draw support this feature?

--mikko

Original comment by memono...@gmail.com on 23 Nov 2011 at 10:31

[GoogleCodeExporter]

Ray casts on the mesh within a single nav mesh work fine every time. The 
problem only occurs when performing a ray cast across the boundary (or edge) of 
two connected nav meshes.

The ray cast doesn't fail, it just stops at the edge. The pathfinder also runs 
into this problem as well. If I ask it for a path from one nav mesh to another 
connected nav mesh, the pathfinder will stop at the boundary between the two 
nav meshes, even though they are connected.

When I say that this happens randomly, what I mean is that it will work 
correctly at some places on the boundary, but fail at other places along the 
boundary. If the ray cast stops at a particular point on a boundary, it will 
always stop there, every time I try the ray cast. However if I the ray cast 
passes though at another point on the boundary, then it will always pass though 
at that point. Hope that makes sense.

I have tested this by performing a ray cast from a fixed position in one nav 
mesh to my mouse position over another nav mesh. I can then move the mouse 
around and watch as it fails (stops) at the boundary in some places, but passes 
though in other places. Sweeping the mouse so that the ray passes the full 
length of the boundary will cause it to always fail (stop on the boundary) at 
the same spots and always pass through at the same spots. However, these 
locations where it fails or passes are random. There is no pattern to them.

I'm using recast through the Esenthel game engine. It does provide debug 
drawing of the nav mesh, however it doesn't show the connected edges as you 
say. Obviously not implemented by the engine in the debug drawing. I have 
contacted the developer of the engine, but was told it is a recast issue?? I 
will point him to this thread and perhaps he can take a look at the debug 
drawing.

Original comment by rubasu...@gmail.com on 24 Nov 2011 at 6:16

[GoogleCodeExporter]

OK, we have finally found the issue. It has to do with setting the maximum 
climb value for the agents to zero. When this is set to zero, recast is unable 
to stich neighbouring nav meshes together correctly.

It would be great if recast could handle a maximum climb value of zero as you 
don't always (as in my situation now) want your agents to be able to climb up 
or step up steps. In my case I want to force my agents to stay on flat ground.

If it is not possible, can you recommend a minimum value to use that would 
allow recast to stich neighbour nav meshes, but still prevent the agents from 
climbing up anything.

Original comment by fatcod...@gmail.com on 30 Nov 2011 at 12:03

[GoogleCodeExporter]

Zero climb height is really nasty value. If you want to prevent your AI to 
climb on some objects, you should mark them completely impassable (rasterize 
them with certain areatype, i.e. the null type). Minimum climb value should be 
a bit more than what is allowed by the slope threshold. Something like this:

minClimb = cs * tan(slope) + ch;

Original comment by memono...@gmail.com on 30 Nov 2011 at 11:10