Skip to content
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

Use recastnavigation for pathfinding (#2229) #1633

Merged
merged 97 commits into from Oct 30, 2018
Merged

Conversation

@elsid
Copy link
Collaborator

@elsid elsid commented Mar 15, 2018

Solves #2229.

Should replace #1542.

To build use recastnavigation from repository.

Tasks and decisions to be done:

  • When build NavMesh? On cell preload and cell load in background.
  • Load Navigator configuration from settings.cfg.
  • Use tiles to build navmesh `. Allows actors to start find path faster. Possibly to do in parallel. Allows caching.
  • Visualize NavMesh. togglenavmesh command.
  • Visualize actors paths. toggleactorspaths command.
  • Split RecastMesh into tiles. Reduces time to build single navmesh tile.
  • Limit number of tiles to add to NavMesh. Important when number of loaded cells more than 9. There is a physical limit in recastnavigation how much polygons and tiles could be in navmesh. Polygon identifier contains tile number and polygon number inside tile 22 bits total. Now 10 bits used for tile and 12 for polygon. Could be increased if recastnavigation would use 64 bits identifiers (need a lot of changes).
  • Support changing collision shapes. Navmesh updates when object changed or transformed.
    • Animated
    • Transformed (doors)
  • Support avoided areas (task #1724)
  • Support swim (water). Navmesh surface with specific water flag. Possible to forbid actors to swim:
    • Exterior cells
    • Interior cells
  • Support doors. Allow actors to find path through closed doors:
    • without teleports
    • with teleports (who can use it?)
  • Use different navmesh with half extents for different actors:
    • Exterior cells (takes too much time to build navmesh, need optimization)
    • Interior cells
  • Different settings for interior and exterior cells. There is a restrictions for that. Tile size depends on cell size. Navmesh can't contain tiles with different sizes, so different navmeshes are required to use different cell size for interior and exterior. Probably will not be possible to make off mesh connections for teleports (needs research).
  • Documentation for settings
    • Comment for each option in settings-default.cfg file
    • docs/source/reference/modding/settings/navigator.rst document
  • Cache NavMesh tiles data
    • Select key generation approach:
      • Use btCollisionShape user pointer to store original memory address or counter value. Small size. Possible collisions. Surrogate key.
      • Use RecastMesh binary data. Requires ordered build of RecastMesh. Large size. Persistent key.
    • Select limit cache size approach:
      • Limit by total NavMeshData size. Allows to limit by used memory. Too large objects possible could not fit cache size in some specific cases.
      • Limit by number of items. May lead to large variance of used memory.
    • Select cache item replacement method:
      • Replace least recently used item. Requires external lifetime handling of a NavMeshData value.
      • Replace currently unused least recently used item. Allows internal lifetime handling of a NavMeshData value. Requires to hold used item externally.
  • Find optimal parameters values
  • Unit tests
  • Consider actors as obstacles (implemented with some issues here, disabled now), (see #1633 (comment))
    • Find out how to communicate openmw physics and dtCrowd physics.
    • Use dtCrowd for multiple navmeshes.
    • Handle agents number overflow.
  • Support jump
  • Build NavMesh tiles data on cell preload
@elsid elsid force-pushed the pathfinder_detour branch 15 times, most recently from 679aee0 to bd5d3a7 Mar 16, 2018
@akortunov
Copy link
Collaborator

@akortunov akortunov commented Mar 16, 2018

I am not sure if popular Linux distros contain recastnavigation package. If not, OpenMW will be harder to maintain with new dependency, especially we will use custom patches.

UPDATE:
builds fine with latest commit, helps with bug #1997 and bug #3524.

@elsid elsid force-pushed the pathfinder_detour branch 5 times, most recently from 7f273fd to 3aee2ee Mar 16, 2018
@elsid
Copy link
Collaborator Author

@elsid elsid commented Mar 16, 2018

I agree, but there are some solutions. We can include recastnavigation as submodule. Custom patches also bad idea, and I've made pull requests for those changes to eliminate this. Of course, it is always possible to go back to master version. For now it's just more convenient to make it this way.

@JDGBOLT
Copy link

@JDGBOLT JDGBOLT commented Mar 16, 2018

Well, was doing some testing of this pull request within my game and it's pretty dang impressive. It definitely will need work on some sort of caching mechanism or whatever, as those load times when changing cells are pretty distracting. Perhaps might be better to generate them once when loading the cell, with it having basically a cache stored for each cell which keeps track of the order of mods affecting that particular cell. Also just experienced a fatal error seg fault within it. Kernel log says within OpenAL but it was during one of the parts where it was generating, as the sound just all of a sudden paused. Maybe OpenAL was expecting output from the game but as it was completely paused while doing the generation it didn't get the output it needed or something. Will try to recompile with debugging symbols and see if it does it again, running it within GDB. But I have to admit this seems much more impressive than the #1542 pull request, as that one would constantly be regenerating the paths as you were moving and was causing a lot of stuttering as you get further from the enemies. Was playing around outdoors with a kwama forager and it was really cool seeing it not being stupid, taking actual intelligent paths and seeming to always get to the player. As I said, the only diminishing part of the experience is the long load times when changing cells, will have to do more testing while indoors but I'm definitely liking where this is going so far. Was pretty magical to see Morrowind AI not being dumb and actually navigating around obstacles. Will do further testing but good work so far!

@JDGBOLT
Copy link

@JDGBOLT JDGBOLT commented Mar 16, 2018

All right, it's been consistently crashing and segfaulting, in different areas, another time in OpenAL, one time in OSG as it is trying to run a single pass render. Though it seems the commonality is related to starting a thread, I'm going to try rebuilding without this patch just to make sure that it's not something on my end, but it definitely seems to be maybe related to some thread altering memory it shouldn't be, or something like that.

@ghost
Copy link

@ghost ghost commented Mar 16, 2018

Drools

That's so cool. Sounds like all of our woes with AI and pathfinding will be fixed for good.

As you noted, the main question is when to build the navmesh. When I thought about recast a while back, I thought that obviously we'll save navmeshes with the editor and that way recast can only be a post 1.0 feature because we need to break the ESM file format to include navmeshes. But now that I think about it again, prebuilding the navmesh into the files is probably a bad idea. Different mods can add different objects into a cell, and you can't build the final navmesh until you know all of the mods. Plus, the system will have to somehow cope with objects that are placed or disabled at runtime (e.g. the faction strongholds) and rebuild the cell's navmesh then. So in my mind the navmesh should probably be built at runtime. Obviously the 2-3 seconds extra loading time on each cell change are too much though. Can the navmeshes be built in a background thread and then the AI could fall back to the 'dumb' (current) pathfinding implementation as long as the navmesh is not built yet (or use the previous navmesh in the case where we already have one, but need to update it to account for some disabled/enabled objects)? Is recast modular/threadsafe enough to accomplish that? If not, could we run two separate instances of recast and swap them every time the navmesh has finished building?

@JDGBOLT
Copy link

@JDGBOLT JDGBOLT commented Mar 16, 2018

This is especially impressive when I went in and basically deleted all the nav meshes in Morrowind, the AI is surprisingly capable of navigating around the interiors, other than the annoyance of the game crashing like every couple minutes with segfaults. The two main areas I was seeing crashes was with libopenal and creating a thread, and osg when creating a thread to try to render. There are some corner cases where the ai just falls over, such as anything needing jumping to reach, anything over water, the AI hates trying to go into water, and also sometimes it tries to choose a closer path to the player through a wall and basically just runs into the wall. There are also some points where the ai will stop at the wrong place when trying to do spells or whatever and will basically have the spells ram into objects and not reach the player.

But otherwise the AI will do what it's supposed to, trying to navigate to the player in order to attack. Also by removing the nav meshes the wandering/patrolling is kind of broken, since they no longer just go along the path grids they will still try strolling around a bit, but like sometimes the guards can go outside the walls in balmora or whatever. But again, this is with every navmesh in Morrowind deleted using openmw-cs, and when starting combat they will try to navigate around remarkably well considering there is no hand placed stuff, just whatever recast pregenerates in the like 5 seconds or whatever when entering a new cell.

Honestly I would say pregeneration should be when starting up the game for the first time with a new load order, as the generation times are pretty dang painful when running around, especially outdoors, the game will constantly be pausing and stuttering when running around, and when it's doing the pregeneration the game basically just stops 100%, no sound or anything. Also I have encountered when the ai is trying to do a path sometimes the game will also just completely pause while it's doing it's calculations. Interiors might potentially be fine with doing the pregeneration when first entering the cell, you kind of expect that it might take a moment to load the cell. But yeah, there really needs to be a caching system in place, hopefully that just takes into account the plugins that affect that cell, and in what order, that way only massive changes to the cell are necessary for the generation. And while very impressive without the help of the nav meshes, the nav meshes still are a bit better in regards to getting around, as sometimes the characters will be skirting a wall or whatever when navigating, rather than going in a straight line.

But otherwise, great work as far from a player experience, only the pauses to the game and the crashing, and a few edge cases that need to be fixed up tarnish the experience.

@JDGBOLT
Copy link

@JDGBOLT JDGBOLT commented Mar 17, 2018

Just for an example of the crash that I experience with this patch applied: https://pastebin.com/5d5CN0sf , the other I notice being somewhere in OSG, but it also was crashing with the start_thread() of libpthread, so I'm guessing there is some sort of thread contention or something.

@kcat
Copy link
Contributor

@kcat kcat commented Mar 17, 2018

Smells to me like memory corruption (buffer overrun, or use-after-free or something). I'd suggest compiling with Clang's memory or address sanitizer, or using Valgrind, to find where invalid writes happen.

@JDGBOLT
Copy link

@JDGBOLT JDGBOLT commented Mar 17, 2018

All right, after running OpenMW through valgrind, and suffering through 2fps performance running around with NPC's until it crashed, I think this should hopefully help with tracking down the crash: https://pastebin.com/sA2QxNHi

Edit 1: Looks like valgrind is specifically complaining about this line: https://github.com/OpenMW/openmw/pull/1633/files#diff-2318e0517898da5f974fd390a55511c9R1216

Probably moving/accessing some memory it shouldn't be or something like that.

Edit 2: One other thing I have encountered is where the game will just freeze and have 100% cpu utilization for a thread and will call that function listed above lots of times and begin just gobbling lots of memory. As far as what is calling it, not sure, as I just put in a cout for that part of the function and it was doing it constantly.

Edit 3: Just thought I would update and put in the memmove command which caused the game to segfault, which was memmove(0x563294c0e3b0 + 2, 0x563294c0e3b0 + 1, 18446744073709551615 * 4), with the values being:
path = 0x563294c0e3b0
req = 2
orig = 1
size = 18446744073709551615
Not 100% sure if it is because req = 2 or size = some huge number, will try plugging those in and seeing what causes the crash.

Edit 4: Well, plugging in the numbers into the function, it was the size being a huge number that caused the crash, and I would guess it is related to the line https://github.com/OpenMW/openmw/pull/1633/files#diff-2318e0517898da5f974fd390a55511c9R1214 .

Edit 5: A bit more debugging done, looks like maxPath becomes 1 and the other value to 2, which when it reaches that point it basically does 1-2 and creates the maximum negative number as it is unsigned. An example of the calculation working is req(1) + size(0) > maxPath(2) , but then right before the crash req(2) + size(0) > maxPath(1), size = -1 and memmove(0x55f9bc2342c0 + 2, 0x55f9bc2342c0 + 1, 18446744073709551615 * 4) .

@greye
Copy link
Contributor

@greye greye commented Mar 17, 2018

@scrawl
Recast is able to handle dynamically added static objects (huh) in the world using tiling and cutting. I.e. when objects being added it is possible to just cut wholes in adjacent navmeshes, when object being removed it is possible to recreate just an affected tiles in realtime. Therefore it is quite appealing to prebuild navmeshes for at least main files.

@AnyOldName3
Copy link
Member

@AnyOldName3 AnyOldName3 commented Nov 1, 2018

Do we actually run the tests on AppVeyor or do we just assume they'll do the same thing as on Travis and ignore them? The AppVeyor builds don't work on my computer, so it's possible.

@psi29a
Copy link
Member

@psi29a psi29a commented Nov 1, 2018

That is something we should fix, the tests should work on all platforms. It is possible that it just hasn't be implemented.

@psi29a
Copy link
Member

@psi29a psi29a commented Nov 1, 2018

Things that need addressing:

  1. OpenMW needs to not crash on Windows
  2. 'New Game' needs to work, as in... the guard needs to come down and un-glue you from the boat's hold

Hopefully these can be resolved and we can move on with 0.46, otherwise we can always revert.

@elsid
Copy link
Collaborator Author

@elsid elsid commented Nov 1, 2018

One thing I've figured out. New game was broken before this merge. I'm trying to find a commit where.

@JDGBOLT
Copy link

@JDGBOLT JDGBOLT commented Nov 1, 2018

I just found what broke, it's here: 49d8124#diff-f13496d9875b2507b0140ff8db91a2f0R25

Wrong datatype, since it's bool it's 1*1 for the max distance. Changing to float or int or whatever causes the new game sequence to successfully work.

@elsid
Copy link
Collaborator Author

@elsid elsid commented Nov 1, 2018

Changing type works, but there is another issue. Scripted actors couldn't reach target, so they are making circles around.

@AnyOldName3
Copy link
Member

@AnyOldName3 AnyOldName3 commented Nov 2, 2018

I'll try and get you another for a Debug build.

The past few days have been really effective for finding Windows-specific issues. I can't build in debug mode because a function declaration seems to have gone missing. I'll get this sorted, but @elsid if you can manage to work with the RelWIthDebInfo stack trace screenshots in the meantime, that's your best bet, as it may be some time.

It looks like there were two issues with Debug builds on Windows.

One was a regression from a year ago when d19839a bumped up the minimum CMake version, thereby changing a bunch of policies from OLD to NEW. In the future, this can be avoided by looking at the warnings CMake outputs before bumping the CMake version. I didn't know this was a thing, so may well have signed off on the change. Either way, it shows how infrequently I clear my CMake cache.

The other was that https://github.com/OpenMW/openmw/blob/master/components/debug/debugging.hpp#L55 uses OutputDebugString, but we hadn't actually included the Windows header which contains it. I guess maybe the headers included in that file might have indirectly included it when testing was done, but some other change removed it.

Expect a PR soon.

@AnyOldName3
Copy link
Member

@AnyOldName3 AnyOldName3 commented Nov 2, 2018

#2010 should fix debug build on Windows. I've not merged it because I'm not 100% sure that including the whole of Windows.h is the best approach, even though that seems to be what Microsoft's documentation recommends.

@AnyOldName3
Copy link
Member

@AnyOldName3 AnyOldName3 commented Nov 3, 2018

Although I think we've got everything fixed that we'd found so far, someone just reported a bump in memory usage from 1GB to 13GB+ when using recent nightlies to explore emba-5, which I assume is because of this PR. Anything we can do about that, do we back off our RAM usage if we're eating more than a computer has, and is emba-5 doing anything weird that wasn't taken into account when this PR was written that we can work around?

@akortunov
Copy link
Collaborator

@akortunov akortunov commented Nov 3, 2018

Suggestions how to improve the "toggleactorspaths" console command:

  1. Do not render paths for dead actors.
  2. Do not render path, if an actor (a wandering one, for example) reached the destination, but with destination tolerance (when pathTo() returns true, I suppose).
  3. Add a shortcut ("tap", for example).

@psi29a
Copy link
Member

@psi29a psi29a commented Nov 3, 2018

I ran around Morrowind (with Expansions) for about 10 minutes:

bcurtis@Wintermute:/Workspace/Private/OpenMW/build$ ps aux | grep openmw
bcurtis 24101 232 2.4 2607352 805432 pts/12 Rl+ 09:32 7:11 ./openmw
bcurtis 24506 0.0 0.0 14756 1060 pts/17 S+ 09:35 0:00 grep --color=auto openmw
bcurtis@Wintermute:
/Workspace/Private/OpenMW/build$ ps aux | grep openmw
bcurtis 24101 241 3.9 3165424 1285744 pts/12 Rl+ 09:32 15:34 ./openmw
bcurtis 24903 0.0 0.0 14756 1012 pts/17 S+ 09:39 0:00 grep --color=auto openmw
bcurtis@Wintermute:~/Workspace/Private/OpenMW/build$ ps aux | grep openmw
bcurtis 24101 242 5.7 3707644 1876676 pts/12 Rl+ 09:32 22:29 ./openmw
bcurtis 25430 0.0 0.0 14756 1012 pts/17 S+ 09:41 0:00 grep --color=auto openmw

@psi29a
Copy link
Member

@psi29a psi29a commented Nov 3, 2018

Gluka said Yesterday at 10:47 PM

yeah, i've noticed that it can struggle pretty hard to draw the navmesh for emba5 in a reasonable amount of time but the geometry can get kind of crazy there.
also had an out of memory issue running around the tunnels in emba5 for some reason. i think it could be related to recastnav, but i need to test it some more.

@psi29a
Copy link
Member

@psi29a psi29a commented Nov 3, 2018

#2014 was added thanks to @akortunov

@Capostrophic
Copy link
Collaborator

@Capostrophic Capostrophic commented Nov 3, 2018

Is there anything possible to do with the fact that actors may shortcut over deep holes to reach the player and subsequently fall through them?

@elsid
Copy link
Collaborator Author

@elsid elsid commented Nov 3, 2018

@AnyOldName3 Found problem with memory consumption. Navmesh cache tracks only navmesh data size to limit total size. Actually a cache key is usually bigger than data, because it contains all geometry, and navmesh data contains only usable for actors to move. For morrowind the ratio is 1 / 7 (data size / key size), but for emba-5 it is 1 / 48. With cache limit 256 MiB actual memory consumption should be 12544 MiB. The fix is to calculate cache item size as data size + key size. I will make a pr.

Another problem I've found is updating every tick animated objects with collision object in emba-5. It blocks navmesh updater worker to do anything except reacting to this updates. I see two possible fixes. First is to change job priority for those updates. Second is to skip updates when job queue is not empty. I will make a pr, but need some time to try and to test solutions.

@Capostrophic Is is about https://gitlab.com/OpenMW/openmw/issues/1997 ? It seems the problem is with this fallback. Need to do more research to how to fix this without breaking anything else.

@psi29a
Copy link
Member

@psi29a psi29a commented Nov 3, 2018

There is a much higher memory allocation with navmeshes, 3x so many. Using valgrind and loading my savegame just outside of excise office for both 0.45 and master:

0.45:

==27413== HEAP SUMMARY:
==27413== in use at exit: 295,334 bytes in 2,888 blocks
==27413== total heap usage: 5,301,971 allocs, 5,299,083 frees, 921,940,302 bytes allocated
==27413==
==27413== LEAK SUMMARY:
==27413== definitely lost: 8,785 bytes in 15 blocks
==27413== indirectly lost: 13,898 bytes in 77 blocks
==27413== possibly lost: 1,352 bytes in 18 blocks
==27413== still reachable: 271,299 bytes in 2,778 blocks
==27413== of which reachable via heuristic:
==27413== newarray : 1,536 bytes in 16 blocks

master:

==5409== HEAP SUMMARY:
==5409== in use at exit: 293,294 bytes in 2,854 blocks
==5409== total heap usage: 6,737,240 allocs, 6,734,386 frees, 3,241,209,132 bytes allocated
==5409==
==5409== LEAK SUMMARY:
==5409== definitely lost: 8,905 bytes in 15 blocks
==5409== indirectly lost: 13,778 bytes in 77 blocks
==5409== possibly lost: 1,352 bytes in 18 blocks
==5409== still reachable: 269,259 bytes in 2,744 blocks
==5409== of which reachable via heuristic:
==5409== newarray : 1,536 bytes in 16 blocks

What is interesting is that the same number of blocks lost, so the memory leaks have always been there... they seem to be exasperated now by master.

@psi29a
Copy link
Member

@psi29a psi29a commented Nov 3, 2018

I did a test with vanilla Morrowind using latest master. I started fresh off the boat, then flew my butt to solstheim and picked a fight with two Rieklings and a Riekling Raider then went all god mode on them and left OpenMW to run for a few hours.

The end result is that OpenMW memory consumption never budged even while the little bastards were running around and attacking me. So I don't see any memory leak leak.

Loaded fresh off the boat:
bcurtis 14970 200 1.2 2241612 416516 pts/12 Rl+ 18:18 1:20 ./openmw
bcurtis 14970 201 1.2 2241612 416516 pts/12 Rl+ 18:18 1:26 ./openmw
bcurtis 14970 204 1.2 2241740 416516 pts/12 Sl+ 18:18 1:38 ./openmw
Flew to solstheim and picked a fight:
bcurtis 14970 219 2.4 2645044 807920 pts/12 Rl+ 18:18 71:15 ./openmw
bcurtis 14970 218 2.4 2645044 807920 pts/12 Rl+ 18:18 72:29 ./openmw
bcurtis 14970 212 2.4 2645044 807920 pts/12 Rl+ 18:18 128:28 ./openmw
bcurtis 14970 211 2.4 2645044 807920 pts/12 Rl+ 18:18 140:00 ./openmw
Did a quick save and quick load:
bcurtis 14970 211 2.4 2634196 812324 pts/12 Rl+ 18:18 142:41 ./openmw
bcurtis 14970 207 2.4 2635732 812324 pts/12 Rl+ 18:18 179:20 ./openmw
bcurtis 14970 205 2.4 2635732 812324 pts/12 Rl+ 18:18 232:43 ./openmw
bcurtis 14970 205 2.4 2635732 812324 pts/12 Rl+ 18:18 237:38 ./openmw

@elsid elsid mentioned this pull request Nov 4, 2018
@jvoisin
Copy link
Contributor

@jvoisin jvoisin commented Nov 4, 2018

It seems that using recastnavigation will bump the memory requirement of openmw :/

@psi29a
Copy link
Member

@psi29a psi29a commented Nov 4, 2018

@jvoisin have a look at #2021 Looks like the memory requirement for recastnav is being dialed back to something less grotesque. ;)

@jvoisin
Copy link
Contributor

@jvoisin jvoisin commented Nov 4, 2018

It looks like it still doubles the amount of used memory, doesn't it?

@psi29a
Copy link
Member

@psi29a psi29a commented Nov 4, 2018

I'm sure there is more work to be done.

@elsid
Copy link
Collaborator Author

@elsid elsid commented Nov 4, 2018

It doubles amount of allocated memory, but not used memory. Basically amount of used memory depends on max nav mesh tiles cache size setting. Used memory is about 3% more with disabled cache (max nav mesh tiles cache size = 0). Default cache size adds about 500 MiB. Default settings value is 256, but cache key is stored twice in cache. This should be fixed to avoid any confusion. I will make a pr. How much memory we consider affordable for navmesh cache size?

Memory consumption with disabled cache size:
disabled_cache

Memory consumption with default cache size:
default_cache_size

@elsid elsid mentioned this pull request Nov 4, 2018
@akortunov
Copy link
Collaborator

@akortunov akortunov commented Nov 5, 2018

Clang analyzer complains about some issues in the RecastNavigation itself:

In file included from /home/travis/build/OpenMW/openmw/extern/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp:24:
/home/travis/build/OpenMW/openmw/extern/recastnavigation/Detour/Include/DetourCommon.h:142:17: warning: The right operand of '-' is a garbage value
        dest[0] = v1[0]-v2[0];
                       ^~~~~~
/home/travis/build/OpenMW/openmw/extern/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp:511:21: warning: Called C++ object pointer is null
        if (dtStatusFailed(m_nav->getTileAndPolyByRef(ref, &tile, &poly)))
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/travis/build/OpenMW/openmw/extern/recastnavigation/Detour/Source/DetourNavMeshQuery.cpp:556:37: warning: Division by zero
                const float* vb = &verts[((imin+1)%nv)*3];
                                          ~~~~~~~~^~~
/home/travis/build/OpenMW/openmw/extern/recastnavigation/Recast/Source/RecastMeshDetail.cpp:586:2: warning: Function call argument is an uninitialized value
        tris.push(hull[start]);
        ^~~~~~~~~~~~~~~~~~~~~~
/home/travis/build/OpenMW/openmw/extern/recastnavigation/Recast/Source/RecastMeshDetail.cpp:587:2: warning: Function call argument is an uninitialized value
        tris.push(hull[left]);
        ^~~~~~~~~~~~~~~~~~~~~

/home/travis/build/OpenMW/openmw/extern/recastnavigation/DetourTileCache/Source/DetourTileCacheBuilder.cpp:485:7: warning: Value stored to 'ndir' during its initialization is never read
                int ndir = dir;
                    ^~~~   ~~~
/home/travis/build/OpenMW/openmw/extern/recastnavigation/DetourTileCache/Source/DetourTileCacheBuilder.cpp:1280:22: warning: The left operand of '&' is a garbage value
        *dst++ = indices[2] & 0x7fff;
                 ~~~~~~~~~~ ^

Probably we should fix these issues and send a PR to the RecastNavigation repo.

@elsid
Copy link
Collaborator Author

@elsid elsid commented Mar 3, 2019

I've made and issues based on some TODOs in pr description:

Other open TODOs seems for me not important or I have not idea how they could be implemented.

@elsid elsid deleted the pathfinder_detour branch Nov 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet