UNIVERSITÀ DEGLI STUDI DI PAVIA Facoltà di Ingegneria Dipartimento di Ingegneria Industriale e dell Informazione

Transcript

1 UNIVERSITÀ DEGLI STUDI DI PAVIA Facoltà di Ingegneria Dipartimento di Ingegneria Industriale e dell Informazione Corso di Laurea in Ingegneria Informatica TITOLO OpenGL Once-for-All : una soluzione alla ricodifica di Algoritmi di Grafica 3D Relazione discussa in sede di esame finale dal candidato: Stefano Di Palma Docente tutore: Prof. Alessandro Martinelli A.A. 2011/12

2

3 Indice Abstract Introduzione vii ix 1 OpenGL Introduzione Architettura di Rendering La pipeline di Rendering Primitive di Rendering Proprietà del punto Proprietà della linea Proprietà del triangolo Clipping e Viewport Transform Modulo di digitalizzazione Algoritmo Scan-Line Gestione della profondità Illuminazione Modelli di luce Materiali Modelli di Shading Blending Anti-Aliasing Fog Trasformazioni di coordinate Texturing Texture Object Gestione delle coordinate texture Gestione del colore Parametri dei Texture Object Buffer Manager Mesh indicizzate iii

4 Object Buffer Pipeline programmabili GLSL JOGL OpenGL ES WebGL Test Driven Development Introduzione La classe Util Test sv Test sv Test sv Test sv Test sv Test va Test sv Test sv Test sv Test sv Test va JCodeConverterLite Introduzione CodeModule CodeLine Block DeclaredBlock ICodePiece Word Value Keyword OptionalCode CompositeCodePiece CodeSequence AlternativeCode BestAlternativeCode Expression CodePattern CodePieceComparator iv

5 4.6 CodePatternComparator Fase di identificazione Fase di interpretazione Fase di confronto Risultati 77 Conclusioni 79 Bibliografia 81 v

6

7 Abstract OpenGL è un interfaccia software che fornisce API per algoritmi di grafica 3D. Esistono differenti implementazioni di OpenGL, una di queste è JOGL, per il linguaggio Java. Con la diffusione dei sistemi embedded, che possono non avere l hardware grafico, si sono dovute modificare le API OpenGL in modo da renderle compatibili con questi tipi di device, per questo motivo è stato introdotto OpenGL ES. Per portare la grafica 3D sul web si è introdotto WebGL, che è una replica della pipeline di OpenGL ES in Javascript. Ci si è posti quindi l obbiettivo di fornire un supporto allo sviluppo di algoritmi grafici 3D che debbano essere eseguiti su sistemi diversi. In particolare si è sviluppata una procedura che confronta un sorgente Java con uno Javascript ed individua gli eventuali disallineamenti nel codice. Esistono tre problemi di confronto, il primo relativo al diverso linguaggio di programmazione, il secondo relativo alle differenze tra JOGL e WebGL e il terzo relativo alle differenze tra le API OpenGL e OpenGL ES. Come soluzione, si è pensato di generare una serie di CodePattern (una linea di codice strutturata, dipendente dal linguaggio di programmazione) per ciascun sorgente e di confrontarli. vii

8

9 Introduzione OpenGL è un interfaccia software per il motore grafico, cioè definisce una serie di API di grafica 3D che, interagendo con la GPU, permettono di generare un immagine da visualizzare sullo schermo. Esiste una libreria OpenGL scritta in C/C++ per ogni sistema operativo, tuttavia si possono utilizzare dei binding OpenGL per usare le stesse API in altri linguaggi di programmazione. JOGL è il binding Java di OpenGL. OpenGL ES estende l uso delle API OpenGL ai sistemi embedded (smartphone, tablet, ecc... ) che talvolta non possiedono neanche l hardware grafico, di conseguenza sono state modificate o eliminate alcune API. WebGL permette di utilizzare API grafiche su un browser web tramite il linguaggio Javascript ed è basato sulle specifiche OpenGL ES. Per risolvere il problema di dover scrivere una algoritmo grafico diverso a seconda del sistema di destinazione, ci si è posti l obiettivo a lungo termine di creare un convertitore di codice tra un linguaggio di programmazione e un altro. L idea è quella di scrivere, in uno pseudo codice OpenGL, un algoritmo grafico e poi, grazie al convertitore, riuscire a produrre lo stesso algoritmo in tutte le diverse piattaforme. Per questa tesi, inizialmente si è pensato di creare un traduttore tra Java e Javascript, successivamente si è scelto di costruire una procedura che confrontasse i due file sorgenti, questo per tre motivi: È più semplice creare una procedura di confronto piuttosto che una di conversione, nella prima si deve solo dire se due linee di codice fanno la stessa cosa, mentre nell altra si deve creare del codice. Una volta creata la procedura di confronto è più facile creare un convertitore, perché si conosce già la differente struttura delle linee di codice nei due linguaggi. Aver creato una procedura di confronto prima del convertitore ne facilita lo sviluppo, in quanto si ha a disposizione un test che dice se si ha convertito bene oppure no. ix

10 Ho scelto di usare Java perché volevo utilizzare l ambiente di sviluppo Eclipse, in quanto offre numerose funzioni che aiutano il programmatore nella stesura del codice. Invece, ho usato Javascript perché non ho uno smartphone compatibile con OpenGL ES per poter effettuare i miei test. Nel confronto tra Java e Javascript sono da considerare tre aspetti: Alcune API OpenGL non ne hanno una corrispondente in OpenGL ES. In altri casi invece, c è una corrispondenza ma varia il numero dei parametri da passare alle API. Pur avendo la stessa API sia in OpenGL che in OpenGL ES, è differente il modo usato per chiamarle, per esempio possono cambiare lievemente i nomi dei metodi e le costanti. Il problema più ovvio riguarda la differenza dei linguaggi di programmazione, può cambiare la sintassi, i costrutti, i tipi di dato, ecc.... Prima di creare la procedura di confronto sono stati scritti dei test che implementassero determinati algoritmi grafici grazie alle istruzioni OpenGL. Ogni test è stato scritto sia in Java che in Javascript. Si è iniziato con un test che disegna delle semplici figure 2D con istruzioni di base OpenGL e si è arrivati all ultimo test che crea uno scenario 3D con oggetti in movimento, con istruzioni per il texturing, illuminazione, ecc.... I test sono poi stati utilizzati nello sviluppo della procedura di confronto, cioè si iniziava a scrivere le funzioni che confrontassero solo le istruzioni di un determinato test, quando il confronto andava a buon fine, si procedeva con il test successivo. Questo procedimento è noto come Test Driven Development. Si è passati poi alla scrittura del JCodeConverterLite, che realizza l operazione di confronto. Essa si può dividere in tre parti, una di identificazione, dove vengono riconosciuti i moduli principale di un sorgente, una di interpretazione, dove a ogni linea di codice viene associato un CodePattern, e una di confronto, dove vengono confrontati i CodePattern dei due sorgenti scritti in Java e Javascript rispettivamente. Si è scelto di creare dei CodePattern, così da avere un oggetto strutturato dal quale è possibile recuperare facilmente gli elementi di una linea di codice. Ogni CodePattern ha una struttura che dipende, sia dal tipo di linea di codice, sia dal linguaggio di programmazione. Il confronto avviene tra gli elementi in comune di due CodePattern dello stesso tipo. L esposizione degli argomenti è articolata come segue. Nel primo capitolo verrà descritta l architettura di base di comunicazione tra CPU e GPU, la pipeline di rendering OpenGL, il modello di pipeline programmabili, il linguaggio di programmazione degli shader GLSL e la libreria JOGL. x

11 Nel secondo capitolo verrà descritto OpenGL ES, verranno esposte le principali differenze con OpenGL e si introdurrà WebGL. Nel terzo capitolo verrà descritta la struttura dei test e per ognuno verranno specificate le istruzioni che cambiano da JOGL a WebGL. Nel quarto capitolo verrà descritta la struttura delle classi del JCodeConverterLite, compresi i CodePattern, e verranno descritte le tre fasi della procedura di confronto. Nel quinto capitolo verranno illustrati e commentati i risultati ottenuti. xi

12

13 Capitolo 1 OpenGL 1.1 Introduzione OpenGL (Open Graphics Library) è un interfaccia software per l hardware grafico. Questa interfaccia consiste in circa 250 distinti comandi (API: Application Programming Interface) che consentono di specificare gli oggetti e le operazioni necessarie per produrre applicazioni interattive tridimensionali. OpenGL è progettato come un interfaccia semplificata, indipendente dall hardware, così da essere implementato su molte piattaforme hardware diverse. Per raggiungere questo obiettivo, in OpenGL non è incluso nessun comando per eseguire le operazioni di gestione delle finestre o di interfacciamento con l utente. Invece, ci si deve servire del sistema di gestione delle finestre per la particolare macchina che si sta utilizzando. Analogamente, OpenGL non fornisce comandi di alto livello per descrivere modelli di oggetti tridimensionali. Tali comandi potrebbero consentire di specificare forme relativamente complesse, quali automobili, parti del corpo, aerei, o molecole. Con OpenGL, è necessario costruire il modello desiderato da un piccolo insieme di primitive geometriche punti, linee e poligoni. Una libreria sofisticata che offre queste caratteristiche potrebbe essere usata in appoggio a OpenGL. L OpenGL Utility Library (GLU) fornisce molte delle funzionalità di modellazione, quali superfici quadriche, curve e superfici. GLU è una componente standard di ogni implementazione OpenGL. 1.2 Architettura di Rendering L architettura di rendering è la struttura dei dispositivi coinvolti per produrre applicazioni grafiche. L elemento fondamentale di questa architettura è la GPU (Graphics Processing Unit) che ha l obbiettivo di dialogare con l applicazione che gira 1

14 1 OpenGL sulla CPU per generare l immagine finale da visualizzare sullo schermo. Il sistema CPU-GPU è di tipo Master-Slave, la GPU (Slave) riceve dalla CPU (Master) un serie di comandi che via via interpreta per modificare l immagine finale. Figura 1.1. Architettura di rendering CPU Applicazione API Buffer Driver Comado 1 Comado 2 Comado 3... Bus GPU CPU e GPU sono in grado di funzionare in modo asincrono. Quando l applicazione chiama una API OpenGL viene eseguito il driver del dispositivo grafico. Il driver assembla i comandi di rendering e li invia sul bus di comunicazione con la GPU. Per ottenere le massime prestazioni, si desidera che entrambi siano impegnati per più tempo possibile, quindi il driver salva continuamente blocchi di dati e comandi in un buffer, quando il buffer è pieno i comandi vengono inviati sul bus. La GPU riceve tali comandi e li esegue, nel frattempo il driver continua a riempire il buffer. Si possono verificare due tipi di stallo: 1. La GPU è ferma ad aspettare nuovi comandi 2. Il driver deve aspettare che la GPU termini il lavoro Il secondo caso è il più grave, perché la CPU, se non utilizzata per fare grafica, può servire per fare altre cose. 1.3 La pipeline di Rendering La pipeline di rendering è il modello di GPU che OpenGL adotta. La pipeline rappresenta la catena degli stadi da percorrere per avere l immagine finale, ogni stadio implementa un proprio algoritmo grafico. La struttura della pipeline è la seguente: 2

15 1.3 La pipeline di Rendering Figura 1.2. Vertici, colori, texture, normali Pipeline di rendering Input Manager Memoria GPU Generazione coordinate texture Buffer Manager Vertex pipeline Trasformazioni di coordinate Illuminazione Blending Fog Fragment pipeline Gestione delle primitive Texturing Frammenti Clipping e Viewport Transform Modulo di digitalizzazione Input Manager: dà la possibilità di definire degli oggetti grafici da salvare nella memoria della GPU, per poi utilizzarli successivamente. Accetta come input vertici, colori, texture, coordinate texture e vettori normali. Generazione coordinate texture: a ciascun vertice associa un pixel dell immagine texture applicata all oggetto che si vuole disegnare. Trasformazioni di coordinate: si occupa di applicare trasformazioni di coordinate ai vertici di un geometria e imposta anche il tipo di proiezione sull inquadratura dello scenario 3D. Esempi di trasformazioni sono la traslazione, la rotazione attorno ad un asse e il ridimensionamento. Illuminazione: vengono applicati gli algoritmi di illuminazione per simulare la presenza di luci nello scenario 3D. Gestione delle primitive: interpreta i vertici ricevuti in base alla primitiva grafica impostata. Le primitive grafiche sono punti, linee, triangoli, quadrilateri e poligoni. 3

16 1 OpenGL Clipping e Viewport Transform: le geometrie 3D vengono mappati su oggetti 2D. Modulo di digitalizzazione: gli algoritmi presenti in questo stato si occupano di trasformare l oggetto 2D in un insieme di frammenti che sono associati ai pixel dell immagine finale. Texturing: applica ai frammenti l immagine texture selezionata. Fog: applica l effetto nebbia. Blending: applica la trasparenza agli oggetti. Buffer Manager: gestisce il buffer della profondità, dei colori, delle maschere, delle texture, degli oggetti e il buffer che contiene l immagine finale. Alcuni stadi possono essere eseguiti in parallelo su set di dati differenti, così da aumentare le prestazioni. Attraverso le API possono essere impostate delle variabili di stato che operano su stadi differenti della pipeline. Variabili di stato sono per esempio le proprietà del vertice (colore, normale, coordinata texture,... ) e le proprietà di rendering, quest ultime non possono essere modificate durante il rendering di una geometria. Questo modello standard di pipeline è caratteristico di OpenGL 1, vedremo poi che nelle versioni successive di OpenGL è possibile personalizzare la vertex e la fragment pipeline, grazie al modello di pipeline programmabile. 1.4 Primitive di Rendering Una primitiva geometrica è un elemento grafico di cui nella pipeline di rendering esiste un algoritmo di digitalizzazione, in grado di trasformare la geometria in un insieme di pixel opportuni. Ogni primitiva è definita da un insieme di vertici e da specifiche proprietà di rendering. In OpenGL si inizia a creare una geometria con il comando glbegin(geometric_primitive) e si termina con glend(). Tra glbegin e glend si possono usare i comandi elencati nella tabella Il comando glbegin accetta come parametro il tipo di primitiva, i tipi possibili di primitive sono elencati nella tabella 1.2 e raffigurati nella figura Al posto dell aterisco va inserita una combinazione dei seguenti caratteri {234}{sifd}[v] 4

