SVILUPPO DI UN GEOBROWSER 3D BASATO SU SHADER PER DISPOSITIVI IOS

Transcript

1 Università di Trento SVILUPPO DI UN GEOBROWSER 3D BASATO SU SHADER PER DISPOSITIVI IOS Federico Devigili Relatore: Raffaele De Amicis Università di Tento Facoltà di scienze MM.FF.NN Corso di laurea in Informatica Documento relativo alla tesi triennale Novembre

2 2

3 Abstract Negli ultimi anni la diffusione di sistemi per la visualizzazione 3D di immagini terrestri è cresciuta vertiginosamente. La disponibilità e la qualità delle informazioni consultabili sono cresciute di pari passo. Sin dal 2006 sono disponibili cellulari compatibili con le API OpenGL ES ed è già disponibile hardware destinato a mobile che implementa le specifiche Opengl 4.0 e DirectX Nonostante questo, applicazioni che facciano uso di tali funzioni, sono ancora poche. L obiettivo di questo documento è di fornire le specifiche dell implementazione di un software per la visualizzazione di terreni 3D reali su dispositivi mobile che tragga vantaggio dalle funzionalità del nuovo hardware. Nel rendering di terreni realistici il limite maggiore è quello della memoria e della potenza di calcolo del dispositivo che deve contenere e processare una grande quantità di dati. E stato di conseguenza sviluppato un geobrowser WMS basato sugli shader, che trae vantaggio della possibilità di riutilizzare le geometrie e texture compresse minimizzando il lavoro della CPU e l utilizzo di memoria. Texture e dati d elevazione [DEM] vengono forniti da un server personalizzato che processa i dati on-the-fly. La soluzione risulta essere performante nel caso in cui il dispositivo sia CPU-limited o si abbia un grande numero di texture da renderizzare. 3

4 4

5 Sommario Abstract... 3 Stato dell arte... 9 Iphone hardware... 9 Iphone OS... 9 Opengl ES Gli Shader Il Vertex shader Il Fragment Shader Protocollo WMS GetCapabilities GetMap Il formato BIL La compressione PVRTC Soluzione Proposta Schema dell Architettura Level of Detail, Il Quadtree dei Tile Implementazione del Culling Il Frustum Culling Culling basato sull incidenza Culling, Considerazioni Vertex Shader e VBO (Vertex Buffer Object) Le skirts Fragment Shader e le Texture Compresse La servlet Il sistema di cache I problemi riscontrati Displacement Mapping e il Vertex Texture Fetch

6 2010 La compressione PVRTC Lo Z-Buffer, il limite dei 16 bit Test Test delle Prestazioni Conclusioni Conclusioni Lavori Futuri Hardware Tessellation su GPU di nuova generazione

7 Introduzione Sin dal 2006 GPU compatibili con le API OpenGL ES 2.0 sono disponibili sul mercato, mentre nel 2010 è stata stampata la prima GPU destinata a dispositivi mobile compatibile con le specifiche OpenGL 4.0 e DirectX Anche se sui personal computer GPU programmabili sono disponibili ormai da dieci anni sui dispositivi mobile la mancanza di memoria e di Potenza di calcolo non hanno permesso fino ad ora di sfruttare pienamente le potenzialità di queste nuove tecnologie. Tuttavia, sui dispositivi mobile, il passaggio al nuovo standard è solo questione di tempo. Il problema più grande quando si sviluppa un geobrowser su un dispositivo mobile è la mancanza di memoria e la potenza della CPU. Grandi strutture dati contenenti i dati tridimensionali e le texture sono necessarie per il rendering del terreno in tre Dimensioni. Oltre a questo durante la navigazione il terreno deve costantemente essere aggiornato a una risoluzione maggiore, nuove texture devono essere scaricate e processate e il tutto deve essere caricato in memoria video utilizzando cosi costantemente il bus di trasmissione. La nostra soluzione minimizza il carico della CPU, della memoria e del bus. Una lista di tile che compongono il terreno è generata da un algoritmo che tiene conto della posizione del punto di vista. In base alla distanza dal punto di vista è disegnato un tile a minore o maggiore risoluzione. L algoritmo di rendering utilizza i vertex shader per riutilizzare le geometrie già caricate in memoria video, infatti, non sono mai caricati in memoria dati 3D aggiuntivi ma lo stesso tile è ridisegnato continuamente. Il vertex shader si occupa di traslare e scalare il tile nella posizione corretta in base ai parametri di rendering. Sempre nel vertex shader le coordinate delle textures sono generate on-the-fly. Un server personalizzato si occupa di preparare i dati per essere caricati dal sotware, le texture, scaricate da un server WMS, sono trasformate in un formato compresso e, insieme ai dati DEM, inviate al client. 7

8 8

