Fully generates polygon cells for the entire navmesh. Previously we never build this which caused ai to clip into, or walk into each other in-game (this system is an MSET 8 feature).
Allow to compile the editor for separate versions of the navmesh set. NavMesh cells are now also partially reversed and properly read out. Creating and writing them will happen in the future.
Titanfall navmeshes have the dtOffMeshConnection::userId field changed from unsigned into to unsigned short, and the lower half seems to be used for the jump types and (possibly) some flag. Work in progress implementation of the jump system on off-mesh links.
Originally taken from https://github.com/ASpoonPlaysGames/r2recast, slightly modified to use the new constants added in commit 78a632eec85ca5406adb03617084746b446b0044, and now renders white crosses if reverse links are set.
The dtNavMesh structure members were marked as public, but they should be private. Made them private. Also, dtNavMesh::addTile was reconstructing all links, even when we add tiles with pre-existing links. The link building logic has been moved to a new member function 'dtNavMesh::connectTile'. This should only be called once the navmesh tile has been added succesfully during build. If we load a navmesh now, the existing links will be used from now on. The dtNavMesh::m_tileCount member is now also correctly incremented and decremented in addTile/removetile.
Don't render the geom off-mesh connection, this is already done when the tool is enabled, and we don't want to render it outside the tool since it would overlap with the built off-mesh connection.
EditorPolyAreas::EDITOR_POLYAREA_JUMP is supposed to be right after EDITOR_POLYAREA_GROUND, this enumerant has been moved there (in exchange of water which is as far as i can tell unused). For the off-mesh connection tool the flags have to be set to EDITOR_POLYFLAGS_WALK (this is what Titanfall 2 does). Off-mesh links don't work yet, more work is needed in dtLink.
Some data that is in between the poly's and links weren't skipped properly. The engine skips this data in dtNavMesh::addTile, we didn't. This is now skipped properly by advancing over it before going over the links. The 2nd and 3rd bug was that the poly's end pointer, and off-mesh connections end pointer was set to the data size of the poly's and off-mesh connections rather than the poly and off-mesh con count. This small oversight has been fixed and the end pointers are now set correctly. The function dtCreateNavMeshData has also been updated to take this data into account correctly, it was using the Titanfall 2 NavMesh (NavMesh Set Version 5), structure sizes but this has been changed in Apex (NavMesh Set Version 7 and 8). These fixes did reduce the NavMesh's file size by a few kilobytes per megabyte.
Tool states aren't always set, they are typically only set for the active tool if an option changed, but if nothing changed, then nothing will get updated (including the navmesh handle) so dangling pointers will be used. This makes sure everything gets initialized.
the box's shape rendered correctly, but the faces were in the wrong order. The top face was on the side, so the voxel debug view didn't render correctly.
This is useful when a project file (.GSET) has been loaded with predetermined navmesh bounds, which allows you to check the new bounds to the old, and also see what you will be resetting too if mistakes were made during the modification thereof.
When loading from .gset, the editor would clip anything outside the stored bounds, but we still need the outer bounds as otherwise editing the existing bounds would be a lot harder.
The thickness of the bounds were increased, so the red one doesn't need to be darker anymore. Previously it was hard to see compared to the blue poly's.
