Sei sulla pagina 1di 121

` di Ingegneria dellinformazione, Facolta Informatica e Statistica

Tesi di Laurea Magistrale in

Ingegneria Informatica

Simulazione interattiva di corpi deformabili su piattaforma mobile

Relatore

Candidato

Prof. Marco Fratarcangeli

Antonio Passarella

Anno Accademico 2011/2012

Ringrazio cordialmente il mio relatore, Prof. Marco Fratarcangeli per la sua disponibilit` a, la sua pazienza nei lunghi ricevimenti e per tutte le nozioni che mi ha trasmesso e di cui sicuramente far` o buon uso in futuro. Un ringraziamento sincero e pi` u che sentito va alla mia famiglia che mi ha consentito di studiare e mi ` e stata accanto sopportando le ansie e i timori e aiutandomi nei tanti momenti di bisogno. Ai miei nonni, che mi hanno cresciuto e non hanno mai mancato di farmi sentire il loro aetto e la loro vicinanza. A Miriam, che mi ha sempre supportato in ogni mia scelta e mi ` e stata accanto durante tutto il mio percorso di studi regalandomi pi` u di un sorriso nei momenti dicili. Ringrazio con aetto tutti i miei colleghi, in particolare Roberto per la forte amicizia che ci lega, per la sua simpatica compagnia e per avermi fatto da cicerone in pi` u di unoccasione nella metropoli romana. Ad Angela, Andriy ed Alessandro per la loro preziosa amicizia, per aver condiviso le gioie della carriera universitaria e aver arontato insieme le tante sde e, immancabilmente, per avermi donato il loro aiuto senza esitazione. Un caloroso ringraziamento va ai miei amici, soprattutto Davide per le lunghe chiacchierate, la sua cucina e la compagnia a casa. A Nando, Miki, Daniela e Laura che mi hanno aiutato a distrarre dallo studio, a divertirmi e a non dimenticare troppo la mia citt` a natale. Ai miei amici di infanzia, a Nicola e ai miei ex compagni di scuola con cui spesso mi sono ritrovato, e ai miei ex coinquilini Luigi, Michele e Daniele, per la loro simpatia, il loro sostegno e le indimenticabili serate prima degli esami.

Abstract In questa tesi viene presentato un framework che simula il comportamento di oggetti deformabili. La simulazione ` e sviluppata su piattaforma mobile per dimostrare linterattivit` a che lalgoritmo proposto garantisce nonostante la mole di dati, i calcoli da eettuare in tempo reale e le risorse limitate dei dispositivi mobili. I corpi sono composti da particelle e vincoli di diversa natura che assicurano la deformabilit` a tipica degli oggetti che si desidera simulare. Il movimento dei vari punti ` e gestito dalla dinamica basata sulle posizioni che permette alti livelli di manovrabilit` a e controllabilit` a. Il risultato ` e una simulazione visibilmente plausibile, utilizzabile in applicazioni interattive e molto adattabile anche in scenari con oggetti che presentano caratteristiche e comportamenti diversi. La piattaforma mobile non limita luso di questa tecnica e garantisce comunque un interazione real-time ecace e realistica.

Abstract In my work its presented a framework that simulates the behaviour of deformable objects. The simulation is developed on mobile platform in order to demonstrate the interactivity that the proposed algorithm guarantees despite the amount of data, real-time calculations and resource constraints of mobile devices. The bodies are composed by particles and constraints of dierent types to ensure the typical deformability of the objects. The movement of the various points is managed with the position based dynamics that allows high levels of controllability. The result is a simulation that is usable in interactive applications and very adaptable, even in scenes with objects that have dierent characteristics and behaviors. The mobile platform does not limit the use of this technique and however it guarantees a real-time eective and realistic interaction.

Indice
1 Introduzione 1.1 Lidea . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Contesto e soluzioni . . . . . . . . . . . . . . . . . . . . 1.2.1 Visualizzazione della mesh su dispositivo mobile 1.2.2 Interazione dellutente . . . . . . . . . . . . . . 1.2.3 Modello di simulazione proposto . . . . . . . . . 1.3 Struttura della tesi . . . . . . . . . . . . . . . . . . . . 2 Background 2.1 Background teorico . . . . . . . . . . . . . . . . 2.1.1 Mesh . . . . . . . . . . . . . . . . . . . . 2.1.2 Manipolazioni naturali: Arcball . . . . . 2.1.3 Simulazione di un sistema sico . . . . . 2.2 Background software . . . . . . . . . . . . . . . 2.2.1 MeshLab . . . . . . . . . . . . . . . . . . 2.2.2 3D Studio Max . . . . . . . . . . . . . . 2.2.3 Simulazione sica con plugin con Blender 3 Aspetti teorici 3.1 Ambiente di sviluppo . 3.2 Gesture di pinch . . . 3.3 Rotazione con Arcball 3.3.1 Quaternioni . . 3.3.2 Funzionamento Mappatura sulla sfera 1 2 3 3 6 7 8 10 10 10 12 14 19 19 21 22 23 23 25 27 28 29 29

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . 4

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3.4

Calcolo della rotazione corrente . . . . . . . . . . . . . . . Aggiornamento della rotazione globale . . . . . . . . . . . Simulazione di corpi deformabili . . . . . . . . . . . . . . . 3.4.1 Metodo mass-spring . . . . . . . . . . . . . . . . . 3.4.2 Struttura degli oggetti . . . . . . . . . . . . . . . . 3.4.3 Vincoli strutturali . . . . . . . . . . . . . . . . . . . Lista degli edge . . . . . . . . . . . . . . . . . . . . . . . . Funzione di hash . . . . . . . . . . . . . . . . . . . . . . . Vincoli di distanza . . . . . . . . . . . . . . . . . . . . . . Vincoli di volume . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Interazione dellutente: risultati della deformazione 3.4.5 Picking . . . . . . . . . . . . . . . . . . . . . . . . . Trasformazioni inverse . . . . . . . . . . . . . . . . . . . . Indicizzazione 3D allinterno di una griglia . . . . . . . . . Calcolo delle distanze . . . . . . . . . . . . . . . . . . . . Vincolo di picking . . . . . . . . . . . . . . . . . . . . . . 3.4.6 Schema generale . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

30 30 32 32 34 35 35 36 37 41 43 45 47 51 55 57 59 62 62 63 64 67 67 69 69 71 72 73 74 76 77 78

4 Implementazione 4.1 Strumenti utilizzati . . . . . . . . . . . . . . . . . . 4.2 Struttura dellapplicazione . . . . . . . . . . . . . . 4.2.1 Componenti chiave: Activity . . . . . . . . . 4.2.2 Il le Manifesto . . . . . . . . . . . . . . . . 4.2.3 Risorse dellapplicazione . . . . . . . . . . . 4.3 Graca 3D su dispositivi mobili . . . . . . . . . . . 4.3.1 Vertex Buer Object . . . . . . . . . . . . . 4.3.2 Integrazione delle API di OpenGL ES . . . . 4.4 La libreria Min3D . . . . . . . . . . . . . . . . . . . 4.4.1 Moduli software . . . . . . . . . . . . . . . . 4.4.2 RendererActivity . . . . . . . . . . . . . . . 4.4.3 Supporto alle texture, allilluminazione e agli 4.4.4 Limiti . . . . . . . . . . . . . . . . . . . . . 4.5 Sviluppo . . . . . . . . . . . . . . . . . . . . . . . . 5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . shader . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

4.5.1 Avvio dellapplicazione . . . . . . . . . 4.5.2 Caricamento dei le . . . . . . . . . . . 4.5.3 Fase di parsing . . . . . . . . . . . . . 4.5.4 Visualizzazione del modello al centro di 4.5.5 Sviluppo della simulazione sica . . . . Soddisfacimento dei vincoli . . . . . . . . . . Picking . . . . . . . . . . . . . . . . . . . . . 4.5.6 Gestione dellinput . . . . . . . . . . . 4.5.7 Men` u e preferenze . . . . . . . . . . . Preferenze sulle texture . . . . . . . . . . . . Preferenze di disegno . . . . . . . . . . . . . Preferenze sulla rotazione . . . . . . . . . . . Impostazione dei parametri della simulazione Salvataggio dello stato . . . . . . . . . . . . .

. . . . . . . . . vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

78 79 80 81 81 81 82 83 84 86 87 88 89 90

5 Test e risultati 91 5.1 Analisi delle prestazioni . . . . . . . . . . . . . . . . . . . . . 91 5.1.1 Occupazione di memoria primaria . . . . . . . . . . . . 92 5.1.2 Tempo della fase di parsing . . . . . . . . . . . . . . . 92 5.1.3 Tempo per il picking . . . . . . . . . . . . . . . . . . . 93 5.1.4 Tempo per uno step di risoluzione dei vincoli . . . . . . 93 5.2 Eetti della simulazione . . . . . . . . . . . . . . . . . . . . . 95 5.2.1 Simulazione 1: assenza delleetto dei vincoli . . . . . . 95 5.2.2 Simulazione 2: indipendenza delle due tipologie di vincolo 97 5.2.3 Simulazione 3: variazione del parametro di tipo distance 97 5.2.4 Simulazione 4: variazione del parametro di tipo pressure 98 5.2.5 Simulazione 5: inuenza dei vincoli su una mesh complessa . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.2.6 Simulazione 6: ritorno alla forma originale . . . . . . . 101 5.2.7 Simulazione 7: eetti su una mesh composta da pi` u oggetti . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6 Conclusioni 104 6.1 Lavori futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Bibliography 107

Elenco delle gure


1.1 1.2 1.3 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 Multi-platform development . . . . . . . . . . . . . . . . . . . Architettura del sistema Android . . . . . . . . . . . . . . . . Esempio di deformazione . . . . . . . . . . . . . . . . . . . . . Arcball . . . . . . . . . . . . . . . . . Ragdoll . . . . . . . . . . . . . . . . Angoli di piega degli edge . . . . . . Simulazione ottenibile con il lavoro di MeshLab su PC . . . . . . . . . . . . MeshLab sul mobile . . . . . . . . . . 3D Studio Max . . . . . . . . . . . . Simulazione tramite plugin . . . . . . . . . . . . . . . . . . Muller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 8 13 16 16 17 19 20 21 22 25 26 27 29 33 34 35 37 41 43 44 47 50

Pipeline delle trasformazioni in OpenGL Pinch to zoom . . . . . . . . . . . . . . . Drag sullArcball . . . . . . . . . . . . . Mappatura sulla sfera . . . . . . . . . . . Struttura Mass-Spring . . . . . . . . . . Struttura Mass-Spring su tessuto . . . . Edge e facce di una mesh . . . . . . . . . Risoluzione di un vincolo di tipo distance Rilassamento iterativo dei vincoli . . . . Eetto dei vincoli sul volume . . . . . . Esempio di interazione con lutente . . . Ray picking . . . . . . . . . . . . . . . . Trasformazione della retta di picking . . 8

3.14 3.15 3.16 3.17 3.18 3.19 3.20 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 5.1 5.2 5.3 5.4 5.5 5.6 5.7

Dierenza nelle coordinate dello schermo . . . . . . . . . . . Griglia 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mapping della retta sulla griglia. . . . . . . . . . . . . . . . Ray picking su griglia 2D . . . . . . . . . . . . . . . . . . . . Selezione dei vertici errata . . . . . . . . . . . . . . . . . . . Spostamento del vertice per il vincolo di picking . . . . . . . Schema generale del funzionamento del sistema mass spring

. . . . . . .

51 52 53 55 56 58 59 65 68 74 76 79 80 84 85 86 87 88 88 89 96 97 98 99 100 102 103

Ciclo di vita di un Activity . . . . . . . . . . . . . . . . . . . . Struttura della memoria secondaria di un device Android . . . Moduli software della libreria Min3D . . . . . . . . . . . . . . Thread in esecuzione durante la visualizzazione . . . . . . . . Schermata visualizzabile allavvio del software . . . . . . . . . Interfaccia graca per linserimento dei path di modello e texture Disegno dellArcball . . . . . . . . . . . . . . . . . . . . . . . . Men` u dellapplicazione . . . . . . . . . . . . . . . . . . . . . . Schermata delle impostazioni . . . . . . . . . . . . . . . . . . Preferenze sulle texture . . . . . . . . . . . . . . . . . . . . . . Scelta della modalit` a di disegno della mesh . . . . . . . . . . Opzione di rotazione . . . . . . . . . . . . . . . . . . . . . . . Cambio dei parametri della simulazione . . . . . . . . . . . . . Simulazione Simulazione Simulazione Simulazione Simulazione Simulazione Simulazione 1 2 3 4 5 6 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Elenco delle tabelle


5.1 Analisi prestazionale: confronto tra tre modelli diversi . . . . . 92

10

Capitolo 1 Introduzione
Negli ultimi anni si ` e assistito ad una evoluzione e diusione importante di smartphone e tablet, dispositivi che hanno ottenuto sempre maggiore rilevanza nella vita quotidiana e che a volte si sostituiscono ai pi` u performanti PC grazie alla loro praticit` a. Le moderne tecnologie hanno portato allo sviluppo di processori e schede grache sempre pi` u performanti da integrare in tali dispositivi. Larchitettura ARM in particolare ha permesso di orire velocit` a di elaborazione di rilievo dove il risparmio energetico ` e fondamentale. In concomitanza con lo sviluppo hardware anche lo sviluppo software ha avuto una piega importante. Fino a pochi anni fa le software house si concentravano nello sviluppo su PC o sulle console per videogiochi, ma il nuovo mercato aperto dagli smartphone ha indotto a sviluppare applicazioni di rilievo per questo tipo di architettura. Il bacino di utenza a cui il software pu` o arrivare ` e davvero vasto e chiaramente ci` o allarga il business e linteresse. Sorge quindi una nuova propensione nello sviluppo che porta con s` e non pochi problemi legati alla natura stessa di tali dispositivi. Il risparmio energetico e lattenzione quindi nel consumo delle risorse sono un fattore da non tralasciare se si vuol diondere il pi` u possibile la propria applicazione. I nuovi mercati virtuali per applicazioni fanno il resto e possono contribuire al successo del software grazie anche a nuove forme di pubblicit` a. Oggi tra i sistemi operativi pi` u diusi per tali terminali si trova Android [1], sviluppato dalla nota Google, che ha la particolarit` a di essere open

source rispetto agli altri sistemi come iOs della Apple e Windows Phone della Microsoft. Android pu` o essere impiegato su diversi dispositivi, che dieriscono per tipo e potenza hardware. La versatilit` a di tale sistema ne ha decretato il successo in pochi anni e tuttora ci sono milioni di attivazioni ogni giorno. Come gli altri sistemi, Android permette di sfruttare tutta la potenza hardware dei device e fornisce supporto alle applicazioni grache grazie ad una delle librerie grache pi` u diuse in questo ambito, ossia OpenGL ES [2]. Negli ultimi anni si pu` o osservare come linformatica graca abbia assistito ad un notevole sviluppo, soprattutto nella realizzazione di animazioni interattive credibili per la creazione di eetti speciali e lm di animazione, grazie sia a societ` a che sviluppano videogiochi che a societ` a che si interessano di ricerca medica o comunicazioni. Lobiettivo ` e sempre stato quello di riprodurre simulazioni sempre pi` u attendibili curando con grande attenzione i dettagli. Col tempo nascono nuovi algoritmi e tecniche di programmazione che permettono di spostare verso la qualit` a graca quella linea virtuale che ha sempre indicato il giusto compromesso tra velocit` a di esecuzione (fps) e particolari da rappresentare. La nuova frontiera risulta sicuramente lapplicazione sulle piattaforme mobili di tecniche e metodologie di sviluppo studiate e implementate su computer. Le caratteristiche di tali device descritte in precedenza, in particolare la limitazione nelle risorse disponibili e linterazione real-time dellutente, sono un esempio delle sde da arontare nello sviluppo su queste nuove piattaforme.

1.1

Lidea

La libreria graca OpenGL ES integrata nei framework disponibili per le piattaforme mobili consente ladozione di tecniche e algoritmi dellinformatica graca nello sviluppo. Loggetto di questa tesi ` e proprio un applicazione graca che sappia mettere in mostra da un lato le capacit` a di tali dispositivi e dallaltro le tecniche di programmazione utili a implementare metodologie studiate da anni su computer che orono performance notoriamente maggiori. Il lavoro, sviluppato per sistema Android, permette la visualizzazione realtime di oggetti 3D rappresentati tramite la lettura di mesh poligonali salvate 2

su le. Lutente pu` o direttamente interagire con il modello visualizzato oltre che accedere a varie impostazioni di disegno dello stesso. Al di l` a di queste operazioni utili ma non cos` signicative, si vuole implementare una tecnica per simulare i corpi deformabili. La mesh ` e arricchita di vincoli strutturali che consentono di modicarne la forma senza stravolgere lintero corpo. Il metodo solitamente utilizzato nella computer graca per simulare un sistema sico ` e quello di sommare le forze interne e quelle esterne e, da queste, calcolare le accellerazioni in base alla seconda legge della dinamica di Newton. In seguito viene applicato un passo di integrazione per calcolare le velocit` a dalle accellerazioni e le posizioni dalle velocit` a. In questa tesi, invece, si utilizza un algoritmo basato sulle posizioni. Il maggior vantaggio che si trae da questa scelta ` e quello di lavorare direttamente sulle stesse. Aggiornando le posizioni delle varie particelle di cui si compone loggetto si pu` o controllare e manovrare direttamente i vincoli che determinano la simulazione. Al contrario della sica che nei calcoli punta sulla precisione e sullesattezza, nella computer graca gli obiettivi pi` u importanti sono la stabilit` a, la robustezza, la velocit` a di calcolo e un risultato che sia visibilmente pi` u che plausibile e questo metodo consente di abbracciare tale losoa. Infatti lapproccio utilizzato ` e ottimo nelle simulazioni che richiedono un elevato fps come videogames o simulazioni in tempo reale, perch` e garantisce una notevole velocit` a di esecuzione. Le caratteristiche della dinamica basata sulle posizioni sono ottime quindi anche per il realizzarsi della simulazione su piattaforma mobile.

1.2
1.2.1

Contesto e soluzioni
Visualizzazione della mesh su dispositivo mobile

La simulazione sica ` e realizzata su una mesh poligonale, per cui si rende necessario caricare e visualizzare correttamente la mesh. Lobiettivo nale non risulta essere la modica di tali modelli dal dispositivo, ma esclusivamente una loro visualizzazione. Il motivo ` e indicato dal fatto che tali terminali sono 3

spesso un utile sostituto del computer su cui ` e possibile realizzare software pi` u completi e performanti in grado di gestire tali compiti. Il parsing e la visualizzazione sono possibili attraverso diverse librerie grache di terze parti disponibili nel settore mobile. Si ` e analizzato in particolare un possibile impiego di tre librerie: EdgeLib [3], Marmalade [4] e Min3D [5]. Pi` u in dettaglio le prime due sono utili per creare applicazioni multi piattaforma. Per i motivi precedentemente citati ci` o pu` o essere un obiettivo fondamentale per diondere il software negli store dei principali sistemi operativi mobili, il bacino di utenza risulta chiaramente maggiore. I framework elencati sono vantaggiosi in tal senso poich` e la scrittura dellapplicazione avviene con un unico linguaggio di programmazione. Sar` a poi il tool di compilazione fornito a generare la build adatta al sistema in uso, con evidenti dierenze se larchitettura del processore sia di tipo ARM (mobile) o x86 (tipica architettura da computer).

Figura 1.1: Multi-platform development con EdgeLib: lo stesso codice in esecuzione su sistema Android a sinistra e su sistema Windows a destra

EdgeLib ` e una libreria oggi poco supportata e quindi lo sviluppo ` e relativamente dicoltoso, soprattutto se si considera che oggi il sistema Android ` e ancora in sviluppo e le nuove release si dierenziano notevolmente dalle precedenti. Dierentemente Marmalade risulta pi` u supportata in quanto il suo uso non ` e libero ma soggetto ad acquisto di licenza. Entrambe sono sviluppate in codice C++, dierentemente da Min3D che ` e basata su codice Java. Ci` o mette in luce la doppia natura di Android: tale sistema operativo ` e costituito da un Kernel basato sul sistema operativo Linux, con middleware, 4

librerie e API scritti in C, e software in esecuzione su un framework di applicazioni che include librerie Java. Android usa una Dalvik virtual machine per eseguire codice derivato dal bytecode delle applicazioni scritte in Java.

Figura 1.2: Architettura del sistema Android

