- 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/
Currently, we use an `UnrefQueue` which supposedly aims to transfer destruction costs to another thread. The implications of this unusual pattern can not be well understood because some allocators might free resources more efficiently if they are freed by the same thread that allocated them. In addition, `UnrefQueue` complicates the validation of thread safety in our engine. Lastly, our current usage of `UnrefQueue` triggers `ref()`, `unref()` atomic operations as objects are passed into the queue. These operations could be more expensive than the actual destruction.
With this PR we thus remove `UnrefQueue`. We can expect these changes to have a minor impact at most because we free most resources elsewhere in `ResourceSystem::updateCache`.
==16218== Conditional jump or move depends on uninitialised value(s)
==16218== at 0xCDBC27: MWPhysics::Object::commitPositionChange() (object.cpp:68)
==16218== by 0xCE5B64: MWPhysics::PhysicsTaskScheduler::updatePtrAabb(std::shared_ptr<MWPhysics::PtrHolder> const&) (mtphysics.cpp:446)
==16218== by 0xCE5CC3: operator() (mtphysics.cpp:432)
==16218== by 0xCE5CC3: for_each<std::_Rb_tree_const_iterator<std::shared_ptr<MWPhysics::PtrHolder> >, MWPhysics::PhysicsTaskScheduler::updateAabbs()::<lambda(const std::shared_ptr<MWPhysics::PtrHolder>&)> > (stl_algo.h:3820)
==16218== by 0xCE5CC3: MWPhysics::PhysicsTaskScheduler::updateAabbs() (mtphysics.cpp:431)
==16218== by 0xCE5E35: MWPhysics::PhysicsTaskScheduler::afterPreStep() (mtphysics.cpp:586)
==16218== by 0xCE6238: operator() (mtphysics.cpp:533)
==16218== by 0xCE6238: wait<MWPhysics::PhysicsTaskScheduler::doSimulation()::<lambda()> > (barrier.hpp:33)
==16218== by 0xCE6238: MWPhysics::PhysicsTaskScheduler::doSimulation() (mtphysics.cpp:533)
==16218== by 0xCE6377: MWPhysics::PhysicsTaskScheduler::worker() (mtphysics.cpp:464)
==16218== by 0x74523C3: execute_native_thread_routine (thread.cc:82)
==16218== by 0x76FF258: start_thread (in /usr/lib/libpthread-2.33.so)
==16218== by 0x78155E2: clone (in /usr/lib/libc-2.33.so)
==16218==
==16218== Conditional jump or move depends on uninitialised value(s)
==16218== at 0xCDBC30: MWPhysics::Object::commitPositionChange() (object.cpp:73)
==16218== by 0xCE5B64: MWPhysics::PhysicsTaskScheduler::updatePtrAabb(std::shared_ptr<MWPhysics::PtrHolder> const&) (mtphysics.cpp:446)
==16218== by 0xCE5CC3: operator() (mtphysics.cpp:432)
==16218== by 0xCE5CC3: for_each<std::_Rb_tree_const_iterator<std::shared_ptr<MWPhysics::PtrHolder> >, MWPhysics::PhysicsTaskScheduler::updateAabbs()::<lambda(const std::shared_ptr<MWPhysics::PtrHolder>&)> > (stl_algo.h:3820)
==16218== by 0xCE5CC3: MWPhysics::PhysicsTaskScheduler::updateAabbs() (mtphysics.cpp:431)
==16218== by 0xCE5E35: MWPhysics::PhysicsTaskScheduler::afterPreStep() (mtphysics.cpp:586)
==16218== by 0xCE6238: operator() (mtphysics.cpp:533)
==16218== by 0xCE6238: wait<MWPhysics::PhysicsTaskScheduler::doSimulation()::<lambda()> > (barrier.hpp:33)
==16218== by 0xCE6238: MWPhysics::PhysicsTaskScheduler::doSimulation() (mtphysics.cpp:533)
==16218== by 0xCE6377: MWPhysics::PhysicsTaskScheduler::worker() (mtphysics.cpp:464)
==16218== by 0x74523C3: execute_native_thread_routine (thread.cc:82)
==16218== by 0x76FF258: start_thread (in /usr/lib/libpthread-2.33.so)
==16218== by 0x78155E2: clone (in /usr/lib/libc-2.33.so)
==16218==
To reduce amount of computations on the caller side and restrict possible
values.
* verts can't be non-int because it's a number of things.
* worldsize is initially defined as int by ESM::Land::REAL_SIZE.
* Put function to calculate heightfied shift into components to be able to
reuse by other binaries.
This is the value used by vanilla Morrowind engine. At this angle player
character starts sliding down the slope.
This fixes navigation and movement issue in Mournhold, Godsreach.
Use faster aabbTest but without destance filter. To avoid dependency on a
specific constant and correctly handle situations when there is a big
difference between actors sizes.
Simple Physics API modification for Lua
See merge request OpenMW/openmw!1216
(cherry picked from commit d88494c90b501d0832ae0330a0ca81d8b8e5aa50)
02dd055a Save hitObject in castSphere() just like in castRay()
0793d0bf Allow to override collision mask and group for castSphere() as for castRay()
- enchanted arrow explode upon hit the water plane
- non enchanted arrow disappear (or more accurately, they hit nothingness)
- enchanted arrow shot underwater explode immediately
- non enchanted arrow disappear immediately
Also, solve a bug that occured previously and could theoritically still happens where we use the last tested collision position for instead of the last registered hit:
Use the hit position as saved inside Projectile::hit() instead of the last position saved inside the callback.
If a projectile collides with several objects (bottom of the sea and water surface for instance), the last collision tested won't necessarily be the impact position as we have no control over the order in which the tests are performed.
simulation
The purpose of weak_ptr is to avoid performing the simulation on deleted
Actor by promoting it to a shared_ptr via a lock() call. This clutter
the code with a lot of branches, whereas the overwhelmingly common case is for the call to succeed.
Since the simulation is decoupled from the engine state, we can use a shared_ptr instead of a weak_ptr.
This allow us to ignore (ie not handle) the rarer case where the actor is delete from the scene. This means that the simulation
will run for one frame more than before for each actor, whereas the rest of the engine
will be ignorant of this.