17 1.4 Primitive di Rendering Tabella 1.1. Comando glvertex*() glcolor*() glnormal*() gltexcoord*() Comandi per primitive OpenGL Descrizione imposta un vertice imposta un colore imposta una normale imposta una coordinata texture Primitiva GL_POINTS GL_LINES GL_LINE_STRIP GL_LINE_LOOP GL_TRIANGLES GL_TRIANGLE_STRIP GL_TRIANGLE_FAN GL_QUADS GL_QUAD_STRIP GL_POLYGON Tabella 1.2. Descrizione Primitive OpenGL disegna un punto per ogni vertice disegna una linea ogni due vertici disegna una linea tra un vertice e il precedente come GL_LINE_STRIP, tranne che si traccia anche la linea che chiude il percorso tra il primo e l ultimo vertice disegna un triangolo ogni tre vertici disegna un triangolo tra un vertice e i due precedenti disegna un triangolo tra un vertice, il primo e il precedente disegna un quadrilatero(due triangoli) ogni quattro vertici disegna un quadrilatero tra due vertici e i due precedenti disegna un poligono suddiviso in triangoli Proprietà del punto Per impostare la dimensione del punto si usa glpointsize(glfloat size) che accetta come parametro la dimensione desiderata in pixel. La quantità di pixel che è effettivamente disegnata sullo schermo dipende dall attivazione dell Antialiasing. Se l antialiasing non è attivo, le dimensioni frazionali sono arrotondate a dimensioni intere e viene disegnata una regione quadrata di pixel. Così, se la dimensione è 2, il quadrato sarà 2 pixel per 2 pixel. Con l antialiasing abilitato, viene disegnato un gruppo circolare di pixel, con i pixel ai bordi disegnati con un intensità minore per dare al bordo un aspetto più arrotondato. 5

18 1 OpenGL Figura 1.3. Primitive OpenGL V 0 V 1 V 2 V 3 V4 GL_POINTS V 2 V 0 V 1 V4 V 3 V 1 V V 3 V 0 7 V 5 V 3 V 4 V 2 V 6 V 5 GL_LINES V 1 V 2 V 4 V 2 GL_LINE_STRIP V 0 V 1 GL_LINE_LOOP V 4 V 1 V 2 V 0 V 2 V 0 V 4 V V 3 1 V 3 V 5 V 5 V 0 V 3 V 4 GL_TRIANGLES GL_TRIANGLE_STRIP GL_TRIANGLE_FAN V 1 V 2 V 5 V 6 V 1 V 3 V 5 V 7 V 0 V 1 V 2 V 0 V 3 V 4 V 7 V 0 V 5 V 2 V 4 V 6 V 4 GL_QUADS GL_QUAD_STRIP GL_POLYGON V Proprietà della linea Per impostare lo spessore della linea si usa gllinewidth(glfloat width) che accetta come parametro lo spessore desiderato in pixel. Come per il punto, se è attivato l antialiasing i pixel ai bordi sono disegnati con un intensità minore per dare al bordo un aspetto più arrotondato Proprietà del triangolo Per il triangolo è possibile attivare l antialiasing come per il punto e la linea. Modalità di rendering Un triangolo ha due facce, frontale e retrostante, e possono essere disegnate in modo differente a seconda del lato visibile. Di default le facce sono disegnate nello stesso modo, ma è possibile cambiare questa impostazione con il comando glpolygonmode(glenum face, GLenum mode). Il parametro face può essere GL_FRONT_AND_BACK (entrambe le facce), GL_FRONT (faccia frontale) o GL_BACK (faccia retrostante). Il parametro mode può essere GL_POINT (disegna solo i vertici), GL_LINE (disegna i bordi) o GL_FILL (disegna anche i pixel interni al triangolo). 6

19 1.4 Primitive di Rendering La Winding-Rule La Winding-Rule (regola di avvolgimento) determina quale faccia di un triangolo è quella frontale. I vertici di un triangolo possono essere ordinati in senso orario (Clock-Wise) o in senso antiorario (Counter-Clock-Wise), vedi figura 1.4. V1 Figura 1.4. La Winding-Rule V1 V3 V3 A V2 B V2 In OpenGL si può specificare la winding-rule con il comando glfrontface( GLenum mode). Il parametro mode può assumere il valore GL_CCW (winding-rule antioraria) o GL_CW (winding-rule oraria). Face Culling In una superficie chiusa, nessuna delle facce retrostanti è mai visibile, sono sempre nascoste dalle facce frontali, vedi figura 1.5. Se sei al di fuori della superficie, puoi abilitare il face culling per non disegnare le facce retrostanti. Allo stesso modo, se sei dentro l oggetto, solo le facce retrostanti sono visibili. Per dire a OpenGL quali facce non devono essere disegnate si usa il comando glcullface(glenum mode), dove mode può essere GL_FRONT (per eliminare le facce frontali) o GL_BACK (per eliminare le facce retrostanti). Prima di usare il comando glcullface è necessario abilitare il face culling con il comando glenable(gl_cull_face). Per disabilitarlo si usa gldisable(gl_cull_face). Interpolazione del colore Il comando glshademode(gl_flat) disattiva l interpolazione del colore, cioè ad ogni triangolo viene associato l ultimo colore impostato. Il comando glshademode(gl_smooth) attiva l interpolazione del colore, cioè il colore di ogni pixel della parte interna di un triangolo è interpolato linearmente in funzione dei diversi colori associati ai vertici, vedi figura

