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.
Should've been converted to the source engine coordinate system as well, but we missed this as then rendering thereof was 'fixed' incorrectly causing incorrect bounding volumes to appear correctly. Fixed the renderer and the calculation; the AI now never gets stuck in-game regardless whether 256 or 512 sized tiles are used.
Since the table was taken out of the child instance in commit 245ff565042870e0cded7a2ec3dcc868a00414af, we should no longer handle the window and frame separately. Car count must now be counted together.
Allow the user to specify how far to extend from the current tile towards the direction of the traverse link, this is useful when navmeshes with smaller tiles are generated as the neighbor lookup boundary for these are essentially bound to the tile size, thus smaller tiles will result in smaller links unless we extend to further neighbors.
Reducing the tile size to 16 for all types completely eliminated the issue where an NPC in-game fails to find a steer poly after traversal (call to dtNavMeshQuery::findNearestPoly fails). Tile size of 16 causes correct tile numbering for world bmins and bmaxs. Also added 2 new sliders allowing the change of min and max tile bits + some additional cleanup.
Added table that allows you to fine tune and toggle traverse types for all anim types and navmeshes. Also tweaked default values with newer fine tuned ones to improve link generation more. There's still a ton of fine tuning work left to be done.