9 Stato dell Arte 2010 Stato dell arte Iphone hardware Per lo sviluppo dell'applicazione è stato scelto il dipositivo iphone 3GS, questa versione, rispetto alla precedente, offre, oltre a una migliore CPU e un maggior quantitativo di memoria, un ottima soluzione grafica, necessaria per lo sviluppo di qualsiasi applicazione 3D. Specifiche tecniche: CPU: ARM 8 600MHz GPU: Power VR SGX 525 RAM: 128Mb Shared Memory (Cache, L1:32KB, L2:256KB) Schermo: 480x320(0.15Mp) LCD TouchScreen Per la nostra applicazione l'importanza della CPU è relativa, come andremo a vedere, il vero lavoro sarà svolto dalla GPU. La soluzione grafica presente è compatibile con le librerie OpenGL ES 2.0 ed è quindi una GPU programmabile attraverso il linguaggio GLSL, considerando la relativamente bassa risoluzione dello schermo tale soluzione grafica è in grado di renderizzare in real-time scene piuttosto complesse ed effetti grafici avanzati quando necessario. La quantità di memoria RAM è modesta e condivisa tra CPU e GPU. Come andremo a vedere il throughput RAM sarà il collo di bottiglia per la nostra applicazione. Iphone OS Iphone OS è il sistema operativo presente su tutti i dispositivi mobile Apple. Contiene le api necessarie per l'interfacciamento con tutte le periferiche del dispositivo, come la bussola, lo schermo touchscreen o il GPS oltre che a varie librerie: UIKit, la libreria per la costruzione della parte grafica delle applicazioni touchscreen. Foundation, la libreria di classi per la gestione dei dati (Collezioni), e la gestione dell'applicazioni in generale. E le librerie OpenGL ES necessarie per l'interfacciamento a basso livello e la programmazione della GPU. L'insieme di queste tecnologie forma il COCOA framework. Il principale linguaggio di programmazione usato è Objective C. Objective C è un linguaggio di programmazione riflessivo ad oggetti che estende C. E' prevalentemente utilizzato nei sistemi operativi Apple. 9

10 Stato dell Arte 2010 Opengl ES OpenGL ES è un API multi-piattaforma per la grafica 2D e 3D su sistemi embedded. Offre un interfaccia a basso livello tra il software e l acceleratore grafico. Sono presenti due versioni di quest API: 1.0/1.1: Per hardware a pipeline fissa. Basata sulle specifiche delle OpenGL 1.5 offre funzionalità di base, performance e miglioramenti per minimizzare il consumo energetico e l'utilizzo di banda in memoria. 2.0: Per hardware a pipeline programmabile. Basata sulle specifiche OpenGL 2.0 permette quindi di sfruttare la pipeline programmabili delle GPU compatibili. Si ha la possibilità di scrivere vertex e fragment shaders in GLSL (OpenGL Shading Language). Questa versione rimuove totalmente la possibilità di usare la fixed pipeline orami obsoleta, che è, infatti, del tutto emulabile via shaders. E' stato scelto quindi di implementare l applicazione utilizzando l'ultima versione delle API. Tale scelta è stata dettata anche dalla necessità di trasferire quanto più carico possibile sulla GPU, per questioni di risparmio energetico e responsività dell'applicazione. Essendo quest API un sottoinsieme delle più complete classiche OpenGL molte funzionalità sono state rimosse, in particolare sono state rimosse: API e funzionalità ridondanti lasciando solamente le più performanti (es. glbegin(), glend()) L OpenGL Utility Library, contenente varie funzioni d'utilità come le strutture matematiche e le funzioni più utilizzate nel campo della grafica 3D. Il supporto ai numeri Floating Point in doppia precisione. Wireframe rendering, 24bit Z-Buffer e altre funzioni troppo computazionalmente pesanti per essere utilizzate su mobile. La rimozione di tali funzionalità non compromette le potenzialità della libreria, e forza lo sviluppatore a utilizzare le funzioni più adatte allo scopo. Gli Shader Gli shader sono piccoli programmi che sono eseguiti parallelamente sulla GPU per renderizzare le immagini. Nel caso delle OpenGL ES 2.0 si possono distinguere due shader differenti. In ordine cronologico abbiamo il Vertex Shader e il Fragment Shader. 10

11 Stato dell Arte 2010 Figure 1- OGL ES 2.0 Pipeline Anche se gli shader erano originariamente pensati solo per renderizzare effetti grafici avanzati, la loro continua evoluzione e maggiore versatilità li ha portati a diventare strumenti per calcolo parallelo ad alte prestazioni. Le GPU odierne dispongono di API per il calcolo parallelo [CUDA e DirectCompute] con le quali sono stati implementati vari software per la simulazione fisica, folding di proteine, simulazione n-body, motori di rendering non realtime e basati su ray-tracing. 11 Figure 2 NVIDIA CUDA, Simulazione n-body Tra i più comuni e utilizzati c è sicuramente Physx il simulatore fisico targato NVIDIA già utilizzato in molti software videoludici.

