Здається, рух залежить від частоти кадрів, незважаючи на використання Time.deltaTime

У мене є наступний код для обчислення перекладу, необхідного для переміщення ігрового об'єкта в Unity, який викликається LateUpdate. З того, що я розумію, моє використання Time.deltaTimeповинно зробити остаточну частоту кадрів перекладу незалежною (будь ласка, зверніть увагу, що CollisionDetection.Move()це просто виконання радіопередач).

public IMovementModel Move(IMovementModel model) {    
    this.model = model;

    targetSpeed = (model.HorizontalInput + model.VerticalInput) * model.Speed;

    model.CurrentSpeed = accelerateSpeed(model.CurrentSpeed, targetSpeed,
        model.Accel);

    if (model.IsJumping) {
        model.AmountToMove = new Vector3(model.AmountToMove.x,
            model.AmountToMove.y);
    } else if (CollisionDetection.OnGround) {
        model.AmountToMove = new Vector3(model.AmountToMove.x, 0);
    }

    model.FlipAnim = flipAnimation(targetSpeed);
    // If we're ignoring gravity, then just use the vertical input.
    // if it's 0, then we'll just float.
    gravity = model.IgnoreGravity ? model.VerticalInput : 40f;

    model.AmountToMove = new Vector3(model.CurrentSpeed, model.AmountToMove.y - gravity * Time.deltaTime);

    model.FinalTransform =
        CollisionDetection.Move(model.AmountToMove * Time.deltaTime,
            model.BoxCollider.gameObject, model.IgnorePlayerLayer);
    // Prevent the entity from moving too fast on the y-axis.
    model.FinalTransform = new Vector3(model.FinalTransform.x,
        Mathf.Clamp(model.FinalTransform.y, -1.0f, 1.0f),
        model.FinalTransform.z);

    return model;
}

private float accelerateSpeed(float currSpeed, float target, float accel) {
    if (currSpeed == target) {
        return currSpeed;
    }
    // Must currSpeed be increased or decreased to get closer to target
    float dir = Mathf.Sign(target - currSpeed);
    currSpeed += accel * Time.deltaTime * dir;
    // If currSpeed has now passed Target then return Target, otherwise return currSpeed
    return (dir == Mathf.Sign(target - currSpeed)) ? currSpeed : target;
}

private void OnMovementCalculated(IMovementModel model) {
    transform.Translate(model.FinalTransform);
}

Якщо я заблокую рамку гри до 60 кадрів в секунду, мої об'єкти рухаються так, як очікувалося. Однак якщо я його розблокую ( Application.targetFrameRate = -1;), деякі об'єкти будуть рухатися значно повільніше, тоді, як я очікував, досягнувши ~ 200 кадрів в секунду на моніторі 144 Гц. Це, здається, відбувається лише в самостійній збірці, а не в редакторі Unity.

GIF переміщення об'єкта в редакторі, розблокований FPS

http://gfycat.com/SmugAn yearFugu

GIF руху об'єктів в рамках самостійної збірки, розблокований FPS

http://gfycat.com/OldAmpleJuliabutterfly

Моделювання на основі кадру зазнає помилок, коли оновлення не зможе компенсувати нелінійні темпи зміни.

Наприклад, розглянемо об'єкт, починаючи зі значення нульової позиції та швидкості, відчуваючи постійне прискорення одиниці.

Якщо ми застосуємо цю логіку оновлення:

velocity += acceleration * elapsedTime
position += velocity * elapsedTime

Ми можемо очікувати цих результатів при різних частотах кадрів:

Помилка викликана обробкою кінцевої швидкості так, ніби вона застосовується для всього кадру. Це схоже на правий Ріман Сума, і кількість помилок змінюється залежно від частоти кадрів (проілюстровано на іншій функції):

Як зазначає MichaelS , ця помилка зменшиться вдвічі, коли тривалість кадру скоротиться вдвічі, і може стати непослідовною при високій частоті кадрів. З іншого боку, будь-які ігри, у яких спостерігаються сплески продуктивності або тривалі кадри, можуть виявити, що це призводить до непередбачуваної поведінки.

На щастя, кінематика дозволяє точно розрахувати переміщення, викликане лінійним прискоренням:

d =  vᵢ*t + (a*t²)/2

where:
  d  = displacement
  vᵢ = initial velocity
  a  = acceleration
  t  = elapsed time

breakdown:
  vᵢ*t     = movement due to the initial velocity
  (a*t²)/2 = change in movement due to acceleration throughout the frame

Тож якщо ми застосуємо цю логіку оновлення:

position += (velocity * elapsedTime) + (acceleration * elapsedTime * elapsedTime / 2)
velocity += acceleration * elapsedTime

У нас будуть такі результати:

Це залежить від того, звідки ви дзвоните на свій крок. Якщо ви зателефонуєте йому з Update, ваш рух дійсно буде незалежно від кадру, якщо ви масштабуєте за допомогою Time.deltaTime, але якщо ви викликаєте його з FixedUpdate, вам потрібно масштабувати за допомогою Time.fixedDeltaTime. Я думаю, ви називаєте свій крок від FixedUpdate, але масштабування за допомогою Time.deltaTime, що призведе до зниження видимої швидкості, коли фіксований крок Unity повільніше, ніж основний цикл, що відбувається у вашій самостійній збірці. Коли фіксований крок повільний, фіксованийDeltaTime великий.