In che modo i motori di giochi commerciali organizzano i buffer di indice / vertice?

Prefazione: questa domanda verrà dal punto di vista di Direct3D, perché è questo che mi è familiare.

Ovviamente subiamo un leggero sovraccarico ogni volta che cambiamo i vertici o i buffer degli indici in Direct3D (cioè con IASetIndexBuffer). Ma suppongo che se allociamo un gigantesco buffer indice / vertice finiremo per dover gestire la memoria manualmente e per finire con un problema di frammentazione (o pause mentre scambiamo tutti i dati).

In che modo i motori commerciali caricano / scaricano i dati? Sono un po 'propenso ad un approccio basato sul' pacchetto ', quindi un' pacchetto 'di modelli ha il suo buffer vertice / indice che possiamo caricare / scaricare poiché il pacchetto non è più necessario; e quindi prova a disegnare tutte le istanze dallo stesso pacchetto insieme.

Ma sarei interessato a sapere qual è il modo accettato / standard di gestione di questo?

Esistono diverse tecniche per organizzare i dati e molti giochi ne usano un mix.

Per la geometria statica, è meglio avere meno singoli IB e VB.

Tradizionalmente i giochi si basano sul livello, il che significa che vengono caricate le risorse per una sezione di gioco e quindi inizia il gioco. Per ridurre al minimo i tempi di caricamento, le informazioni sono organizzate in modo ideale per supportare ciò (ovvero caricare tutto per il livello il più velocemente possibile senza cercare sul supporto / disco), possibilmente replicando le informazioni tra i livelli. In questo approccio, uno schema consiste nell'avere un VB e IB di grandi dimensioni per un modello o una serie di modelli, quindi inviare sottoinsiemi da quello da disegnare.

Per la generazione Xbox 360 / PS 3, la quantità di RAM era piuttosto piccola rispetto alle dimensioni dei giochi, quindi i motori sono diventati orientati allo "streaming", il che significa che caricano i contenuti dinamicamente mentre il giocatore si muove attraverso di essi. Questo è anche chiamato un approccio "open world". In questo approccio, la sfida è "tagliare" la geometria in bit che è possibile caricare in base a suggerimenti spaziali. Un'altra sfida, in particolare per le piattaforme a 32 bit, è garantire che la memoria non diventi frammentata (o anche frammentazione dello spazio degli indirizzi virtuali) per un lungo periodo di tempo: i giochi basati su livelli spesso ripristinano la memoria tra i livelli, cosa che i motori di streaming non possono fare così facilmente. Pertanto, è utile impacchettare in una dimensione fissa o in una serie di dimensioni fisse per gli IB / VB che sono stati allocati e riutilizzati come pool.

Per la generazione Xbox One / PS 4, c'è molta RAM con cui lavorare rispetto alle console precedenti e molti core extra, quindi molti giochi comprimono in modo aggressivo i loro asset e quindi utilizzano core CPU "extra" per decomprimerli nel sfondo. Con lo spazio degli indirizzi virtuali a 64 bit, c'è meno preoccupazione per la frammentazione dello spazio degli indirizzi virtuali. Questo approccio mantiene bassi i tempi di caricamento, integra bene le risorse per il download digitale e supporta il rendering "open world". Qui viene utilizzato l'approccio pool alla gestione di IB / VB.

Esiste anche l'invio di geometria dinamica che viene spesso utilizzato per terreni, modelli deformabili / distruttibili, ecc. Non è efficiente in termini di larghezza di banda del bus GPU, quindi i giochi hanno spesso un mix di geometria statica e dinamica. In questo caso, il modello di aggiornamento DISCARD di Direct3D Map in genere indica che si sta utilizzando un solo IB / VB (o per scenari di rendering multithread, doppio IB / VB con cui si scambia il riempimento / rendering di ciascun fotogramma).