Tecnologie per la renderizzazione e la correzione di superfici trasparenti in grafica computerizzata

Transcript

1 POLITECNICO DI MILANO Corso di Laurea Specialistica in Ingegneria Informatica Dipartimento di Elettronica, Informazione e Bioingegneria Tecnologie per la renderizzazione e la correzione di superfici trasparenti in grafica computerizzata Relatore: Prof. Marco Gribaudo Tesi di Laurea di: Niccolò Capitelli, matricola Anno Accademico

2 Ringraziamenti 2

3 Indice Sommario 11 1 Introduzione Inquadramento generale Breve descrizione del lavoro Struttura della tesi Background OpenGL Rendering Pipeline Passi multipli di rendering Atomicità in OpenGL Allocazione statica di memoria Analisi della problematica Funzione di blending Ordinamento delle superfici Stato dell arte Algoritmo di renderizzazione delle trasparenze Struttura generale dell algoritmo Renderizzazione superfici opache Renderizzazione su texture Gestione del canale alpha nelle superfici opache Renderizzazione superfici trasparenti Strutture dati Costruzione delle Linked List Risoluzione Anti-aliasing

4 3.6 Risultati grafici Ottimizzazione dell algoritmo Memoria vs Performance Bottleneck nell algoritmo di OIT Implementazione BMA Operazioni offline per BMA Operazioni online per BMA Performance soluzione BMA Strumenti hardware e software utilizzati Valutazione delle performance Algoritmi di ordinamento per gli intervalli di BMA Tecnica OIT per la correzione di errori di renderizzazione Errata sovrapposizione delle superfici Correzione frontale Strutture OIT per la risoluzione Algoritmo di correzione Correzione laterale Spiegazione della problematica Nuovo algoritmo di correzione Differenze implementative e di performance tra i due algoritmi di correzione Separazione mesh opache e trasparenti Algoritmo esatto Algoritmo statistico Conclusioni Conclusione e Lavori Futuri Riassunto delle tecnologie implementate Algoritmi di trasparenza e Unity Lavori futuri A Pipeline di renderizzazione del motore grafico di test 98

5 Bibliografia 100

6 Elenco delle figure 2.1 pipeline di rendering in OpenGL miscela del colore di due superfici sovrapposte utilizzando la funzione di blending per la miscelazione del colore differente risultato del colore della superficie trasparente dovuto al diverso ordine di miscelazione errore di miscela del colore dovuto all ordinamento sbagliato delle superfici modello di una scena che contiene superfici trasparenti e opache sovrapposizione tra triangoli renderizzazione di una superficie opaca sulla texture texture risultante alla fine della renderizzazione strutture create e inizializzate per l inizio dell algoritmo preparazione delle strutture per iniziare la renderizzazione delle superfici trasparenti inserimento del primo ID all interno dell head pointer buffer inserimento delle informazioni del fragment all interno del node buffer renderizzazione di una superficie trasparente coperta in parte da una superficie opaca sovrapposizione di superfici trasparenti 1/ sovrapposizione superfici trasparenti 2/ ogni pixel recupera la propria lista ogni pixel ordina la lista e calcola il colore utilizzo del multisample per implementare l antialiasing differenza tra l assenza e la presenza dell algoritmo di OIT

7 3.14 capelli lunghi femminili capelli corti femminili variazione delle performance all aumentare della memoria locale utilizzata Livelli lista capelli lunghi gestione statica della memoria in OpenGL stencil buffer utilizzato per associare ad ogni pixel un intervallo di renderizzazione ai cappelli lunghi di un personaggio modello utilizzato per valutare le performance della tecnica BMA differenza di performance dovuta all assenza o alla presenza della tecnica BMA performance algoritmi di ordinamento per ogni intervallo di renderizzazione performance algoritmi di ordinamento per ogni intervallo di renderizzazione in rapporto con l insertion sort errata intersezione tra superfici intersezione tra mesh appartenenti a due modelli differenti linked list di un pixel appartenente allo spazio in cui avviene l errore di renderizzazione inversione dei fragment nella lista in base alla priorità cancellazione fragment con priorità minore variazione non lineare della variabile Z in screen coordinates correzione errori con personaggio in posizione frontale errore dovuto alla mancanza del fragment della maglietta in seconda posizione nella lista mancanza di un fragment correttore nella lista del pixel errato lista con fragment correttore distante rispetto al fragment da correggere renderizzazione lista con fragment errato trasparente applicazione della texture corretta sul modello del personaggio correzione errore con personaggio in posizione laterale localizzazione sulla texture dei fragment da correggere

8 6.1 bounding box per un triangolo della mesh applicazione campionamento sistematico su una texture differenza tra l assenza e la presenza dell algoritmo OIT differenza di renderizzazione delle trasparenze tra unity e il motore grafico utilizzato per lo studio delle trasparenze differenza di renderizzazione tra le funzioni di base di unity e il motore grafico utilizzato per lo studio delle trasparenze... 95

9 Lista degli Algoritmi 1 Inserimento della distanza nel canale alpha del colore opaco renderizzazione dei fragment trasparenti recupero dei fragment dal node buffer inserimento fragment opaco nella lista dei fragment trasparenti 42 5 miscelazione del colore da attribuire al pixel memoria temporanea per riordino della lista dei fragment definizione della lunghezza della lista tramite BMA conteggio del numero dei fragment per ogni pixel creazione della maschera BMA eliminazione dei pixel che hanno un numero di fragment inferiore all intervallo considerato utilizzo della maschera BMA per la renderizzazione inserimento informazione relativa alla priorità di renderizzazione dei fragment ordinamento delle liste in base alla priorità rendere permanente la correzione delle superfici classificazione poligoni con algoritmo esatto campionamento sistematico

10 Elenco delle tabelle 3.1 struttura interna di un nodo nel Node Buffer software utilizzato per l implementazione dell algoritmo caratteristiche scheda grafica struttura interna di un nodo nel Node Buffer con il quarto spazio del vettore non utilizzato aggiunta dell informazione di priorità all interno della struttura del nodo

11 Sommario La tesi affronta la problematica della renderizzazione di oggetti e superfici trasparenti in grafica computerizzata, sfruttando quelle che sono le tecnologie hardware e software presenti nel panorama informatico in modo da creare un algoritmo open-source che possa essere implementato nella maggior parte dei motori grafici. Queste tipologie di oggetti e superfici devono essere trattate in modo differente rispetto alle superfici definite opache, poiché assumono una colorazione differente in base al grado di trasparenza di ogni singola superficie, al numero di superfici sovrapposte e alla quantità di luce che le colpisce. A causa della loro peculiarità questi oggetti hanno bisogno di una trattazione particolareggiata che entri nel dettaglio dell implementazione e ottimizzazione degli algoritmi che ne permettono una renderizzazione di qualità con alte performance. Il lavoro parte da una analisi degli strumenti software e hardware necessari per affrontare il problema, per poi entrare nel dettaglio di quelle che sono le soluzioni e le criticità, tenendo sempre conto delle performance del sistema. In un sistema di questo tipo alti livelli di performance sono fondamentali poiché la maggior parte delle operazioni vengono eseguite in real-time, obbligando l applicazione a svolgere tutte le operazioni nel minor tempo possibile per far si che la renderizzazione della scena permetta una visione che sia la più fluida possibile. 11

12 Capitolo 1 Introduzione 1.1 Inquadramento generale La computer grafica nasce intorno alla seconda metà degli anni 60 per scopi industriali e militari ed era pertinenza esclusiva di computer dotati di grande potenza e di componenti elettronici dedicati. Grazie alla miniaturizzazione dei componenti e all evoluzione tecnologica nascono i primi personal computer che riescono ad esprimere le stesse performance in dimensioni molto più ridotte permettendo una sempre più elevata diffusione della elaborazione e visualizzazione di immagini. Un ulteriore passo fu fatto con l introduzione delle prime schede video dedicate (GPU) che, pur operando a frequenza più bassa rispetto a quella del processore, sono molto veloci nell eseguire quelle operazioni per le quali sono specializzate. Le prime schede video potevano visualizzare solo testo; successivamente si sono diffuse anche schede video in grado di mostrare output grafici (immagini non testuali) per poi arrivare alle cosiddette schede video 2D accelerate e successivamente le 3D accelerate. Queste GPU hanno la caratteristica di eseguire la maggior parte delle funzioni grafiche in modo autonomo, senza che il processore principale debba intervenire. In questo modo, ogni pixel dell immagine viene calcolato dalla GPU fotogramma per fotogramma partendo da una serie di dati forniti dalla CPU. Sfruttando quelle che sono le principali funzioni grafiche messe a disposizione da parte dei produttori di schede video, è stato possibile creare immagini sempre più reali, simulando effetti grafici che la realtà offre.

13 1.2. Breve descrizione del lavoro 13 L effetto di trasparenza delle superfici sfrutta queste funzioni e la sua implementazione è evoluta con l evolversi delle funzioni grafiche a disposizione degli sviluppatori. Nel corso di questo lavoro andremo ad approfondire l argomento cercando di dare un quadro di quelle che sono le possibili implementazioni e ottimizzazioni per creare un effetto di trasparenza sempre più reale. 1.2 Breve descrizione del lavoro Nella tesi viene affrontata la problematica di renderizzare al meglio gli oggetti e le superfici trasparenti in modo da dare un effetto di trasparenza del tutto simile all effetto reale. In particolare verrà descritto un algoritmo che sarà inserito all interno di un motore grafico il cui scopo è quello di dare la possibilità a designer e stilisti di visualizzare su un modello virtuale i vestiti da loro pensati. La particolarità di questo lavoro sta nel fatto che non verranno utilizzate soluzioni proprietarie, delle quali non sono conosciute le implementazioni, ma saranno utilizzate funzioni e strumenti messi a disposizione da OpenGL per creare un algoritmo che utilizzi funzioni standard per dare un effetto molto simile a quello offerto dalle soluzioni proprietarie in termini di grafica e prestazione. 1. Descrizione dell algoritmo: descrizione dell algoritmo di base e delle fasi che lo costituiscono, entrando nel dettaglio di quelle che sono le strutture dati e le funzioni grafiche utilizzate e messe a disposizione dal software e dall hardware utilizzato. 2. Ottimizzazioni dell algoritmo: ottimizzazione delle fasi e delle strutture di base oltre all aggiunta di nuove fasi che, sfruttando le caratteristiche del software utilizzato, permettono di aumentare le performance nonostante l aggiunta di elaborazione da parte della GPU. 3. Possibili altri utilizzi dell algoritmo: utilizzo dell algoritmo pensato in un primo momento per la realizzazione dell effetto di trasparenza, per risolvere altre problematiche che sfruttino le strutture utilizzate dall algoritmo.

14 1.3. Struttura della tesi Struttura della tesi La tesi è strutturata come di seguito: Nel Capitolo 2 verranno illustrate le basi teoriche che sono servite per affrontare il problema, andando ad analizzare dapprima gli strumenti software e hardware utilizzati, per poi descrivere quelle che sono state le soluzioni degli anni passati e lo stato dell arte. Nel Capitolo 3 sarà illustrato l algoritmo di riferimento per l effetto della trasparenza. Dopo una spiegazione generale saranno approfondite le strutture dati utilizzate e tutti i passaggi che compongono la procedura di implementazione dell algoritmo. Nel Capitolo 4 il focus sarà sulla possibilità di ottimizzare l algoritmo descritto precedentemente sia dal punto di vista delle performance temporali sia da quello delle performance riguardanti lo spazio di memorizzazione occupato dalle strutture dati e dalle informazioni necessarie per l implementazione dell algoritmo. Nel Capitolo 5 sarà descritta una metodologia che permetterà di sfruttare le strutture e la capacità di poter conoscere in profondità la scena possedute dall algoritmo di renderizzazione delle superfici trasparenti per poter risolvere problemi di altra natura in cui le intersezioni tra le superfici di modelli diversi possono creare errori di renderizzazione. Nel Capitolo 6 sarà descritto ciò che avviene prima di poter renderizzare le superfici della scena utilizzando l algoritmo descritto in questo lavoro di tesi. Infatti prima di procedere all esecuzione dell algoritmo sarà necessario suddividere le superfici in opache e trasparenti in modo da separare in due fasi differenti la renderizzazione di queste due tipologie di oggetti. La separazione delle superfici avviene utilizzando un algoritmo che può essere implementato secondo caratteristiche differenti in base al contesto in cui si trova ad operare. Nel Capitolo 7 saranno riassunti tutti gli argomenti trattati e saranno forniti alcuni spunti per eventuali nuovi argomenti che possono essere approfonditi e studiati utilizzando come base questo lavoro di tesi.

15 Capitolo 2 Background In questo capitolo si forniscono le basi teoriche per comprendere meglio il problema. Si descrivono prima di tutto gli strumenti software e gli aspetti architetturali sui quali si basa il ragionamento, per poi entrare nel dettaglio di quelle che sono state le soluzioni passate. Questa analisi permetterà di capire quali sono gli aspetti più critici sui quali bisogna fare più attenzione per creare un qualcosa di più performante ed efficiente rispetto al passato. 2.1 OpenGL OpenGL è una specifica che definisce una API per più linguaggi e per più piattaforme per scrivere applicazioni che producono computer grafica 2D e 3D. L interfaccia consiste in circa 250 diverse chiamate di funzione che si possono usare per interagire con la scheda grafica in modo da poter disegnare complesse scene tridimensionali a partire da semplici primitive. OpenGL include anche le specifiche necessarie per il linguaggio di programmazione GLSL, simile alla sintassi del linguaggio C, che permette di scrivere shader eseguiti dalla GPU. Lo shader in breve è il programma che permette di calcolare il colore di un sample o pixel dello schermo in un passo di rendering. Nei paragrafi successivi saranno descritte le caratteristiche di OpenGL che hanno una incidenza maggiore nella trattazione del problema delle trasparenze e che saranno poi approfondite durante la descrizione dell algoritmo e della sua ottimizzazione.

16 2.1. OpenGL Rendering Pipeline Figura 2.1: pipeline di rendering in OpenGL Il compito di OpenGL è quello di ricevere primitive come punti, linee e poligoni, e di convertirli in pixel calcolandone il relativo colore. Ciò è realizzato attraverso una pipeline grafica (Figura 2.1) nota come OpenGL state machine. La maggior parte dei comandi OpenGL forniscono primitive alla pipeline grafica o istruiscono la pipeline su come elaborarle. Vertex processing: chiamato anche vertex shader, processa ogni singolo vertice per ogni triangolo dato alla GPU. Viene usato per trasformare la posizione 3D di un vertice nelle coordinate 2D che quel vertice occupa sullo schermo. Il vertex shader è programmabile. Primitive processing: chiamato anche geometry shader, è uno step opzionale all interno della pipeline. Viene utilizzato per creare geometrie nuove e più complesse. Rasterization: nella fase di rasterizzazione, il triangolo viene convertito in pixel, determinando quale triangolo copre un determinato pixel.

17 2.1. OpenGL 17 Il risultato dell intersezione tra il triangolo e il pixel viene chiamato fragment. Fragment processing: chiamato anche fragment shader, si occupa di calcolare il colore del fragment in output dalla fase di rasterizzazione. Il fragment shader ha come output non necessariamente un colore e lo può salvare in numerose tipologie di buffer o immagini. Il fragment shader è programmabile. Pixel processing: una volta stabilito il colore del fragment, in questa fase viene analizzato il canale alpha in modo da mixare il colore dei fragment appartenenti allo stesso pixel e creare il colore finale. Comprendere al meglio il funzionamento della pipeline offerta da OpenGL è fondamentale, poiché nei capitoli successivi il fragment shader e il processamento dei pixel saranno modificati per essere adattati all implementazione dell algoritmo che gestirà le trasparenze Passi multipli di rendering Grazie alla struttura della pipeline vista in precedenza, è possibile calcolare attraversando tutti gli step il colore di ogni pixel dello schermo a partire dall informazione dei vertici dei triangoli che compongono l oggetto da renderizzare. Come output della pipeline si ottiene un immagine che sarà mostrata a schermo come unico frame. Effettuare dei rendering multipli vuol dire invece applicare la struttura della pipeline più volte nel corso della creazione di un frame. In questo modo ogni ciclo di pipeline viene utilizzato per raccogliere dati e creare strutture che possano essere utili nei successivi cicli. Il ciclo di pipeline finale si occupa genericamente di raccogliere le strutture dati intermedie, di elaborare un risultato e mostrare a video il colore del pixel. L algoritmo trattato in questa tesi sfrutterà la possibilità di utilizzare più volte la pipeline nel corso della creazione di un unico frame per raccogliere i dati necessari per il calcolo del colore finale dei pixel. Ciò comporterà una ricerca della massima ottimizzazione in modo da ridurre i tempi di creazione dell intero frame.

