El movimiento parece depender de la velocidad de fotogramas, a pesar del uso de Time.deltaTime

Tengo el siguiente código para calcular la traducción requerida para mover un objeto de juego en Unity, que se llama LateUpdate. Por lo que entiendo, mi uso de Time.deltaTimedebería hacer que la velocidad de fotogramas de traducción final sea independiente (tenga en cuenta CollisionDetection.Move()que solo está realizando transmisiones de rayos).

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);
}

Si bloqueo el framerate del juego a 60FPS, mis objetos se mueven como se esperaba. Sin embargo, si lo desbloqueo ( Application.targetFrameRate = -1;), algunos objetos se moverán a una velocidad mucho más lenta de lo que esperaría cuando logre ~ 200FPS en un monitor de 144hz. Esto solo parece suceder en una compilación independiente, y no dentro del editor de Unity.

GIF de movimiento de objetos dentro del editor, FPS desbloqueado

http://gfycat.com/SmugAnnualFugu

GIF de movimiento de objetos dentro de la construcción independiente, FPS desbloqueado

http://gfycat.com/OldAmpleJuliabutterfly

Las simulaciones basadas en marcos experimentarán errores cuando las actualizaciones no puedan compensar las tasas de cambio no lineales.

Por ejemplo, considere un objeto que comienza con valores de posición y velocidad cero experimentando una aceleración constante de uno.

Si aplicamos esta lógica de actualización:

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

Podemos esperar estos resultados bajo diferentes velocidades de cuadros:

El error se produce al tratar la velocidad final como si se aplicara a todo el cuadro. Esto es similar a una suma de Riemann correcta y la cantidad de error varía con la velocidad de fotogramas (ilustrada en una función diferente):

Como señala MichaelS , este error se reducirá a la mitad cuando la duración del cuadro se reduzca a la mitad y puede volverse intrascendente a velocidades de cuadro altas. Por otro lado, cualquier juego que experimente picos de rendimiento o cuadros de larga duración puede encontrar que esto produce un comportamiento impredecible.

Afortunadamente, la cinemática nos permite calcular con precisión el desplazamiento causado por la aceleración lineal:

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

Entonces, si aplicamos esta lógica de actualización:

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

Tendremos los siguientes resultados:

Depende de dónde llames tu paso. Si lo está llamando desde Update, su movimiento será independiente de la velocidad de fotogramas si escala con Time.deltaTime, pero si lo llama desde FixedUpdate, necesita escalar con Time.fixedDeltaTime. Me imagino que estás llamando a tu paso desde FixedUpdate, pero escalando con Time.deltaTime, lo que daría como resultado una velocidad aparente disminuida cuando el paso fijo de Unity es más lento que el bucle principal, que es lo que está sucediendo en tu construcción independiente. Cuando el paso fijo es lento, fixedDeltaTime es grande.