Lo sviluppo ` e possibile, quindi, con entrambi i linguaggi ma la programmazione con linguaggio Java ` e facilitata dalle API messe a disposizione dal SDK (Software Development Kit). Google incita la scrittura di applicazioni proprio in questo linguaggio data ladabilit` a e le prestazioni fornite dalla macchina virtuale implementata. EdgeLib e Marmalade sono state testate a fondo al ne di comprendere i reali vantaggi di uno sviluppo a basso livello. Infatti entrambe lavorano direttamente con il kernel di Android senza essere eseguite nella Dalvik virtual machine. Non ` e possibile eseguire quindi le API Java del SDK Android,

piuttosto tali framework orono propri metodi per accedere alle risorse del dispositivo. Si nota comunque una minore completezza software rispetto al SDK, ad esempio EdgeLib sore della mancanza di supporto al multi-touch, ossia al tocco contemporaneo in pi` u parti dello schermo del dispositivo. Tale mancanza porta alla creazione di applicazioni che nonostante abbiano il vantaggio di essere eseguibili su piattaforme diverse, hanno interfacce dicoltose da gestire. Si ` e preferito quindi uno sviluppo su Java con la libreria Min3D dato il supporto oerto dal SDK e dato che le prestazioni non decadono eccessivamente nonostante il codice sia eseguito nella macchina virtuale grazie allottimizzazione dellintero sistema. Min3D ` e open source e quindi il suo codice ` e stato interamente inglobato nellapplicazione. La libreria consente il caricamento di mesh poligonali salvate in diversi tipi di le. Il suo funzionamento verr` a dettagliato in seguito.

1.2.2

Interazione dellutente

Ottenuta la visualizzazione e il caricamento si ` e proceduto allo studio dellinterazione dellutente in modo che si possa ruotare, ingrandire, rimpicciolire o deformare la mesh. La particolarit` a dei dispositivi su cui il software verr` a eseguito ` e lorire metodologie di input diverse dai classici mouse e tastiera utilizzati su computer. La gestione dellinput mette in primo piano luso del display touch-screen di cui smartphone e tablet dispongono. Si ` e inserito quindi il supporto alle gesture eseguibili sul display per qualsiasi operazione da eettuare sulloggetto rappresentato. La rotazione delloggetto in tre dimensioni ` e stata ottenuta attraverso limplementazione di un Arcball. Questultima ` e una tecnica molto utilizzata nella computer graca oggi. Essa permette una rotazione naturale e libera da eventuali vincoli legati al fatto che si vuole gestire un movimento in tre dimensioni quando linput ` e in sole due dimensioni. Lo zoom ` e possibile attraverso il movimento ormai brevettato del cosiddetto pinch. Tale gesture si serve di due tocchi simultanei del display e

mette in luce come lusabilit` a possa migliorare attraverso lo schermo tattile. La deformazione, inne, viene gestita attraverso un drag sul display, ossia un trascinamento del tocco da una parte ad un altra dello schermo.

1.2.3

Modello di simulazione proposto

E stata creata unapplicazione che simula linterazione tra corpi deformabili. Il modello proposto si basa su oggetti realizzati da sistemi di particelle legate tra loro da vincoli strutturali. La mesh viene quindi arricchita di vincoli sui propri edge (lati), su ognuno la distanza tra i due vertici collegati non pu` o variare. La tipologia di tali vincoli ` e denita stretching ed in eetti essi simulano lelasticit` a delloggetto. Oltre a tali vincoli si inserisce un vincolo denito di overpressure che limita il volume del corpo. La presenza di un vincolo sul volume fa in modo che la mesh possa essere s` modicata ma ritorner` a comunque al suo volume originario. Lutente pu` o deformare la mesh selezionando ad esempio un vertice delloggetto e trascinandolo in una direzione. Lo spostamento implica la creazione del cosiddetto vincolo di picking che determina una traslazione del vertice interessato nella direzione del trascinamento. Durante questa operazione i restanti vincoli strutturali continuano a valere e determinano quindi la particolare simulazione della deformabilit` a delloggetto. Alla rimozione dei vincoli sul trascinamento i restanti vincoli sulla lunghezza degli edge e sul volume eventualmente violati vengono risolti in maniera iterativa in diversi istanti temporali nch` e non si raggiunge una congurazione stabile.

Figura 1.3: Esempio di deformazione ottenibile con la simulazione sviluppata

1.3

Struttura della tesi

Capitolo 2 Sono citate le tecniche e gli algoritmi attualmente utilizzati nel settore dove la tesi ha sbocco. I lavori teorici descritti sono serviti come utile base per la creazione dellapplicazione. Inoltre sono elencati i software di rilievo, disponibili sia nel panorama Android che in altri sistemi, che sono stati utili come metro di paragone nei primi step di sviluppo. Capitolo 3 Si descrivono dettagliatamente gli algoritmi e le metodologie adottati nello sviluppo. In particolare si pone in risalto lapproccio matematico necessario per la comprensione di tecniche come lArcball e si deniscono in modo esaustivo tutte le nozioni riguardanti la simulazione di corpi deformabili. Capitolo 4 Sono presentati tutti i dettagli relativi allimplementazione. Oltre al focus sulla realizzazione pratica delle tecniche precedentemente 8

elencate si descrive il funzionamento della libreria e la connessione realizzata con gli strumenti del SDK Android. In tal modo si vuole mostrare anche la realizzazione della gestione dellinput e dellinterfaccia utente. Capitolo 5 Si mostrano test e risultati dellimplementazione della simulazione su piattaforma Android. Sono denite le tempistiche necessarie per eettuare le principali operazioni in cui ` e suddivisa la simulazione sica, oltre che le risorse in termini di memoria necessarie per garantire il funzionamento del software. In pi` u si riportano i risultati della simulazione su oggetti dalla forma diversa, mettendo in risalto i cambiamenti nella loro struttura a causa del cambio dei parametri che condizionano la deformazione. Capitolo 6 Sono inne presentate le conclusioni adottando un approccio critico verso il lavoro realizzato per meglio mettere in luce sia i limiti che i vantaggi degli approcci utilizzati.

Capitolo 2 Background
In questo capitolo sar` a fatta una panoramica generale delle tecniche attualmente utilizzate in diversi settori come ad esempio lo sviluppo di videogiochi e lanimazione cinematograca, settori ai quali questa tesi in diversi modi si va a collegare. In particolare si mostra lo stato dellarte ossia quei lavori che sono serviti come fonte di ispirazione spiegando le eventuali dierenze di utilizzo, i vantaggi e gli svantaggi. Oltre ai lavori teorici si far` a riferimento anche ad applicazioni gi` a disponibili che sono state utilizzate per analizzare le funzioni da implementare.

2.1
2.1.1

Background teorico
Mesh

Una mesh poligonale, anche detta maglia poligonale, ` e una collezione di vertici, lati e facce che deniscono la forma di un oggetto poliedrico nella computer graca 3D e nella modellazione solida [6]. Le facce consistono solitamente di triangoli, quadrilateri od altri semplici poligoni convessi, dal momento che ci` o semplica il rendering. Lo studio di mesh poligonali ` e un grande sotto-campo della computer graca e le diverse rappresentazioni sono utilizzate per molte applicazioni e con diverse nalit` a. Sono stati creati algoritmi per il Ray tracing, il collision detection, e la simu10

lazione di corpi rigidi o corpi deformabili che possono essere applicati a tali rappresentazioni poligonali di oggetti tridimensionali. Le mesh poligonali possono essere rappresentate in diversi modi, utilizzando diverse strutture dati. Alcuni esempi sono i seguenti: Face-vertex mesh: una semplice lista di vertici e un insieme di facce che puntano ai vertici che formano il poligono. Winged-edge mesh, in cui ogni edge punta a due vertici, due facce, e ai quattro (in senso orario e antiorario) edge (lati) che toccano le facce a cui esso appartiene. Questo tipo di strutturazione dei dati permette un tempo costante di attraversamento della mesh, ma richiede una quantit` a maggiore di dati da memorizzare [7]. Half-edge mesh: simile al precedente, ma possiede solo la met` a delle informazioni riguardo ogni edge dato che questultimo ` e considerato direzionato e le informazioni riguardano una sola direzione [8]. Quad-edge mesh: vengono memorizzati solo gli edge, gli half-edge e i vertici senza considerare i poligoni. Questultimi sono impliciti nella rappresentazione, e si possono ottenere attraversando la struttura. I requisiti di memoria sono simili alle half-edge mesh [9]. Corner-tables: memorizzano i vertici in una tabella predenita, in modo che scorrendo le informazioni nella tabella si possano ottenere i poligoni rappresentati implicitamente. La rappresentazione ` e pi` u compatta e pi` u eciente, ma le operazioni di modica sono lente. Inoltre, questo tipo di struttura non rappresenta la mesh completamente [10]. Vertex-vertex mesh: una mesh VV rappresenta solo i vertici, che puntano ad altri vertici. Sia ledge e le informazioni sulla faccia sono implicite nella rappresentazione. La semplicit` a di tale strutturazione consente di svolgere con maggiore ecienza diverse elaborazioni [11]. La scelta della struttura dati viene fatta in base allapplicazione che utilizza tali dati, le prestazioni richieste, la dimensione dei dati, e le operazioni 11

da eseguire. Ad esempio ` e pi` u facile utilizzare triangoli piuttosto che altri poligoni, soprattutto in geometria computazionale. Per certe operazioni ` e necessario avere un accesso rapido alle informazioni e questo richiede strutture pi` u complesse come le winged-edge mesh. Per il rendering hardware sono necessarie strutture semplici e di conseguenza le corner-tables sono comunemente incorporate in API di basso livello per il rendering come DirectX ed OpenGL. La rappresentazione utilizzata in questa tesi ` e simile alla prima della lista (Face-Vertex Mesh) dato che ` e la pi` u diusa e la pi` u semplice da analizzare. La scelta ` e motivata anche dal tipo di le che lapplicazione sviluppata supporta ossia le di estensione OBJ [12]. Tale formato ` e molto comune e utilizzato in particolare per denire le geometrie 3D grazie alla sua natura open. La struttura del le ` e molto semplice e permette di denire le posizioni dei vertici, le normali, le facce, le coordinate texture. I vertici sono memorizzati in un ordine orario in modo da rendere lesplicitazione delle normali non necessaria. Al le ` e spesso allegato un le di tipo MTL [13] che specica i materiali e le texture della mesh.

2.1.2

Manipolazioni naturali: Arcball

Una volta che la mesh ` e caricata e visualizzata ` e possibile applicarvi numerose trasformazioni geometriche sfruttando la pipeline graca. Alcune trasformazioni come la rotazione sono calcolabili indipendentemente dal modello e sono soggette ad altri fattori quali ad esempio linput dellutente. Larticolo di Shoemake [14] mostra una tecnica che fa uso di una cosiddetta Arcball per la rotazione, molto utile per gestire dispositivi di input il cui movimento ` e limitato in due dimensioni. Nel suo lavoro si fa riferimento ad un mouse, ma le stesse considerazioni possono essere applicate ad altri dispositivi di input quali touch-pad o touch-screen. Nelle scene 3D simulate, lorientamento degli oggetti rispetto alla camera di vista pu` o cambiare durante lesecuzione e in alcuni casi si vuole permettere allutente di interagire direttamente con la rotazione delloggetto. Fin dai primi anni 90 si ` e riettuto su come ottenere una tecnica che permetta di

12

ovviare alla limitatezza dei dispositivi di input. Si pensi ad esempio al lavoro di Chen et all. [15] in cui si prospetta un metodo con cui si seleziona un asse di rotazione e quindi si eettua il cosiddetto dragging per ruotare, ossia si trascina linput in una singola direzione mantenendo un click sulloggetto. Questultimo verr` a ruotato secondo la direzione di trascinamento. Il lavoro di Shoemake ` e innovativo e dierente dai precedenti poich` e introduce alcuni fondamenti matematici gi` a studiati [16], [17], [18], con i quali ` e possibile calcolare le giuste rotazioni di un oggetto senza ssare un asse di rotazione. La tecnica pu` o essere spiegata in modo visuale in modo molto semplice: si pu` o pensare ad una sfera che racchiude il corpo da ruotare. Lutente che vuole ruotare il corpo non deve far altro che disegnare un arco sulla sfera, che dovr` a ruotare nella direzione e di un angolo che dipendono dallarco stesso. Larco ` e chiaramente disegnato sullo schermo (con un dragging su di esso) e quindi deve essere proiettato sulla sfera.

Figura 2.1: Rappresentazione visuale di un Arcball e dellarco di rotazione

Le rotazioni nello spazio sono spesso molto complesse e si compongono di multiple rotazioni su assi dierenti [19]. La tecnica in questione permette di evitare la complessit` a nei calcoli attraverso dei principi matematici noti, che inoltre rendono il movimento semplice ed intuitivo per lutente.

13

2.1.3

Simulazione di un sistema sico

Al di l` a di rotazioni, traslazioni o scaling il software oggetto di questa tesi permette anche una deformazione della mesh. La deformazione ` e ottenibile simulando il comportamento di corpi che in natura sono etichettati come deformabili. Quando si parla di questa tipologia si pensa sempre a corpi pieghevoli, di gomma o elastici. Il comportamento di tali oggetti ` e estremamente complicato da simulare in quanto implica il calcolo delle nuove posizioni di ogni particella che compone il corpo. In aggiunta il livello di deformabilit` a viene deciso dai vincoli che tengono unite le particelle. Questi vincoli devono essere rispettati in ogni step della simulazione aumentando notevolmente la complessit` a di calcolo. Fino a poco pi` u di 10 anni fa la simulazione dinamica di tessuti e corpi deformabili non era richiesta n` e nelle produzioni cinematograche n` e in quelle dei videogames. In passato questo tipo di oggetto era rappresentato come un corpo rigido che al massimo presentava dei comportamenti prestabiliti per farlo sembrare deformabile. Nonostante tutto esistevano gi` a diversi metodi per simulare ad esempio tessuti liberi di muoversi come in [20], [21], [22], [23], ma non erano sviluppate tesi che riguardassero una reale implementazione di modelli simulativi per corpi deformabili o collisioni di tali corpi con altri oggetti. Oggi, invece si applicano algoritmi sempre pi` u robusti per gestire tali oggetti come insieme di particelle distinte. In termini elaborativi, si introduce una notevole complessit` a ma i vantaggi di tale tecnica hanno indotto a studiare diversi metodi per la realizzazione, i pi` u validi sono illustrati nella relazione sullo stato dellarte [24]. Gli autori presentano due categorie principali per gli approcci adottabili: quelli che sfruttano la tecnica di Lagrange, dove i modelli sono costituiti da insiemi di punti con diverse posizioni e caratteristiche, e quelli che usano i metodi di Eulero, che basa il calcolo delle propriet` a dei modelli su un insieme di punti stazionari. In particolare hanno preso il sopravvento algoritmi basati sulla posizione appartenenti alla prima categoria sopra descritta. Il vantaggio di tali algoritmi risiede nel lavorare direttamente sulla posizione dei singoli vertici, garantendo una minore insta-

14

bilit` a rispetto ad altre tecniche. Nella computer graca e, soprattutto, nei giochi per computer ` e importante poter avere un controllo diretto con i vertici di una mesh. Infatti potrebbe essere necessario evitare che un vertice penetri in un oggetto imponendogli di rimanere allesterno del corpo con cui la particella collide; oppure potrebbe essere importante attaccare un vertice ad altri oggetti in movimento nella simulazione. La dinamica position-based permette di avere un controllo diretto durante tutta la simulazione evitando cos` problemi dovuti a spostamenti eccessivi dei vertici creando una simulazione innaturale. Riassumendo sono molti i vantaggi dellutilizzo della dinamica basata sulle posizioni: permette di risolvere i problemi di instabilit` a interagendo direttamente sullapplicazione delle forze proiettando le particelle in posizioni corrette; ` e possibile agire direttamente sui vertici e sulle parti degli oggetti modicandoli direttamente durante la simulazione; gli algoritmi basati sulle posizioni sono semplici da capire e da implementare; questi tipi di algoritmi permettono di agire direttamente sui vincoli espressi sulle particelle. Thomas Jacobsen ha adottato questo approccio nel suo motore sico, descritto in [25], che usa un integratore di Verlet per calcolare lapplicazione delle forze alle particelle. Lintegrazione di Verlet [26] ` e un metodo numerico usato per integrare le equazioni del moto di Newton. Esso ore grande stabilit` a oltre che il rispetto di propriet` a importanti per un sistema sico quali la reversibilit` a temporale, ad un costo non signicativo rispetto allaltrettanto famoso metodo di Eulero. Lintegratore di Verlet ` e stato arricchito nellarticolo di Jacobsen con un sistema di gestione dei vincoli basato sulle posizioni. Ci` o ha permesso di realizzare il ragdoll che ha rappresentato lanatomia umana dei personaggi 15

presenti nel videogioco Hitman: Codename 47 [27] della IO Interactive [28]. Il sistema di vincoli presentato ` e molto ricco e prevede vincoli di diversa natura, non solo di tipo stretching. Si dimostra ad esempio come ` e possibile costruire un insieme di vincoli anti collisione per evitare che due oggetti rigidi si sovrappongano. Inoltre per simulare correttamente la creazione di un ragdoll i vincoli sono rigidi per evitare innaturali allungamenti delle parti del corpo, ma contengono anche dei prestabiliti angoli di piega (Fig. 2.3) per evitare che il ragdoll compia movimenti che il corpo umano non pu` o realizzare come ad esempio pieghe eccessive dei gomiti e delle ginocchia. Infatti i vertici in questo caso riproducono le giunture tipiche del corpo umano per permettere alloggetto di muoversi in maniera naturale.

Figura 2.2: Ragdoll rappresentante lanatomia umana

Figura 2.3: Jacobsen

Vincoli sullangolo formato da due edge descritti nel lavoro di

16

La tecnica proposta da Jacobsen ` e stata ripresa ed ampliata in vari lavori successivi. Ad esempio Fedor in [29] si concentra sullapplicare tali tecniche su oggetti dalla scheletratura simile allanatomia umana, simulandone dierenti comportamenti. Il lavoro di Muller [30] ` e riguardevole in quanto esso amplia lo studio di Jacobsen e viene utilizzato per creare tessuti. A sua volta il testo di Muller et al. si rif` a ad altri lavori precedenti come [31], [32] Lutilizzo di vincoli indipendenti permette di simulare il comportamento di tessuti con diverse caratteristiche strutturali dovute a costanti di stretching e di bending. I vincoli di bending delimitano langolo di piega tra due mesh triangolari adiacenti che compongono loggetto e quindi deniscono la rigidit` a del corpo. Oltre a ci` o gli autori di questo lavoro inseriscono altre tipologie di vincolo come quello di overpressure che controlla il cambio di volume della mesh e determina il ritorno ad un volume prossimo alloriginale dopo la deformazione. Questa tecnica permette di creare simulazioni con corpi dalle caratteristiche diverse ed animati dallo stesso algoritmo. Ci` o rappresenta un vantaggio non indierente per quei programmi, come i videogames, che possono necessitare di tessuti multipli con caratteristiche diverse simulate nello stesso ambiente.

Figura 2.4: Simulazione ottenibile con il lavoro di Muller, composizione di due corpi rigidi e un corpo deformabile su cui si costruiscono vincoli di stretching, di bending e di overpressure.

Gli approcci nora descritti vengono utilizzati anche nellindustria cinematograca ed in particolare nei lm danimazione. Infatti i tessuti vengono 17

simulati in maniera automatica attraverso un motore sico che agisce sulle particelle che compongono loggetto. In questo modo gli animatori hanno la possibilit` a di occuparsi solo di muovere il personaggio mentre tutto il resto della scena, come gli abiti indossati, vengono animati dal computer secondo le leggi della sica. Questa tecnica rende la simulazione estremamente realistica. Un esempio di applicazione ` e dato dai lm danimazione prodotti dalla Pixar [33]. Il lavoro oggetto di questa tesi mostra la facilit` a implementativa di queste tecniche e il loro realismo anche se in piccola parte rispetto a tutte le possibili applicazioni. In particolare i lavori di Muller [30] e Jacobsen [25] citati sono utilizzati come base per le conoscenze degli algoritmi utilizzabili per la simulazione. Gli algoritmi position-based si adattano bene ad oggetti la cui struttura ` e ben denita e rende possibile costruire tutto linsieme di vincoli che realizzano in pratica la simulazione. Le strutture che verranno cotruite a partire dalla mesh saranno molto pi` u complicate di un ragdoll ma si dimostrer` a che il framework riesce ad essere eciente anche con un elevato numero di vincoli.

18

2.2
2.2.1

Background software
MeshLab

La realizzazione di un lavoro di tesi di questo tipo porta ad analizzare software gi` a esistenti per studiarne le funzionalit` a e le varie caratteristiche implementate. Un esponente di spicco tra i lavori analizzati ` e MeshLab, un software di mesh processing molto conosciuto nel settore graco [34].

