Qual è il miglior metodo LOD per il rendering dei pianeti?

Attualmente sto lavorando alla mia tesi, è un motore per rendere terreni di dimensioni planetarie.

Sto ancora terminando la mia ricerca e ho riscontrato molte cose su questo argomento, il problema è che non riesco a decidere quale metodo di livello di dettaglio (LOD) dovrei usare.

Conosco il geomipmapping, la geometria clipmap (GPU) e il LOD in pezzi di Ulrich che funzionano bene su terreni di grandi dimensioni e possono essere usati per rendere 6 facce di un cubo e poi "sferificare" il cubo con questo metodo e capisco come implementare tutto questi metodi su GPU usando C ++ / OpenGL / GLSL (usare metodi come ROAM o qualsiasi altro metodo che non usa un cubo è fuori dalla mia portata perché la trama è una seccatura). Anche di recente ho avuto in un tutorial di terreni di rendering utilizzando shader tessellazione qui

Quindi, non ho il tempo di implementare TUTTI i metodi e vedere quale è il migliore e più adatto per una scala planetaria e sto chiedendo qui per vedere se qualcuno ha fatto questo tipo di confronto e aiutarmi a decidere quale metodo dovrei implementarlo e usarlo (il mio tutor è un po 'pazzo e vuole che io faccia qualcosa con un icosaedro, ma non riesco a capire quel metodo se non usando ROAM)

Comunque, se mi puoi aiutare a decidere o avere altri suggerimenti o metodi, lo apprezzerò davvero. Una condizione è che il metodo dovrebbe essere in grado di implementare il lato GPU (almeno la maggior parte) per evitare colli di bottiglia della CPU.

Un'altra richiesta è che so che ci sono problemi numerici sulla precisione con i galleggianti quando si ottengono molti dettagli sul terreno, non so come risolverlo, leggo una soluzione in un forum ma non riesco a capire come Ho perso traccia di quel thread e vorrei sapere come risolvere questo problema di precisione.

Attualmente sto leggendo alcune trasformazioni della matrice per risolvere la precisione del float, i problemi di z-fighting, l'abbattimento del frustum con valori z dinamici e la rappresentazione dei dati per i blocchi (usando lo spazio patch con float e la sua posizione nelle coordinate del mondo come doppia) quindi Penso di poter risolvere facilmente il problema della precisione. Ho ancora bisogno di un confronto tra i metodi LOD con le tue opinioni e i tuoi suggerimenti per decidere quale sia la soluzione migliore per questo progetto. Prendi in considerazione la difficoltà di implementazione vs qualità visiva vs prestazioni, voglio il meglio.

Qualcosa che ho dimenticato di menzionare è che la generazione è ibrida, voglio dire, dovrei essere in grado di rendere il pianeta interamente usando GPU (altezze calcolate al volo) e / o usando un'immagine di mappa altezza base e aggiungere dettagli con GPU (vertice Shader). La trama sarà una parte laterale di cui mi preoccuperò, in questo momento sono felice di usare solo i colori a seconda dell'altezza, o forse usare una sorta di trama del rumore generata sullo shader di frammenti.

Alla fine, dopo molte ricerche, posso concludere che, come qualcuno ha detto prima, non esiste un metodo universalmente "migliore". Ma la mia ricerca mi ha portato alla conoscenza delle seguenti cose:

A seconda della mesh utilizzerai finalmente:

• Cubo sferificato: qualsiasi metodo LOD con implementazione quadtree funzionerà perfettamente, devi solo occuparti di casi speciali come i bordi tra le facce, nel qual caso il tuo quadtree deve avere un puntatore al vicino nella faccia adiacente in ogni livello.
• Qualsiasi altro: penso che ROAM (la nuova versione 2.0 o qualsiasi altra estensione come BDAM, CABTT o RUSTIC) farà bene, tuttavia, questi algoritmi sono difficili da lavorare, richiedono più memoria e sono un po 'più lenti rispetto ad altri approcci con i cubi.

Esistono molti metodi LOD che possono adattarsi bene, ma i miei primi 5 personali sono:

1. LOD dipendente dalla distanza (CDLOD)
2. ClipArt Geomety Based GPU (GPUGCM)
3. Chunked LOD
4. Rendering di terreni con OpenGL GPU Tessellation (Libro: OpenGL Insight, Capitolo 10)
5. MipMapping geometrico

Ognuno offre un modo unico per rendere i terreni, ad esempio, CDLOD ha un'implementazione molto semplice usando shader (GLSL o HLSL) ma è anche in grado di essere implementato su CPU (per hardware legacy) tuttavia l'obiettivo su Planet Rendering è quello di far esplodere il meglio sulle moderne GPU, quindi GPUGCM è il migliore quando vuoi spremere la tua GPU. Entrambi funzionano molto bene con il rendering basato su dati, procedurale o misto (terreno basato su dati fissi o altezze e dettagli aggiunti con il lavoro procedurale) per il rendering di grandi terreni.

Esiste anche l'estensione sferica al metodo base Clipmap geometrica ma presenta alcuni problemi perché i campioni planari della mappa altezza devono essere parametrizzati utilizzando coordinate sferiche.

Chunked LOD, d'altra parte, è perfetto per l'hardware legacy, non ha bisogno di calcoli laterali della GPU per funzionare, è perfetto per set di dati di grandi dimensioni ma non può gestire i dati procedurali in tempo reale (forse con alcune modifiche, potrebbe)

L'utilizzo degli shader Tessellation è un'altra tecnica, molto nuova, da quando OpenGL 4.x è uscito, secondo me potrebbe essere il migliore, ma, stiamo parlando di Planet Rendering, incontriamo un problema che altri metodi possono gestire molto facilmente ed è sulla precisione.

A meno che tu non voglia solo che la tua precisione sia di 1Km tra i vertici, scegli gli shader di tassellatura. Il problema con terreni molto grandi con questo metodo è che il jitter è un po 'difficile da risolvere (o almeno per me, poiché sono nuovo agli shader di tassellatura).

Il geomipmapping è un'ottima tecnica, sfrutta il quadrifoglio e presenta un errore pixel proiettato basso, ma, per il rendering planetario dovrai impostare almeno 16 livelli di dettagli, il che significa che avrai bisogno (per cucire punti) alcune patch extra per collegare diversi livelli e prendersi cura del livello del vicino, questo può essere noioso da risolvere, specialmente usando 6 facce del terreno.

Esiste un altro metodo, molto particolare nel suo: "Proiezione di griglie proiettive per terreni planetari" eccellente per la visualizzazione, ma presenta i suoi svantaggi, se vuoi saperne di più vai al link.

I problemi:

• Jitter : la maggior parte delle GPU odierne supporta solo valori a virgola mobile a 32 bit, che non forniscono una precisione sufficiente per manipolare posizioni di grandi dimensioni su terreni su scala planetaria. Il jitter si verifica quando lo spettatore ingrandisce, ruota o si sposta, quindi i poligoni iniziano a rimbalzare avanti e indietro.

  La soluzione migliore per questo è usare il metodo "Rendering relativo all'occhio usando la GPU". Questo metodo è descritto nel libro "3D Engine Design for Virtual Globes" (sono sicuro che puoi trovarlo anche su Internet) in cui in pratica devi impostare tutte le tue posizioni con doppi sulla CPU (patch, clipmaps, oggetti, frustrum, camera, ecc.) e poi MV è centrata attorno allo spettatore impostando la sua traduzione su (0, 0, 0) T e i doppi sono codificati in una rappresentazione a punto fisso usando i bit di frazione (mantissa) di due float, basso e in alto con alcuni metodi (leggi sull'utilizzo dell'implementazione di Ohlarik e della libreria DSFUN90 Fortran).

  Sebbene lo shader di vertici richieda solo due ulteriori sottrazioni e un'aggiunta, GPU RTE raddoppia la quantità di memoria del buffer di vertici richiesta per le posizioni. Ciò non raddoppia necessariamente i requisiti di memoria a meno che non vengano memorizzate solo posizioni.

• Depth Buffer Precision : Z-fighting. Dato che stiamo realizzando terreni molto grandi, in questo caso: pianeti, il buffer Z deve essere ENORME, ma non importa quali valori impostati per znear e zfar, ci saranno sempre problemi.

  Poiché il buffer Z dipende da un intervallo in virgola mobile, ed è anche lineare (anche se la proiezione prospettica non è lineare) i valori vicino all'occhio soffrono di combattimenti Z perché la mancanza di precisione dei float a 32 bit.

  Il modo migliore per risolvere questo problema è usare un "Buffer di profondità logaritmica" http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

  Un buffer di profondità logaritmico migliora la precisione del buffer di profondità per oggetti distanti utilizzando una distribuzione logaritmica per zscreen. Scambia precisione per oggetti vicini per precisione per oggetti distanti. Dato che stiamo eseguendo il rendering con un metodo LOD, gli oggetti lontani richiedono meno precisione perché hanno meno triangoli.

Qualcosa di importante da ricordare è che tutti i metodi elencati (ad eccezione della griglia proiettiva) sono molto buoni quando si fa fisica (principalmente collisioni) a causa della base Quadtree, che è qualcosa di obbligatorio se si prevede di fare un gioco.

In conclusione, controlla tutte le opzioni disponibili e scegli quella che ritieni più comoda, a mio avviso CDLOD fa un ottimo lavoro. Non dimenticare di risolvere i problemi di jitter e buffer Z, e soprattutto: divertiti a farlo!

Per ulteriori informazioni su LOD, consultare questo link .

Per una dimostrazione completa sulla sferificazione di un cubo, controlla questo link .

Per una spiegazione migliore sulla risoluzione del jitter e delle precisioni Z-Buffer, consulta questo libro .

Spero che questa piccola recensione sia utile.