In commit f5f14c153f0115af7a0ac5fe3b4be98b3816be84, a change was made to switch the default keys to pgup and pgdown. It appears however that these keys were used for the chat window.
The defaults have been adjusted to (backtick and f10) for console, and (insert and f11) for the browser.
There was also a bug in ImGuiConfig::Save() where it double nested the keyvalues, this has also been fixed. The keyvalue file now parser properly.
The option panel in the console has been slightly reworked to also show the secondary binding options for both the console als browser allowing the user to change both the primary and secondary for both windows without having to manually edit the files.
The home key should be reserved for console input as this is useful when running script code through the console, and needing to switch cursor positions to fix a typo or copy something. Page Up and Page Down weren't used and are less likely to be used by something in the game, remapped the defaults' secondary to these keys.
The algorithm can create multiple portals of different traverse types between 2 specific polygons, this option allows the user to override this behavior by limiting this to 1.
Optimization by only calulcating it when its used to avoid calculating it for nothing when we end up moving to the next edge. This is only used when the link is established.
The prune code will prune everything marked unlinked, but unlinked means that that polygon doesn't link to another, it doesn't mean its useless. Therefore, if we have an island that is unlinked, but still want to keep it, we should be to. The polygon should only be considered dead when its unlinked and disabled, which only happens through the prune tool. This allows for pruning and cleaning single polygon navmeshes.
dtHint::triangle should be triangles as it can contain more than one triangle, renamed it to 'tris' to keep consistency with the rest of the code base. Also fixed its comment explaining what its size is.
This causes many problems in titanfall and apex maps due to the large voxel sizes we have to use to generate navmeshes. A single unwalkable voxel makes a large difference. disabling these feature results in much better results. The problems this test filters away can be fixed with setting proper cell heights in our case.
Fixes https://github.com/recastnavigation/recastnavigation/issues/317. This can happen when we mave multiple spans in the X row. So far this crash only occured in Capitol City in Apex Legend's Worlds Edge map, where there are internal polygons in high rise buildings with 10 or more floors equally placed on top of another.
Increase to 29 bits for span limits, previously this was 13 and since the next field in the struct was a pointer, we end up using the 4 bytes padding so the struct size didn't increase. The reason for this increase is that rcSpan::smin and rcSpan::smax overflow when building a navmesh with a low cell height. This is especially an issue with maps that contain mountains. For the season 1 kings canyon map, the tiles containg the polygons for the firing range will be entirely flat due to the massive height difference between the base map and the firing range which resides under the map, causing it to be clamped to the previous MAX_HEIGHT value.
During new tests, not starting from the neighboring tile at north caused some smaller links to not establish, which is roughly 30 links in angel_city.bsp. This patch makes it always start from north without any alternation and yields the best results during all tests.
rdClassifyDirection never got intercardinal sides causing it to be unreliable and inaccurate. rdClassifyPointInsideBounds and rdClassifyPointOutsideBounds are tested and confirmed correct during every case, switched use to rdClassifyPointInsideBounds instead and removed rdClassifyDirection for the start side of the neighbor tile lookup. For the links: the base side is always the opposite of the land side.
Big optimization as you cannot link to the same polygon, you also cannot link to the same triangle. This drops polyCount number of iterations on polygons per tile.
The library used signed 32bit integers and single precission floating points to represent build times, but on long build times this will overflow. Added a dedicated time type while promoting it to double precission and adjusting all use cases throughout the library.
Go over each neighboring tile starting with the tile facing the edge normal, and then its oposite, and perform the same alternation on the next tiles. This link pattern gives the best and most consistent results by trying to link all sides equally. In order to guarantee maximum coverage, the link count multiplication has been increased from 8 to 32 per detail mesh bound as this new approach is creating an incredible amount of new links. Some of the links will end up not being used, but these will be removed during the prune stage.
- Portal kink point is now always offset twice the walkable radius to account ledge spans and center of hull to ledge, any extra is put on top with the default being 4.f to account for irregularities.
- Make sure we have enough clearance over the kink point and lower start point of the portal so that the NPC does not clip into overhead obstacles when performing an animation.
- Make sure we don't link a portal from underneath geometry by performing a raycast from the edge's mid point, and 2 additional ones if the link's span is larger than 100.f in world units.
This allows for getting the direct side of a side by doing side-1, side+1, etc.. A useful case would be to get tiles at sides facing the normal of an edge on our own tile and doing anything with these tiles.
If there's no movement on the x-y plane between sp and sq, there will be no magnitude, and thus also no discriminant. The code however will continue as it only checks if discriminant < 0. Due to this, the code will no longer take the origin and radius of the cylinder into account and that will cause any ray that extends above or below the cylinder to be a hit, regardless of where it was emitted from in the world. If we have no magnitude, we should always check if the start point resides inside the cylinder area on the x-y plane and determine from there whether to perform a vertical intersection test.
Shift portal mins and maxs together to try and align the portals. The system is dynamic and will take portal span into consideration. Also slightly changed the API to implement an optimization by switching the directional vector of the edges to their normals as we only need the normals in traverseLinkInLOS, this avoids having to recalculate them.
The static pathing data is either not built, or has to be rebuilt at this stage. If we have do happen to have dead polygons that we can use for traverse portals then we should leverage them to get as much coverage as possible.
Connecting adjacent polygons with traverse links will cause pathfinding to run into itself infinitely if either of the 2 poly's first link references the polygon from which the traverse link originates from. The behavior in-game is that the AI become stuck in the area with error code FAIL_NO_ROUTE_BLOCKED. Implemented the method 'dtNavMesh::arePolysAdjacent' to make sure we never connect adjacent polygons on our own or neighboring tile with a traverse link.
The traversability of off-mesh links is not dictated by the walkable climb in this engine; an off-mesh connection can be higher from the ground due to ziplines.
The mesh data from the game's BVH4 tree does not appear to have a fixed triangle winding order, making it nearly impossible to generate correct navmeshes while using the decoded BVH4 data. Fixing the sign enables us to generate the navmesh over the game's collision data properly rather than using the render mesh. This change does not appear to have a negative effect on the generated NavMesh.
These changes seem to yield better results for the larger maps. The improvements are minimal however. This change is probably more noticable on tile cache.
In recastnavigation/recastnavigation@15ebb8bd25 the change was made to use detail polygons, but it appears that after this change, the bounding volume gets build under the polygons, especially if the polygons's Z are equal on all vertices. Flooring the mins and ceiling the maxs appears to yield correct behavior in all scenarios by making sure the bounding volume always encases its respective polygon.