12 Stato dell Arte 2010 Il Vertex shader Il Vertex shader è un programma che riceve in input la posizione di un vertice in 3 dimensioni e deve dare in output [come minimo] la posizione del vertice proiettata in 2 dimensioni. Il vertex shader viene utilizzaro oltre che per la classica trasformazione in coordinate-schermo anche per eseguire vari effetti grafici che alterano la posizione dei vertici. Ad esempio se si alterano le posizioni dei vertici di un piano si possono simulare le onde dell oceano. Aattraverso una texture si può eseguire il displacement-mapping cioè lo scostamento dei vertici in base ad una texture in bianco e nero lungo la normale. Tale tecnica è utilizzata per aggiungere dettagli ad alta frequenza a modelli più grossolani. Il Fragment Shader Il Fragment Shader, conosciuto in altri contesti come Pixel Shader, è un programma che riceve in input tutti gli output del vertex shader da in output unicamente il colore del frammento relativo. Un frammento corrisponde solitamente ma non necessariamente ai pixel dello schermo. Nel Fragment Shader sono implementate tutte le tecniche d illuminazione oltre a molte altre tecniche per rendere più realistiche le immagini sullo schermo. Bump mapping, normal mapping, effetti di sfocatura, motion blur, ombre ecc. E nel Fragment Shader che la maggior parte delle letture-texture avvengono; ogni effetto, oltre alla classica lettura della texture diffusa, si basa solitamente su una texture aggiuntiva sul modello. Il bump mapping usa una texture in bianco e nero per simulare piccole imperfezioni della superficie, stessa cosa accade per il normal mapping che però si basa su una texture dove sono immagazzinati vettori direzione. L unico limite per generare effetti aggiuntivi è dato dalla memora e dalla potenza di calcolo della GPU e dalle capacità di artisti e programmatori. Protocollo WMS Il protocollo Web Map Service [WMS] è un interfaccia ad un servizio web per la richiesta di immagini geo-referenziate ottenute da una o più basi di dati. Il servizio si occupa di recuperare le immagini da una o più sorgenti, di costruire l'immagine finale in base alle coordinate di richiesta e di trasformarla nel formato richiesto (es. jpg, png). Lo stesso server può fornire diversi livelli d immagini e quindi differenti tipi d informazioni. I dati disponibili e i formati possono variare sensibilmente da server a server. In generale si può dire che un generico server WMS possa: -Produrre e fornire una mappa in un generico formato. -Fornire le proprie funzionalità e di dati disponibili. Per generare queste richieste il client deve accedere al server attraverso un URL 12

13 Stato dell Arte 2010 che sarà differente a seconda della richiesta, in particolare andremo a descrivere le 2 richieste più comuni. Da notare che un servizio WMS è generico, non include solamente i dati visuali del terreno ma può includere qualsiasi dato geo referenziato mappabile. Ad esempio esistono layer in bianco e nero che descrivono l altezza del terreno, altri che mappano la densità di popolazione, le piogge, l emissione di raggi IR o l assorbimento UV. GetCapabilities La richiesta GetCapabilities serve a fornire al client la lista di funzionalità disponibili sul server WMS. Attraverso questa richiesta si puo ottenere la lista di mappe e layer disponibili, il formato delle immagini supportate, l area nella quale sono disponibili i dati, e descrizioni in linguaggio naturale del layer. Grazie alla standardizzazione del formato è possibile popolare dinamicamente una lista di funzionalità e implementare cosi un client che sia compatibile con tutti i server wms. Un esempio di richiesta può essere: tale richiesta restituisce un file XML contenete le informazioni indicate. GetMap La richiesta GetMap è la richiesta vera e propria del dato al servizio WMS. I parametri necessari, oltre ai parametri comuni, per eseguire la richiesta sono: Layers: Descrive i layer che si desiderano attivare, il server wms comporrà l immagine finale utilizzando i layer selezionati. SRS: Specifica in che modo saranno passate le coordinate del Bounding Box dell immagine. BBOX: Specifica l area che si vuole sia visualizzata sull immagine. Width/Height: Specifica la risoluzione della texture desiderata. Format: Specifica il formato desiderato dell immagine. Un esempio di richiesta GetMap è la seguente: 326&format=image/jpeg&layers=bmng200406&styles=&bbox=27,27,35,35&widt h=512&height=512 La richiesta d esempio richiede al server di generare un immagine utilizzando il layer [bmng200406] dell area che va dalle coordinate [27,27 ] e si estende per 8 a nord ed ad est; l immagine deve essere della risoluzione 512x512 e verrà fornita nel formato [JPEG]. 13

14 Stato dell Arte Figura 1 - Blue Marble e la stessa texture utilizzata nell applicazione. Come possiamo vedere il risultato è un immagine in colori artificiali del delta del Nilo. Il nome comune del layer utilizzato è Blue Marble. Il formato BIL Il formato file BIL è un formato non standard per la trasmissione di dati DEM [Digital Elevation Model] utilizzato in Nasa World Wind, cioè un file che contiene informazioni sull altezza del terreno in vari punti della terra. Dato che i file BIL non contengono header e informazioni sulla struttura, bisogna conoscere in anticipo queste informazioni, nel nostro caso i file BIL provengono dal server pubblico JPL (Jet Propulsion Laboratory) ed hanno dimensione fissa. Il file BIL è composto di un bitmap a risoluzione e dimensione fissa di 150x150 pixel 16bpp [45000B]. Ogni pixel va a descrivere l altezza di un area del terreno in metri, i sedici bit d informazione vanno interpretati come intero con segno quindi il formato può descrivere altezze da -32 a 32 Km con una risoluzione di 1 m, più che sufficiente per descrivere la variazione di altitudine presente sulla terra che va circa da -13Km a 9Km. Per richiedere un file BIL si utilizza una richiesta http attraverso una semplice sintassi. Un esempio di richiesta di un file BIL è la seguente:

