Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

Are PhysicsScenes Parallelizable?

Discussion in 'Physics' started by JohannesMP, Sep 3, 2019.

  1. JohannesMP

    JohannesMP

    Joined:
    Nov 4, 2016
    Posts:
    17
    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)
     
    Last edited: Sep 3, 2019
  2. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    1,960
    That is correct however that doesn't mean it runs entirely on the main-thread. The actual simulation takes place on multiple-cores which you should easily be able to verify by looking at the profiler. A chunk of the simulation step does require main-thread access however such as Transform write-back and performing script-callbacks. These cannot happen from a thread.

    The separation of PhysicsScenes is simply to provide an isolated domain of physics objects that cannot interact with other PhysicsScene (a physics sandbox if you will) and not to provide some kind of thread-specifc isolation.