18 2.1. OpenGL Atomicità in OpenGL All intero di un unico ciclo di pipeline, ogni pixel viene calcolato in modo concorrenziale rispetto agli altri utilizzando thread diversi. Questo avviene per sfruttare la potenza di calcolo parallela delle GPU moderne e diminuire di molto il tempo impiegato per la creazione di un singolo frame. Questa caratteristica comporta delle difficoltà che devono essere tenute conto nel corso dell implementazione dell algoritmo, poiché alcune delle operazioni devono essere svolte in modo atomico per dare un risultato coerente che non presenti effetti di flickering dovuti ad una sbagliata sequenzialità delle operazioni. Fortunatamente OpenGL presenta delle funzioni molto utili che permettono di rendere atomiche alcune operazioni molto importanti per la realizzazione dell algoritmo. Con la release del 8 Agosto 2011, OpenGL si è aggiornato alla versione 4.2 introducendo molte novità tra le quali il supporto per gli shader all atomic counter e alle operazioni di load e store che permettono di leggere o scrivere in una texture in modo atomico[1]. Queste funzioni sono di fondamentale importanza per l implementazione dell algoritmo, tanto che precedentemente alla loro introduzione, non era possibile creare le strutture che sono ora alla base della sua implementazione Allocazione statica di memoria Un altra considerazione da fare e da tenere a mente per il proseguo del discorso è come OpenGL alloca la memoria per salvare i dati e le strutture che utilizza durante l esecuzione del progamma. OpenGL infatti utilizza una gestione statica della memoria, allocandola a compile time anziché renderla disponibile a run time come accade nell allocazione di tipo dinamica. Vedremo nel corso della tesi come questa caratteristica sia di particolare importanza per la progettazione e l ottimizzazione dell algoritmo poiché crea delle limitazioni alle quali è necessario porre rimedio per avere un aumento di prestazione ideale. Una delle questioni principali è che la memoria occupata influenza il numero di thread che possono essere eseguiti in contemporanea, influenzando quindi la velocità con cui ogni frame viene elaborato.

19 2.2. Analisi della problematica Analisi della problematica Dopo aver visto quali sono le principali caratteristiche di OpenGL che influenzano il procedimento di implementazione e l esecuzione degli algoritmi che permettono di creare l effetto di trasparenza, entriamo più in dettaglio in quella che è la problematica che andremo ad affrontare Funzione di blending Il blending (miscela) in OpenGL è conosciuto comunemente come la tecnica per implementare le trasparenze degli oggetti. La trasparenza nella computer grafica è definita come un oggetto (o una parte di esso) che in fase di renderizzazione non assume la colorazione dovuta al colore intrinseco dell oggetto, ma il colore di cui è costituito è una combinazione tra il colore posseduto dall oggetto e dai colori degli oggetti che si trovano dietro di lui all interno della scena. Gli oggetti o le superfici trasparenti possono essere di due tipologie differenti: Completamente trasparenti: mostrano unicamente i colori degli oggetti che si trovano dietro di loro senza influenzare in nessun modo il colore di questi oggetti. Parzialmente trasparenti: mostrano il colore degli oggetti dietro di loro influenzandone il colore finale durante la fase di miscelazione del colore che avviene nella renderizzazione finale. La differenza appena descritta è dovuta al fatto che ogni fragment che costituisce l oggetto può possedere un diverso grado di trasparenza definito dal valore del canale alpha (alpha channel). Il canale alpha è il quarto componente del vettore che rappresenta il colore e può assumere un valore compreso tra 0 e 1. Il valore 0 indica che il colore è del tutto trasparente, mentre il valore 1 indica che il colore è del tutto opaco. Un valore come 0.5 ad esempio indica che il colore finale sarà influenzato per un 50% dal colore dell oggetto e dal rimanente 50% dal colore di ciò che si trova dietro di esso.

20 2.2. Analisi della problematica 20 Figura 2.2: miscela del colore di due superfici sovrapposte utilizzando la funzione di blending per la miscelazione del colore L operazione di blending in OpenGL viene implementata tramite la seguente formula: C result = C source F source + C destination F destination C source è il vettore colore analizzato nel momento in cui avviene l operazione. C destination è il vettore colore analizzato precedentemente e già presente nel buffer di renderizzazione. F source è un valore che stabilisce l impatto dell alpha channel del colore di source. F destination è un valore che stabilisce l impatto dell alpha channel del colore di destinazione. F source e F destination possono assumere diversi valori attraverso la funzione OpenGL chiamata glblendfunc(glenum sfactor, GLenum dfactor)[2]. funzione accetta due parametri che permettono di scalare le componenti del vettore colore sorgente (sfactor) e il vettore colore destinazione(dfactor). La soluzione più usata è espressa dalla funzione glblendfunc(gl SRC ALPHA, GL ONE MINUS SRC ALPHA) che permette di settare F source = α source e F destination = 1 α source utilizzando l alpha channel del colore sorgente. La

21 2.2. Analisi della problematica Ordinamento delle superfici La figura 2.3 mostra l applicazione della funzione di blending utilizzando la formula appena commentata. Come si può notare dalla figura, invertendo quello che è il colore source con il colore destination si possono ottenere diverse miscelazioni del colore. A sinistra la superficie rossa si trova al di sopra della superficie verde creando una superficie trasparente che ha nel rosso il suo colore predominante. A destra invece accade il contrario, poiché la superficie verde si trova al di sopra della superficie rossa dando origine ad una superficie trasparente che ha nel verde il suo colore predominante. Possiamo quindi dedurre che l ordine con cui le superfici vengono renderizzate e i colori miscelati tra loro è di fondamentale importanza. Figura 2.3: differente risultato del colore della superficie trasparente dovuto al diverso ordine di miscelazione La problematica diventa ancora più complessa se aumentano le superfici da miscelare e gli oggetti all interno della scena. Un esempio di questa complessità è la figura 2.4, che mostra due oggetti trasparenti renderizzati attraverso la funzione di blending descritta nella sezione precedente. I due oggetti presentano numerose superfici che si sovrappongono e che non sono miscelate nel corretto ordine. L errore di miscelazione è ben visibile in figura e si manifesta attraverso una errata definizione del colore. Si nota infatti come il colore degli oggetti risulti non omogeneo con una netta variazione da una mesh ad un altra.

22 2.2. Analisi della problematica 22 Figura 2.4: errore di miscela del colore dovuto all ordinamento sbagliato delle superfici L errore appena descritto è dovuto alla metodologia che OpenGL utilizza per gestire la miscelazione del colore e l ordinamento delle superfici. L ordine di renderizzazione tra oggetti diversi può essere controllato dall utente specificando nel codice quale oggetto renderizzare per primo e quale per ultimo, mentre l ordine di superfici trasparenti appartenenti allo stesso oggetto non può essere controllato in modo semplice dall utente ma è affidato completamente alla pipeline di OpenGL. L unico modo quindi per evitare l errore, è creare un algoritmo che possa ordinare gli oggetti e le superfici in base alla distanza dalla camera prima di calcolarne il colore. Per realizzare un effetto di trasparenza che abbia un alta qualità dal punto di vista visivo, è necessario creare un algoritmo che possa prendersi carico della risoluzione. Esistono più tipologie di algoritmi di questo tipo, ma possono in generale essere suddivisi in due macro categorie che si differenziano per la procedura con cui avviene la collezione dei fragment relativi ad un determinato pixel: 1. renderizzazione in ordine delle geometrie in modo da applicare la funzione di blending precedentemente descritta. 2. renderizzazione non in ordine delle geometrie per poi riordinare i fragment dopo lo step di renderizzazione e prima di calcolare il colore

23 2.3. Stato dell arte 23 definitivo. Questa tecnica è chiamata Order Independent Transparency (OIT). La figura 2.5 mostra una tipica scena in cui è possibile vedere come sia complicato definire un vero e proprio ordinamento delle superfici a causa delle sovrapposizioni che non permettono a volte di stabilire con certezza quale oggetto si trova più vicino alla camera rispetto all altro. Inoltre è importante notare come la presenza di superfici opache possano facilitare l ordinamento poiché permettono di estromettere dall elaborazione tutte quelle superfici sia opache che trasparenti che si trovano dietro di esse. E il caso della superficie S 7 che copre completamente la superficie S 6 facendo si che essa possa essere esclusa dall analisi. Figura 2.5: modello di una scena che contiene superfici trasparenti e opache 2.3 Stato dell arte La renderizzazione di superfici trasparenti è un problema conosciuto nel mondo della computer grafica, ma non esiste un implementazione standard per via del grande numero di tecnologie software e hardware che esistono nel panorama informatico e per la loro continua evoluzione. In questa sezione vedremo come in passato si è cercato di ricreare l effetto di trasparenza sfruttando in un primo momento le funzioni di blending offerte

24 2.3. Stato dell arte 24 da OpenGL per poi approfondire il concetto di Order Independent Transparency (OIT) che ha permesso un aumento considerevole delle performance di elaborazione e delle performance legate alla qualità dell immagine. Ordinamento della geometria Le tecniche descritte di seguito hanno bisogno di un ordinamento delle superfici prima che possa avvenire la miscela del colore per la renderizzazione finale. Vedremo come questo tipo di soluzione sia complesso poiché stabilire l ordinamento delle superfici basandosi sui modelli non è una problematica banale. Gli algoritmi principali che utilizzano questo tipo di soluzione sono due, ma applicano l ordinamento in due modalità differenti. Alpha blending: miscela dei colori applicando semplicemente la funzione di blending[3] descritta in precedenza. L ordinamento delle superfici viene effettuato dall utente, il quale può soltanto ordinare gli oggetti tra loro in base alla distanza dalla camera, ma non può agire sull ordinamento delle singole superfici. Questa soluzione comporta quindi problemi di renderizzazione che coinvolgono le superfici dello stesso oggetto. Ordinamento dei triangoli: l ordinamento delle mesh o dei triangoli cerca di porre rimedio al problema dell alpha blending semplice andando ad ordinare i singoli triangoli che compongono gli oggetti. Questo tipo di algoritmo è molto complesso proprio perché ogni superficie deve essere scomposta nei triangoli che la compongono e aumenta il tempo di elaborazione e di renderizzazione dell immagine poiché ogni singolo triangolo deve essere processato e confrontato con i triangoli ad esso vicini. Inoltre la difficoltà maggiore sorge nel momento in cui esistono triangoli dei modelli da renderizzare che si intersecano tra loro, poiché in questa situazione è impossibile stabilire in modo preciso quale triangolo si trovi più vicino alla camera (Figura 2.6).

25 2.3. Stato dell arte 25 Figura 2.6: sovrapposizione tra triangoli Ordinamento dei fragment (OIT) Le tecniche di tipo OIT sono tecniche più evolute rispetto alle precedenti, poiché non ordinano le geometrie ma assicurano un corretto ordine a livello dei fragment. Questo cambio di implementazione è molto importante dal punto di vista delle performance del sistema su cui viene eseguito l algoritmo. L ordinamento delle geometrie era affidato completamente alla CPU che doveva poi comunicare i risultati alla GPU. Negli algoritmi di OIT non c è più la necessità di coinvolgere la CPU per l ordinamento degli oggetti in base alla loro profondità prima della renderizzazione. Tutti i calcoli vengono svolti dalla GPU e l interazione con la CPU viene ridotta al minimo necessario. Il problema principale consiste invece nel fatto che questa tipologia di algoritmo richiede un elevato uso della memoria per il salvataggio dei frammenti e delle loro caratteristiche. Depth Peeling: è il primo algoritmo di tipo OIT implementato presentato nel 2001 da C.Everitt [4]. L idea di base è che il fragment shader può scartare i fragment che non sono vicini ad un certo valore di threshold e il depth buffer identificherà il fragment più vicino fra tutti i fragment non scartati. La scena viene renderizzata più volte ignorando i livelli identificati precedentemente. In pratica l oggetto viene sbucciato considerando ad ogni passaggio uno strato diverso. Dual Depth Peeling: metodo creato da Bavoil [5] è una modifica del depth peeling che permette di sbucciare due layer alla volta. Ad

26 2.3. Stato dell arte 26 ogni passaggio vengono analizzati i layer frontale e posteriore in modo simultaneo. Siccome non è possibile creare l algoritmo utilizzando il classico depth buffer e la GPU non possiede depth buffer multipli, bisogna creare un depth buffer che sappia gestire valori massimi e minimi. In questo modo si passa dagli N passi di renderizzazione delle geometrie da parte del peeling classico, a N/2 + 1 passi di renderizzazione. Algoritmi con strutture dati customizzate: negli anni successivi sono stati creati numerosi algoritmi che sfruttano tipologie di strutture dati differenti per la gestione delle informazioni riguardanti la scena. Il più conosciuto è l algoritmo che utilizza un A-Buffer [6] utilizzato per capire se una superficie è visibile o meno. Insieme al buffer viene utilizzata una lista chiamata per pixel concurrent linked list[7], che permette di raccogliere tutti i fragment appartenenti ad un determinato pixel. Nei capitoli successivi andremo ad approfondire il concetto di strutture custom cercando di descriverle ed ottimizzarle. Questo tipo di strutture permette di conoscere di salvare le informazioni relative ad ogni fragment presente all interno della scena in modo da permettere di capire qual è il contributo che ogni superficie porta ad un determinato pixel. In questo modo ogni pixel possiede tutte le informazioni necessarie per il calcolo del colore.

27 Capitolo 3 Algoritmo di renderizzazione delle trasparenze In questo capitolo sarà descritto l algoritmo di renderizzazione delle superfici trasparenti in ambito computer grafica, entrando nel dettaglio delle fasi che lo compongono e delle strutture dati utilizzate. In questa fase saranno descritte le operazioni essenziali per la sua implementazione, lasciando le considerazioni di ottimizzazione ai prossimi capitoli. 3.1 Struttura generale dell algoritmo L algoritmo è articolato in più parti distinte che interagiscono tra loro attraverso l aggiornamento e l utilizzo di informazioni presenti in strutture condivise. La prima fase sarà eseguita una sola volta mentre le altre appartengono al ciclo di renderizzazione ripetuto ogni volta che avviene la creazione di un singolo frame. 1. Costruzione strutture dati: prima che avvenga il ciclo di renderizzazione, è necessario fornire all algoritmo le strutture dati adatte per memorizzare le informazioni relative alle superfici presenti nella scena. Avviene così una fase in cui le strutture vengono create e inizializzate per l inizio della fase di renderizzazione. Inoltre saranno create e messe a disposizione per le fasi successive, le funzioni adatte a resettare