15 Stato dell Arte 2010 &L=0&X=9&Y=6 Come possiamo vedere la richiesta ha bisogno di quattro parametri; il primo è il tipo di file desiderato, possiamo richiedere un file compresso o non compresso, in questo caso stiamo richiedendo un file compresso. Il secondo parametro indica il livello di dettaglio desiderato, il livello zero è il livello minimo di dettaglio, dove ogni file descrive un area di 20x20, sono quindi necessari 18x9 tile per coprire il globo al livello minimo. A ogni livello successivo la risoluzione raddoppia quindi l area coperta è un quarto del livello precedente. Gli altri due parametri sono il numero del tile a partire da [-180,-90 ]. A livello zero le coordinate 5,8 corrispondono al tile che va da [0,0 ] a [20,20 ], le coordinate 6,9 a [20,20 ], [40,40 ]; a livello 1 ogni tile copre un area di 10 quindi a coordinate 0,0 l area coperta sarà [-180,-90 ], [-170,-80 ]. 15 Figura 2- Altimetria e Batimetria attraverso BIL Le immagini mostrano il tile [9,6] a livello zero, le immagini sono state processate in un programma di fotoritocco per aumentarne il contrasto. La compressione PVRTC La Compressione texture PVRTC usata nell applicazione è una compressione lossy, block based usata su tutte le schede grafiche Power VR MBX e SGX, schede montate in particolare sul nostro Device di riferimento. Al contrario delle comuni compressioni lossy come le compressioni usate nel formato jpg, la compressione PVRTC è stata sviluppata in modo che sia possibile decomprimere i dati via hardware, in modo veloce ed efficiente senza dover decomprimere l intera immagine, questo permette di mantenere i dati compressi in memoria video e decomprimerli al volo quando richiesti per il rendering risparmiando memoria e

16 Stato dell Arte 2010 banda. La compressione funziona generando due immagini a bassa frequenza (1/16 o 1/64 della risoluzione) dell immagine originale e un immagine di modulazione a risoluzione piena raggiungendo una compressione finale di 1/8 o 1/16 su immagini RGBA8 (32bit), corrispondente a un costo fisso per pixel di 4bpp o 2bpp. Per ottenere il colore del pixel richiesto si scalano le due immagini a bassa frequenza alla risoluzione originale con un filtro bilineare, e utilizzando i dati dell immagine modulatrice si compone il colore finale. L utilizzo di questa tecnologia permette di caricare in memoria fino a 3200 texture RGBA8 256x256 nella memoria video del dispositivo contemporaneamente usando il formato a 4bpp. Figura 3 - Compressione PVRTC e S3TC 16

17 Soluzione Proposta Schema dell Architettura Com è possibile osservare dallo schema nella pagina seguente l applicazione è stata progettata per essere molto parallelizzabile. Una servlet installata su un server WEB apache funziona da interfaccia e primo livello di cache per la raccolta dei dati necessari al rendering del terreno attraverso due servizi pubblici WMS e DEM. All interno della servlet un software per la compressione PVRTC processa le immagini ricevute da server WMS per trasformarle nel formato adatto all harware; allo stesso modo i dati DEM vengono processati per essere pronti per il caricamento in memoria. 17

18 Soluzione Proposta 2010 Figura 4 - Schema dell'architettura. La parte dedicata alla CPU è divisa in quattro parti logiche alle quali sono assegnati uno o più thread. La prima si occupa di gestire l input dall utente, ne intercetta gli eventi e modifica il punto di vista dell utente nel geobrowser. Il Data-Manager s interfaccia alla servlet e invia le richieste per il download dei dati, inoltre si occupa della gestione dei dati in memoria, scarica e carica i dati in memoria video quando richiesto e tiene traccia di tutti i dati disponibili. Implementa un livello di cache sulla memoria fissa del dispositivo, il download è effettuato solo se i dati richiesti non sono disponibili localmente. Fatta eccezione per l effettivo caricamento in memoria video dei dati, che non è possibile parallelizzare, il procedimento di download e preparazione dei dati avviene in thread separati per ogni richiesta permettendo cosi all applicazione di mantenere l interattività durante il download. L algoritmo di pre-rendering si occupa della logica della suddivisione in tile del terreno. Basandosi sul POV e dai dati attualmente disponibili, attraverso un 18

19 Soluzione Proposta 2010 algoritmo di suddivisione ricorsiva dei tile e due tecniche di culling genera una lista di tile pronti al rendering. Con la lista generata dal pre-rendering, nel thread dove è presente il contesto OpenGL ES, avviene l effettiva richiesta di rendering alla GPU. Lo stesso thread si deve occupare obbligatoriamente anche del caricamento in memoria dei dati necessari quando istruito dal data manager bloccando il rendering. Ciò è dovuto al fatto che i driver a disposizione non supportano il DMA che permetterebbe di accedere direttamente alla memoria destinata alla scheda video e quindi di caricare dati da thread separati. In fine la GPU, istruita dal Rendering-Loop e carica dei dati necessari, va a disegnare l immagine finale per ogni frame utilizzando due semplici shader, il Vertex shader si occuperà di processare i vertici e i triangoli eseguendo trasformazioni e traslazioni dei dati 3D mentre il Fragment Shader leggerà i dati delle texture caricate che andranno cosi a definire il colore finale dell immagine renderizzata. 19

