Closed AqlaSolutions closed 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.
@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.
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.
@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?
@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.
I tried to tweak settings but even when I make it disappear (with erode radius usually) it appears in another place.
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?
@Robmaister no, they don't go away
@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.
Huh, that's interesting. There's probably a small rendering bug somewhere then. And a bug in PolyMesh. Thanks for being patient about this :)
@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.".
ping?
Thanks for the reminder, I'll look into this particular map today
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
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.
@Robmaister I'll test it a bit later (New Year, you know), thank you very much for the fix!
I tried to adjust parameters but this is the best I've got:![111](https://cloud.githubusercontent.com/assets/3465565/9007531/db074088-379a-11e5-9f1a-f06361f19d97.png)
Can you please look at the model? https://www.dropbox.com/s/49drj4kjjrz6e43/nav_saga_problem.obj?dl=1