28 3.1. Struttura generale dell algoritmo 28 le informazioni contenute nelle strutture in modo da poter iniziare un nuovo ciclo di renderizzazione. 2. Renderizzazione superfici opache: in questo passaggio vengono renderizzate tutte le superfici opache all interno della scena utilizzando come destinazione della renderizzazione una texture anziché il buffer di default messo a disposizione da OpenGL per renderizzare l immagine a schermo. In questa fase è necessario inoltre salvare la distanza dei fragment della superficie dalla camera in modo da settare il limite oltre il quale non è necessario considerare le superfici in quel punto della scena poiché utilizzando questo dato nei passi successivi sarà possibile scartare le superfici trasparenti che sono dietro alla superficie opaca considerata aumentando le performance di calcolo. 3. Renderizzazione superfici trasparenti: le superfici trasparenti vengono scomposte nei fragment che le costituiscono per poi assegnare ogni fragment al pixel corrispondente. In questa fase è importante che le impostazioni di back face culling e depth test [8][9] siano disattivate in modo che tutte le superfici del modello vengano considerate, anche quelle nascoste dalle superfici più vicine alla camera, poiché in un contesto di renderizzazione di superfici trasparenti, anche le superfici nascoste influenzano il colore finale del pixel in fase di renderizzazione. I fragment trasparenti che sono coperti dal relativo fragment opaco contenuto nella texture delle superfici opache, vengono scartati poiché non hanno la possibilità di influenzare il colore finale del pixel. 4. Calcolo del risultato: una volta raccolte le informazioni sulle superfici opache e trasparenti, ogni pixel calcola il colore definitivo tramite operazioni svolte sui fragment che gli sono stati assegnati che permettono di miscelare il colore dei fragment per ottenere il colore finale da attribuire al pixel. Nelle sezione successive saranno approfonditi tutti i passaggi dell algoritmo tenendo presente che a priori è stata effettuata una valutazione delle mesh per stabilire se una superficie risulta essere trasparente oppure opaca. La procedura di discriminazione verrà descritta nel capitolo 6.

29 3.2. Renderizzazione superfici opache Renderizzazione superfici opache La renderizzazione delle superfici opache avviene in modo del tutto simile ad una normale renderizzazione della scena, con qualche modifica alla procedura necessaria per salvare l informazione relativa alla distanza di ogni fragment opaco dalla camera Renderizzazione su texture In una procedura di renderizzazione classica, l intera scena viene elaborata e renderizzata utilizzando il buffer di default per essere mostrata a schermo. In questa situazione invece, l obiettivo è poter salvare unicamente le informazioni relative alle superfici opache presenti all interno della scena, per poi essere utilizzate nei passi successivi per scartare i fragment sia opachi che trasparenti che si trovano dietro di esse. Per ottenere questo risultato è necessario disattivare per il momento la renderizzazione sul buffer di default per far si che la renderizzazione venga effettuata su un buffer personalizzato al quale viene associato una texture in cui è possibile salvare la scena opaca. Questa tecnica prende il nome di renderizzazione su texture[10] ed è importante all interno della procedura di gestione delle superfici opache dell algoritmo, poiché permette di salvare in modo efficace le informazioni dei fragment opachi. L utilizzo della tecnica permette di suddividere in tre parti la procedura di gestione delle superfici opache all interno dell algoritmo: 1. Creazione del buffer personalizzato e creazione della texture associata ad esso, sulla quale avverrà la renderizzazione della scena opaca. 2. Renderizzazione delle superfici opache sulla texture associata al buffer personalizzato. 3. Utilizzo della texture nei passaggi successivi dell algoritmo. Grazie alle figure 3.1 e 3.2 è possibile osservare il procedimento che permette di giungere al risultato finale della fase di renderizzazione delle superfici opache. I pixel assumono il colore della superficie opaca corrispondente dopo

30 3.2. Renderizzazione superfici opache 30 aver eseguito i test chiamati depth test e back face culling che permettono di stabilire quale superficie è più vicino alla camera in un determinato punto della scena scartando le superfici più lontane. Figura 3.1: renderizzazione di una superficie opaca sulla texture Figura 3.2: texture risultante alla fine della renderizzazione Un aspetto fondamentale da tenere conto prima di effettuare questo tipo di renderizzazione, è il dimensionamento della texture. Infatti, dato che l obiettivo è renderizzare la scena opaca, la texture deve possedere le stesse identiche dimensioni della finestra o dello schermo che contiene la scena (ViewPort). La texture alla fine di questo passaggio rappresenterà esattamente il frame che deve essere mostrato a video, contenente in questo primo momento unicamente le superfici opache visibili all interno della scena.

31 3.2. Renderizzazione superfici opache Gestione del canale alpha nelle superfici opache Al momento della renderizzazione delle superfici opache, le funzioni depth test e back face culling permettono di eliminare dalla scena le superfici coperte e non visibili per renderizzare solo le superfici più vicine alla camera. Durante la fase di renderizzazione avviene un passaggio fondamentale che permetterà nelle fasi successive dell algoritmo di sapere a quale distanza si trova il fragment opaco appena renderizzato e capire così qual è il limite di distanza possibile. Siccome le superfici trattate in questo passaggio sono state dichiarate esplicitamente come opache, il canale alpha del colore, settato a 1 (superficie opaca), risulta ridondante ai fini dell applicazione e può essere utilizzato per memorizzare altre informazioni. In questo caso il canale alpha viene sfruttato per memorizzare la distanza dalla camera da parte del fragment, in modo da sapere esattamente qual è il valore limite imposto dal fragment opaco alla profondità della scena in quel determinato punto. Algoritmo 1 Inserimento della distanza nel canale alpha del colore opaco if fragment più vicino alla camera then vec4 coloreopaco = calcolacolore(); colorefinale = vec4(coloreopaco,distanza); else scarta il fragment; end calcolo colore distanza in alpha L algoritmo 1 descrive esattamente la procedura eseguita durante questo passaggio. Se il fragment supera il test di visibilità, il suo colore può essere salvato nella texture e il canale alpha conterrà la distanza del fragment dalla camera. Un appunto da fare è quello che riguarda la tipologia di distanza da poter memorizzare nel canale alpha. Infatti, siccome il canale può memorizzare numeri floating point compresi tra 0 e 1, l unica distanza che può essere memorizzata, a meno di trasformazioni che aggiungano overhead, è quella relativa alla zeta delle screen coordinates. Il difetto di questa tipologia sta nel fatto che la zeta in screen coordinates non è lineare, creando qualche

32 3.3. Renderizzazione superfici trasparenti 32 problema nella soluzione di alcune problematiche, che saranno affrontate nei capitoli successivi riguardanti l ottimizzazione dell algoritmo. 3.3 Renderizzazione superfici trasparenti Il passaggio successivo alla creazione della scena dal punto di vista delle superfici opache, è raccogliere le informazioni per renderizzare le superfici trasparenti. Le informazioni dei vertici delle mesh trasparenti vengono passate alla GPU ed è importante che, al contrario di ciò che accade precedentemente, le funzioni di depth test e back face culling vengano disattivate, altrimenti la GPU scarterà le superfici che si trovano dietro alle altre più vicine alla camera e importanti informazioni per la trasparenza saranno perse. Il vertex shader stabilirà la posizione dei fragment in modo del tutto simile al vertex shader delle superfici opache, mentre il fragment shader sarà modificato. In questa fase il fragment shader ha come obiettivo quello di creare per ogni pixel una lista che contenga tutti i fragment relativi a quella posizione e che dovranno poi essere ordinati nel passaggio successivo Strutture dati Prima di descrivere la creazione delle liste per i pixel, è necessario introdurre le strutture dati alla base dell implementazione dell algoritmo. Queste strutture sono importanti perché permettono di mantenere intatte le proprietà di atomicità e coerenza senza le quali non sarebbe possibile sfruttare il concetto di elaborazione parallela introdotto da OpenGL per aumentare le performance di renderizzazione permettendo di eseguire la procedure attraverso l utilizzo di più thread di renderizzazione. Le strutture dati utilizzate dall algoritmo sono tre: 1. Head pointer buffer 2. Atomic counter 3. Node buffer

33 3.3. Renderizzazione superfici trasparenti 33 Dalla figura 3.3 è possibile notare un altra struttura chiamata render target che non è altro che una virtualizzazione dello spazio di renderizzazione (ViewPort). Quindi non è una struttura fisica ma viene utilizzato in figura per comprendere meglio la sovrapposizione delle superfici. Figura 3.3: strutture create e inizializzate per l inizio dell algoritmo Head pointer buffer L head pointer buffer è un buffer di dimensione X Y con X e Y dimensioni dello spazio di renderizzazione (ViewPort). La struttura possiede queste dimensioni perché rappresenta il potenziale frame che dovrà essere calcolato. Ogni spazio del buffer è un pixel del potenziale frame ed è inizializzato con valore 1, ovvero il valore che indica il termine della lista. Quando l algoritmo viene eseguito, gli spazi del buffer vengono aggiornati con l ID del primo fragment presente nella lista relativa a quello spazio. Atomic counter L atomic counter[11] è un tipo di variabile del linguaggio GLSL la cui memoria è costituita da un buffer con un unico spazio. Come il nome suggerisce, possiede delle funzioni che possono operare in modo atomico sul buffer di

34 3.3. Renderizzazione superfici trasparenti 34 memoria utilizzato per la sua implementazione (incremento e decremento del valore). Questa caratteristica è molto importante, poiché, trovandoci in un ambiente completamente parallelo, è necessario garantire che il contatore venga aggiornato da un solo fragment alla volta, questo perchè la sua funzione è quella di poter assegnare uno spazio univoco nel node buffer ad un determinato fragment. Senza l utilizzo di un contatore atomico, gli spazi potrebbero essere sovrascritti perdendo le informazioni necessarie alla costruzione dell immagine. Node buffer Il node buffer è un buffer di dimensione 1 N che raccoglie tutti i fragment appartenenti alle liste dei pixel. Ad ognuno di essi è assegnata una posizione precisa e unica, stabilita dall atomic counter al momento del loro processamento ed ogni spazio assegnato presenta la stessa struttura interna, mostrata in tabella 3.1. Variabile Dimensione in byte NextPointer 4 Color 4 Depth 4 4 Totale 16 Tabella 3.1: struttura interna di un nodo nel Node Buffer La struttura interna non è nient altro che un vettore a quattro elementi, nei quali vengono salvate tutte le informazioni necessarie per la renderizzazione del fragment associato. La scelta di utilizzare un vettore è dovuta al fatto che il node buffer viene creato e dichiarato come una struttura per la memorizzazione di dati RGBA di tipo unsigned int, in modo da poter utilizzare le funzioni atomiche messe a disposizione da OpenGL per la gestione dei buffer di questo tipo (Load/Store functions)[12][13]. Questo comporta quindi una trasformazione del formato utilizzato per le informazioni prima di essere sal-

35 3.3. Renderizzazione superfici trasparenti 35 vate all interno del vettore. Andiamo ora ad osservare le componenti che lo costituiscono: 1. Next pointer: rappresenta la posizione all interno del node buffer del fragment successivo appartenente alla stessa lista. Il next pointer permette in fase di recupero dei fragment per la creazione della lista, di risalire ai fragment appartenenti effettivamente a quella determinata lista. 2. Color: rappresenta il colore del fragment trasparente. Siccome lo spazio di memorizzazione può contenere un numero, è necessario utilizzare la funzione messa a disposizione da GLSL chiamata packunorm4x8(), che permette di impacchettare un vettore all interno di una variabile dichiarata unsigned int. 3. Depth: rappresenta la distanza del fragment dalla camera. Anche in questo caso, essendo la struttura capace di memorizzare valori interi senza segno, è necessario trasformare il valore di tipo float utilizzando la funzione floatbitstouint(). 4. Il quarto elemento del vettore viene lasciato vuoto in questa fase poiché non è necessario aggiungere ulteriori informazioni per il funzionamento classico dell algoritmo. Lo spazio vuoto in questo momento può risultare uno spreco di memoria, ma tornerà utile successivamente in fase di ottimizzazione e di implementazione di nuove funzioni Costruzione delle Linked List Sfruttando le strutture descritte precedentemente è possibile creare e riempire le linked-lists[7]. Una linked list è una struttura dati dinamica, costituita da nodi ognuno contenente campi di dati arbitrari ed un riferimento (link) che punta al nodo successivo. In questo caso esiste una lista per ogni pixel reale e tutti i nodi delle liste sono contenuti nello stesso buffer chiamato node buffer di cui abbiamo parlato precedentemente. Utilizzando le figure sottostanti sarà più semplice spiegare il procedimento che porta alla realizzazione delle liste[14].

36 3.3. Renderizzazione superfici trasparenti 36 In figura 3.4 le strutture sono pronte per iniziare la procedura: il node buffer è vuoto, ogni spazio dell head pointer buffer è inizializzato a 1(lista vuota), l atomic counter è inizializzato a 0 e una nuova superficie trasparente è pronta per essere renderizzata. Figura 3.4: preparazione delle strutture per iniziare la renderizzazione delle superfici trasparenti In figura 3.5 la renderizzazione della superficie trasparente ha inizio con l inserimento dell ID del primo nodo all interno dell head pointer buffer, nello spazio corrispondente alla posizione reale di renderizzazione. Il valore dell ID è assegnato dall atomic counter, il quale viene incrementato di uno, una volta che viene letto il suo valore. Figura 3.5: inserimento del primo ID all interno dell head pointer buffer

37 3.3. Renderizzazione superfici trasparenti 37 In figura 3.6 tutte le informazioni relative al fragment vengono inserite all interno del node buffer nella posizione indicata dall ID inserito nell head pointer buffer in precedenza. Utilizzando la struttura interna del nodo, vengono inserite le informazioni relative al colore, alla distanza e il puntatore al prossimo nodo della lista. In questo caso la lista è costituita unicamente da un nodo, quindi il next pointer conterrà il valore 1. Figura 3.6: inserimento delle informazioni del fragment all interno del node buffer In figura 3.7 avviene la renderizzazione di una nuova superficie trasparente. La particolarità sta nel fatto che uno dei tre pixel che la compongono è coperto da una superficie opaca renderizzata su texture precedentemente. Il fragment coperto viene scartato, mentre gli altri due, in modo atomico, leggono il valore del counter, lo aggiornano e procedendo aggiornando le altre strutture nello stesso modo della prima superficie renderizzata. Per far si che ci sia un confronto continuo tra le distanze imposte dalle superfici opache e le distanze delle nuove superfici, è necessario avere sempre a disposizione la texture delle superfici opache creata al passo precedente. Ricordiamo che la texture opaca contiene la distanza dalla camera di ogni pixel all interno del canale alpha, quindi è facile reperirla tramite le apposite funzioni di accesso e lettura di una texture di OpenGL.

38 3.3. Renderizzazione superfici trasparenti 38 Figura 3.7: superficie opaca renderizzazione di una superficie trasparente coperta in parte da una Le figure 3.8 e 3.9 mostrano la sovrapposizione da parte di due superfici trasparenti. Nella prima figura, la superficie gialla è composta da due fragment: il primo viene renderizzato in uno spazio libero e procede normalmente, mentre il secondo si sovrappone ad un fragment trasparente già inserito in precedenza. Trattandosi di due fragment trasparenti appartenenti allo stesso pixel, devono essere inseriti all interno della stessa lista e il nuovo nodo creato a partire dal nuovo fragment deve prendere il posto del vecchio nodo di testa della lista. Viene così aggiornato lo spazio relativo dell head pointer buffer con il nuovo ID indicato dall atomic counter, mentre il vecchio valore viene inserito all interno della struttura del nodo come puntatore alla vecchia testa della lista. Figura 3.8: sovrapposizione di superfici trasparenti 1/2

39 3.3. Renderizzazione superfici trasparenti 39 Figura 3.9: sovrapposizione superfici trasparenti 2/2 Tutto ciò che è stato detto in modo discorsivo e utilizzando le figure, può essere descritto tramite l algoritmo implementato all interno del fragment shader adibito alla renderizzazione delle superfici trasparenti. Questo algoritmo viene eseguito da ogni fragment delle superfici trasparenti che vengono renderizzate. Algoritmo 2 renderizzazione dei fragment trasparenti if f ragmentt rasparente.z < f ragmentopaco.z then uint index = atomiccounterincrement(); oldhead = imageatomicexchange(index); valore counter recupero vecchio ID vec4 fragmentcolor = colorcalculation(); calcolo colore fragment uvec4 node; node.x = oldhead; node.y = fragmentcolor; node.z = fragmentdepth; node.w = 0; storenode(index,node); else scarta il fragment; end definizione vettore per struttura nodo salvataggio nodo nel node buffer il fragment è coperto dal fragment opaco