20 Soluzione Proposta 2010 Level of Detail, Il Quadtree dei Tile Perché sia possibile renderizzare livelli di dettaglio diverso, in un applicazione come un geobrowser, è necessario implementare un sistema di LOD avanzato, i sistemi comuni come il mip mapping sono pensati per avere differenze di livello di dettaglio limitate e non prevedono l ottimizzazione sull uso della memoria. Figura 5 Bianco: Tile Disegnati, Nero: Tile Esclusi per Frustum Culling Nell applicazione sviluppata è stato implementato un sistema personalizzato per avere risoluzioni da centinaia di km/pixel fino a frazioni di m/pixel. Per eseguire il rendering della superficie terrestre si parte alla risoluzione base, dove un tile corrisponde a 20x20 gradi. Questo porta a un primo livello composto di 18x9 tile. Tale soluzione è stata scelta per corrispondere alla risoluzione del servizio DEM utilizzato. In questo modo si ha una corrispondenza 1:1 con i file BIL ed i tile. 20

21 Soluzione Proposta 2010 Nel momento in cui la visuale si avvicina alla superfice terrestre, e la risoluzione spaziale diminuisce, i tile renderizzati sono suddivisi in quattro sotto tile di dimensioni inferiori aventi tuttavia textures alla stessa risoluzione aumentando cosi il dettaglio. Questo è eseguito finché la distanza tra il nostro punto di vista ed i nuovi tile non è sufficientemente elevata rispetto alla dimensione stessa dei tile o finche non si raggiunge il livello massimo consentito. Per gestire le suddivisioni sono generati diversi quadtree. Ogni tile di primo livello corrisponde a una root di un quadtree avente a sua volta quattro figli. Grazie a questa struttura è facile associare a ogni tile tutti i dati relativi. Implementazione del Culling Un sistema di LOD come descritto sopra sarebbe del tutto inattuabile se non fosse integrato insieme con un sistema di culling dei tile. Se si disegnassero tutti i tile di un determinato livello il numero di tile da disegnare salirebbe esponenzialmente, per il livello uno sarebbero 162, a livello tre sarebbero 2592, a livello otto sarebbero più di due milioni. Per ovviare a questo problema i tile non visibili sono scartati. Grazie alla struttura del quadtree sappiamo che se il tile padre non è visibile allora anche tutti i figli non lo sono. Sfruttando questa proprietà possiamo implementare un sistema di hierarchical 21

22 Soluzione Proposta 2010 culling basato su due tecniche. La prima, la più comune è il frustum culling, la seconda, specifica di quest applicazione, è una tecnica basata sull angolo d incidenza tra il tile e la telecamera. L insieme delle due tecniche permette di avere un efficienza sul culling e raramente sono disegnati più di venti tile alla volta durante il normale utilizzo dell applicazione. Figura 6 - Blu: Tile Esclusi per incidenza. Il Frustum Culling Il frustum culling è una tecnica di culling basata sul volume visivo della matrice di proiezione usata per la trasformazione delle coordinate. Una matrice di proiezione prospettica genera un frustum che può essere definito da 6 piani (Left,Right,Top,Bottom,Near,Far). Il software oltre a generare la classica matrice di trasformazione modifica i valori del Near e Far Plane per ottenere una maggiore risoluzione sullo Z-Buffer. Conoscendo i sei piani che definiscono il frustum è possibile stabilire se un punto è all interno di essi facendo un controllo sulla distanza tra punto e piano relativo. Se la distanza è positiva per tutti sei i piani 22

23 Soluzione Proposta 2010 significa che il punto si trova all interno del frustum. Si può eseguire lo stesso processo per una sfera semplicemente tenendo conto del suo raggio quando si fa il controllo sulla distanza. Per verificare l effettiva visibilità di un tile il programma calcola quindi una sfera (Bounding Sphere) che contiene completamente il tile e verifica se tale sfera è almeno in parte all interno del frustum della telecamera. Tale controllo non è perfetto e dato che una sfera è comunque un approssimazione dei tile è possibile che vengano disegnati tile che non sono all interno dell area di visualizzazione. Figura 7 - Punto di vista reale ( Blu: Tile esclusi per incidenza) Culling basato sull incidenza Questa tecnica di culling si basa su una caratteristica della sfera. Se l incidenza di un raggio che ha origini al nostro punto di vista su un certo punto di una sfera è minore di zero allora quel punto non è visibile dal punto di vista. Questo significa semplicemente che i tile nell emisfero retrostante rispetto al nostro punto di vista, com è ovvio che sia, non sono visibili. Tuttavia tali tile possono comunque risulatare all interno del frustum della telecamera e quindi essere disegnati. Se si calcola l angolo tra il vettore normale di un tile e un vettore con direzione pov -> tile possiamo dire che se quest angolo è maggiore di 90 allora il tile non è visibile. Effettuare questo test è molto veloce e permette di escludere molti tile in alcune situazioni, vedi Figura 7. 23

