Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Question Physics.AutoSyncTransforms

Discussion in 'Physics' started by Olarr, Sep 22, 2023.

  1. Olarr

    Olarr

    Joined:
    Oct 20, 2022
    Posts:
    5
    Hi everyone, I've read in the documentation and on this forum that the AutoSyncTransform option should never be used. But I'm working on an Android application where no objects move, except in very (very) rare cases. I don't use physics other than with raycasts (no Rigidbody, no collisions). Using Physics.AutoSimulation (Unity 2021), I see in the Inspector that physics calculations take a long time, 0.5ms+. However, with AutoSyncTransform ON and AutoSimulation OFF, I have much less calculation time for physics. So, in the case of a scene where nothing moves except very rarely, and where these objects must then be resynchronized with physics, isn't it more efficient to use Physics.AutoSyncTransform rather than Physics.AutoSimulation?
    Another question: is calling Physics.SyncTransforms() manually (when an object with collider has been moved) more efficient than using Physics.SyncTransforms()? (I precise I'm only using simple box colliders). Thanks for your answers, and excuse-me for my bad english!
     
  2. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    10,468
    So you're using colliders and queries; that IS physics. Physics != Movement only.

    I don't see how it can be better for performance, that's got to be wrong. All it does is check to see if you've modified a transform and writes those changes to rigidbodies and colliders. This is automatically done each time the simulation runs anyway to ensure it's in-sync with transform changes you might have done.

    With it on, it performs that sync each and every time you read any physics property that might relate to anything spatial so it's pretty terrible for performance, despite what you've said above.

    It's for backwards compatibility, don't use it. If you've convinced yourself you must then there's nobody to stop you. ;)
     
  3. Olarr

    Olarr

    Joined:
    Oct 20, 2022
    Posts:
    5
    Thank you for your reply! I won't use it. The app will (maybe) evolve and I don't want to create a problematic situation for the future.
    What about manually call Physics.SyncTransforms() after a transform change (position, rotation, scale...)? Is it a bad idea too?
    This app must run on very low end VR headsets like Oculus Go :(, and I don't have a lot of power at my disposal.I probably don't understand what Physics.autoSimulation does exactly, in my mind it calculates all kind of physics things like collisions, effect of forces, etc. I don't use them in this app, I just have box colliders which must be detected by raycasts and are immobile 99.99% of the time. So I don't know if it is really necessary to calculate all this physics stuff on a regular basis. Maybe the best solution would be to call manually Physics.Simulate() when a transform have changed? Or just augment the time between two calculations?
     
  4. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    10,468
    The main point I'm trying to get across is that calling these things costs as you've highlighted that you have a potentially strict CPU budget. If you want to avoid all simulation operations then yes, turn off the auto-simulation.

    If you don't want the simulation then there'd be no purpose in calling this so no, not really.

    If you want disable simulation and are modifying the Transform only then go ahead and turn on auto-sync transforms but this will call SyncTransforms for you whenever you do a read operation (query, read the pose of a body etc). If you want to manually SyncTransforms whenever you feel like it do that instead.

    In the end, these things cost so unless you know what they actually do and profile then you're likely to run into performance issues. Move/Sync/Move/Sync/Move/Sync lots of times per-frame doesn't scale well. This is why the simulation calls it once before the simulation runs as everything as a batch. With the simulation off, you could do the same and just issue this call once so get all your changes synced once before you go ahead and use queries etc.
     
  5. Olarr

    Olarr

    Joined:
    Oct 20, 2022
    Posts:
    5
    Thank you for your quick reply! I was thinking of doing the last solution you mentionned. I will do some tests, and try to find the best solution for my case. I don't want to overcomplicate the code either...
     
    MelvMay likes this.