40 3.4. Risoluzione Risoluzione L ultimo passaggio per concludere l algoritmo è la risoluzione delle liste costruite per i pixel. Ogni pixel deve recuperare la propria lista, aggiungere l eventuale fragment opaco presente nella posizione corrispondente all interno della texture delle superfici opache, ordinarla in base alla distanza dei fragment dalla camera e calcolare il colore finale. La figura 3.10 mostra il recupero della lista da parte del pixel che ha come nodo di testa il nodo che si trova nella posizione 5 del node buffer. Partendo dall ID contenuto nell head pointer buffer, il pixel recupera il primo nodo della lista e leggendo il puntatore contenuto all interno di esso può recuperare il nodo successivo. Questa procedura continua fino a quando non si recupera il nodo che contiene come puntatore il valore 1. I nodi recuperati devono essere salvati in uno spazio di memoria temporaneo (tipicamente un array) che permetta in un secondo momento di eseguire operazioni di riordino. Figura 3.10: ogni pixel recupera la propria lista Infine la figura 3.11 mostra il riordino della lista in base alla distanza che i fragment hanno dalla camera e il calcolo del colore finale da mostrare a schermo. Il lavoro di riordino viene eseguito sfruttando la zona di memoria temporanea. Nel caso sia un array è possibile applicare qualsiasi tipo di algoritmo di riordino, cercando di ottimizzare lo spazio di memorizzazione e il tempo per risolvere l ordinamento. Questa fase è molto importante dal punto di vista delle performance, poiché, anche se ogni pixel esegue la procedura in

41 3.4. Risoluzione 41 parallelo con gli altri, questo passaggio risulta essere il vero collo di bottiglia dell intero algoritmo dato l elevato numero di pixel presente negli schermi moderni. Come per il riordino, anche per la funzione che miscela i colori per creare il colore finale esistono più tipologie anche se la più semplice da utilizzare è quella offerta da OpenGL. Figura 3.11: ogni pixel ordina la lista e calcola il colore La procedura appena descritta in modo discorsivo, può essere rappresentata in modo formale dall algoritmo che la implementa. Per semplicità di lettura e comprensione l algoritmo sarà suddiviso in 4 passi: 1. Recupero della lista e memorizzazione dei nodi all interno di un array temporaneo. Il recupero dei nodi viene effettuato tramite l utilizzo della funzione atomica imageload offerta da GLSL che ha come parametri il buffer da accedere (in questo caso il node buffer) e la posizione in cui accedere (indicata dalla posizione del pixel che stiamo considerando). Algoritmo 3 recupero dei fragment dal node buffer currentindex = imageload(headpointerbuffer,posizione); while lista non finita do uvec4 node = imageload(nodebuffer,currentindex); currentindex = node.x; recupero l ID recupero il next pointer fragmentlist[fragmentcount] = fragment; salvo il nodo nel temp array fragmentcount++; end

42 3.4. Risoluzione Recupero e inserimento nella lista del corrispondente fragment opaco salvato nella texture delle superfici opache. Algoritmo 4 inserimento fragment opaco nella lista dei fragment trasparenti vec4 texturecolor = texture(opaquetexture, UV); vec4 opaquefragment = vec4(texturecolor.rgb, 1); recupero colore opaco float opaquedepth = texturecolor.a; recupero distanza fragment opaco uvec4 opaquefragmentitem; creazione nodo opaco opaquefragmentitem.x = 0; inserimento informazioni nel nodo opaquefragmentitem.y = packunorm4x8(opaquefragment); opaquefragmentitem.z = floatbitstouint(opaquedepth); opaquefragmentitem.w = 0; fragmentlist[fragmentcount] = opaquefragmentitem; Aggiunta nell array fragmentcount++; 3. Riordino dell array tramite algoritmo di ordinamento. L array viene ordinato in modo tale da disporre i fragment in ordine crescente di distanza rispetto alla camera. Trattandosi di un array la lista può essere riordinata sfruttando uno dei numerosi algoritmi di ordinamento presenti in letteratura. Naturalmente la scelta della tipologia di algoritmo da implementare avrà un diverso impatto sulle performance del sistema in termini di tempo di elaborazione del risultato. 4. Miscelazione dei colori dei fragment utilizzando la funzione di mix offerta da GLSL che utilizza il canale alpha per determinare la prevalenza di un colore sull altro. La miscelazione avviene partendo dal fragment più distante fino al fragment più vicino alla camera. Il colore risultante sarà il colore finale che assumerà il relativo pixel sullo schermo.

43 3.5. Anti-aliasing 43 Algoritmo 5 miscelazione del colore da attribuire al pixel for ogni nodo della lista do vec4 fragmentcolor = unpackunorm4x8(fragmentlist[i].y); end finalcolor = mix(finalcolor, fragmentcolor,fragmentcolor.a); color = finalcolor; 3.5 Anti-aliasing La risoluzione appena descritta parte dal presupposto che per ogni pixel esista un unica lista di fragment che deve essere elaborata, poiché il pixel viene ritenuto essere l unità atomica della creazione del frame della scena. In un applicazione implementata utilizzando OpenGL è però possibile suddividere il pixel in più parti atomiche che permettono di ottenere una maggiore risoluzione dell immagine e che prendono il nome di sample o subpixels. La tecnica che implementa questo tipo di suddivisione viene chiamata Multisampling[15] ed è presente in ogni sistema grafico moderno, ma l applicazione in un contesto nel quale la pipeline di renderizzazione è basata sulla tecnica OIT, non è banale. Il multisampling agisce a livello dei singoli pixel andando a campionare più volte la parte di superficie che ricade all interno di esso. Ad esempio settando a 4 il parametro di multisampling, è possibile campionare quattro volte il pixel suddividendolo in quattro sample. La possibilità di campionare più volte l unità di renderizzazione, permette di aumentare la risoluzione dell elaborazione raggiungendo livelli di qualità di immagine più alti e agevola l introduzione di altre tecniche che si basano su questi principi. Una tecnica molto importante in computer grafica che sfrutta il multisampling è l Anti-aliasing[16]. L anti-aliasing riduce l effetto di aliasing (in italiano scalettatura,gradinatura) permettendo di ammorbidire le linee e smussare i bordi dell immagine, grazie all utilizzo delle multi campionature offerte dal multisampling. In figura 3.12 viene mostrato l utilizzo in simultanea delle due tecniche e il risultato finale in cui è possibile notare come il multi cam-

44 3.5. Anti-aliasing 44 pionamento permetta di stabilire in modo più preciso il colore che il pixel deve assumere. I pixel di confine infatti, in un contesto di renderizzazione semplice, possiedono un colore molto più marcato rispetto ai pixel adiacenti dello sfondo, poiché l unico campionamento avviene nella parte centrale del pixel, mentre in un contesto multi campione la variazione di colore all interno di un unico pixel può essere percepita e il colore calcolato permette una transizione più morbida tra le diverse superfici del modello e dello sfondo. (a) Multisample (b) Antialiasing Figura 3.12: utilizzo del multisample per implementare l antialiasing La tecnica Multisampling e la tecnica Anti-aliasing non sono nuove nel panorama della computer grafica ed esiste infatti un ampia documentazione che permette di implementare le due tecniche senza grandi difficoltà in molte applicazioni. Inserire però le due tecniche all interno della ben strutturata pipeline di renderizzazione basata sull algoritmo di OIT per la renderizzazione delle superfici trasparenti, assume una difficoltà molto alta dovuta al fatto che l algoritmo in questione va ad agire direttamente nello stesso contesto in cui le due tecniche normalmente operano, ovvero l elaborazione e il calcolo del colore che i pixel devono assumere. La difficoltà principale sta nel fatto che non esiste più una corrispondenza uno ad uno tra il pixel e la superficie da renderizzare, ma ogni pixel ora possiede una lista di fragment che devo-

45 3.5. Anti-aliasing 45 no essere elaborati e il cui colore deve essere miscelato tenendo conto anche dell aggiunta di valutazioni per integrare il multisampling e l anti-aliasing. Il fatto di dover campionare più di una volta ogni fragment appartenente ad un determinato pixel, facendo si che il pixel non risulti più essere l elemento atomico di creazione del frame della scena, pone il problema di come gestire i fragment all interno di un unico pixel ma che appartengono a sample diversi. In questo contesto possono essere implementate diverse soluzioni che essenzialmente possono dividersi in due macro categorie: Risoluzione per Sample: risolvere per sample significa rendere il sample l oggetto atomico di costruzione della scena. Ogni sample a questo punto assume lo stesso significato del pixel all interno della risoluzione di base in cui era l oggetto atomico della scena, possedendo quindi un proprio shader e una lista propria che concorre al calcolo del colore unicamente per il sample. Una volta che ogni sample del pixel ha calcolato il proprio colore risolvendo la propria lista dei fragment, è necessario che avvenga una media tra tutti i colori risultanti per stabilire il colore finale del pixel che rimane comunque oggetto atomico per la renderizzazione finale della scena sullo schermo. Questo calcolo finale è lasciato alla pipeline di renderizzazione di OpenGL poiché non esiste uno shader unico per il pixel. Risoluzione per Pixel: la risoluzione per pixel è molto simile alla risoluzione di base poiché ogni pixel indipendentemente dal numero di sample che lo costituiscono, possiede un unica lista per la memorizzazione dei fragment e un unico shader per il calcolo del colore che deve mostrare a schermo. All interno dell unico shader deve essere calcolato il contributo di ogni sample recuperando i fragment ad esso associati dalla lista, per poi calcolare una media dei contributo per mostrare a schermo il colore finale. Per qualsiasi soluzione scelta per la risoluzione della problematica, le strutture messe a disposizione dalla tecnica OIT diventano centrali nell implementazione e nell aggiunta delle tecniche di multisampling e anti-alising. I nodi che compongono le linked-list possiedono una struttura fissa che è stata

46 3.6. Risultati grafici 46 ampiamente descritta precedentemente e che permette di salvare nei campi al suo interno le informazioni relative al fragment di cui è contenitore. Nella tecnica OIT di base, non tutti gli spazi di memorizzazione messi a disposizione sono utilizzati per l implementazione dell algoritmo per le trasparenze e possono quindi essere utilizzati ad esempio per memorizzare informazioni relative a quale sample quel determinato fragment fa riferimento. 3.6 Risultati grafici I risultati ottenuti applicando l algoritmo sono ben visibili guardano le figure sottostanti che mostrano lo stesso modello senza e con l implementazione dell algoritmo appena descritto. La figura 3.13 mostra un modello utilizzato per lo studio dell effetto, che presenta la sovrapposizione di superfici appartenenti ad oggetti o del tutto opachi o del tutto trasparenti. Questa tipologia di oggetti è più facile da trattare poiché, conoscendo già a priori la caratteristica dell oggetto, non è necessario applicare nessun algoritmo che differenzi le mesh opache da quelle trasparenti. (a) Modello senza tecnica OIT (b) Modello con tecnica OIT Figura 3.13: differenza tra l assenza e la presenza dell algoritmo di OIT Come è possibile notare, la figura (a) presenta degli errori di renderizzazione e di miscelazione dei colori che la figura figura (b) non presenta. Gli errori sono ben visibili nella sovrapposizione degli occhi, in cui il colore verde del-

47 3.6. Risultati grafici 47 l occhio vicino alla camera dovrebbe essere predominante, ma alcuni triangoli della parte sottostante assumono il colore giallo dell occhio in secondo piano. Oppure alcuni triangoli della testa presentano un colore diverso rispetto a quello che dovrebbe essere il colore predominante, dando un peso maggiore alle mesh più lontane dalla camera piuttosto che a quelle più vicine. Infine è possibile notare come nella zona dell orecchio, sia predominante il colore dell oggetto in secondo piano, piuttosto che il colore verde dell orecchio in primo piano. Tutti questi errori vengono pienamente risolti nella figura (b) in cui si può notare come il concetto di predominanza delle superfici in primo piano rispetto a quelle in secondo, sia pienamente rispettato. La figura 3.14 mostra invece la differenza tra l assenza e la presenza dell algoritmo per le trasparenze implementato in una scena più complessa. (a) Capelli senza tecnica OIT (b) Capelli con tecnica OIT Figura 3.14: capelli lunghi femminili La complessità della scena è dovuta al fatto che il modello utilizzato per renderizzare i capelli del personaggio, possiede un numero molto elevato di mesh che si sovrappongono e si intersecano tra loro. Lo scopo dell algoritmo in questo caso non è tanto quello di creare una superficie attraverso il quale è possibile vedere un altro oggetto in secondo piano come nel modello prece-

48 3.6. Risultati grafici 48 dente, ma è quello di ricreare nel miglior modo possibile la sovrapposizione e l intersezione di superfici con un grado di trasparenza differente, che riproducano lo stesso effetto delle ciocche dei capelli. La figura (a) è il risultato di una procedura di renderizzazione che non prevede l utilizzo dell algoritmo di tipo OIT, mostrando infatti tutte le problematiche di una renderizzazione di questo tipo. Rispetto al modello di figura (b) che invece implementa l algoritmo OIT, il modello di figura (a) mostra una capigliatura diradata dovuta alla presenza di spazi bianchi che non sono dovuti allo sfondo della scena, ma sono il residuo dei bianchi presenti nelle texture che nascondono le ciocche di capelli che si trovano in secondo piano. La figura (b) non soffre di questa problematica renderizzando nel migliore dei modi sia la sovrapposizione tra ciocche di capelli, sia la sovrapposizione tra le ciocche e la pelle del personaggio. (a) Capelli senza tecnica OIT (b) Capelli con tecnica OIT Figura 3.15: capelli corti femminili La figura 3.15 mostra esattamente tutto ciò che è stato detto per quanto riguarda la figura 3.14 ma applicato su un modello più semplice con molte meno mesh da renderizzare. I risultati visivi dell algoritmo sono evidenti osservando queste figure. Le scene sono molto più simili alla realtà, ma l au-

49 3.6. Risultati grafici 49 mento della complessità della procedura di renderizzazione può comportare un peggioramento dal punto di vista delle performance del sistema, misurate in f rame/secondo (f ps). Più la scena risulta complessa, più il valore dei f ps cala, rendendo il sistema troppo lento per essere utilizzato. Lo scopo del prossimo capitolo sarà quello di descrivere le ottimizzazione che possono alzare il valore dei f ps per migliorare l esperienza di visualizzazione delle immagini create da questa procedura di renderizzazione.

50 Capitolo 4 Ottimizzazione dell algoritmo L algoritmo così come descritto nei capitoli precedenti, permette di raggiungere l obiettivo dal punto di vista della realizzazione dell effetto grafico ma presenta ancora grandi problemi dal punto di vista delle performance. Il parametro principale da osservare quando si ha che fare con un motore grafico è quanti frame riesce a produrre in un secondo (fps). Questo valore è importante perché più è alto più l immagine prodotta risulta fluida all occhio di chi osserva. Ad esempio il frame rate minimo di un filmato, affinché l apparato visivo umano non percepisca sfarfallii e artefatti, si attesta sui 29, 5f ps (30 Hz), ma può anche essere superiore per gli oggetti che si muovono molto veloci sullo schermo. Le considerazioni appena fatte suggeriscono quindi di realizzare un motore grafico che sia capace di mostrare e calcolare in real-time come minimo 30f rame/secondo, ma l algoritmo così come descritto precedentemente, riesce a raggiungere questi valori solo se il modello da renderizzare è semplice e/o occupa solo una piccola parte dello schermo (pochi pixel sono coinvolti nella fase di calcolo). L obiettivo in questo capitolo è quindi quello di ottimizzare la procedura di renderizzazione in modo da ottenere buone performance in qualsiasi tipo di scenario.

