Instead of using just the polygon edges, use the detail edges as well. Ray cast errors have been fully eliminated; nothing ever clips through geometry anymore. The results are also a lot more detailed now as we can connect various sub edges together. The resulting navmesh also performs better in-game, the npc's are now a lot more fluent with jumps and climbs, they rarely clip though geometry, if they do its typically an error with the input geometry used to build the navmesh.
There was also a bug in GetBestTraverseType; the exclusive check (where at least one overlap had to occur) returned true if both overlap tests failed. This has been fixed by flipping the check and now checking if at least one overlaps when an exclusive test was specified.
Use rdClassifyPointOutsideBounds to mark neighbor tile so it only gets marked if we mark a tile, and a polygon outside the marked tile. Also added an optimization so the same tile doesn't get rendered twice (side == 0xff).
Now also gets stored in the project file. Also reordered the way each field gets stored so its easier to tweak or add/remove outside the editor by external tools.
Handle it in the same loop as standard traverse links, off-mesh links also have a link determining its traverse type after it has been reverse engineered and fixed. The output and behavior is now correct.
We would only clear polygons that weren't marked as unlinked, this was introduced when the prune tool was refactored to use the unlinked polygroup tag. The side effect is, when you remove a tile, and cause a polygon on a neighbor tile to not link to anything, it will be marked as unlinked which is the correct behavior, but when you readd the tile, the entire island will be marked as unlinked.
The function dtCreateDisjointPolyGroups got fixed later by not taking traverse links into account, since polygon islands linked together with traverse links are still disjoint. This was also the time the check had to be removed when clearing all labels but this didn't happen.
Removing and readding tiles now work properly after this patch.
From now on, internal links are connected first before external neighbor links. This now also happens in the same pass which improves performance (this yields better results and behavior after the last few and current changes).
Also added a fine tunable test dictating whether links should only connect when edges overlap, or when one of the edges overlap (can be tweaked by setting an elevation trigger, by skipping out on lower elevations if this deems necessary, but typically doesn't).
The slope angle option was originally in the table but removed. After reconsideration this has been brought back in as you cannot define min/max slopes with 3d distances and elevation differences. The distance either needs to be 2d (which will break the max 2550.f distance per link rule), or an additional slope check has to be used to define this properly.
After a lot of fine tuning, the results appear to be almost identical to the original navmeshes shipped with Respawn games. The algorithm is also a lot faster now (went from 30 seconds to 8 seconds on the staging area with much better and more accurate results).
The direction is represented over the XY plane, previously XZ on Recast's original coordinate system. There were multiple inconsistencies in Recast where the XZ plane got represented as XY and visa versa.
Rework the way traverse links are tracked and how the traverse table gets recreated when a tile gets removed/added. We would rebuild the entire traverse network and thus leak links since we also cleared the map that tracks the connections.
Noticed this issue when creating multiple number of off-mesh links between 2 polygon islands. Turns out a pull request was already created to address this problem at https://github.com/recastnavigation/recastnavigation/pull/622. Merged the changes directly as this yields correct behavior as far as off-mesh links have been tested.
-x and +x have to be flipped because of the coordinate system conversion (OpenGL XZY -> Source XYZ). The diagonal cases of rdClassifyPointInsideBounds also rarely worked... Rewritten to use rdClassifyPointOutsideBounds instead by moving the point outside the box towards its direction. Hack but works very reliably.
Instead of setting it to the old flags (undoing any changes we did while we were at the off-mesh connection tool) only set the off-mesh draw flag if it was enabled since that's the only one we disable when entering this tool.
Merge recastnavigation/recastnavigation#672
Actually improves the filtering of ledge spans as they are now a lot firmer against their limits, this is also beneficial for traverse link generation as we get more accurate ledge spans to work with (making the offsetting math do its job better since it assumes accurate ledge spans).
There was a report further down this pull request that pathing results differed after this change, along with a new one at https://github.com/recastnavigation/recastnavigation/issues/729. I was however not able to replicate it, nor did any behavior change in-game on a navmesh generated on kings canyon.
Only limit it to the actual neighborhood since otherwise removing a tile will become a problem, the current logic only unlinks it from its neighborhood if its not an off-mesh link. We also should keep it that way. If user wants links that extend further horizontally, they should increase the tile size.
Slightly more expensive than just checking neighbors, but offers a lot more possibilities with off-mesh links (long diagonal jump, zip lines, etc..). The mesh linking stage has now been moved to an offline process anyways so performance isn't a huge issue here.
These were adjusted in commit 513f4a52971f5ca9090a4789c34733b9946ad390, the reason for this was because smaller tiles had a lot less errors in-game than larger ones. But the issue was that our BVTree was incorrectly transformed, and thus poly's on edges would almost always be outside their respective bounding volumes. Now the navmeshes work normally regardless of tile sizes, but 512 sized tiles generate and perform better than 256 ones.
