Are PhysicsScenes Parallelizable?

Apologies if this has already been discussed in other places. If so please point me in the right direction.


Using PhysicsScenes to manually separate a single large physics simulation into multiple smaller discrete ones seems like a really powerful tool for optimizing physics performance.

As far as I understand, PhysicsScenes enable the creation of separate discrete bubbles of physical interactions that can be simulated completely independently of each other, at their own discrete timesteps. I'm trying to explore this for a Unity Project currently using 2018.4 (though 2019 is a potential option) that has a large world with many physics objects and where we're always looking to improve physics performance.


I was wondering, how parallelizable is PhysicsScene.Simulate(timestep) when called on two or more independent PhysicsScenes? Of course the guarantee needs to be made that no Physics callbacks such as OnCollisionEnter on an object in one scene try to modify state of an object in another scene, but if such an assumption could be made, Is that even theoretically possible?

Under the hood, how well does Unity (if at all) current parallelize code like this?

Code (CSharp):

1. void FixedUpdate()
2. {
3.     physicsScene1.Simulate(timestep1);
4.     physicsScene2.Simulate(timestep2);
5. }

My assumption (and please correct me here) is that Simulate on scene 1 is a blocking call, and scene 2 will only be simulated when scene1's call has completed, and I assume that this is for the most part single-threaded. Is that correct?

My (probably ill-informed) Intuition is that this separation of separate physics scenes lends itself naturally to distributing the physics calculation to separate threads, and I'm curious how much that is now possible.


My hope is that, if we say scene1 takes t1 arbitrary CPU time units to simulate and scene2 takes t2 time to simulate, that there is some way to simulate both and distribute the work over multiple threads so that after both scenes have completed the time spent by the whole system is closer to max(t1, t2) time instead of the (I am assuming) current t1+t2 time. (obviously if you add up the overall CPU time spent across all threads it would always be t1+t2)