51 4.1. Memoria vs Performance Memoria vs Performance Le performance del sistema sono molto influenzate da come OpenGL gestisce gli accessi alla memoria locale in cui sono salvati i dati per la renderizzazione della scena. Ogni pixel possiede gli shader per il calcolo della geometria e del colore, i quali possiedono una zona di memoria che fa a loro riferimento. Per rendere il sistema più performante, OpenGL permette ai pixel di eseguire in parallelo le operazioni di calcolo sfruttando i thread. Il numero di possibili thread attivi però è limitato dalla disponibilità di memoria locale poiché ogni thread necessità di un proprio spazio di memorizzazione dati per essere eseguito. Figura 4.1: variazione delle performance all aumentare della memoria locale utilizzata La figura 4.1 mostra l esistenza di una proporzionalità inversa tra il numero di thread che possono essere eseguiti contemporaneamente e la dimensione di memoria che ogni thread occupa. Quindi minore è lo spazio di memoria occupato da ogni thread, maggiore sarà il numero di thread in esecuzione contemporaneamente sulla GPU, diminuendo il tempo di creazione di ogni singolo frame. Data questa caratteristica di OpenGL, l obiettivo diventa quello di tenere il più bassa possibile la memoria locale occupata da ogni singolo thread per favorire la massima parallelizzazione dell esecuzione. Il fatto che OpenGL utilizzi un allocazione statica della memoria crea però delle problematiche dal punto di vista delle performance poiché questo tipo di allocazione non permette di fare una valutazione in real-time di quella che è

52 4.2. Bottleneck nell algoritmo di OIT 52 la memoria effettivamente occupata da ogni singolo thread. 4.2 Bottleneck nell algoritmo di OIT Conoscendo ora le caratteristiche di OpenGL sulla gestione e l allocazione di memoria, possiamo analizzare l algoritmo di OIT e valutare quale siano le problematiche principali riguardanti l efficienza con la quale ogni pixel occupa il proprio spazio di memoria. Il punto critico è la memoria temporanea utilizzata per la memorizzazione e l ordinamento della lista dei fragment, dichiarata e inizializzata nell algoritmo 6 sotto forma di array. Algoritmo 6 memoria temporanea per riordino della lista dei fragment #define MAX FRAGMENTS 60 uvec4 fragmentlist[max FRAGMENTS]; lunghezza statica della lista definizione array temp La memoria temporanea è un array di tipo uvec4 poiché deve memorizzare i nodi così come recuperati dal node buffer e la sua dimensione viene stabilita tramite l utilizzo di una #define in modo del tutto statico. Ogni pixel però ha una dimensione della lista dei fragment diversa dagli altri, ma siccome l allocazione dinamica non è disponibile in OpenGL, non è possibile assegnare in real-time ad ogni array la dimensione esatta della lista che deve contenere. La figura 4.2 mostra la distribuzione della lunghezza delle liste in un modello con complessità molto alta. In giallo sono indicati i pixel che posseggono una lista di dimensione minore di 10 fragment fino a salire con step di 10 unità al colore blu con pixel con liste di dimensione maggiore a 60 fragment.

53 4.2. Bottleneck nell algoritmo di OIT 53 (a) (b) Figura 4.2: Livelli lista capelli lunghi In un sistema che alloca la memoria in modo statico, l unica soluzione per non avere nessun tipo di artefatto dovuto alla mancanza di memoria disponibile e alla conseguente perdita di informazioni, è quella di assegnare a tutti gli array la stessa dimensione, stabilita sulla dimensione della lista massima (worst case). In questo modo però si otterrà un inutile overhead sulle performance del sistema poiché, come è possibile osservare dalla figura precedente, i pixel con liste lunghe sono molto pochi rispetto agli altri e apportare questo tipo di dimensionamento comporterà la presenza di numerosissime liste per lo più vuote. In figura 4.3 viene mostrato con esattezza quanto appena detto focalizzando l attenzione sulla zona di memoria che ogni thread occupa. La maggior parte della memoria allocata non viene utilizzata (zona rossa) e ciò comporta un minor numero di thread che ha accesso alla memoria locale e quindi ad una esecuzione parallela.

54 4.3. Implementazione BMA 54 Figura 4.3: gestione statica della memoria in OpenGL 4.3 Implementazione BMA Per risolvere il problema delle performance e della poco efficiente allocazione di memoria, sarà introdotta la tecnica chiamata Backwards Memory Allocation che permette di raggruppare i thread in base alla dimensione della memoria di cui hanno bisogno in real-time ed eseguire ogni gruppo con uno shader differente che possieda un appropriata dimensione per l array di ordinamento. La parola backwards sta indicare il rovescio della concezione di memoria statica, infatti pur utilizzando un allocazione di questo tipo, la tecnica permette di avvicinarsi al concetto di allocazione dinamica sfruttando alcuni passaggi in più nella pipeline di renderizzazione Operazioni offline per BMA L implementazione della tecnica BMA parte dalla definizione di quelli che sono gli intervalli di allocazione per raggruppare i thread dei pixel, ognuno con un numero diverso di fragment da processare e quindi un diversa richiesta di dimensione della memoria. Per ogni intervallo saranno poi generati i relativi shader per ordinare e miscelare i fragment. Utilizzando diversi intervalli di dimensionamento delle liste, è possibile diminuire di molto lo spreco di memoria anche se questo non arriverà mai ad essere nullo. La creazione degli intervalli e le relative strutture, viene effettuata prima di iniziare il ciclo di renderizzazione (operazioni offline). La scelta sul dimensionamento degli intervalli non risulta decisiva ai fini delle performance,

55 4.3. Implementazione BMA 55 ma osservando il grafico in figura 4.1, si è deciso di utilizzare intervalli che seguissero la potenza del due partendo però dal valore otto (0-8,9-16,17-32,33-64,65-128). Come si può notare il primo intervallo partendo dal valore 0, comprende la lista vuota, permettendo in questo modo alle liste vuote di essere comunque inserite in un intervallo di renderizzazione, poiché sicuramente in fase di creazione della lista, ci sarà un fragment opaco salvato nella texture delle superfici opache che deve essere inserito, ad esempio il fragment opaco di sfondo. La stessa cosa accade anche per gli altri intervalli e quindi bisognerà fare in modo che il dimensionamento dell array di ogni intervallo, tenga in considerazione l aggiunta di un fragment opaco. L algoritmo 7 mostra il cambiamento che avviene nella definizione dell array temporaneo. L allocazione di memoria avviene ancora in modo statico ma ora la costante MAX FRAGMENTS assumerà il valore dell upper bound dell intervallo proprietario dello shader. Algoritmo 7 definizione della lunghezza della lista tramite BMA #define MAX FRAGMENTS upper bound uvec4 fragmentlist[max FRAGMENTS]; Operazioni online per BMA Dopo aver creato gli intervalli di renderizzazione associando ad ognuno di essi un fragment shader di risoluzione con una dimensione della lista differente, è possibile iniziare il ciclo di renderizzazione apportando delle modifiche all algoritmo di OIT per far si che in real-time ogni pixel sia assegnato al giusto intervallo di renderizzazione. Per fare in modo che questo accada è necessario svolgere tre operazioni che devono essere inserite nel processo di renderizzazione del frame, subito dopo l analisi delle superfici trasparenti, sostituendo la fase di risoluzione classica delle liste. 1. Contare il numero di fragment che ogni pixel possiede. 2. Creare una maschera che permetta di associare il giusto intervallo di esecuzione ad ogni pixel.

56 4.3. Implementazione BMA Eseguire gli shader per ogni intervallo definito dalla maschera. Contare i fragment In questa fase è necessario contare i fragment che ogni pixel possiede e salvare il numero totale in una texture. Il conteggio può essere aggiunto all interno del fragment shader che si occupa di renderizzare le superfici trasparenti (Algoritmo 8) utilizzando la funzione imageatomicadd(), che permette di incrementare di una unità il valore salvato all interno della texture countlevelsimage nella posizione relativa al pixel di riferimento. Algoritmo 8 conteggio del numero dei fragment per ogni pixel if f ragmentt rasparente.z < f ragmentopaco.z then uint index = atomiccounterincrement(); oldhead = imageatomicexchange(index); valore counter recupero vecchio ID vec4 fragmentcolor = colorcalculation(); calcolo colore fragment uvec4 node; node.x = oldhead; node.y = fragmentcolor; node.z = fragmentdepth; node.w = 0; definizione vettore per struttura nodo storenode(index,node); salvataggio nodo nel node buffer imageatomicadd(countlevelsimage, pixelposition, 1); else scarta il fragment; il fragment è coperto dal fragment opaco end Il risultato ottenuto sarà una texture aggiuntiva rispetto all algoritmo OIT di base, che permetterà di conoscere esattamente qual è il numero totale dei fragment che fanno riferimento ad un determinato pixel. Questo valore sarà necessario successivamente per capire a quale determinato intervallo di renderizzazione ogni pixel dovrà essere assegnato.

57 4.3. Implementazione BMA 57 Creazione maschera BMA La creazione della maschera che permette di assegnare ad ogni pixel il giusto intervallo di renderizzazione, è affidata all utilizzo dello Stencil Buffer[17], utilizzato spesso per delimitare le zone di renderizzazione e che possiede le dimensioni della ViewPort. L algoritmo 9 mostra come abilitare e impostare lo stencil buffer ad ogni ciclo di renderizzazione e come disabilitarlo una volta utilizzato. Algoritmo 9 creazione della maschera BMA Enable(StencilTest); Clear(StencilBufferBit); StencilOp(Keep,Replace,Replace); for ogni intervallo i do StencilFunc(Greater, 1 << i, 0xFF); renderobjects(); end Disable(StencilTest); Il ciclo for permette di renderizzare tutti gli oggetti trasparenti della scena per ogni intervallo di renderizzazione utilizzando una classica funzione di rendering alla quale è associato il fragment shader contente l algoritmo 10. Algoritmo 10 eliminazione dei pixel che hanno un numero di fragment inferiore all intervallo considerato int fragment count = imageload(countlevelsimage, pixelposition).x; if fragment count <= interval then discard; end Questo algoritmo legge dalla texture calcolata al passo precedente il numero di fragment appartenenti al pixel e tramite l utilizzo dell istruzione if scarta

58 4.3. Implementazione BMA 58 i pixel che hanno un numero di fragment più basso rispetto al valore minimo che delimita l intervallo di renderizzazione considerato in quel momento. Il risultato ottenuto tramite questo procedimento è ben visibile in figura 4.4, in cui è possibile notare come la suddivisione in intervalli venga creata colorando con sfumature di grigio differenti i pixel del modello. I pixel più scuri fanno parte di intervalli con liste corte mentre i pixel più chiari possiedono liste più lunghe. Figura 4.4: stencil buffer utilizzato per associare ad ogni pixel un intervallo di renderizzazione ai cappelli lunghi di un personaggio Eseguire gli shader degli intervalli Il passo finale per concludere la creazione del frame consiste nel considerare un intervallo alla volta e per ognuno di essi renderizzare gli oggetti dell intera scena, sia opachi che trasparenti. La maschera creata al passo precedente permetterà di renderizzare solamente le parti degli oggetti che corrispondo ai pixel facenti parte di quel determinato intervallo mentre tutti gli altri saranno scartati e renderizzati nel momento in cui sarà considerato l intervallo di cui fanno parte. L algoritmo 11 mostra la procedura finale dell algoritmo e in particolare è possibile notare la funzione StencilFunc, che permette di stabilire qual è l intervallo di renderizzazione considerato in quel momento, andando a leggere il valore della maschera BMA.

59 4.4. Performance soluzione BMA 59 Algoritmo 11 utilizzo della maschera BMA per la renderizzazione Enable(StencilTest); StencilOp(Keep,Keep,Keep); for ogni intervallo i do StencilFunc(Equal,1 << i,0xff); end renderobjects(); Disable(StencilTest); L istruzione for permette di considerare un intervallo alla volta e renderizzare solamente gli oggetti o le superfici che li compongono e che appartengono a quel determinato intervallo. La scena finale viene così composta intervallo per intervallo e mostrata a schermo una volta che tutti gli intervalli di renderizzazione hanno espresso il loro risultato. 4.4 Performance soluzione BMA In questa sezione andremo a considerare le performance del sistema in seguito all implementazione della tecnica Backwards Memory Allocation, confrontando i risultati ottenuti con le performance del sistema che implementa l algoritmo OIT di base. Inoltre grazie all introduzione della tecnica BMA, il tema della scelta dell algoritmo di ordinamento degli array temporanei assumerà un valore molto importante per quanto riguarda un ulteriore aumento delle performance, questo perché la renderizzazione ad intervalli permette di fare considerazioni diverse in base alla lunghezza della lista da ordinare Strumenti hardware e software utilizzati Le performance di un sistema grafico dipendono non soltanto da come vengono implementati gli algoritmi necessari per la renderizzazione degli oggetti e della scena, ma anche dalla potenza dell hardware e dalla bontà del software utilizzato. E necessario quindi mostrare le caratteristiche dell ambiente di

60 4.4. Performance soluzione BMA 60 sviluppo utilizzato per svolgere i test, in modo da valutare i risultati ottenuti alla luce di quello che è il contesto. Le tabelle 4.1 e 4.2 mostrano gli strumenti hardware e software utilizzati per l implementazione e lo studio delle performance. IDE: Visual Studio 2015 Linguaggio di programmazione: C++, C# Specifica (API): OpenGL 4.4 Linguaggio shader: GLSL Monitoraggio Performance: Nvidia Nsight Tabella 4.1: software utilizzato per l implementazione dell algoritmo Le funzioni grafiche utilizzate sono funzioni standard di OpenGL, quindi le considerazioni fatte sull algoritmo riguardano tutte le schede grafiche che le supportano, non solo schede grafiche Nvidia ma anche AMD. 640 CUDA Cores Boost base Clock (MHz) memory clock 2500 MHz NVIDIA GeForce GTX 960M memory interface GDDR5 memory size 4 GB OpenGL 4.5 Tabella 4.2: caratteristiche scheda grafica

61 4.4. Performance soluzione BMA Valutazione delle performance Per valutare al meglio le performance raggiunte utilizzando la tecnica BMA è necessario utilizzare un modello molto complesso, poiché l algoritmo base di OIT risulta comunque performante nel renderizzare modelli semplici e in questo modo, i vantaggi introdotti dall implementazione della tecnica BMA vengono nascosti. Tutte le valutazioni sono state fatte utilizzando il modello in figura 4.5, ovvero un modello che rappresenta i capelli di un personaggio femminile costituiti da più di vertici. Inoltre il modello, dovendo simulare le ciocche di capelli che si distendono lungo il corpo del personaggio, presenta numerose sovrapposizione di triangoli e mesh che permette di ottenere liste di differenti lunghezze. Importante è anche la grandezza della ViewPort utilizzata che determina il numero totale di pixel dello schermo che appartengono alla scena, in questo caso è stata utilizzata una ViewPort con una risoluzione di pixel. Figura 4.5: modello utilizzato per valutare le performance della tecnica BMA Per valutare la tecnica si è deciso di considerare anche l algoritmo di ordinamento utilizzato per ordinare gli array temporanei che contengo i fragment dei pixel. Questa scelta è dovuta al fatto che, essendo molto alta la mole di liste da ordinare, l algoritmo di ordinamento acquisisce importanza ed è

62 4.4. Performance soluzione BMA 62 interessante andare a valutare come la tecnica BMA si comporta in tutte le diverse situazioni. Infine le valutazioni sono state effettuate tenendo conto di dover renderizzare la scena più critica, ovvero la scena in cui le superfici trasparenti occupano quasi la totalità della ViewPort, coinvolgendo la maggior parte dei pixel nella procedura dell algoritmo. La figura 4.6 mostra la differenza di performance ottenuta introducendo la tecnica BMA, dimostrando che l algoritmo che la implementa risulta essere mediamente quattro volte e mezzo più performante rispetto all algoritmo di base nel punto più critico. Figura 4.6: differenza di performance dovuta all assenza o alla presenza della tecnica BMA Si passa infatti dai 6fps ai 26fps di media utilizzando un qualsiasi tipo di algoritmo di ordinamento. I 26fps sono molto più vicini alla soglia dei 30fps con cui l occhio umano campiona la realtà che ci circonda rispetto ai 6fps, ma ancora non è abbastanza, anche se stiamo pur sempre valutando la renderizzazione della scena più critica. Come vedremo successivamente, la tecnica BMA offre la possibilità di scegliere il giusto algoritmo di ordinamento per ogni intervallo di renderizzazione grazie al fatto che ogni intervallo possiede un fragment shader differente. Questa ulteriore analisi, porterà ad avere un incremento di performance tale da poter raggiungere anche con la renderiz-

