OpenGL vs fisica?


8

Sono molto nuovo nella programmazione dei giochi e sono nel mio primo progetto. Sono arrivato al punto in cui ho bisogno del parere di un esperto:

Ora che la fisica del gioco sia in grado di lavorare sugli oggetti, deve conoscere la posizione di ciascun oggetto e il suo orientamento nello spazio 3D. Come parte della simulazione e per via degli oggetti si sposta (cambio di posizione) e cambia orientamento (rotazione).

Ciò significa che la rotazione e il calcolo della traduzione vengono eseguiti due volte? Uno in fisica e l'altro è fatto usando glTranslate e glRotate prima di disegnare l'oggetto?

IMO questo non dovrebbe succedere. Anche il calcolo della traduzione e della rotazione nella parte fisica li farà utilizzare la CPU anziché la GPU, il che influirà sulle prestazioni.

In che modo vengono eseguiti gli esperti e quali consigli offri sull'architettura di gioco efficiente per gestire tali situazioni?

Risposte:


17

Esistono diversi motivi per cui le condutture di rendering e fisica sono state tradizionalmente mantenute discrete. Tieni a mente mentre li elenco, che non si tratta solo di giochi. La tua domanda tocca qualsiasi applicazione che utilizza una tecnologia di rendering 3D come OpenGL, i suoi concorrenti o i suoi predecessori.

  • Non tutte le applicazioni che usano il 3D hanno bisogno della fisica. Ricorda che OpenGL non è stato creato solo per i giochi, il suo utilizzo copre tutto, dalle simulazioni mediche alla modellazione delle statistiche delle vendite, dalle simulazioni del traffico aereo alle complesse reazioni chimiche, e così via.
  • Qualsiasi sistema che serve troppi scopi viene diluito in termini di efficienza. Una pipeline grafica deve essere incredibilmente veloce. Nel momento in cui inizi a introdurre punti in cui quella pipeline deve interfacciarsi con altri sottosistemi come la memoria di sistema principale (dove risiede il tuo codice), sperimenterai riduzioni dell'ordine di grandezza in termini di efficienza. L'hardware della tua scheda grafica è molto specifico e ultra-ottimizzato per la spinta dei pixel , a costi elevati e molti anni di ricerca altamente competitiva.

  • La natura della matematica e delle strutture di dati che circondano le operazioni di fisica (in particolare il rilevamento e la risoluzione delle collisioni, senza le quali non esiste davvero fisica ) è ampiamente diversa dalla matematica richiesta per il rendering.

  • Esistono soluzioni che si occupano di fisica nell'hardware. Ma a differenza del modo in cui rendiamo, il modo in cui eseguiamo la fisica in una determinata situazione differisce ampiamente. L'indicazione fondamentale di ciò è che la fisica newtoniana non è adatta a tutti; ci sono altri modi per modellare matematicamente la fisica che sono più appropriati in altre situazioni, come la meccanica hamiltoniana. E in particolare nei giochi, ogni singolo gioco può scegliere di modellare la propria fisica in modo diverso, sia in 2D che in 3D. Questi non devono nemmeno riflettere la fisica del mondo reale! - perché un gioco è un prodotto dell'immaginazione. In altre parole, la fisica è in definitiva parte della dinamica del tuo gioco e ciò può cambiare da gioco a gioco - per non parlare di tutte le altre soluzioni a cui vengono applicate tecnologie come OpenGL.
  • La simulazione accurata della fisica a livello di vertice per vertice non è, per la maggior parte, attualmente un'opzione praticabile. Dati gli alti conteggi dei modelli nella maggior parte dei giochi e la difficoltà intrinseca del rilevamento delle collisioni che coinvolge poliedri concavi, non è così semplice come calcolare la fisica dal modello fornito. Per molti, se non per la maggior parte dei giochi 3D, i volumi di delimitazione sotto forma di cilindri o scatole vengono utilizzati per semplificare il rilevamento delle collisioni, dove è persino richiesto quel tipo di rilevamento delle collisioni. Data l'attuale tecnologia, il livello di elaborazione coinvolto non lascerebbe molto spazio per il resto della logica di gioco. Anche il PhysX di Nvidia richiede poliedri complessi e concavi per essere decomposti in poliedri convessi più semplici, per la simulazione fisica.

  • La tua scheda grafica sta producendo una prospettiva con le trasformazioni che esegue. Ciò è diverso dalle trasformazioni eseguite in fisica, che non hanno nulla a che fare con la prospettiva in quanto tale - sta semplicemente calcolando posizioni e orientamenti di base nel tuo mondo. Se conosci MVC, capirai che esiste una netta differenza tra i dati che conservi nella tua applicazione e come li presenti .

L'industria della tecnologia informatica è guidata dalla necessità e, sebbene la visualizzazione sia un'esigenza quasi universale, le simulazioni fisiche non sono affatto universali né come requisito né in termini delle rispettive implementazioni.

Quindi il mio consiglio è, smetti di preoccuparti di andare controcorrente e inizia a concentrarti su come fare le due cose che devi fare: rendering e fisica. Non otterrai i dati nella pipeline di elaborazione della tua scheda grafica (CUDA / OpenCl sono eccezioni): inserisci triangoli e dati sui materiali, pompa il tuo mondo 3D come immagine in movimento.


A parte il finale, la tua domanda non è senza senso. Il desiderio di una base combinata per la fisica e il rendering, e il fatto che la matematica in virgola mobile può essere molto più lenta del punto fisso, ci mostra perché le tecnologie voxel stanno assistendo a un enorme ritorno di interesse: semplificano il mondo intero fino a posizionarlo sulla griglia poliedri convessi allineati ad asse. Ciò migliora enormemente le prestazioni, riducendo la quantità di matematica vettoriale in virgola mobile necessaria per le operazioni fisiche, poiché ora si lavora principalmente in una griglia suddivisibile spazialmente, installabile, indicizzata per intero. Questa stessa griglia può essere utilizzata sia per il rendering che per la fisica, in particolare in quanto è possibile utilizzare risoluzioni della griglia diverse per questi due sottosistemi distinti (quando si utilizza una soluzione basata su octree come SVO).


3
Il quinto punto elenco deve essere enfatizzato maggiormente: in genere si utilizza la geometria di collisione che è separata dalla geometria visiva.
jhocking

La tua risposta è molto perspicace. Grazie mille. Ho pensato di usare OpenCL per il codice fisico. Ciò farà sì che le operazioni di trasformazione della matrice di cui ho parlato siano eseguite sulla GPU e dovrebbero dare un po 'di miglioramento delle prestazioni. Cosa ne pensi, è una buona idea?
M.Sameer

3
È un piacere. "Dovremmo dimenticare le piccole efficienze, diciamo circa il 97% delle volte: l'ottimizzazione prematura è la radice di tutti i mali" -Donald Knuth. Concentrati sulla tua logica e ottimizza come e dove ti serve. Sei troppo preoccupato per le prestazioni in quello che presumo sia una fase molto precoce dello sviluppo del tuo gioco. È molto più facile rallentare di più quando si condivide l'elaborazione tra CPU e GPU come con CUDA / OpenCL. Google "CUDA slow", troverai molti risultati. Ciò che si invia alla GPU deve essere messo in batch con molta attenzione. Non aspettarti di scrivere ogni pochi millisecondi, ecc.
Ingegnere
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.