Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
Utilizzo dell'interpolazione fisica
Come integriamo l'interpolazione fisica in un gioco di Godot? C'è qualche avvertenza?
Abbiamo cercato di rendere il sistema il più semplice possibile da usare, e molti giochi esistenti funzioneranno con poche modifiche. Detto questo, ci sono alcune situazioni che richiedono un trattamento speciale, e queste saranno descritte di seguito.
Attivare l'impostazione dell'interpolazione fisica
Il primo passo è attivare l'interpolazione fisica in Impostazioni del progetto > Fisica > Comune > Interpolazione fisica. Ora si può eseguire il gioco.
È probabile che nulla sembri molto diverso, soprattutto se si esegue la fisica a 60 TPS o a un multiplo di essa. Tuttavia, dietro le quinte sta succedendo molto di più.
Suggerimento
Per convertire un gioco esistente in modo che utilizzi l'interpolazione, è altamente consigliato impostare temporaneamente Impostazioni del progetto > Fisica > Comune > Tick di fisica al secondo su un valore basso, ad esempio 10, che renderà più evidenti i problemi di interpolazione.
Spostare (quasi) tutta la logica di gioco da _process a _physics_process
Il requisito fondamentale per l'interpolazione fisica (che si potrebbe già aver già implementato) è che sia necessario spostare ed eseguire la logica di gioco sugli oggetti all'interno di _physics_process (che è eseguito a ogni tick di fisica) anziché di _process (che è eseguito su un frame renderizzato). Ciò significa che gli script dovrebbero in genere svolgere la maggior parte della loro elaborazione all'interno di _physics_process, inclusa la risposta agli input e all'IA.
Impostando la trasformazione degli oggetti solo all'interno dei tick di fisica, l'interpolazione automatica gestisce le trasformazioni tra i tick di fisica e garantisce che il gioco funzioni allo stesso modo su qualsiasi computer. In più, ciò riduce anche l'utilizzo della CPU se il gioco renderizza ad alti FPS, poiché la logica dell'IA (ad esempio) non sarà più eseguita su ogni frame renderizzato.
Nota
Se si tenta di impostare la trasformazione degli oggetti interpolati fuori dal tick di fisica, i calcoli per la posizione interpolata saranno errati, e pertanto avverrà un tremolio. Questo tremolio potrebbe non essere evidente sul computer in uso, ma avverrà per alcuni giocatori. Per questo motivo, si dovrebbe evitare di impostare la trasformazione degli oggetti interpolati fuori dal tick di fisica. Godot tenterà di generare avvisi nell'editor se questo caso viene rilevato.
Suggerimento
Questa è solo una regola flessibile. Ci sono alcune occasioni in cui potrebbe essere desiderato teletrasportare oggetti fuori dal tick di fisica (ad esempio all'inizio di un livello o quando si rigenerano oggetti). In generale, si dovrebbero comunque applicare le trasformazioni dal tick di fisica.
Assicurarsi che tutti i movimenti indiretti avvengano durante i tick di fisica
Si consideri che in Godot, i nodi si possono spostare non solo direttamente nei propri script, ma anche tramite metodi automatici come tweening, animazione e navigazione. Tutti questi metodi dovrebbero inoltre avere la loro temporizzazione impostata per operare sul tick di fisica piuttosto che su ogni frame ("idle"), se si usano per spostare oggetti (è possibile usare questi metodi anche per controllare proprietà non interpolate).
Nota
Also consider that nodes can be moved not just by moving themselves, but also by moving parent nodes in the SceneTree. The movement of parents should therefore also only occur during physics ticks.
Scegliere una frequenza di tick di fisica
When using physics interpolation, the rendering is decoupled from physics, and you can choose any value that makes sense for your game. You are no longer limited to values that are multiples of the user's monitor refresh rate (for stutter-free gameplay if the target FPS is reached).
As a rough guide:
Frequenze di tick basse (10-30) |
Frequenze di tick medie (30-60) |
Frequenze di tick alte (60+) |
|---|---|---|
Migliori prestazioni sulla CPU |
Buon comportamento fisico in scene complesse |
Buono con fisica rapida |
Add some delay to input |
Ideale per giochi in prima persona |
Ideale per giochi da corsa |
Simple physics behaviour |
Nota
È sempre possibile cambiare la frequenza di aggiornamento (tick rate) durante lo sviluppo, basta modificare l'impostazione del progetto.
Chiamare reset_physics_interpolation() quando si teletrasportano oggetti
Most of the time, interpolation is what you want between two physics ticks. However, there is one situation in which it may not be what you want. That is when you are initially placing objects, or moving them to a new location. Here, you don't want a smooth motion between where the object was (e.g. the origin) and the initial position - you want an instantaneous move.
The solution to this is to call the Node.reset_physics_interpolation function. What this function does under the hood is set the internally stored previous transform of the object to be equal to the current transform. This ensures that when interpolating between these two equal transforms, there will be no movement.
Even if you forget to call this, it will usually not be a problem in most situations (especially at high tick rates). This is something you can easily leave to the polishing phase of your game. The worst that will happen is seeing a streaking motion for a frame or so when you move them - you will know when you need it!
In realtà ci sono due modi per usare reset_physics_interpolation():
Standing start (e.g. player)
Imposta la trasformazione iniziale
Chiama
reset_physics_interpolation()
The previous and current transforms will be identical, resulting in no initial movement.
Moving start (e.g. bullet)
Imposta la trasformazione iniziale
Chiama
reset_physics_interpolation()Immediately set the transform expected after the first tick of motion
The previous transform will be the starting position, and the current transform will act as though a tick of simulation has already taken place. This will immediately start moving the object, instead of having a tick delay standing still.
Importante
Make sure you set the transform and call
reset_physics_interpolation() in the correct order as shown
above, otherwise you will see unwanted "streaking".
Test e consigli per il debug
Even if you intend to run physics at 60 TPS, in order to thoroughly test your interpolation and get the smoothest gameplay, it is highly recommended to temporarily set the physics tick rate to a low value such as 10 TPS.
The gameplay may not work perfectly, but it should enable you to more easily see cases where you should be calling Node.reset_physics_interpolation, or where you should be using your own custom interpolation on e.g. a Camera3D. Once you have these cases fixed, you can set the physics tick rate back to the desired setting.
The other great advantage to testing at a low tick rate is you can often notice
other game systems that are synchronized to the physics tick and creating glitches
which you may want to work around. Typical examples include setting animation blend
values, which you may decide to set in _process() and interpolate manually.
Nota
In 2D, the position of visible collision shapes shown by the option will take physics interpolation into account.
By contrast, in 3D, the position of visible collision shapes will not take physics interpolation into account. This means the visible collision shapes can appear to move less smoothly and appear slightly in front of the object's visual representation when the object is moving. This is not a bug, but a consequence of how physics interpolation is implemented in 3D.