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”?