Since actors can be active in 3x3 grid around the player, we need to
first load all objects in a 5x5 grid around the player.
Split load and unloading in 2 phases. Add an mInactiveCells set into the
scene, which contains all cells inside the aforementioned 5x5 grid.
These cells contains only heightfields and non-animated physics objects.
Animated objects are tied to the scene graph, which doesn't exists yet
in these cells, so we skip them.
Actor's position can be determined in 3 ways:
1/ as a result of physics simulation
2/ after a script require a relative position change (SetPos, Move)
3/ absolutely set from games mechanics event (teleport) or script
(PositionCell)
In case 1/, RefData::mPosition is updated with the physics simulation result
In case 2/, when RefData::mPosition is updated, physics simulation is informed of the change and update accordingly
In case 3/, when RefData::mPosition is updated, the physics simulation state is reset
In all 3 cases, we don't need to check the RefData::mPosition to get a
correct behaviour.
TSAN reported the following data race:
Read of size 4 at 0x7b50005b75b0 by thread T12 (mutexes: write M656173, write M84859534346343880):
#0 ESM::Position::asVec3() const /build/openmw/openmw/master2/.build/freebsd/TSAN/../../.././components/esm/defs.hpp:55:27 (openmw+0xb809d5)
#1 MWPhysics::Actor::updateWorldPosition() /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwphysics/actor.cpp:131:59 (openmw+0xb809d5)
#2 MWPhysics::Actor::setPosition(osg::Vec3f const&) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwphysics/actor.cpp:177:5 (openmw+0xb809d5)
#3 MWPhysics::PhysicsTaskScheduler::updateActorsPositions() /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwphysics/mtphysics.cpp:524:28 (openmw+0xb91ac0)
#4 MWPhysics::PhysicsTaskScheduler::afterPostStep() /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwphysics/mtphysics.cpp:614:13 (openmw+0xb915e7)
#5 MWPhysics::PhysicsTaskScheduler::worker()::$_5::operator()() const /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwphysics/mtphysics.cpp:498:45 (openmw+0xb915e7)
#6 void Misc::Barrier::wait<MWPhysics::PhysicsTaskScheduler::worker()::$_5>(MWPhysics::PhysicsTaskScheduler::worker()::$_5&&) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../.././components/misc/barrier.hpp:30:21 (openmw+0xb915e7)
#7 MWPhysics::PhysicsTaskScheduler::worker() /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwphysics/mtphysics.cpp:498:31 (openmw+0xb915e7)
#8 MWPhysics::PhysicsTaskScheduler::PhysicsTaskScheduler(float, btCollisionWorld*, MWRender::DebugDrawer*)::$_0::operator()() const /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwphysics/mtphysics.cpp:162:45 (openmw+0xb92630)
#9 decltype(std::__1::forward<MWPhysics::PhysicsTaskScheduler::PhysicsTaskScheduler(float, btCollisionWorld*, MWRender::DebugDrawer*)::$_0>(fp)()) std::__1::__invoke<MWPhysics::PhysicsTaskScheduler::PhysicsTaskScheduler(float, btCollisionWorld*, MWRender::DebugDrawer*)::$_0>(MWPhysics::PhysicsTaskScheduler::PhysicsTaskScheduler(float, btCollisionWorld*, MWRender::DebugDrawer*)::$_0&&) /usr/include/c++/v1/type_traits:3899:1 (openmw+0xb92630)
#10 void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, MWPhysics::PhysicsTaskScheduler::PhysicsTaskScheduler(float, btCollisionWorld*, MWRender::DebugDrawer*)::$_0>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, MWPhysics::PhysicsTaskScheduler::PhysicsTaskScheduler(float, btCollisionWorld*, MWRender::DebugDrawer*)::$_0>&, std::__1::__tuple_indices<>) /usr/include/c++/v1/thread:280:5 (openmw+0xb92630)
#11 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, MWPhysics::PhysicsTaskScheduler::PhysicsTaskScheduler(float, btCollisionWorld*, MWRender::DebugDrawer*)::$_0> >(void*) /usr/include/c++/v1/thread:291:5 (openmw+0xb92630)
Previous write of size 8 at 0x7b50005b75b0 by main thread:
#0 memcpy /wrkdirs/usr/ports/devel/llvm-devel/work-default/llvm-project-3f6753efe1990a928ed120bd907940a9fb3e2fc3/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:827:5 (openmw+0x55a057)
#1 MWWorld::RefData::setPosition(ESM::Position const&) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwworld/refdata.cpp:216:19 (openmw+0xa3de1c)
#2 MWWorld::World::moveObject(MWWorld::Ptr const&, MWWorld::CellStore*, float, float, float, bool) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwworld/worldimp.cpp:1130:26 (openmw+0xa57300)
#3 MWWorld::World::moveObject(MWWorld::Ptr const&, float, float, float, bool, bool) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwworld/worldimp.cpp:1253:16 (openmw+0xa580c8)
#4 MWWorld::World::doPhysics(float, unsigned long long, unsigned int, osg::Stats&) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwworld/worldimp.cpp:1530:17 (openmw+0xa5af8f)
#5 MWWorld::World::updatePhysics(float, bool, unsigned long long, unsigned int, osg::Stats&) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/mwworld/worldimp.cpp:1862:13 (openmw+0xa61a7c)
#6 OMW::Engine::frame(float) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/engine.cpp:333:42 (openmw+0xcce9e7)
#7 OMW::Engine::go() /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/engine.cpp:935:14 (openmw+0xcd86ed)
#8 runApplication(int, char**) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/main.cpp:296:17 (openmw+0xcbffac)
#9 wrapApplication(int (*)(int, char**), int, char**, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../components/debug/debugging.cpp:205:15 (openmw+0x1335442)
#10 main /build/openmw/openmw/master2/.build/freebsd/TSAN/../../../apps/openmw/main.cpp:308:12 (openmw+0xcc008a)
:wqa
Previous MR change the meaning of mPositionOffset: it is now just a log
of relative movement that were already applied to allow the physics
simulation to catch up, instead of changes that needs to be applied. As
such, after a teleport we need to reset it. Also, since mWorldPosition
is already with the offset we should not update its value in
applyPositionOffset().
Instead of registering the desired change of position and rely on
physics simulation to apply it to the world, immediately change the
position in the world without reset the simulation.
When a script calls SetPos for x,y,z in sequence on an actor, we need to make sure
that the actor will not spawn under ground at x,y coordinates.
Now that change of coordinates are cumulated and applied all at once, we
need to account for the whole offset.
To this end move the terrain height check inside of Actor class.
To make SetPos works with async physics, it was modified to register a
position offset that would be applied to the real position during the
simulation.
A common pattern to teleport NPC in scripts is a sequence of SetPos/Disable/Enable in the same frame.
Since Disable/Enable creates a new physics actor using last known
RefData::Position, the registered offset never get a chance to be applied.
Modify disable() to call moveObject with the offset applied, so that the newly created physics actor will have up-to-date position
When a position is forced, the actor position in physics subsystem is
overriden. The background physics thread is not made aware of this,
its result are simply discarded.
There is a short window where this doesn't work (in this
example, actor is at A and script moves it to B)
1) actor position is set to B. (among others, Actor::mPosition is set to B)
2) physics thread reset Actor::mPosition with stale value (around A)
3) main thread read simulation result, reset Actor::mSkipSimulation flag => actor is at B
4) physics thread fetch latest Actor::mPosition value, which is around A
5) main thread read simulation result, actor is around A
To avoid this situation, do not perform 2) until after 3) occurs. This
way, at 4) starts the simulation with up-to-date Actor::mPosition
Restore projectile caster from savegame (#5860)
See merge request OpenMW/openmw!616
(cherry picked from commit d595c7adb0fb45eafed6d3d0403ad640a91411ed)
c5426bec In the savegame, projectile caster is identified by its actor id. When
This enables accelleration of heightfield collisions.
Unfortunately, `btHeightfieldTerrainShape::processAllTriangle` does not
yet use the accellerator data, so this change does not improve
performance yet but might do so in future bullet versions.
References:
* Accellerator introduced in:
https://github.com/bulletphysics/bullet3/pull/2062
* Feature request to use the accellerator in `processAllTriangle`:
https://github.com/bulletphysics/bullet3/issues/3276
projectile collision shape.
A side effect of moving actors outside of projectile collision shape is that if both the actor and the projectile are
near a wall, the actor could get moved outside of the world.
A prerequisite to create physics objects for statics was to remove the
dependency on base node (since it doesn't yet exists) for object
position. It is still necessary for animation though.
Restore the basenode (and the associated FIXME) so that animated objects works properly.
Since actors can be active in 3x3 grid around the player, we need to
first load all statics in a 5x5 grid around the player.
Split load and unloading in 2 phases. Add an mInactiveCells set into the
scene, which contains all cells inside the aforementioned 5x5 grid.
These cells contains only heightfields and physics objects of static
class.
imprecision issue with projectile collision detection.
Simplify the mechanics: manage hits in one spot.
Give magic projectiles a collision shape similar in size to their visible
model.
Rename the 2 convex result callback to clearly state their purpose.
In this case, the actor mPreviousPosition is not updated, so the actor
position is interpolated between an old (stucked) position and the new
(unstucked) position. The new position is most likely "stucked", so the
unstuck code strikes again, making the actor "vibrates".
That's exactly what the sync code path does, and it doesn't exhibit this
behavior.
What happened is that the last handle to an Actor shared_ptr was a
promoted weak_ptr. When the shared_ptr goes out of scope, the Actor dtor
is invoked. That involves removing the Actor collision object after
exclusively locking mCollisionWorldMutex. In this case, the lock was
already held in the outter scope of the promoted weak_ptr.
Reduce the scope of the mCollisionWorldMutex to never encompass the
lifetime of a promoted weak_ptr.
This unbreak abot's boat mods: they're continually teleporting
the boats (who is an actor with waterwalking effect). As such, the
physics simulation was never run and the boat never went to sea level.
One of the issue since the introduction of async physics is the quirky
handling of scripted moves. Previous attempt to account for them was
based on detecting changes in actor position while the physics thread is
running. To this end, semantics of Actor::updatePosition() (which is
responsible for set the absolute position of an actor in the world) was
toned down to merely store the desired position, with the physics system
actually responsible for moving the actor. For the cases were complete
override of the physics simulation was needed, I introduced
Actor::resetPosition(), which actually have same semantics as
original updatePosition(). This in turn introduced a loads of new bugs
when the weakened semantics broke key assumptions inside the engine
(spawning, summoning, teleport, etc).
Instead of tracking them down, count on the newly introduced support for
object relative movements in the engine (World::moveObjectBy) to
register relative movements and restore original handling of absolute positionning.
Changes are relatively small:
- move resetPosition() content into updatePosition()
- call updatePosition() everywhere it was called before
- remove all added calls to the now non-existing resetPosition()
tldr; ditch last month worth of bug introduction and eradication and redo
it properly
This gives finer control over reseting positions (switch off tcl is no
longer glitchy) and solve most of the erroneous usage of stale World::Ptr
indicated by:
"Error in frame: moveTo: object is not in this cell"
its current position.
Use it in relevant MWScripts opcode (move and moveworld).
Remove the fragile detection of scripted translation from PhysicsTaskScheduler.
No user visible change, just a more robust mechanism.
When an NPC fire a projectile, it should affect only its targeted actor.
To this end, after a hit is detected the target is checked against the
list of AI targets and reactivated if necessary.
Problem occurs when the hit occurs as a result of a friendly actor going
into the projectile (detected in ClosestNotMeConvexResultCallback):
while the projectile is inside the friend's collision box, it is
deactivated, just to be immediately reactivated. Effectively, the
projectile does nothing until the actor moves out.
Add a check inside the ClosestNotMeConvexResultCallback before declaring
a hit.
Since the necessary data is not safely accessible from the async thread,
maintain a copy inside the Projectile class.
position being used under heavy load, I introduced a regression that
prevented the position to be updated in case of teleport.
Move the logic in its own function and decide in PhysicsSystem whether a
reset is needed.
be sure the simulation is over. Otherwise, if the simulation is too slow
the position is wrong, and the actors would jump back and forth between
old and new position instead of actually moving.
Before this change, if an actor position was changed while the physics
simulation was running, the simulation result would be discarded. It is
fine in case of one off event such as teleport, but in the case of
scripts making use of this functionality to make lifts or conveyor (such
as Sotha Sil Expanded mod) it broke actor movement.
To alleviate this issue, at the end of the simulation, the position of the Actor
in the world is compared to the position it had at the beginning of the
simulation. A difference indicate a force move occured. In this case,
the Actor mPosition and mPreviousPosition are translated by the difference of position.
Since the Actor position will be really set while the next simulation runs, we
save it in the mNextPosition field.
it is updated in the solver only if the actor is standing on
"something". The ground is not "something", so in case the actor goes
from standing on an object to the standing on the ground, this change was not taken
into account.
Clear the value before the simulation to solve this problem.
Before movement calculation, the main thread prepare a
vector of ActorFrameData, which contains all data necessary to perform
the simulation, and feed it to the solver. At the same time it fetches
the result from the previous background simulation, which in turn is
used by the game mechanics.
Other functions of the physics system (weapon hit for instance)
interrupt the background simulation, with some exceptions described
below.
The number of threads is controlled by the numeric setting
[Physics]
async num threads
In case 'async num threads' > 1 and Bullet doesn't support multiple threads,
1 async thread will be used. 0 means synchronous solver.
Additional settings (will be silently switched off if async num threads = 0)
[Physics]
defer aabb update
Update AABBs of actors and objects in the background thread(s). It is not an especially
costly operation, but it needs exclusive access to the collision world, which blocks
other operations. Since AABB needs to be updated for collision detection, one can queue
them to defer update before start of the movement solver. Extensive tests on as much
as one installation (mine) show no drawback having that switched on.
[Physics]
lineofsight keep inactive cache
Control for how long (how many frames) the line of sight (LOS) request will be kept updated.
When a request for LOS is made for the first time, the background threads are stopped to
service it. From now on, the LOS will be refreshed preemptively as part of the background
routine until it is not required for lineofsight keep inactive cache frames. This mean
that subsequent request will not interrupt the background computation.
Change order of traversal simulation step to make it rare enough to be parallelizable
Before:
for actor in actors:
repeat numstep:
solve(actor)
After:
repeat numstep:
for actor in actors:
solve(actor)
Introduce struct ActorFrameData to pack all data that is necessary for
the solver
1. Do not update physics and animations for actors outside processing range (bug #4647)
2. Do not render such actors
3. Add transparency to actors near processing border, so they will not pop up suddenly
A Warning indicates a potential problem in the content file(s) that the user told OpenMW to load. E.g. this might cause an object to not display at all or as intended, however the rest of the game will run fine.
An Error, however, is more likely to be a bug with the engine itself - it means that basic assumptions have been violated and the engine might not run correctly anymore.
The above mostly applies to errors/warnings during game-play; startup issues are handled differently: when a file is completely invalid/corrupted to the point that the engine can not start, that might cause messages that are worded as Error due to the severity of the issue but are not necessarily the engine's fault.
Hopefully, being a little more consistent here will alleviate confusion among users as to when a log message should be reported and to whom.
The cylinder base is no longer appropriate as of the change to capsules.
This also works around a bug when tracing a small cylinder/box shape apparently introduced with bullet 2.86.
Previously we were handling 'on slope' synonymously with 'in air' which caused some odd effects.
Practical changes:
- Sliding down a slope no longer applies fall damage.
- Fixed a climbing exploit that would allow climbing steep slopes with repeated use of the Jump function.
to be able to reuse up stepper results
for successive movement solver iterations.
This can reduce the number of convex casts
almost by half in some cases.
This helps to capture the case where new velocity
only differs in the z component (normal pointing up).
TODO: Find a better way to handle the normal pointing up case.
This reverts commit cbf344663f.
Doesn't work correctly because the Animation delays the assignment of the UpdateCallbacks until the animation starts. The commit broke the animation of in_dagoth_bridge00
