Tile can be present in either mPushed (waiting in a queue), mProcessingTiles (
being processed or waiting in db queue), mPresentTiles (added to navmesh). It's
not enough to walk over mPushed tiles to find all not present. Need also to
check mProcessingTiles.
Otherwise if all tiles are in mProcessingTiles only
waitUntilJobsDoneForNotPresentTiles may return too early because there are none
in mPushed and therefore none tiles are considered to be absent on navmesh which
is not true.
Primarily for crossing cell border case. Each Navigator::update call has a cost.
Doing it multiple times per frame increased frame duration on cell loading.
Call Navigator::wait only when cell has changed but do not use
Scene::hasCellChanged because it doesn't always indicates it.
Actors may have different collision shapes. Currently there are axis-aligned
bounding boxes and rotating bounding boxes. With AABB it's required to use
bounding cylinder for navmesh agent to avoid providing paths where actor can't
pass. But for rotating bounding boxes cylinder with diameter equal to the front
face width should be used to not reduce of available paths. For example rats
have rotating bounding box as collision shape because of the difference between
front and side faces width.
* Add agent bounds to navmesh tile db cache key. This is required to distinguish
tiles for agents with different bounds.
* Increase navmesh version because navmesh tile db cache key and data has changed.
* Move navmesh version to the code to avoid misconfiguration by users.
* Fix all places where wrong half extents were used for pathfinding.
Simultaneously writing to sqlite3 database is not possible. Process exclusively
locks the database for this. Another process will fail to perform any request
when database is locked. Alternatively it can wait. Handling this situation
properly requires complexity that is not really needed. Users are not expected
to run multiple openmw processes simultaneously using the same navmeshdb.
Before this change running multiple openmw processes using the same navmeshdb
can lead to a crash when first transaction fails to start because there is
exception thrown and not catched.
Remove use of explicit transactions from DbWorker. Handling all possible
transaction states due to different errors brings unnecessary complexity.
Initially they were introduced to increase time between flushes to disk. This
makes sense for navmeshtool because of massive number of writes but for the
engine this is not an issue.
Use "pragma max_page_count" to define max allowed file size in combination with
"pragma page_size" based on a new setting "max navmeshdb file size".
* Stop navmeshtool on the first db error.
* Disable writes to db in the engine on first "database or disk is full"
SQLite3 error. There is no special error code for this error.
* Change default "write to navmeshdb" to true.
* Use time intervals for transaction duration instead of number of changes.
Perform all request to db in a single thread to avoid blocking navmesh
generator threads due to slow write operations.
Write to db navmesh for all changes except update as it done for memory cache.
Batch multiple db operations into a single transaction to speed up writing by
not executing fsync after each insert/update query. All reads are performed in
the same transaction so they see uncommited data.
* Change job change type to remove when tile is outside allowed range.
* Swap try number and change type in job priority. To make sure remove jobs
always processed before any other.
This saves cache capacity when a scene contains objects contantly transforming
by scripts and causing changes in navmesh. The probability to get cache hit for
such states is almost zero because even a constant change in a single float
value may give up to 2^32 different states.
When player tile changes distance to player that is part of jobs priority is
invalidated. So jobs are no longer in the right order. This can lead to
processing of farests tiles first.
Sort queue each time player tile is changed.
Add special loading progress bar.
It should be fast enough to not keep loading screen for noticably long but
will provide better pathfinding for actors inside interior cells.
To avoid triggering NavMesh update when RecastMesh change should not change
NavMesh.
Based on the following assumption:
Given a set of transformations and a bounding shape for all these
tranformations, a new object transformation that does not change this
bounding shape also should not change navmesh if for all of this object
transformations resulting navmesh tiles are equivalent
The idea is to report back to RecastMeshManager all changes of NavMesh if there
are any assiciated with RecastMesh version. So we know the last time when
RecastMesh change resulted into the NavMesh change. When later report shows
that there was no NavMesh change for a new RecastMesh version we can assume
that any object transformation within the same bounding box should not change
NavMesh.
