Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Question Are Physics Scenes multithreaded?

Discussion in 'Physics' started by CunningFox146, Feb 27, 2023.

  1. CunningFox146


    Mar 2, 2020
    Hey, I was wondering if Physics Scenes that I create are being run on other threads, or are they all being run on the same thread? And if they're not multithreaded, is there a way to use jobs with them?
    AntonioModer likes this.
  2. MrBigly


    Oct 30, 2017
    This is an interesting question. (I don't mean to hijack this thread, but I want to ask more pointed questions if I may...)

    For any given scene, are the physics calculations being performed simultaneously across multiple threads for improved performance, or are they constrained by being performed only in the main thread?

    If in multiple threads, what types of calculations exactly are being handled in parallel?
  3. Augustinas-Simkus


    Unity Technologies

    Mar 9, 2020
    Hey, so the actual simulation step is indeed multi-threaded. Although the main thread is blocked until all PhysX tasks are complete, it's picking up other work while waiting (see Physics.Processing). You can see what PhysX is working on in the profiler.

    On latest Unity versions, Transform Sync, parts of simulation result readback, and interpolation/extrapolation pipeline are also multithreaded internally.

    So you can use jobs to accelerate some parts of your physics code:
    Hope that clears things up a little bit. Let me know if you have any specific inquiries that I did not cover.

    Attached Files:

  4. mainVar


    Jul 4, 2017
    hi, "On latest Unity versions, Transform Sync, parts of simulation result readback, and interpolation/extrapolation pipeline are also multithreaded internally." - would you write a version ? You maybe mean 2023.1 ? or other?
  5. Augustinas-Simkus


    Unity Technologies

    Mar 9, 2020
    Hey! Sure:
    • Transform Sync became threaded in 2023.1.0a4.
    • Simulation readback (contacts to be specific) became threaded in 2022.2.0a15 (you can read more here)
    • Interpolation/extrapolation have some threading in all supported Unity streams.
    AntonioModer and CunningFox146 like this.
  6. manu_fpv


    Dec 1, 2018
    I'm very interested in this discussion. And I'd like to share my problem with it.
    When the frameRate drops very low, even if it's for a very short time (10 FPS for one second, for example)
    FixedUpdate, which is set to run every 0.02 seconds, does indeed run 50 times a second, but as it runs at a higher frequency than Update! it runs several times in a row before the Update. So FixedUpdate doesn't actually execute every 0.02 seconds!
    I have the same problem with inputs! When using the New InputSystem, the refresh rate is higher than when using the OldInputManager. The problem remains the same: the inputs are refreshed several times before the Update, and then throughout the rest of the frame - it's a total blackout. No input refresh, and no physics simulation.

    When the player turns, many new objects are displayed, so it's when the player turns that the FrameRate decreases. And this is precisely the crucial moment when the player needs maximum precision in his movements.

    Is there a way of passing inputs and physics simulation to a thread other than the main one?
    Or, conversely, switch all the rest of the rendering preparation calculations to another thread?
    For me, the priority is inputs and physics. As for the rest, if some images are missing... it doesn't matter.

    Augustinas-Simkus, in the image you posted above, we cannot see the rest of the frame. We see that multithreading is used even for physics, but it is only valid for the start of the frame. I would like the physics to be able to be executed even in the middle and end of a frame in order to have physics executed in a truly constant manner. Is there a way to do this?
    Last edited: Oct 3, 2023
  7. arkano22


    Sep 20, 2012
    You just described how physics simulation works in general: when a physics engine simulates 0.02 seconds worth of "game time", it doesn't take exactly 0.02 real-world seconds to do it. It might take less (allowing to skip physics update during some frames) or it might take more (forcing to update physics several times per frame).

    FixedUpdate doesn't execute at a 0.02 seconds interval (50 Hz frequency). It executes once for every 0.02 seconds that have passed in-game, which are two completely different things since it may execute multiple times in a row or not be executed at all some frames.

    This is just how computers work: they perform work as fast as possible, and then go on to the next task. Even when performing multiple tasks at once, their inputs/outputs follow a specific order. If you somehow spread out the physics calculation over the entire duration of the frame, results would be the exact same, there's absolutely no benefit in executing physics "in the middle and end of a frame" compared to executing them at the start: the amount of time simulated by the engine is exactly the same.

    I think you need to revisit your understanding of how game engines - and computers in general - work. All tasks (updating physics, updating input, updating rendering, etc) are performed at a specific point in time, and follow a specific order. Even when using multithreading, they have some clearly defined inputs when they start executing and clearly defined output upon finishing, so the end result is exactly the same as if everything had been executed in a single thread.

    In few words: multithreading won't make input or physics update "continuously" during the frame. They will just take less time to execute, but at the end of the day tasks happen at a specific point in time. The only way to make things update "constantly" in computers -which are digital/discrete machines at their core- is to update them more often, which typically can only be achieved by doing less work (optimizing your game).
    Last edited: Oct 5, 2023
    Pronetizen likes this.