New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for long range off-mesh connection support #645
base: main
Are you sure you want to change the base?
Conversation
I reads:
I seen the commit effectively disables So I wondered, is there any technical way to add adjacent tile offmesh links like the current code does and only postpone non-adjacent tile offmesh links? Also, would there be any benefit in doing this? I guess this would still allow adjacent offmesh links to work if not all tiles are loaded yet. This is just a thought I share, no more. |
That should be easy to overcome, one simply would need to create a list of all unlinked off-mesh connections, as said in the comment below: The only reason for my commit disabling |
Merged the fix, but without the catch upgrade.
This is excellent, are you planning an implementation that supports the tile cache (Sample_TempObstacles) as well? I'm not sure how to integrate this into the tile cache. |
Some feedback on this. 1)It works 2)The documentation for the function is incorrect in my understanding, target is actually where the starting point is, and tile is the end point. It's reverse what you would expect. 3)The sample connection establishment is extremely slow for meshes with large amounts of tiles First I moved it to be a member function of dtNavMesh, as it's something I think should be supplied and simply called by anyone using the library. I then focused on optimizing the function call. I altered and rearranged the checks, continuing the loop if
this was the first major speedup as there's no point looping thru the X range if there's no offmesh connections in the target tile. I then added a new variable to the dtMeshTile class unconnectedOffMeshCount, and during tile construction set this to the header->offMeshConCount. This value is also checked, at the end of dtAddtile and if it has a value > 0 then m_hasOffMesh is set to true. This gives a huge performance benefit for meshes where there are only connections inside the same tile that we don't have to scan the entire tile range to find start/end connections. Further possible improvements: It maybe worthwhile to keep the neighbor checks in, as searching neighbors is faster then scanning the entire tile range. It maybe worthwhile to import the rcVector class and add the tiles where unconnectedOffMeshCount > 0 that way we don't scan the entire tile range It maybe faster to use a navmeshquery to find the what the end tile would be for a given off mesh connection, rather then scanning all the given tiles.
|
So I played around with this a bit more I ported over rcVectorBase and renamed to dtVectorBase etc, and during the dtnavmesh::addtile, checked if header->offMeshConCount > 0 added it to the vector. Then a simple function
and smashed together the logic from dtNavMeshQuery::queryPolygons and the previous function create the following:
this new method is exceptionally fast, two orders of magnitude faster for meshes with large tile counts, and handles all connections just fine so I even went and disabled the self tile check inside addtile, so that all offmesh connections are handled thru this one function. Concerns that are outside my usecase: |
This lifts the restriction for off-mesh connections for tiled navigation meshes
where the two endpoints for a connection must be located in the same tile, or in adjacent tiles.
This is done by connection the off-mesh links AFTER all tiles have been built.
You may find more detail on: #195 (comment)
This "fix" is only crudely worked on as this issue suggests; an impropmtu fix.
#586 (comment)
More specifically, the change was only made to serve as a showcase, and although this should be working as intended with building the whole tile mesh, the same may not be applied to:
To make it work for cases above, further exploration on this method of approach should be necessary.