Contour simplifications error

[GoogleCodeExporter]

Contour following uses neighbours using 4 connected check. Combined with
the assumption that segments between two regions are always straight, this
can sometimes create holes in the contours. See screenshort.

This problem usually happens when there are one voxel holes and very small
radius (0 or 1).

This data will create the problem. 1,2=regions, # hole.

22211
22211
2##22
22222

Original issue reported on code.google.com by memono...@gmail.com on 12 Feb 2010 at 10:23

Attachments:

• contour_simplification_error.png

[GoogleCodeExporter]

I'm not sure if this is the same issue, because in your image the raw contours 
seem different. The case I've found is in the boundary between an area marked 
on the navmesh and the normal walkable area. The raw contours are the same, but 
they are simplified differently, resulting in holes at some places in the 
boundary. It doesn't occur very frequently.

This is currently giving me a bit of a headache, because I'm constraining the 
player to the navmesh to ensure bots will be able to reach him, so these holes 
appear to the player to be invisible collisions.

I'd appreciate it if you raised the priority on this issue a bit.

Thanks

Original comment by daniel.a...@gmail.com on 20 Jan 2011 at 2:58

Attachments:

• recast-bug-contours.png

[GoogleCodeExporter]

Hi,

Firstly, which version of Recast are you using? The case you describe should 
work just fine, but once upon a time the contour code would produce such errors.

I think it is not the same problem as described in the bug. Can you repro the 
bug in RecastDemo? If so can, you send me the level and the settings which 
cause it to happen? You can send the level directly to me at memon@inside.org

Are you using area types? I recommend using median filtering when you use area 
types:
http://digestingduck.blogspot.com/2010/07/recast-area-types-per-triangle.html

Original comment by memono...@gmail.com on 20 Jan 2011 at 7:09

[GoogleCodeExporter]

Hi,

I could reproduce it in the latest Recast.exe that's in SVN (that's where the 
screenshot came from, I don't have such nice visualizations :) ). That was 
committed in Revision 217, and the last revision for RecastContour.cpp was 212, 
so I guess the issue is still there. As for which specific revision I'm using 
for the game, it's 241.

Easiest way I can reproduce it is in dungeon.obj, you mark a convex area that 
is kind of circular, and then you start tweaking the cell size and eventually 
it will happen. In the screenshot I sent you, I reduced cell size to 0.26, but 
in my game I'm using 0.15.

In my game I'm only marking convex areas as well, not using triangle area 
types. Is median filtering necessary in that case?

Thanks for looking into this.

Original comment by daniel.a...@gmail.com on 20 Jan 2011 at 10:47

[GoogleCodeExporter]

Oh, forgot to mention, this is with the Tile Mesh sample with default settings 
apart from the change in cell size.

Original comment by daniel.a...@gmail.com on 20 Jan 2011 at 10:50

[GoogleCodeExporter]

Good that you can repro it. Can you help me out a bit more and press 1 key * in 
the demo after you have created an area which messes things up? That should 
save geomset.txt which contains the area. That would speed up my debugging a 
lot.

Filtering helps always when you are using areas. The aliasing is worst when 
using per input tri flags, but happens elsewhere too. In common case the border 
expansion phase acts as a sort of filter, so it is not necessary.

*) the key changed to 9 at some point, r217 should be still using 1.

Original comment by memono...@gmail.com on 20 Jan 2011 at 11:03

[GoogleCodeExporter]

Ok, there's the file.

I'm doing something similar to the border expansion with some of the areas, and 
I haven't seen the issue as much with those, now that you mention it. But I'm 
not doing that for the ones that are currently giving me trouble because they 
are added/removed from the navmesh more frequently so I wanted to keep their 
cost down.

Original comment by daniel.a...@gmail.com on 20 Jan 2011 at 11:25

Attachments:

• geomset.txt