63 4.4. Performance soluzione BMA 63 zazione della scena più critica la soglia dei 30fps. In conclusione possiamo dire che un ampia allocazione di memoria locale non utilizzata può impattare in modo significativo sulle performance del sistema. La tecnica BMA migliora le performance di quattro volte e mezza permettendo di velocizzare la renderizzazione delle scene con minore profondità e permettendo una corretta renderizzazione delle scene con una profondità elevata evitando possibili artefatti dovuti alla mancanza di memoria Algoritmi di ordinamento per gli intervalli di BMA L aggiunta della tecnica BMA all algoritmo di OIT permette di utilizzare potenzialmente un diverso tipo di algoritmo di ordinamento per ogni intervallo di renderizzazione, reso possibile dal fatto che ogni intervallo possiede un diverso fragment shader. Algoritmi per ordinare gli array ne esisto moltissimi in letteratura, ma per implementazione, caratteriste e complessità, è stato deciso di considerare cinque algoritmi diversi. Le implementazioni non saranno descritte poiché sono bene conosciute in letteratura, ma saranno elencate le caratteristiche principali che permetteranno di fare alcune valutazioni sui risultati ottenuti e sulle scelte fatte. Insertion Sort: l ordinamento a inserimento è un algoritmo relativamente semplice ed è un algoritmo in place, cioè ordina l array senza doverne creare una copia. Il fatto che sia un algoritmo in place è molto importante poiché una eventuale copia, andrebbe ad impattare sulla dimensione delle memoria locale vanificando l aumento delle performance dovute alla tecnica BMA. Inoltre pur essendo molto meno efficiente di algoritmi più avanzati, risulta molto efficiente nel caso in cui l insieme di partenza è quasi ordinato, oppure il numero degli elementi da ordinare è piccolo. La complessità media temporale è O(n 2 ). Bubble Sort: algoritmo in place in cui ogni coppia di elementi adiacenti viene comparata e invertita di posizione se sono nell ordine sbagliato. L algoritmo continua nuovamente a rieseguire questi passaggi

64 4.4. Performance soluzione BMA 64 per tutta la lista finché non vengono più eseguiti scambi, situazione che indica che la lista è ordinata. La complessità media temporale è O(n 2 ). Shell Sort: algoritmo simile all insertion sort, ma funziona spostando i valori di più posizioni per volta man mano che risistema i valori, diminuendo gradualmente la dimensione del passo sino ad arrivare ad uno. La complessità rimane simile all insertion sort ma migliora per quanto riguarda il caso ottimo temporale che passa da O(n 2 ) a O(n log 2 n). Merge Sort: è un algoritmo di ordinamento basato su confronti che utilizza un processo di risoluzione ricorsivo, sfruttando la tecnica del Divide et Impera, che consiste nella suddivisione del problema in sottoproblemi della stessa natura di dimensione via via più piccola. L algoritmo risulta essere molto efficiente poiché possiede una complessità di tipo O(n log 2 n) ma a causa di un problema di specifica non può essere espressa in questo contesto. La problematica è che OpenGL non permette di scrivere shader che possiedono parti di codice ricorsive, quindi è necessario utilizzare la versione del merge sort che non utilizzi la ricorsione. Questa versione però utilizza un array di appoggio che aumenta la memoria utilizzata da ogni singolo shader vanificando in parte l aumento delle performance dovute alla tecnica BMA. Heap Sort: è un algoritmo di ordinamento iterativo ed in-place proposto che si basa su strutture dati ausiliarie. Per eseguire l ordinamento, utilizza una struttura chiamata heap rappresentabile con un albero binario in cui tutti i nodi seguono una data proprietà, detta priorità. Esso è completo almeno fino al penultimo livello dell albero e ad ogni nodo corrisponde uno ed un solo elemento. La descrizione dei principali algoritmi di ordinamento, mostra come il contesto in cui vengono implementati sia molto influente e snaturi le reali potenzialità descritte in letteratura. Il grafico in figura 4.7 mostra l influenza degli algoritmi in ogni intervallo della tecnica BMA utilizzando una scena test costituita da numerosissimi oggetti trasparenti sovrapposti. Siccome il numero di pixel appartenenti ad ogni intervallo è diverso e le performance dipendono molto dal numero di liste da ordinare, ogni intervallo deve essere

65 4.4. Performance soluzione BMA 65 analizzato autonomamente dagli altri. Dai risultati ottenuti, si è deciso di utilizzare per la renderizzazione di questo modello due algoritmi di ordinamento, ovvero lo Shell Sort per i primi tre intervalli e il Bubble Sort per gli ultimi due permettendo alla scena complessa di raggiungere i 30f ps nel punto in cui tutta la ViewPort è coinvolta nella renderizzazione delle superfici trasparenti. Figura 4.7: performance algoritmi di ordinamento per ogni intervallo di renderizzazione Il fatto che nei primi intervalli gli algoritmi come l Insertion Sort e lo Shell Sort siano i più efficienti, è del tutto prevedibile. Le liste di questi intervalli sono corte e algoritmi che, sebbene abbiano una complessità temporale alta, non possiedono una struttura complessa, risultano più efficaci. Per quanto riguarda gli intervalli che possiedono liste più lunghe invece accade ciò che non ci si aspetterebbe basandoci sulle caratteristiche descritte in letteratura. Algoritmi come il Merge Sort oppure l Heap Sort, risultano essere meno efficaci di algoritmi che in realtà possiedono una complessità temporale superiore. Il contesto infatti penalizza molto questo tipo di algoritmi poiché l utilizzo di strutture aggiuntive e l impossibilità di utilizzare la ricorsione all interno degli shader, ne limita le performance. Così il Bubble Sort grazie alla sua semplicità di implementazione e di attuazione, pur con una complessità temporale del tipo O(n 2 ) che lo rende uno degli algoritmi di ordinamento meno

66 4.4. Performance soluzione BMA 66 efficienti in letteratura, risulta essere il più efficace tra tutti gli algoritmi considerati per quanto riguarda liste più lunghe. Figura 4.8: performance algoritmi di ordinamento per ogni intervallo di renderizzazione in rapporto con l insertion sort Il grafico di figura 4.8 prende come riferimento per ogni intervallo l algoritmo di Insertion Sort rendendo ancora più visibili le considerazione fatte precedentemente.

67 Capitolo 5 Tecnica OIT per la correzione di errori di renderizzazione L implementazione e l ottimizzazione dell algoritmo di Order Independent Transparency che utilizza come struttura dati una linked list per ogni pixel della ViewPort, permette di raggiungere alti livelli di performance sia dal punto di vista quantitativo che da quello qualitativo, creando l effetto di trasparenza desiderato. L algoritmo introduce una pipeline di renderizzazione ben strutturata che può essere utilizzata, oltre che per lo scopo principale, anche per svolgere operazioni a livello di singolo fragment, poiché le linked list offrono un ampia conoscenza di come la scena e ogni modello presente in essa si sviluppano in profondità coprendo un determinato pixel da una certa distanza. In questo capitolo andremo ad affrontare in particolare l utilizzo della tecnica OIT e delle sue strutture, per risolvere errori di renderizzazione dovuti alla sbagliata sovrapposizione di superfici appartenenti a modelli diversi. 5.1 Errata sovrapposizione delle superfici Durante la fase di renderizzazione della scena, esistono situazioni in cui non è possibile variare quelle che sono le dimensioni delle singole mesh appartenenti allo stesso modello, sia per il fatto che intervenire su di esso dopo averlo importato nella pipeline di renderizzazione può non risultare semplice, sia

68 5.1. Errata sovrapposizione delle superfici 68 per il fatto che in alcune situazioni implementative il modello deve possedere delle determinate caratteristiche dimensionali. Inoltre può accadere che il modello abbia delle animazioni che in real-time modificano le dimensioni del modello, facendo si che i rapporti dimensionali tra modelli che interagiscono all interno della scena vengano modificati e portino alla luce alcuni errori di sovrapposizione delle mesh. Figura 5.1: errata intersezione tra superfici L esempio di figura 5.1 è emblematico per quanto riguarda questo tipo di problematica. I tre modelli presenti in figura, ovvero il corpo del personaggio, i capelli e la maglietta, occupano uno spazio ben preciso all interno della scena ed essendo tutti elementi che concorrono alla creazione di un personaggio, alcune delle loro mesh necessitano di sovrapporsi tra loro per creare una figura completa. Per quanto riguarda l interazione tra il corpo e i capelli del personaggio non esiste alcuna problematica poiché essendo i capelli renderizzati come modello interamente costituito da mesh trasparenti, l algoritmo di OIT svolge in pieno il suo lavoro, mentre l interazione tra due modelli opachi come il corpo e la maglietta, se non dimensionati a dovere, genera errori di intersezione di superfici che in realtà non dovrebbero intersecarsi. Le mesh che modellizzano il seno del personaggio femminile, possiedono una dimensione che va oltre alla dimensione concessa dal modello della maglietta,

69 5.1. Errata sovrapposizione delle superfici 69 facendo si che la maglietta risulti bucata quando invece dovrebbe coprire il corpo del personaggio. (a) (b) Figura 5.2: intersezione tra mesh appartenenti a due modelli differenti La figura 5.2 mostra il dettaglio di ciò che accade effettivamente a livello dei singoli triangoli che costituiscono le superfici dei due modelli che entrano in contatto, rappresentando in blu i triangoli che modellizzano la maglietta e in nero quelli che modellizzano il corpo del personaggio (figura b). La maglietta è renderizzata completamente, anche in quelle zone in cui la superficie si trova erroneamente dietro al corpo del personaggio e tramite l utilizzo della tecnica OIT, che permette di conoscere ciò che accade per ogni fragment ad ogni livello di profondità della scena, problemi di questo tipo possono essere risolti poiché la tecnica permette di rilevare la presenza e il contributo delle superfici nascoste come in questo caso. Non potendo modificare la dimensioni dei modelli a causa delle problematiche spiegate in precedenza e non potendo quindi invertire in modo fisico l ordine delle superfici nei punti critici, la tecnica OIT permette di invertire l ordine in modo virtuale, nel senso che le superfici continuano ad essere renderizzate nello stesso modo, ma sfruttando la possibilità di agire su ogni singolo fragment dei pixel è possibile rendere trasparente la parte di corpo che

70 5.2. Correzione frontale 70 sporge oppure renderla del colore del fragment appartenente alla maglietta che si trova subito dietro rispetto al fragment della pelle nella linked-list del pixel. 5.2 Correzione frontale Strutture OIT per la risoluzione Utilizzare la tecnica OIT per risolvere questo tipo di problemi, significa anche utilizzare e sfruttare le strutture implementate dalla tecnica per il suo normale scopo senza doverne creare altre che potrebbero inficiare sulle performance del sistema. Le strutture presentate nei capitoli precedenti sono state create con lo scopo di implementare l effetto di trasparenza in un ambiente che sia il più possibile ottimizzato sia in termini di tempo speso nell elaborazione sia in termini di spazio totale di memoria occupato per memorizzare tutte le informazioni necessarie per la creazione del frame. Accade però che in alcune situazioni si è obbligati dal contesto a dover utilizzare delle funzioni o delle strutture che per favorire l ottimizzazione della velocità di calcolo perdono in performance dal punto di vista dello spazio occupato in memoria o viceversa. Variabile Dimensione in byte NextPointer 4 Color 4 Depth 4 4 Totale 16 Tabella 5.1: struttura interna di un nodo nel Node Buffer con il quarto spazio del vettore non utilizzato Una delle strutture soggette a questo tipo di ragionamento è ad esempio la struttura dati utilizzata per salvare le informazioni relative ad un fragment nel node buffer (Tabella 5.1). Per far si che il numero di accessi alla zona di memoria sia il minore possibile, l algoritmo OIT permette di salvare tutte le

71 5.2. Correzione frontale 71 informazioni necessarie all interno di un unico vettore anziché creare un buffer differente per ogni tipologia di informazione. In questo caso però, a fronte di uno spazio di memoria che può contenere un vettore con quattro elementi, le informazioni salvate all interno della struttura sono solo tre lasciando per ogni fragment salvato uno spazio libero della dimensione di 4 byte. Lo spazio vuoto lasciato dall algoritmo di OIT diventa di fondamentale importanza in questo frangente, poiché sfruttandolo è possibile aggiungere nuove informazioni che permettono nei passi successivi della pipeline di renderizzazione di prendere decisioni diverse su ogni singolo fragment del frame Algoritmo di correzione Una volta definito il punto di congiunzione tra la tecnica OIT e la correzione degli errori dovuti all intersezione tra modelli differenti, possiamo entrare nello specifico della risoluzione dell errore di renderizzazione che si presenta nella scena di figura 5.1 in cui alcune mesh della maglietta del personaggio venivano sovrastate dalle mesh che modellizzano il corpo della figura femminile. Alla base di tutto il procedimento di correzione vi è il fatto di rendere l algoritmo capace di capire in modo autonomo quale tipologia di superficie deve essere visibile in un determinato punto della scena. Questa capacità ovviamente non è intrinseca nella normale pipeline di renderizzazione, ma deve essere implementata fornendo in fase di modellizzazione le informazioni necessarie per far si che durante l elaborazione in real-time della scena, l algoritmo possa dare una certa priorità ad una superficie piuttosto che ad un altra. Ecco che il concetto di priorità diventa fondamentale per l algoritmo di correzione della scena e ad ogni fragment deve essere aggiunto questo tipo di informazione all interno della struttura (Tabella 5.2). Variabile Dimensione in byte NextPointer 4 Color 4 Depth 4 Priority 4 Tabella 5.2: aggiunta dell informazione di priorità all interno della struttura del nodo

72 5.2. Correzione frontale 72 Algoritmo 12 inserimento informazione relativa alla priorità di renderizzazione dei fragment if f ragmentt rasparente.z < f ragmentopaco.z then uint index = atomiccounterincrement(); oldhead = imageatomicexchange(index); valore counter recupero vecchio ID vec4 fragmentcolor = colorcalculation(); calcolo colore fragment int priorityfragment = 1; uvec4 node; definizione vettore per struttura nodo node.x = oldhead; node.y = fragmentcolor; node.z = fragmentdepth; node.w = priorityfragment; storenode(index,node); else scarta il fragment; end salvataggio nodo nel node buffer il fragment è coperto dal fragment opaco L informazione relativa alla priorità viene aggiunta in fase di renderizzazione delle superfici trasparenti nel momento in cui viene creato il vettore che la conterrà insieme alle informazioni relative al colore e alla profondità del fragment (Algoritmo 12). Siccome questo tipo di memorizzazione si esegue solo nella fase della pipeline in cui avviene il processamento delle superfici trasparenti poiché solo in questa fase esistono strutture adatte allo scopo, i modelli della scena che con una risoluzione classica sarebbero considerati opachi, se sono soggetti ad errori di questo tipo, devono essere considerati trasparenti ed elaborati di conseguenza. L algoritmo 12 descrive esattamente ciò che accade nella fase in cui viene renderizzata la maglietta del personaggio preso ad esempio per la descrizione dell algoritmo. Il vettore di memorizzazione non avrà più lo spazio W vuoto,

