I’m working on a game that has moderately complex custom physics code that executes per actor. Currently it’s hung off a custom timer that I set up like so and run 30 times per second:
tm.SetTimer(PhysTimer, this, &UPhysMovementComponent::CalcPhysics, PhysicsRate, true);
This is okay. However, it won’t scale well to a very large number of objects, so I want to punt this off to a separate thread, and have the actor Tick() function do only the very simple “tail end” of the physics such as vel=vel+accel type stuff.
I found this tutorial Rama made, which I guess will be helpful when I get to writing the code. There’s one thing I’m unclear on though. I don’t need to create or destroy objects in my physics thread, but I DO need to modify some instance data, which that page suggests is a bad idea.
My plan is to set up a physics thread that iterates through the global actor list, running physics on each in turn. It would use some kind of lock (FCriticalSection? FScopeLock? what’s the right thing?) to avoid collisions between itself and the game thread. Something like this in pseudocode:
Physics thread(s): For each actor: Grab a lock for this actor Run the heavy duty physics Release the lock Game thread actor Tick() fn: Grab a lock Run the light duty physics & update actor positions Release the lock
Is this a viable way to go? And what flavor of UE4 lock do I want to be using? What issues are there with traversing the set of actors in a separate thread like that, where the main thread can delete them, even if this physics thread never will?
Thanks for any insights!