Figura 2.5: Workspace di MeshLab su PC Windows

MeshLab ` e open source e di libero utilizzo, uno strumento utilissimo per visualizzare mesh salvate in diversi formati di le. E stato progettato principalmente con tre obiettivi: facilit` a duso, orientamento allo scanning 3D ed ecienza. MeshLab ` e quindi stato concepito pi` u per la visualizzazione che per lediting della mesh la cui funzionalit` a` e contenuta in altri software professionali quali Blender, 3D Studio Max o Maya. Una volta che la mesh ` e caricata il software permette di lavorare su un largo set di parametri che consentono di controllare il disegno, lilluminazione 19

e le texture del modello. Oltre a tali parametri si pu` o utilizzare un Arcball per la rotazione, oltre che ingrandire o rimpicciolire la mesh. Le ultime release del software su computer introducono limportante supporto allo scanning 3D: dai dati grezzi ottenuti tramite i device di acquisizione hardware il software riesce a ricreare un modello 3D pronto alluso. Tale processo ` e ricco di dierenti algoritmi che provvedono a ricostruire le superci 3D e convertirli in facce della mesh. Grazie a questa e alle altre sue caratteristiche MeshLab ` e molto utilizzato tuttoggi e uno sviluppo su pi` u piattaforme ne aiuta sensibilmente la diusione. Lapplicazione ` e disponibile anche su piattaforma Android e ci` o dimostra come la realizzazione di tali applicazioni grache sia possibile e non condizionata da un hardware limitato come quello dei dispositivi mobili rispetto ai computer. Le funzioni disponibili sono, tuttavia, limitate rispetto alla versione Desktop e ci` o mette in luce il fatto che solitamente le caratteristiche disponibili su applicazioni mobili sono ridotte rispetto a software completi implementati per computer. Su Android in particolare il software permette di aprire la mesh, ruotarla o traslarla tramite gesture e cambiare alcune impostazioni di disegno. Tale versione risulta comunque un ottimo esempio da seguire per la costruzione dellinterfaccia, delle funzioni e della visualizzazione della mesh sul dispositivo.

Figura 2.6: MeshLab su Android

20

2.2.2

3D Studio Max

Un ulteriore software che si vuole citare ` e 3D Studio Max, il quale permette di realizzare da zero geometrie complesse in 3D. Il software ` e quindi dierente dal precedentemente descritto MeshLab in quanto ` e votato non solo alla visualizzazione di mesh ma anche alla creazione e allediting delle stesse.

Figura 2.7: Workspace di 3D Studio Max

3D Studio Max ` e un editor 3D molto potente, sviluppato dalla Autodesk [35], e risulta uno dei software pi` u utilizzati per creare geometrie 3D, denirne le superci, applicarvi animazioni, simulare la sica e usare diverse tecniche di illuminazione. Ha grandi capacit` a di modellazione e uninterfaccia molto valida. Con le ultime versioni sono state aggiunte una serie di funzionalit` a avanzate come shader, simulazione dinamica, sistemi di particelle, radiosity e linguaggio per gli script. Il software non ` e disponibile per dispositivi mobili, in qualche modo risente delle molte caratteristiche messe in gioco. La complessit` a determina quindi la scelta di limitare lo sviluppo ai computer che possono orire performance superiori. Con il progresso tecnologico, tuttavia, i dispositivi mobili potrebbero integrare ben presto tutte le feature del software su PC.

21

2.2.3

Simulazione sica con plugin con Blender

La maggior parte dei software disponibili legati al video editing di mesh poligonali non consentono di simulare il comportamento tipico degli oggetti deformabili con i metodi descritti. Tuttavia un esempio pratico pu` o essere sviluppato tramite plugin per Blender [36]. Questultimo ` e un noto software dalle funzionalit` a simili a 3D Studio Max ma con laggiunta di essere open source. Blender ore la possibilit` a di aggiungere plugin ossia codice accessorio da eseguire sulle mesh poligonali. Esistono perci` o diversi lavori che consentono di rappresentare una simulazione sica con i principi descritti in lavori come quello di Jacobsen [25] visibile nella sottostante gura. Lambiente estensibile rende quindi agevole lingresso di nuove caratteristiche speciche e la creazione di simulazioni altrimenti non direttamente incluse nella versione originale. La potenzialit` a di questo aspetto ` e stata integrata anche nelle ultime release dei principali concorrenti di questo software come il precedentemente citato 3D Studio Max.

Figura 2.8: Simulazione sica con Blender tramite plugin aggiuntivo

22

Capitolo 3 Aspetti teorici


In questo capitolo verranno arontate tutte le fasi del progetto da un punto di vista teorico, illustrando quindi le tecniche matematiche utili a raggiungere i ni previsti. Viene presentata una prima panoramica sullambiente di sviluppo e sulle caratteristiche tipiche dei device su cui il software verr` a eseguito. A seguire si mostra il funzionamento dellArcBall in maniera dettagliata introducendo tutte le nozioni matematiche necessarie alla comprensione. Inne si delineano le pratiche utilizzate per costruire la simulazione di un sistema sico. Viene presentato il meccanismo di relazione tra le particelle di cui si compone il corpo ed in che modo avviene linterazione con lutente.

3.1

Ambiente di sviluppo

Lapplicazione oggetto della tesi ` e pensata e sviluppata per dispositivi mobili dallhardware avanzato. Molte caratteristiche accomunano tali device. In primo luogo essi hanno pochi tasti sici che sono dediti solitamente a operazioni di base del sistema operativo come gestione del volume audio o chiusura dellapplicazione in esecuzione. La maggior parte delle interazioni con lutente avviene attraverso lo schermo che permette linput attraverso il tocco dello stesso. La natura touch permette allutente di interagire direttamente con gli oggetti presenti nella scena 3D e ci` o risulta chiaramente una sda per

23

lo sviluppatore. La gestione dellinput ` e infatti dierente rispetto ad esempio a mouse o tasti sici presenti sui computer, soprattutto se si pensa che si possono inserire gesture ossia assegnare funzioni a particolari movimenti eseguiti toccando lo schermo in pi` u punti. Un esempio ` e la gesture del pinch to zoom che verr` a spiegata nella sezione 3.2. La scena 3D viene sviluppata e disegnata attraverso lo standard OpenGL, nella sua versione ES. OpenGL (Open Graphics Library) [37] ` e una libreria per lo sviluppo di applicazioni grache 2D e 3D. Fin dal 1992, anno del rilascio, OpenGL ` e diventata linterfaccia di programmazione (API) graca pi` u usata e supportata nei linguaggi e nelle piattaforme. Linterfaccia consiste in oltre 250 chiamate di funzione, che permettono di ottenere graca ad alte prestazioni, di gestire oggetti geometrici 3D e immagini e di creare applicazioni interattive come i videogiochi. OpenGL ` e pensato per essere indipendente dallhardware e dal sistema operativo. Per questo non contiene comandi per gestire le nestre. Svolge due funzioni importanti: orire al programmatore unAPI unica e uniforme, e permettere di superare le dierenze hardware riscontrabili tra piattaforme diverse. OpenGL ES ` e un sottoinsieme delle librerie grache OpenGL pensato per dispositivi integrati (telefoni cellulari, PDA ecc. ma anche strumentazione scientica e industriale). Viene gestito dal consorzio no-prot Gruppo Khronos [38], che cura anche lo sviluppo della libreria madre OpenGL. Le API messe a disposizione sono pensate per dispositivi dalle risorse limitate e quindi non tutte le caratteristiche messe a disposizione da OpenGL sono utilizzabili nella versione ES. Tuttavia tale versione risulta il miglior modo per eseguire lo sviluppo di applicazioni grache e le mancanze non portano allimpossibilit` a di implementare gli obiettivi che si vogliono ottenere come verr` a mostrato successivamente. Luso di questa libreria graca comporta ladozione della geometria adatta a rappresentare oggetti sulla scena. Loggetto che viene rappresentato ` e soggetto a diverse trasformazioni prima di essere disegnato. Le trasformazioni permettono di: specicare la locazione dellosservatore e della camera di vista (Viewing), muovere loggetto nella scena (Modeling), ridimensionare e 24

tagliare la scena secondo il volume di vista (Projection) e la dimensione della nestra (ViewPort). Le trasformazioni sono calcolate in forma matriciale e applicate in sequenza nella pipeline graca alle coordinate dei vertici originali. La matrice a cui si pone maggiore attenzione ` e la matrice di ModelView che permette di posizionare e orientare loggetto disegnato combinando le trasformazioni di Viewing e Modeling.

Figura 3.1: Pipeline delle trasformazioni in OpenGL

3.2

Gesture di pinch

Linterazione dellutente con dispositivi mobili touch-screen si arricchisce della capacit` a di supportare gesture multi-touch. Lo schermo tattile si dierenzia dai classici monitor per computer per il fatto che ` e sensibile al tocco anche in pi` u punti diversi della supercie contemporaneamente. Se lhardware supporta questa caratteristica essa deve essere supportata anche dal software del device. Il software, riconoscendo la posizione, la pressione, la distanza di ogni punto indipendente, quali i gesti e linterazione di pi` u dita o mani contemporaneamente, fornisce il risultato dellinterazione.

25

Un esempio che si collega al lavoro di tesi ` e lingrandimento o il rimpicciolimento di oggetti rappresentati sullo schermo. Le gesture pi` u naturali e intuitive che permettono di eettuare tali operazioni prendono il nome di pinch to zoom. Tale tipologia di movimento ` e stata per la prima volta utilizzata come parte integrante dellinterfaccia su dispositivi mobili dalla Apple sul suo iPhone [39]. In particolare tale movimento viene utilizzato per lingrandimento di immagini visualizzate sul display. Le gesture sono basate su due tocchi simultanei sullo schermo: se i due tocchi si allontanano ci sar` a uno zoom in, altrimenti uno zoom out.

Figura 3.2: Gesture per il pinch to zoom: a sinistra per lo zoom in, a destra per lo zoom out

Per rilevare il movimento viene calcolata la distanza euclidea tra i due tocchi: una distanza molto piccola indica che la gesture ` e per lo zoom out, una distanza sempre maggiore tra i due punti di contatto rappresenta un movimento di zoom in. Nel caso in esame un fattore numerico legato a tale movimento pu` o essere utilizzato per calcolare la relativa trasformazione di scaling in OpenGL del modello visualizzato.

26

3.3

Rotazione con Arcball

La rotazione di un oggetto nello spazio pu` o avvenire lungo diversi assi, e ogni rotazione si pu` o comporre di diverse rotazioni, ognuna su un asse dierente. E provata la dicolt` a nel delineare un interfaccia semplice e naturale per manipolare la rotazione attraverso un dispositivo di input che lavora in sole due dimensioni. LArcball ` e una tecnica di input che risolve tali dicolt` ae consente di manipolare la rotazione combinando fattori sia matematici che legati allinterazione dellutente [14]. Lidea alla base dellArcball ` e intuitivamente semplice: si vuole rappresentare la rotazione di un qualsiasi oggetto come la rotazione di una sfera. Per cambiare lorientamento delloggetto lutente disegna un arco sullo schermo che verr` a quindi proiettato sulla sfera. Per eettuare il disegno dellarco semplicemente lutente deve eettuare un movimento di drag: su un dispositivo mobile con touch screen ci` o avviene toccando in un punto e trascinando il tocco senza distaccarsi dallo schermo. Se i punti di tocco e di rilascio avvengono in posizioni esattamente opposte ci` o implica una rotazione completa di 360 gradi (fenomeno di wrapping).

Figura 3.3: Movimento di drag sullArcball, Mouse Down e Mouse Up si riferiscono a eventi di clic del mouse su computer, su dispositivi mobili ci` o si tramuta in tocco e rilascio dello schermo tattile.

27

3.3.1

Quaternioni

La rotazione di un oggetto in tre dimensioni pu` o essere soggetta al fenomeno del gimbal lock. Questultimo corrisponde alla perdita di un grado di libert` a se la rotazione ` e basata su angoli di Eulero e per risolverlo si pu` o applicare la matematica dei quaternioni [18], [40]. Un quaternione ` e una notazione matematica conveniente a rappresentare orientamento e rotazione di un oggetto in tre dimensioni. Ogni rotazione in tre dimensioni pu` o essere rappresentata come combinazione del vettore dellasse e di un angolo. Dato un vettore (ax , ay , az ) il quaternione pu` o essere costruito con la seguente formula: 1 1 q = cos + (ax i + ay j + az k ) sin 2 2 (3.1)

dove ` e langolo di rotazione ed il vettore rappresenta lasse di rotazione. Data una posizione p descritta dalle coordinate spaziali (px , py , pz ) per applicare la rotazione bisogna eettuare la seguente moltiplicazione: px i + py j + pz k = q (px i + py j + pz k )q ove q ` e il coniugato di q: 1 ( px i + p y j + pz k ) 1 1 q = e 2 = cos (px i + py j + pz k ) sin 2 2 (3.2)

(3.3)

Inoltre due quaternioni possono essere combinati in un unica rotazione: q = q2 q1 (3.4)

Ci` o fornisce la rotazione risultato delle due rotazioni nella sequenza con cui vengono moltiplicate dato che tale operazione non ` e commutativa. Nella formula mostrata la rotazione si compone di una prima rotazione q2 e una seconda rotazione q1 applicata alloggetto successivamente. In tal modo lutilizzo dei quaternioni, oltre a risolvere il gimbal lock, 28

permette di facilitare la combinazione delle rotazioni. In computer graca ci` o` e importante in quanto lanimazione di una singola rotazione in realt` a` e la composizione di pi` u rotazioni. Ognuna di esse viene calcolata in un time step e si combina con le precedenti. Se le rotazioni fossero rappresentate in forma di matrici ortogonali o con angoli di Eulero le composizioni risulterebbero dicili da calcolare.

3.3.2

Funzionamento

Lintroduzione delle nozioni viste nora permettono di capire il funzionamento dellArcBall che pu` o essere riassunto nei punti di seguito mostrati. Mappatura sulla sfera Loggetto da ruotare ` e virtualmente inserito al centro di una sfera su cui lutente pu` o eettuare il drag. Quindi il primo passo ` e proiettare le coordinate di input in 2D sulla sfera in 3D. Ci` o avviene quando lutente eettua il primo tocco sullArcball, tale evento ` e denito solitamente click. Il click fornisce x ed y e si conosce il raggio della sfera, ci` o che ` e ignoto ` e la coordinata z del punto in 3D.

Figura 3.4: Rappresentazione della mappatura del punto p di tocco sullo schermo (linea in basso) sulla sfera

Dato che ogni punto della sfera si trova a distanza pari al raggio dal centro ` e facile calcolare la coordinata z tramite il teorema di Pitagora (Fig. 3.4). 29

Lunico problema ` e che il punto in 3D calcolato potrebbe non trovarsi sulla supercie se lutente eettua il tocco al di fuori del raggio della sfera, in tal caso la coordinata z sar` a tale che il punto in 3D ` e il punto della supercie sferica pi` u prossimo alle coordinate di tocco. Ci` o che si ottiene non ` e semplicemente una posizione, bens` un vettore rappresentante lasse di partenza della rotazione selezionato dallutente. Al termine di questa fase tale vettore deve essere normalizzato per semplicare i calcoli successivi. Calcolo della rotazione corrente Quando lutente eettua il drag si vuole ottenere una rotazione della sfera. Durante il movimento di drag la sfera ` e toccata in diversi punti, ognuno di essi rappresenta un vettore nello spazio che combinato al vettore di click fornisce unasse e un angolo di rotazione. Per il calcolo di questi valori si possono utilizzare il prodotto scalare ed il prodotto vettoriale. Il prodotto vettoriale tra i due vettori fornisce il vettore perpendicolare ad entrambi, quindi lasse di rotazione. Il prodotto scalare serve per determinare langolo tra due vettori a e b nel seguente modo: = arccos(a b) (3.5)

Questultimo calcolo ` e possibile solo se i vettori sono normalizzati (per il vettore di click ci` o viene svolto nel punto precedente). A partire dallasse e dallangolo di rotazione appena calcolati ` e possibile ricavare il quaternione q ad essi associato attraverso le formule viste in precedenza. Esso rappresenta la rotazione corrente imposta alloggetto. Aggiornamento della rotazione globale La rotazione appena calcolata va a combinarsi con le precedenti applicate alloggetto. Si possono combinare le rotazioni moltiplicando i quaternioni ad esse associate nella giusta sequenza.

30

Tuttavia ` e bene calcolarne la combinazione in forma matriciale. Ci` o` e dovuto al fatto che le librerie di supporto graco come OpenGL calcolano le trasformazioni in base a matrici 4x4 [19], [18]. Conviene quindi trasformare il quaternione relativo alla rotazione corrente in una matrice da moltiplicare con la matrice relativa alla rotazione precedente per ottenere la matrice di rotazione nale. Un quaternione q pu` o essere trasformato nella corrispondente matrice 4 4 nel seguente modo: 1 2qy qy 2qz qz 2qx qy 2qw qz 2qx qz + 2qw qy 2qx qy + 2qw qz 1 2qx qx 2qz qz 2qy qz 2qw qx 2q q 2q q 2qy qz + 2qw qx 1 2qx qx 2qy qy x z w y 0 0 0 0 0 0 1

(3.6)

dove qx , qy , qz e qw rappresentano i rispettivi elementi di q . La matrice di rotazione ottenuta viene utilizzata per il calcolo della rotazione nella pipeline graca, viene quindi moltiplicata per la matrice di ModelView. Laggiornamento della rotazione avviene ogni volta che viene calcolato un nuovo vettore dal movimento di drag e ci` o dipende quindi dalla frequenza con la quale vengono prelevati gli eventi di input sullo schermo. Al rilascio dello schermo il drag termina e quindi non viene pi` u aggiornato lo stato della rotazione che rimane sso. Tutti gli step elencati si ripetono ad un nuovo evento di click.

31

3.4

Simulazione di corpi deformabili

Una delle caratteristiche di maggior spessore di questo lavoro di tesi ` e la capacit` a di simulare un sistema sico. Si vuole infatti creare una simulazione che permetta di rappresentare la deformabilit` a degli oggetti. Denire un sistema sico di questo genere in computer graca determina alcune dicolt` a nella denizione della struttura degli oggetti e della loro rappresentazione. Nei successivi punti si enunciano i principi adottati denendo ogni aspetto che permette il realizzarsi della simulazione.

3.4.1

Metodo mass-spring

In questa tesi si ` e utilizzato il metodo basato su particelle e vincoli (massspring) per la simulazione di deformabilit` a in quanto risulta il pi` u semplice, intuitivo e adattabile tra tutti i metodi possibili utili a ricreare tale simulazione. La modellazione mass-spring ha le sue origini nel mondo della Computer Graphics a partire dalla seconda met` a degli anni 80, per modellare il corpo di esseri viventi, tessuti e materiali molto deformabili come la gomma. Tale modellazione ` e basata su un modello analitico per rappresentare le caratteristiche meccaniche dei corpi, ma in maniera diversa rispetto a quella che si basa su elementi niti [24]. Infatti questa tecnica viene utilizzata soprattutto per simulare la deformabilit` a dei corpi. Un sistema mass-spring richiede una discretizzazione di un oggetto continuo: si utilizzano masse puntiformi opportunamente disposte nel volume occupato dal corpo. Il comportamento delloggetto viene simulato imponendo che ciascuna particella interagisca con quelle adiacenti; linterazione viene modellata come una forza che dipende dalle azioni esterne applicate a tutto il corpo e dalle caratteristiche strutturali del materiale. Cos` le forze di interazione corrispondono a quelle di classici modelli per materiali di tipo elastico, plastico, viscoelastico o simili, deniti dalla Scienza dei materiali.

32

Figura 3.5: Rappresentazione di un sistema mass-spring (Immagine presa da [24])

