Memorizzazione di voxel per un motore voxel in C ++

Sto cercando di scrivere un piccolo motore voxel perché è divertente, ma faccio fatica a trovare il modo migliore per memorizzare i voxel reali. Sono consapevole che avrò bisogno di pezzi di qualche tipo, quindi non ho bisogno di avere l'intero mondo in memoria, e sono consapevole di aver bisogno di renderli con prestazioni ragionevoli.

Ho letto di ocre e da quello che ho capito inizia con 1 cubo, e in quel cubo possono esserci altri 8 cubi, e in tutti quegli 8 cubi possono esserci altri 8 cubi ecc. Ma non penso che questo si adatti al mio motore voxel perché i miei cubi / oggetti voxel avranno tutti la stessa identica dimensione.

Quindi un'altra opzione è quella di creare un array di dimensioni 16 * 16 * 16 e avere un pezzo, e lo riempi di elementi. E le parti in cui non ci sono articoli avranno 0 come valore (0 = aria). Ma temo che questo sprecherà molta memoria e non sarà molto veloce.

Quindi un'altra opzione è un vettore per ogni blocco e riempilo con cubetti. E il cubo mantiene la sua posizione nel blocco. Ciò consente di risparmiare memoria (senza blocchi d'aria), ma rende molto più lento la ricerca di un cubo in una posizione specifica.

Quindi non riesco davvero a trovare una buona soluzione e spero che qualcuno mi possa aiutare in questo. Quindi cosa useresti e perché?

Ma un altro problema è il rendering. Basta leggere ogni blocco e inviarlo alla GPU usando OpenGL è facile, ma molto lento. Generare una mesh per blocco sarebbe meglio, ma ciò significa che ogni volta che rompo un blocco, devo ricostruire l'intero blocco che potrebbe richiedere un po 'di tempo causando un piccolo ma evidente singhiozzo, che ovviamente non voglio neanche. Quindi sarebbe più difficile. Quindi come renderei i cubi? Basta creare tutti i cubi in un buffer di vertici per blocco e renderlo e magari provare a inserirlo in un altro thread o c'è un altro modo?

Grazie!

Memorizzare i blocchi come posizioni e valori è in realtà molto inefficiente. Anche senza alcun sovraccarico causato dalla struttura o dall'oggetto in uso, è necessario memorizzare 4 valori distinti per blocco. Avrebbe senso usarlo solo con il metodo di "memorizzazione dei blocchi in array fissi" (quello che hai descritto in precedenza) quando solo un quarto dei blocchi sono solidi, e in questo modo non prendi nemmeno altri metodi di ottimizzazione in account.

Gli Octrees sono in realtà fantastici per i giochi basati su voxel, poiché sono specializzati nella memorizzazione di dati con funzionalità più grandi (ad es. Patch dello stesso blocco). Per illustrare questo, ho usato un quadrifoglio (fondamentalmente octrees in 2d):

Questo è il mio set iniziale contenente 32x32 tessere, che equivarrebbe a 1024 valori:

Memorizzare questo come 1024 valori separati non sembra così inefficiente, ma una volta raggiunte dimensioni della mappa simili ai giochi, come Terraria , il caricamento delle schermate richiederebbe più secondi. E se lo aumenti alla terza dimensione, inizia a consumare tutto lo spazio nel sistema.

Quadtrees (o octrees in 3d) possono aiutare la situazione. Per crearne uno, puoi andare dalle tessere e raggrupparle insieme, oppure passare da una cella enorme e dividerla fino a raggiungere le tessere. Userò il primo approccio, perché è più facile da visualizzare.

Quindi, nella prima iterazione raggruppa tutto in celle 2x2 e se una cella contiene solo riquadri dello stesso tipo, elimini i riquadri e ne memorizzi il tipo. Dopo una ripetizione, la nostra mappa sarà simile a questa:

Le linee rosse segnano ciò che memorizziamo. Ogni quadrato ha solo 1 valore. Ciò ha portato la dimensione da 1024 valori a 439, con una riduzione del 57%.

Ma conosci il mantra . Facciamo un passo avanti e raggruppiamo questi in celle:

Ciò ha ridotto la quantità di valori memorizzati a 367. Questo è solo il 36% delle dimensioni originali.

Ovviamente devi fare questa divisione fino a quando ogni 4 celle adiacenti (8 blocchi adiacenti in 3d) all'interno di un blocco vengono archiviate all'interno di una cella, essenzialmente convertendo un blocco in una cella di grandi dimensioni.

Questo ha anche alcuni altri vantaggi, principalmente quando si fa una collisione, ma potresti voler creare un ottetto separato per quello, che si preoccupa solo del fatto che un singolo blocco sia solido o meno. In questo modo, invece di verificare la collisione per ogni blocco all'interno di un blocco, puoi semplicemente farlo contro le celle.

Esistono octrees per risolvere esattamente il problema che descrivi, consentendo una densa memorizzazione di dati sparsi senza grandi tempi di ricerca.

Il fatto che i tuoi voxel abbiano le stesse dimensioni significa solo che il tuo octree ha una profondità fissa. per esempio. per un pezzo 16x16x16, sono necessari al massimo 5 livelli di albero:

• chunk root (16x16x16)
  • ottante di primo livello (8x8x8)
    • ottante di secondo livello (4x4x4)
      • ottante di terzo livello (2x2x2)
        • voxel singolo (1x1x1)

Questo significa che hai al massimo 5 passaggi per scoprire se c'è un voxel in una particolare posizione nel blocco:

• chunk root: l'intero chunk ha lo stesso valore (es. tutta l'aria)? Se è così, abbiamo finito. Altrimenti...
  • primo livello: l'ottante che contiene questa posizione ha lo stesso valore? Altrimenti...
    • secondo livello...
      • terzo livello ...
        • ora stiamo affrontando un singolo voxel e possiamo restituire il suo valore.

Molto più breve rispetto alla scansione anche dell'1% del percorso attraverso una serie di fino a 4096 voxel!

Si noti che questo ci consente di comprimere i dati ovunque ci sia un ottante completo dello stesso valore, indipendentemente dal fatto che quel valore sia tutta aria o tutta roccia o qualsiasi altra cosa. È solo dove gli ottanti contengono valori misti che dobbiamo suddividere ulteriormente, fino al limite dei nodi foglia a singolo voxel.

Per rivolgersi ai figli di un pezzo, in genere procediamo nell'ordine di Morton , qualcosa del genere:

1. X- Y- Z-
2. X- Y- Z +
3. X- Y + Z-
4. X- Y + Z +
5. X + Y- Z-
6. X + Y- Z +
7. X + Y + Z-
8. X + Y + Z +

Quindi, la navigazione del nostro nodo Octree potrebbe assomigliare a questa:

GetOctreeValue(OctreeNode node, int depth, int3 nodeOrigin, int3 queryPoint) {
    if(node.IsAllOneValue)
        return node.Value;

    int childIndex =  0;
    childIndex += (queryPoint.x > nodeOrigin.x) ? 4 : 0;
    childIndex += (queryPoint.y > nodeOrigin.y) ? 2 : 0;
    childIndex += (queryPoint.z > nodeOrigin.z) ? 1 : 0;

    OctreeNode child = node.GetChild(childIndex);

    return GetOctreeValue(
                child, 
                depth + 1,
                nodeOrigin + childOffset[depth, childIndex],
                queryPoint
    );
}