Come posso incorporare la fisica in un mondo generato proceduralmente da uno shader di geometria?

In sostanza, desidero rimuovere la necessità di generare rumore coerente dalla CPU alla GPU. Da lì, voglio anche generare il terreno per un mondo tridimensionale usando questo rumore come densità nei punti voxel. Dopo questo, voglio prendere quelle densità e poligonizzarle (generare vertici) che rappresentano il terreno del mondo.

Va tutto bene. Ma voglio anche deformare dinamicamente il mondo in tempo reale. Una volta arrivato a questo punto, ho un problema nel tentativo di riportare i vertici nella CPU per fare cose come il rilevamento delle collisioni e tutti i calcoli di gioco che voglio coinvolgere sulla CPU e non sulla GPU.

Quindi la domanda è: come posso riportare un sottoinsieme dei vertici nella CPU per gestire le collisioni tra le altre cose?

E un'altra domanda: esiste un modo semplice per prendere una serie di vertici e generare indici da essi sulla GPU?

Sono confuso e che tipo di shader dovrei usare per queste diverse cose. Ho sentito parlare di persone che usano un pixel shader per raccogliere densità e poi usare uno shader di geometria per gestire la generazione del terreno dai vertici e quindi in qualche modo incorporare uno shader di vertice per fare le deformazioni dinamiche.

Sto usando C # 4.0, .NET 4.0 e XNA Game Studio 4.0.

c# xna shaders

— Michael J. Gray
fonte

Dici che stai usando uno shader di geometria nel titolo, ma dici anche che stai usando XNA4.0, per quanto ne so XNA 4.0 richiede DirectX 10 (per rendere più semplice lo sviluppo per una piattaforma più uniforme) ma supporta solo le funzionalità SM3.0, quindi nessuno shader di geometria. forums.create.msdn.com/forums/p/31369/178924.aspx

— Roy T.

E ora non userò più XNA o rielaborerò il mio progetto. Grazie per la segnalazione. Ci avevo pensato e non avevo realizzato questa limitazione (no SM 4). Suppongo che la domanda rimanga comunque, senza la considerazione di XNA. Quindi, da una prospettiva solo DirectX, c'è un modo per fare quello che voglio? O forse con uno shader di vertice in XNA?

Bene, XNA è ancora valido da usare, a meno che tu non abbia un caso di prova comprovato in cui fare deformazioni e generazione è troppo lento. E che hai dimostrato in un altro caso di prova che la GPU deforma + generazione e quindi il recupero dei dati nella CPU è più veloce :)

— Roy T.

Infatti. Abbiamo scoperto che l'uso di XNA e il mantenimento di tutto sulla CPU ci ha dato circa 1 milione di vertici in circa tre minuti su un Core i7 con 8 core e 8 thread che parallelizzano più sezioni di terreno per thread. Quando abbiamo provato a farlo in tempo reale e speriamo di rendere il terreno prima che il giocatore potesse vederlo, abbiamo raggiunto circa 20 fotogrammi al secondo. Quindi, un caso di test è sicuramente in ordine con ciascuno dei metodi.

— Michael J. Gray,

Poiché XNA non supporta gli shader di geometria, risponderò come se stessi usando DX 10. In sostanza, hai tre opzioni.

Shader di geometria Gli shader di geometria possono effettivamente modificare e aggiungere vertici a un buffer di vertici. Potresti rileggerlo nella CPU. Non ci ho pensato, ma è sicuramente possibile.

Basta usare la CPU In secondo luogo, perché non calcolarla semplicemente sulla CPU? Il fatto che venga eseguito sulla GPU negli shader suggerisce che l'algoritmo di deformazione è localizzabile, ovvero è possibile generare facilmente solo le parti relavent per il controllo delle collisioni.

Ad esempio, ho fatto un gioco di vela qualche tempo fa. L'oceano ha usato i vertici e gli shader della geometria per deformare l'acqua con le onde. Ho usato lo stesso algoritmo calcolato sulla CPU in pochi punti sotto la barca per il movimento della barca tra le onde. Sono sicuro che potresti fare qualcosa di simile per la tua mappa voxel.

Pixel shader L'ultima opzione, hai menzionato anche questo nella tua domanda: generare le densità nel pixel shader e scriverlo su una trama 3D. Puoi accedervi dalla CPU e dagli shader in modo abbastanza innocuo. Il pixel shader è perfetto per questa attività, ma questo metodo ha molte spese generali. Rendering della trama del volume, nonché campionamento da dentro nel vertice e geo. shader e dover leggere la trama sulla CPU.

Non conosco i dettagli del tuo progetto, ma per questo utilizzerei sempre la CPU. Certamente calcola anche le densità sugli shader, ma continua a usare la scheda grafica per il rendering.

— Hannesh
fonte

Il problema principale che abbiamo avuto è stata la barriera GPU-CPU. Nel senso che, una volta generato e reso il terreno sulla GPU, come possiamo capire come appare il terreno sul lato CPU delle cose per fare collisioni e altre cose. Suppongo che il tuo pensiero di tenerlo sulla CPU sia valido. Voglio dire, probabilmente possiamo ottimizzare un po 'il nostro algoritmo e generare meno terreno. Contrassegnerò la tua risposta come soluzione tra un giorno o due per vedere se qualcun altro ha una risposta. Grazie per provocare alcuni pensieri alternativi.

— Michael J. Gray,

Con il tuo esempio di navigazione, non saresti in grado di collegare facilmente il risultato della forma d'onda di una barca che schizza attraverso le onde alla GPU, giusto?

— Deceleratedcaviar

Puoi mantenere lo stesso sistema di rendering, ovvero generare e renderizzare il terreno sulla GPU, ma rispecchiare le parti del terreno necessarie sulla CPU. Utilizzando lo stesso algoritmo e gli stessi parametri, otterresti lo stesso terreno sulla CPU che vedi sullo schermo.

— Hannesh,

@Daniel Non direttamente con l'algoritmo wave, ma è possibile deformare la maglia d'acqua secondo la scia della barca con una trama di spostamento che ogni barca "trascina" dietro di essa.

— Hannesh,

Ah! Questa è una grande idea :). Ma probabilmente non supporta molto bene le imbarcazioni multiple.

— deceleratedcaviar