Nella simulazione mass-spring, il modello viene completato denendo le condizioni di vincolo per i punti del corpo, e le azioni esterne applicate ad essi. Lo stato del modello viene valutato in istanti successivi pressati, separati da intervalli di piccola durata. Ad ogni istante, per ogni particella vengono determinate le forze agenti, sia quelle applicate dallesterno, sia quelle interne dovute alle interazioni con le particelle adiacenti. In questo lavoro non si implementano direttamente le forze agenti sulle particelle, cosa che avrebbe messo in gioco lintegrazione di Verlet ed altri aspetti. La simulazione ` e infatti governata dai soli vincoli tra le particelle che permettono di modicare la struttura delloggetto in modo coerente rispetto agli input esterni. I vincoli deniscono la composizione interna del corpo andando ad impostare ad esempio la lunghezza della distanza tra le particelle o il volume dellintero oggetto. Essi possono essere violati in un istante di tempo ma nei successivi instanti torneranno ad essere vericati. In sostanza ci` o garantisce che la struttura non sia rigida, ma abbia una certa elasticit` ae possa evolvere in dipendenza ad esempio di input esterni. La tecnica descritta pu` o essere molto utile a rappresentare tessuti dinamici o materiali elastici come si pu` o osservare in Fig. 3.6.

33

Figura 3.6: Esempio di struttura di un oggetto rappresentante un tessuto

3.4.2

Struttura degli oggetti

Il modello sico prevede che il sistema di particelle sia visto dallesterno come un elemento unico, un punto multidimensionale nello spazio. Dallinterno, invece, questo ` e una complessa struttura che gestisce un insieme di oggetti distinti che interagiscono tra loro. In pratica si considera il sistema di particelle come un contenitore in cui governare il movimento delle masse. Gli oggetti su cui applicare le simulazioni sono mesh e quindi dati strutturati che deniscono la geometria principalmente attraverso vertici e facce. Nel sistema mass-spring le particelle sono denite come oggetti con una massa, una posizione, una velocit` a e unaccellerazione. Rispondono alle forze a cui sono soggette, ma non hanno una dimensione sica. Vengono, dunque, considerate come punti materiali che si muovono nello spazio. Risulta quindi logico assegnare ad ogni vertice la posizione di una particella. Tralasciando velocit` a e accellerazioni che non sono utili agli obiettivi preposti, ogni vertice pu` o essere visto come un punto materiale della mesh, importante a denirne la struttura e il comportamento nella simulazione. Le facce identicano i triangoli che compongono la mesh. Ogni faccia possiede un collegamento ai tre vertici che la delimitano, le informazioni sui lati (edge) e i collegamenti alle tre facce adiacenti ad essa. Questa caratteristica ` e molto importante per operare sulla struttura delloggetto, infatti diventa molto semplice aggiungere eventuali vincoli grazie a queste informazioni.

34

3.4.3

Vincoli strutturali

I vincoli strutturali vengono creati al momento della realizzazione delloggetto e mai cancellati o modicati durante tutta la simulazione. Essi sono intrinsechi nella struttura del corpo e ne determinano la dinamica durante la simulazione. Ogni volta che un oggetto ` e soggetto a deformazioni, le particelle che lo compongono vengono mosse. Dopo questo spostamento la struttura delloggetto potrebbe risultare alterata e i vincoli fanno s` che la struttura delloggetto non risulti compromessa. Questi vengono risolti secondo il metodo iterativo Gauss-Seidel che serve per arrivare alla soluzione dellequazione non lineare generata da ogni vincolo [41]. Lidea ` e di risolvere ogni vincolo in maniera indipendente uno dopo laltro. Tuttavia ci` o non fa in modo che il calcolo per ogni vincolo diventi unoperazione lineare. Per arontare il problema della non linearit` a si ` e pensato di ripetere in maniera iterativa per un numero nito di volte lo spostamento di ogni particella in una posizione valida rispettando ogni singolo vincolo. Questa operazione ` e resa molto semplice dalla dinamica basata sulle posizioni. Lista degli edge Nel lavoro sviluppato una tipologia di vincoli ` e determinata in base ai cosiddetti edge o lati della mesh. Ogni edge non ` e altro che un lato di una o pi` u facce che collega due vertici. La gura sottostante li mostra chiaramente.

Figura 3.7: Edge (a sinistra) e facce (a destra) di una mesh ragurante un parallelepipedo, ogni edge pu` o essere condiviso da pi` u di una faccia

35

Ogni edge ` e identicato principalmente dai due vertici che lo compongono, e ci` o ne caratterizza lunicit` a allinterno delloggetto. Dato che bisogna caratterizzare un vincolo per ogni edge ` e importante denirli. Un le di una mesh pu` o non contenere la lista degli edge, ` e il caso del tipo di le che il software in sviluppo supporta (OBJ). La struttura del le prevede la specicazione solo di vertici, facce e normali. Tuttavia si pu` o ricavare linsieme dei lati grazie alle facce: in fondo ognuna di esse denisce i tre lati di cui ` e composta attraverso i suoi vertici. Il problema che evidentemente pu` o sorgere ` e che alcuni edge sono condivisi tra due o pi` u facce, bisogna evitare che uno stesso edge sia aggiunto pi` u volte allinsieme. Se ci` o avvenisse, parallelamente linsieme dei vincoli crescerebbe inutilmente, dato che molti di questi sarebbero ripetuti. Creare dinamicamente una lista di edge unici ` e unoperazione non lineare e ci` o determina tempi lunghi per le computazioni soprattutto se il numero di facce della mesh ` e elevato. Per creare un insieme di elementi unici in tempistiche adeguate si pu` o utilizzare un Hashset, ossia una struttura dati che consente laggiunta di elementi in base ad una funzione di hash. Di ogni elemento viene calcolato il codice hash che si suppone essere unico nellinsieme: se due elementi hanno lo stesso codice allora sono uguali e quindi lelemento non viene aggiunto. La scelta di questa rappresentazione ` e motivata dalle prestazioni in termini di complessit` a temporale nellaggiunta di elementi allinsieme. Funzione di hash La funzione di hash ` e importantissima per denire la lista degli edge: una scelta non ottima potrebbe incentivare le collisioni. Avere una collisione nellaggiunta degli elementi implicherebbe ad esempio che due edge diversi vadano a collidere nella stessa posizione nellHashset, si perderebbe quindi linformazione relativa a uno dei due. Ogni edge ` e rappresentato dai due vertici che esso collega. Tali vertici sono espressi non con le rispettive coordinate, ma con gli indici (interi) relativi alla loro posizione nella lista di tutti i vertici. Occorre quindi una funzione

36

che eettui un mapping da un insieme N N ad un insieme N senza generare collisioni. La funzione di hash scelta ` e la funzione di parit` a di Cantor. Essa ` e la funzione : N N N denita da: 1 (3.7) (k1 , k2 ) = (k1 + k2 )(k1 + k2 + 1) + k2 2 dove k 1 e k2 sono due numeri interi. La parit` a di Cantor ` e molto adabile e solitamente viene utilizzata in ambito informatico in problemi della tipologia descritta. Vincoli di distanza A partire dallinsieme dei lati della mesh ` e possibile calcolare i vincoli di tipo distance che permettono di regolare la distanza tra le particelle. Ogni vincolo ` e creato solo in fase di inizializzazione e non viene alterato in seguito. Ci` o che si modica ` e la posizione delle particelle, e tali vincoli fanno s` che le particelle continuino ad avere sempre le stesse distanze tra loro. La risoluzione del sistema di vincoli non lineare avviene in maniera molto semplice grazie alla tecnica di rilassamento illustrata in precedenza. Iterativamente, per ogni vincolo, ogni particella viene spostata avvicinandola o allontanandola dalla particella ad essa connessa. Il processo mira quindi a giungere alla soluzione del sistema in piccoli passi svolti pi` u volte.

Figura 3.8: Rappresentazione graca della risoluzione del vincolo di distanza tra due particelle: al centro ` e visualizzata la distanza corretta.

37

Per ogni lato dei triangoli che compongono loggetto viene generato un vincolo di tipo distance secondo la funzione: Cdist (p1 , p2 ) = |p1 p2 | l0 (3.8)

Lo scalare l0 ` e la distanza iniziale tra le due particelle nelle posizioni p1 e p2 . Quindi, data p, posizione della particella nello spazio 3D, si vuole trovare la correzione p della posizione tale che C (p + p) = 0. Questa equazione si pu` o approssimare a: C (p + p) C (p) + p C (p) p = 0 (3.9)

Per costringere il p a stare nella direzione di p C bisogna scegliere uno scalare tale che: p = p C (p) (3.10)

Dalle due formule precedentemente descritte si ottiene la formula per il p eliminando lo scalare : p = C ( p) p C (p) |p C (p)|2 (3.11)

che ` e un passo Newton-Raphson per le soluzioni iterative delle equazioni non lineari date da un singolo vincolo. Per la correzione della posizione pi di una particella si ha: pi = spi C (p1 , p2 ) dove il parametro s ` e dato da: s=
j

(3.12)

C (p1 , p2 ) |pj C (p1 , p2 )|2

(3.13)

Si noti che questo parametro ` e uguale per ogni particella. Considerando che le derivate rispetto alle due particelle in posizioni p1 e p2 sono rispettiva-

38

mente p1 C (p1 , p2 ) = n e p2 C (p1 , p2 ) = n con n =

p1 p 2 , il parametro |p1 p2 |

|p p | l0 s` e uguale a: 1 22 . Ed inne le correzioni da fare per far rispettare il vincolo di distanza sono pari a: p1 = 1 (|p1 p2 | l0 )(p1 p2 ) 2 |p1 p2 | 1 (|p1 p2 | l0 )(p1 p2 ) p2 = 2 |p1 p2 | (3.14) (3.15)

I delta mostrati andranno rispettivamente a sommarsi alle posizioni attuali p1 e p2 . Nellarticolo di Muller [30] da cui si traggono questi calcoli si fa riferimento anche al parametro kdist dal valore in [0...1] che rappresenta una costante di rigidit` a del corpo. In pratica se si moltiplica tale parametro per il valore del delta si ottiene che la distanza da rispettare deve essere kdist volte loriginale. Un valore di kdist pari ad 1 fa s` che la distanza tra p1 e p2 sia sempre rispettata. Invece un valore molto vicino allo 0 rende il vincolo molto meno rigido permettendo alle particelle di stare ad una distanza maggiore di l0 se sottoposte a forze che tendono a separarle. Le correzioni da applicare, tenendo conto del valore di kdist , sono dunque:

p1 =

1 (|p1 p2 | l0 )(p1 p2 ) kdist 2 |p1 p2 | 1 (|p1 p2 | l0 )(p1 p2 ) p2 = kdist 2 |p1 p2 |

(3.16) (3.17)

Il problema di questo tipo di algoritmo ` e che a causa delle iterazioni multiple necessarie per risolvere le equazioni non lineari dei vincoli, anche leetto di kdist non sar` a lineare. Questo porta alla presenza di un errore in p per un numero di iterazioni molto grande. Per risolvere il problema si pu` o mol1 tiplicare p non per kdist , ma per k = 1 (1 k ) ns dove ns rappresenta il numero di iterazioni del solver. Questo approccio necessita di conoscere in anticipo il numero di step risolutivi, cosa non possibile per applicazioni inte39

rattive come questo lavoro di tesi dato che il numero di iterazioni condiziona il numero di frame per secondo e non ` e instaurabile a priori. Perci` o il valore di k ` e ignorato e si utilizza il valore di kdist introdotto in precedenza. Per ottenere il comportamento descritto con le formule elencate si pu` o utilizzare lo pseudocodice seguente tratto da [25]. Algorithm 1: Risoluzione vincolo di distanza Data: restlenght=distanza originale,(x1,x2)=posizioni attuali dei vertici Result: Correzione nale delle posizioni 1 delta = x2 - x1; 2 deltalength = sqrt(delta*delta); 3 di = (deltalength-restlength)/deltalength; 4 x1 += delta*0.5*di*k; 5 x2 -= delta*0.5*di*k; Il codice si riferisce al caso monodimensionale ma pu` o essere facilmente esteso in tre dimensioni. Il valore di restlength si riferisce alla distanza originale tra i due punti. Lalgebra lineare aiuta in tal modo ad ottenere il comportamento preposto: si calcola la distanza attuale tra i due punti e quindi si avvicinano o si allontanano le particelle di una quantit` a che dipende dalla dierenza della distanza attuale rispetto a quella originale. Si noti che, per mantenere la simmetria, le due particelle verranno spostate sempre della stessa quantit` a. Inne si mostra nella seguente gura una rappresentazione graca della risoluzione iterativa dei vincoli descritti.

40

Figura 3.9: Risoluzione di un sistema di vincoli di distanza tramite la tecnica di Gauss-Seidel: le immagini rappresentano ogni step delliterazione e sono in successione, a partire dallalto a sinistra verso destra continuando poi in basso a sinistra verso destra.

Vincoli di volume In caso di oggetti chiusi, una pressione eccessiva interna alla mesh pu` o essere facilmente implementata tramite il metodo descritto in [30]. Si vuole ottenere un comportamento tale che i corpi, sollecitati da forze eccessive, combiano forma, ma che, una volta sparite le forze, ritornino nuovamente nella forma originale. Un esempio pu` o essere il caso delle sfere che, in caso di urto, si deformano, ma poi tornano alla forma e al volume originale. Per far questo si aggiunge un vincolo denito di overpressure a tutti gli N vertici che compongono una mesh. Questo vincolo sar` a soggetto ad una funzione pari a:
ntriangoli

C(p1 ,...,pN ) = (
i=1

(p

ti 1

p i ) p i ) kpressure V0 t2 t3

(3.18)

Nella (3.18) il parametro kpressure rappresenta di quanto il volume corrente (il primo termine della dierenza) pu` o discostarsi dal volume originario V0 , mentre i termini p i rappresentano le coordinate dei vertici di ogni faccia della tj mesh. Il parametro k bilancia la deformazione delloggetto ed ` e compreso nel range [0...1].

41

Tramite questa funzione ` e possibile ricavare i gradienti dei vertici: pi C = j : t1 j = i (p tj 2 p j) + t3 (p j : t2 j = i tj 3 p j) + t1 (p j : t3 j = i tj 1 p j) t2 (3.19) ove j rappresenta lindice delle facce. Il calcolo dei gradienti permette di calcolare il delta di spostamento per ogni vertice: pi = pi s kpressure (3.20)

Il parametro s consente di dosare lo spostamento in base al volume della mesh corrente e a quanto dista dal volume originario: s= C 2 j |pj | (3.21)

dove C ` e la dierenza tra i due volumi. Come per i vincoli di distanza il delta va sommato ad ogni vertice. Inoltre si noti che il calcolo dei gradienti, del volume originario e della sommatoria a denominatore della (3.21) possono essere eettuati al caricamento della mesh in memoria. Ci` o giova alle prestazioni real time dato che lunico calcolo pi` u lungo da risolvere durante la simulazione ` e quello del volume corrente. Chiaramente linsieme di tutti i vincoli di overpressure per ogni particella determina un sistema non lineare e perci` o la tecnica di risoluzione iterativa deve essere utilizzata anche in questo caso.

42

Figura 3.10: Esempio graco delleetto dei vincoli sul volume: risultato dellanimazione da destra verso sinistra con al centro la massima distorsione applicata alla sfera (nella simulazione si utilizza un valore di k pari a 1).

3.4.4

Interazione dellutente: risultati della deformazione

Un sistema mass-spring mantiene il suo stato di quiete nch` e una forza, una collisione o altri aspetti comportano dei cambiamenti allinterno della struttura. Quando ci` o avviene alcuni vincoli saranno violati e si dovranno risolvere in modo iterativo cos` da giungere allinsieme di soluzioni che soddisfa tutti i vincoli espressi per loggetto. Nel lavoro oggetto di questa tesi, lobiettivo ` e rendere il sistema liberamente perturbabile dallutente. Forze o collisioni non sono implementate e quindi linterazione ` e possibile solo se i vincoli sulla distanza sugli edge o di overpressure sulle particelle sono violate. La violazione potrebbe avvenire cambiando semplicemente le posizioni di alcuni vertici. Se ci` o avviene ecco cosa accade allinterno della struttura mass-spring: 1. gli edge dei vertici interessati dallo spostamento non hanno pi` u le lunghezze prestabilite e il volume della mesh non ` e pi` u analogo al volume originario; 2. con la tecnica del rilassamento il sistema mass-spring risolve ogni vincolo violato;

43

3. la mesh adatta la sua forma secondo le nuove posizioni dei vertici che rappresentano la soluzione al sistema non lineare dei vincoli. La simulazione sica ` e avviata quindi dallutente che ` e in grado di selezionare e trascinare i vertici in posizioni diverse dalle originali. In condizione di riposo il sistema mass-spring non modica le posizioni nch` e linput dellutente non determina la violazione di qualche vincolo espresso per loggetto. Chiaramente il sistema dei vincoli verr` a risolto ad ogni time step sia durante che dopo il trascinamento del vertice selezionato.

Figura 3.11: Esempio di interazione con lutente: la freccia nella prima immagine a sinistra indica il punto di selezione e la direzione di trascinamento, al centro lutente smette di trascinare il vertice e quindi avviene il rilassamento dei vincoli che termina dopo un certo numero di time step come nellimmagine pi` u a destra.

44

3.4.5

Picking

La deformazione vista in precedenza ` e possibile se lutente ` e in grado di eettuare un picking dei vertici, ossia la selezione dei vertici da traslare. Loperazione appare semplice ed intuitiva dal punto di vista dellutente ma presenta delle problematiche tecniche non indierenti per lo sviluppatore del software. La scena 3D ha una propria geometria spaziale e ogni oggetto al suo interno presenta determinate coordinate relative a tutte le trasformazioni geometriche, di vista o prospettiche ad esso applicate. Una rapida panoramica delle trasformazioni che si applicano alle coordinate di ogni vertice in OpenGL ` e stata introdotta nella sezione 3.1. In generale le librerie grache creano ambientazioni 3D in cui le coordinate dieriscono totalmente dalle coordinate dello schermo, ossia ci` o che vede lutente. Ci` o` e dovuto principalmente al fatto che lo schermo ` e in due dimensioni e quindi limitato rispetto alle tre dimensioni dello spazio rappresentato. La selezione di un area dello schermo deve essere quindi proiettata nello spazio rappresentato. Essa non sar` a una semplice area in due dimensioni bens` un certo volume della scena. Esistono diversi modi per gestire tale situazione secondo la libreria graca utilizzata. Un esempio ` e dato dalle API di OpenGL, nella sua versione standard utilizzabile su computer. Il funzionamento del picking con OpenGL ` e molto semplice e pu` o essere riassunto nei seguenti passi: 1. Ottenere le coordinate del mouse (si analizza il caso dei computer, ma ci` o pu` o essere esteso ad altri meccanismi di input indipendentemente da OpenGL); 2. Entrare in Selection Mode: una modalit` a di rendering speciale in cui il frame buer (responsabile del disegno sullo schermo) non viene alterato, ossia lutente continua a visionare la scena come in precedenza; 3. Ridenire il volume di vista in modo che solo una piccola porzione dello schermo attorno al cursore ` e utilizzata per il rendering;

45

4. Eettuare il render della scena, utilizzando solo le primitive che sono visibili nel volume di vista selezionato; 5. Uscire dal Selection Mode e identicare gli oggetti che sono stati interessati dal render, essi saranno quelli selezionati dal picking. In pratica si nominano le primitive di disegno e in modalit` a Selection si collezionano solo le primitive che vengono disegnate nel volume di vista prossimo al cursore memorizzandone il nome e la profondit` a. Tale tecnica ` e molto utile ed ` e stato studiata una sua applicabilit` a in ambito mobile per lo sviluppo del picking. Purtroppo non ` e utilizzabile in quanto OpenGL ES non supporta la modalit` a Selection e quindi non permette laccesso al buer contenente i nomi delle primitive interessate dal picking. Per ovviare a tali mancanze bisogna eettuare dei ragionamenti dierenti che mettono in gioco la geometria della scena 3D di OpenGL. La tecnica utilizzabile ` e denita ray picking ed ` e descrivibile in modo semplice: si calcola la retta passante per il punto di tocco sullo schermo e che attraversa tutta la scena, intersecando o meno la bounding box delloggetto rappresentato (si veda Fig. 3.12). Lintersezione della bounding box implica che la retta attraversi o sia vicina alla mesh visualizzata ed ` e quindi calcolabile quali sono i vertici pi` u prossimi ad essa. Il vertice pi` u vicino in assoluto e pi` u prossimo al punto di osservazione sar` a il risultato della selezione sullo schermo.

46

Figura 3.12: Rappresentazione graca della tecnica del ray picking nello spazio 3D di OpenGL.

Trasformazioni inverse Linput del picking ` e chiaramente limitato a due dimensioni e ci` o rende impossibile determinare quale sia la profondit` a del punto nello spazio corrispondente al pixel selezionato. Nella versione standard di OpenGL listruzione glReadPixel consente di ottenere la profondit` a leggendone il valore nel Depth Buer. Tuttavia questultimo non ` e accessibile in OpenGL ES e ci` o giustica la creazione della retta. Lo spazio geometrico rappresentato tramite OpenGL ` e racchiuso idealmente tra due piani come esposto in Fig. 3.12: i cosiddetti near plane e far plane. Si possono calcolare le proiezioni del punto di tocco su tali piani in modo da ottenere due punti che appartengono alla retta: con essi si pu` o calcolare lequazione della retta in tre dimensioni sfruttando le equazioni della geometria analitica. La proiezione di un punto dello schermo nello spazio tridimensionale implica linversione della pipeline graca di OpenGL. La sequenza delle trasformazioni nella terminologia di OpenGL e nel suo utilizzo standard comporta 47

