We have noticed some performance issues caused by Mover running exclusively on the GameThread, and were thinking about moving it to other threads. Luckily, we are using `UMoverStandaloneLiaisonComponent`, which already contains such support, but probably not complete (as why I’m writing this down).
I have tried enabling `SetUseAsyncMovementSimulationTick(true)` and `SetUseAsyncProduceInput(true)` on the Liaison itself and then enabled `mover.standalone.RunMovementSimOnAnyThread 1` and `mover.standalone.RunProduceInputOnAnyThread 1` since it’s conditioned via cvars as well.
But then all hell broke loose because of other systems the Mover is calling requiring GameThread context.
Some examples:
Physics:
[Image Removed]
World:
[Image Removed]
Most likely playing montage from SimulationTick (traversal in this case), we might have to defer it to GT anyway:
[Image Removed]
Do I have to turn on anything else to make these Async Mover Ticks work, or is full support planned for the future?
One thing I see from the callstacks is the use of movement modes that perform ‘immediate’ movement. e.g. WalkingMode, FallingMode
Give their ‘Async’ cousins a shot, such as AsyncWalkingMode, AsyncFlyingMode, AsyncFallingMode.
There are still some caveats. Some features and events will not work in async mode yet.
For instance, you should be able to do montage-based root motion but not motion warping (MotionWarpingComponent is not thread-safe).
Additionally, SmoothWalkingMode is a subclass of WalkingMode and does not have an async variant yet. But I don’t see any major barriers if you wanted to create the equivalent behavior AsyncSmoothWalkingMode deriving from AsyncWalkingMode.
We are still working towards full feature parity with non-async movement, and I expect this to be an continuing effort this year.
This is something we’re actively looking at as part of our efforts to support physics-based character movement. Once it’s solved for the async networked physics case, I think all async Mover cases will be covered. I’d be surprised if it didn’t happen this year.
You may be able to make some cases work with just a few small modifications to the Motion Warping Component. If I recall correctly, there were a couple of uobject allocations and cvar accesses that needed to be tweaked to be OK on a worker thread. You would run into these simply by trying to use motion warping off the game thread.