Mostrare una collisione al rallentatore è rilassante dal punto di vista computazionale?


11

In molti giochi di corse ( Burnout Paradise , ad esempio) quando sta per verificarsi una collisione, il gioco passa automaticamente al rallentatore e prosegue in sequenza lenta fino al termine della collisione.

Ho sempre pensato che fosse per gli effetti. Non vuoi perdere nessuna parte della collisione! Ma uno dei miei amici ha recentemente suggerito che questo viene fatto per assicurarsi che non ci sia una velocità schiacciante di elaborazione richiesta quando si verifica una collisione.

Ora penso che sia effettivamente il contrario. Quando si verifica una collisione, molti dettagli vengono mostrati al rallentatore, sono sicuro che ci sia un sovraccarico nella pipeline di elaborazione e rendering.

Cosa è corretto?

Una scena al rallentatore aumenta l'utilizzo della CPU / GPU o la diminuisce?

Risposte:


4

Se stai eseguendo la tua simulazione fisica con un timestep fisso (come dovresti), un rallentatore caricherà meno la simulazione fisica, perché dovranno essere effettuati meno calcoli per frame.

Supponiamo che tu stia eseguendo la tua fisica con 200 aggiornamenti al secondo. Per esempio. un aggiornamento ogni 0.005secondo del tempo di simulazione. Quando si esegue il gioco con 50 aggiornamenti al secondo, ciò comporterebbe 4 aggiornamenti di fisica per aggiornamento di rendering. Ora eseguiresti il ​​gioco al rallentatore, ciò significa che stai rallentando i tempi di simulazione. Quindi, se il gioco continua a 50 aggiornamenti al secondo ( 0.02secondi del tempo di simulazione), ma stai mostrando il mondo al rallentatore (diciamo metà velocità), allora un fotogramma equivarrebbe a 0.01secondi di tempo di simulazione. Quindi solo 2 aggiornamenti di fisica per fotogramma renderizzato. Significa meno calcoli fisici per fotogramma renderizzato.

Quindi, se lo stai osservando dal punto di vista dell'utilizzo della CPU per fotogramma renderizzato, il rallentatore è meno pesante della CPU (a meno che tu non scelga di aumentare la velocità di simulazione fisica durante il rallentatore). Il carico della GPU per frame è ovviamente praticamente costante.

Se stai chiedendo il carico cumulativo CPU / GPU per la durata di una collisione , ovviamente la simulazione fisica è la stessa, sia al rallentatore che a velocità normale. Il carico della GPU sarà maggiore, perché si esegue il rendering di più frame.


Il tuo primo paragrafo parla del carico della GPU in aumento. Mi aspetto che il carico sulla GPU sia relativamente costante, o meglio affermato, direttamente correlato al framerate (supponendo che il contenuto della scena non cambi).
notlesh

Ha detto che era maggiore per collisione , ma è solo perché la collisione dura più a lungo. Come dice l'ultima frase del primo paragrafo.
MichaelHouse

Penso che nel caso medio i carichi dovrebbero rimanere tutti pressoché uguali: il codice attraverserà gli stessi passaggi in entrambi i modi e avrà quindi circa lo stesso carico. In casi speciali, penso che il carico sulla CPU sarà effettivamente più elevato nel caso del rallentatore se osservato durante la durata dell'intera collisione, poiché la loro risoluzione delle collisioni probabilmente funzionerà con un qualche tipo di fattore temporale che sarà molto più piccolo (riducendo le traduzioni risultanti) al rallentatore, aumentando la possibilità che vengano rilevate le collisioni per fotogramma, con conseguente risoluzione
TravisG

Non lo sto aggiungendo come risposta perché è proprio quello a cui riesco a pensare in questo momento e non ho dati o esperienza reale con i sistemi al rallentatore per il backup: P
TravisG,

2
@ Byte56 La domanda è "Una scena al rallentatore aumenta l'utilizzo di CPU / GPU?" Ciò [quasi] implica certamente un utilizzo per volta, non per collisione. Quindi penso che la risposta, per quanto riguarda la GPU, sia che rimanga invariata. Lo sollevo solo perché non è chiaro cosa il primo paragrafo stia cercando di comunicare.
notlesh

3

È possibile che sia così. A meno che tu non stia facendo fisica per la collisione con la GPU, significa accovacciarlo. Ma in termini di fisica stessa ... è possibile.

Se stai simulando il movimento di un numero di corpi, tendono a muoversi in modo molto prevedibile. Forze e campi di forza (es. Gravità) sono facilmente prevedibili. Dove le cose si muovono viene rapidamente calcolato.