73 5.2. Correzione frontale 73 ma conterrà il valore 1 che permette di dare priorità ai fragment appartenenti al modello della maglietta rispetto ai fragment relativi alla pelle del personaggio, la cui priorità sarà settata a 0. Se prendiamo ad esempio i pixel della ViewPort in cui avviene l errata renderizzazione delle superfici e andiamo ad analizzare le linked list a loro relative, notiamo che i fragment possiedono la tipologia di ordinamento descritta in figura 5.3. Figura 5.3: linked list di un pixel appartenente allo spazio in cui avviene l errore di renderizzazione La linked list in figura è una fotografia di ciò che accade poco prima della renderizzazione finale della scena, fase in cui è già avvenuto l ordinamento finale delle superfici. Come è possibile notare infatti l ordinamento in base all informazione relativo alla distanza è rispettato, ma ora che è stato introdotto il parametro di priorità, è opportuno analizzare ulteriormente l array di ordinamento prima di miscelare il colore. In questo caso infatti il fragment in seconda posizione ha una priorità superiore rispetto al fragment in prima posizione anche se la sua distanza dalla camera è inferiore. Dopo aver verificato che i due fragment si trovino ad una distanza inferiore ad un certo valore di threshold, per far si che l analisi avvenga solo tra fragment appartenenti a superfici vicine, può iniziare l algorimtmo di correzione, il quale può agire in due modi differenti: Inversione dei fragment: il fragment con priorità più alta viene invertito di posto con il fragment con priorità più bassa. Questa soluzione permette di mantenere le informazioni relative al fragment con priorità più bassa in modo da poterle utilizzare se necessario in fase di miscelazione. Una soluzione di questo tipo permette di correggere l errore tra superfici trasparenti.

74 5.2. Correzione frontale 74 Figura 5.4: inversione dei fragment nella lista in base alla priorità Cancellazione dei fragment con priorità più bassa: il fragment con priorità più bassa viene cancellato dall array di miscelazione mentre i fragment rimasti vengono spostati di una posizione verso sinistra. In questo caso le informazioni relative al fragment a bassa priorità vengono perse e in fase di miscelazione il risultato sarà identico a quello ottenuto senza la renderizzazione di quella particolare superficie. Questa soluzione può essere utilizzata quando il fragment a priorità alta è opaco e nasconde tutto ciò che si trova dietro di lui. Figura 5.5: cancellazione fragment con priorità minore Algoritmo 13 ordinamento delle liste in base alla priorità for ogni fragment i presente nella lista do end if f ragmentsuccessivo.z f ragment.z < threshold then algoritmo per la cancellazione del fragment for j = i 1; j < fragment count 1; j + + do fragment list[j] = fragment list[j + 1]; end Oppure uvec4 tmp = fragment list[i-1]; fragment list[i-1] = fragment list[i]; fragment list[i] = tmp; end algoritmo di inversione delle posizioni

75 5.2. Correzione frontale 75 L algoritmo 13 riassume utilizzando lo pseudo codice tutto ciò che è stato detto precedentemente ed è possibile notare come il controllo della distanza tra i due fragment interessati è la prima operazione che viene eseguita. Questa osservazione ci porta ad effettuare delle considerazioni riguardo a come le distanze devono essere elaborate in questo tipo di operazioni. Molto spesso nelle implementazioni effettuate nel fragment shader per riferirsi alle distanze dei pixel si utilizza la variabile gl FragCoord messa a disposizione da GLSL per contenere le informazioni relative alle screen coordinates di quel determinato pixel che il fragment shader sta processando. Questo tipo di coordinate però non offrono un valore della distanza che abbia una variazione lineare tra il Near Plane e il Far Plane comportando ulteriori problematiche per quanto riguarda il controllo delle distanze effettuato dall algoritmo di correzione, poiché al variare della posizione della camera nello spazio varierà anche il valore della distanza tra le superfici, rendendo il controllo del tutto impossibile. Figura 5.6: variazione non lineare della variabile Z in screen coordinates La soluzione al problema è implementare tutto il sistema OIT sulla base dell utilizzo di coordinate che possano offrire una variazione lineare della distanza e che possano definire una posizione assoluta delle superfici all interno della scena. Le coordinate adatte a questo tipo di operazione sono le camera view coordinates ed è possibile ottenerle ad esempio tramite l applicazione della matrice inversa di proiezione alla matrice MVP di renderizzazione. Qualunque sia la tipologia di algoritmo scelto per l implementazione, il risultato raggiunto sarà il medesimo ed è ben visibile in figura 5.7. Il colore delle superfici errate viene ricalcolato sulla base del colore della superficie nasco-

76 5.3. Correzione laterale 76 sta permettendo di rimediare all errore senza dover modificare le dimensioni fisiche del modello. (a) (b) Figura 5.7: correzione errori con personaggio in posizione frontale 5.3 Correzione laterale L algoritmo descritto precedentemente permette di correggere con ottimi risultati l errore di sovrapposizione delle mesh, ma così come implementato non ha la possibilità di poter gestire in modo ottimale alcune situazioni particolari che possono presentarsi durante la fase di renderizzazione Spiegazione della problematica Negli esempi precedenti il corpo del personaggio era in posizione frontale rispetto alla camera facendo si che le superfici da correggere avessero sempre un fragment in seconda posizione che potesse risolvere l errore tramite l esecuzione dell algoritmo di correzione. Nel caso in cui invece il personaggio assuma una posizione laterale rispetto alla camera, può accadere che i fragment da correggere non abbiano un fragment in seconda posizione che possa

77 5.3. Correzione laterale 77 prendere il loro posto e risolvere il problema, poiché il fragment correttore, che in posizione frontale sarebbe stato nella stessa lista del fragment da correggere, in posizione laterale sarà assegnato alla lista di un pixel laterale rispetto al pixel considerato. Tutto ciò che è stato appena descritto accade nell esempio di figura 5.8, in cui si può notare come l errore torni a ripresentarsi nei punti in cui l algoritmo di correzione aveva già operato. Le liste dei pixel coinvolti non contengono più dei fragment che grazie alle loro caratteristiche possano essere utilizzati come fragment correttori e il problema torna ad esistere. Figura 5.8: posizione nella lista errore dovuto alla mancanza del fragment della maglietta in seconda Le principali cause che portano ad avere un errore di renderizzazione anche dopo aver applicato l algoritmo di correzione, sono essenzialmente di due tipologie diverse: Mancanza di un fragment correttore: quando la camera ruota attorno al personaggio, le liste associate ai pixel vengono ricalcolate e i fragment che prima appartenevano alla stessa lista ora sono associati a liste appartenenti a pixel adiacenti. In questo modo accade che alcuni pixel che devono essere corretti dall algoritmo non possiedono più fragment correttori che possano risolvere l errore.

78 5.3. Correzione laterale 78 Figura 5.9: mancanza di un fragment correttore nella lista del pixel errato La lista rappresentata in figura 5.9 non contiene fragment correttori poiché l unico fragment oltre a quello da correggere è il fragment opaco dello sfondo che per caratteristica possiede la più bassa priorità all interno della scena e possiede una distanza pari alla distanza del FarPlane. Fragment correttore non adatto: in questo caso il fragment correttore è presente all interno della lista del pixel da correggere, ma l algoritmo di correzione non lo prende in considerazione a causa del fatto che il delta tra le distanze dei due fragment è superiore rispetto al valore di threshold utilizzato dall algoritmo per far si che l elaborazione del risultato avvenga unicamente tra fragment vicini. Anche se questo tipo di ragionamento comporta la renderizzazione errata della scena, non è possibile farne a meno poiché permette di evitare correzioni tra superfici che non appartengono allo stesso contesto all interno della scena. Figura 5.10: lista con fragment correttore distante rispetto al fragment da correggere In figura 5.10 è rappresentata la lista di un pixel errato che concorre alla renderizzazione del personaggio femminile presente nella scena d esempio. Il fragment correttore appartiene ad una superficie del modello della maglietta che è distante dal punto in cui deve avvenire la correzione. Più la distanza è ampia più diventa difficile garantire la giu-

79 5.3. Correzione laterale 79 sta correzione per tutti i pixel errati della scena poiché il colore della maglietta potrebbe non essere uniforme su tutto il modello. In seguito alle considerazioni effettuate possiamo dire che l algoritmo di correzione delle superfici errate così come descritto e implementato non è completo, infatti l algoritmo risolve solo in parte il problema poiché le superfici che non possiedono fragment correttori adatti non possono essere corrette in nessun modo Nuovo algoritmo di correzione La soluzione a questo tipo di problematica è trovare un modo per correggere il fragment errato in qualsiasi tipo di situazione, anche quando la lista non possiede alcun tipo di fragment correttore per rimediare all errore. Il problema principale è che generalizzando la correzione ad ogni tipo di situazione, i fragment errati che non possiedono fragment correttori nella stessa lista non sono facilmente riconoscibili in modo sistematico dall algoritmo e il rischio è quello di andare a correggere superfici che in realtà non andrebbero corrette. L unica soluzione possibile quindi è correggere l errore nel momento in cui la lista del pixel da correggere contiene un fragment correttore e salvare l informazione di avvenuta correzione in modo tale che, se in un frame successivo la superficie corretta non ha più un fragment correttore nella lista che possa correggerla di nuovo, si possa ricordare che in precedenza è stata corretta e quindi non dovrà più fornire il suo contributo in fase di renderizzazione dei nuovi frame. Sulla base di ciò che è stato detto possiamo dire che l algoritmo precedente è un ottima base di partenza per costruire un nuovo algoritmo di correzione che abbia in più la capacità di rendere permanente nel tempo le correzioni effettuate. Il modo migliore per offrire questo tipo di capacità all algoritmo è quello di rendere possibile la modifica diretta della texture che contiene le superfici da correggere in modo tale che, se la texture dovrà essere utilizzata per la costruzione del frame successivo, essa sarà già modificata in modo ottimale per la renderizzazione senza alcun tipo di errore. L algoritmo 14 rappresenta l implementazione del nuovo algoritmo di correzione che rimane del tutto simile al precedente tranne per l aggiunta di una riga di codice che

80 5.3. Correzione laterale 80 permette la modifica della texture. Grazie alla sua implementazione, ogni volta che avviene una correzione, la funzione imagestore() setta a 0 il channel alpha della texture in modo da rendere il colore trasparente nel punto definito dalle coordinate U V appartenenti al pixel in questione. Algoritmo 14 rendere permanente la correzione delle superfici for ogni fragment i presente nella lista do if f ragmentsuccessivo.z f ragment.z < threshold then uvec4 tmp = fragment list[i-1]; fragment list[i-1] = fragment list[i]; fragment list[i] = tmp; imagestore(texturefile,ivec2(pixel.x,pixel.y), vec4(1,1,1,0)); end end Il fatto di aver reso trasparente il colore del fragment da correggere, permette di non doversi più preoccupare nei frame successivi di riordinare i fragment errati all interno della lista in cui avviene l errore poiché il fragment errato, avendo l alpha channel settato a 0 non ha più l opportunità di poter dare il proprio contributo in fase di miscelazione del colore. Figura 5.11: renderizzazione lista con fragment errato trasparente Da ora in poi le liste errate, che con il vecchio algoritmo non erano modificabili a causa dell elevata distanza tra il fragment da correggere e il fragment correttore oppure della mancanza totale di un fragment correttore, possono essere renderizzate nel modo corretto senza preoccuparsi di dover effettuare un riordino (Figura 5.11). Il primo fragment da correggere ora possiede un

81 5.3. Correzione laterale 81 colore trasparente permettendo senza problemi la sua renderizzazione poiché la miscelazione dei colori effettuata dall algoritmo OIT fa si che il fragment errato non dia più alcun contributo dal punto di vista del colore. (a) modello senza correzione (b) applicazione texture corretta Figura 5.12: applicazione della texture corretta sul modello del personaggio In figura 5.12 è possibile verificare che il nuovo algoritmo rispetta esattamente quelli che sono i prerequisiti specificati all inizio del capitolo. Il modello in figura (a) non subisce alcun tipo di modifica dal punto di vista delle dimensioni delle mesh che lo compongono, ma una volta che la texture corretta viene applicata, come in figura (b), le correzioni diventano visibili. Anche con l applicazione del nuovo algoritmo quindi le correzioni non avvengono a livello fisico, ma una corretta applicazione del colore alle mesh che compongo il modello, rendono l effetto di correzione in modo virtuale. In figura 5.13 viene mostrato tutto il potenziale del nuovo algoritmo di correzione. Il personaggio non presenta più nessuna imperfezione sia in posizione frontale che in posizione laterale rispetto alla camera e non avviene nessun tipo di alterazione nelle zone in cui la correzione non deve avvenire, risultando un algoritmo estremamente preciso nella risoluzione di questo tipo di

82 5.4. Differenze implementative e di performance tra i due algoritmi di correzione 82 problematiche. Inoltre l effetto introdotto dalla tecnica OIT non risente delle modifiche introdotte in questa fase, ma permette ancora di avere una qualità alta per quanto riguarda la renderizzazione delle superfici trasparenti. (a) (b) Figura 5.13: correzione errore con personaggio in posizione laterale 5.4 Differenze implementative e di performance tra i due algoritmi di correzione L ultimo algoritmo presentato oltre ad essere più performante dal punto di vista della capacità di correggere gli errori di sovrapposizione presenti nella scena, rispetto al primo algoritmo descritto risulta essere più performante per quanto riguarda il tempo e le modalità di esecuzione. La caratteristica principale del secondo algoritmo infatti è quella di poter essere eseguito un unica volta all inizio della renderizzazione della scena per poi non essere

83 5.4. Differenze implementative e di performance tra i due algoritmi di correzione 83 più utilizzato per la realizzazione di ogni singolo frame. Questo è possibile poiché la modifica della texture permette di rendere permanente la correzione delle superfici. Il primo algoritmo invece, non avendo memoria, deve ad ogni frame ricalcolare le correzioni rendendo la pipeline di renderizzazione più pesante e lenta dal punto di vista dell elaborazione del colore dei pixel che compongono la scena. Alla luce di quanto detto, mentre il primo algoritmo può essere inserito nella pipeline di renderizzazione di ogni singolo frame della scena, l algoritmo completo necessita di uno spazio al di fuori della pipeline di renderizzazione che permetta una sua esecuzione solo per pochi frame all inizio della scena. Questo tipo di approccio permette di dividere la costruzione della scena in due parti: 1. Correzione delle superfici: in questa prima fase avviene la vera e propria esecuzione dell algoritmo e correzione delle superfici. Per far si che la modifica della texture avvenga in modo completo, il modello deve trovarsi in una posizione tale per cui tutti i pixel da correggere abbiano nelle proprie liste almeno un fragment correttore idoneo all operazione di correzione. Figura 5.14: localizzazione sulla texture dei fragment da correggere

84 5.4. Differenze implementative e di performance tra i due algoritmi di correzione 84 Nell esempio della scena su cui abbiamo focalizzato l attenzione in questo capitolo e in quelli precedenti (Figura 5.14), la posizione idonea per correggere le superfici errate del corpo del personaggio è la posizione frontale. Questo tipo di posizione permette di inserire all interno di tutte le liste dei pixel i fragment relativi al modello della maglietta che possiedono una priorità superiore rispetto agli altri. Ogni volta che avviene una correzione all interno della lista, deve avvenire la modifica della texture per settare a 0 l alpha channel dei texel coinvolti. E necessario infine che il processo di correzione e di modifica della texture avvenga nel corso di più frame per avere un effetto di correzione accettabile e che la camera venga progressivamente avvicinata alle zone della scena che necessitano di essere elaborate e corrette. L avvicinamento da parte della camera permette di agire e modificare ogni texel della texture poiché la distanza ravvicinata aumenta la sua risoluzione. 2. Normale renderizzazione: in seguito al gruppo di frame necessari per la correzione, la texture risulta modificata. A questo punto l algoritmo di correzione ha svolto il suo compito e non è più necessario un suo intervento nei frame successivi. Ogni frame quindi viene realizzato sfruttando unicamente le proprietà della tecnica OIT che durante la fase di miscelazione dei colori permette di non tenere conto dei fragment trasparenti modificati.

