Search Unity

Feedback [1.0.0-pre.47] Performance improvement for prediction

Discussion in 'NetCode for ECS' started by optimise, Mar 22, 2023.

  1. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,129
    Currently at latest pre.47, PredictedSimulationSystemGroup and PredictedFixedStepSimulationSystemGroup still takes a lot of time to execute. Firstly, it's caused by the same build physics keep running at prediction multiple times that can make them batch together and run only once to improve performance significantly. Secondly is currently the time taken to execute will keep increasing when the ping is keep increasing which also need to find better solution to solve this issue. Will official address both of this issues to make it really usable at production project?
     
  2. CMarastoni

    CMarastoni

    Unity Technologies

    Joined:
    Mar 18, 2020
    Posts:
    895
    First, to clarify, it is correct that prediction loop and physics (if enabled) run multiple time if you have high ping.
    It has always been like that.
    We are optimising the physics loop to reduce the burden of this multiple simulation steps, but still requires some time and validation.

    Batching the physics steps together is not really always possible. Apart collision detection issue and stability, it really depend on your game and client logic.

    We don't have yet a way to customise the current physics simulation loop (in a generic way) such that it run fewer steps.

    You can still use client-side prediction batch to reduce the prediction loop cost. See ClientTickRate
    Code (csharp):
    1.  
    2. /// <summary>
    3. /// The client can batch simulation steps in the prediction loop. This setting controls
    4. /// how many simulation steps the simulation can batch for ticks which have previously
    5. /// been predicted.
    6. /// Setting this to a value larger than 1 will save performance, but the gameplay systems
    7. /// needs to be adapted.
    8. /// </summary>
    9. public int MaxPredictionStepBatchSizeRepeatedTick;
    10. /// <summary>
    11. /// The client can batch simulation steps in the prediction loop. This setting controls
    12. /// how many simulation steps the simulation can batch for ticks which are being predicted
    13. /// for the first time.
    14. /// Setting this to a value larger than 1 will save performance, but the gameplay systems
    15. /// needs to be adapted.
    16. /// </summary>
    17. public int MaxPredictionStepBatchSizeFirstTimeTick;
    18.  
    However, that means in one loop step you may actually be predicting up to MaxPredictionStepBatchSizeRepeatedTick at once, using the same input. That may be fine (the delta time is correct) but may be not.
    For physics though, this still run the simulation multiple time. (and that it is a limitation).

    Speaking about physics, what you can do already today, is to avoid
    - building the physics world multiple time
    - run everything on the main thread if the number of simulated entities is small (usually < some hundreds, the threshold may vary).
    - in case of this batching in particular, do things only once for the first and last physics steps.

    But this still requires changes in the Physics package, Netcode package, and potentially your physics code too.
     
    optimise likes this.
  3. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,129
    What I actually mean is batch building the physics world to only once. I guess physics steps and building the physics world are different things?
     
  4. CMarastoni

    CMarastoni

    Unity Technologies

    Joined:
    Mar 18, 2020
    Posts:
    895
    We can build the world once and do steps multiple time, this is plenty possible, even today with small modification or even without.
    I though you also would want to do less steps, for example to handle 100ms latency (that mean about 7 step), by using some-how a "variable" step size. The Unity.Physics engine is not mean to work like that in general, and the integrator (euler), collision detection and joint simulation requires small steps to be precise and stable.

    However, I think in certain scenarios (depend on the game) you double or triple the delta time and so doing 1/3 of the steps in certain case (especially if we have slow motion objects).