Fino a quando una cosa colpisce un'altra. Vedi, in fisica, hai quello che viene chiamato timeslice; questo è il periodo di tempo coperto dall'esecuzione del sistema fisico. Se la tua fascia oraria copre 1/30 di secondo (30 fps per l'aggiornamento della fisica), ogni aggiornamento della fisica sposta gli oggetti di 33,3 millisecondi nel futuro.

Quando gli oggetti non si scontrano, puoi semplicemente spostarli dall'inizio di quei 33.3ms alla fine. La fisica per farlo è semplice ed è nota da secoli. È sufficiente determinare l'accelerazione dalle forze nette, applicare tale accelerazione per il timeslice all'oggetto e spostarlo alla sua nuova velocità (nota: questo può essere più complesso se si desidera una maggiore precisione).

Il problema è quando gli oggetti si scontrano. All'improvviso, ora devi elaborare le forze fisiche in un intervallo, piuttosto che una sola volta all'inizio. Se un oggetto si scontra due o tre volte all'interno di un riquadro di fisica, allora è necessario ripetere altri calcoli di fisica.

Se ci sono molte collisioni in una sola volta, puoi davvero uccidere il tuo framerate. Tuttavia, la possibilità di più collisioni all'interno di un intervallo è diminuita al diminuire della dimensione del periodo. Sim da corsa di fascia alta come Forza e Gran Turismo gestiscono i loro sistemi fisici con incredibili framerate. Penso che uno di loro ottenga fino a 300 + fps sul proprio aggiornamento di fisica.

Il rallentatore è l'equivalente effettivo di quello. Diminuendo il timelice della fisica senza aumentare anche il framerate di rendering per compensare, il mondo appare più lento. Pertanto, è molto meno probabile che si verifichino più collisioni in un intervallo di tempo.

Detto questo, dubito che sia per questo che giochi come questo vanno al rallentatore. In generale, è più per stile visivo e presentazione drammatica. Quei sistemi fisici possono generalmente gestirlo, per quanto riguarda le prestazioni.


1

Prima di tutto, questo viene fatto per l'effetto visivo, non per motivi di performance.

Il modo standard di gestire le prestazioni nei giochi pesanti di fisica è ridimensionare il numero di oggetti, ridimensionare la complessità degli oggetti e giocherellare con le impostazioni del motore per scalare tra precisione e prestazioni della simulazione. In caso di problemi, eliminerai quelle che ritieni siano le funzionalità meno significative.

Ricorda, tuttavia, che l'industria ha realizzato giochi di automobili piuttosto realistici negli ultimi 15 anni, con i computer moderni non è come se dovessero ridimensionarsi su 3 ruote per far funzionare le cose.

Il problema:
è vero che una collisione può causare lavoro extra, quanto dipende molto dalle specifiche del gioco, un motore fisico più dettagliato avrà molte piccole collisioni tra parti diverse che possono costituire un aumento significativo del calcolo richiesto . Ma questo dovrebbe essere preso in considerazione quando la fisica è ridimensionata, non è un problema ottenere una buona fisica che possa ancora gestire alcune collisioni.

Se si esegue semplicemente la simulazione fisica più lentamente per ottenere rallentatore, il carico diminuirà in modo proporzionale. Tuttavia, si dovrebbe notare che i requisiti per il rallentatore e la fisica in tempo reale sono diversi, puoi permetterti di avere una precisione inferiore quando le cose accadono a velocità di corsa. Finché il giocatore non nota che il motore fisico è sbagliato, non è un grosso problema, il rallentatore rende molto più facile la cattura degli scivoloni, quindi il rallentatore ha un requisito di precisione più elevato.

Si può scegliere di usare la stessa fisica, ridimensionata per soddisfare entrambe le serie di requisiti. Questa soluzione richiederà una potenza di elaborazione aggiuntiva, ma è facile da implementare e offre computer moderni perfettamente fattibili.

Il cambio delle impostazioni fisiche è più complicato, ma può potenzialmente provocare alcune collisioni meravigliose, non solo si può aumentare la precisione, ma è anche possibile cambiare i modelli fisici delle auto per quelli più dettagliati che si rompono in modo più realistico. Questa modalità dovrebbe finire per usare approssimativamente la stessa quantità di tempo della CPU per la fisica della modalità normale, semplicemente perché entrambi sono scalati per funzionare con la stessa configurazione di minspec.

Una via di mezzo è quella di utilizzare un motore fisico a passi variabili, che aumenteranno in generale la precisione quando rallenterai la simulazione, risolvendo così almeno una parte del problema. Ci sono altri motivi per non usare la fisica a passi variabili, ma il passo variabile è ancora abbastanza comune nel settore.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.