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.
Actors with disabled collisions still have physics simulations. Assuming they
should not be processed at all instead of disabling collision add a new flag to
make them inactive.
Actor::getOnGround and Actor::getOnSlope is used to initialize ActorFrameData.
After a physics simulation the result is copied back. But when actor is outside
processing range, Actor::mInternalCollisionMode is false and physics simulation
does not recalculate OnGround and OnSlope flags. So the flags are always set to
false that makes actor play landing animation when they exit and then enter
actors processing range.
In file included from /home/elsid/dev/openmw/apps/openmw/mwphysics/actor.hpp:7,
from /home/elsid/dev/openmw/apps/openmw/mwphysics/trace.cpp:9:
/home/elsid/dev/openmw/apps/openmw/mwphysics/ptrholder.hpp: In member function ‘osg::Vec3f MWPhysics::PtrHolder::velocity()’:
/home/elsid/dev/openmw/apps/openmw/mwphysics/ptrholder.hpp:42:25: error: ‘exchange’ is not a member of ‘std’
42 | return std::exchange(mVelocity, osg::Vec3f());
| ^~~~~~~~
Engine controls lifetime of managers therefore it should own them. Environment
is only access provider.
This allows to avoid redundant virtual calls and also some functions from
managers base classes can be removed if they are used only by Engine.
Lock Simulation weak_ptr in all visitors to avoid use after free.
And swap order for weak_ptr locking with locking collision world mutex to avoid
deadlock when underlying object tries to lock the same mutex in the destructor.
Add SimulationImpl type to avoid use of FrameData without locking weak_ptr.
- properly initialize mSimulationPosition in the constructor. Unlucky thread scheduling can cause processHits to be called before the first simulation run, causing the projectile to vanish to whatever value the variable happens to contains.
- don't continue moving the projectile after a hit. The position would continue to be updated to some senseless value.
1. Reorder unlock and notify_all calls to avoid notifying when not all worker
threads are waiting.
2. Make sure main thread does not attempt to exclusively lock mSimulationMutex
while not all workers are done with previous frame.
3. Replace mNewFrame flag by counter to avoid modification from multiple
threads.
1) As much as I dislike it, upping the collision margin from 0.1 to 0.2
fixes bugs, particularly involving walking into upwards-slanted walls.
2) There were still some problems involving acute crevices/seams; they
were using the adjusted instead of unadjusted normal, and also they need
to bypass the don't-slide-upwards check to prevent (see #6379)
3) The move-away-from-what-we-just-hit code needs to run always, not
just on non-initial iterations. No idea why I did it this way before.
4) Force bullet to give actor boxes a tiny collision margin of 0.001
instead of the default 0.04. I can't tell whether this is actually
working or not, but it should reduce unexplained weirdness.
5) A piece of code that was meant to prevent bugs by short-circuiting
the movement solver if its direction changed more than 180 degrees
actually caused problems instead of preventing them, so I deleted it.
Previous version skipped collision the frame immediately after a call to SetPos. It worked for one-off calls (teleports for instance) and continuous call along a pre-defined path (scenic travel). However, in the case of mod which uses SetPos to simulate a player-controlled movement, it is equivalent to using tcl.
Solution:
1/ skip update of mPosition and mPreviousPosition to avoid janky interpolation
2/ use back plain moveObject() instead of moveObjectBy() since we don't want physics simulation
3/ rework a little bit waterwalking influence on coordinate because of 1/
