J'allais écrire ceci comme un commentaire, mais cela a fini par être assez long, donc je l'ai transformé en réponse.
Les réponses actuelles sont généralement correctes, mais quelques éléments mentionnés sont trompeurs / erronés.
En général, la plupart des tâches liées au jeu entrent Update
.
Par exemple, vous ne voulez pas interroger l'entrée FixedUpdate
(pas à cause des performances, mais parce que les appels ne fonctionneront tout simplement pas correctement). AI tombe dans le même bateau.
La physique mise à jour en continu est la seule tâche liée au gameplay FixedUpdate
à utiliser. Appels non continus / ponctuels à des choses comme Physics.Raycast
, ou même à faire Rigidbody.AddForce
partie Update
. Ma mention Rigidbody.AddForce
est apparemment contraire à ce que pourrait impliquer la documentation, mais la clé est continue vs non continue.
Une des principales raisons pour lesquelles seule la physique continue appartient FixedUpdate
est la nature réelle de FixedUpdate
. D'autres réponses ont mentionné comment FixedUpdate est appelé à un fixe interval, but that's slightly misleading. In reality, a script is passed a time in Time.deltaTime
/ Time.fixedDeltaTime
* qui ne correspond pas directement au temps réel entre les appels, mais plutôt au temps simulé entre les appels.
(* Time.deltaTime
et Time.fixedDeltaTime
ont la même valeur lorsqu'ils sont appelés dans FixedUpdate
[Unity est en mesure de dire si l'appel en Time.deltaTime
cours a commencé pendant FixedUpdate
et revient Time.fixedDeltaTime
])
Naturellement, la même manière Update
ne peut pas être appelée de manière constante en raison des performances variables, non plus FixedUpdate
. La principale différence est que, chaque trame, si elle FixedUpdate
n'a pas été appelée assez souvent pour faire la moyenne de l'intervalle correct entre les appels, elle est appelée plusieurs fois (ou n'est pas appelée, la moyenne est trop élevée). C'est ce à quoi se réfèrent les documents sur l'ordre d'exécution en disant que FixedUpdate peut être appelé plusieurs fois par image:
... FixedUpdate: FixedUpdate est souvent appelé plus fréquemment que Update. Il peut être appelé plusieurs fois par trame, si la fréquence d'images est faible et il peut ne pas être appelé du tout entre les trames si la fréquence d'images est élevée ...
Cela n'affecte pas la physique en raison de la nature du reste de l'ordre d'exécution et du moteur, mais à peu près tout ce que vous insérerez FixedUpdate
sera affecté et entraînera des problèmes.
Par exemple, si vous mettez le traitement de l'IA à l'intérieur, FixedUpdate
il n'y a aucune raison de supposer que l'IA ne sautera pas les mises à jour pour plusieurs images consécutives. De plus, chaque fois que `FixedUpdate prend du retard, votre IA se mettra à jour plusieurs fois dans une seule image avant que des choses comme la physique et l'entrée / le mouvement du joueur ne soient traitées, ce qui est à tout le moins un gaspillage de traitement, mais est également extrêmement susceptible de causer des problèmes pour rechercher les bogues et les comportements erratiques.
Si vous devez faire quelque chose à un intervalle fixe, utilisez d'autres méthodes fournies par Unity telles que Coroutines
et InvokeRepeating
.
Et une petite note sur Time.deltaTime
et quand l'utiliser:
La façon la plus simple de décrire l'effet de Time.deltaTime est de changer un nombre d'unité par image en unité par seconde . Par exemple, si vous avez un script avec quelque chose comme transform.Translate(Vector3.up * 5)
dans Update, vous déplacez essentiellement la transformation à une vitesse de 5 mètres par image . Cela signifie que si le framerate est faible, le mouvement est plus lent, et si le framerate est élevé, le mouvement est plus rapide.
Si vous prenez ce même code et le changez en transform.Translate(Vector3.up * 5 * Time.deltaTime)
, l'objet est déplacé à une vitesse de 5 mètres par seconde . Cela signifie que peu importe le débit d'images, l'objet se déplacera de 5 mètres toutes les secondes (mais plus le débit d'images est lent, plus le mouvement de l'objet apparaît rapidement car il se déplace toujours de la même quantité toutes les X secondes)
En général, vous voulez que votre mouvement soit par seconde. De cette façon, quelle que soit la vitesse de l'ordinateur, votre physique / mouvement se comportera de la même manière et vous n'aurez pas de bugs étranges sur des appareils plus lents.
Et cela ne sert à rien de l'utiliser FixedUpdate
. En raison de ce que j'ai mentionné ci-dessus, vous obtiendrez la même valeur à chaque appel (la valeur Fixed Update Timestep), et cela ne fera rien à vos valeurs. Le mouvement / physique défini dans FixedUpdate
va déjà être en unités par seconde, donc vous n'en avez pas besoin.