Ottimizzazione di una mesh per i paesaggi del cubo di voxel

Giocando con la creazione di paesaggi del mondo minecraft / lego in Unity 3D (paesaggi voxel generati proceduralmente con cubi), sto scoprendo che le maglie create per questi paesaggi occupano MOLTA memoria. La mesh attualmente consiste solo di vertici per i lati visibili di un cubo. L'utilizzo della memoria per un terreno complesso può richiedere 6 o 7 cento mega.

Queste maglie potrebbero essere ottimizzate, ma faccio fatica a trovare un algoritmo decente per farlo.

L'algoritmo deve tenere conto del fatto che non si desidera "unire" blocchi di diversi tipi di terreno. Immagino che un inizio davvero semplice potrebbe essere solo quello di elaborare tutti i blocchi lungo un asse e fare ulteriori spostamenti per gli altri due assi.

Devo mantenere la forma della mesh, ovvero non unire i vertici al punto in cui viene modificato lo spazio vuoto o solido. Il motivo è che potrebbero esserci creature / etc che devono ancora navigare nella mesh. Quindi non posso semplicemente creare un dettaglio molto basso, mesh distorta.

Hai pensieri / suggerimenti / suggerimenti su questo?

3d-meshes optimization voxels

— James Livingston
fonte

Perché stai memorizzando vertici per un cubo di dimensioni note? Fallo algoritmicamente; oppure usa un buffer di vertici condiviso.

— deceleratedcaviar

Perché maglia poligonale? Voxel può essere reso in modo abbastanza efficiente proprio come loro . Per un cubo voxel sono necessari 3 float (x, y, z), per 1 riquadro Sono necessari circa 8 * 3 float (8 vertici) e nel caso in cui si abbiano bordi e poligoni impliciti. Forse Unity non è lo strumento per questo problema voxel.

— user712092,

Risposte:

La mia domanda è:

Perché avresti bisogno della maglia stessa per fare il movimento della creatura?

Non riesci a fare il calcolo del percorso su una matrice 3d di ID?

Penso che Minecraft utilizzi una matrice 3d con blocco pr a 4 bit. Simula anche solo creature di un certo raggio attorno al giocatore.

Potresti conservare i tuoi pezzi in una struttura ad albero, dove ogni pezzo è compresso.

Se si mantengono i dati compressi nella RAM, è possibile decomprimere i dati abbastanza rapidamente quando necessario.

testo alternativo

— fabbricante di chiodi
fonte

Facevo affidamento sull'avere la mesh per il rilevamento delle collisioni integrato con Unity, ma non c'è nulla che mi impedisca di testare le collisioni / i percorsi su una struttura di dati personalizzata. Tuttavia, devo ancora creare una mesh visibile per visualizzare il terreno, e questo è ciò che devo ottimizzare.

— James Livingston,

Un altro punto ... come puoi vedere dallo screenshot ... non c'è molto terreno pianeggiante. Le mesh sono generalmente superfici ruvide di cubi, ma penso che ci sia spazio per l'ottimizzazione delle facce / vertici della mesh. Sembra che un ottetto sarebbe il migliore per i dati che hanno molti blocchi di dati simili, invece dei dati "jaggy". O questo non è corretto?

— James Livingston,

@Gatorfrog: Ricorda, anche lo spazio vuoto è un dato. se è irregolare, certo, ci saranno molti bit che segnalano che è vuoto. L'ottavo è lì solo per capire quali pezzi dovresti decomprimere prima di renderli. Lo spazio vuoto sarà solo un mucchio di zero. La mia giornata di lavoro implica lavorare con una libreria di rendering voxel molto sofisticata. Il mio prossimo post descriverà cosa fanno.

— Nailer,

La libreria con cui lavoro fa quanto segue: Crea blocchi di dati e li archivia in un database di file flat. Ogni blocco ha un ID. Ogni cubo è composto da molti pezzi. Per ogni blocco viene creato un certo numero di livelli di dettaglio. Laddove il livello più alto di dettaglio ha il 100% dei voxel, il secondo più alto ha il 25% di tutti i voxel e quindi dividere per 4 tutti per ogni livello successivo. I pezzi vicini a te possono essere visualizzati utilizzando il massimo livello di dettaglio.

— Chiodatrice,

tutti i dati vengono spediti in forma compressa dalla RAM alla VRAM, dove vengono gonfiati dagli algoritmi di compressione GPGPU in esecuzione in CUDA. Ciò consente di risparmiare molta memoria con banda. Quindi: controlla dove si trova il giocatore e ottieni livelli elevati di dettagli lì, le cose più lontane possono essere facilmente visualizzate usando uno dei LOD inferiori.

— Chiodatrice,

Che ne dici di usare un octree per conservare il terreno?

Ad esempio aria = nessun nodo, tutti gli altri tipi di terreno avrebbero un nodo con il tipo di terreno.

Quando si inseriscono / rimuovono nodi, è possibile verificare se tutti e otto i figli di ciascun nodo sul percorso dell'albero modificato hanno lo stesso tipo di terain e unirli se necessario. In questo modo, grandi blocchi dello stesso materiale occuperebbero solo un nodo.

— Exilyth
fonte

Stai creando i cubi solo per parti della geometria che il giocatore può vedere? Questo sarebbe il mio primo passo. A seconda delle dimensioni del tuo terreno, non devi caricare l'intero mondo / disegno / visibile / qualunque cosa.

— tetrade
fonte

Sto solo creando la mesh per i lati dei cubi che hanno aria vuota accanto a loro. Per quanto riguarda il non disegnare maglie che il giocatore non può vedere ... Ho pensato di escludere blocchi che non avevano blocchi visibili, come grotte sotterranee o buchi che portavano nel terreno in un angolo. A quel punto non sarei sicuramente in grado di fare affidamento sulle mie maglie per collisioni / percorsi.

— James Livingston,