Does Async Physics Actually DO Anything?

I’m finding myself down a deep rabbit hole of trying to see if I can lock my character inputs and core movement to the async physics thread at a fixed framerate. I discovered the potential of implementing the experimental Async Physics feature through the Project Settings, which in turn allows you to implement an optional AsyncPhysicsTick() on actors and AsyncPhysicsTickComponent() on components.

However, as I dig through the source code to understand what all of this is doing, it comes across that turning this setting on does very little. I obviously struggle to understand the underlying low-level Chaos Physics code, so I might be misunderstanding something, but from what I can tell, this feature simply allows components and actors to register these new tick functions. The engine doesn’t actually DO anything with these tick functions if you haven’t implemented them yourself.

Is there anything the Chaos engine is actually doing to run all of its simulations on the determined Async Physics Tick Rate for any given actor that is registered with the system? It doesn’t appear so. The only points in time at which a given actor’s Async Physics state is queried are just used to call that separate tick function.

So, for instance, as I go to try to see how I can tie various logic of the Character Movement Component to this Async Physics parameter, all I find is that it’s kind of pointless. Character Movement is so intrinsically tied to the Game Thread of Unreal Engine that all of its physics-influenced logic is not only processed by its own game thread tick function, if I try to override things and run the Character Movement Tick on the Physics Tick, the engine is crashing as it expects Movement Component ticks to be synchronized across the entire engine (to the point that somehow I’m crashing in the Particle Physics code if I try to call Movement Component Tick at a different tick rate).

On top of all of that, to turn on Async Physics for a component, you have to use protected native functions, meaning any component you’d like to use this system, you need to create a child class of and reparent all of your blueprint component classes to interact with. So, for instance, if Actor Async Physics is turned on, it’s not turned on for ANY of its components. At that point, doesn’t that clearly imply it’s not doing anything at all? An actor can’t simulate physics separately from its components, as it doesn’t HAVE physics without components. Simply sending asynchronous physics API calls to game thread physics components isn’t actually async physics whatsoever, so it’s all coming across as almost lying to the user.

I know I am getting into really fringe uses of the engine, but I’m trying to see if anyone has confirmation that Async Physics does anything beyond what you manually implement in its tick function. And if not, I’m wondering how it would be helpful, as it would essentially require writing your own physics system within these functions, which seems unrealistic. Such a system doesn’t seem like it can interface with Unreal physics API in a sane way, especially complex existing features like the Movement Component.

I would expect this feature to intercept the underlying physics simulation API and force all aspects of an actor and its components, if not the entire physics state of the game simulation, to be run at the same tick rate. There are literally Pre- through Post-Physics Tick Groups, and this parameter doesn’t appear to interact with them at all. If that somehow IS what it does in spite of all these other components still running on the game thread, perhaps the feature is just too advanced for me to understand how to interact with.

What this SEEMS to be, rather than an Async Physics system, is simply a method to have a secondary constant tick function on another thread. That’s actually kind of useful! But why call it “Async Physics”?

1 Like

For anyone who comes on this in the future, found a bit more…

Turns out there is some code in the character movement component specifically for processing async movement. I stumbled on this as I was going about learning how the movement component consumes inputs.

However, obviously per the comments around it, it’s an in-development feature that’s not ready yet.

image

I tried toggling this on, along with making my movement component register with the async physics system, and on first test, my movement inputs no longer worked, the character no longer had a recognizable movement mode, and I hit multiple ensures in code. So yeah, this is more unfinished than just an “experimental” feature, it’s just not done and probably not worth barking up this tree for now.

Another thing I learned in the process of digging into all of this is that I think a lot more would need to be rewritten for inputs to be processed in this async manner. It appears that delegate bindings in general run on the game thread, and the base and enhanced input system is obviously using those across the board to work at all. If your inputs are processed on the game thread, then it seems like their timing can get out of sync with another tick like this (i.e. late or early).

I toyed with processing inputs on this async tick, but that didn’t really work, can see the movement code already was trying to go down that route for the user.

2 Likes

Another notable factor is I was just told by a friend about the new Mover Plugin (introduced in 5.4), which it appears is being created from the ground up with the async physics thread in mind. Still experimental as well, I don’t envy the Epic engineers trying to maintain two completely different movement architectures with a new physics method, but here’s hoping that ends up in Fortnite and becomes a stable thing we can all use one day.