Hi, @sergio.gardeazabal!
Thanks so much for confirming this!
Reading the thread you mentioned, I’m surprised to learn that UActorComponent::AsyncPhysicsTickComponent runs on the Game Thread. I was assuming it was called on one of the Physics Threads. But, if I understood correctly, it will be executed once by physics tick anyways and it’s not tied in any way to the Game Thread tick rate, right?
Now, at the code that goes in UActorComponent::AsyncPhysicsTickComponent, instead of obtaining physics state and adding forces and torques through the FBodyInstance returned by UPrimitiveComponent::GetBodyInstance, I’m doing all those things through the FBodyInstanceAsyncPhysicsTickHandle returned by UPrimitiveComponent::GetBodyInstanceAsyncPhysicsTickHandle. That’s the correct thing to do, right?
When I get the physics state from the FBodyInstanceAsyncPhysicsTickHandle, am I obtaining the (potentially stale) physics state from the Game Thread or the latest state from the Physics world?
Also, are there plans to make the API of FBodyInstanceAsyncPhysicsTickHandle equivalant to the API of FBodyInstance? I miss convenient methods like the AddForceAtPosition and the self-descriptive names of methods from FBodyInstance (In example, FBodyInstance::GetUnrealWorldVelocity() instead of FBodyInstanceAsyncPhysicsTickHandle::V()).