swordlegend / recastnavigation

Automatically exported from code.google.com/p/recastnavigation
zlib License
0 stars 0 forks source link

Off Mesh Connections do not work with tiles. #235

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Open Demo (tested on r351)
1. Make yourself a tile mesh with at least 3 tiles in a row
2. You shall have 2 OffMeshConnection's:
   - first inside a middle tile
   - second from first to last tile
3. Open `Test Navmesh` Tool
4. Create a Path from first tile to last.
5. you can now see that only inner tile OffMeshConnections do work.

Atteched Bug demonstration image.

Expected output was a path from first Tile to last that uses OffMeshConnection 
between first and last tile.

tested on r351, windows (looks like logical bug so should be platform agnostic)

Please provide any additional information below.

Original issue reported on code.google.com by Oleg.Jak...@gmail.com on 26 Mar 2013 at 11:08

Attachments:

GoogleCodeExporter commented 9 years ago
You can only link off-mesh connections to a neighbour tile. Your longer 
connection spans too far.

Original comment by mi...@tinkercad.com on 26 Mar 2013 at 4:11

GoogleCodeExporter commented 9 years ago
Is there any way to make connectoins across multiple tiles avaliable? (in 
source code or in ofdmeshconnection settings)

Original comment by Oleg.Jak...@gmail.com on 27 Mar 2013 at 8:42

GoogleCodeExporter commented 9 years ago

Original comment by memono...@gmail.com on 16 Sep 2013 at 7:22

GoogleCodeExporter commented 9 years ago
Could I ask what the technical reason for not being able to support jumping 
over a tile is?

I'm currently in the process of moving from the simple tile to the tile cache 
implementations and the reduction in supported tile is size is posing as a bit 
of an issue.

Any possible suggestions on a work around? 

Currently I can only think of not using the recast implementation of off-mesh 
connections and using a separate way-point network. Each off-mesh connection is 
a way-point with direct connections to other walk-able points and A* would 
first be used on this network to plan the initial route. Recast would then be 
used to simply navigate between walk-able points.

Cheers, Stace

Original comment by Stace.Hindle on 9 Oct 2013 at 10:07

GoogleCodeExporter commented 9 years ago
The logic to connect off-mehs links were growing complex, so I decided to keep 
as simple as possible.

Off-mesh links are currently stored so that the link gets attached to the tile 
where the start point of the link is. When a tile is added to navmesh, it is 
easy to connect the off-mesh link to the destination tile where the link just 
happens to land. The core problem is that when you add a tile(x,y), you will 
need to know which other off-mesh links land to that tile. I chose to only 
check the neighbour tiles in order to avoid extra book keeping.

In retrospect, I think this was not a very good solution, I probably should 
have taken an approach where all off-mesh links are created from one pool, and 
bit the bullet and add that extra book keeping.

If you'd like to see that happen, please add an issue at the github page:
https://github.com/memononen/recastnavigation

Original comment by mik...@unity3d.com on 9 Oct 2013 at 12:12

GoogleCodeExporter commented 9 years ago
Maybe related to this, but I would like to see changes that support the dynamic 
addition and removal of links at runtime without rebuilding tiles. Seems like 
part of that would be to move all the off mesh connections out to a single list 
on the root nav mesh object which would presumably make them easier to go 
through and check when addTile is called.

Would that be a reasonable change that could be integrated back into detour?

Original comment by jswig...@gmail.com on 7 Jan 2015 at 10:47

GoogleCodeExporter commented 9 years ago
Let's continue the discussion here:
https://github.com/memononen/recastnavigation/issues/72

Original comment by memono...@gmail.com on 8 Jan 2015 at 6:48