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.