diff --git a/CMakeLists.txt b/CMakeLists.txt
index 292d1dc06..09ccb315b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -604,9 +604,7 @@ if(WIN32)
endif(WIN32)
# Extern
-set(RECASTNAVIGATION_DEMO OFF CACHE BOOL "Do not build RecastDemo")
set(RECASTNAVIGATION_STATIC ON CACHE BOOL "Build recastnavigation static libraries")
-set(RECASTNAVIGATION_TESTS OFF CACHE BOOL "Do not build recastnavigation tests")
add_subdirectory (extern/recastnavigation EXCLUDE_FROM_ALL)
add_subdirectory (extern/osg-ffmpeg-videoplayer)
diff --git a/extern/recastnavigation/.gitignore b/extern/recastnavigation/.gitignore
index 98f17e4b7..7c12d58f0 100644
--- a/extern/recastnavigation/.gitignore
+++ b/extern/recastnavigation/.gitignore
@@ -9,16 +9,6 @@
*.so
*.idb
-## Linux exes have no extension
-RecastDemo/Bin/RecastDemo
-RecastDemo/Bin/Tests
-
-# Build directory
-RecastDemo/Build
-
-# Ignore meshes
-RecastDemo/Bin/Meshes/*
-
## Logs and databases #
*.log
*.sql
@@ -38,9 +28,6 @@ Thumbs.db
## xcode specific
*xcuserdata*
-## SDL contrib
-RecastDemo/Contrib/SDL/*
-
## Generated doc files
Docs/html
diff --git a/extern/recastnavigation/.travis.yml b/extern/recastnavigation/.travis.yml
deleted file mode 100644
index 0e63abad1..000000000
--- a/extern/recastnavigation/.travis.yml
+++ /dev/null
@@ -1,72 +0,0 @@
-language: cpp
-branches:
- only:
- - master
- - coverity_scan
- - /recast-.*$/
-
-sudo: false
-
-addons:
- apt:
- sources:
- - ubuntu-toolchain-r-test
- - llvm-toolchain-xenial-7
- packages: [ cmake, clang-7, clang-tools-7, gcc-8, g++-8, libsdl2-dev ]
-
-matrix:
- include:
- - name: Recastnavigation (all) on MacOS xcode9.4
- os: osx
- osx_image: xcode9.4
- before_install:
- - brew update
- - brew install sdl2
- if: branch != coverity_scan
- - name: Recastnavigation on Ubuntu Xenial GCC-5
- os: linux
- dist: xenial
- sudo: required
- if: branch != coverity_scan
- - name: Recastnavigation on Ubuntu Xenial GCC-8
- os: linux
- dist: xenial
- sudo: required
- env:
- - MATRIX_EVAL="CC=gcc-8 && CXX=g++-8"
- if: branch != coverity_scan
- - name: Recastnavigation on Ubuntu Xenial GCC-5 using Premake5
- os: linux
- dist: xenial
- sudo: required
- if: branch != coverity_scan
- before_install:
- - wget https://github.com/premake/premake-core/releases/download/v5.0.0-alpha12/premake-5.0.0-alpha12-linux.tar.gz -O premake.tar.gz
- - tar -xf premake.tar.gz
- env:
- - PREMAKE=1
- - name: Recastnavigation on Ubuntu Xenial Clang-7 with Static Analysis
- os: linux
- dist: xenial
- sudo: required
- env:
- - MATRIX_EVAL="CC=clang-7 && CXX=clang++-7"
- - ANALYZE="scan-build-7 --force-analyze-debug-code --use-cc clang-7 --use-c++ clang++-7"
- if: branch != coverity_scan
- compiler: clang
- - name: Recastnavigation Coverity Scan
- os: linux
- dist: xenial
- sudo: required
- if: branch = coverity_scan
-
-before_script:
- - if [ "${TRAVIS_OS_NAME}" = "linux" ]; then eval "${MATRIX_EVAL}"; fi
- - if [ "${PREMAKE}" = "1" ]; then cd RecastDemo && ../premake5 gmake && cd ..; fi
- - if [ "${PREMAKE}" != "1" ]; then mkdir -p build && cd build && ${ANALYZE} cmake ../ && cd ..; fi
-
-script: # 2 CPUs on Travis-CI + 1 extra for IO bound process
- - if [ "${PREMAKE}" = "1" ]; then make -C RecastDemo/Build/gmake -j3; fi
- - if [ "${PREMAKE}" != "1" ]; then make -C build -j3; fi
- - if [ "${PREMAKE}" = "1" ]; then RecastDemo/Bin/Tests; fi
- - if [ "${PREMAKE}" != "1" ]; then cd build && ctest; fi
diff --git a/extern/recastnavigation/CMakeLists.txt b/extern/recastnavigation/CMakeLists.txt
index d23859dfc..4952e51da 100644
--- a/extern/recastnavigation/CMakeLists.txt
+++ b/extern/recastnavigation/CMakeLists.txt
@@ -6,9 +6,6 @@ project(RecastNavigation)
SET(SOVERSION 1)
SET(VERSION 1.0.0)
-option(RECASTNAVIGATION_DEMO "Build demo" ON)
-option(RECASTNAVIGATION_TESTS "Build tests" ON)
-option(RECASTNAVIGATION_EXAMPLES "Build examples" ON)
option(RECASTNAVIGATION_STATIC "Build static libraries" ON)
add_subdirectory(DebugUtils)
@@ -16,12 +13,3 @@ add_subdirectory(Detour)
add_subdirectory(DetourCrowd)
add_subdirectory(DetourTileCache)
add_subdirectory(Recast)
-
-if (RECASTNAVIGATION_DEMO)
- add_subdirectory(RecastDemo)
-endif ()
-
-if (RECASTNAVIGATION_TESTS)
- enable_testing()
- add_subdirectory(Tests)
-endif ()
diff --git a/extern/recastnavigation/CONTRIBUTING.md b/extern/recastnavigation/CONTRIBUTING.md
deleted file mode 100644
index 3cfdc2160..000000000
--- a/extern/recastnavigation/CONTRIBUTING.md
+++ /dev/null
@@ -1,185 +0,0 @@
-# Contributing to Recast and Detour
-
-We'd love for you to contribute to our source code and to make Recast and Detour even better than they are
-today! Here are the guidelines we'd like you to follow:
-
- - [Code of Conduct](#coc)
- - [Question or Problem?](#question)
- - [Issues and Bugs](#issue)
- - [Feature Requests](#feature)
- - [Submission Guidelines](#submission-guidelines)
- - [Git Commit Guidelines](#git-commit-guidelines)
-
-## Code of Conduct
-This project adheres to the [Open Code of Conduct][code-of-conduct].
-By participating, you are expected to honor this code.
-
-## Got a Question or Problem?
-
-If you have questions about how to use Recast or Detour, please direct these to the [Google Group][groups]
-discussion list. We are also available on [Gitter][gitter].
-
-## Found an Issue?
-If you find a bug in the source code or a mistake in the documentation, you can help us by
-submitting an issue to our [GitHub Repository][github]. Even better you can submit a Pull Request
-with a fix.
-
-**Please see the Submission Guidelines below**.
-
-## Want a Feature?
-You can request a new feature by submitting an issue to our [GitHub Repository][github]. If you
-would like to implement a new feature then consider what kind of change it is:
-
-* **Major Changes** that you wish to contribute to the project should be discussed first on our
-[Google Group][groups] or in [GitHub Issues][github-issues] so that we can better coordinate our efforts, prevent
-duplication of work, and help you to craft the change so that it is successfully accepted into the
-project.
-* **Small Changes** can be crafted and submitted to the [GitHub Repository][github] as a Pull Request.
-
-## Submission Guidelines
-
-### Submitting an Issue
-Before you submit your issue search the [GitHub Issues][github-issues] archive,
-maybe your question was already answered.
-
-If your issue appears to be a bug, and hasn't been reported, open a new issue.
-Help us to maximize the effort we can spend fixing issues and adding new
-features, by not reporting duplicate issues. Providing the following information will increase the
-chances of your issue being dealt with quickly:
-
-* **Overview of the Issue** - what type of issue is it, and why is it an issue for you?
-* **Callstack** - if it's a crash or other runtime error, a callstack will help diagnosis
-* **Screenshots** - for navmesh generation problems, a picture really is worth a thousand words.
- Implement `duDebugDraw` and call some methods from DetourDebugDraw.h. Seriously, just do it, we'll definitely ask you to if you haven't!
-* **Logs** - stdout and stderr from the console, or log files if there are any.
- If integrating into your own codebase, be sure to implement the log callbacks in `rcContext`.
-* **Reproduction steps** - a minimal, unambigious set of steps including input, that causes the error for you.
- e.g. input geometry and settings you can use to input into RecastDemo to get it to fail.
- Note: These can be saved by pressing the 9 key in RecastDemo, and the resulting .gset file can be shared (with the .obj if it is not one of the default ones).
-* **Recast version(s) and/or git commit hash** - particularly if you can find the point at which the error first started happening
-* **Environment** - operating system, compiler etc.
-* **Related issues** - has a similar issue been reported before?
-* **Suggest a Fix** - if you can't fix the bug yourself, perhaps you can point to what might be
- causing the problem (line of code or commit)
-
-Here is a great example of a well defined issue: https://github.com/recastnavigation/recastnavigation/issues/12
-
-**If you get help, help others. Good karma rulez!**
-
-### Submitting a Pull Request
-Before you submit your pull request consider the following guidelines:
-
-* Search [GitHub Pull Requests][github-pulls] for an open or closed Pull Request
- that relates to your submission. You don't want to duplicate effort.
-* Make your changes in a new git branch:
-
- ```shell
- git checkout -b my-fix-branch master
- ```
-
-* Implement your changes, **including appropriate tests if appropriate/possible**.
-* Commit your changes using a descriptive commit message that follows our
- [commit message conventions](#commit-message-format).
-
- ```shell
- git commit -a
- ```
- Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files.
-
-* Squash any work-in-progress commits (by rebasing) to form a series of commits that make sense individually.
- Ideally the pull request will be small and focused enough that it fits sensibly in one commit.
-
- ```shell
- git rebase -i origin/master
- ```
-
-* Push your branch to GitHub:
-
- ```shell
- git push origin my-fix-branch
- ```
-
-* In GitHub, send a pull request to `recastnavigation:master`.
-* If we suggest changes then:
- * Make the required updates.
- * Commit your changes to your branch (e.g. `my-fix-branch`).
- * Squash the changes, overwriting history in your fix branch - we don't want history to include incomplete work.
- * Push the changes to your GitHub repository (this will update your Pull Request).
-
-If you have rebased to squash commits together, you will need to force push to update the PR:
-
- ```shell
- git rebase master -i
- git push origin my-fix-branch -f
- ```
-
-That's it! Thank you for your contribution!
-
-#### After your pull request is merged
-
-After your pull request is merged, you can safely delete your branch and pull the changes
-from the main (upstream) repository:
-
-* Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
-
- ```shell
- git push origin --delete my-fix-branch
- ```
-
-* Check out the master branch:
-
- ```shell
- git checkout master -f
- ```
-
-* Delete the local branch:
-
- ```shell
- git branch -D my-fix-branch
- ```
-
-* Update your master with the latest upstream version:
-
- ```shell
- git pull --ff upstream master
- ```
-
-## Git Commit Guidelines
-
-### Commit content
-
-Do your best to factor commits appropriately, i.e not too large with unrelated
-things in the same commit, and not too small with the same small change applied N
-times in N different commits. If there was some accidental reformatting or whitespace
-changes during the course of your commits, please rebase them away before submitting
-the PR.
-
-### Commit Message Format
-Please format commit messages as follows (based on this [excellent post](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)):
-
-```
-Summarize change in 50 characters or less
-
-Provide more detail after the first line. Leave one blank line below the
-summary and wrap all lines at 72 characters or less.
-
-If the change fixes an issue, leave another blank line after the final
-paragraph and indicate which issue is fixed in the specific format
-below.
-
-Fix #42
-```
-
-Important things you should try to include in commit messages include:
-* Motivation for the change
-* Difference from previous behaviour
-* Whether the change alters the public API, or affects existing behaviour significantly
-
-
-
-[code-of-conduct]: http://todogroup.org/opencodeofconduct/#Recastnavigation/b.hymers@gmail.com
-[github]: https://github.com/recastnavigation/recastnavigation
-[github-issues]: https://github.com/recastnavigation/recastnavigation/issues
-[github-pulls]: https://github.com/recastnavigation/recastnavigation/pulls
-[gitter]: https://gitter.im/recastnavigation/chat
-[groups]: https://groups.google.com/forum/?fromgroups#!forum/recastnavigation
diff --git a/extern/recastnavigation/Docs/Conceptual/license_c.txt b/extern/recastnavigation/Docs/Conceptual/license_c.txt
deleted file mode 100644
index c2a3c1e85..000000000
--- a/extern/recastnavigation/Docs/Conceptual/license_c.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-
-/**
-@page License License
-
-
-Copyright (c) 2009-2011 Mikko Mononen memon@inside.org
-
-This software is provided 'as-is', without any express or implied
-warranty. In no event will the authors be held liable for any damages
-arising from the use of this software.
-
-Permission is granted to anyone to use this software for any purpose,
-including commercial applications, and to alter it and redistribute it
-freely, subject to the following restrictions:
-
-1. The origin of this software must not be misrepresented; you must not
- claim that you wrote the original software. If you use this software
- in a product, an acknowledgment in the product documentation would be
- appreciated but is not required.
-
-2. Altered source versions must be plainly marked as such, and must not be
- misrepresented as being the original software.
-
-3. This notice may not be removed or altered from any source distribution.
-
-
-*/
\ No newline at end of file
diff --git a/extern/recastnavigation/Docs/Conceptual/mainpage_c.txt b/extern/recastnavigation/Docs/Conceptual/mainpage_c.txt
deleted file mode 100644
index 14dd1cf8f..000000000
--- a/extern/recastnavigation/Docs/Conceptual/mainpage_c.txt
+++ /dev/null
@@ -1,109 +0,0 @@
-/// @mainpage Recast Navigation
-///
-/// @image html recast_intro.png
-///
-/// Recast
-///
-/// _Recast_ is a state of the art navigation mesh construction toolset for
-/// games.
-///
-/// - It is automatic, which means that you can throw any level
-/// geometry at it and you will get a robust mesh out.
-/// - It is fast, which means swift turnaround times for level designers.
-/// - It is open source, so it comes with full source and you can
-/// customize it to your hearts content.
-///
-/// The latest version can be found on
-/// GitHub.
-///
-/// The _Recast_ process starts with constructing a voxel mold from level
-/// geometry and then casting a navigation mesh over it. The process
-/// consists of three steps: building the voxel mold, partitioning the
-/// mold into simple regions, and triangulating the regions as simple polygons.
-///
-/// -# The voxel mold is built from the input triangle mesh by
-/// rasterizing the triangles into a multi-layer heightfield. Some
-/// simple filters are then applied to the mold to prune out locations
-/// where the character would not be able to move.
-/// -# The walkable areas described by the mold are divided into simple
-/// overlayed 2D regions. The resulting regions have only one
-/// non-overlapping contour, which simplifies the final step of the
-/// process tremendously.
-/// -# The navigation polygons are generated from the regions by first
-/// tracing the boundaries and then simplifying them. The resulting
-/// polygons are finally converted to convex polygons which makes them
-/// perfect for pathfinding and spatial reasoning about the level.
-///
-/// Detour
-///
-/// _Recast_ is accompanied by _Detour_, a path-finding and spatial reasoning
-/// toolkit. You can use any navigation mesh with _Detour_, but of course
-/// the data generated by _Recast_ fits perfectly.
-///
-/// _Detour_ offers a simple static navigation mesh that is suitable for
-/// many simple cases, as well as a tiled navigation mesh that allows you
-/// to add and remove pieces of the mesh. The tiled mesh allows you to
-/// create systems where you stream new navigation data in and out as
-/// the player progresses the level, or regenerate tiles as the
-/// world changes.
-///
-/// Recast Demo
-///
-/// You can find a comprehensive demo project in the `RecastDemo` folder. It
-/// is a kitchen sink demo containing all the major functionality of the library.
-/// If you are new to _Recast_ & _Detour_, check out
-///
-/// Sample_SoloMesh.cpp to get started with building navmeshes and
-///
-/// NavMeshTesterTool.cpp to see how _Detour_ can be used to find paths.
-///
-/// Building RecastDemo
-///
-/// RecastDemo uses [premake5](http://premake.github.io/) to build platform specific projects.
-/// Download it and make sure it's available on your path, or specify the path to it.
-///
-/// Linux
-///
-/// - Install SDl2 and its dependencies according to your distro's guidelines.
-/// - run `premake5 gmake` from the `RecastDemo` folder.
-/// - `cd Build/gmake` then `make`
-/// - Run `RecastDemo\Bin\RecastDemo`
-///
-/// OSX
-///
-/// - Grab the latest SDL2 development library dmg from [here](https://www.libsdl.org/download-2.0.php) and place `SDL2.framework` in `/Library/Frameworks/`
-/// - Navigate to the `RecastDemo` folder and run `premake5 xcode4`
-/// - Open `Build/xcode4/recastnavigation.xcworkspace`
-/// - Select the "RecastDemo" project in the left pane, go to the "BuildPhases" tab and expand "Link Binary With Libraries"
-/// - Remove the existing entry for SDL2 (it should have a white box icon) and re-add it by hitting the plus, selecting "Add Other", and selecting `/Library/Frameworks/SDL2.framework`. It should now have a suitcase icon.
-/// - Set the RecastDemo project as the target and build.
-///
-/// Windows
-///
-/// - Grab the latest SDL2 development library release from [here](https://www.libsdl.org/download-2.0.php) and unzip it `RecastDemo\Contrib`. Rename the SDL folder such that the path `RecastDemo\Contrib\SDL\lib\x86` is valid.
-/// - Run `"premake5" vs2015` from the `RecastDemo` folder
-/// - Open the solution, build, and run.
-///
-/// Integrating With Your Own Project
-///
-/// It is recommended to add the source directories `DebugUtils`, `Detour`,
-/// `DetourCrowd`, `DetourTileCache`, and `Recast` into your own project
-/// depending on which parts of the project you need. For example your
-/// level building tool could include `DebugUtils`, `Recast`, and `Detour`,
-/// and your game runtime could just include `Detour`.
-///
-/// Contributing
-/// All development is centralized in github. Check out the Contributing Guidelines for more information.
-///
-/// Discuss
-///
-/// - Discuss _Recast_ and _Detour_:
-///
-/// Recast Navigation Group
-/// - Development Blog:
-/// Digesting Duck
-///
-/// License
-///
-/// _Recast Navigation_ is licensed under the ZLib license.
-///
diff --git a/extern/recastnavigation/Docs/DoxygenLayout.xml b/extern/recastnavigation/Docs/DoxygenLayout.xml
deleted file mode 100644
index b20079c91..000000000
--- a/extern/recastnavigation/Docs/DoxygenLayout.xml
+++ /dev/null
@@ -1,194 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/extern/recastnavigation/Docs/Extern/Recast_api.txt b/extern/recastnavigation/Docs/Extern/Recast_api.txt
deleted file mode 100644
index f6ff06444..000000000
--- a/extern/recastnavigation/Docs/Extern/Recast_api.txt
+++ /dev/null
@@ -1,587 +0,0 @@
-// This file contains the detail API documentation for
-// elements defined in the Recast.h.
-
-/**
-
-@defgroup recast Recast
-
-Members in this module are used to create mesh data that is then
-used to create Detour navigation meshes.
-
-The are a large number of possible ways to building navigation mesh data.
-One of the simple piplines is as follows:
-
--# Prepare the input triangle mesh.
--# Build a #rcHeightfield.
--# Build a #rcCompactHeightfield.
--# Build a #rcContourSet.
--# Build a #rcPolyMesh.
--# Build a #rcPolyMeshDetail.
--# Use the rcPolyMesh and rcPolyMeshDetail to build a Detour navigation mesh
- tile.
-
-The general life-cycle of the main classes is as follows:
-
--# Allocate the object using the Recast allocator. (E.g. #rcAllocHeightfield)
--# Initialize or build the object. (E.g. #rcCreateHeightfield)
--# Update the object as needed. (E.g. #rcRasterizeTriangles)
--# Use the object as part of the pipeline.
--# Free the object using the Recast allocator. (E.g. #rcFreeHeightField)
-
-@note This is a summary list of members. Use the index or search
-feature to find minor members.
-
-@struct rcConfig
-@par
-
-The is a convenience structure that represents an aggregation of parameters
-used at different stages in the Recast build process. Some
-values are derived during the build process. Not all parameters
-are used for all build processes.
-
-Units are usually in voxels (vx) or world units (wu). The units for voxels,
-grid size, and cell size are all based on the values of #cs and #ch.
-
-In this documentation, the term 'field' refers to heightfield and
-contour data structures that define spacial information using an integer
-grid.
-
-The upper and lower limits for the various parameters often depend on
-the platform's floating point accuraccy as well as interdependencies between
-the values of multiple parameters. See the individual parameter
-documentation for details.
-
-@var rcConfig::borderSize
-@par
-
-This value represents the the closest the walkable area of the heightfield
-should come to the xz-plane AABB of the field. It does not have any
-impact on the borders around internal obstructions.
-
-@var rcConfig::tileSize
-@par
-
-This field is only used when building multi-tile meshes.
-
-@var rcConfig::cs
-@par
-
-@p cs and #ch define voxel/grid/cell size. So their values have significant
-side effects on all parameters defined in voxel units.
-
-The minimum value for this parameter depends on the platform's floating point
-accuracy, with the practical minimum usually around 0.05.
-
-@var rcConfig::ch
-@par
-
-#cs and @p ch define voxel/grid/cell size. So their values have significant
-side effects on all parameters defined in voxel units.
-
-The minimum value for this parameter depends on the platform's floating point
-accuracy, with the practical minimum usually around 0.05.
-
-@var rcConfig::walkableSlopeAngle
-@par
-
-The practical upper limit for this parameter is usually around 85 degrees.
-
-@var rcConfig::walkableHeight
-@par
-
-Permits detection of overhangs in the source geometry that make the geometry
-below un-walkable. The value is usually set to the maximum agent height.
-
-@var rcConfig::walkableClimb
-@par
-
-Allows the mesh to flow over low lying obstructions such as curbs and
-up/down stairways. The value is usually set to how far up/down an agent can step.
-
-@var rcConfig::walkableRadius
-@par
-
-In general, this is the closest any part of the final mesh should get to an
-obstruction in the source geometry. It is usually set to the maximum
-agent radius.
-
-While a value of zero is legal, it is not recommended and can result in
-odd edge case issues.
-
-@var rcConfig::maxEdgeLen
-@par
-
-Extra vertices will be inserted as needed to keep contour edges below this
-length. A value of zero effectively disables this feature.
-
-@var rcConfig::maxSimplificationError
-@par
-
-The effect of this parameter only applies to the xz-plane.
-
-@var rcConfig::minRegionArea
-@par
-
-Any regions that are smaller than this area will be marked as unwalkable.
-This is useful in removing useless regions that can sometimes form on
-geometry such as table tops, box tops, etc.
-
-@var rcConfig::maxVertsPerPoly
-@par
-
-If the mesh data is to be used to construct a Detour navigation mesh, then the upper limit
-is limited to <= #DT_VERTS_PER_POLYGON.
-
-
-@struct rcHeightfield
-@par
-
-The grid of a heightfield is layed out on the xz-plane based on the
-value of #cs. Spans exist within the grid columns with the span
-min/max values at increments of #ch from the base of the grid. The smallest
-possible span size is (#cs width) * (#cs depth) * (#ch height). (Which is a single voxel.)
-
-The standard process for buidling a heightfield is to allocate it using
-#rcAllocHeightfield, initialize it using #rcCreateHeightfield, then
-add spans using the various helper functions such as #rcRasterizeTriangle.
-
-Building a heightfield is one of the first steps in creating a polygon mesh
-from source geometry. After it is populated, it is used to build a
-rcCompactHeightfield.
-
-Example of iterating the spans in a heightfield:
-@code
-// Where hf is a reference to an heightfield object.
-
-const float* orig = hf.bmin;
-const float cs = hf.cs;
-const float ch = hf.ch;
-
-const int w = hf.width;
-const int h = hf.height;
-
-for (int y = 0; y < h; ++y)
-{
- for (int x = 0; x < w; ++x)
- {
- // Deriving the minimum corner of the grid location.
- float fx = orig[0] + x*cs;
- float fz = orig[2] + y*cs;
- // The base span in the column. (May be null.)
- const rcSpan* s = hf.spans[x + y*w];
- while (s)
- {
- // Detriving the minium and maximum world position of the span.
- float fymin = orig[1]+s->smin*ch;
- float fymax = orig[1] + s->smax*ch;
- // Do other things with the span before moving up the column.
- s = s->next;
- }
- }
-}
-@endcode
-
-@see rcAllocHeightfield, rcFreeHeightField, rcCreateHeightfield
-
-@struct rcCompactCell
-@par
-
-See the rcCompactHeightfield documentation for an example of how compact cells
-are used to iterate the heightfield.
-
-Useful instances of this type can only by obtained from a #rcCompactHeightfield object.
-
-@see rcCompactHeightfield
-
-@struct rcCompactSpan
-@par
-
-The span represents open, unobstructed space within a compact heightfield column.
-See the rcCompactHeightfield documentation for an example of iterating spans and searching
-span connections.
-
-Useful instances of this type can only by obtained from a #rcCompactHeightfield object.
-
-@see rcCompactHeightfield
-
-
-@struct rcCompactHeightfield
-@par
-
-For this type of heightfield, the spans represent the open (unobstructed)
-space above the solid surfaces of a voxel field. It is usually created from
-a #rcHeightfield object. Data is stored in a compact, efficient manner,
-but the structure is not condusive to adding and removing spans.
-
-The standard process for buidling a compact heightfield is to allocate it
-using #rcAllocCompactHeightfield, build it using #rcBuildCompactHeightfield,
-then run it through the various helper functions to generate neighbor
-and region data.
-
-Connected neighbor spans form non-overlapping surfaces. When neighbor
-information is generated, spans will include data that can be used to
-locate axis-neighbors. Axis-neighbors are connected
-spans that are offset from the current cell column as follows:
-
-Direction 0 = (-1, 0)
-Direction 1 = (0, 1)
-Direction 2 = (1, 0)
-Direction 3 = (0, -1)
-
-
-Example of iterating and inspecting spans, including connected neighbors:
-
-@code
-// Where chf is an instance of a rcCompactHeightfield.
-
-const float cs = chf.cs;
-const float ch = chf.ch;
-
-for (int y = 0; y < chf.height; ++y)
-{
- for (int x = 0; x < chf.width; ++x)
- {
- // Deriving the minimum corner of the grid location.
- const float fx = chf.bmin[0] + x*cs;
- const float fz = chf.bmin[2] + y*cs;
-
- // Get the cell for the grid location then iterate
- // up the column.
- const rcCompactCell& c = chf.cells[x+y*chf.width];
- for (unsigned i = c.index, ni = c.index+c.count; i < ni; ++i)
- {
- const rcCompactSpan& s = chf.spans[i];
-
- Deriving the minimum (floor) of the span.
- const float fy = chf.bmin[1] + (s.y+1)*ch;
-
- // Testing the area assignment of the span.
- if (chf.areas[i] == RC_WALKABLE_AREA)
- {
- // The span is in the default 'walkable area'.
- }
- else if (chf.areas[i] == RC_NULL_AREA)
- {
- // The surface is not considered walkable.
- // E.g. It was filtered out during the build processes.
- }
- else
- {
- // Do something. (Only applicable for custom build
- // build processes.)
- }
-
- // Iterating the connected axis-neighbor spans.
- for (int dir = 0; dir < 4; ++dir)
- {
- if (rcGetCon(s, dir) != RC_NOT_CONNECTED)
- {
- // There is a neighbor in this direction.
- const int nx = x + rcGetDirOffsetX(dir);
- const int ny = y + rcGetDirOffsetY(dir);
- const int ni = (int)chf.cells[nx+ny*w].index + rcGetCon(s, 0);
- const rcCompactSpan& ns = chf.spans[ni];
- // Do something with the neighbor span.
- }
- }
- }
- }
-}
-@endcode
-
-@see rcAllocCompactHeightfield, rcFreeCompactHeightfield, rcBuildCompactHeightfield
-
-@struct rcContour
-@par
-
-A contour only exists within the context of a #rcContourSet object.
-
-While the height of the contour's border may vary, the contour will always
-form a simple polygon when projected onto the xz-plane.
-
-Example of converting vertices into world space:
-
-@code
-// Where cset is the rcContourSet object to which the contour belongs.
-float worldX = cset.bmin[0] + vertX * cset.cs;
-float worldY = cset.bmin[1] + vertY * cset.ch;
-float worldZ = cset.bmin[2] + vertZ * cset.cs;
-@endcode
-
-@see rcContourSet
-
-@var rcContour::verts
-@par
-
-The simplified contour is a version of the raw contour with all
-'unnecessary' vertices removed. Whether a vertex is
-considered unnecessary depends on the contour build process.
-
-The data format is as follows: (x, y, z, r) * #nverts
-
-A contour edge is formed by the current and next vertex. The r-value
-represents region and connection information for the edge. For example:
-
-@code
-int r = verts[i*4+3];
-
-int regionId = r & RC_CONTOUR_REG_MASK;
-
-if (r & RC_BORDER_VERTEX)
-{
- // The edge represents a solid border.
-}
-
-if (r & RC_AREA_BORDER)
-{
- // The edge represents a transition between different areas.
-}
-@endcode
-
-@var rcContour::rverts
-@par
-
-See #verts for information on element layout.
-
-@struct rcContourSet
-@par
-
-All contours within the set share the minimum bounds and cell sizes of the set.
-
-The standard process for building a contour set is to allocate it
-using #rcAllocContourSet, then initialize it using #rcBuildContours.
-
-@see rcAllocContourSet, rcFreeContourSet, rcBuildContours
-
-@struct rcPolyMesh
-@par
-
-A mesh of potentially overlapping convex polygons of between three
-and #nvp vertices. The mesh exists within the context of an axis-aligned
-bounding box (AABB) with vertices laid out in an evenly spaced grid, based
-on the values of #cs and #ch.
-
-The standard process for building a contour set is to allocate it using
-#rcAllocPolyMesh, the initialize it using #rcBuildPolyMesh
-
-Example of iterating the polygons:
-
-@code
-// Where mesh is a reference to a rcPolyMesh object.
-
-const int nvp = mesh.nvp;
-const float cs = mesh.cs;
-const float ch = mesh.ch;
-const float* orig = mesh.bmin;
-
-for (int i = 0; i < mesh.npolys; ++i)
-{
- const unsigned short* p = &mesh.polys[i*nvp*2];
-
- // Iterate the vertices.
- unsigned short vi[3]; // The vertex indices.
- for (int j = 0; j < nvp; ++j)
- {
- if (p[j] == RC_MESH_NULL_IDX)
- break; // End of vertices.
-
- if (p[j + nvp] == RC_MESH_NULL_IDX)
- {
- // The edge beginning with this vertex is a solid border.
- }
- else
- {
- // The edge beginning with this vertex connects to
- // polygon p[j + nvp].
- }
-
- // Convert to world space.
- const unsigned short* v = &mesh.verts[p[j]*3];
- const float x = orig[0] + v[0]*cs;
- const float y = orig[1] + v[1]*ch;
- const float z = orig[2] + v[2]*cs;
- // Do something with the vertices.
- }
-}
-@endcode
-
-@see rcAllocPolyMesh, rcFreePolyMesh, rcBuildPolyMesh
-
-@var rcPolyMesh::verts
-@par
-
-The values of #bmin ,#cs, and #ch are used to convert vertex coordinates
-to world space as follows:
-
-@code
-float worldX = bmin[0] + verts[i*3+0] * cs
-float worldY = bmin[1] + verts[i*3+1] * ch
-float worldZ = bmin[2] + verts[i*3+2] * cs
-@endcode
-
-@var rcPolyMesh::polys
-@par
-
-Each entry is 2 * #nvp in length. The first half of the entry
-contains the indices of the polygon. The first instance of #RC_MESH_NULL_IDX
-indicates the end of the indices for the entry. The second half contains
-indices to neighbor polygons. A value of #RC_MESH_NULL_IDX indicates no
-connection for the associated edge. (I.e. The edge is a solid border.)
-
-For example:
-
-nvp = 6
-For the entry: (1, 3, 4, 8, RC_MESH_NULL_IDX, RC_MESH_NULL_IDX,
- 18, RC_MESH_NULL_IDX , 21, RC_MESH_NULL_IDX, RC_MESH_NULL_IDX, RC_MESH_NULL_IDX)
-
-(1, 3, 4, 8) defines a polygon with 4 vertices.
-Edge 1->3 is shared with polygon 18.
-Edge 4->8 is shared with polygon 21.
-Edges 3->4 and 4->8 are border edges not shared with any other polygon.
-
-
-@var rcPolyMesh::areas
-@par
-
-The standard build process assigns the value of #RC_WALKABLE_AREA to all walkable polygons.
-This value can then be changed to meet user requirements.
-
-@struct rcPolyMeshDetail
-@par
-
-The detail mesh is made up of triangle sub-meshes that provide extra
-height detail for each polygon in its assoicated polygon mesh.
-
-The standard process for building a detail mesh is to allocate it
-using #rcAllocPolyMeshDetail, then build it using #rcBuildPolyMeshDetail.
-
-See the individual field definitions for details realted to the structure
-the mesh.
-
-@see rcAllocPolyMeshDetail, rcFreePolyMeshDetail, rcBuildPolyMeshDetail, rcPolyMesh
-
-@var rcPolyMeshDetail::meshes
-@par
-
-[(baseVertIndex, vertCount, baseTriIndex, triCount) * #nmeshes]
-
-Maximum number of vertices per sub-mesh: 127
-Maximum number of triangles per sub-mesh: 255
-
-The sub-meshes are stored in the same order as the polygons from the
-rcPolyMesh they represent. E.g. rcPolyMeshDetail sub-mesh 5 is associated
-with #rcPolyMesh polygon 5.
-
-Example of iterating the triangles in a sub-mesh.
-
-@code
-// Where dmesh is a reference to a rcPolyMeshDetail object.
-
-// Iterate the sub-meshes. (One for each source polygon.)
-for (int i = 0; i < dmesh.nmeshes; ++i)
-{
- const unsigned int* meshDef = &dmesh.meshes[i*4];
- const unsigned int baseVerts = meshDef[0];
- const unsigned int baseTri = meshDef[2];
- const int ntris = (int)meshDef[3];
-
- const float* verts = &dmesh.verts[baseVerts*3];
- const unsigned char* tris = &dmesh.tris[baseTri*4];
-
- // Iterate the sub-mesh's triangles.
- for (int j = 0; j < ntris; ++j)
- {
- const float x = verts[tris[j*4+0]*3];
- const float y = verts[tris[j*4+1]*3];
- const float z = verts[tris[j*4+2]*3];
- // Do something with the vertex.
- }
-}
-@endcode
-
-@var rcPolyMeshDetail::verts
-@par
-
-[(x, y, z) * #nverts]
-
-The vertices are grouped by sub-mesh and will contain duplicates since
-each sub-mesh is independently defined.
-
-The first group of vertices for each sub-mesh are in the same order as
-the vertices for the sub-mesh's associated PolyMesh polygon. These
-vertices are followed by any additional detail vertices. So it the
-associated polygon has 5 vertices, the sub-mesh will have a minimum
-of 5 vertices and the first 5 vertices will be equivalent to the 5
-polygon vertices.
-
-@var rcPolyMeshDetail::tris
-@par
-
-[(vertIndexA, vertIndexB, vertIndexC, flags) * #ntris]
-
-The triangles are grouped by sub-mesh.
-
-Vertex Indices
-
-The vertex indices in the triangle array are local to the sub-mesh, not global.
-To translate into an global index in the vertices array, the values must be
-offset by the sub-mesh's base vertex index.
-
-Example: If the baseVertexIndex for the sub-mesh is 5 and the triangle entry
-is (4, 8, 7, 0), then the actual indices for the vertices are (4 + 5, 8 + 5, 7 + 5).
-
-@b Flags
-
-The flags entry indicates which edges are internal and which are external to
-the sub-mesh. Internal edges connect to other triangles within the same sub-mesh.
-External edges represent portals to other sub-meshes or the null region.
-
-Each flag is stored in a 2-bit position. Where position 0 is the lowest 2-bits
-and position 4 is the highest 2-bits:
-
-
-Position 0: Edge AB (>> 0)
-Position 1: Edge BC (>> 2)
-Position 2: Edge CA (>> 4)
-Position 4: Unused
-
-
-Testing can be performed as follows:
-
-@code
-if (((flags >> 2) & 0x3) != 0)
-{
- // Edge BC is an external edge.
-}
-@endcode
-
-@fn void rcSetCon(rcCompactSpan &s, int dir, int i)
-@par
-
-This function is used by the build process. It is rarely of use to end users.
-
-@see #rcCompactHeightfield, #rcCompactSpan
-
-@fn int rcGetCon(const rcCompactSpan &s, int dir)
-@par
-
-Can be used to locate neighbor spans in a compact heightfield. See the
-#rcCompactHeightfield documentation for details on its use.
-
-@see #rcCompactHeightfield, #rcCompactSpan
-
-@fn int rcGetDirOffsetX(int dir)
-@par
-
-The value of @p dir will be automatically wrapped. So a value of 6 will be interpreted as 2.
-
-See the #rcCompactHeightfield documentation for usage details.
-
-@fn int rcGetDirOffsetY(int dir)
-@par
-
-The value of @p dir will be automatically wrapped. So a value of 6 will be interpreted as 2.
-
-See the #rcCompactHeightfield documentation for usage details.
-
-*/
diff --git a/extern/recastnavigation/Docs/Images/recast_intro.png b/extern/recastnavigation/Docs/Images/recast_intro.png
deleted file mode 100644
index ad18ac610..000000000
Binary files a/extern/recastnavigation/Docs/Images/recast_intro.png and /dev/null differ
diff --git a/extern/recastnavigation/Docs/Readme.txt b/extern/recastnavigation/Docs/Readme.txt
deleted file mode 100644
index be153b94b..000000000
--- a/extern/recastnavigation/Docs/Readme.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-This directory contains source for the documentation. It is also the
-build target for doxygen output.
-
-Directory Layout
-
-. (Docs root)
-
- High level content and format files. (E.g. css, header, footer.)
-
-./Conceptual
-
- Conceptual (non-api) documentation such as overviews, how-to's, etc.
- The main index page content is also in this directory.
-
-./Extern
-
- API documentation that is located outside the source files.
-
- When the API documentation gets too big or complex for the header
- and source files, it goes in this directory.
-
-./Images
-
- Images related to the documentation.
-
-./html
-
- The target for the Doxygen build. (Created during the build process.)
-
-Miscellany
-
-One of the requirements for the API documentation is that it
-has the minimum possible impact on the declarations in the
-header files. So, in general, the header file declarations only
-contain summary documentation. The detail documentation
-is placed as follows:
-
-1. If an element is defined in a cpp file, then place
- the detail documentation in the source file.
-2. If an element does not have an associated cpp file, then
- place the detail documentation at the end of the header file.
-3. If there is a lot of detail documentation cluttering up
- the end of a header file, then the content is moved to
- a separate file in the Extern directory.
-
-Building the Documentation
-
-1. Download and install the appropriate Doxygen version. (See the first
- line in the Doxyfile for the current version.)
-2. Run "doxygen" in the project root directory. (The location of the Doxyfile.)
- No arguments are required.
-
-The generated html files will be located in the /Docs/html directory.
-
-If you want to "version" the documentation, you can set the PROJECT_NUMBER
-setting in the Doxyfile. E.g. PROJECT_NUMBER = "(2014-04-23)". The project
-number will be added to the header of the documentation.
-E.g. "Recast Navigation (2014-04-23)"
-
-
-
-
-
-
diff --git a/extern/recastnavigation/Docs/footer.html b/extern/recastnavigation/Docs/footer.html
deleted file mode 100644
index 5bd570ad1..000000000
--- a/extern/recastnavigation/Docs/footer.html
+++ /dev/null
@@ -1,21 +0,0 @@
-
-
-
-
-
-
-
-
-
-