24 Soluzione Proposta 2010 Figura 8 - Verde: Frustum, Rosso: Intersezione Frustum e Superficie. Culling, Considerazioni In Figura 7 sono visibili tile bianchi all esterno del frustum (Notare che il limite della visualizzazione è dato dalla linea rossa). Questo perché sfere contenenti tile completamente esterni al Frustum potrebbero intersecarlo. Soluzioni migliori prevedono l uso di forme di bounding diverse come il cilindro, o tecniche basate sul calcolo della visibilità dei triangoli; più complesse tuttavia da implementare e più computazionalmente pesanti. 24

25 Soluzione Proposta 2010 Vertex Shader e VBO (Vertex Buffer Object) attribute vec4 position; attribute float height; varying vec2 textcoord; uniform float size,x,y; uniform mat4 u_matviewprojection; uniform sampler2d s_texture; void main() { textcoord = vec2(position.x+0.5, position.y+0.5); vec4 pos = position; pos.x = (pos.x * size + x) ; pos.y = (pos.y * size + y); pos.x = * (pos.x - 9.0) / 9.0; pos.y = * (pos.y - 4.0) / 9.0; float coslat=cos(pos.y); float sinlat=sin(pos.y); float coslon=cos(pos.x); float sinlon=sin(pos.x); float equatorialradius = ; float distortioncoeff = ; float rpm = equatorialradius / sqrt(1.0 - distortioncoeff * sinlat * sinlat); pos.x = (rpm + 0.0) * coslat * sinlon; pos.y = (rpm * (1.0 - distortioncoeff) + 0.0) * sinlat; pos.z = (rpm + height) * coslat * coslon; gl_position = u_matviewprojection * pos; } Nell applicazione 3D il vertex shader non si occupa solamente della proiezione dei vertici ma anche dell effettiva trasformazione in sfera dei tile. La CPU disegna costantemente un unico tile nella stessa posizione, le uniche cose che cambiano sono i parametri passati al vertex shader con i quali il programma trasforma i vertici nella posizione e dimensione adatta. I parametri effettivi passati o generati dallo shader sono elencati di seguito. In particolare il programma andrà a basarsi su size, x, y per traslare il vertice in due dimensioni. In seguito, durante la 25

26 Soluzione Proposta 2010 trasformazione in sfera del tile, sarà aggiunta all altezza base, computata da latitudine e longitudine, la componente di altezza letta dal VBO andando cosi a trasformare il vertice nel punto esatto. Si può inoltre vedere come le coordinte textures siano generate on-the-fly dallo shader textcoord = vec2(position.x+0.5, position.y+0.5); Questo permette, in caso di utilizzo di alter tecniche di rendering, di rimappare ogni tile a piacimento a seconda di ulteriori parametri. PARAMETER USE position Actual vertex position before transforming height VBO ready to get used for displacement textcoord TextCoords generated on the fly for the Fragment Shader Based on position size Parameter used to scale the tile to the real size x, y Parameters used to translate the tile to the correct position u_matviewprojection Transformation matrix, representing view and projection s_texture Diffuse texture pointer. 26

27 Soluzione Proposta 2010 Le skirts Quando durante il rendering sono disegnati i tile su un terreno che non è piano, può succedere che i bordi dei tile adiacenti e a LOD differenti, non condividano la coordinata Z o l altitudine. Questo perché la mappatura dell altezza non è perfetta e i file bil a diversi LOD contengono informazioni leggermente differenti. Cioè se andiamo a interpolare linearmente le altezze di un DEM a bassa risoluzione non corrisponderanno ovviamente a quelle di un DEM a risoluzione maggiore. Questo può causare dei buchi nel rendering e quindi rovinare la percezione del terreno e spezzare la continuità del modello tridimensionale. Per ovviare a questo problema sono possibili molteplici soluzioni. La tecnica implementata nel prototipo è di utilizzare delle skirts per i tile [Gonne]. Le skirts sono una serie di poligoni aggiuntivi che circondano tutti i tile andando quindi a formare delle gonne. E facile capire come sono costruite se pensiamo a una semplice operazione di estrusione sul tile. I vertici delle skirts andranno a ereditare le coordinate texture dai vertici soprastanti Figura 9 Wireframe skirts venendo cosi renderizzati con i colori dei bordi dei tile dando un senso di continuità al terreno. In figura 9 è possibile osservare le geometrie aggiuntive generate dalle skirts. Ai bordi dei tile si notano i poligoni verticali che vanno a coprire gli eventuali buchi di rendering. 27

28 Soluzione Proposta 2010 Figura 10 - Tile con skirts Figura 11 - Tile Senza Skirts Fragment Shader e le Texture Compresse Il Fragment shader utilizzato è estremamente semplice ed esegue unicamente l operazione di leggere dalla texture il colore della mappa e restituirlo in output. Lo shader corrente è solo la base dell algoritmo necessario a renderizzare le immagini più realisticamente. Vanno ancora implementata la parte d illuminazione che necessita tuttavia delle informazioni sul vettore normale delle superfici che non 28

