Iba a escribir esto como un comentario, pero terminó siendo bastante largo, así que lo convertí en una respuesta.
Las respuestas actuales son en su mayoría correctas, pero algunas cosas mencionadas son engañosas / incorrectas.
En general, la mayoría de las tareas relacionadas con el juego entrarán Update
.
Por ejemplo, no desea sondear la entrada FixedUpdate
(no por el rendimiento, sino porque las llamadas simplemente no funcionarán correctamente). La IA cae en el mismo bote.
La física actualizada continuamente es la única tarea relacionada con el juego que se FixedUpdate
debe utilizar. Llamadas no continuas / de vez en cuando a cosas como Physics.Raycast
, o incluso Rigidbody.AddForce
pertenecer Update
. Mi mención de Rigidbody.AddForce
es aparentemente contraria a lo que podría implicar la documentación, pero la clave es Continua vs No continua.
Una gran razón por la que solo pertenece la física continua FixedUpdate
es la naturaleza real de FixedUpdate
. Otras respuestas han mencionado cómo se llama a FixedUpdate en un interval, but that's slightly misleading. In reality, a script is passed a time in Time.deltaTime
/ Time.fixedDeltaTime
* fijo que no corresponde directamente al tiempo real entre llamadas, sino al tiempo simulado entre llamadas.
(* Time.deltaTime
y Time.fixedDeltaTime
son el mismo valor cuando se llama FixedUpdate
[Unity puede decir si la llamada actual se Time.deltaTime
originó durante FixedUpdate
y regresa Time.fixedDeltaTime
])
Naturalmente, Update
no se puede llamar de la misma manera de manera constante debido al rendimiento variable, tampoco se puede FixedUpdate
. La diferencia clave es que cada cuadro, si FixedUpdate
no se ha llamado con la frecuencia suficiente para promediar el intervalo correcto entre llamadas, se llama varias veces (o no se llama, el promedio es demasiado alto). Esto es a lo que se refieren los documentos sobre la orden de ejecución al decir que FixedUpdate se puede llamar varias veces por marco:
... FixedUpdate: FixedUpdate a menudo se llama con más frecuencia que Update. Se puede llamar varias veces por fotograma, si la velocidad de fotogramas es baja y no se puede llamar entre fotogramas si la velocidad de fotogramas es alta ...
Esto no afecta a la Física debido a la naturaleza del resto de la orden de ejecución y el motor, pero casi cualquier otra cosa que ingrese FixedUpdate
se verá afectada y causará problemas.
Por ejemplo, si coloca el procesamiento de AI dentro, FixedUpdate
no hay razón para suponer que la IA no omitirá las actualizaciones para varios cuadros seguidos. Además, cada vez que `FixedUpdate se queda atrás, su IA se actualizará varias veces en un solo cuadro antes de que se procesen cosas como la física y la entrada / movimiento del jugador, lo que es un desperdicio de procesamiento como mínimo, pero también es extremadamente probable que cause problemas rastrear errores y comportamientos erráticos.
Si necesita hacer algo en un intervalo fijo, use otros métodos que proporciona Unity, como Coroutines
y InvokeRepeating
.
Y una pequeña nota sobre Time.deltaTime
y cuándo usarlo:
La forma más fácil de describir el efecto de Time.deltaTime es que cambia un número de unidad por cuadro a unidad por segundo . Por ejemplo, si tiene un script con algo como transform.Translate(Vector3.up * 5)
en Actualización, esencialmente está moviendo la transformación a una velocidad de 5 metros por cuadro . Eso significa que si la velocidad de fotogramas es baja, el movimiento es más lento, y si la velocidad de fotogramas es alta, el movimiento es más rápido.
Si toma el mismo código y lo cambia transform.Translate(Vector3.up * 5 * Time.deltaTime)
, el objeto se está moviendo a una velocidad de 5 metros por segundo . Eso significa que no importa la velocidad de fotogramas, el objeto se moverá 5 metros por segundo (pero cuanto más lenta sea la velocidad de fotogramas, más rápido aparecerá el movimiento del objeto ya que todavía se mueve la misma cantidad cada X segundos)
En general, quieres que tu movimiento sea por segundo. De esa manera, no importa a qué velocidad vaya la computadora, su física / movimiento se comportará de la misma manera, y no tendrá errores extraños apareciendo en dispositivos más lentos.
Y no tiene sentido usarlo FixedUpdate
. Debido a lo que mencioné anteriormente, obtendrá el mismo valor en cada llamada (el valor de Tiempos de actualización fijos), y no hará nada a sus valores. El movimiento / física definido en FixedUpdate
ya estará en unidades por segundo, por lo que no lo necesita.