Robmaister / SharpNav

Advanced Pathfinding for C#
sharpnav.com
Other
534 stars 165 forks source link

Not all area is covered with generated navmesh #41

Closed AqlaSolutions closed 8 years ago

AqlaSolutions commented 8 years ago

I tried to adjust parameters but this is the best I've got: 111

Can you please look at the model? https://www.dropbox.com/s/49drj4kjjrz6e43/nav_saga_problem.obj?dl=1

Robmaister commented 8 years ago

I've received a few emails about this kind of bug. This one appears to be the worst of all possible cases. I'll have to step through the PolyMesh and PolyMeshDetail code a few more times to pinpoint the bug that's causing this.

AqlaSolutions commented 8 years ago

@Robmaister, hi again, do you have any thought at which date this issue is going to be closed? this bug is really critical for us.

Robmaister commented 8 years ago

I'm currently working 2 jobs and trying to be a student at the same time, so I don't really have a lot of bandwidth for this right now. I can try taking a look at it this weekend, but this has been a long-standing bug in arguably the most complex part of SharpNav algorithm-wise, so I can't really promise anything.

Tweaking the generation settings and ignoring the detail mesh will probably get you a result that's good enough for now.

AqlaSolutions commented 8 years ago

@Robmaister, ok.

ignoring the detail mesh will probably get you a result that's good enough for now

do you mean that the detail mesh is not actually used in calculations and only displayed in the viewer app? or do we need to pass some specific settings for navmesh generation so it will not use the detail mesh?

AqlaSolutions commented 8 years ago

@Robmaister I finally found a time and updated us to the latest version. It's much better now but still have some not covered area. 2015-09-01_1855

I tried to tweak settings but even when I make it disappear (with erode radius usually) it appears in another place.

Robmaister commented 8 years ago

If you switch to the Polygon Mesh view, do those holes go away? I should have some time towards the end of this week to debug or replace the Delaunay triangulation code.

If the holes go away when you switch views, are you still able to find paths through the areas with holes?

AqlaSolutions commented 8 years ago

@Robmaister no, they don't go away

AqlaSolutions commented 8 years ago

@Robmaister I realized that when I select the view "NavMesh" it has more holes than showed in PolyMeshDetail. However agents are able to navigate through them IF these holes are not visible in PolyMeshDetail mode.

Robmaister commented 8 years ago

Huh, that's interesting. There's probably a small rendering bug somewhere then. And a bug in PolyMesh. Thanks for being patient about this :)

AqlaSolutions commented 8 years ago

@Robmaister sorry for disturbing you again, I just want to bump this in case you have a time to " to debug or replace the Delaunay triangulation code.".

AqlaSolutions commented 8 years ago

ping?

Robmaister commented 8 years ago

Thanks for the reminder, I'll look into this particular map today

Robmaister commented 8 years ago

This particular map works perfectly if you set the cell size to 0.19 instead of 0.16 and bump up the agent height a bit.

Spent a lot of today doing a huge refactoring run, looking at this now and potentially fixing tomorrow

Robmaister commented 8 years ago

Never mind, this ended up being pretty simple and apparently Recast exhibited this same bug a while ago. I ported over the fix they added to PolyMesh.Triangulate and the problem seemed to go away!

For reference: https://github.com/recastnavigation/recastnavigation/blob/master/Recast/Source/RecastMesh.cpp#L377

Those exact settings were causing overlapping/parallel edges apparently. I tried a few other settings but only that one map. I'll leave this open for you to test further before seeing if there are any other edge cases.

AqlaSolutions commented 8 years ago

@Robmaister I'll test it a bit later (New Year, you know), thank you very much for the fix!