29 Soluzione Proposta 2010 sono al momento disponibili. La natura del motore di rendering adottato impone alcuni limiti su come ottenere le normali delle superfici. Se per oggetti statici o conosciuti a priori le normali possono essere computate prima, quando si generano le geometrie on-the-fly, come nel nostro caso, questo non è possibile. Le normali potrebbero essere computate dall analisi dei dati DEM quindi generando una texture aggiuntiva per il Fragment Shader. Tale soluzione tuttavia andrebbe a pesare ulteriormente sul già limitato quantitativo di memoria del dispositivo. La servlet Per ovviare al problema della compressione delle texture è stata implementata una servlet in grado di funzionare oltre che come servizio per la compressione delle texture anche come primo livello di cache. Dato che la compressione PVRTC utilizzata nelle GPU SGX è estremamente pesante da effettuare e, in ogni caso, non esistono ancora librerie per effettuarla sul dispositivo mobile; la servlet si occuperà di comprimerla attraverso un applicazione apposita. Dato che comprimere una piccola texture 256x256, al formato utilizzato [4bpp - Low Quality], su una macchina intel a 2GHz impiega ben due secondi, è stato implementato una cache a livello di file in modo che richieste successive dello stesso tile non abbiano bisogno di nuovo calcolo. I tile calcolati sono quindi salvati sul server web in una cache. La servlet riceve la richiesta attraverso un URL che come parametro ha un ulteriore URL che corrisponde all indirizzo dell immagine da comprimere. L indirizzo dell immagine non deve necessariamente essere quello di un server WMS e, in effetti, la servlet può comprimere qualsiasi immagine presente sul web se appartenente a uno dei formati supportati [jpg, png]. Il sistema di cache Mantenere in memoria tutte le texture scaricate comporterebbe un enorme spreco di memoria. Per ovviare a ciò è stato implementato un sistema di cache a più livelli. Quando è richiesta la texture di un certo tile per il rendering viene generato un thread che ha la funzione di caricarla in memoria. Per prima cosa il thread controlla che la texture non sia già presente nella memoria fisica del dispositivo, se è presente, la texture è caricata direttamente e segnata come pronta al caricamento sulla GPU. Nel caso in cui la texture non sia presente, è generato un URL di richiesta per la servlet che si occuperà di preparare e restituire la texture. Una volta ottenuta la texture dalla servlet, il thread ne salva una copia sulla memoria fisica del dispositivo e segna la copia in memoria RAM come pronta al caricamento sulla GPU. 29

30 Soluzione Proposta 2010 Solo il thread di rendering può eseguire l effettivo caricamento in memoria video delle texture pronte al caricamento; sfortunatamente questo implica che durante il caricamento effettivo in memoria il thread di rendering sia bloccato. Questo è un limite delle librerie OpenGL che solitamente è aggirato attraverso l uso del DMA [Direct Memory Access] che non è tuttavia disponibile sul dispositivo utilizzato. 30

31 I problemi riscontrati Displacement Mapping e il Vertex Texture Fetch La soluzione che inizialmente era stata pensata per eseguire il rendering del terreno prevedeva l utilizzo di una tecnica, già da qualche tempo utilizzata nei software d intrattenimento, chiamata Displacement Mapping. Il Displacement Mapping è una tecnica che prevede l utilizzo di texture in bianco e nero per compiere un displacement (Uno scostamento) dei vertici di una superfice. Attraverso l utilizzo del vertex shader è possibile andare a leggere i dati presenti in una texture e quindi utilizzarli per eseguire uno spostamento, solitamente lungo la normle dei vertici di un oggetto 3D. Nel caso del rendering di un terreno 3D è facile immaginare che disegnando un oggetto piano formato da molti poligoni, è possibile applicarci una texture in bianco e nero, quindi, nel vertex shader, andare a leggere il punto relativo e scostare il vertice lungo l asse z di un valore proporzionale al colore della texture. L operazione di letture delle texture nel vertex shader è chiamata Vertex Texture Fetch [VTF]. I vantaggi di questa tecnica sono molteplici. Il Vertex Texture Fetch funziona esattamente come la lettura di una texture del Fragment Shader e quindi trae vantaggio dall hardware della GPU. E possibile utilizzare diversi tipi d interpolazione dei dati [punto, bilineare, trilineare]. Le texture traggono vantaggio della compressione hardware. E possibile mappare più tile sulla stessa texture andando a modificare le coordinate U.V. Ma soprattutto le texture possono avere qualsiasi risoluzione e non sono legate alla risoluzione poligonale del tile. Questo significa che potremmo variare le risoluzioni poligonali dei tile in realtime senza andare a modificare le texture di displacement. Tuttavia ciò non è possibile sul dispositivo utilizzato; anche se la GPU montata supporta il Vertex Texture fetch, i driver disponibili al momento della realizzazione del software non ne hanno permesso l utilizzo. Questo ci ha portato a utilizzare i Vertex Buffer Object [VBO]; i VBO sono array ad alte prestazioni solitamente utilizzati per lo storage di dati 3D e parametri nella memoria video e per l ottimizzazione del rendering. Nel nostro caso sono stati utilizzati per eseguire il Displacement. Utilizzare i VBO implica però che ci sia una corrispondenza 1:1 tra il numero di vertici dell oggetto disegnato e il numero di elementi dell array. Quando il VBO è passato come parametro alla GPU è possibile leggerne i valori dal Vertex shader e quindi utilizzare i dati presenti per eseguire il Displacement del vertice. Al contrario delle texture però i VBO sono strettamente collegati all oggetto renderizzato. Se andiamo a disegnare un tile a risoluzione maggiore, cioè con più poligoni, con lo stesso VBO la corrispondenza tra gli elementi 31