i seguenti cambi di coordinate a partire dalle coordinate delloggetto per terminare nelle coordinate visualizzate sullo schermo: Object World Eye Clip Normalized Device Window. Si utilizza una matrice di ModelView (M ) per trasformare le coordinate delloggetto (p) in coordinate di vista (v ): Mp = v (3.22)

Unaltra matrice, la Projection (P ) consente la trasformazione in coordinate di clip (c): Pv = c (3.23) Le coordinate vengono quindi normalizzate e vi si applica una trasformazione di Viewport (V ) che consente di ottenere le coordinate dello schermo (s): c cw Vn=s n= (3.24) (3.25)

Per la proiezione si devono eettuare i passi mostrati esattamente nellordine opposto. Ci sono, tuttavia, due metodologie per eettuare il ray picking che dipendono da quali coordinate sono scelte per la creazione la retta: 1. Si calcola la retta nello spazio in coordinate di vista (Eye) 2. Si calcola la retta nello spazio in coordinate delloggetto Nel primo caso le distanze devono essere calcolate con i vertici nelle stesse coordinate della retta, quindi si possono prelevare i valori delle coordinate originali dei vertici moltiplicati per la ModelView. Dato che OpenGL ES non permette laccesso diretto al buer contenente le trasformazioni delle coordinate dei vertici, bisogna ricalcolare tali coordinate. Quindi per ogni vertice bisogna computare una moltiplicazione per la ModelVielw: la complessit` a temporale risulterebbe O(numero vertici). Il calcolo ` e parallelizzabile ma

48

dato che lapplicazione ` e destinata a dispositivi mobili ` e opportuno risparmiare calcoli complessi sulla CPU che in alcuni casi ` e formata da un unico processore. Il secondo approccio ` e quindi quello pi` u indicato e comporta la denizione della retta in coordinate delloggetto. In questo modo le coordinate dei vertici possono essere lette direttamente dal le della mesh senza alcuna ulteriore computazione. Il primo step ` e la trasformazione delle coordinate sullo schermo in coordinate di clip, per farlo si utilizza la matrice V . Invertendo la (3.25): x 1 2s w sy 2 h c= (3.26) 2s 1 z 1 dove sx , sy e sz sono le coordinate del punto selezionato sullo schermo e w e h sono relativi rispettivamente alla larghezza e allaltezza dello schermo. Si ottengono direttamente le coordinate di clip in quanto la coordinata w ` e unitaria. In (3.26) si rende necessaria la coordinata z relativa alla profondit` a ma come descritto in precedenza essa non ` e rilevabile. Piuttosto dalla (3.26) si possono ricavare i due punti appartenenti alla retta sui due piani dierenti near e far. La sz sar` a in un caso uguale a 0 (punto sul near plane), in un altro uguale a 1 (punto sul far plane), dato che la (3.25) determina che lo spazio di clip sia compreso sullasse z proprio tra 0 e 1. Ripartendo dallequazione (3.26) si passa dalle coordinate di clip alle coordinate di vista in tal modo: P 1 c = v (3.27)

e inne si applica la trasformazione della ModelView per ottenere le coordinate oggetto: M 1 v = p (3.28) La retta appena calcolata serve per testare la vicinanza dei vertici della

49

mesh al punto selezionato dallutente, possibile grazie al fatto che le coordinate della retta e delloggetto stesso sono relative allo stesso spazio. Tuttavia il modello pu` o essere soggetto a rotazioni, traslazioni o trasformazioni di scaling. Lapproccio nora descritto prende in considerazione i vertici della mesh nelle coordinate di partenza e queste non vengono in alcun modo alterate prima del calcolo della distanza con la retta. Quindi ` e la retta stessa che deve essere ruotata o scalata secondo le trasformazioni della matrice di ModelView mentre loggetto viene considerato fermo. I vantaggi sono evidenti: non si traformano tutti i vertici delloggetto, ma solo i due vertici di proiezione sul far plane e near plane appartenenti alla retta.

Figura 3.13: Trasformazione della retta tramite la matrice di ModelView per calcolare le distanze dei vertici. La mesh ` e ssata nelle sue coordinate di partenza senza alcuna trasformazione applicata.

Quindi nella (3.28) la matrice di ModelView verr` a prelevata dallo stack di OpenGL dopo aver computato tutte le trasformazioni applicate alloggetto. I calcoli da eettuare per giungere alle proiezioni sui due piani near e far sono molteplici ma le API di OpenGL ES orono un utile istruzione che aiuta ad evitarli: gluUnProject. Listruzione prende in ingresso le coordinate di tocco dello schermo (impostando la z a 0 o 1 come descritto precedentemente), le matrici di proiezione e ModelView correnti e il vettore di Viewport. Prima

50

dellutilizzo ` e opportuno trasformare la coordinata sy nel seguente modo: sy = h sy (3.29)

Ci` o poich` e le coordinate dello schermo prelevate tramite una gestione dellinput sul dispositivo in uso deniscono la posizione (0,0) in alto a sinistra, in OpenGL invece si ha lopposto ossia la posizione (0,0) ` e denita in basso a destra dello schermo.

Figura 3.14: Dierenza nelle coordinate dello schermo

Dietro una singola istruzione ci sono quindi numerosi calcoli da eettuare che comunque sono veloci ed eettuati in poche occasioni. Piuttosto i calcoli pi` u lunghi e gravosi per la CPU riguardano la determinazione della distanza di ogni singolo vertice della mesh dalla retta in questione. Si rende necessaria un ottimizzazione che permetta di calcolare le distanze solo sui vertici pi` u vicini alla retta, riducendo le computazioni e agevolando linterazione in tempo reale. Indicizzazione 3D allinterno di una griglia La tecnica del ray picking non evita uno dei problemi pi` u evidenti legati alla selezione di oggetti sullo schermo da parte dellutente: il calcolo delle distanze su ogni vertice. Infatti il numero dei vertici ` e generalmente elevato e il calcolo pu` o risultare lungo e gravoso.

51

In molti casi il picking viene sfruttato per determinare la selezione di interi oggetti e perci` o il problema si risolve enormemente dato che basta computare la distanza tra il centro di ogni oggetto e la retta per determinare quale sia loggetto selezionato. Invece, in casi come quello in esame, anche su piattaforme hardware pi` u performanti non ` e una buona pratica calcolare tutte le distanze soprattutto perch` e la maggior parte di esse ` e elevata e perci` o alcuni vertici non dovrebbero essere presi in considerazione. Si pu` o procedere ad una ottimizzazione nella ricerca del vertice dalla minima distanza con una tecnica di facile comprensione: 1. si costruisce una griglia in tre dimensioni che racchiude tutto loggetto, indicizzando tutti i vertici nelle rispettive celle della griglia;

Figura 3.15: Griglia 3D con allinterno la mesh.

2. si eettua un mapping della retta di picking sulla griglia;

52

Figura 3.16: Mapping della retta sulla griglia.

3. si calcola la distanza dei vertici contenuti nelle sole celle della griglia intersecate dalla retta. Nella gura 3.16 le celle in questione saranno comprese tra Cs e Ce . La griglia deve essere grande quanto la bounding box del modello al ne di racchiudere ogni possibile vertice. Inoltre essa deve contenere un numero di celle adeguato al modello stesso: ad esempio se un modello ` e molto grande (quindi ha una bounding box di grandi dimensioni), ma ha pochi vertici, ` e inutile costruire una griglia con molte celle in quanto la maggior parte di esse sarebbe vuota. Nel caso opposto un numero elevato di vertici per un modello di piccole dimensioni costringe alla creazione di molte celle, altrimenti si vanicherebbe lottimizzazione introdotta dalla griglia. In denitiva la dimensione sar` a sempre uguale alla bounding box, ma il numero di celle sar` a soggetto al numero di vertici, con il rispetto di una misura minima di diagonale di cella anch` e questultima non risulti troppo piccola per essere selezionata dallutente. Inoltre, dato che lapplicazione oggetto della tesi ` e diretta a dispositivi dalla memoria ridotta si pu` o pensare ad una ulteriore ottimizzazione ossia convertire la griglia da tre dimensioni a due. In pratica si rimuove la profondit` a della griglia, ma con alcuni accorgimenti per non condizionare il funzionamento dellevento di picking. Il vantaggio ` e evidente sia in termini 53

di calcolo che in termini di requisiti di memoria: bisogna memorizzare un numero di celle pari a un sesto del totale e le celle intersecate dalla retta saranno nettamente inferiori. Quindi ogni vertice della mesh (in coordinate non trasformate) viene proiettato sul piano contenente la griglia. La proiezione implica che ogni posizione sia considerata sul piano cartesiano formato dalle coordinate x e y, ignorando quindi la coordinata z. Per proiettare la retta bisogna ragionare in modo diverso al ne di non perdere linformazione relativa alla profondit` a: 1. Si calcolano i punti P1 e P2 in cui la retta interseca la griglia 3D. Data la massima z e la minima z dalla bounding box si utilizza lequazione parametrica della retta in uno spazio tridimensionale: x = x0 + tvx y = y0 + tvy z = z0 + tvz (3.30) dove v rappresenta il vettore direzionale della retta e (x0 , y0 , z0 ) il punto della retta sul near plane. 2. Si mappano i punti P1 e P2 sulla griglia 2D, calcolando le celle che li contengono. Per ogni punto ci possono essere diversi casi: se ` e nel piano della griglia basta solo calcolare la cella in cui ` e contenuto, se al contrario si trova al di fuori del piano bisogna riportarlo su di esso per calcolare la cella (sfruttando la retta congiungente i due punti). 3. Si calcolano tramite il noto algoritmo di Bresenham le celle comprese tra le celle di P1 e P2 . Allo stato attuale ` e lalgoritmo pi` u usato per la rasterizzazione di linee, soprattutto per la sua bassa richiesta di risorse computazionali [42]. Esso ` e anche usato per il disegno di linee sulla griglia di pixel dello schermo e perci` o` e implementato in rmware di schede grache o su hardware.

54

Figura 3.17: Ray picking su griglia 2D: le celle selezionate sono comprese tra Cs e Ce calcolate con lalgoritmo di Bresenham

Calcolo delle distanze Lobiettivo del ray picking ` e il prelevare il vertice pi` u prossimo alla retta di proiezione creata. Grazie alla tecnica della griglia si ottengono un insieme di celle che sono attraversate dalla retta. Tali celle contengono un numero di vertici che pu` o essere ampio ma non sar` a mai eccessivo per le risorse computazionali del dispositivo in uso grazie allopportuna ottimizzazione introdotta dalla griglia stessa. Per determinare i vertici pi` u vicini si sfruttano note basi di geometria che permettono di calcolare la distanza di un punto da una retta nello spazio tridimensionale. Dati i vertici P1 = (x1 , y1 , z1 ), P2 = (x2 , y2 , z2 ) per i quali passa la retta e il vertice P = (x, y, z ) da cui calcolare la distanza si operano i seguenti calcoli: 1. si ricavano i vettori: v = (x2 x1 , y2 y1 , z2 z1 ) u = (x x1 , y y1 , z z1 )

55

2. si calcola il prodotto vettoriale v u, la norma di tale prodotto rappresenta larea del parallelogramma formato da v ed u; 3. dato che |v u| ` e larea basta dividere questa quantit` a per la lunghezza del vettore v (la base) e si ricava laltezza ossia la distanza del punto dalla retta. In ogni cella si calcolano le distanze dei vertici col metodo descritto e al termine si ottiene un solo vertice per cella, il pi` u prossimo alla retta. A questo punto ` e opportuno eettuare un ulteriore scrematura per denire lunico vertice da selezionare. Si ricorda che nora le coordinate dei vertici sono prelevate direttamente dal le della mesh lavorando quindi in coordinate oggetto. Perci` o i vertici non hanno linformazione relativa alla trasformazione della matrice di ModelView applicata alloggetto e se non si operasse un ulteriore anamento nel calcolo si otterrebbero un insieme di vertici che sono sia quelli pi` u prossimi allutente che quelli pi` u lontani, dal lato opposto, del punto di selezione.

Figura 3.18: Vertici selezionati senza linformazione sulla trasformazione della ModelView: il vertice corretto ` e quello pi` u vicino allutente ossia quello in alto a sinistra

Si deve quindi necessariamente calcolare la coordinata z relativa alla profondit` a corrente per ognuno dei vertici rimasti. Viene moltiplicato ogni vertice per la matrice ModelView che denisce come i vertici sono rappresentati nella scena in base alla trasformazione di rotazione, di traslazione e di scaling corrente. 56

Alla ne si ottiene il vertice con la massima z , dato che il verso dellasse z` e uscente dallo schermo. Si noti come il calcolo ` e eettuato per pochissimi vertici, uno per ogni cella della griglia che comprende la retta; ci` o non richiede elevati tempi computazionali. Vincolo di picking Fino ad ora si ` e descritto come selezionare opportunamente e in maniera ottimizzata i vertici della mesh corrente senza menzionare eettivamente quale operazione sia prevista per il vertice interessato dal picking. Come mostrato nel precedente sottocapitolo linterazione dellutente riguarda lo spostamento del vertice selezionato per fare in modo che loggetto si deformi. Non appena lutente termina la traslazione del vertice il sistema perturbato dei vincoli trover` a una soluzione alle posizioni dei vertici che compongono la mesh. Ma come pu` o avvenire la traslazione del vertice selezionato? Si pensi al dispositivo dutilizzo del presente lavoro di tesi: esso dispone di uno schermo tattile e quindi il modo pi` u naturale per rappresentare tutto ci` o` e supportare lazione di trascinamento. In pratica lutente al primo tocco seleziona il vertice da traslare, e successivamente, senza lasciare lo schermo, muove il tocco nella direzione voluta. Al termine esso rimuover` a il tocco dallo schermo e il sistema mass-spring sar` a libero di risolvere i vincoli senza che sia condizionato dal trascinamento. Tale azione quindi non fa altro che vincolare il sistema mass-spring a risolvere i propri vincoli in base alla traslazione del vertice selezionato. E molto pratico rappresentare il trascinamento come un vincolo dato che si gioverebbe della struttura sica creata e si utilizzerebbero le nozioni matematiche viste nora senza introdurre ulteriori concetti. Il vincolo denito dal picking ` e di una tipologia simile al vincolo di distanza sugli edge poich` e loperazione di trascinamento pu` o essere vista in un modo dierente: essa non ` e altro che linsieme di molteplici tocchi sullo schermo. Se da ognuno di essi si costruisce una retta di proiezione si pu` o calcolare la distanza del vertice selezionato con tale retta. A questo punto si inserisce un vincolo su una distanza molto piccola tra il vertice e la retta che comporta lo spostamento del vertice in

57

direzione della retta stessa. Per esprimere questo vincolo ` e opportuno riprendere i concetti espressi in relazione al vincolo di distanza sugli edge. Si pu` o osservare che nel rilassamento di tale vincolo si utilizzano due vertici e invece in questo caso abbiamo un vertice e una retta. Per realizzare un calcolo analogo si deve denire il vertice della retta che ` e pi` u vicino al vertice della mesh da traslare. Per farlo si denisce il piano t, passante per la posizione p del vertice selezionato, e ortogonale alla retta proiettata corrente, quindi si calcola il vertice di intersezione tra la retta e il piano t. Il rilassamento del vincolo avviene come descritto in precedenza, ma senza rispettare la simmetria negli spostamenti. Ci` o vuol dire che il vertice della retta non verr` a realmente spostato ma solamente utilizzato per calcolare direzione e quantit` a dello spostamento del vertice selezionato. Il rispetto di tale vincolo ` e il primo ad essere garantito nel sistema massspring ad ogni iterazione poich` e` e il pi` u importante: esso determina la violazione di tutti i vincoli precedentemente creati. In tal modo ` e lutente che avvia la simulazione e al rilascio dello schermo del dispositivo il vincolo semplicemente cessa di esistere. Quando ci` o avviene i restanti vincoli determinano il progresso della simulazione verso una congurazione stabile.

Figura 3.19: Rappresentazione dello spostamento del vertice selezionato durante il trascinamento del tocco sullo schermo.

58

Si noti inne come lo spostamento dei vertici comporta che questultimi debbano essere indicizzati di nuovo sulla griglia al ne di garantire che le successive operazioni di picking avvenghino in base alle nuove coordinate dei vertici e non rispetto alle coordinate originali.

3.4.6

Schema generale

Figura 3.20: Schema generale del funzionamento del sistema mass spring

59

Lo schema in Fig. 3.20 ben rappresenta i collegamenti logici tra i vari elementi che permettono di costruire la simulazione sica. Dalla mesh si ricavano i vincoli strutturali del sistema e la griglia attraverso un indicizzazione dei vertici. La gestione dellinput consente di costruire una retta la cui proiezione sulla griglia permette di determinare il vertice selezionato. In denitiva si calcola il vertice pi` u prossimo alla retta per determinare il vincolo di picking. Lottimizzazione mostrata permette di eettuare pochi calcoli real-time (distanze, volume corrente, retta di picking), e al caricamento della mesh ` e opportuno eettuare i calcoli pi` u complessi (gradienti dei vertici per esempio) o relativi a informazioni statiche (volume originario, distanze originali degli edge ecc.). Il sistema di risoluzione dei vincoli non ` e lineare ma la tecnica di rilassamento di Gauss-Seidel [41] permette di risolvere in real-time i vincoli in maniera semplice e lineare. In denitiva si mostra lo pseudocodice relativo alla risoluzione dei vincoli.

60

Algorithm 2: Risoluzione sistema mass-spring Data: posizioni attuali dei vertici, volume delloggetto, distanze originali degli edge Result: Correzione nale delle posizioni in base a tutti i vincoli 1 foreach time-step do
2 3

if esiste un vertice selezionato then risolvi vincolo distanza del vertice selezionato con retta di picking; end foreach edge do risolvi vincolo distanza ; end foreach particella do risolvi vincolo volume ; end //fase di update foreach particella do aggiorna posizione nel buer di disegno; end end

4 5 6 7 8 9 10 11 12 13 14 15

61

Capitolo 4 Implementazione
In questo capitolo verranno presentate tutte le tecniche implementative per raggiungere gli obiettivi preposti su dispositivo mobile equipaggiato con sistema Android. Si mostra quindi il funzionamento di un applicazione per tale sistema operativo, le sue componenti principali e in che modo vengono integrate le funzioni grache oerte da OpenGL ES. Di questultima libreria si spiegano le dierenze principali con la libreria completa OpenGL e come utilizzare gli strumenti messi a disposizione per il render 3D. Quindi si descrive ogni aspetto della libreria Min3D utilizzata per accedere al le della mesh e rappresentare il tutto sullo schermo, soprattutto i suoi limiti e cosa ` e stato introdotto per rendere il software funzionale agli scopi. Inne si mostrano tutte le caratteristiche dellapplicazione, linterfaccia graca e linterazione con lutente. Oltre alla panoramica software si deniscono anche gli strumenti utilizzati per lo sviluppo.

4.1

Strumenti utilizzati

Lapplicazione per sistema Android viene sviluppata su computer e compilata tramite il tool messo a disposizione insieme al SDK. LIDE supportato per lo sviluppo ` e Eclipse [43]. Per consentire la compilazione e linstallazione del programma sul dispositivo occorre il plugin Android Development Tools

62

(ADT). Esso consente inoltre il supporto alleditor dei le XML necessari ad alcune operazioni dellapplicazione; la visualizzazione di una nestra di debug su computer, riportante gli eventi generati nellapplicazione in esecuzione sul dispositivo; e la creazione del pacchetto APK che rappresenta il le di installazione del software. Il dispositivo di testing utilizzato nello sviluppo ` e un Samsung Galaxy Nexus dotato di display da 4.65 pollici e una piattaforma hardware performante con processore ARM dual-core. Per garantire una compatibilit` a maggiore ` e stato eettuato il testing anche su un Samsung Galaxy S con display dalla dimensione di 4 pollici e un hardware meno eccellente con processore single-core. Entrambi i dispositivi contengono un chip adibito alla graca, multi-core e prodotto dalla PowerVR [44] abbastanza potente da garantire il funzionamento dellapplicazione.

4.2

Struttura dellapplicazione