20 1 OpenGL Figura 1.5. Face Culling Facce visibili Facce non visibili Figura 1.6. Interpolazione del colore FLAT SMOOTH 1.5 Clipping e Viewport Transform Per rappresentare una scena 3D è necessario definire un volume entro il quale le geometrie possono essere collocate. In OpenGL è definito Volume Unitario il cubo di dimensioni [ 1,1] [ 1,1] [ 1,1], tutto quello che non è dentro il cubo non viene visualizzato. È possibile che un oggetto sia in parte dentro e in parte fuori, qui interviene il Clipping che definisce nuovi triangoli in modo da tagliare la geometria e cancellare la parte al di fuori del volume unitario. Successivamente il motore di rendering proietta le primitive 3D sulla facciata frontale del cubo ottenendo così delle primitive 2D, a quest ultime rimane associata una proprietà z di profondità. Infine si applica la Viewport Transform (Trasformazione di Viewport) che converte le coordinate del volume unitario nelle coordinate dell immagine finale. Per definire la Viewport si usa il comando glviewport(glint x, GLint y, GLsizei width, GLsizei height) che usa la seguente formula per convertire le coordinate. { xim = x vp + (1+x)width 2 y im = y vp + (1 y)height 2 8

21 1.6 Modulo di digitalizzazione Figura 1.7. Clipping e Viewport Transform (-1,1) (1,1) (0,0) (-1,1) (1,-1) Clipping Proiezione Viewport Transform 1.6 Modulo di digitalizzazione (width,height) Questo modulo riceve in ingresso le primitive 2D in uscita dal modulo di Clipping e Viewport Transform ed ha lo scopo di trasformarle in frammenti. Ogni frammento corrisponde a un pixel dell immagine finale ed ha la seguente struttura: (x, y): coordinate del pixel nell immagine finale c: colore z: profondità Ciascun frammento viene poi elaborato da altri algoritmi (per esempio quello della profondità) per produrre poi l immagine finale che viene memorizzata nel Color Buffer Algoritmo Scan-Line Questo algoritmo risolve il problema di digitalizzazione di un triangolo. I dati in ingresso sono le coordinate dei tre vertici (in figura 1.8: A,B,C), il loro colore e la loro profondità z. L algoritmo svolge i seguenti passaggi: Vengono determinati il valore massimo e minimo della coordinata y Per ogni valore della y vengono calcolate le coordinate x dei degli estremi della scanline (D,E) Vengono calcolati colore e profondità di tali estremi facendo l interpolazione lineare con i valori ai vertici adiacenti (AC e CB) 9

22 1 OpenGL Per ogni valore x della scanline viene generato un frammento, assegnandoli colore e profondità per interpolazione lineare con gli estremi della scanline (D,E) L algoritmo produce un insieme di frammenti. C Figura 1.8. Algoritmo Scan-Line C scanline D E A A frammento B B Primitiva 2D Frammenti Gestione della profondità Può succedere che due frammenti provenienti da due triangoli diversi abbiano le stesse coordinate, semplicemente perché parte di un triangolo si sovrappone all altro. Bisogna quindi scegliere quale colore applicare al pixel dell immagine finale. Ci sono essenzialmente due metodi: l algoritmo del pittore, l algoritmo dello Z-Buffer. Algoritmo del pittore Si ordinano tutti i triangoli dal più lontano al più vicino e si digitalizzano in quest ordine. Se un nuovo frammento ha le stesse coordinate di un altro viene mantenuto solo il colore di quello nuovo. Problemi: difficoltà di ordinamento, non si riescono a gestire le intersezioni tra triangoli. Algoritmo dello Z-Buffer Lo Z-Buffer è una matrice con le stesse dimensioni dell immagine finale, solo che a ciascun pixel è associato un valore diverso a seconda della profondità del frammento associato. Inizialmente lo Z-Buffer è inizializzato con un valore che significa lontanissimo. Per ogni frammento si confronta il suo valore z di profondità con quello salvato nello Z-Buffer. Se è superiore il frammento viene scartato. Se il valore di z è inferiore allora il colore del frammento viene salvato nel Color Buffer e il valore della profondità viene salvato nello Z-Buffer. 10

23 1.7 Illuminazione In OpenGL si usa il comando glenable(gl_depth_test) per abilitare lo Z- Buffer. Se viene disabilitato con gldisable(gl_depth_test) è utilizzato l algoritmo del pittore (ma senza ordinamento). 1.7 Illuminazione Per rendere più realistiche delle scene 3D, occorre introdurre il concetto di illuminazione. OpenGL fornisce API per selezionare il modello di shading, creare delle sorgenti di luce e definire dei materiali. Per abilitare e disabilitare l illuminazione si usa il comando glenable/gldisable(gl_lighting), per abilitare e disabilitare una luce (è possibile usare fino a otto luci) si usa il comando glenable/gldisable(gl_lighti) con i=0,...,7. Per impostare i parametri di una luce si usa il comando gllight*(light, param_name, param) (al posto dell asterisco può esserci i:intero, f:float, v:vector). I nomi dei parametri sono indicati nella tabella 1.3. Tabella 1.3. Nome del Parametro GL_AMBIENT GL_DIFFUSE GL_SPECULAR GL_POSITION GL_SPOT_DIRECTION GL_SPOT_EXPONENT GL_SPOT_CUTOFF GL_CONSTANT_ATTENUATION GL_LINEAR_ATTENUATION GL_QUADRATIC_ATTENUATION Nomi dei parametri di una luce Descrizione intensità ambientale intensità diffusa intensità speculare Imposta la direzione della luce. Se la quarta componente del vettore è 0 imposta una luce direzionale, se è 1 imposta una luce puntiforme direzione principale di una luce spot termine di decadimento rispetto alla direzione principale di una luce spot estensione angolare del cono di luce decadimento costante dell intensità di luce decadimento lineare dell intensità di luce decadimento quadratico dell intensità di luce Modelli di luce I modelli di luce che vengono considerati forniscono un vettore unitario L, che indica la direzione che porta alla luce, e un vettore RGB I, che ne indica l intensità. Esistono quattro modelli di luce in OpenGL: 11

24 1 OpenGL Luce direzionale La luce direzionale è una sorgente di luce posta a distanza infinita ed ha direzione ed intensità uguali in qualunque punto dello spazio. Luce Puntiforme La luce puntiforme è una sorgente di luce posta in un punto P dello spazio e trasmette la luce in tutte le direzione. I vettori L e V dipendono dal punto V, dal quale si osserva la luce, in particolare: L = P V d I = I P ad 2 + bd + c d = P V I P : intensità in P a: decadimento quadratico b: decadimento lineare c: decadimento costante Luce Spot La luce spot è una luce puntiforme che trasmette luce lungo una direzione principale D (cono di luce). L intensità I tiene conto anche di quanto L è inclinato rispetto a D (vedi figura 1.9): Figura 1.9. Luce spot D cutoff P α L 0 se α > cutoff k = (cos α) ex se α cutoff I = ki P ad 2 + bd + c Luce Ambientale La luce ambientale simula l effetto di illuminazione globale, cioè la luce diffusa dovuta agli infiniti rimbalzi dei raggi di luce sugli oggetti di uno scenario. È caratterizzata dal solo valore di intensità. Per definire la luce ambientale si usa il comando gllightmodelfv(gl_light_model_ambient, ambient). 12

25 1.7 Illuminazione Intensità Luminosa L intensità I è in realtà divisa in tre componenti: Intensità Ambientale I A : effetto aggiuntivo sulla luce ambientale. Intensità Diffusa I D : effetto sulla riflessione diffusa della luce. Intensità Speculare I S : effetto sulla riflessione speculare della luce Materiali I materiali indicano in che modo un oggetto reagisce alle varie componenti di una luce, quindi un materiale è definito dai seguenti colori: C A : risposta alla luce ambientale. C D : termine di riflessione diffusa. C S : termine di riflessione speculare. C E : colore emesso dal materiale (in assenza di illuminazione). Il comando OpenGL per impostare i parametri di un materiale è glmaterial* (face, param_name, param). Il parametro face può essere GL_FRONT_AND_BACK, GL_FRONT, GL_BACK. I nomi dei parametri sono riportati nella tabella 1.4. In questa sezione il simbolo sta per moltiplicazione componente per componente. Tabella 1.4. Nome del Parametro GL_AMBIENT GL_DIFFUSE GL_AMBIENT_AND_DIFFUSE GL_SPECULAR GL_SHININESS GL_EMISSION Nomi dei parametri di un materiale Descrizione colore ambientale colore diffuso colore ambientale e diffuso dello stesso colore colore speculare lucentezza colore emesso dal materiale Colore luce ambientale Il colore dovuto alla luce ambientale è: C amb = C A I A 13

26 1 OpenGL Modello di Lambert Il modello di Lambert tiene conto dell intensità diffusa della luce I L, che dipende dall inclinazione della superficie dell oggetto rispetto alla direzione L della luce. Occorre quindi definire il vettore normale alla superficie N. Il colore di diffusione sarà quindi dato da: C diff = C D I D max(n L,0) Riflessione speculare Il modello di riflessione speculare, oltre alla normale N, utilizza: H: il vettore medio (half-vector) tra L e V, dove V è il vettore che indica la direzione del punto di vista. sh: il coefficiente di lucentezza. Il colore speculare risulta: C spec = C S I S (max(n H,0)) sh H = L + V L + V Modello Blinn-Phong Il modello Blinn-Phong è un modello completo di illuminazione, che calcola il colore di un punto di una superficie utilizzando la componente diffusa del modello di Lambert e la componente speculare (Phong) calcolata con l half-vector (Blinn). Date n sorgenti di luce, il colore finale è dato da: C = C E + C A I A + n i=1 C amb i + C diff i + C spec i Figura Modello Blinn-Phong Ambientale + Diffusa + Speculare = Blinn-Phong 14

27 1.8 Blending Modelli di Shading Il modello di shading dice dove e come deve fatto il calcolo dell iluminazione. I modelli di shading principali sono: Flat Shading: ad ogni triangolo viene associato un unico vettore normale, quindi l illuminazione è calcolata una sola volta per ogni triangolo. La superficie appare seghettata, il risultato non è per niente realistico. Gouraud Shading: ad ogni vertice è associato un vettore normale, l illuminazione è calcolata su ogni vertice e il colore risultante viene poi interpolato lungo il triangolo. Ne risulta un illuminazione che migliora con l aumentare dei vertici usati per rappresentare la superficie. Il Gouraud Shading è l elemento principale della pipeline OpenGL. Phong Shading: ad ogni vertice è associato un vettore normale, il vettore normale viene interpolato lungo il triangolo e l illuminazione è calcolata su ogni frammento. Ne risulta un illuminazione molto realistica, ha lo svantaggio di essere un modello molto costoso in quanto i frammenti sono molti di più dei vertici. Il Phong Shading non è supportato nella pipeline OpenGL 1, ma è possibile implementarlo grazie all introduzione della pipeline programmabile. Figura Modelli di Shading Flat Gouraud Phong 1.8 Blending Il blending è un operazione che si usa per ottenere un effetto di trasparenza su un oggetto. Si basa su una determinata funzione di blending che viene applica sull immagine finale prima che un frammento venga scritto su di essa. In pratica dice come il colore del frammento si debba mescolare con il colore dell immagine. Una tipica funzione di blending è: 15

28 1 OpenGL C nuovo immagine = αc frammento + (1 α)c vecchio immagine α: canale alpha del frammento (1.1) In OpenGL si usa il comando glenable/gldisable(gl_blend) per abilitare o disabilitare il blending. Per impostare la funzione di blending 1.1 si usa il comando glblendfunc(gl_src_alpha, GL_ONE_MINUS_SRC_ALPHA) Anti-Aliasing L aliasing è l effetto dentellato che possono avere i contorni di alcune immagini, a causa di un difetto negli algoritmi di digitalizzazione. È possibile diminuire tale effetto attivando la funzionalità di anti-aliasing che associa ad alcuni frammenti un effetto di trasparenza per definire meglio i contorni di un immagine. Affinché si possa applicare la trasparenza, deve essere attivo il blending. In OpenGL il comando per attivare o disattivare l anti-aliasing è glenable/ gldisable(gl_polygon_smooth). 1.9 Fog Si può rendere uno scenario più realistico aggiungendo un effetto nebbia, che fa scomparire gli elementi in lontananza. Di solito è usata per simulare una foschia o del fumo ed è spesso usata per simulare l effetto della visibilità nei simulatori di volo. L effetto nebbia è ottenuto mescolando il colore di un frammento con il colore della nebbia, in base alla profondità z. C nuovo frammento = k z C vecchio frammento + (1 k z )C nebbia k Z : dipende dalla profondità z 1.10 Trasformazioni di coordinate Per poter collocare oggetti in uno scenario 3D occorre un sistema di coordinate e un metodo per applicare le trasformazioni di base come la traslazione, il cambio di scala (scaling) e la rotazione. In OpenGL è utilizzato il sistema di riferimento cartesiano con l asse x diretto verso destra, l asse y verso l alto e l asse z uscente dallo schermo(vedi figura 1.12). Ogni trasformazione lineare nel sistema di riferimento cartesiano può essere descritta dalla seguente equazione: 16

29 1.10 Trasformazioni di coordinate Figura Sistema di coordinate y x z x a b c x l y = d e f y + m z g h i z n Occorrono quindi una matrice e un vettore. Per avere un unica matrice, si introducono le coordinate omogenee, a ciascun vettore [ x y z ] T è associato il vettore [ x y z 1 ] T in coordinate omogenee. Si ottiene quindi l equazione: x a b c l x y z = d e f m y g h i n z In realtà viene anche utilizzata la quarta componente, ad ogni vettore in coordinate omogenee [ x y z w ] T è associato il vettore: x x w y = y w z z w w è quindi usato come fattore di scala. Vediamo quindi come si possono applicare le seguenti trasformazioni: Traslazione: t x t y t z

30 1 OpenGL Scaling: s x s y s z Rotazione intorno all asse z: cos α sin α 0 0 sin α cos α Rotazione intorno all asse x: cos α sin α 0 0 sin α cos α Rotazione intorno all asse y: cos α 0 sin α sin α 0 cos α Rotazione intorno all asse determinata dal versore [ x y z ] T : x 2 + (1 x 2 ) cos α (1 cos α)xy z sin α (1 cos α)xz + y sin α 0 (1 cos α)yx + z sin α y 2 + (1 y 2 ) cos α (1 cos α)yz x sin α 0 (1 cos α)zx y sin α (1 cos α)zy + x sin α z 2 + (1 z 2 ) cos α Se si vogliono applicare più trasformazioni, semplicemente si moltiplicano le rispettive matrici, stando attenti all ordine perché il prodotto di matrici non è commutativo. In realtà la pipeline OpenGL utilizza due matrici per le trasformazioni di coordinate: La matrice di proiezione P (Projection): modellizza una telecamera nella scena 3D. Definisce il punto di vita, in particolare specifica come la scena è proiettata sull immagine finale sullo schermo. 18

31 1.10 Trasformazioni di coordinate La matrice di trasformazione M (Modelview): descrive le trasformazioni di coordinate sugli oggetti del mondo 3D. Le coordinate finali del vertice sono calcolare applicando prima le trasformazioni sugli oggetti e poi la proiezione: Esempi di matrice di proiezione sono: v = P Mv Proiezione ortogonale: La proiezione avviene lungo rette parallele. La proiezione di default lungo l asse z è associata alla matrice identità. Applicando rotazioni e traslazioni si può cambiare la direzione di proiezione. Proiezione prospettica: Applica l effetto di proiezione che si avrebbe con una normale macchina fotografica, gli oggetti lontani vengono rimpiccioliti mentre quelli vicini ingranditi (vedi figura 1.13). 1 aspect tan angle tan angle z far +z near z far z near 2z far z near z far z near Figura Proiezione prospettica angle w h aspect=w/h z near zfar La matrice modelview agisce su tutti gli oggetti della scena, ma per esempio noi vorremmo poter applicare delle trasformazioni ad un determinato gruppo di oggetti e successivamente applicare un ulteriore trasformazione su un solo elemento del gruppo. Per risolvere questo problema si è introdotto il Grafo della Scena (SceneGraph), che è un albero i cui nodi sono delle trasformazioni e le foglie sono oggetti 3D. Di solito la radice è la matrice di proiezione. Ai vertici di ogni oggetto devono essere applicate tutte le trasformazioni che collegano la foglia alla radice. OpenGL fornisce due stack di matrici, uno per la projection e uno per la modelview. È quindi possibile applicare lo SceneGraph salvando di volta in volta le 19

32 1 OpenGL matrici nello stack prima di applicare determinate trasformazioni. Nella tabella 1.5 sono elencati tutti i comandi per le trasformazioni di coordinate e per la gestione dello stack delle matrici. Comando Tabella 1.5. glmatrixmode(mode) glloadidentity() glscale(s x,s y,s z ) gltranslatef(t x,t y,t z ) glrotatef(α,x,y,z) gluperspective(angle,aspect,z near,z far ) glpushmatrix() glpopmatrix() Comandi per le trasformazioni di coordinate Descrizione indica su quale stack si vuole lavorare. mode può essere GL_PROJECTION oppure GL_MODELVIEW carica la matrice identità applica uno scaling applica una traslazione applica una rotazione attorno all asse [ x y z ] T applica la proiezione prospettica salva una copia della matrice attuale e la aggiunge allo stack preleva l ultima matrice dello stack e la imposta come matrice attuale 1.11 Texturing Il texturing è l assegnazione del colore ad un oggetto 3D tramite un immagine chiamata texture. In pratica si assegnano delle coordinate texture a ciascun vertice, le coordinate sono poi interpolate dagli algoritmi di digitalizzazione e vengono usate per determinare il colore del frammento. Le coordinate texture sono una coppia di valori (t x, t y ) compresi tra 0 e 1 alle quali corrisponde il pixel dell immagine in posizione (t x imagew idth, t y imageheight) 2. 2 Si ricorda che in un immagine il pixel di coordinate (0, 0) è quello in alto a sinistra 20

33 1.11 Texturing Texture Object Un texture object è una parte della memoria grafica allocata per contenere una texture e tutti i suoi parametri. In OpenGL si usa il comando glgentextures(n, textureids) per generare n texture object e salvare i relativi identificativi nell array textureids. Per assegnare temporaneamente un texture object alla pipeline di rendering si usa in comando glbindtexture(gl_texture_2d, textureid). Per salvare nel texture object un immagine texture si usa il comando glteximage2d(...) che vuole come parametri i pixel, la dimensione e il formato dell immagine Gestione delle coordinate texture Per assegnare le coordinate texture ai vertici di una geometria esistono due metodi: Assegnazione manuale: le coordinate vengono assegnate manualmente o attraverso programmi di modellazione memorizzandole su un file. Assegnazione automatica: le coordinate sono calcolate attraverso delle formule in funzione delle coordinate (x, y, z) di un vertice. Alcune tecniche di calcolo automatico sono: Coordinate Planari: ricavate dalla proiezione su di un piano. Coordinate Sferiche: ricavate dalla proiezione su di una sfera. Coordinate Cilindriche: ricavate dalla proiezione su di un cilindro. È possibile applicare anche delle trasformazioni alle coordinate texture, a questo scopo OpenGL mette a disposizione un ulteriore matrice di trasformazione: glmatrixmode(gl_texture) Gestione del colore Nella fragment pipeline ci si ritrova con un frammento che ha il colore calcolato dagli algoritmi di illuminazione C I, ma grazie alle coordinate texture si preleva il colore della texture C t. Come ottengo il colore finale del frammento? Esistono tre metodi: Modulazione (Modulate): C = C I C t Aggiungi (Add): C = C I + C t Rimpiazza (Replace): C = C t 21

34 1 OpenGL Figura Gestione del colore No Texture Modulate Add Replace Parametri dei Texture Object Il comando OpenGL per impostare i parametri di un texture object è gltexparameter*(gl_texture_2d, param_name, param) i possibili parametri sono elencati nella tabella 1.6 Tabella 1.6. Nomi dei parametri di un Texture Object Nome del Parametro Descrizione Valori GL_TEXTURE_WRAP_S imposta il texture wrap GL_REPEAT per la coordinata t x GL_MIRRORED_REPEAT GL_CLAMP_TO_EDGE GL_CLAMP_TO_BORDER GL_TEXTURE_WRAP_T imposta il texture wrap GL_REPEAT per la coordinata t y GL_MIRRORED_REPEAT GL_CLAMP_TO_EDGE GL_CLAMP_TO_BORDER GL_TEXTURE_MAG_FILTER imposta il filtro di magni- GL_NEAREST ficazione GL_LINEAR GL_TEXTURE_MIN_FILTER imposta il filtro di mini- GL_NEAREST ficazione GL_LINEAR GL_LINEAR_MIPMAP_LINEAR Texture Wrap I texture wrap forniscono diversi metodi di interpretazioni per le coordinate texture che non sono comprese tra 0 e 1. I tipi di texture wrap sono: Repeat: viene presa in considerazione solo la parte decimale delle colordinate. Si ha così un ripetersi della stessa texture. 22

35 1.11 Texturing Mirrored Repeat: se la parte intera della coordinata è dispari funziona come la repeat, altrimenti la coordinata viene cambiata in 1 meno la parte decimale. Si ha così un ripetersi a specchio della texture. Clamp to Edge: viene usato il colore del punto più vicino della texture. Vengono proiettati i lati dell immagine. Clamp to Border: viene usato un colore di default. Figura Texture Wrap Repeat Mirrored Repeat Clamp to Edge Clamp to Border Filtri Anti-Aliasing Il texturing introduce due ulteriori problemi di aliasing: Magnificazione: questo effetto compare quando un texel 3 è mappato da più pixel. L immagine finale appare pixelata. Minificazione: questo problema compare quando più texel sono mappati dallo stesso pixel. Per risolvere la magnificazione si usa il filtro Bi-Lineare (o lineare), il colore del texel è calcolato facendo la somma pesata dei colori di un gruppo di quattro pixel contigui. I pesi sono ricavati in funzione della parte decimale delle coordinate immagine associate alle coordinate texture del texel. Figura Filtro lineare Nearest Linear Il Mip-Mapping è la soluzione al problema della minificazione, genera delle versioni ridotte dell immagine di una texture, quando una texture deve essere letta, viene fornita l immagine più adatta al contesto. 3 Il texel è il pixel dell immagine di una texture 23

36 1 OpenGL Figura Mip-Mapping Nearest Mip-Map 1.12 Buffer Manager Il modulo di gestione dei Buffer consente di interagire con la memoria della scheda grafica per salvare dati utili durante la fase di rendering. I buffer sono: Color Buffer: contiene l immagine finale da visualizzare sullo schermo. Depth Buffer: contiene i valori z usati dall algoritmo Z-Buffer. Stencil Buffer: è usato per la creazione di maschere. Accumulation Buffer: contiene il risultato delle operazioni di copiatura, caricamento, somma e moltiplicazione tra il Color Buffer e l Accumulation Buffer. Frame Buffer: è usato per copiare momentaneamente il Color Buffer o il Depth Buffer per poi utilizzarli come texture nel processo di rendering. Display List: rappresenta una lista di istruzioni grafiche, le istruzioni sono comunicate una sola volta alla GPU per poi utilizzarle più volte durante il processo di rendering. In questo modo il bus di comunicazione tra CPU e GPU risulta alleggerito. Object Buffer: consente di memorizzare diversi oggetti nella memoria grafica Mesh indicizzate Abbiamo visto che per disegnare un oggetto bisogna fornire una serie di vertici, ma molti di questi vertici sono ripetuti perché di solito si disegnano superfici chiuse. Si può sfruttare questo fatto per diminuire l occupazione di memoria grafica introducendo le Mesh indicizzate. In pratica si elencano tutti i vertici distinti di un oggetto e poi, alle funzioni di disegno, si passano gli indici dei vertici. Si risparmia memoria perché un indice (intero: 2 byte) occupa meno spazio di un vertice (tre coordinate float: 12 byte). 24

37 1.12 Buffer Manager Wavefront obj file I file Wavefront obj sono file di testo per la memorizzazione di mesh indicizzate. In ogni riga è possibile specificare uno dei comandi elencati in tabella 1.7. Comando Tabella 1.7. Comandi Wavefront obj file Descrizione v x y z definisce un vertice vn x y z definisce una normale vt t x t y definisce una coordinata texture f i v 1/i vt 1 /i vn 1 i v 2/i vt 2 /i vn 2 i v 3/i vt 3 /i vn 3 definisce una faccia composta da tre vertici (triangolo) Object Buffer Gli Object Buffer consentono di memorizzare sulla memoria grafica vettori di vertici, normali, coordinate texture ed indici. In questo modo bisogna comunicare soltanto una volta le geometrie alla GPU, alleggerendo così il bus di comunicazione tra CPU e GPU. Il funzionamento degli Object Buffer è simile ai Texture Object, si usa il comando glgenbuffers(n, bufferids) per generare n Object Buffer e salvare i relativi identificativi nell array bufferids. Per assegnare temporaneamente un Object Buffer alla pipeline di rendering si usa in comando glbindbuffer(target, bufferid). target specifica il tipo di buffer, per vettori, normali e coordinate texture si usa GL_ARRAY_BUFFER, per gli indici si usa GL_ELEMENT_ARRAY_BUFFER. Per salvare dei dati nell Object Buffer si usa il comando glbufferdata(target, size, data, usage), data è il vettore dei dati, size è la dimensione in byte dei dati, usage specifica lo scopo del buffer, se lo scopo è disegnare si usa GL_STATIC_DRAW. Per disegnare dei vertici si usa il comando gldrawarrays(mode, first, count), mode può assumere uno dei valori della tabella 1.2, first specifica l indice del primo elemento, count specifica il numero di elementi che devono essere disegnati. Per disegnare delle Mesh indicizzate si usa il comando gldrawelements(mode, count, type, indices), mode può assumere uno dei valori della tabella 1.2, count specifica il numero di elementi che devono essere disegnati, type specifica il tipo di indici, indices specifica il buffer degli indici. 25

38 1 OpenGL 1.13 Pipeline programmabili Da OpenGL 2.0, oltre alla normale pipeline, si è introdotto il modello di pipeline programmabile, che prevede due nuove unità, il Vertex Shader e il Fragment Shader, essi vanno a sostituire la Vertex Pipeline e la Fragment Pipeline rispettivamente. Gli shader sono moduli programmabili, è quindi possibile personalizzare il modo con cui i vertici e i frammenti sono elaborati durante il processo di rendering. Per rendere il calcolo più veloce, nelle GPU che supportano questo modello, esistono più unità in grado di applicare in parallelo gli shader. Il Vertex Shader sostituisce i moduli di gestione delle coordinate texture, trasformazioni di coordinate, illuminazione. Accetta in input un vertice, una normale e coordinate texture, l output principale è la posizione finale del vertice, può anche passare dei parametri al Fragment Shader. Il Fragment Shader sostituisce i moduli di texturing, fog e blending. Accetta come input un frammento generato dal modulo di digitalizzazione, l output principale è il colore del frammento, ma può anche modificare la profondità z e le coordinate del pixel associato GLSL GLSL (Graphics Library Shading Language) è il linguaggio di shading di OpenGL. Come tutti i linguaggi di shading, è vettoriale, cioè le operazioni di somma, prodotto e sottrazione sono operazioni componente per componente su vettori della stessa lunghezza. Oltre alle variabili temporanee dichiarate dal programmatore, GLSL fornisce quattro tipi speciali di variabili: Variabili di linguaggio predefinite: sono variabili predefinite del linguaggio di shading che contengono informazioni di input o variabili di stato della pipeline di rendering. Alcuni esempi di queste variabili sono elencati in tabella 1.8. Variabili attribute: sono variabili di ingresso al Vertex Shader. Variabili uniform: sono variabili visibili in sola lettura sia dal Vertex che dal Fragment Shader. Variabili varying: sono variabili definite nel Vertex Shader, interpolate dai moduli di digitalizzaione e possono essere lette dal Fragment Shader. Per usare gli shader in OpenGL bisogna compilare sia il vertex che il fragment shader separatamente e poi linkarli in un unico Shader Program. La procedura di compilazione di uno shader è la seguente: 26

39 1.14 JOGL Tabella 1.8. Variabili di linguaggio predefinite Variabile Descrizione gl_vertex posizione del vertice in input al Vertex Shader gl_position posizione del vertice in output al Vertex Shader gl_color colore in input al Fragment Shader gl_fragcolor colore in output al Fragment Shader Si crea l identificativo dello shader con glcreateshader(type), type può essere GL_VERTEX_SHADER o GL_FRAGMENT_SHADER. Si definisce il codice sorgente dello shader con glshadersource(type, count, string, length). Si compila lo shader con glcompileshader(shader). La procedura per linkare gli shader allo shader program è la seguente: Si crea l identificativo dello shader program con glcreateprogram(). Si associano gli shader allo shader program con glattachshader(program, shader). Si linkano gli shader con gllinkprogram(program). Si imposta lo shader program come parte del processo di rendering con gluseprogram(program). In OpenGL, per impostare il valore di una variabile attribute bisogna prima recuperare il suo identificativo con glgetattriblocation(program, name), abilitarlo come variabile array con glenablevertexattribarray(attrubuteid) e poi usare glvertexattri bpointer(...) per inizializzarlo. Per impostare il valore di una variabile uniform bisogna prima recuperare il suo identificativo con glgetuniformlocation(program, name) e poi usare gluniform*(...) per inizializzarla JOGL JOGL (Java OpenGL) è un Java Binding per le API OpenGL, cioè una libreria che permette di creare applicazioni di grafica 3D in Java. La libreria sfrutta la tecnologia delle JNI (Java Native Interface) per permettere l accesso alle API OpenGL disponibili per il linguaggio C/C++. 27

40 1 OpenGL L oggetto principale della libreria è il GL (in JOGL 2 si usa GL2), nel quale sono contenute tutte le costanti e i metodi OpenGL. JOGL fornisce degli oggetti che si integrano con le librerie grafiche di Java (AWT e Swing), per disegnare con le API OpenGL. Uno di questi è GLCanvas che implementa l interfaccia GLAutoDrawable e estende il componente Canvas della libreria AWT. L oggetto GLCanvas fornisce l accesso al GL e un meccanismo di eventi per eseguire il rendering OpenGL, in pratica contiene un oggetto GLEventListener che definisce dei metodi da chiamare in risposta agli eventi di un GLAutoDrawable. L interfaccia GLEventListener è un componente fondamentale, perché ci permette di inserire nei sui metodi le istruzioni OpenGL. I metodi di questa interfaccia sono: init: è chiamato subito dopo che il contesto OpenGL è inizializzato. Può essere usato per impostare i parametri iniziali di OpenGL come le luci, i buffer e le texture. dispose: è chiamato subito dopo che il contesto OpenGL è terminato da un evento esterno, come la chiusura della finestra. Può essere usato per rilasciare tutte le risorse usate da OpenGL come i buffer e programmi GLSL. display: è chiamato per iniziare il rendering OpenGL, In questo metodo vanno inserite tutte le istruzioni di disegno. reshape: è chiamato durante il primo disegno dopo il ridimensionamento del componente GLCanvas. Questo metodo può essere usato per reimpostare la viewport. Se nella vostra scena volete inserire delle animazioni, non basta il semplice metodo GLEventListener, ma dovete usare l oggetto Animator. Un Animator può essere associato a uno o più GLAutoDrawable per eseguire ripetutamente il metodo display. La classe Animator crea un thread in background che chiama con una certa frequenza il metodo display, tra una chiamata e l altra esegue una piccola pausa per evitare di sovraccaricare la CPU. Un Animator ha quindi il metodo start per lanciare il thread e stop per terminarlo. Il codice 1.1 presenta un esempio JOGL che disegna un quadrato bianco su sfondo nero. 28

41 1.14 JOGL Codice 1.1. import javax.media.opengl.gl; import javax.media.opengl.gl2; import javax.media.opengl.glautodrawable; import javax.media.opengl.gleventlistener; import javax.media.opengl.awt.glcanvas; import javax.swing.jframe; Hello World in JOGL import com.sun.opengl.util.animator; public class HelloWorld implements GLEventListener { public static void main(string[] args) { JFrame frame=new JFrame("Hello World"); frame.setsize(500,500); frame.setdefaultcloseoperation(jframe.exit_on_close); GLCanvas canvas=new GLCanvas(); canvas.addgleventlistener(new HelloWorld()); frame.getcontentpane().add(canvas); Animator animator=new Animator(canvas); animator.start(); } public void display(glautodrawable drawable) { GL2 gl = drawable.getgl().getgl2(); gl.glclear(gl.gl_color_buffer_bit); gl.glrectf(-0.5f, -0.5f, 0.5f, 0.5f); public void dispose(glautodrawable drawable) { public void init(glautodrawable drawable) { public void reshape(glautodrawable drawable, int x, int y, int w, int h) { } } 29

42

43 Capitolo 2 OpenGL ES OpenGL ES (OpenGL Embedded System) è un sottoinsieme di OpenGL ed è stato progettato per l uso su dispositivi embedded come cellulari, PDA (personal digital assistant), console e veicoli, che hanno una più bassa potenza di calcolo e minori capacità rispetto a un desktop computer. OpenGL ES è stato progettato in base ai seguenti criteri: Rimuovere la ridondanza: OpenGL ha un enorme quantità di API e di solito fornisce diverse alternative per produrre gli stessi risultati, per esempio, per disegnare dei vertici si può, sia usare glbegin e glend, sia usare gli Object Buffer. OpenGL ES usa solo gli Object Buffer, perchè sono più performanti. Mantenere un interfaccia comune: è importante avere un sottoinsieme di API in comune tra OpenGL e OpenGL ES, in modo da permettere agli sviluppatori di produrre applicazioni, sia per dispositivi embedded, sia per desktop computer, usando le stesse API. Introdurre nuove caratteristiche: bisogna introdurre nuove funzioni per risolvere le specifiche restrizioni dei sistemi embedded. Per esempio, ridurre il consumo di energia ed aumentare le prestazioni degli shader. Migliore qualità d immagine: gli sviluppatori di OpenGL ES si sono posti l obbiettivo di assicurare un insieme minimo di funzionalità per la qualità dell immagine. La maggior parte dei dispositivi embedded ha uno schermo di grandezza limitata, diventa quindi essenziale che la qualità dei pixel disegnati sia migliore possibile. Garantire le prestazioni: gli ideatori di OpenGL ES hanno voluto garantire che ogni implementazione di OpenGL ES soddisfasse determinati standard per la qualità dell immagine, la correttezza, e la robustezza. Questo viene fatto 31

44 2 OpenGL ES sviluppando uno specifico test di conformità che un applicazione OpenGL ES deve superare per essere accettata. Ci sono tre diverse versioni di OpenGL ES che sono state rilasciate da Khronos: 1.0, 1.1 e 2.0. OpenGL ES 1.0 e 1.1 implementano una pipeline derivata da OpenGL 1.3 e 1.5, rispettivamente. OpenGL ES 2.0 implementa unicamente il modello di pipeline programmabile derivata da OpenGL WebGL WebGL è uno standard web Javascript basato su OpenGL ES 2.0, quindi usa il modello di pipeline programmabile per portare la grafica 3D sul web. Il rendering di WebGL avviene attraverso l elemento canvas di HTML5 e non richiede l installazione di nessun plugin per il browser. Si può recuperare l oggetto gl, che contiene tutte le costanti e i metodi OpenGL ES, con il metodo getcontext("experimental-webgl") dell elemento canvas inserito nella pagina HTML. Attualmente è supportato solo il contesto sperimentale di WebGL, in futuro sarà disponibile il contesto standard getcontext("webgl"). I browser che attualmente supportano WebGL sono: Firefox 4+ Safari 5+ Chrome 10+ Opera Infatti Mozilla, Apple, Google e Opera fanno parte del gruppo di sviluppo Khronos di WebGL. La Microsoft, che sviluppa le DirectX, non fa parte del gruppo di lavoro ed attualmente WebGL non è supportato in Internet Explorer. Per inserire delle animazioni bisogna usare una funzione che richiama ripetutamente la funzione che disegna la scena. A questo scopo si usa la funzione requestanimframe della libreria webgl-utils.js fornita da Google. In realtà esistono delle funzioni specifiche per ogni browser (per esempio, Firefox ha una funzione chiamata mozrequestanimationframe). In futuro si spera che il nome della funzione si standardizzi, ma per ora dobbiamo usa le WebGL utils di Google che vanno bene per qualunque browser. In realtà si potrebbe ottenere lo stesso effetto con la funzione Javascript setinterval, ma essa richiama la funzione di disegno a prescindere dal fatto che la 32

45 2.1 WebGL scheda del browser dove sto disegnando sia visibile oppure no. Questo non è ovviamente un buon comportamento, per questo si usa requestanimframe che smette di chiamare la funzione di disegno quando la scena WebGL non è visibile. Il codice 2.1 presenta un esempio WebGL che disegna un quadrato bianco su sfondo nero. Codice 2.1. Hello World in WebGL <html> <head> <title>hello World</title> <script type="text/javascript" src="webgl-utils.js"></script> <script id="shader-fs" type="x-shader/x-fragment"> void main(void) { gl_fragcolor = vec4(1.0, 1.0, 1.0, 1.0); } </script> <script id="shader-vs" type="x-shader/x-vertex"> attribute vec3 avertexposition; uniform mat4 umvmatrix; uniform mat4 upmatrix; void main(void) { gl_position = upmatrix * umvmatrix * vec4(avertexposition, 1.0); } </script> <script type="text/javascript"> var gl; var shaderprogram; var mvmatrix; var pmatrix; var squarevertexpositionbuffer; function initgl(canvas) { try { gl = canvas.getcontext("experimental-webgl"); gl.viewportwidth = canvas.width; gl.viewportheight = canvas.height; } catch (e) { alert("could not initialise WebGL, sorry :-("); } } function getshader(gl, id) { var shaderscript = document.getelementbyid(id); if (!shaderscript) { return null; } var str = ""; var k = shaderscript.firstchild; while (k) { if (k.nodetype == 3) { str += k.textcontent; } k = k.nextsibling; } 33

46 2 OpenGL ES var shader; if (shaderscript.type == "x-shader/x-fragment") { shader = gl.createshader(gl.fragment_shader); } else if (shaderscript.type == "x-shader/x-vertex") { shader = gl.createshader(gl.vertex_shader); } else { return null; } gl.shadersource(shader, str); gl.compileshader(shader); if (!gl.getshaderparameter(shader, gl.compile_status)) { alert(gl.getshaderinfolog(shader)); return null; } } return shader; function initshaders() { var fragmentshader = getshader(gl, "shader-fs"); var vertexshader = getshader(gl, "shader-vs"); shaderprogram = gl.createprogram(); gl.attachshader(shaderprogram, vertexshader); gl.attachshader(shaderprogram, fragmentshader); gl.linkprogram(shaderprogram); if (!gl.getprogramparameter(shaderprogram, gl.link_status)) { alert("could not initialise shaders"); } gl.useprogram(shaderprogram); shaderprogram.vertexpositionattribute = gl.getattriblocation(shaderprogram, "avertexposition"); gl.enablevertexattribarray(shaderprogram.vertexpositionattribute); } shaderprogram.pmatrixuniform = gl.getuniformlocation(shaderprogram, "upmatrix"); shaderprogram.mvmatrixuniform = gl.getuniformlocation(shaderprogram, "umvmatrix"); function initbuffers() { squarevertexpositionbuffer = gl.createbuffer(); gl.bindbuffer(gl.array_buffer, squarevertexpositionbuffer); var vertices = [ 0.5, 0.5, 0.0, -0.5, 0.5, 0.0, 0.5, -0.5, 0.0, -0.5, -0.5, 0.0 ]; gl.bufferdata(gl.array_buffer, new Float32Array(vertices), gl.static_draw); squarevertexpositionbuffer.itemsize = 3; squarevertexpositionbuffer.numitems = 4; } function drawscene() { requestanimframe(drawscene); gl.clearcolor(0.0, 0.0, 0.0, 1.0); 34

47 2.1 WebGL gl.viewport(0, 0, gl.viewportwidth, gl.viewportheight); gl.clear(gl.color_buffer_bit); gl.bindbuffer(gl.array_buffer, squarevertexpositionbuffer); gl.vertexattribpointer(shaderprogram.vertexpositionattribute, squarevertexpositionbuffer.itemsize, gl.float, false, 0, 0); pmatrix = new Float32Array([ 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 ]); mvmatrix = new Float32Array([ 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 ]); gl.uniformmatrix4fv(shaderprogram.pmatrixuniform, false, pmatrix); gl.uniformmatrix4fv(shaderprogram.mvmatrixuniform, false, mvmatrix); } gl.drawarrays(gl.triangle_strip, 0, squarevertexpositionbuffer.numitems); function webglstart() { var canvas = document.getelementbyid("mycanvas"); initgl(canvas); initshaders(); initbuffers(); drawscene(); } </script> </head> <body onload="webglstart();"> <canvas id="mycanvas" style="border: none;" width="500" height="500"></canvas> </body> </html> noview 35

48

49 Capitolo 3 Test Driven Development 3.1 Introduzione Il Test Driven Development (TDD) è una tecnica di sviluppo del software, dove si creano i test prima di sviluppare il codice sorgente di un programma. Il TDD si divide in 5 fasi: Scrittura del test Verifica di fallimento del test Sviluppo del codice necessario per superare il test Verifica di superamento del test Refactoring del codice Il TDD aiuta i programmatori nel processo di pianificazione perché consente di riflettere sulle funzionalità che deve avere un programma ancora prima di implementarlo. Inoltre dà la possibilità agli sviluppatori di testare il codice più frequentemente in modo da trovare i problemi in anticipo, rendendo più semplice la risoluzione degli errori. Abbiamo visto che OpenGL e OpenGL ES hanno funzionalità in comune e più o meno si riescono a fare le stesse cose, però è necessario modificare il codice. L obiettivo di questa tesi è quello di scrivere una procedura che confronti due file sorgenti, uno scritto in Java e l altro scritto in Javascript, ed individui gli eventuali errori di traduzione del codice. Si è dovuto quindi scrivere dei test, sia in Java che in Javascript, che testassero le funzioni OpenGL e OpenGL ES più comuni. Come descritto dal TDD, si scriverà del codice che porti al successo della procedura di confronto per un dato test e successivamente si passerà a considerare il test successivo. 37

50 3 Test Driven Development Come già visto, per Java si utilizzano le istruzioni di JOGL che sono le implementazioni delle API OpenGL. Invece per Javascript si utilizzano le istruzioni WebGL che sono le implementazioni delle API OpenGL ES. Di seguito verranno descritti i test che sono stati prodotti, descrivendo per ognuno le funzionalità che si sono volute testare ed evidenziandone le differenze delle istruzioni OpenGL. 3.2 La classe Util Figura 3.1. UML della classe Util.java Nonostante l obiettivo finale sia quello di tradurre codice Java in Javascript e viceversa, ci sono funzionalità che vanno gestite in modo completamente diverso nei due linguaggi. Per questo motivo si è pensato di fornire una classe Util che dia a disposizione una serie di metodi di utilità per i test. Esistono quindi una classe Util.java e una util.js, entrambe hanno gli stessi metodi che svolgono gli stessi compiti ma sono scritti appositamente per lo specifico linguaggio. I metodi di utilità sono: loadfile(src): legge il file src e ritorna il suo contenuto come stringa. getshader(gl, src, type): compila il file shader src a seconda del tipo di shader (FRAGMENT_SHADER o VERTEX_SHADER) e ritorna il suo identificativo. colle- getshaderprogram(gl, fragmentshaderfile, vertexshaderfile): ga i due shader allo shader program e ritorna il suo identificativo. loadobj(src): carica il Wavefront obj file src e restituisce un oggetto ObjModel. multiplymatrix(a,b): ritorna la matrice risultante dal prodotto della matrice a con la matrice b. 38

51 3.3 Test sv1 multiplymatrixvector(a,b): ritorna il vettore risultante dal prodotto della matrice a con il vettore b. mat4toinversemat3(a): ritorna la matrice inversa della parte 3 3 della matrice a. mat3traspose(a): ritorna la matrice trasposta della matrice a. ObjModel è una classe interna a Util ed ha come attributi le posizioni, le normali, le coordinate texture dei vertici e gli indici delle facce. 3.3 Test sv1 Figura 3.2. Schermata del Test sv1 Figura 3.3. UML java del Test sv1 In questo test vengono disegnati un quadrato rosa e un triangolo colorato con interpolazione del colore tra i vertici di colore rosso, blu e verde (vedi figura 3.2). 39

52 3 Test Driven Development Il diagramma UML in figura 3.3 mostra che si è scelto di dividere il test in due classi, Test_sv1 e Test_sv1Drawer. Questo perché alcune funzioni, come il settaggio della finestra di disegno, sono completamente differenti nei due linguaggi, quindi queste funzioni non devono essere prese in considerazione nella procedura di confronto finale. La procedura di confronto prenderà in considerazione solo la classe Test_sv1Drawer scritta sia in Java che in Javascript. Questa struttura è usata per tutti i test effettuati. La classe Test_sv1 inizializza la finestra di disegno e crea un oggetto drawer, riferito alla classe Test_sv1Drawer. Nel metodo display viene richiamato il metodo drawscene del drawer. Nel metodo init vengono richiamati i metodi initshaders e initbuffers del drawer. Nella classe Test_sv1Drawer sono presenti i seguenti metodi: initshaders: crea lo shader program e inizializza gli attribute vertexposition e vertexcolor e gli uniform pmatrix (matrice di proiezione) e mvmatrix (matrice dell modello di vista). setmatrixuniforms: si occupa di associare alle variabili uniform delle matrici i rispettivi buffer dove sono salvate tali matrici. initbuffers: vengono inizializzati i buffer dei vertici e dei colori, sia del triangolo che del quadrato. drawscene: si occupa di disegnare la scena, imposta il colore di sfondo, abilita il depth test, imposta la viewport, setta i buffer per le matrici di proiezione e trasformazione. Gli attributi buffer della classe sono dichiarati come array di interi di dimensione 3. Questo perché occorre memorizzare l identificativo del buffer, la dimensione di un elemento e il numero di elementi presenti nel buffer. Per esempio le posizioni dei vertici del triangolo sono elementi di dimensione 3 e il numero di vertici nel triangolo è 3. In questo test vengono utilizzati dei file di shader molto semplici: shader1.vs (vertex shader): si occupa solo di applicare le trasformazioni di coordinate della matrice di proiezione e del modello di vista al singolo vertice e passa al fragment shader come variabile varying il colore del vertice. shader1.fs (fragment shader): viene settato solo il colore del frammento. Di seguito verranno descritte le principali differenze tra le istruzioni JOGL (prima riga) e WebGL (seconda riga) di questo test: gl.gluniformmatrix4fv(pmatrixuniform, 16, false, pmatrix) gl.uniformmatrix4fv(pmatrixuniform, false, pmatrix) 40

53 3.4 Test sv2 In WebGL si può omettere il parametro count (in questo caso 16) che rappresenta il numero di elementi della matrice. gl.glgenbuffers(1, trianglevertexpositionbuffer, 0) trianglevertexpositionbuffer[0] = gl.createbuffer() In WebGL esiste uno specifico comando per creare un buffer. gl.glbufferdata(gl2.gl_array_buffer, vertices.length * BufferUtil.SIZEOF_FLOAT, BufferUtil.newFloatBuffer(vertices), GL2.GL_STATIC_DRAW) gl.bufferdata(gl.array_buffer, new Float32Array(vertices), gl.static_draw) In JOGL è necessario specificare anche il parametro size che indica la dimensione del buffer in byte. 3.4 Test sv2 Figura 3.4. Schermata del Test sv2 Il test disegna una piramide colorata che ruota contemporaneamente attorno all asse x e y (vedi figura 3.4). Come si vede nel diagramma UML in figura 3.5, per animare la scena si è creato un metodo animate. Questo metodo viene chiamato alla fine del metodo drawscene e si occupa di aggiornare delle variabili che sono usate dalla matrice mvmatrix per applicare agli oggetti delle trasformazioni di coordinate. In questo modo a ogni iterazione della fase di disegno viene disegnata un immagine differente, creando così un animazione. La variabile usata per l animazione di questo test è rangle e rappresenta l angolo di rotazione attorno agli assi x e y. Le diverse implementazioni di OpenGL possono avere un frame rate differente, quindi per avere una velocità di animazione uniforme si è utilizzata la variabile lasttime, che memorizza l istante di tempo dell ultima chiamata alla funzione 41

54 3 Test Driven Development Figura 3.5. UML java del Test sv2 animate. Quando vado a cambiare il valore di rangle calcolo il tempo passato facendo la differenza tra il tempo corrente e lasttime, quindi incremento la variabile di un valore ottenuto con il prodotto tra la velocità di animazione (in questo caso velocità angolare) e il tempo passato. In questo modo l animazione avrà la velocità desiderata in tutte le diverse piattaforme. In questo test si sono aggiunte anche le istruzioni di face culling e winding rule. 3.5 Test sv3 Figura 3.6. Schermata del Test sv3 La novità di questo test è il texturing, viene disegnato un cubo con applicata una texture (vedi figura 3.6). Dal diagramma UML in figura 3.7 si vede che è stato aggiunto il metodo inittexture. Questo metodo si occupa di caricare un immagine e salvarla nel buffer come texture. 42

55 3.6 Test sv4 Figura 3.7. UML java del Test sv3 Per disegnare il cubo, a differenza dei test precedenti, vengono utilizzate le mesh indicizzate. Questo test utilizza dei file shader in grado di gestire texture: shader2.vs (vertex shader): passa al fragment shader come variabile varying le coordinate texture del vertice. shader2.fs (fragment shader): il colore del frammento è dato dalla funzione texture2d che estrae il colore della texture specificata dalla variabile uniform usampler in base alle coordinate date. Le principali differenze tra le istruzioni JOGL (prima riga) e WebGL (seconda riga) di questo test sono: gl.glgentextures(1, texture1, 0) texture1[0] = gl.createtexture() Per creare una texture in WebGL esiste una specifica istruzione. gl.glteximage2d(gl2.gl_texture_2d, 0, GL2.GL_RGB, tex.getwidth(), tex.getheight(), 0, GL2.GL_RGB, GL2.GL_UNSIGNED_BYTE, tex.getbuffer()) gl.teximage2d(gl.texture_2d, 0, gl.rgb, gl.rgb, gl.unsigned_byte, tex) In WebGL si possono omettere i parametri width e height che rappresentano la dimensione dell immagine e non è presente il parametro border che rappresenta la dimensione del bordo. 43

56 3 Test Driven Development Figura 3.8. Schermata del Test sv4 Nearest filtering Linear filtering Mipmaps Figura 3.9. UML java del Test sv4 3.6 Test sv4 In questo test viene disegnato un cubo che è possibile ruotare a proprio piacimento con i tasti direzionali della tastiera. È inoltre possibile zoommare con i tasti A e Z e cambiare il filtro texture con il tasto F (vedi figura 3.8). In questo test si sono aggiunti i comandi da tastiera, a tal scopo, come si vede dal diagramma UML in figura 3.9, sono stati aggiunti i seguenti metodi: handlekeys: all interno della classe è definito un array di booleani commands, ogni elemento dice se un certo tasto è premuto oppure no. In questo metodo si controllano tutti gli elementi dell array e per ogni elemento risultato positivo si esegue la relativa azione. Le azioni sono di incremento/decremento dello zoom e della velocità di rotazione attorno all asse x e y. Tali operazioni sono gestite in modo analogo a quanto fatto precedentemente con il metodo animate. 44

57 3.7 Test sv5 setcommands: associa ad ogni codice tasto un elemento di commands e ne imposta il valore passato come parametro. keypressed: chiama la funzione setcommands passandogli come parametro true e il codice tasto premuto. keyreleased: chiama la funzione setcommands passandogli come parametro false e il codice tasto rilasciato. I metodi keypressed e keyreleased della classe Test_sv4 richiamano i rispettivi metodi del drawer. Per poter cambiare il filtro texture in real time sono creati tre texture object contenuti nell array textures. Alla pressione dell opportuno tasto viene cambiato l indice della texture utilizzata attraverso la variabile filter. 3.7 Test sv5 Figura Schermata del Test sv5 Repeat Mirrored Repeat Clamp to Edge Rispetto al precedente test si possono provare differenti texture wrap (vedi figura 3.10) e il filtro texture è impostato su Mipmaps. 3.8 Test va1 Come si vede in figura 3.11, in questo test si è realizzato uno scenario più complesso che usasse tutte le funzionalità usate nei test precedenti. 3.9 Test sv6 Questo test disegna un cubo in una scena con illuminazione ambientale e una luce direzionale (vedi figura 3.12), per questo è necessario definire tre nuove variabili 45

58 3 Test Driven Development Figura Schermata del Test va1 Figura Schermata del Test sv6 uniform da passare agli shader: il colore della luce ambientale, il colore e la direzione della luce direzionale. È necessario fornire anche un altra variabile uniform, la matrice di trasformazione delle normali. Non si può usare la matrice model-view perché applicare una traslazione può portare a una rotazione delle normali. Per esempio, se applichiamo una traslazione di (0, 0, -5) a una normale (0, 0, 1) il risultato verrà (0, 0, -4) che punta in una direzione differente. Anche i ridimensionamenti possono portare a errori. Per ottenere una corretta matrice delle normali bisogna fare la trasposta dell inversa della parte 3 3 della matrice model-view (la matrice delle normali è una 3 3, la model-view è una 4 4). Vediamo come sono cambiati gli shader per gestire questa semplice illuminazione: shader3.vs (vertex shader): passa al fragment shader come variabile varying l intensità dell illuminazione del vertice calcolata come il massimo tra 0 e il prodotto scalare tra la normale trasformata e la direzione della luce (modello di Lambert). La normale trasformata è calcolata moltiplicando la matrice di trasformazione delle normali per la normale del vertice. 46

59 3.10 Test sv7 shader3.fs (fragment shader): il colore del frammento è dato dal prodotto tra il colore della texture e l intensità dell illuminazione in quel frammento. Di seguito verranno descritte le principali differenze tra le istruzioni JOGL (prima riga) e WebGL (seconda riga) di questo test: gl.gluniformmatrix3fv(nmatrixuniform, 9, false, normalmatrix) gl.uniformmatrix3fv(nmatrixuniform, false, normalmatrix) gl.gluniform3fv(lightingdirectionuniform, lightingdirectionv.length, lightingdirection) gl.uniform3fv(lightingdirectionuniform, lightingdirection) In WebGL si può omettere il parametro count (nel primo caso 9) che rappresenta il numero di elementi della matrice Test sv7 Figura Schermata del Test sv7 per-vertex lighting per-fragment lighting In questo test viene applicata una luce puntiforme davanti a una sfera. È possibile scegliere tra due tipi di illuminazione premendo il tasto S, illuminazione per-fragment e per-vertex (vedi figura 3.13). Nel per-vertex l algoritmo di illuminazione viene applicato nel vertex shader, di conseguenza si ha una qualità dell illuminazione che dipende dal numero di vertici usati per creare la sfera. Nel per-fragment invece l algoritmo è applicato nel fragment shader, avendo così una qualità dell illuminazione decisamente migliore. Per poter scegliere il tipo di illuminazione si è creata una variabile uniform booleana, se è vera viene usato il per-fragment altrimenti il per-vertex. Le ulteriori 47

60 3 Test Driven Development uniform sono per il colore della luce ambientale, il colore e la posizione della luce puntiforme. I file shader utilizzati sono i seguenti: shader4.vs (vertex shader): per-vertex: viene calcolata la direzione della luce normalizzando la differenza tra la sua posizione e la posizione del vertice. Viene poi calcolata l intensità della luce in modo analogo al precedente test. per-fragment: passa al fragment shader come variabile varying la normale trasformata del vertice e la sua posizione. shader4.fs (fragment shader): per-vertex: il colore del frammento è dato dal prodotto tra il colore della sfera e l intensità dell illuminazione in quel frammento. per-fragment: viene calcolata la direzione della luce normalizzando la differenza tra la sua posizione e la posizione del frammento. Poi viene calcolata l intensità della luce come nel precedente test e infine il colore del frammento è dato dal prodotto tra il colore della sfera e l intensità calcolata Test sv8 Figura Schermata del Test sv8 Questo test disegna una teiera con il modello d illuminazione di Phong (vedi figura 3.14). Quindi sono state definite delle variabili uniform per il colore d ambiente, i colori di diffusione e speculare della luce, la sua posizione e l intensità di riflessione del materiale. I file shader utilizzati sono i seguenti: 48

61 3.12 Test sv9 shader5.vs passa al fragment shader come variabile varying la normale trasformata del vertice e la sua posizione. shader5.fs (fragment shader): calcola la direzione della luce, la direzione della vista, la direzione della riflessione e la normale normalizzata. Applica il modello di Lambert per calcolare l intensita della luce di diffusione e applica il modello Phong per calcolare l intensità della luce di riflessione. Poi viene calcolata l intensità della luce come somma delle varie componenti e infine il colore del frammento è dato dal prodotto tra il colore dell oggetto e l intensità calcolata. Il modello 3D della teiera è caricato da un file Wavefront obj Test sv9 Figura Schermata del Test sv9 Come di vede in figura 3.15, questo test disegna una bolla di sapone trasparente utilizzando il blending. È inoltre possibile ruotare la bolla trascinando il mouse. Dal diagramma UML in figura 3.16 si vede che è stata dichiarata la variabile rotationmatrix, la matrice che memorizzerà l attuale rotazione della bolla. Prima di disegnare la bolla si moltiplicherà questa matrice per la matrice model-view in modo che la bolla venga ruotata. Inoltre sono stati aggiunti dei metodi per gestire gli input dal mouse: mousepressed: salva le coordinate x e y del mouse nelle variabili lastmousex e lastmousey. mousedragged: viene calcolata la differenza tra le nuove coordinate del mouse e quelle precedenti, in base a questa vengono calcolati gli angoli di rotazione rispetto agli assi x e y, viene calcolata la matrice di rotazione associata e infine 49

62 3 Test Driven Development Figura UML java del Test sv9 quest ultima viene moltiplicata per la matrice rotationmatrix. Il risultato diventa la nuova rotationmatrix. Per gestire il blending è stata creata la variabile uniform alphauniform che rappresenta l indice di trasparenza (compreso tra 0 e 1). I file di shader utilizzati sono simili ai precedenti, sono state aggiunte la gestione delle texture e nel colore del frammento finale si tiene conto della alphauniform Test va2 In questo test viene ripreso lo scenario del Test va1, vengono aggiunti i modelli 3D del trattore e del gabbiano caricati da file Wavefront obj ed è usato il modello di illuminazione Phong (vedi figura 3.17). Il trattore transita davanti alla casa e il gabbiano vola attorno al tetto. È possibile muoversi nello scenario con i tasi A, W, D, S e cambiare l inquadratura con i tasti direzionali. 50

63 3.13 Test va2 Figura Schermata del Test va2 51

64

65 Capitolo 4 JCodeConverterLite 4.1 Introduzione Il JCodeConverterLite ha l obbiettivo finale di tradurre codice sorgente tra linguaggi di programmazione diversi (C++, Java, Javascript, ecc... ), comprese le API OpenGL o OpenGL ES implementate per quel linguaggio (JOGL, WebGL, ecc... ). Perché scrivere da zero un convertitore di codice? Non ne esiste già uno? Si, esiste il GWT (Google Web Toolkit), che consente di scrivere codice Javascript usando un insieme di apposite librerie Java. Non consente una vera e propria traduzione, peraltro il codice Javascript in uscita è illeggibile. Inoltre questi strumenti non fornisco supporto per la stesura di codice WebGL a partire da codice JOGL, anche perché non è sempre una diretta conversione di codice. Quindi si è preferito scrivere una libreria da zero che raggiungesse gli obiettivi prefissati. Per questa tesi si è scelto di creare una procedura del JCodeConverterLite che confronti due file sorgenti, uno scritto in Java incluse istruzioni JOGL e l altro scritto in Javascript incluse istruzioni WebGL. Successivamente con un adeguato refactoring si intende modificare questa procedura per consentire anche la conversione. La procedura di confronto può essere divisa in tre fasi: Identificazione vengono riconosciuti i moduli principali di un sorgente: classi, metodi, costrutti e linee di codice. Interpretazione: i moduli vengono interpretati e viene generato un codepattern per ogni linea di codice. Confronto: si confrontano i codepattern dei due file sorgenti. 53

66 4 JCodeConverterLite 4.2 CodeModule CodeModule è un interfaccia che rappresenta un modulo del codice sorgente. Esempi di moduli sono: una classe, gli attributi, i metodi, i costrutti e le linee di codice. Un modulo può anche contenere altri moduli, per esempio, una classe può avere dei metodi e i metodi possono avere delle linee di codice. Le classi che implementano questa intefaccia sono: Block, CodeLine e Declared- Block. Figura 4.1. UML dei CodeModule Dal diagramma UML in figura 4.1 si vede che è stato usato il Design Pattern Composite, CodeModule rappresenta l elemento astratto, Block rappresenta un nodo, Codeline e DeclaredBlock le foglie. L interfaccia CodeModule ha i seguenti metodi: getsize: ritorna il numero di moduli che contiene. getsubmodule(index): ritorna il modulo specificato dall indice. print: stampa in una stringa il modulo e tutti i moduli che contiene in modo dettagliato. tostring: ritorna una stringa che descrive il modulo in maniera meno dettagliata CodeLine Rappresenta una linea di codice. Possiede l attributo stringa codeline che contiene il testo della linea di codice e l attributo booleano che indica se è la dichiarazione di un Block. 54

67 4.3 ICodePiece for (int i = 0; i < 4; i++) { int c = i << 2; colors2[c] = 1; colors2[c + 1] = 0.75f; colors2[c + 2] = 0.8f; colors2[c + 3] = 1; } Figura 4.2. Esempi di CodeModule for (int i = 0; i < 4; i++) { int c = i << 2; colors2[c] = 1; colors2[c + 1] = 0.75f; colors2[c + 2] = 0.8f; colors2[c + 3] = 1; } for (int i = 0; i < 4; i++){ int c = i << 2; colors2[c] = 1; colors2[c + 1] = 0.75f; colors2[c + 2] = 0.8f; colors2[c + 3] = 1; } Block Codeline Codeline con isblockdeclaration=true DeclaredBlock blockdeclaration relatedblock Block Un Block rappresenta un insieme di CodeModule e può far parte di un Block padre. In Java e Javascript un Block è delimitato dalle parentesi graffe. In Block è presente il metodo correctblock che controlla tutti i CodeModule appartenenti al blocco e corregge due problemi: Il ciclo for: viene interpretato erroneamente come tre Codeline (per via del punto e virgola), quindi vengono sostituite da una unica CodeLine che contiene tutti e tre i pezzi. I DeclaredBlock: nella fase di identificazione vengono riconosciuti solo Block e CodeLine, quindi in questo metodo vengono uniti i Block con la relativa CodeLine di dichiarazione in un DeclaredBlock DeclaredBlock Rappresenta un Block con dichiarazione. Ha l attributo blockdeclaration che memorizza la CodeLine di dichiarazione del Block associato, rappresentato dall attributo relatedblock. 4.3 ICodePiece ICodePiece è una classe astratta e rappresenta un pezzo di codice che può essere rappresentato come una stringa, esempio il nome di una variabile, un tipo di dato, un numero, una parentesi, ecc.... Può a sua volta contenere altri ICodePiece, esempio la dichiarazione di una variabile contiene il tipo di dato e il nome della variabile. Ad esso è associato un PieceType, una enumerazione che contiene tutti i possibili tipi di ICodePiece. La classe ha i seguenti metodi: 55

68 4 JCodeConverterLite Figura 4.3. UML degli ICodePiece getpieces: ritorna la lista degli ICodePiece che contiene. add: aggiunge nuovi elementi alla lista. getpiecebytype: ritorna il primo elemento della lista che è del tipo specificato. getpiecetype: ritorna il tipo di ICodePiece. setpiecetype: imposta il tipo di ICodePiece. elementmatch (astratto): verifica se l ICodePiece è presente nella stringa data a partire dalla posizione matchposition, entrambe date come parametri. L idea è quella di usare gli ICodePiece durante il processo di interpretazione, data una linea di codice si verifica che corrisponda a un determinato ICodePiece. Il metodo ritorna l oggetto ICodePieceMatch che contiene la posizione del prossimo carattere da verificare (matchposition) e l ICodePiece che è stato trovato (datapiece). Se non c è corrispondenza viene posto matchposition a -1. writesonspieces: crea una stringa composta da tutte le stringhe ottenute chiamando il metodo tostring di tutta la lista di ICodePiece. 56

69 4.3 ICodePiece tostring: richiama la funzione writesonspieces. printtypes: costruisce una stringa che visualizza tutta la struttura dell ICodePiece, compresi i PieceType. Le classi che estendono ICodePiece sono: Word, Value, Keyword, Optional- Code, CompositeCodePiece, CodeSequence, AlternativeCode, BestAlternativeCode, Expression Word La classe Word rappresenta una generica parola che può rappresentare differenti ICodePiece, è usato per impostare il datapiece di un ICodePieceMatch. Ha come attributi la stringa word e un wordbuilder, che rappresenta l ICode- Piece che ha creato la corrispondente Word. Contiene i seguenti metodi: getword: ritorna la stringa word. setword: imposta la stringa word. elementmatch: ritorna il risultato dell omonimo metodo del wordbuilder. tostring (Override): ritorna la stringa word Value La classe astratta Value rappresenta una stringa che può contenere un numero limitato di caratteri. All interno è definita la classe CharInterval, un intervallo di caratteri, che ha come attributi il carattere iniziale e finale dell intervallo. La classe Value ha i seguenti metodi: getavailableintervals (astratto): ritorna la lista dei CharInterval consentiti per una determinata posizione nella stringa. getendcharacter (astratto): ritorna la lista dei CharInterval consentiti alla fine della stringa. elementmatch: individua la porzione di stringa che rispetta i vincoli dati dalle liste di CharInterval restituiti dai metodi sopra descritti. stays: dice se un carattere appartiene a un determinato CharInterval. 57

70 4 JCodeConverterLite Figura 4.4. UML delle Value ischaractercontained: dice se un carattere appartiene a uno dei CharInterval contenuti in una lista. Le classi che estendono Value sono: Name: rappresenta un generico nome, deve iniziare con caratteri alfabetici, può contenere caratteri alfanumerici e underscore. Number: rappresenta un numero, deve iniziare con numeri, +, - o #, può contenere caratteri alfanumerici e punti. JavaType: rappresenta un tipo di dato Java, deve iniziare con caratteri alfabetici, può contenere caratteri alfanumerici, underscore, maggiore, minore e parentesi quadre. JavaNamePart: rappresenta il nome di un JavaName, deve iniziare con caratteri alfabetici, doppie virgolette o backslash, può contenere caratteri alfanumerici, underscore, punti, doppie vigolette e backslash. JsNamePart: lo stesso di JavaNamePart ma per JsName. 58

71 4.3 ICodePiece Keyword La classe astratta Keyword rappresenta una parola chiave che deve appartenere a una lista di alternative. Figura 4.5. UML delle Keyword La classe contiene i seguenti metodi: getalternatives (astratto): ritorna la lista delle possibili parole chiave che la Keyword può assumere. checkalternatives: confronta ogni alternativa con la stringa data, in caso positivo ritorna la prossima matchposition, altrimenti -1. elementmatch: recupera le alternative con la funzione getalternatives, le passa alla funzione checkalternatives e ritorna un ICodePieceMatch con il risultato del check. Le classi che estendono Keyword sono: UniqueKeyword: rappresenta un unica parola chiave. KeywordSet: rappresenta un insieme di parole chiave. JavaModifier estende KeywordSet definendo il seguente insieme di parole chiave: public, private, protected, static, final, abstract. 59

72 4 JCodeConverterLite OptionalCode La classe OptionalCode rappresenta un elemento opzionale. Ha un attributo optionalelement che è un ICodePiece al quale si vuole associare l etichetta di opzionale (è l applicazione del design pattern Decorator). Ha due metodi: getpiecetype (Override): ritorna il PieceType dell elemento opzionale. elementmatch: richiama l omonimo metodo del elemento opzionale, se il risultato è negativo crea un nuovo ICodePieceMatch con PieceType IGNORED CompositeCodePiece La classe CompositeCodePiece rappresenta una serie di ICodePiece. Un CompositeCodePiece è riconosciuto quando tutte le sue parti sono riconosciute. Figura 4.6. UML dei CompositeCodePiece I suoi metodi sono: elementmatch: controlla che tutti gli elementi vengano riconosciuti. writesonspieces: come l omonimo metodo del ICodePiece, ma aggiunge uno spazio tra un elemento e l altro. Le classi che estendono CompositeCodePiece sono: 60

73 4.3 ICodePiece JavaMethodEvaluation e JsMethodEvaluation: rappresentano la chiamata di un metodo. JavaExtendsDeclaration: rappresenta la dichiarazione di estensione ad una classe. JavaImplementsDeclaration: rappresenta la dichiarazione di implementazione di un interfaccia. JavaThrowsDeclaration: rappresenta la dichiarazione di throws Exception in un metodo. JavaNewStatement e JsNewStatement: rappresentano l istruzione new per istanziare una classe. JavaName e JsName: rappresentano i nomi, compresi indici per gli array e Generics Java. JavaVariable e JsVariable: rappresentano la dichiarazione di una variabile. JavaTernaryOperator e JsTernaryOperator: rappresentano l operatore ternario. JoglConstant e WebGLConstant: rappresentano le costanti OpenGL. JoglMethodEvaluation e WebGLMethodEvaluation: rappresentano la chiamata a un metodo OpenGL. JsArrayContent: rappresenta l inizializzazione di un array. Figura 4.7. Esempio di CompositeCodePiece: JoglConstant GL2.GL_ DEPTH_TEST GL2.GL_ DEPTH_TEST CompositeCodePiece UniqueKeyword Name CodeSequence La classe CodeSequence rappresenta una sequenza di ICodePiece separati da uno dei caratteri divisori. Ha quindi come attributi element e la stringa div, che contiene i caratteri divisori, inoltre ha l attributo mandatory che indica se è obbligatorio. Contiene i seguenti metodi: 61

74 4 JCodeConverterLite Figura 4.8. UML dei CodeSequence isdiv: indica se un carattere è divisore o meno. elementmatch: controlla se l ICodePiece viene identificato, ignora il carattere divisore e cerca un ulteriore elemento. Le classi che estendono CodeSequence sono JavaMethodVariables e JsMethodVariables che rappresentano la dichiarazione dei parametri di un metodo AlternativeCode La classe AlternativeCode rappresenta un alternativa tra una lista di ICodePiece. La classe implementa il metodo elementmatch che scorre tutte le alternative, se una è riconosciuta viene ritornato l ICodePieceMatch associato BestAlternativeCode La classe BestAlternativeCode ha la stessa funzione della classe AlternativeCode, con la differenza che il metodo elementmatch scorre tutte le alternative e sceglie quella che riconosce la stringa più lunga Expression La classe astratta Expression rappresenta una generica espressione. Un espressione può essere vista come un insieme di elementi divisi da dei separatori. Ha come attributo alternatives, un BestAlternativeCode, che contiene tutti gli elementi che possono trovarsi in una determinata espressione, è usato dal metodo elementmatch per riconoscere i vari elementi dell espressione. I suoi metodi sono: 62

75 4.4 CodePattern Figura 4.9. UML delle Expression getexpressionseparators (astratto): ritorna la lista dei separatori. checkseparators: riconosce una stringa data una lista di alternative. matchsymbol: chiama la funzione precedente passandogli come alternative la lista di separatori. alternativematch: riconosce un elemento che corrisponda a uno delle alternative. elementmatch: riconosce un espressione riconoscendo alternative e separatori. Le classi che estendono Expression sono: JavaAlgebraicExpression e JsAlgebraicExpression: rappresentano delle espressioni algebriche. JavaBitwiseExpression e JsBitwiseExpression: rappresentano delle espressioni bit a bit. JavaBooleanExpression e JsBooleanExpression: rappresentano delle espressioni booleane. 4.4 CodePattern La classe CodePattern rappresenta una sequenza di ICodePiece che possono essere usati per riconoscere una linea di codice (CodeLine). Ha quindi l attributo elements, che è una lista di ICodePiece, e un attributo patterntype, che è una lista di PatternType. PatternType è una enumerazione che contiene tutti i tipi possibili di pattern. CodePattern possiede i seguenti metodi: addcodepiece: aggiunge elementi alla lista di ICodePiece. 63

76 4 JCodeConverterLite Figura UML del CodePattern getpieces: ritorna la lista di tutti gli elementi. addpatterntype: aggiunge elementi alle lista dei PatternType. getpatterntype: ritorna la lista dei PatternType. getpiecebytype: ritorna il primo elemento della lista degli ICodePiece che è del tipo specificato. match: verifica se una linea di codice viene identificata con questo CodePattern, in caso positivo viene ritornato un nuovo CodePattern contenente la struttura della linea di codice. In pratica chiama il metodo elementmatch di tutti gli ICodePiece che contiene, se un ICodePiece non viene riconosciuto viene ritornato null. tostring: costruisce una stringa chiamando l omonimo metodo di ogni ICodePiece contenuto nella lista degli elementi. printtypes: costruisce una stringa che visualizza tutta la struttura del CodePattern. Le classi che estendono CodePattern sono: 64

77 4.4 CodePattern JavaClassDeclaration e JavaClassDeclaration: rappresentato la dichiarazione di una classe. JavaMethodDeclaration e JsMethodDeclaration: rappresentano la dichiarazione di un metodo. JavaElse e JsElse: rappresentano il costrutto else. JavaFor e JsFor: rappresentano i costrutti for. JavaIf e JsIf: rappresentano il costrutto if. JavaAttributeDeclaration: rappresenta la dichiarazione di attributi. JavaAttributeDeclarationAndAssignemnt: rappresenta la dichiarazione di attributi con inizializzazione. JavaAttributeAssignmentPattern e JsAttributeAssignmentPattern: rappresentano l assegnazione di un attributo. JavaImportDeclaration: rappresenta un import di una libreria. JavaReturnPattern e JsReturnPattern: rappresenta il comando return. JavaSuperPattern: rappresenta il comando super. JavaPackageDeclaration: rappresenta la dichiarazione di un package. JavaVariableDeclaration e JsVariableDeclaration: rappresentano la dichiarazione di una variabile. JavaVariableDeclarationAndAssignment e JsVariableDeclaration- AndAssignment: rappresentano la dichiarazione e l inizializzazione di una variabile. JavaVariableAssignment e JsVariableAssignment: rappresentano l assegnazione di una variabile. JavaInterfaceDeclaration: rappresenta la dichiarazione di un interfaccia. JavaIsolatedKeywords e JsIsolatedKeywords: rappresentano un unica parola chiave. JavaMethodAccess e JsMethodAccess: rappresentano un accesso a un metodo. 65

78 4 JCodeConverterLite JoglMethodAccess e WebGlMethodAccess: rappresentano un accesso a un metodo OpenGL. JavaConstructorDeclaration e JsConstructorDeclaration: rappresentano la dichiarazione del metodo costruttore. JavaArrayContentDeclaration: rappresenta la dichiarazione del contenuto di un array. Figura Esempio di CodePattern: JoglMethodAccess gl. gl Enable ( GL2.GL_DEPTH_TEST ) gl. gl Enable ( GL2.GL_DEPTH_TEST ) CodePattern JoglConstant UniqueKeyword Name 4.5 CodePieceComparator La classe astratta CodePieceComparator esegue il confronto tra due ICodePiece dello stesso tipo, ma di linguaggi differenti, uno in Java e l altro in Javascript. Ha come attributi javafather e jsfather che sono i due ICodePiece che devono essere confrontati. Figura UML dei CodePieceComparator La classe ha come metodi: internalcompare (astratto): esegue il vero e proprio confronto, guardando gli elementi degli ICodePiece. Se il confronto va a buon fine ritorna true, altrimenti false. 66

79 4.5 CodePieceComparator compare: controlla che i due ICodePiece siano dello stesso tipo e chiama internalcompare passando la lista degli elementi di ciascuno dei due ICodePiece. Le classi che estendono CodePieceComparator sono: BooleanExpressionComparator: confronta due espressioni booleane. In Java e Javascript le espressioni booleane sono identiche, si è dovuto aggiungere solo un eccezione sul metodo che ritorna il codice di un tasto premuto, che in Java è getkeycode mentre in Javascript è keycode. È stato aggiunto nelle espressioni booleane perché nei test è usato dentro una if. ExpressionComparator: confronta due espressioni algebriche o bit a bit. Le differenze tra i due linguaggi sono il casting, che viene ignorato, le funzioni di creazione di buffer OpenGL e i comandi per prelevare le coordinate del mouse. MethodComparator: confronta due chiamate a un metodo. MethodVariablesComparator: confronta due dichiarazione dei parametri di un metodo. La differenza è che in Javascript non si deve indicare il tipo di parametro, ma solo il nome. NameComparator: confronta due nomi di variabili. La differenza è che in Javascript un qualsiasi tipo di array si dichiara con il tipo Array, mentre in Java occorre specificarne il tipo. Inoltre sono ignorati i generics Java e la presenza o la macanza del comando this davanti ai metodi della stessa classe. NewStatementComparator: confronta due istruzioni new. La differenza è che quando si dichiara un array in Java bisogna dirne la lunghezza. Inoltre vengono riconosciuti come uguali i tipi float (Java) e Float32Array (Javascript) nella dichiarazione di un array. NumberComparator: confronta due numeri. In Java un numero può terminare con una lettera per indicarne il tipo. OpenGlConstantComparator: confronta due costanti OpenGL. In Java iniziano sempre con GL2.GL_, in Javascript con gl. OpenGlMethodComparator: confronta due metodi OpenGL. In Java iniziano sempre con gl.gl seguito dal nome del metodo con la prima lettera maiuscola, in Javascript iniziano con gl. seguito dal nome del metodo in minuscolo. TernaryOperatorComparator: confronta due operatori ternari. 67

80 4 JCodeConverterLite VariableComparator: confronta due dichiarazioni di variabili. La differenza è che in Javascript il tipo è sempre var. 4.6 CodePatternComparator L interfaccia CodePatternComparator ha un unico metodo compare che serve per confrontare due CodePattern, uno Java e l altro Javascript. Figura UML del CodePatternComparator Il metodo vuole come parametri la lista dei CodePattern di un file sorgente Java e quella di un sorgente Javascript con un indice di partenza ciascuna. Restituisce una matrice di interi, nella prima riga sono elencati gli indici dei CodePattern Java riconosciuti, mentre nella seconda ci sono gli indici di quelli Javascript. Se non viene riconoscuto nessun CodePattern viene ritornato null. Le classi che implementano CodePatternComparator sono: AttributeAndVariableDeclarationComparator: confronta una dichiarazione di attributo Java con una dichiarazione di variabile Javascript, questo perché in Javascript gli attributi si dichiarano come le variabili. AttributeAndVariableDeclarationAndAssignmentComparator: confronta una dichiarazione di attributo con inizializzazione in Java con una dichiarazione di variabile con inizializzazione in Javascript. In Java una dichiarazione di un array e la sua inizializzazione sono visti come due Code- Pattern separati, per via delle parentesi graffe, quindi una volta riconosciuta la dichiarazione si deve cercare nel CodePattern successivo l inizializzazione e confrontarla con la relativa parte del CodePattern Javascript. AttributeAssignmentComparator: confronta due assegnazioni ad un attributo. ClassDeclarationComparator: confronta due dichiarazioni di classe. Le due dichiarazioni sono completamente diverse, il confronto avviene solo sul nome della classe. ConstructorDeclarationComparator: confronta due dichiarazioni di metodi costruttori. Il confronto avviene sul nome e sui parametri. 68

81 4.7 Fase di identificazione ElseComparator: confronta due costrutti else. ForComparator:confronta due costrutti for. IfComparator: confronta due costrutti if. IsolatedKeywordsComparator: confronta due parole chiave. MethodAccessComparator: confronta due accessi a un metodo. MethodDeclarationComparator: confronta due dichiarazioni di un metodo. Il confronto avviene sul nome e sui parametri. OpenGlGenBuffersMethodComparator: confronta due metodi per la generazione di buffer OpenGL. Il confronto avviene tra due CodePattern di tipo diverso, in quanto in Java glgenbuffers viene visto come una chiamata Open- GL, mentre in Javascript createbuffer è visto come un assegnamento di una variabile. OpenGlGenTexturesMethodComparator: confronta due metodi per la generazione di texture OpenGL. È un discorso analogo al precedente Comparator. OpenGlMethodAccessComparator: confronta due chiamate a un metodo OpenGL. ReturnComparator: confronta due comandi return. VariableDeclarationComparator: confronta due dichiarazioni di variabili. VariableAssignmentComparator: confronta due assegnazioni ad una variabile. Vale sempre il discorso delle inizializzazioni degli array, inoltre si valuta positivamente il confronto tra il metodo Java Arrays.copyOf(x) e l istruzione Javascript new Float32Array(x). VariableDeclarationAndAssignmentComparator: confronta due dichiarazioni di variabili con inizializzazione. Stesse osservazioni del precedente Comparator, inoltre valuta positivamente il confronto tra le istruzioni di temporizzazione e tra le istruzioni necessarie per caricare un immagine, in Java basta un CodePattern, mentre in Javascript ne servono tre. 69

82 4 JCodeConverterLite Figura UML di BlockUtilities 4.7 Fase di identificazione Nella fase di identificazione vengono riconosciuti tutti i CodeModule di un sorgente, che vengono messi in un unico oggetto Block. A questo scopo esiste la classe BlockUtilities, che ha i seguenti metodi: findposition: dati un array di caratteri e un carattere da cercare, ritorna la lista delle posizioni in cui è presente il carattere. buildsubstring: dati un array di caratteri, una posizione iniziale e una finale, ritorna un nuovo array contenente i caratteri compresi tra le due posizioni. insertnewcodeline: aggiunge una CodeLine al blocco dato come parametro. Vuole come parametri anche un array di caratteri, la posizione iniziale e la lunghezza, che identificano nell array la stringa da passare alla CodeLine creata e un parametro che dice se la CodeLine è di dichiarazione. addcodelinestoblock: Vuole come parametri un blocco, un array di caratteri, una posizione iniziale e una finale. Costruisce un nuovo array di caratteri temp con la funzione buildsubstring, passandogli posizione iniziale e finale. Trova tutte le posizioni del carattere ; nell array temp. Per ogni posizione trovata, aggiunge una nuova CodeLine al blocco con la funzione insertnewcodeline, passandogli come posizione iniziale, la posizione del precedente ; e come lunghezza, la differenza tra la sua posizione e quella precedente. L ultima CodeLine è impostata di tipo dichiarazione. generateblocks: Vuole in ingresso un array di caratteri, che rappresenta il testo del file sorgente. Crea un blocco fileblock, che conterrà tutti i CodeModule del sorgente, e viene impostato come actualblock. Trova tutte le posizioni delle parentesi graffe, sia di apertura che di chiusura. Per ogni posizione chiama la funzione addcodelinestoblock, passandogli actualblock, la posizione stessa e la posizione precedente. Poi, se in quella posizione c è una parentesi di apertura, viene creato un nuovo blocco, che viene aggiunto all actualblock, dopodiché viene impostato come actualblock. Se invece c è 70

83 4.7 Fase di identificazione una parentesi di chiusura, viene impostato come actualblock il padre dell attuale actualblock. Poi viene ritornato fileblock dopo averlo corretto con il metodo correctblock. Nel codice 4.2 è illustrato un esempio di output della fase di identificazione del codice Java 4.1. package testpackage; Codice 4.1. Esempio di codice Java da identificare public class SimpleClass { private int a; public int geta() { return a; } } public void seta(int a) { if (a == 1) { a += 1; } for (int i = 0; i < 10; i++) { a = * a; } this.a = a; } { } Codice 4.2. sentence:package testpackage DECLAREDBLOCK public class SimpleClass { sentence:private int a DECLAREDBLOCK public int geta() { sentence:return a } DECLAREDBLOCK public void seta(int a) { DECLAREDBLOCK if (a == 1) { sentence:a += 1 } DECLAREDBLOCK for (int i = 0;i < 10;i++) { sentence:a = * a } sentence:this.a = a } } Esempio di identificazione 71

84 4 JCodeConverterLite 4.8 Fase di interpretazione Nella fase di interpretazione, l oggetto Block viene analizzato e si associa ad ogni CodeModule il relativo CodePattern. Figura UML di BlockInterpreter Le classi coinvolte in questa fase sono: BlockInterpreter, BlockDataInterpreter, JavaCodePatternInterpreter, JsCodePatternInterpreter. I metodi dell interfaccia BlockDataInterpreter sono: getblockdeclarationpattern: data la stringa codeline della CodeLine di un DeclaredBlock, ritorna il CodePattern corrispondente. getlineofcodepattern: data la stringa codeline di una CodeLine, ritorna il CodePattern corrispondente. Le classi che implementano BlockDataInterpreter sono: JavaCodePatternInterpreter: contiene la lista di tutti i possibili Code- Pattern Java. Quando viene chiamato uno dei due metodi dell interfaccia, si scorre tutta la lista dei CodePattern finché il metodo match di uno di questi non ritorni un valore non null, quindi si ritorna il CodePattern riconosciuto. Se non si trova nessun CodePattern si ritorna null. JsCodePatternInterpreter: svolge la stessa funzione della precedente classe, ma contiene la lista dei CodePattern Javascript. Un oggetto della classe BlockInterpreter deve essere inizializzato passandogli un BlockDataInterpreter, che viene memorizzato nell attributo interpreter. La classe BlockInterpreter ha i seguenti metodi: updateinterpretation: vuole in ingresso un oggetto Block e una mappa, che associa a un CodeModule, un CodePattern. Per ogni CodeModule presente nel blocco, controlla se è una CodeLine o un DeclaredBlock. Se è 72

85 4.9 Fase di confronto una CodeLine, chiama il metodo getlineofcodepattern dell interpreter e aggiunge il risultato nella mappa. Se è un DeclaredBlock, chiama il metodo getblockdeclarationpattern dell interpreter, aggiunge il risultato nella mappa e richiama il metodo updateinterpretation, passandogli come oggetto Block il relatedblock del DeclaredBlock. getinterpretation: vuole come parametro un oggetto Block. Crea una mappa che associa a un CodeModule, un CodePattern. Chiama il metodo updateinterpretation per riempire la mappa e infine ritorna la mappa. I codici 4.3 e 4.4 illustrano degli esempi di interpretazione. Codice 4.3. Esempio interpretazione di un JoglMethodAccess [OPENGL_CALL, LINE_OF_CODE] > gl. gl Enable ( GL2.GL_ DEPTH_TEST ) OPENGL_CALL: gl. gl Enable ( GL2.GL_ DEPTH_TEST ) IGNORED: COMPOSITE:gl. VALUE:gl KEYWORD:. KEYWORD:gl NAME:Enable KEYWORD:( SEQUENCE:GL2.GL_ DEPTH_TEST EXPRESSION:GL2.GL_ DEPTH_TEST OPENGL_CONSTANT:GL2.GL_ DEPTH_TEST KEYWORD:GL2 KEYWORD:.GL_ NAME:DEPTH_TEST KEYWORD:) Codice 4.4. Esempio interpretazione di un WebGlMethodAccess [OPENGL_CALL, LINE_OF_CODE] > gl. enable ( gl. DEPTH_TEST ) OPENGL_CALL:gl. enable ( gl. DEPTH_TEST ) KEYWORD:gl. NAME:enable KEYWORD:( SEQUENCE:gl. DEPTH_TEST EXPRESSION:gl. DEPTH_TEST OPENGL_CONSTANT:gl. DEPTH_TEST KEYWORD:gl. NAME:DEPTH_TEST KEYWORD:) 4.9 Fase di confronto In questa fase avviene il confronto tra CodePattern Java e Javascript. Per il momento la procedura di confronto è racchiusa nella classe TestFileComparator, successivamente verrà integrata nel JCodeConverterLite. 73

86 4 JCodeConverterLite Figura UML del TestFileComparator La classe TestFileComparator contiene i seguenti metodi: isdefaultconstructor: controlla che un CodePattern di tipo CONSTRUCTOR_ DECLARATION abbia zero parametri, di conseguenza rappresenta un metodo costruttore di default. removecommentblocks: togli i blocchi di commenti da una stringa. getcodepatterns: vuole come parametri una stringa, che rappresenta il contenuto di un file sorgente, e un BlockDataInterpreter. Chiama il metodo removecommentblocks per rimuovere i commenti. Chiama generateblocks della classe BlockUtilities, per creare il Block del file. Chiama il metodo getinterpretation del BlockInterpreter inizializzato con il BlockDataInterpreter passato come parametro. Ritorna la lista dei CodePattern, estratti dalla mappa di interpretazione. main: viene effettuata la vera e propria procedura di confronto. Per la procedura di confronto, vengono create due liste, una contiene i nomi dei file dei test Java e l altra quelli Javascript. Per ogni file si eseguono i seguenti passi: Viene chiamato il metodo getcodepatterns per generare sia i CodePattern del test Java, sia quelli del test Javascript. Sono creati due array di booleani, javaconfirmations e jsconfirmations, che tengono conto dei CodePattern che sono stati confrontati positivamente, tra quelli Java e Javascript rispettivamente. Gli array sono inizializzati a false e hanno un numero di elementi pari al numero dei CodePattern interpretati. Per ogni CodePattern Java si cerca un CodePattern Javascript che faccia ritornare un risultato non null al metodo compare di un CodePatternComparator, ottenuto dalla lista dei CodePatternComparator presa dalla classe JavaJsCodePatternComparators. Quindi si mettono a true gli elementi degli array di booleani che sono indicati dagli indici ritornati dal metodo compare. Vengono controllati tutti i CodePattern Javascript, se ce n è uno di tipo CONSTRUCTOR_DECLARATION, viene assegnato al rispettivo elemento dell array di booleani il valore ritornato dalla funzione isdefaultconstructor. Questo 74