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.
Results in better and more correct navmeshes as super_spectre doesn't support all the types frag_drone has for example, use the mask table to determine whether to establish or not. Also added proper directives now to map the 19 and 20 types properly between MSET 5 and MSET 8.
Low res version of the firing range had 1 failure case, kings canyon had 10+. This typically happens if the cell is right on a poly edge. If getting the height from triangle fails, get it from detail edges instead. This fixes pretty much all failure cases with high accuracy (not as high as getting it from the triangle, but with only 10 failures on a map the size of kings canyon is more than good enough).
Out of bounds access caused when a navmesh is loaded with a smaller amount of tables than currently selected. Always reset the selector when loading/building.
Instead of getting the opposite tile of where our vert is to create the largest links possible, get the nearest one instead. This gets rid of almost all unwanted noise.
Changed algorithm to use elevation instead of slopes and updated values to newer values which are still somewhat incorrect, but at least now we have full coverage on all types. Will need to be polished further. Also made the selector loop in reverse which causes way better and more coverage than starting from the start of the table.
Should always be checked, linking edges that face the same direction causes the ai to perform unnecessary jumps and sometimes even causes it to clip into geometry.
Check if we have enough space for num new links before starting the complex calculations. This optimization saved 10+ seconds on the firing range and had no effect on the output results; the navmesh still hashed to the same value as the one build before this patch.
Move internal edge link generation to separate loop, this results in way better jump link coverage on the navmesh, else we eat up all available links by the time a neighbor uses the tile again. Also did some improvements to the masks in s_traverseAnimTraverseFlags to better reflect coverage for each traverse anim type, this most likely could still use some work however.
