Skip to content

Async physics

Frederic Chardon requested to merge fr3dz10/openmw:async-physics into master

Process movement queue in one or several background threads

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.

There are roughly 3 consumers of LOS:

  • scripts, which very seldomly make such requests and rather don't repeat them. They don't benefit from the cache.
  • AI (pursuit, combat) which tends to repeat the request for as long as it is positive
  • greetings / head tracking, which makes a lot of requests and repeat some of them

More tests and profiling are required to determine if this feature is really useful in this form. A more fruitful approach would probably be to modify the AI, greetings & co to cope with async resolution.

Edited by Frederic Chardon

Merge request reports