85 Capitolo 6 Separazione mesh opache e trasparenti Nei capitoli precedenti è stata descritta l implementazione e l ottimizzazione dell algoritmo di OIT partendo dall assunzione che una divisione delle mesh in opache e trasparenti fosse stata fatta precedentemente. In questo capitolo si entrerà nel merito della classificazione delle mesh per separare i poligoni in due diversi vertex buffer, il primo utilizzato nella prima fase dell algoritmo OIT per la renderizzazione delle superfici opache mentre il secondo utilizzato per la seconda fase in cui vengono renderizzate le superfici trasparenti. Per separare le mesh è necessario conoscere il canale alpha dei texel della texture di riferimento e valutarne il valore in esso contenuto. Esiste uno svariato numero di modi per valutare i texel all interno di una texture, ma in questo caso descriveremo le due tipologie principali che raccolgono la maggior parte delle caratteristiche e delle considerazioni da fare su di essi. 6.1 Algoritmo esatto Il primo algoritmo presentato è detto esatto, poiché permette di stabilire con estrema precisione se un triangolo della mesh è opaco oppure trasparente. L algoritmo valuta tutti i triangoli che costituiscono le mesh del modello, andando ad analizzare unicamente i texel della texture le cui coordinate U V sono interne alle coordinate U V dei vertici del triangolo considerato. Inol-

86 6.1. Algoritmo esatto 86 tre, alcune implementazione estreme fan si che possa bastare un unico pixel trasparente per dichiarare trasparente il triangolo del modello (Algoritmo 15). Algoritmo 15 classificazione poligoni con algoritmo esatto v 0 vertices[0].uv v 1 vertices[1].uv v 2 vertices[2].uv bb.bottomleft min(min(v 0, v 1 ), v 2 ) Costruzione del bounding box bb.topright max(max(v 0, v 1 ), v 2 ) texelw idth 1.0/getT exturew idth(texture) texelheight 1.0/getT extureheight(texture) for y bb.bottomlef t.y to bb.topright.y step texelheight do for x bb.bottomlef t.x to bb.topright.x step texelw idth do I due cicli for permettono di muoversi all interno del bounding box p (x, y) edge 1 edgef unction(v 0, v 1, p) edge 2 edgef unction(v 1, v 2, p) edge 3 edgef unction(v 2, v 0, p) end end if edge 1 0 and edge 2 0 andedge 3 0 then il punto p è interno al triangolo considerato end alpha samplet exture(texture, sampler, p).alpha if alpha < threshold then return true; end return false; Il poligono contiene la trasparenza Il poligono non contiene alcuna trasparenza Il grado di esattezza con cui possono essere valutate le mesh è deciso dal pro-

87 6.2. Algoritmo statistico 87 grammatore andando a variare il valore di threshold del canale alpha oppure cambiando il numero minimo di texel trasparenti per dichiarare un triangolo trasparente. Quello che non cambia è l impostazione di base dell algoritmo che consiste nel creare un bounding box (il rettangolo giallo in figura 6.1) che intersechi esattamente le U V corrispondenti ai vertici del triangolo. La costruzione del bounding box è il passaggio preliminare che permette di delimitare la zona di lavoro unicamente ai texel della texture che sono coinvolti nella renderizzazione effettiva di quel particolare triangolo. L intero bounding box viene percorso come se fosse una matrice utilizzando un doppio ciclo for e ogni texel all interno del bounding box viene analizzata. In un primo momento si stabilisce se il texel è interno o meno al triangolo che si sta analizzando utilizzando per ogni suo lato la funzione edgefunction. In un secondo momento, se la verifica di appartenenza da esito positivo, si valuta il grado di trasparenza del texel. Figura 6.1: bounding box per un triangolo della mesh 6.2 Algoritmo statistico L algoritmo statistico si differenzia dall algoritmo esatto dal fatto che il procedimento di valutazione avviene utilizzando un altra prospettiva. Il focus non è più su ogni singolo triangolo del modello, ma l oggetto dell intera valutazione diventa unicamente la texture. Tramite l utilizzo di questa tipologia

88 6.2. Algoritmo statistico 88 di algoritmo, la texture viene analizzata e dichiarata opaca oppure trasparente e da questo momento ogni triangolo del modello sarà dichiarato opaco o trasparente in base al grado di trasparenza dell intera texture ad essi collegata. Per valutare la texture il metodo più efficace è utilizzare una tecnica di campionamento che possa dare un risultato statistico soddisfacente senza dover analizzare l intera texture. Il metodo più efficace in questo caso è il campionamento sitematico che differisce dal campionamento casuale dal punto di vista della tecnica di estrazione delle unità. Infatti l estrazione non avviene più in maniera casuale, ma una volta estratto il primo elemento, il secondo estratto sarà scelto tramite l utilizzo di un intervallo di campionamento partendo dalla posizione del primo. Il vantaggio del campionamento sistematico è che consente di ottenere un campione formato da unità che provengono da ogni parte della texture e non solo da alcune sue parti come potrebbe avvenire per effetto della casualità introdotta da un campionamento casuale. Figura 6.2: applicazione campionamento sistematico su una texture In figura 6.2 è stato applicato il campionamento sistematico su una texture utilizzata per creare il cuoio capelluto di un personaggio. L intervallo di campionamento è stato scelto in modo tale da non permettere all algoritmo di campionare due volte lo stesso texel, sfruttando la definizione dei numeri

89 6.3. Conclusioni 89 coprimi, ovvero due numeri sono definiti coprimi se e solo se essi non hanno nessun divisore comune eccetto 1 e 1. Per il campionamento della texture in figura 6.2 è stato scelto un intervallo di campionamento pari a 19 che risulta essere coprimo della dimensione della texture pari a 144 texel (12x12). Il processo di campionamento può essere reso più efficiente introducendo una soglia di trasparenza che permetta di terminare l algoritmo di decisione una volta che viene superata dal numero di texel campionati e risultati trasparenti. In questo modo non è più necessario svolgere un campionamento completo ma, in base al contesto, è possibile determinare una soglia più o meno alta per stabilire in quale tipo di buffer di renderizzazione devono essere inserite le mesh del modello che fanno riferimento alla texture campionata. Algoritmo 16 campionamento sistematico if read from file then gettransparencyinfofromfile(texture); else texturesize = getsize(texture); int samplinginterval = getcoprime(texturesize); bool transparency = calctransparency(texture,samplinginterval,threshold); end L algoritmo 16 mostra utilizzando lo pseudo codice tutto ciò che è stato detto precedentemente riguardo al campionamento sistematico delle texture, aggiungendo inoltre, attraverso il costrutto if-else, la possibilità di decidere se calcolare la trasparenza della texture oppure leggere l informazione da un file in cui è stato salvato il risultato di una elaborazione precedente. 6.3 Conclusioni In generale i due algoritmi descritti possono essere considerati delle buone soluzioni per la separazione delle mesh trasparenti da quelle opache ma le caratteristiche più evidenti che li differenziano possono fare la differenza in alcuni ambiti. L estrema precisione dell algoritmo esatto permette di raggiungere un livello di trasparenza più elevato dovuto al fatto che la focalizza-

90 6.3. Conclusioni 90 zione del processo è su ogni singolo triangolo del modello rendendo la scena del tutto reale a discapito delle performance. L algoritmo di tipo statistico invece è soggetto ad errori di valutazione poiché la focalizzazione del processo si sposta dai triangoli del modello alle texture e inoltre la valutazione viene resa più o meno precisa dal valore soglia scelto. Una minore precisione di valutazione e il fatto di valutare unicamente le texture della scena senza dover analizzare i triangoli del modello, permettono all algoritmo statistico di avere performance superiori all algoritmo esatto. Qualsiasi sia l algoritmo di valutazione scelto è possibile applicare la separazione delle mesh in due tempi diversi: Online: il processo di valutazione e separazione delle mesh avviene durante il caricamento dell applicazione. Per diminuire il tempo di caricamento dei modelli presenti nella scena, richiede performance elevate che possono essere fornite solo nel caso in cui i triangoli o le texture da processare siano di dimensione e numero ridotto oppure se è già avvenuta precedentemente un analisi di trasparenza ed è necessario recuperare le informazioni da una struttura dati. Offline: il processo di valutazione e separazione delle mesh avviene durante la loro esportazione. La valutazione della trasparenza non compromette le performance dell applicazione in real-time poiché il processo si trova al di fuori di quella che è la pipeline di renderizzazione. Il risultato ottenuto al momento dell esportazione viene salvato in una struttura dati in modo che al momento del caricamento della applicazione è possibile separare le mesh semplicemente leggendo le informazioni salvate in essa. Anche in questo caso la scelta su quale metodo utilizzare dipende unicamente dal contesto dell applicazione. Il metodo Online permette di cambiare la valutazione di una particolare mesh in real-time variando semplicemente il valore soglia di valutazione a discapito delle performance, mentre un approccio di tipo Offline offre performance superiori ma possiede una certa rigidità nel cambiare la valutazione di ogni singola mesh.

91 Capitolo 7 Conclusione e Lavori Futuri 7.1 Riassunto delle tecnologie implementate L implementazione dell algoritmo di Order Independent Transparency ha permesso di creare l effetto di trasparenza utilizzando funzioni e strutture di base offerte da OpenGL senza dover far uso di strumenti esterni per la sua implementazione, permettendo quindi di essere inserito nella pipeline di renderizzazione della maggior parte delle applicazioni grafiche. (a) Modello senza tecnica OIT (b) Modello con tecnica OIT Figura 7.1: differenza tra l assenza e la presenza dell algoritmo OIT

92 7.1. Riassunto delle tecnologie implementate 92 In figura 7.1 è possibile notare quanto l algoritmo sia importante per la renderizzazione dei modelli trasparenti come ad esempio i capelli del personaggio oppure per risolvere errori di intersezione delle superfici come accade tra il corpo e la maglietta. Inoltre è stato possibile ottimizzare l implementazione e l elaborazione del risultato da parte dei pixel introducendo la tecnica BMA, che ha permesso di passare dai 5fps ai 30fps nelle scene più critiche, in cui le superfici trasparenti occupano la maggior parte, se non la totalità, della ViewPort, facendo si che tutti i pixel della scena siano coinvolti nell ordinamento dei fragment e nell elaborazione del colore. La tecnica BMA ha inoltre permesso di fare considerazioni riguardo all algoritmo di ordinamento migliore per ogni intervallo di lunghezza delle liste in modo da velocizzare ulteriormente la realizzazione del frame. Le strutture implementate per l utilizzo della tecnica OIT hanno permesso di avere una conoscenza importante di ciò che accade all interno della scena, facendo si che fosse possibile conoscere le informazioni relative ai fragment di ogni livello di profondità tra il NearPlane e il FarPlane. L utilizzo delle strutture OIT e le numerose informazioni relative ai fragment, hanno permesso di creare un algoritmo che potesse correggere gli errori dovuti alla sbagliata sovrapposizione delle mesh tra modelli diversi ma che si trovano nello stesso contesto di renderizzazione. L introduzione dell algoritmo di correzione non ha un impatto forte sulle performance del sistema poiché è ben integrato nelle strutture e nell implementazione dell algoritmo OIT ed è relegato per la maggior parte del tempo di elaborazione, nei primi frame di creazione dell immagine. Infine ma non meno importante è stato trattato l argomento della suddivisione delle mesh in opache e trasparenti. La suddivisione, come abbiamo visto, risulta essere fondamentale poiché permette raggiungere un certo equilibrio tra performance in termini di elaborazione del risultato e qualità dell immagine.

93 7.2. Algoritmi di trasparenza e Unity Algoritmi di trasparenza e Unity Le tecnologie trattate in questa tesi sono state implementate utilizzando un motore grafico creato con lo scopo di mostrare in virtuale il risultato degli studi effettuato sui capi d abbigliamento da parte dei designer. Questa prerogativa ha permesso di sfruttare la sua pipeline di rendering anche per lo studio delle trasparenze e delle sovrapposizioni delle superfici, poiché una scena in cui il protagonista è un personaggio necessita di renderizzare al meglio tutti i modelli ad esso collegati, come ad esempio i capelli e i vestiti che indossa. Infatti, come è stato descritto in modo ampio nei capitoli precedenti, l interazione tra modelli in questo contesto è molto elevata così come è elevato il numero di possibili errori dovuti alle sovrapposizioni. Nel panorama informatico legato alla computer grafica esistono numerose soluzioni che permettono di facilitare il lavoro di creazione di una scena 3D con lo scopo di creare contenuti interattivi, videogiochi oppure animazioni 3D. La massima espressione in questo ambito è Unity, uno strumento grafico che domina il mercato grazie al fatto di essere multipiattaforma e molto intuitivo nel suo utilizzo, permettendo di automatizzare la maggior parte delle procedure di base per quanto riguarda la renderizzazione di una scena in computer grafica. Tra le funzioni di base presenti in Unity, c è la possibilità di rendere le superfici del modello trasparenti in modo da poter creare l effetto di trasparenza all interno della scena. Questo tipo di effetto però automatizza semplicemente l algoritmo di trasparenza descritto nel capitolo 2 ovvero l alpha blending, che permette di ottenere un effetto di trasparenza senza però effettuare l ordinamento delle superfici necessario per ottenere una corretta miscelazione dei colori e un risultato finale che possa raggiungere alti livelli di performance sia grafici che di elaborazione. In figura 7.2 viene mostrata la differenza di renderizzazione dell immagine utilizzando le funzioni di base offerte da Unity (a) rispetto alla renderizzazione di immagine del motore grafico utilizzato in questo lavoro di tesi (b). Ovviamente il paragone non si basa sulle stesse prerogative, poiché la prima immagine è il risultato di una renderizzazione che utilizza una versione primitiva dell algoritmo per le trasparenze mentre il secondo è il risultato di una pipeline progettata con lo scopo di offrire un effetto di trasparenza che

94 7.2. Algoritmi di trasparenza e Unity 94 sia il più reale possibile. Il paragone però diventa necessario nel momento in cui la prerogativa di facilità di utilizzo introdotta da Unity non permette di raggiungere con la stessa facilità una qualità elevata dell immagine. (a) Trasparenza renderizzata in unity con funzioni di base (b) Trasparenza renderizzata con motore grafico di test Figura 7.2: differenza di renderizzazione delle trasparenze tra unity e il motore grafico utilizzato per lo studio delle trasparenze Sulla base delle considerazioni effettuate, anche in un motore grafico come Unity è necessario implementare un algoritmo di renderizzazione delle superfici trasparenti, utilizzando script o shader personalizzati e non presenti di base. Le modalità di implementazione saranno diverse rispetto al motore grafico di test, ma i concetti che danno vita alle funzioni e ai risultati dell algoritmo sono del tutto uguali a quelli descritti nei capitoli precedenti. Lo stesso paragone può essere effettuato anche sulla problematica che riguarda l errata sovrapposizione delle superfici tra modelli che interagiscono all interno della scena. Unity permette di modificare con estrema facilità il modello in modo da eliminare le sovrapposizioni variando le dimensioni delle mesh mentre il motore grafico di test non offre questo tipo di possibilità. La variazione delle dimensioni del modello non è però la soluzione migliore in questo caso, poiché, come è stato spiegato nel capitolo 5, esistono delle situazioni in cui la variazione delle dimensioni non è applicabile oppure non

95 7.2. Algoritmi di trasparenza e Unity 95 comporta l eliminazione totale dell errore. Ad esempio in situazioni in cui il modello possiede un animazione che permette al personaggio di muoversi all interno della scena, dimensionare nel modo migliore la maglietta è molto difficile poiché ogni movimento può variare la distanza delle superfici che entrano in conflitto. (a) Modello renderizzato con unity (b) Modello renderizzato con motore grafico di test Figura 7.3: differenza di renderizzazione tra le funzioni di base di unity e il motore grafico utilizzato per lo studio delle trasparenze Anche in questo caso è necessario implementare l algoritmo in Unity utilizzando script e shader personalizzati, che permettano la correzione delle superfici in real-time. Possiamo quindi dire in conclusione che Unity permette di velocizzare il lavoro di renderizzazione delle scene permettendo di raggiungere una buon qualità dell immagine, ma per ottenere immagini che riproducano effetti simili alla realtà, è necessario implementare anche in questo contesto tutti gli algoritmi descritti nei capitoli di questo elaborato utilizzando shader e script personalizzati che non sono offerti di base da Unity.