32 Problemi Riscontrati 2010 dell array e i vertici dell oggetto verrà a mancare. Con questa soluzione si perde quindi la possibilità di cambiare la risoluzione del tile a piacimento poiché questo prevedrebbe l aggiornamento di tutti i VBO caricati in memoria. La compressione PVRTC Inizialmente il software è stato sviluppato senza tenere conto della compressione texture, tuttavia i limiti dovuti a tale scelta non hanno tardato a farsi notare. Con un limite di memoria video utilizzabile dalle texture impostato a 50 MB è possibile caricare sul dispositivo utilizzando texture non compresse circa 200 textures 256x256x32bit. Tuttavia navigando sul terreno, è estremamante facile superare questo limite. Dato che le texture compresse permettono, oltre che un risparmio di memoria, anche un aumento prestazionale considerevole, è stato obbligatorio introdurle. La compressione texture PVRTC, o la compressione texture in genere, potrebbe sembrare la panacea di tutti i problemi di memoria sui dispositivi con performance limitate. Tuttavia l utilizzo di questa tecnica non è banale. Se in un applicazione 3D classica come potrebbe essere un software d intrattenimento, le texture sono solitamente già presenti sul dispositivo al momento dell avvio e quindi fornite nel formato più comodo e performante, ciò non è possibile per un geobrowser. I servizi WMS solitamente offrono la possibilità di scaricare le texture in vari formati [png, jpg, dds] tuttavia essendo il formato PVR relativamente nuovo e di nicchia non è mai presente. Non esistono quindi servizi in grado di fornire direttamente le texture compresse nel formato compatibile con il dispositivo utilizzato. Attualmente l unico modo per ottenere una texture PVRTC è quella di crearla attraverso una libreria sviluppata da Imagination Technologies, l azienda che sviluppa le GPU SGX. Comprimere una texture come quelle utilizzate dall applicazione [256x256x32bit] risulta essere estremamente pesante. Oltre a richiedere circa 30MB di memoria il processo impiega circa due secondi se eseguito su CPU intel a 2GHz. Questo, comporta che, anche esistesse una libereria per eseguire la compressione sul dispositivo, il tempo per eseguire il processo sarebbe troppo elevato, più di 10 secondi per un singolo tile. Per questo è stata sviluppata una servlet di compressione da utilizzare anche come primo livello di cache. Lo Z-Buffer, il limite dei 16 bit Uno dei problemi delle specifiche OpenGL ES 2.0 è la precisione dello Z-Buffer limitata a 16 bit. Lo Z-Buffer è un buffer creato per tenere traccia di cosa è stato disegnato sullo schermo dalla GPU. 32

33 Problemi Riscontrati Figura 31 - Esempio di Z-Fighting tra 2 piani Lo Z-Buffer, se attivato, ha la stessa risoluzione del render buffer corrente e solitamente può essere usato a precisioni multiple. Già da molto tempo sui dispositivi desktop, secondo le specifiche OpenGL e DirectX più aggiornate, è possibile scegliere tra Z-Buffer a 24b e Z-Buffer a 16b. All inizio del rendering di ogni frame la scheda grafica esegue una pulitura dello Z-Buffer assegnando a tutti i pixel il valore 0. Prima che la GPU inizi a calcolare il colore di un pixel, fa un controllo tra la profondità di quel pixel e quella del pixel salvato sullo Z-Buffer; solo se la profondità è minore, la GPU va a calcolare e salvare il nuovo colore altrimenti salta il calcolo. Se il pixel è effettivamente calcolato e salvato sul render buffer, allora anche lo Z-Buffer è aggiornato con la nuova profondità. Com è ovvio che sia uno Z-Buffer a 16 bit per pixel permette di avere 2^16 piani di disegno. La precisione spaziale finale dipende poi dal frustum della telecamera; più precisamente dalla distanza tra near e far plane definiti nella matrice di proiezione. Se due triangoli o facce condividono la stessa profondità, allora avviene un fenomeno detto Z-Fighting (Vedi Figura 11). Per combattere questo fenomeno si può intervenire su più fronti. Solitamente si va ad aumentare la precisione a 24 bit, operazione che, sulle GPU odierne, ha un impatto sulle prestazioni quasi nullo. Tuttavia le specifiche OpenGL ES 2.0 prevedono solo lo Z- Buffer a 16 Bit. In un applicazione come un geobrowser, il range di profondità e la precisione necessaria sono enormi. Questo può causare un fenomeno tra un tile e le sue skirts. Un altra operazione che può migliorare la situazione è di avere un