Il software in sviluppo ` e scritto nel linguaggio di programmazione Java e quindi si utilizza il SDK messo a disposizione da Google. Il sistema operativo Android ha un kernel Linux ed ogni applicazione ` e in esecuzione su una Java virtual machine separatamente da tutte le altre. In tal modo si mantiene il principio least privilege, ossia ogni applicazione in esecuzione di default ha accesso solo alle proprie risorse e non va ad intaccare loperato di altre applicazioni. Unapplicazione, tuttavia, pu` o richiedere i permessi per accedere ad esempio a delle risorse condivise quali messaggi, output di sensori ecc. Tali permessi sono specicati in un le denito Manifesto: un documento XML che specica anche altri dettagli. Inoltre il principio non vieta che un applicazione possa richiedere lavvio di unaltra applicazione per assolvere una specica funzione, per esempio scattare una foto o navigare su un sito web. La struttura del software ` e quindi dierente rispetto ad altre piattaforme e si compone di: 1. componenti chiave; 63

2. le di manifesto; 3. risorse. Nei successivi punti si specica il ruolo di ogni componente e come ` e stato sviluppato nel lavoro di tesi.

4.2.1

Componenti chiave: Activity

I componenti chiave di un applicazione Android sono in tutto quattro e ognuno di essi serve a utilizzare il sistema in modi dierenti: Activity, Service, Content provider, Broadcast receiver. Alcuni di essi servono a gestire dati condivisi come database SQL o servizi Internet e quindi non sono utili per il ne ultimo del lavoro in sviluppo. Ci si concentra quindi sul comprendere limportanza dellActivity che diviene il cuore del software. Un Activity (in seguito chiamata anche attivit` a) ` e il componente che fornisce linterfaccia di una singola schermata, consente lesecuzione di determinati comandi o computazioni, permette la visualizzazione di scene 3D e al suo interno si gestisce linterazione dellutente. Attraverso di essa si crea una nestra grande quanto lo schermo e si denisce ogni componente graco disegnato al suo interno. Unattivit` a non ` e separata dalle altre e pu` o richiamare altre attivit` a che verranno quindi istanziate e mostrate a schermo. Durante questo processo la precedente attivit` a sar` a nascosta allutente e quindi entrer` a in uno stato di pausa, rimanendo comunque in memoria. Dierentemente se lutente preme il tasto Back, presente su tutti i device Android e solitamente indicato con una freccia diretta verso sinistra, lattivit` a correntemente visualizzata verr` a stoppata e rimossa ossia eliminata completamente dallo stack di memoria. Il funzionamento delle Activity richiama in qualche modo il concetto di thread, infatti ognuna di esse ` e ne a se stessa ed ` e unesecuzione di determinato codice. Unattivit` a, tuttavia, ` e legata anche ad una interfaccia e al fatto che essa sia visualizzata o meno sullo schermo. Infatti se la vista di unattivit` a correntemente visualizzata viene nascosta dalla nestra di un altra attivit` a, si mette in pausa il suo usso di esecuzione tradendo quindi il 64

concetto di multi-threading. Ogni attivit` a pu` o essere, quindi, in diversi stati: ad esempio in pausa, o in stato di resume quando viene ripristinata. Ogni passaggio da uno stato allaltro viene noticato tramite eventi e pu` o essere ricavato con metodi deniti nellActivity come onPause() o onResume(). Lo schema in Fig. 4.1 riporta i vari stati e i metodi utilizzabili per catturare il passaggio da uno stato allaltro.

Figura 4.1: Stati possibili di un Activity con relativi metodi utili a catturare il passaggio da uno stato allaltro

65

In aggiunta bisogna denotare che linterfaccia graca di unattivit` a non necessariamente deve essere analoga a tutte le altre attivit` a. Tale interfaccia ` e formata da una gerarchia di oggetti di tipo View che permettono di disegnare pulsanti, testo ecc. Come nelle interfacce grache sviluppate su computer anche in Android ogni nestra (quindi ogni attivit` a) pu` o avere un particolare layout, ossia un ordine preimpostato dei vari elementi disegnati. Tutta la UI ` e congurabile attraverso documenti XML che gureranno come risorse dellapplicazione come descritto in seguito. Per questo lavoro si rende necessaria in primo luogo unattivit` a che gestisce la visualizzazione del modello e della scena 3D, e poi altre attivit` a per la gestione ad esempio del caricamento del modello o delle preferenze dellutente riguardo il disegno. Queste ultime due sono necessariamente separate dallattivit` a di visualizzazione in quanto presentano una UI e delle funzionalit` a completamente dierenti. Le Activity da sviluppare sono le seguenti con specicate le relative funzionalit` a: View3DActivity : ` e lattivit` a di partenza avviata allapertura dellapplicazione, essa gestisce il caricamento del modello, quindi permette di accedere alla memoria secondaria del device, vericare la presenza del le specicato e avviare lattivit` a di visualizzazione. Obj3DView : ` e lattivit` a cuore dellintera applicazione, qui si gestisce la visualizzazione della mesh e tutte le operazioni possibili su di essa. Permette quindi la lettura e il caricamento in memoria del modello. Inoltre si ore qui il supporto alle gesture dellutente e si richiama la simulazione del sistema sico. La UI ` e minimale e la maggior parte della nestra visualizza la scena disegnata tramite OpenGL. SettingsActivity : ` e lattivit` a responsabile della gestione delle preferenze dellutente. Essa viene richiamata dallattivit` a di visualizzazione e permette la scrittura di un le di preferenze mantenuto permanentemente in memoria secondaria (anche dopo chiusura dellapplicazione). La UI ` e semplicata e preimpostata. 66

4.2.2

Il le Manifesto

Prima che il sistema operativo lanci unapplicazione deve conoscerne le componenti leggendo il le AndroidManifest.xml salvato nel package dellapplicazione stessa. Questo le consente di denire, attraverso una specica nomenclatura XML, quali siano le attivit` a dellapplicazione e altre componenti importanti. Nel caso in sviluppo ` e quindi opportuno specicare le attivit` a descritte in precedenza con allegate informazioni come ad esempio quale sia lattivit` a di main e di launch, ossia lattivit` a eseguita allapertura. Oltre alle attivit` a` e opportuno descrivere in tale le anche il package dellapplicazione, la versione e il livello minimo delle API Android utilizzate. Riguardo questa specica bisogna eettuare alcune premesse: il sistema operativo ` e oggi ancora in sviluppo e quindi periodicamente viene pubblicata una nuova versione del sistema con nuove API o le stesse rinnovate. Ci` o da un lato giova al programmatore che si aaccia in questa realt` a software ma dallaltro determina una frammentazione nella diusione delle versioni dierenti di Android. Spesso i device non sono aggiornati allultima versione del sistema disponibile e ci` o determina il non utilizzo delle ultime API disponibili. Per tali motivi si ` e scelto di utilizzare come minima versione di Android la 2.1, in quanto la maggior parte dei dispositivi Android ` e oggi equipaggiato con una versione eguale o superiore. Si noti inne come lapplicazione da sviluppare non utilizzi particolari sensori o necessiti di particolari permessi dato che essa deve solo gestire laccesso in lettura a le su memoria secondaria o lorientamento del device. Tali operazioni sono consentite di default ad ogni applicazione senza alcuna specica nel manifesto.

4.2.3

Risorse dellapplicazione

Un applicazione Android non ` e composta solo di codice Java, essa richiede risorse esterne che possono ad esempio essere un le di immagine, un le audio, una specica riguardo la UI ecc. Nel lavoro in esame chiaramente i le della mesh rappresentano risorse esterne allapplicazione e devono essere caricate 67

da memoria secondaria. La memoria secondaria su device Android risulta divisa in pi` u componenti: una riservata al sistema operativo e ai dati delle applicazioni, una memoria interna e una memoria esterna (scheda SD) per i le dellutente. La porzione di memoria riservata ai dati delle applicazioni non ` e visibile allutente che pu` o accedere alle altre due partizioni di memoria per salvare i dati di interesse. Per poter leggere da tali memorie si possono aprire stream con lo stesso meccanismo adoperabile su computer attraverso Java. La locazione di memoria scelta per lapplicazione in sviluppo ` e la memoria interna in quanto di solito ore prestazioni superiori in lettura rispetto allSD-card di cui peraltro alcuni dispositivi sono sprovvisti. Si accede alla cartella radice della memoria interna attraverso listruzione: Environment.getExternalStorageDirectory() dove la classe Environment mantiene il riferimento alle locazioni di memoria disponibili.

Figura 4.2: Struttura della memoria secondaria di un device Android

Non solo il le della mesh ma anche layout, men` u e tutto ci` o che concerne linterfaccia pu` o essere specicato come risorsa. Questi le sono scritti in codice XML e permettono di denire in maniera molto semplice linterfaccia. Essi sono salvati nel package dellapplicazione e sono disposti in cartelle che hanno una specica nomenclatura.

68

4.3

Graca 3D su dispositivi mobili

Android include il supporto a prestazioni grache di alta qualit` a grazie alle librerie grache OpenGL. La particolare versione implementata, OpenGL ES, ` e una versione pi` u leggera della libreria completa disponibile su computer e pensata appositamente per dispositivi con limitate risorse computazionali. Ci sono quindi notevoli dierenze nellutilizzo di tale libreria rispetto alla libreria standard e nei successivi punti si mostrano quali di esse sono rilevanti per la costruzione dellapplicazione. Inoltre si vuole mostrare come integrare in pratica il meccanismo del render di OpenGL nellattivit` a pensata per la visualizzazione ossia Obj3DView. Per ulteriori informazioni riguardo le speciche di OpenGL ES si rimanda al documento uciale [2].

4.3.1

Vertex Buer Object

La principale dierenza tra la versione ES e la versione standard di OpenGL ` e indubbiamente luso forzato dei Vertex Buer Object (VBO) per il disegno delle primitive. Mentre nella versione standard su computer questa ` e una tecnica utilizzabile o meno, su dispositivi mobili ` e obbligatoria grazie alle performance che ore e va a sostituirsi al meccanismo classico di strutturazione del codice di disegno con OpenGL in cui le primitive sono racchiuse tra le istruzioni glBegin e glEnd. I dati riguardanti il disegno devono essere memorizzati in buer su GPU e, durante lesecuzione, si leggono e si interpretano i dati secondo ci` o che viene specicato nellistruzione di disegno. Luso e la struttura dei buer dipendono solo dal programmatore che pu` o decidere come memorizzare i dati al loro interno. I buer non sono utilizzabili solo per i dati ma anche per mantenere una serie di indici relativi al disegno dei vertici. Ad esempio per disegnare una piramide si pu` o creare un buer contenente larray dei vertici e un altro buer contenente gli indici nellordine secondo cui le coordinate dei vertici devono essere lette e disegnate a schermo attraverso listruzione glDrawElements. Il disegno di una mesh, quindi, ` e possibile se prima si ` e instanziato correttamente il buer contenente i vertici della stessa. Ci sono essenzialmente 69

due modalit` a di creazione del buer: 1. buer contenente i vertici della mesh e buer degli indici: in tale caso si deve instanziare un buer con le coordinate dei vertici e un buer con linformazione su come i vertici sono collegati. Ci` o` e possibile grazie alla lettura delle facce della mesh che contengono gli indici dei vertici che le compongono. Listruzione di disegno deve quindi sfruttare entrambi i buer come descritto in precedenza. 2. buer con i vertici ripetuti: in pratica si crea un unico buer con tutti i dati in relazione alle facce del modello. Per ogni faccia f si genera nel buer una locazione per ogni vertice v di f e allinterno di ogni locazione si memorizza la posizione, le coordinate texture, il colore e le normali del vertice relativo. Dato che un singolo vertice pu` o appartenere a pi` u facce, si ottiene una ripetizione delle informazioni riguardanti il vertice nel VBO. Tra le due alternative la seconda ` e sfruttata dalla libreria Min3D utilizzata per il caricamento della mesh. Perci` o il buer dei vertici del modello in realt` a possiede informazioni ripetute. Tale approccio risulta fondamentale in quanto il le della mesh spesso contiene, per ogni vertice, molteplici informazioni su coordinate texture e normali secondo le facce a cui il vertice stesso appartiene. Ad esempio il vertice v1 appartenente alle facce f1 ,f2 e f3 pu` o avere associate le coordinate texture vt1 ,vt2 e vt3 e le normali vn1 ,vn2 e vn3 relative a tali facce. Per memorizzare queste informazioni e ad esempio per non ricalcolare le normali di ogni faccia (dato che sono gi` a esplicitate nel le), ogni vertice ` e rappresentato pi` u volte con la sola informazione sulla normale o sulla coordinata texture cambiata e linformazione sulla posizione non alterata. Questo approccio non risulta un grande problema a livello di disegno in quanto la versione ES ` e ottimizzata per una lettura veloce del buer, ma, come illustrato in seguito, ci` o determina dei problemi quando si vanno a modicare le posizioni dei vertici nella simulazione sica.

70

4.3.2

Integrazione delle API di OpenGL ES

Ci sono due classi fondamentali nel framework di Android che consentono di gestire la graca: GLSurfaceView e Renderer. La prima ` e la classe responsabile della creazione della nestra al cui interno si generano le operazioni di rendering. Allinterno di unattivit` a si deve instanziare questa classe al ne di visualizzare la graca 3D disegnata con OpenGL attraverso la nestra. GLSurfaceView utilizza linterfaccia EGL per gestire la visualizzazione nella nestra. La classe descritta permette anche il decoupling delle operazioni di rendering dalle operazioni di gestione della UI. Ci` o` e molto importante per motivi di performance: il disegno della scena 3D e il disegno dellinterfaccia graca avvengono in due thread separati e inoltre la gestione dellinput avviene interamente nel thread della UI senza intaccare lesecuzione del rendering. Il Renderer ` e invece linterfaccia che denisce i metodi necessari al disegno con OpenGL. Questa interfaccia deve essere implementata e collegata allistanza di GLSurfaceView attraverso il metodo setRenderer. In particolare i seguenti metodi devono essere rideniti se si implementa il Renderer : onSurfaceCreated : il sistema chiama questo metodo una volta quando il GLSurfaceView viene creato. In pratica in questo metodo si possono denire tutti i parametri relativi allenvironment di OpenGL e tutto ci` o che deve essere inizializzato solo una volta. Si noti che il metodo ` e richiamato anche dopo un evento di resume: ci` o avviene, come descritto in precedenza, quando la Activity la cui vista ospita il GLSurfaceView ` e temporaneamente oscurata dalla vista di un altra Activity. Quando si chiude la nuova Activity e si ritorna alla precedente si genera un evento di resume che provoca un redraw della scena. onDrawFrame : il sistema chiama questo metodo ogni time-step per ridisegnare la scena 3D. Di default il time-step ` e impostato in modo tale da avere un frame rate costante. Esso pu` o variare secondo le performance del dispositivo e dipende dal tempo impiegato per le operazioni di rendering. In questo caso la simulazione sica cambia frequentemen71

te le posizioni dei vertici e con tale metodo si pu` o aggiornare il disegno con le nuove coordinate. onSurfaceChanged : il sistema chiama questo metodo quando la geometria del GLSurfaceView cambia. Questo pu` o avvenire quando ad esempio la dimensione della nestra cambia in base allorientamento del device. Durante tale evento si deve cambiare il vettore di ViewPort dello stato di OpenGL poich` e esso necessita dellaltezza e della larghezza corrente della nestra in cui ` e visualizzata la scena. Anche la matrice di proiezione e il frustum di vista devono essere reimpostati in modo che la scena sia disegnata con le nuove prospettive. Le API della libreria graca possono variare secondo la versione della libreria adottata nello sviluppo. Ci sono in tutto tre versioni disponibili: 1.0,1.1 e 2.0. Si dierenziano principalmente nelle speciche e nei device che le supportano, in particolare la 1.1 e la 2.0. Alcuni device possiedono quindi un hardware pi` u avanzato che supporta la versione 2.0, altri invece pi` u datati e con hardware meno performante supportano solo la 1.1. Per lapplicazione in sviluppo si ` e scelto di utilizzare la versione 1.1 in quanto maggiormente diusa rispetto alla versione 2.0. Inoltre le speciche dellultima versione non portano ad un concreto vantaggio nella programmazione di questo lavoro di tesi rispetto alle precedenti versioni.

4.4

La libreria Min3D

Il lavoro di tesi prevede la simulazione di corpi deformabili su mesh caricate e visualizzate su dispositivi mobili. La gestione di questi ultimi due compiti si avvantaggia dellutilizzo di librerie dedicate. Esistono diverse soluzioni multi piattaforma che orono non solo supporto al caricamento ma anche alla gestione del modello, delle luci, dellambientazione ecc. Una delle librerie di libero utilizzo poich` e open source e utile agli scopi descritti in precedenza ` e Min3D. Essa non ` e disponibile per altre piattaforme ma rappresenta, tuttavia, un buon punto di partenza per capire ladattamento della graca 3D su device Android. Consente di caricare e gestire sulla scena diversi modelli 3D 72

salvati in le di vari formati come OBJ e MAX3DS (estensione dei le creati con 3D Studio Max). Le classi della libreria sono interamente scritte in Java e possono essere inglobate nel progetto in sviluppo.

4.4.1

Moduli software

I moduli software della libreria sono schematizzati in gura 4.3. Dai dati su disco i metodi della classe Parser permettono di estrarre le informazioni rigurardanti vertici e facce e impostare i VBO. Tutti i dati di un oggetto sono racchiusi nella classe Object3d che rappresenta la mesh nellambiente di programmazione. Solitamente le strutture dei le sono tali da ospitare i dati riguardanti una sola mesh, ma ne possono contenere anche molteplici. Per tale motivo tutte le istanze dei modelli caricati sono contenuti in una classe contenitore: Object3dContainer. La scena e le relative variabili sono impostate tramite la classe Scene che pu` o contenere pi` u istanze di Object3dContainer al suo interno. In questo modo si possono gestire pi` u oggetti, letti da le diversi, contemporaneamente nella scena. Tutta la scena con i relativi oggetti viene utilizzata dalla classe Renderer per la rappresentazione sullo schermo. Tale classe ` e un implementazione dellinterfaccia Renderer denita nel SDK e in essa quindi si realizzano tutti i metodi che sfruttano le API di OpenGL ES come precedentemente illustrato.

73

Figura 4.3: Schema generale dei moduli software della libreria Min3D

4.4.2

RendererActivity

Il ponte tra il disegno della scena e linterazione dellutente ` e rappresentato dallattivit` a RendererActivity. Essa gestisce la nestra in cui il modello 3D ` e ragurato e lattivit` a Obj3dView ne ` e unimplementazione. Infatti, tramite questa classe, si gestisce da un lato la UI e gli input e dallaltro si inviano informazioni al Renderer impostando gli oggetti da disegnare, le eventuali trasformazioni applicate ad essi e le informazioni riguardanti gli input utili a gestire la simulazione sica. Per gestire la graca, si instanzia nel metodo onCreate() il GLSurfaceView e il Renderer. I diversi metodi implementati sono eseguiti in thread separati, alcuni di essi saranno chiamati dal thread della UI, altri dal thread dedicato al rendering secondo le operazioni che si devono svolgere. Segue una descrizione

74

delle funzionalit` a legate ai metodi principali indicando anche da quale thread essi vengono eseguiti. initScene : si delineano gli oggetti 3D ed i parametri della scena come ad esempio lilluminazione. Il parsing viene eettuato in questo metodo che viene richiamato dal Renderer solo la prima volta che viene ragurata la scena. Ci` o pu` o avvenire anche in seguito a un evento di resume dovuto al fatto che unaltra Activity ` e stata eseguita per un certo tempo oscurando la vista del RendererActivity. updateScene : si operano le trasformazioni geometriche a cui ` e sottoposto loggetto. Ad esempio traslazioni e rotazioni vanno applicate in questo metodo in quanto esso ` e richiamato ad ogni aggiornamento del rendering. Il thread dedicato alla graca richiama le istruzioni del metodo in questione in onDrawFrame() ad ogni time-step. onInitScene e onUpdateScene : i metodi sono gestiti, dierentemente dai precedenti, dal thread della UI e richiamati al termine rispettivamente di initScene e updateScene. La loro funzionalit` a` e quella di noticare levento di termine dellesecuzione del rispettivo metodo da parte del thread graco. Ad esempio il termine del metodo initScene implica che il modello ` e stato caricato con successo e quindi si pu` o noticare ci` o allutente tramite la UI.

75

Figura 4.4: modello

Flussi di esecuzione separati dellattivit` a di visualizzazione del

4.4.3

Supporto alle texture, allilluminazione e agli shader

La visualizzazione di una mesh spesso implica il caricamento e la visualizzazione anche di immagini. Questultime sono utilizzate per eettuare il texture mapping del modello 3D. La libreria consente di gestire le texture rendendo le mesh particolarmente realistiche grazie anche a tecniche che consentono di ridurre laliasing, e quindi aumentare la qualit` a complessiva dellimmagine. Si noti che nonostante il supporto ad un numero indenito di texture della libreria spesso i device non possono caricare tutte le texture in memoria a causa delle varie limitazioni hardware che possiedono e quindi solo la prima texture verr` a caricata dal Renderer e le restanti semplicemente ignorate. Oltre a ci` o la libreria permette di gestire lilluminazione della scena consentendo laggiunta di molteplici fonti di luce nella scena e calcolando la

76

giusta illuminazione delloggetto grazie alle normali delle facce di cui si compone. Inne non sono direttamente implementati nuovi shader ma si utilizzano quelli gi` a presenti in OpenGL ES, si ore comunque il supporto ad un eventuale introduzione di nuovi shader.

4.4.4

Limiti

La libreria non ` e molto supportata ed inoltre non ` e completa per raggiungere tutti gli obiettivi di questo lavoro di tesi. In primo luogo ` e concesso il caricamento del modello e della texture solo da memoria interna dellapplicazione: ci` o implica che questi le devono essere salvati come risorse interne a tempo di compilazione. Anche le varie opzioni di rendering, ad esempio se disegnare la scena in modalit` a wireframe, non possono essere impostate durante lesecuzione. La gestione dellinput ` e assente ma ` e facilmente integrabile nella RendererActivity grazie alle API del SDK. Piuttosto la dicolt` a maggiore risulta la simulazione sica a causa di alcune carenze nella fase di parsing: non vengono salvate le informazioni relative alle coordinate dei vertici e agli indici delle facce originali del modello. Infatti, dopo loperazione di parsing del le, la libreria mantiene in memoria solamente i buer di vertici e facce che consentono il disegno (VBO). In particolare il buer contenente le coordinate dei vertici ` e costruito col secondo metodo esposto in 4.3.1 e il buer relativo alle facce mantiene in memoria gli indici di ogni singola faccia, ma tali indici si riferiscono alla posizione del vertice nel VBO dei vertici. La simulazione non pu` o basarsi sulle informazioni dei buer salvati: essi contengono informazioni duplicate che genererebbero un numero doppio di computazioni. Si devono perci` o operare dei cambiamenti nel codice della libreria per implementare in modo opportuno tutte le speciche richieste.

77

4.5

Sviluppo

Lapplicazione in esame deve da un lato gestire la rappresentazione graca e dallaltro gli input dellutente. Si deve inoltre rendere usabile il software attraverso una UI intuitiva e semplice oltre che funzionale. La libreria in uso presenta alcuni limiti che impediscono di sviluppare con facilit` a alcuni dei compiti pressati. Nei successivi punti si spiegano le modiche svolte al codice di partenza della libreria e le integrazioni inserite per ottenere il risultato nale.

4.5.1

Avvio dellapplicazione

Alla partenza dellapplicazione la Activity avviata ` e View3dActivity la cui schermata ` e minimale e adatta ad introdurre gli unici comandi eseguibili inizialmente dallutente. La scena 3D non ` e ancora creata e quindi lutente pu` o richiamare il caricamento del modello attraverso lopzione Load Model. Si noti che tale attivit` a, essendo la prima ad entrare nello stack di memoria sar` a anche lultima ad uscirne. Ci` o implica che essa rimarr` a nello stato di pausa mentre la visualizzazione del modello ` e attiva in un altra Activity, e verr` a richiamata quando tale Activity verr` a chiusa. Tutto ci` o rende lapplicazione molto funzionale in quanto lutente pu` o caricare diversi modelli durante lesecuzione senza chiudere denitivamente il software ogni volta.

78

Figura 4.5: Schermata visualizzabile allavvio del software

4.5.2

Caricamento dei le

La libreria non consente il caricamento da memoria secondaria, si introducono quindi delle integrazioni nel codice che consentono di accedere ai le specicati dallutente. Si possono gestire i le sulla memoria di massa conoscendone il path completo. Questo ` e costituito da due parti: la prima riguarda la posizione della memoria esterna allinterno del le system, mentre la seconda riguarda la posizione del le scelto dallutente. Un esempio di path completo ` e il seguente: /storage/sdcard0/prova/model.obj La prima parte del path (/storage/sdcard0) va ricavata attraverso le API del SDK dato che non ` e ssa per ogni dispositivo. La seconda invece va richiesta allutente attraverso la UI. Esempi di interazione sono visibili nelle seguenti gure.

79

Figura 4.6: Interfaccia graca per linserimento dei path di modello e texture

Per maggiore usabilit` a sono introdotti dei controlli sul path inserito al ne di: controllare che il le esista e possa essere letto; vericare che lortograa della stringa sia corretta (per es. stringa vuota).

4.5.3

Fase di parsing

Il parsing del le ` e loperazione principale di impostazione della scena in quanto ` e qui che si inizializza la maggior parte delle istanze su cui si lavorer` a in seguito durante linterazione dellutente e la simulazione sica. La libreria Min3D ore supporto al parsing di diversi tipi di le ma si ` e posta maggiore attenzione nellestensione OBJ dato che ` e molto diusa e utilizzata in questo ambito [12]. La struttura del le, come anticipato nel capitolo 2, ` e molto semplice e al suo interno sono scritte le posizioni dei vertici, le coordinate U,V

80

delle texture per ogni vertice, le normali e le facce. Per questultime si memorizzano gli indici dei vertici che le compongono in ordine orario rendendo lesplicitazione delle normali delle facce non necessaria. La lettura del le ` e perci` o di facile comprensione e in questa fase si possono operare delle modiche alla libreria al ne di recuperare e salvare linformazione relativa alle coordinate dei vertici e gli indici originali delle facce per i motivi precedentemente citati. E durante il parsing che vengono calcolati anche i lati della mesh e viene letto il le di tipo MTL che specica lilluminazione dei materiali o le texture [13].

4.5.4

Visualizzazione del modello al centro di vista

Le coordinate dei vertici della mesh potrebbero essere rappresentate oltre il frustum di vista e quindi alcuni modelli potrebbero addirittura non essere visibili al caricamento della scena a meno che lutente non eettui uno scaling adeguato tramite le gesture di zoom. Per tale motivo ` e opportuno traslare e scalare il modello in modo che si trovi al centro della nestra generata dallActivity Obj3dView. Il fattore di scala dipende in primo luogo dalla posizione della camera nello spazio 3D ed in secondo luogo dalla diagonale del modello. Il fattore di traslazione ` e anchesso non costante ed ` e dipendente dalla posizione del centro del modello rispetto al centro geometrico della scena. La diagonale e il centro del modello possono essere facilmente calcolati tramite la bounding box.

4.5.5

Sviluppo della simulazione sica

Soddisfacimento dei vincoli Per gestire la simulazione di oggetti deformabili si introducono diverse classi e metodi. La classe pi` u importante che permette di gestire il soddisfacimento dei vincoli ` e MassSpringSystem. Le informazioni riguardo le posizioni attuali o originarie dei vertici, gli indici delle facce, gli edge, i gradienti dei vertici, il volume della mesh originario

81

sono mantenuti in tale classe in liste ed array per far s` che i metodi di soddisfacimento dei vincoli implementati possano usufruire di queste informazioni e cambiarle alloccorrenza. I metodi sviluppati pi` u importanti che rendono possibile la simulazione secondo gli approcci visti nel precedente capitolo sono i seguenti: initialize : nella fase di inizializzazione della scena questo metodo viene richiamato per impostare posizioni dei vertici, indici delle facce, edge, gradienti, volume della mesh ecc. satisfyConstraints : questo metodo viene richiamato ad ogni time step e permette di risolvere in sequenza i vincoli riguardo il picking, le distanze sugli edge ed il volume della mesh. Chiaramente si sfrutta la tecnica di rilassamento mostrata nel precedente capitolo, quindi in una chiamata del metodo non ` e detto che tutti i vincoli siano risolti, piuttosto si opera un passo verso la soluzione nale. Al termine del rilassamento parziale dei vincoli si eettua un aggiornamento delle posizioni dei vertici nel buer da cui si eettua il rendering. Si ricorda che in tale buer i vertici sono ripetuti perci` o si deve aggiornare la posizione del vertice pi` u volte. Questa operazione ` e lineare in quanto si sfruttano gli indici contenuti nel buer delle facce per ricavare le posizioni dei vertici da aggiornare nel VBO dei vertici su GPU. Picking Loperazione di selezione e trascinamento di un vertice del modello ` e possibile con le tecniche descritte in precedenza: occorre dunque costruire la retta di proiezione dal punto di tocco dello schermo e una griglia che consenta di partizionare i vertici su cui eettuare il test delle distanze dalla retta stessa. La costruzione della retta avviene nel Renderer perch` e si deve leggere lo stato di OpenGL corrente, in particolare le matrici ModelView e Projection. La griglia invece pu` o essere determinata in fase di inizializzazione del modello e diventa una propriet` a delloggetto 3D.

82

Il calcolo del vertice a distanza minima avviene sempre nel Renderer come descritto nella sezione 3.4.5 e viene inviato al MassSpringSystem per la determinazione del vincolo di picking. Al termine del trascinamento del vertice e della risoluzione dei vincoli si eettua un nuovo mapping delle coordinate dei vertici sulla griglia dato che esse sono cambiate a causa della risoluzione dei vincoli. Ci` o consente di eettuare una nuova operazione di picking sui vertici spostati.

4.5.6

Gestione dellinput

La natura touch screen dei dispositivi in cui lapplicazione verr` a eseguita porta a gestire in modo molto pi` u accurato i diversi input dellutente. Come mostrato nel precedente capitolo i movimenti che lutente pu` o eettuare sono diversi, secondo le funzionalit` a che si vogliono attivare. Tutta la gestione avviene nellattivit` a dedicata alla UI ossia Obj3dView che in un thread separato dal thread di disegno della scena 3D avvia un listener sugli eventi derivati dal tocco del display. Le API del SDK permettono di catturare no a dieci tocchi simultanei dello schermo ma chiaramente al massimo due verranno utilizzati in ogni occasione nel software in sviluppo. Inoltre ` e possibile catturare la tipologia di evento generato, che esso sia solo un TOUCH (tocco del display e rilascio) o un DRAG (tocco del display e trascinamento). La rotazione e il picking sono due operazioni che coinvolgono una stessa tipologia di movimento: il dragging. Bisogna produrre una certa logica anch` e lutente possa scegliere se ruotare o trascinare un vertice della mesh. La soluzione pi` u semplice consiste nellimplementare un opzione che permetta di disattivare o meno la rotazione. Se essa ` e disabilitata la simulazione sica viene avviata e in ogni time-step viene richiamato il soddisfacimento dei vincoli nel MassSpringSystem prima del rendering. Se invece la rotazione ` e abilitata si sfrutta la matematica dellArcball per computare la matrice di rotazione da moltiplicare alla ModelView corrente delloggetto. In particolare sono introdotte una serie di classi con le quali ` e possibile eettuare i calcoli di rotazione dellArcBall ed ottenere la matrice

83

di rotazione. Essa verr` a poi passata allo stato di OpenGL tramite il metodo updateScene di Obj3dView. In aggiunta, per meglio identicare lo stato della rotazione corrente, si introduce il disegno dellArcball in cui ` e idealmente racchiuso loggetto durante la rotazione.

Figura 4.7: Disegno dellArcball per controllare visivamente la rotazione applicata al modello

Il riconoscimento delle due modalit` a` e molto utile non solo per la gestione dellinput ma anche per la fase di rendering poich` e durante la rotazione i calcoli da eettuare saranno sicuramente minori rispetto alla fase di simulazione sica. Il movimento del pinch to zoom ` e supportato sia durante la simulazione che durante la rotazione in quanto esso non interferisce con le due fasi servendosi di due tocchi simultanei. Il fattore di scaling ricavato verr` a utilizzato dal thread del rendering per applicare la trasformazione con le API di OpenGL al modello.

4.5.7

Men` u e preferenze

Labilitazione o meno della rotazione e altre impostazioni sono raggiungibili attraverso la pressione del tasto men` u. Le speciche di Android hanno sempre 84

imposto la presenza di tale tasto sico e solo ultimamente il sistema si ` e svincolato da questa propriet` a e sui dispositivi pi` u recenti esso appare sotto forma di tasto virtuale sullo schermo quando occorre. Su ogni device la pressione del tasto apre il men` u ossia una serie di opzioni selezionabili dallutente. Per rendere pi` u usufruibile linterfaccia, nel men` u sono riposti solo i comandi utilizzati pi` u frequentemente: opzione per disabilitare la rotazione ed opzione per ricaricare il modello con le coordinate originali. Il resto delle impostazioni selezionabili ` e riposto in una schermata separata apribile con il tasto Settings.

Figura 4.8: Men` u visualizzato in basso nella schermata di Obj3dView. Nella fascia in basso si pu` o visualizzare anche il set di tasti virtuali tipico di dispositivi Android privi di tasti sici, il tasto men` u` e quello pi` u a destra.

Gli elementi del men` u sono deniti nel le menu.xml contenuto tra le risorse dellapplicazione. La funzione di Reload ` e utile nel momento in cui lutente vuole ricaricare in memoria il modello. Si deve inizializzare di nuovo la scena richiamando il metodo initScene cos` da rieettuare il parsing del le e ripristinare tutti i valori originali delle coordinate dei vertici. La pressione dellopzione Settings determina lapertura dellattivit` a SettingsActivity che gestisce la schermata riguardante le preferenze dellutente. Ogni applicazione Android ` e corredata di un le allinterno della memoria di sistema chiamato SharedPreference adatto proprio a mantenere i dati di preferenza dellutente in maniera consistente anche dopo la chiusura dellapplicazione stessa. Si ha a disposizione, quindi, un metodo pratico per mantenere le impostazioni e lunico compito da svolgere ` e denire le opera85

zioni possibili dellutente e impostare quando e perch` e leggere o scrivere le preferenze.

Figura 4.9: Schermata delle impostazioni

La denizione degli elementi selezionabili allinterno della schermata delle impostazioni ` e sempre possibile attraverso un le XML chiamato preference. In tale schermata si vogliono gestire diverse funzionalit` a di contorno rispetto a quelle gi` a descritte e le diverse preferenze sono suddivise in base al campo in cui si applicano. In particolare si vuole gestire opzioni che riguardano le texture, il disegno della mesh e la deformazione del modello. Preferenze sulle texture Lutente pu` o scegliere se visualizzare o meno la texture. Se lopzione non ` e selezionata la texture non viene considerata, sempre se esiste, nella lettura del le MTL. 86

Invece la selezione di Load texture from internal memory consente di immettere il path della nuova texture da caricare. Essa si andr` a a sostituire a quella di default presente per il modello. Si noti che queste operazioni coinvolgono la fase di parsing durante la quale sono impostate e caricate le texture del modello, per cui ` e necessario rieettuare il parsing per ottenere il modello con le nuove preferenze. Il le MTL collegato al modello non viene modicato, i cambiamenti riguardano esclusivamente la texture che deve essere caricata in memoria per essere poi mappata sul modello in fase di rendering.

Figura 4.10: Modello visualizzabile senza texture (a sinistra) o con texture (a destra)

Preferenze di disegno Per quanto riguarda il rendering della mesh si pu` o scegliere se visualizzare il modello ad esempio in modalit` a wireframe. La pressione dellopzione render type consente di cambiare la modalit` a di visualizzazione, scegliendo nellelenco dei parametri riportati secondo la terminologia di OpenGL.

87

Figura 4.11: Scelta della modalit` a di disegno della mesh

Preferenze sulla rotazione La rotazione pu` o essere disabilitata anche in questa schermata oltre che nel men` u. Lattivazione o disattivazione dellopzione rendono visibile una scritta contestuale che indica se la deformazione ` e attiva o meno. Inoltre lutente pu` o indicare se visualizzare o meno il disegno dellArcBall.

Figura 4.12: Opzione di rotazione con informazione sullabilitazione contestuale della deformazione

88

Impostazione dei parametri della simulazione Attraverso le impostazioni si pu` o modicare il valore dei parametri kpressure e kdist che condizionano la simulazione (si veda sezione 3.4.3). Questi parametri sono utilizzati nel delta di correzione della posizione dei vertici in relazione al vincolo sulla lunghezza degli edge e al vincolo sul volume globale della mesh. I parametri sono compresi nel range [0...1] e possono essere modicati attraverso uno slider dallutente. Lo slider relativo al kdist pu` o assumere valori compresi tra 0.1 e 1: il valore di default ` e 1 (le distanze ritornano al valore originale) mentre il valore minimo non scende al di sotto di 0.1 per non rimuovere totalmente leetto del vincolo. Lo slider relativo a kpressure , invece, pu` o assumere valori da 0 a 1: un valore 0 rimuove leetto del vincolo di volume, 1 ` e invece il valore di default e comporta il ritorno delloggetto al volume originario.

Figura 4.13: Slider per il cambiamento del parametro kdist , il cambiamento del parametro kpressure avviene in maniera simile.

89

Salvataggio dello stato Per come ` e strutturata unapplicazione Android il ritorno alla schermata di un Activity in pausa genera un evento di resume su tale attivit` a che comporta un ridisegno della scena. La libreria, tuttavia, non ` e strutturata in modo tale da salvare tutto il contesto mentre la RendererActivity ` e in fase di pausa. Per tali motivi alla chiusura delle impostazioni la scena viene reinizializzata. Ci` o pu` o comportare tempi di attesa pi` u lunghi soprattutto se la mesh possiede numerosi vertici e facce. Per alleggerire il carico di lavoro richiesto al resume si salvano alcuni elementi che non devono essere riaggiornati, ad esempio il calcolo della griglia, il calcolo degli edge della mesh ecc. Oltre a ci` o, per non perdere linformazione riguardo i vertici traslati per la simulazione, la congurazione dei buer viene salvata prima dello stato di pausa e alloccorrenza ripristinata.

90

Capitolo 5 Test e risultati


In questo capitolo si mostra un analisi sui risultati dellimplementazione sviluppata su piattaforma Android per descrivere cosa permettono di ottenere le tecniche illustrate. Si eettua in primo luogo unindagine sui dati riguardanti loccupazione di memoria primaria che solitamente su piattaforma mobile ` e limitata. Quindi si descrivono le tempistiche necessarie per portare a termine le principali operazioni legate alla simulazione. Inne si mostrano i risultati pratici ottenibili lavorando sui parametri in gioco nella simulazione che permettono di modicare i vincoli sulle distanze tra le particelle e i vincoli sul volume complessivo della mesh.

5.1

Analisi delle prestazioni

La seguente analisi prestazionale ` e eettuata su un Samsung Galaxy Nexus, dispositivo che vanta una piattaforma hardware comprendente un processore dual-core da 1200 Mhz con una scheda graca PowerVR SGX 540 e una memoria RAM installata di 1 Gigabyte. I risultati mostrati sono una media di diverse osservazioni riguardo le tempistiche che occorrono per eettuare diverse operazioni del software. In particolare si espongono i tempi per eettuare la fase di parsing, la fase di picking e il tempo richiesto da uno step di risoluzione dei vincoli e il

91

conseguente aggiornamento in memoria delle nuove coordinate dei vertici. Oltre a ci` o si espone loccupazione di memoria media. Per meglio eettuare un confronto si espongono i tempi relativi a tre modelli diversi le cui caratteristiche si discostano per numero dei vertici, numero delle facce e numero degli edge. Nella seguente tabella sono riassunte le analisi eettuate nei tre casi dierenti e segue una discussione su ogni test eettuato. Modello 1 Modello 2 Modello 3 Vertici Facce Edge Occupazione memoria Tempi parsing Tempi picking 340 680 1000 21 MB 608 ms 4 ms 882 1760 2630 24 MB 710 ms 8 ms 26 ms 6000 12000 18386 30 MB 2783 ms 32 ms 250 ms

Tempi risoluzione vincoli 12 ms

Tabella 5.1: Analisi prestazionale: confronto tra tre modelli diversi

5.1.1

Occupazione di memoria primaria

Loccupazione di memoria RAM ` e in generale non eccessiva e dipende non solo dalla grandezza del modello in termini di vertici, facce e lati ma anche dalle texture che sono allegate al modello stesso. Le tre texture utilizzate per i modelli in questione hanno una risoluzione e una grandezza simile quindi i valori mostrati possono essere confrontati. I device Android dispongono solitamente di un quantitativo di memoria RAM adeguato a contenere le risorse dellapplicazione.

5.1.2

Tempo della fase di parsing

Nella fase di parsing le tempistiche dipendono sia dalla lunghezza del le della mesh da leggere che dai calcoli relativi allinizializzazione dei vincoli strutturali. E in tale fase infatti che si devono calcolare: la lista di vertici, 92

facce e degli edge; le lunghezze a riposo degli edge; i gradienti dei vertici; lindicizzazione dei vertici nella griglia; il volume originario della mesh oltre che allocare opportunamente i VBO. Non sorprende quindi che allaumentare della complessit` a del modello aumenta notevolmente il tempo di attesa per il caricamento in memoria.

5.1.3

Tempo per il picking

Loperazione di picking dei vertici non ` e banale e come illustrato in precedenza si compone di numerose computazioni. Lintroduzione della griglia permette di ridurre notevolmente i tempi di ricerca del vertice a distanza minima dalla retta di picking. Durante questa fase si deve: calcolare la retta di picking, mappare la retta sulla griglia, determinare il vertice a distanza minima in ogni cella, calcolare il vertice pi` u prossimo allo schermo utilizzando la ModelView. In tutti e tre i casi si ottengono comunque risultati accettabili.

5.1.4

Tempo per uno step di risoluzione dei vincoli

La risoluzione dei vincoli ` e unoperazione che avviene in diversi time-step a causa del metodo iterativo utilizzato. E importante quindi osservare il tempo che si necessita per ogni singolo step di rilassamento parziale in quanto esso condiziona il frame-rate dellapplicazione. In tabella sono riportati i tempi di un singolo step e non si riporta il tempo totale di risoluzione dei vincoli poich` e esso varia in dipendenza della struttura del modello e della deformazione correntemente applicata ad esso. I tempi misurati dimostrano come il terzo caso sia un limite per le risorse computazionali dato che il tempo per uno step ` e elevato e ci` o non garantisce unanimazione convincente, il valore di fps ` e molto basso. In eetti le operazioni si complicano allaumentare del numero di vincoli, a sua volta condizionato dal numero complessivo di vertici, edge e facce. Oltre al tempo richiesto per il rilassamento bisogna considerare anche un certo tempo di aggiornamento delle posizioni nei VBO in memoria, il ch` e aumenta notevolmente se il numero di vertici e facce ` e elevato. 93

Il secondo modello, invece, rappresenta un caso di complessit` a geometrica in cui il valore di fps ` e ben al di sopra del valore minimo di 25 fps. Il software implementato riesce perci` o a gestire ecacemente mesh il cui numero di vertici, edge e facce ` e non eccessivamente superiore al modello in questione. Nel caso peggiore di una mesh molto complessa sarebbe opportuno adottare altre tecniche che consentano di creare una struttura allinterno della mesh e quindi di operare sui vincoli determinati in base a tale struttura. Il principio ` e lo stesso del ragdoll esposto nel secondo capitolo, ossia la mesh poligonale pi` u complessa ` e legata al ragdoll la cui struttura ` e semplice e, conseguentemente, il numero di vincoli non risulta eccessivo.

94

5.2

Eetti della simulazione

In questa sezione si mostrano, attraverso degli screenshot eettuati durante lesecuzione dellapplicazione sul dispositivo, gli eetti della simulazione se si cambiano i parametri kdist e kpressure che vengono utilizzati per la risoluzione dei vincoli di tipo distance e di overpressure. Il valore di tali parametri ` e limitato nel range [0...1] e lutente pu` o liberamente modicarli tramite la schermata delle impostazioni. Si ricorda che un valore molto basso per tali parametri in pratica rimuove leetto del vincolo relativo, mentre un valore alto prossimo a 1 determina un ritorno delloggetto ad una forma vicina alloriginale.

5.2.1

Simulazione 1: assenza delleetto dei vincoli

Nella simulazione di seguito mostrata si fa uso di kdist = 0.1 e kpressure = 0. Tali valori sono relativamente bassi e comportano una deformazione importante per loggetto. Il vincolo sul volume ` e praticamente assente mentre il vincolo sulle distanze degli edge comporta che questi ultimi ritornino solo al 10 % della distanza originale. Loggetto utilizzato ` e una sfera in quanto consente di osservare in modo diretto i cambiamenti alla sua struttura dovuti alla simulazione.

95

Figura 5.1: Simulazione 1 con kdist = 0.1 e kpressure = 0: si parte dalla immagine (a), lutente pu` o modicare loggetto trascinando il vertice come in (b), in (c) si mostra il progresso della simulazione che termina come mostrato in (d), si noti che la forma delloggetto risulta compromessa.

96

5.2.2

Simulazione 2: indipendenza delle due tipologie di vincolo

In questa simulazione si mostra leetto del cambio dei valori di kdist e kpressure su una sfera: in particolare si parte da una deformazione con kdist = 0.1 e kpressure = 0, quindi si mostra la deformazione attivando i vincoli di volume con kpressure = 1, inne si mostra leetto del cambio del parametro kdist a 1 mantenendo kpressure = 1. Quando si attivano i soli vincoli di overpressure sulle particelle si nota che il ritorno alla forma originale non ` e aatto garantito: loggetto a causa della congurazione di partenza tende ad allungarsi per ritornare al volume originale.

Figura 5.2: Simulazione 2: eetto del cambio dei parametri, prima kpressure e poi kdist . A sinistra kpressure = 0, kdist = 0.1; al centro kpressure = 1, kdist = 0.1; a destra kpressure = 1 e kdist = 1.

5.2.3

Simulazione 3: variazione del parametro di tipo distance

Nella simulazione mostrata in Fig. 5.3 si parte con un oggetto deformato con kdist = 0.1 e kpressure = 1, quindi si procede ad aumentare il valore di kdist a 0.5 e a 1. Si vuole mettere in risalto il fatto che tali vincoli sono entrambi importanti per mantenere la struttura delloggetto. Infatti, anche con un valore alto di kpressure , la forma delloggetto risulta comunque compromessa 97

(si veda limmagine iniziale della seguente gura). Se si modica opportunamente loggetto, il volume rimane invariato anche se la forma ` e diversa dalloriginaria.

Figura 5.3: Simulazione 3: variazione di kdist . A sinistra kpressure = 1, kdist = 0.1; al centro kpressure = 1, kdist = 0.5; a destra kpressure = 1 e kdist = 1.

5.2.4

Simulazione 4: variazione del parametro di tipo pressure

Gli eetti mostrati nella seguente gura descrivono quanto il parametro kpressure condizioni la forma delloggetto. Si passa da un valore di 0.1 a 0.5, quindi a 1, mantenendo il valore di kdist costante uguale a 1. Se si applicano delle modiche alla struttura della sfera come nellimmagine iniziale, aumentando il valore di kpressure si ottiene un rigonamento delloggetto al ne di raggiungere il volume denito.

98

Figura 5.4: Simulazione 4: cambio del parametro kpressure da 0.1 (a sinistra), 0.5 (al centro) e 1 (a destra)

5.2.5

Simulazione 5: inuenza dei vincoli su una mesh complessa

La seguente simulazione riporta gli eetti del cambio dei parametri su una mesh pi` u complessa. Da una situazione stazionaria si modica loggetto con kdist = 0.1 e kpressure = 0, quindi si attiva prima il vincolo di volume con kpressure = 1 e inne si aumenta il valore di kdist a 1. Nonostante si esegua una deformazione in molti punti della mesh, il sistema mass-spring riesce a ridenire una struttura molto simile alloriginale grazie alle due tipologie di vincolo implementate. Le osservazioni fatte nelle simulazioni precedenti riguardo oggetti geometricamente semplici si applicano senza problemi quindi anche a mesh dalla struttura pi` u complessa come quella ragurata in Fig. 5.5 che riprende le sembianze umane.

99

Figura 5.5: Simulazione 5: eetti del cambio dei parametri su una mesh pi` u complessa. In (a) situazione di partenza; in (b) deformazione con kdist = 0.1 e 100 kpressure = 0; in (c) deformazione con kpressure = 1 e kdist = 0.1; in (d) kdist = 1 e kpressure = 1.

5.2.6

Simulazione 6: ritorno alla forma originale

Dalle precedenti simulazioni si ` e potuto notare che in alcune situazioni la mesh non ritorna alla esatta forma originale dopo la deformazione. In eetti le uniche tipologie di vincolo implementate non bastano a garantire che la forma sia rispettata. Nellarticolo di Muller et al. [30] si denisce una tipologia aggiuntiva di vincolo che pu` o preservare meglio questo aspetto. Il vincolo di bending in questione permette di controllare langolo diedro tra due facce adiacenti e quindi non dipende dalla lunghezza dei lati dei triangoli. Garantendo che langolo sia prossimo alloriginale la mesh risulter` a meno deformata al termine della simulazione. Nella seguente gura si mostrano gli artefatti provocati dai vincoli implementati, in particolare si applica la stessa deformazione alloggetto in un caso con kpressure = 0 e nellaltro con kpressure = 1 mantenendo sempre kdist = 1.

101

Figura 5.6: Simulazione 6: in (a) situazione di partenza, sequenza in alto con kpressure = 0 e kdist = 1, sequenza in basso con kpressure = 1 e kdist = 1. In (c) e in (e) il termine della simulazione con le deformazioni rispetto alloriginale cerchiate. Si pu` o osservare come il rispetto dei vincoli di volume diminuisca il numero di deformazioni.

102

5.2.7

Simulazione 7: eetti su una mesh composta da pi` u oggetti

In generale le mesh possono avere una struttura e una geometria particolare, tale per cui alcune parti sono separate dal resto della mesh. Il modello si pu` o dunque comporre di pi` u oggetti, ognuno di essi ` e un sistema mass-spring separato con propri vincoli strutturali che non coinvolgono le particelle degli altri oggetti. Possiamo dunque considerare tali oggetti come sistemi isolati, in ognuno di essi la pertubazione del sistema dei vincoli ` e possibile solo se lutente interagisce con un vertice, quindi una particella, propria delloggetto. Lesempio mostrato dalle seguenti gure ne ` e un esempio lampante: il modello rappresenta un tipico caso di composizione di pi` u oggetti diversi. Linterazione dellutente comporta la risoluzione dei vincoli esclusivamente sulloggetto selezionato, il quale risulter` a traslato al termine del rilassamento, rispetto al resto della mesh, per eetto dei vincoli calcolati con parametri kpressure e kdist pari a 1.

Figura 5.7: Simulazione 7: eetti dellinterazione con una mesh composta da pi` u oggetti. A sinistra si mostra il modello nella situazione di partenza; al centro risultato della deformazione al termine del trascinamento; a destra termine del rilassamento dei vincoli: si nota che solo loggetto che contiene il vertice selezionato ` e interessato dalla simulazione. I parametri kpressure e kdist sono ssi a 1.

103

Capitolo 6 Conclusioni
In questa tesi si ` e presentato un framework basato sulle posizioni per simulare la dinamica di corpi deformabili che hanno strutture diverse. Questo tipo di simulatori possono avere molte applicazioni nellinformatica graca moderna. Dai videogiochi ai lm danimazione, sono due i parametri fondamentali da esaminare e spesso in contrapposizione: realismo ed interattivit` a. In ogni fase di progettazione della tesi si ` e tenuto conto di entrambi i fattori e, quando necessario, si ` e cercato di mediare per trovare un compromesso valido e soddisfacente. La prima scelta ha riguardato la struttura sica degli oggetti deformabili da animare. Il sistema basato su particelle e vincoli ha reso lalgoritmo molto semplice e, allo stesso tempo, molto potente. I corpi cos` creati possono essere animati facilmente secondo le leggi della sica e la loro dinamica risulta visibilmente pi` u che plausibile. Il framework realizzato, inoltre, utilizza anche un metodo per far s` che corpi deformabili chiusi possano tornare al volume iniziale anche dopo una deformazione. Questo allarga il numero di caratteristiche che gli oggetti animati possono avere aumentando, di conseguenza, anche i possibili scenari realizzabili. La gestione di tutte le operazioni necessarie alla simulazione ` e stata studiata negli ultimi anni su computer misurandone le performance e perci` o si ` e analizzato una possibile applicazione su dispositivi mobili. La scelta del si-

104

stema su cui testare il funzionamento ` e ricaduto su Android, uno dei sistemi operativi maggiormente diuso oggi su tale tipologia di device. Le caratteristiche hardware sono diverse e meno performanti rispetto a un computer e ci` o ha caratterizzato tutto lo sviluppo del progetto. Le librerie grache utilizzate hanno di per s` e dei limiti che si ` e dovuti superare per raggiungere gli obiettivi preposti. Oltre a questo si ` e eettuato uno studio sullinterazione dellutente che ` e chiaramente diversa rispetto ai classici mouse e tastiera. Le tecniche studiate per tali dispositivi di input sono state adattate per garantirne il funzionamento anche su device dal display tattile. Il risultato ottenuto ` e solo un punto di partenza, ma mostra gi` a in modo chiaro come il sistema sviluppato sia da un lato eciente in termini prestazionali e dallaltro visivamente ecace. Il sistema Android risulta, inoltre, una valida piattaforma di sviluppo, consente di sfruttare pienamente lhardware a disposizione e rende lapplicazione eseguibile su un largo insieme di dispositivi. La maggior parte di essi sar` a in grado di supportare senza problemi i numerosi calcoli al secondo grazie a processori e schede grache sempre di maggior potenza. In fondo tali device rappresentano lera post PC e quindi la nuova frontiera a cui linformatica graca va applicata.

6.1

Lavori futuri

Il sistema presenta dei limiti se le mesh caricate sono di grandi dimensioni e con molteplici vincoli creati a causa delle limitazioni hardware ma non solo. La tecnica spesso utilizzata per modelli poligonali complessi ` e quella di creare una struttura interna pi` u semplice sulla quale costruire la simulazione. E in fondo lo stesso principio del ragdoll visto in lavori come quello di Jacobsen [25], le mesh poligonali seguono il movimento del ragdoll e tutti i vincoli sono costruiti su questultimo e quindi non sullintera mesh. Chiaramente costruire uno scheletro adatto per ogni oggetto ` e unoperazione complessa e programmabile solo per modelli semplici o preimpostati. La creazione dei vincoli strutturali pu` o arricchirsi anche di vincoli pi` u 105

complessi come quelli di bending descritti da Muller et all. [30]. Infatti la costante di bending dipende dallangolo diedro tra due facce adiacenti e non dalla lunghezza dei lati dei triangoli. Ci` o pu` o determinare innanzitutto un maggior supporto a tante tipologie di modelli dalle caratteristiche completamente diverse tra loro e visivamente un maggior controllo della deformazione dei modelli, in particolare pu` o garantire un ritorno alla forma originale al termine della simulazione. Sarebbe interessante studiare una possibile applicazione di algoritmi anti-collisione su strutture particellari costruite in questo modo. La gestione della collisione di oggetti di questo tipo sarebbe non banale e una possibile applicazione in ambito mobile risulterebbe una notevole dimostrazione pratica. Oltre alle collisioni tra oggetti deformabili si potrebbero ad esempio studiare gli eetti della collisione di un oggetto deformabile con un corpo rigido. Un altra estensione possibile riguarda laggiunta di forze e quindi di accellerazioni che possono deviare le particelle dalla loro posizione originaria. Le leggi siche verrebbero utilizzate e calcolate tramite lintegratore di Verlet [26]. In questo modo si ottengono simulazioni siche realistiche senza gravare ulteriormente sulle prestazioni. Come si pu` o notare i miglioramenti apportabili al sistema dinamico sono molti, ma la dicolt` a maggiore risiede sicuramente nel convertire algoritmi e metodi di calcolo in modo tale da non eccedere nelle risorse utilizzate e nei tempi computazionali necessari su piattaforme mobili. La pertubazione del sistema di vincoli da parte dellutente ne ` e un esempio lampante: tale operazione non ` e aatto semplice e ha richiesto alcuni studi di applicabilit` a oltre che varie ottimizzazioni software. Questo lavoro di tesi rappresenta comunque una valida base tecnica per riprodurre su dispositivi mobili uno dei metodi migliori oggi disponibili per una simulazione sica convincente sia dal punto di vista strettamente matematico che dal punto di vista graco di corpi deformabili.

106

Bibliograa
[1] Android. www.android.com, 12 2012. [2] Speciche di OpenGL ES. http://www.khronos.org/registry/gles/ specs/1.1/es_cm_spec_1.1.12.pdf, 12 2012. [3] EdgeLib. www.edgelib.com, 12 2012. [4] Marmalade. www.madewithmarmalade.com, 12 2012. [5] Min3D. code.google.com/p/min3d/, 12 2012. [6] J.Foley, a.Van Dam, S.Feiner, J.Hughes. Computer Graphics: Principles and Practice. Addison-Wesley, 1990. [7] B.G. Baumgart. Winged-edge polyhedron representation. Technical report. [8] L.Kobbelt,S. Campagna, H.P. Seidel. A general framework for Mesh Decimation. University of Erlangen-Nurnber, 1998. [9] Leonidas, J. Guibas, J. Stol. Primitive for the manipulation of general subdivisions and the computation of voronoi diagrams. [10] Rossiignac, J. Safonova, Szymczak. A 3d compression made simple: Edgebreaker on a corner table. Proceeding of Shape Modeling International Conference, pages 278283, 2001. [11] C.Smith. On Vertex-Vertex Systems and their use in geometric and biological modelling. University of Calgary, 2006.

107

[12] Obj le. http://www.martinreddy.net/gfx/3d/OBJ.spec, 12 2012. [13] Mtl le. http://people.sc.fsu.edu/~jburkardt/data/mtl/mtl. html, 12 2012. [14] K. Shoemake. ARCBALL:a user interface for specifyng threedimensional orientation using a mouse. 1992. [15] Chen, Michael, Mountford, S.Joy, and Sellen, Abigail. interactive 3-d rotation using 2-d control devices. A study in

[16] Biedenharn, Louck. Angular Momentum in Quantum Physics: Theory and application. In As Encyclopedia of Mathematics and its applications, volume 8. Addison-Wesley, 1981. [17] K. Shoemake. Matrix Animation and Polar Decomposition. Graphics Interface 92 Proceedings, 1992. [18] K. Shoemake. Quaternions and 4X4 Matrices. Graphics Gems II, pages 351354, 1991. [19] Goldstein, Herbert. In Classical Mechanics. Addison-Wesley, 1980. [20] Breen, House, Wozny. Predicting the drape of woven cloth using interacting particles. Computer Graphics, pages 365372, 1994. [21] Bara, Witkin. Large steps in cloth simulation. Computer Graphics, 1998. [22] Fleischer, Terzopoulos. Deformable models. Visual Computer, pages 306331, 1998. [23] Terzopoulos, Platt, Barr, Fleischer. Elastically deformable models. Computer Graphics, pages 205214, 1987. [24] Nealen, Muller, Keiser, Boxerman, Carlson. Phisically based deformable models in computer graphics. Eurographics 2005 state of the art, 2005. [25] Jakobsen. Advanced character physics. IO Interactive, 2001. 108

[26] Verlet. Computer experiment on classical uids. I. Thermodynamical properties of Lennard-Jones molecules. In Phys. Rev., pages 159, 98103. 1967. [27] Hitman: Codename 47. www.ioi.dk/games/hitman1.htm, 06 2007. [28] IO Interactive. www.ioi.dk, 12 2012. [29] Fedor. Fast character animation using particle dynamics. Proceedings of International Conference on Graphics, Vision and Image Processing, 2005. [30] Muller, Heidelberger, Hennix, Ratcli. Position based dynamics. 2006. [31] Grinspun, Hirani, Desbrun, Schroeder. Discrete shells. In Proceedings of the ACM Siggraph, pages 98103, 2003. [32] Muller, Heidelberger, Tescher, Gross. Meshless deformations based on shape matching. Proceedings of ACM Siggraph, pages 471478, 2005. [33] Disney pixar. www.pixar.com, 12 2012. [34] Cignoni, Paolo and Corsini, Massimiliano and Ranzuglia, Guido. MeshLab: an Open-Source 3D Mesh Processing System, April 2008. [35] Autodesk Inc. www.autodesk.it, 12 2012. [36] Blender foundation. www.blender.org, 12 2012. [37] Open graphics library. www.opengl.org, 12 2012. [38] Khronos Group. www.khronos.org, 12 2012. [39] Apple iPhone. www.apple.com/it/iphone/, 12 2012. [40] K. Shoemake. Animating Rotation with Quaternion Curves. Computer Graphics 19 (3), pages 245254, 1985.

109

[41] Barret, Berry, Chan, Demmel, Donato, Dongarra, Eijkhout, Pozo, Romine, van der Vorst. Templates for the Solution of Linear Systems: Building Blocks for Iterative Methods, 2nd ed. SIAM, 1994. [42] Bresenham. Algorithm for computer control of digital plotter. IBM Systems Journal 4 (1), pages 2530, 1965. [43] Eclipse. www.eclipse.org, 12 2012. [44] PowerVR Imagination Technologies . insider/, 12 2012. www.imgtec.com/powervr/

110