Simulazione interattiva di corpi deformabili su piattaforma mobile

Transcript

1 Facoltà di Ingegneria dell informazione, Informatica e Statistica Tesi di Laurea Magistrale in Ingegneria Informatica Simulazione interattiva di corpi deformabili su piattaforma mobile Relatore Prof. Marco Fratarcangeli Candidato Antonio Passarella Anno Accademico 2011/2012

2 Ringrazio cordialmente il mio relatore, Prof. Marco Fratarcangeli per la sua disponibilità, la sua pazienza nei lunghi ricevimenti e per tutte le nozioni che mi ha trasmesso e di cui sicuramente farò buon uso in futuro. Un ringraziamento sincero e più che sentito va alla mia famiglia che mi ha consentito di studiare e mi è 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 affetto e la loro vicinanza. A Miriam, che mi ha sempre supportato in ogni mia scelta e mi è stata accanto durante tutto il mio percorso di studi regalandomi più di un sorriso nei momenti difficili. Ringrazio con affetto 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ù di un occasione nella metropoli romana. Ad Angela, Andriy ed Alessandro per la loro preziosa amicizia, per aver condiviso le gioie della carriera universitaria e aver affrontato insieme le tante sfide 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à 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.

3 Abstract In questa tesi viene presentato un framework che simula il comportamento di oggetti deformabili. La simulazione è sviluppata su piattaforma mobile per dimostrare l interattività che l algoritmo proposto garantisce nonostante la mole di dati, i calcoli da effettuare 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à tipica degli oggetti che si desidera simulare. Il movimento dei vari punti è gestito dalla dinamica basata sulle posizioni che permette alti livelli di manovrabilità e controllabilità. Il risultato è 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 l uso di questa tecnica e garantisce comunque un interazione real-time efficace e realistica. 2

4 Abstract In my work it s 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 different 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 different characteristics and behaviors. The mobile platform does not limit the use of this technique and however it guarantees a real-time effective and realistic interaction. 3

5 Indice 1 Introduzione L idea Contesto e soluzioni Visualizzazione della mesh su dispositivo mobile Interazione dell utente Modello di simulazione proposto Struttura della tesi Background Background teorico Mesh Manipolazioni naturali: Arcball Simulazione di un sistema fisico Background software MeshLab D Studio Max Simulazione fisica con plugin con Blender Aspetti teorici Ambiente di sviluppo Gesture di pinch Rotazione con Arcball Quaternioni Funzionamento Mappatura sulla sfera

6 Calcolo della rotazione corrente Aggiornamento della rotazione globale Simulazione di corpi deformabili Metodo mass-spring Struttura degli oggetti Vincoli strutturali Lista degli edge Funzione di hash Vincoli di distanza Vincoli di volume Interazione dell utente: risultati della deformazione Picking Trasformazioni inverse Indicizzazione 3D all interno di una griglia Calcolo delle distanze Vincolo di picking Schema generale Implementazione Strumenti utilizzati Struttura dell applicazione Componenti chiave: Activity Il file Manifesto Risorse dell applicazione Grafica 3D su dispositivi mobili Vertex Buffer Object Integrazione delle API di OpenGL ES La libreria Min3D Moduli software RendererActivity Supporto alle texture, all illuminazione e agli shader Limiti Sviluppo

7 4.5.1 Avvio dell applicazione Caricamento dei file Fase di parsing Visualizzazione del modello al centro di vista Sviluppo della simulazione fisica Soddisfacimento dei vincoli Picking Gestione dell input Menù e preferenze Preferenze sulle texture Preferenze di disegno Preferenze sulla rotazione Impostazione dei parametri della simulazione Salvataggio dello stato Test e risultati Analisi delle prestazioni Occupazione di memoria primaria Tempo della fase di parsing Tempo per il picking Tempo per uno step di risoluzione dei vincoli Effetti della simulazione Simulazione 1: assenza dell effetto dei vincoli Simulazione 2: indipendenza delle due tipologie di vincolo Simulazione 3: variazione del parametro di tipo distance Simulazione 4: variazione del parametro di tipo pressure Simulazione 5: influenza dei vincoli su una mesh complessa Simulazione 6: ritorno alla forma originale Simulazione 7: effetti su una mesh composta da più oggetti

8 6 Conclusioni Lavori futuri Bibliography 107 7

9 Elenco delle figure 1.1 Multi-platform development Architettura del sistema Android Esempio di deformazione Arcball Ragdoll Angoli di piega degli edge Simulazione ottenibile con il lavoro di Muller MeshLab su PC MeshLab sul mobile D Studio Max Simulazione tramite plugin Pipeline delle trasformazioni in OpenGL Pinch to zoom Drag sull Arcball 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 Effetto dei vincoli sul volume Esempio di interazione con l utente Ray picking Trasformazione della retta di picking

10 3.14 Differenza 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 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 all avvio del software Interfaccia grafica per l inserimento dei path di modello e texture Disegno dell Arcball Menù dell applicazione Schermata delle impostazioni Preferenze sulle texture Scelta della modalità di disegno della mesh Opzione di rotazione Cambio dei parametri della simulazione Simulazione Simulazione Simulazione Simulazione Simulazione Simulazione Simulazione

11 Elenco delle tabelle 5.1 Analisi prestazionale: confronto tra tre modelli diversi

12 Capitolo 1 Introduzione Negli ultimi anni si è assistito ad una evoluzione e diffusione importante di smartphone e tablet, dispositivi che hanno ottenuto sempre maggiore rilevanza nella vita quotidiana e che a volte si sostituiscono ai più performanti PC grazie alla loro praticità. Le moderne tecnologie hanno portato allo sviluppo di processori e schede grafiche sempre più performanti da integrare in tali dispositivi. L architettura ARM in particolare ha permesso di offrire velocità di elaborazione di rilievo dove il risparmio energetico è 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ò arrivare è davvero vasto e chiaramente ciò allarga il business e l interesse. Sorge quindi una nuova propensione nello sviluppo che porta con sè non pochi problemi legati alla natura stessa di tali dispositivi. Il risparmio energetico e l attenzione quindi nel consumo delle risorse sono un fattore da non tralasciare se si vuol diffondere il più 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à. Oggi tra i sistemi operativi più diffusi per tali terminali si trova Android [1], sviluppato dalla nota Google, che ha la particolarità di essere open 1

13 source rispetto agli altri sistemi come ios della Apple e Windows Phone della Microsoft. Android può essere impiegato su diversi dispositivi, che differiscono per tipo e potenza hardware. La versatilità 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 grafiche grazie ad una delle librerie grafiche più diffuse in questo ambito, ossia OpenGL ES [2]. Negli ultimi anni si può osservare come l informatica grafica abbia assistito ad un notevole sviluppo, soprattutto nella realizzazione di animazioni interattive credibili per la creazione di effetti speciali e film di animazione, grazie sia a società che sviluppano videogiochi che a società che si interessano di ricerca medica o comunicazioni. L obiettivo è sempre stato quello di riprodurre simulazioni sempre più attendibili curando con grande attenzione i dettagli. Col tempo nascono nuovi algoritmi e tecniche di programmazione che permettono di spostare verso la qualità grafica quella linea virtuale che ha sempre indicato il giusto compromesso tra velocità di esecuzione (fps) e particolari da rappresentare. La nuova frontiera risulta sicuramente l applicazione 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 l interazione real-time dell utente, sono un esempio delle sfide da affrontare nello sviluppo su queste nuove piattaforme. 1.1 L idea La libreria grafica OpenGL ES integrata nei framework disponibili per le piattaforme mobili consente l adozione di tecniche e algoritmi dell informatica grafica nello sviluppo. L oggetto di questa tesi è proprio un applicazione grafica che sappia mettere in mostra da un lato le capacità di tali dispositivi e dall altro le tecniche di programmazione utili a implementare metodologie studiate da anni su computer che offrono 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

14 su file. L utente può direttamente interagire con il modello visualizzato oltre che accedere a varie impostazioni di disegno dello stesso. Al di là di queste operazioni utili ma non così significative, si vuole implementare una tecnica per simulare i corpi deformabili. La mesh è arricchita di vincoli strutturali che consentono di modificarne la forma senza stravolgere l intero corpo. Il metodo solitamente utilizzato nella computer grafica per simulare un sistema fisico è 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à dalle accellerazioni e le posizioni dalle velocità. In questa tesi, invece, si utilizza un algoritmo basato sulle posizioni. Il maggior vantaggio che si trae da questa scelta è quello di lavorare direttamente sulle stesse. Aggiornando le posizioni delle varie particelle di cui si compone l oggetto si può controllare e manovrare direttamente i vincoli che determinano la simulazione. Al contrario della fisica che nei calcoli punta sulla precisione e sull esattezza, nella computer grafica gli obiettivi più importanti sono la stabilità, la robustezza, la velocità di calcolo e un risultato che sia visibilmente più che plausibile e questo metodo consente di abbracciare tale filosofia. Infatti l approccio utilizzato è ottimo nelle simulazioni che richiedono un elevato fps come videogames o simulazioni in tempo reale, perchè garantisce una notevole velocità di esecuzione. Le caratteristiche della dinamica basata sulle posizioni sono ottime quindi anche per il realizzarsi della simulazione su piattaforma mobile. 1.2 Contesto e soluzioni Visualizzazione della mesh su dispositivo mobile La simulazione fisica è realizzata su una mesh poligonale, per cui si rende necessario caricare e visualizzare correttamente la mesh. L obiettivo finale non risulta essere la modifica di tali modelli dal dispositivo, ma esclusivamente una loro visualizzazione. Il motivo è indicato dal fatto che tali terminali sono 3

15 spesso un utile sostituto del computer su cui è possibile realizzare software più completi e performanti in grado di gestire tali compiti. Il parsing e la visualizzazione sono possibili attraverso diverse librerie grafiche di terze parti disponibili nel settore mobile. Si è analizzato in particolare un possibile impiego di tre librerie: EdgeLib [3], Marmalade [4] e Min3D [5]. Più in dettaglio le prime due sono utili per creare applicazioni multi piattaforma. Per i motivi precedentemente citati ciò può essere un obiettivo fondamentale per diffondere 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è la scrittura dell applicazione avviene con un unico linguaggio di programmazione. Sarà poi il tool di compilazione fornito a generare la build adatta al sistema in uso, con evidenti differenze se l architettura 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 è una libreria oggi poco supportata e quindi lo sviluppo è relativamente difficoltoso, soprattutto se si considera che oggi il sistema Android è ancora in sviluppo e le nuove release si differenziano notevolmente dalle precedenti. Differentemente Marmalade risulta più supportata in quanto il suo uso non è libero ma soggetto ad acquisto di licenza. Entrambe sono sviluppate in codice C++, differentemente da Min3D che è basata su codice Java. Ciò mette in luce la doppia natura di Android: tale sistema operativo è costituito da un Kernel basato sul sistema operativo Linux, con middleware, 4

16 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 è possibile, quindi, con entrambi i linguaggi ma la programmazione con linguaggio Java è facilitata dalle API messe a disposizione dal SDK (Software Development Kit). Google incita la scrittura di applicazioni proprio in questo linguaggio data l affidabilità e le prestazioni fornite dalla macchina virtuale implementata. EdgeLib e Marmalade sono state testate a fondo al fine 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 è possibile eseguire quindi le API Java del SDK Android, 5

17 piuttosto tali framework offrono propri metodi per accedere alle risorse del dispositivo. Si nota comunque una minore completezza software rispetto al SDK, ad esempio EdgeLib soffre della mancanza di supporto al multi-touch, ossia al tocco contemporaneo in più 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 difficoltose da gestire. Si è preferito quindi uno sviluppo su Java con la libreria Min3D dato il supporto offerto dal SDK e dato che le prestazioni non decadono eccessivamente nonostante il codice sia eseguito nella macchina virtuale grazie all ottimizzazione dell intero sistema. Min3D è open source e quindi il suo codice è stato interamente inglobato nell applicazione. La libreria consente il caricamento di mesh poligonali salvate in diversi tipi di file. Il suo funzionamento verrà dettagliato in seguito Interazione dell utente Ottenuta la visualizzazione e il caricamento si è proceduto allo studio dell interazione dell utente in modo che si possa ruotare, ingrandire, rimpicciolire o deformare la mesh. La particolarità dei dispositivi su cui il software verrà eseguito è l offrire metodologie di input diverse dai classici mouse e tastiera utilizzati su computer. La gestione dell input mette in primo piano l uso del display touch-screen di cui smartphone e tablet dispongono. Si è inserito quindi il supporto alle gesture eseguibili sul display per qualsiasi operazione da effettuare sull oggetto rappresentato. La rotazione dell oggetto in tre dimensioni è stata ottenuta attraverso l implementazione di un Arcball. Quest ultima è una tecnica molto utilizzata nella computer grafica oggi. Essa permette una rotazione naturale e libera da eventuali vincoli legati al fatto che si vuole gestire un movimento in tre dimensioni quando l input è in sole due dimensioni. Lo zoom è possibile attraverso il movimento ormai brevettato del cosiddetto pinch. Tale gesture si serve di due tocchi simultanei del display e 6

18 mette in luce come l usabilità possa migliorare attraverso lo schermo tattile. La deformazione, infine, viene gestita attraverso un drag sul display, ossia un trascinamento del tocco da una parte ad un altra dello schermo Modello di simulazione proposto E stata creata un applicazione che simula l interazione 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ò variare. La tipologia di tali vincoli è definita stretching ed in effetti essi simulano l elasticità dell oggetto. Oltre a tali vincoli si inserisce un vincolo definito di overpressure che limita il volume del corpo. La presenza di un vincolo sul volume fa in modo che la mesh possa essere sì modificata ma ritornerà comunque al suo volume originario. L utente può deformare la mesh selezionando ad esempio un vertice dell oggetto 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à dell oggetto. 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 finchè non si raggiunge una configurazione stabile. 7

19 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 dell applicazione. 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 l approccio matematico necessario per la comprensione di tecniche come l Arcball e si definiscono in modo esaustivo tutte le nozioni riguardanti la simulazione di corpi deformabili. Capitolo 4 Sono presentati tutti i dettagli relativi all implementazione. Oltre al focus sulla realizzazione pratica delle tecniche precedentemente 8

20 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 dell input e dell interfaccia utente. Capitolo 5 Si mostrano test e risultati dell implementazione della simulazione su piattaforma Android. Sono definite le tempistiche necessarie per effettuare le principali operazioni in cui è suddivisa la simulazione fisica, oltre che le risorse in termini di memoria necessarie per garantire il funzionamento del software. In più 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 infine 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. 9

21 Capitolo 2 Background In questo capitolo sarà fatta una panoramica generale delle tecniche attualmente utilizzate in diversi settori come ad esempio lo sviluppo di videogiochi e l animazione cinematografica, settori ai quali questa tesi in diversi modi si va a collegare. In particolare si mostra lo stato dell arte ossia quei lavori che sono serviti come fonte di ispirazione spiegando le eventuali differenze di utilizzo, i vantaggi e gli svantaggi. Oltre ai lavori teorici si farà riferimento anche ad applicazioni già disponibili che sono state utilizzate per analizzare le funzioni da implementare. 2.1 Background teorico Mesh Una mesh poligonale, anche detta maglia poligonale, è una collezione di vertici, lati e facce che definiscono la forma di un oggetto poliedrico nella computer grafica 3D e nella modellazione solida [6]. Le facce consistono solitamente di triangoli, quadrilateri od altri semplici poligoni convessi, dal momento che ciò semplifica il rendering. Lo studio di mesh poligonali è un grande sotto-campo della computer grafica e le diverse rappresentazioni sono utilizzate per molte applicazioni e con diverse finalità. Sono stati creati algoritmi per il Ray tracing, il collision detection, e la simu- 10

22 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à maggiore di dati da memorizzare [7]. Half-edge mesh: simile al precedente, ma possiede solo la metà delle informazioni riguardo ogni edge dato che quest ultimo è 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. Quest ultimi 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 predefinita, in modo che scorrendo le informazioni nella tabella si possano ottenere i poligoni rappresentati implicitamente. La rappresentazione è più compatta e più efficiente, ma le operazioni di modifica 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 l edge e le informazioni sulla faccia sono implicite nella rappresentazione. La semplicità di tale strutturazione consente di svolgere con maggiore efficienza diverse elaborazioni [11]. La scelta della struttura dati viene fatta in base all applicazione che utilizza tali dati, le prestazioni richieste, la dimensione dei dati, e le operazioni 11

23 da eseguire. Ad esempio è più facile utilizzare triangoli piuttosto che altri poligoni, soprattutto in geometria computazionale. Per certe operazioni è necessario avere un accesso rapido alle informazioni e questo richiede strutture più 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 è simile alla prima della lista (Face-Vertex Mesh) dato che è la più diffusa e la più semplice da analizzare. La scelta è motivata anche dal tipo di file che l applicazione sviluppata supporta ossia file di estensione OBJ [12]. Tale formato è molto comune e utilizzato in particolare per definire le geometrie 3D grazie alla sua natura open. La struttura del file è molto semplice e permette di definire le posizioni dei vertici, le normali, le facce, le coordinate texture. I vertici sono memorizzati in un ordine orario in modo da rendere l esplicitazione delle normali non necessaria. Al file è spesso allegato un file di tipo MTL [13] che specifica i materiali e le texture della mesh Manipolazioni naturali: Arcball Una volta che la mesh è caricata e visualizzata è possibile applicarvi numerose trasformazioni geometriche sfruttando la pipeline grafica. Alcune trasformazioni come la rotazione sono calcolabili indipendentemente dal modello e sono soggette ad altri fattori quali ad esempio l input dell utente. L articolo 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 è 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, l orientamento degli oggetti rispetto alla camera di vista può cambiare durante l esecuzione e in alcuni casi si vuole permettere all utente di interagire direttamente con la rotazione dell oggetto. Fin dai primi anni 90 si è riflettuto su come ottenere una tecnica che permetta di 12

24 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 effettua il cosiddetto dragging per ruotare, ossia si trascina l input in una singola direzione mantenendo un click sull oggetto. Quest ultimo verrà ruotato secondo la direzione di trascinamento. Il lavoro di Shoemake è innovativo e differente dai precedenti poichè introduce alcuni fondamenti matematici già studiati [16], [17], [18], con i quali è possibile calcolare le giuste rotazioni di un oggetto senza fissare un asse di rotazione. La tecnica può essere spiegata in modo visuale in modo molto semplice: si può pensare ad una sfera che racchiude il corpo da ruotare. L utente che vuole ruotare il corpo non deve far altro che disegnare un arco sulla sfera, che dovrà ruotare nella direzione e di un angolo che dipendono dall arco stesso. L arco è 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 dell arco di rotazione Le rotazioni nello spazio sono spesso molto complesse e si compongono di multiple rotazioni su assi differenti [19]. La tecnica in questione permette di evitare la complessità nei calcoli attraverso dei principi matematici noti, che inoltre rendono il movimento semplice ed intuitivo per l utente. 13

25 2.1.3 Simulazione di un sistema fisico Al di là di rotazioni, traslazioni o scaling il software oggetto di questa tesi permette anche una deformazione della mesh. La deformazione è 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 è 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à viene deciso dai vincoli che tengono unite le particelle. Questi vincoli devono essere rispettati in ogni step della simulazione aumentando notevolmente la complessità di calcolo. Fino a poco più di 10 anni fa la simulazione dinamica di tessuti e corpi deformabili non era richiesta nè nelle produzioni cinematografiche nè 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à 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ù robusti per gestire tali oggetti come insieme di particelle distinte. In termini elaborativi, si introduce una notevole complessità ma i vantaggi di tale tecnica hanno indotto a studiare diversi metodi per la realizzazione, i più validi sono illustrati nella relazione sullo stato dell arte [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à 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

26 bilità rispetto ad altre tecniche. Nella computer grafica e, soprattutto, nei giochi per computer è 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 all esterno 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 dell utilizzo della dinamica basata sulle posizioni: permette di risolvere i problemi di instabilità interagendo direttamente sull applicazione delle forze proiettando le particelle in posizioni corrette; è possibile agire direttamente sui vertici e sulle parti degli oggetti modificandoli 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 fisico, descritto in [25], che usa un integratore di Verlet per calcolare l applicazione delle forze alle particelle. L integrazione di Verlet [26] è un metodo numerico usato per integrare le equazioni del moto di Newton. Esso offre grande stabilità oltre che il rispetto di proprietà importanti per un sistema fisico quali la reversibilità temporale, ad un costo non significativo rispetto all altrettanto famoso metodo di Eulero. L integratore di Verlet è stato arricchito nell articolo di Jacobsen con un sistema di gestione dei vincoli basato sulle posizioni. Ciò ha permesso di realizzare il ragdoll che ha rappresentato l anatomia umana dei personaggi 15

27 presenti nel videogioco Hitman: Codename 47 [27] della IO Interactive [28]. Il sistema di vincoli presentato è molto ricco e prevede vincoli di diversa natura, non solo di tipo stretching. Si dimostra ad esempio come è 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ò 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 all oggetto di muoversi in maniera naturale. Figura 2.2: Ragdoll rappresentante l anatomia umana Figura 2.3: Jacobsen Vincoli sull angolo formato da due edge descritti nel lavoro di 16

28 La tecnica proposta da Jacobsen è stata ripresa ed ampliata in vari lavori successivi. Ad esempio Fedor in [29] si concentra sull applicare tali tecniche su oggetti dalla scheletratura simile all anatomia umana, simulandone differenti comportamenti. Il lavoro di Muller [30] è 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à ad altri lavori precedenti come [31], [32] L utilizzo 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 l angolo di piega tra due mesh triangolari adiacenti che compongono l oggetto e quindi definiscono la rigidità del corpo. Oltre a ciò 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 all originale dopo la deformazione. Questa tecnica permette di creare simulazioni con corpi dalle caratteristiche diverse ed animati dallo stesso algoritmo. Ciò rappresenta un vantaggio non indifferente 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 finora descritti vengono utilizzati anche nell industria cinematografica ed in particolare nei film d animazione. Infatti i tessuti vengono 17

29 simulati in maniera automatica attraverso un motore fisico che agisce sulle particelle che compongono l oggetto. In questo modo gli animatori hanno la possibilità 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 fisica. Questa tecnica rende la simulazione estremamente realistica. Un esempio di applicazione è dato dai film d animazione prodotti dalla Pixar [33]. Il lavoro oggetto di questa tesi mostra la facilità 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 è ben definita e rende possibile costruire tutto l insieme di vincoli che realizzano in pratica la simulazione. Le strutture che verranno cotruite a partire dalla mesh saranno molto più complicate di un ragdoll ma si dimostrerà che il framework riesce ad essere efficiente anche con un elevato numero di vincoli. 18

30 2.2 Background software MeshLab La realizzazione di un lavoro di tesi di questo tipo porta ad analizzare software già esistenti per studiarne le funzionalità e le varie caratteristiche implementate. Un esponente di spicco tra i lavori analizzati è MeshLab, un software di mesh processing molto conosciuto nel settore grafico [34]. Figura 2.5: Workspace di MeshLab su PC Windows MeshLab è open source e di libero utilizzo, uno strumento utilissimo per visualizzare mesh salvate in diversi formati di file. E stato progettato principalmente con tre obiettivi: facilità d uso, orientamento allo scanning 3D ed efficienza. MeshLab è quindi stato concepito più per la visualizzazione che per l editing della mesh la cui funzionalità è contenuta in altri software professionali quali Blender, 3D Studio Max o Maya. Una volta che la mesh è caricata il software permette di lavorare su un largo set di parametri che consentono di controllare il disegno, l illuminazione 19

31 e le texture del modello. Oltre a tali parametri si può utilizzare un Arcball per la rotazione, oltre che ingrandire o rimpicciolire la mesh. Le ultime release del software su computer introducono l importante supporto allo scanning 3D: dai dati grezzi ottenuti tramite i device di acquisizione hardware il software riesce a ricreare un modello 3D pronto all uso. Tale processo è ricco di differenti algoritmi che provvedono a ricostruire le superfici 3D e convertirli in facce della mesh. Grazie a questa e alle altre sue caratteristiche MeshLab è molto utilizzato tuttoggi e uno sviluppo su più piattaforme ne aiuta sensibilmente la diffusione. L applicazione è disponibile anche su piattaforma Android e ciò dimostra come la realizzazione di tali applicazioni grafiche 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ò 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 dell interfaccia, delle funzioni e della visualizzazione della mesh sul dispositivo. Figura 2.6: MeshLab su Android 20

32 D Studio Max Un ulteriore software che si vuole citare è 3D Studio Max, il quale permette di realizzare da zero geometrie complesse in 3D. Il software è quindi differente dal precedentemente descritto MeshLab in quanto è votato non solo alla visualizzazione di mesh ma anche alla creazione e all editing delle stesse. Figura 2.7: Workspace di 3D Studio Max 3D Studio Max è un editor 3D molto potente, sviluppato dalla Autodesk [35], e risulta uno dei software più utilizzati per creare geometrie 3D, definirne le superfici, applicarvi animazioni, simulare la fisica e usare diverse tecniche di illuminazione. Ha grandi capacità di modellazione e un interfaccia molto valida. Con le ultime versioni sono state aggiunte una serie di funzionalità avanzate come shader, simulazione dinamica, sistemi di particelle, radiosity e linguaggio per gli script. Il software non è disponibile per dispositivi mobili, in qualche modo risente delle molte caratteristiche messe in gioco. La complessità determina quindi la scelta di limitare lo sviluppo ai computer che possono offrire performance superiori. Con il progresso tecnologico, tuttavia, i dispositivi mobili potrebbero integrare ben presto tutte le feature del software su PC. 21

33 2.2.3 Simulazione fisica 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ò essere sviluppato tramite plugin per Blender [36]. Quest ultimo è un noto software dalle funzionalità simili a 3D Studio Max ma con l aggiunta di essere open source. Blender offre la possibilità di aggiungere plugin ossia codice accessorio da eseguire sulle mesh poligonali. Esistono perciò diversi lavori che consentono di rappresentare una simulazione fisica con i principi descritti in lavori come quello di Jacobsen [25] visibile nella sottostante figura. L ambiente estensibile rende quindi agevole l ingresso di nuove caratteristiche specifiche e la creazione di simulazioni altrimenti non direttamente incluse nella versione originale. La potenzialità di questo aspetto è stata integrata anche nelle ultime release dei principali concorrenti di questo software come il precedentemente citato 3D Studio Max. Figura 2.8: Simulazione fisica con Blender tramite plugin aggiuntivo 22

34 Capitolo 3 Aspetti teorici In questo capitolo verranno affrontate tutte le fasi del progetto da un punto di vista teorico, illustrando quindi le tecniche matematiche utili a raggiungere i fini previsti. Viene presentata una prima panoramica sull ambiente di sviluppo e sulle caratteristiche tipiche dei device su cui il software verrà eseguito. A seguire si mostra il funzionamento dell ArcBall in maniera dettagliata introducendo tutte le nozioni matematiche necessarie alla comprensione. Infine si delineano le pratiche utilizzate per costruire la simulazione di un sistema fisico. Viene presentato il meccanismo di relazione tra le particelle di cui si compone il corpo ed in che modo avviene l interazione con l utente. 3.1 Ambiente di sviluppo L applicazione oggetto della tesi è pensata e sviluppata per dispositivi mobili dall hardware avanzato. Molte caratteristiche accomunano tali device. In primo luogo essi hanno pochi tasti fisici che sono dediti solitamente a operazioni di base del sistema operativo come gestione del volume audio o chiusura dell applicazione in esecuzione. La maggior parte delle interazioni con l utente avviene attraverso lo schermo che permette l input attraverso il tocco dello stesso. La natura touch permette all utente di interagire direttamente con gli oggetti presenti nella scena 3D e ciò risulta chiaramente una sfida per 23

35 lo sviluppatore. La gestione dell input è infatti differente rispetto ad esempio a mouse o tasti fisici presenti sui computer, soprattutto se si pensa che si possono inserire gesture ossia assegnare funzioni a particolari movimenti eseguiti toccando lo schermo in più punti. Un esempio è la gesture del pinch to zoom che verrà 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] è una libreria per lo sviluppo di applicazioni grafiche 2D e 3D. Fin dal 1992, anno del rilascio, OpenGL è diventata l interfaccia di programmazione (API) grafica più usata e supportata nei linguaggi e nelle piattaforme. L interfaccia consiste in oltre 250 chiamate di funzione, che permettono di ottenere grafica ad alte prestazioni, di gestire oggetti geometrici 3D e immagini e di creare applicazioni interattive come i videogiochi. OpenGL è pensato per essere indipendente dall hardware e dal sistema operativo. Per questo non contiene comandi per gestire le finestre. Svolge due funzioni importanti: offrire al programmatore un API unica e uniforme, e permettere di superare le differenze hardware riscontrabili tra piattaforme diverse. OpenGL ES è un sottoinsieme delle librerie grafiche OpenGL pensato per dispositivi integrati (telefoni cellulari, PDA ecc. ma anche strumentazione scientifica e industriale). Viene gestito dal consorzio no-profit 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 grafiche e le mancanze non portano all impossibilità di implementare gli obiettivi che si vogliono ottenere come verrà mostrato successivamente. L uso di questa libreria grafica comporta l adozione della geometria adatta a rappresentare oggetti sulla scena. L oggetto che viene rappresentato è soggetto a diverse trasformazioni prima di essere disegnato. Le trasformazioni permettono di: specificare la locazione dell osservatore e della camera di vista (Viewing), muovere l oggetto nella scena (Modeling), ridimensionare e 24

36 tagliare la scena secondo il volume di vista (Projection) e la dimensione della finestra (ViewPort). Le trasformazioni sono calcolate in forma matriciale e applicate in sequenza nella pipeline grafica alle coordinate dei vertici originali. La matrice a cui si pone maggiore attenzione è la matrice di ModelView che permette di posizionare e orientare l oggetto disegnato combinando le trasformazioni di Viewing e Modeling. Figura 3.1: Pipeline delle trasformazioni in OpenGL 3.2 Gesture di pinch L interazione dell utente con dispositivi mobili touch-screen si arricchisce della capacità di supportare gesture multi-touch. Lo schermo tattile si differenzia dai classici monitor per computer per il fatto che è sensibile al tocco anche in più punti diversi della superficie contemporaneamente. Se l hardware 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 l interazione di più dita o mani contemporaneamente, fornisce il risultato dell interazione. 25

37 Un esempio che si collega al lavoro di tesi è l ingrandimento o il rimpicciolimento di oggetti rappresentati sullo schermo. Le gesture più naturali e intuitive che permettono di effettuare tali operazioni prendono il nome di pinch to zoom. Tale tipologia di movimento è stata per la prima volta utilizzata come parte integrante dell interfaccia su dispositivi mobili dalla Apple sul suo iphone [39]. In particolare tale movimento viene utilizzato per l ingrandimento di immagini visualizzate sul display. Le gesture sono basate su due tocchi simultanei sullo schermo: se i due tocchi si allontanano ci sarà 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 è 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ò essere utilizzato per calcolare la relativa trasformazione di scaling in OpenGL del modello visualizzato. 26

38 3.3 Rotazione con Arcball La rotazione di un oggetto nello spazio può avvenire lungo diversi assi, e ogni rotazione si può comporre di diverse rotazioni, ognuna su un asse differente. E provata la difficoltà nel delineare un interfaccia semplice e naturale per manipolare la rotazione attraverso un dispositivo di input che lavora in sole due dimensioni. L Arcball è una tecnica di input che risolve tali difficoltà e consente di manipolare la rotazione combinando fattori sia matematici che legati all interazione dell utente [14]. L idea alla base dell Arcball è intuitivamente semplice: si vuole rappresentare la rotazione di un qualsiasi oggetto come la rotazione di una sfera. Per cambiare l orientamento dell oggetto l utente disegna un arco sullo schermo che verrà quindi proiettato sulla sfera. Per effettuare il disegno dell arco semplicemente l utente deve effettuare un movimento di drag : su un dispositivo mobile con touch screen ciò 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ò implica una rotazione completa di 360 gradi (fenomeno di wrapping). Figura 3.3: Movimento di drag sull Arcball, Mouse Down e Mouse Up si riferiscono a eventi di clic del mouse su computer, su dispositivi mobili ciò si tramuta in tocco e rilascio dello schermo tattile. 27

39 3.3.1 Quaternioni La rotazione di un oggetto in tre dimensioni può essere soggetta al fenomeno del gimbal lock. Quest ultimo corrisponde alla perdita di un grado di libertà se la rotazione è basata su angoli di Eulero e per risolverlo si può applicare la matematica dei quaternioni [18], [40]. Un quaternione è una notazione matematica conveniente a rappresentare orientamento e rotazione di un oggetto in tre dimensioni. Ogni rotazione in tre dimensioni può essere rappresentata come combinazione del vettore dell asse e di un angolo. Dato un vettore (a x, a y, a z ) il quaternione può essere costruito con la seguente formula: q = cos 1 2 θ + (a xi + a y j + a z k) sin 1 2 θ (3.1) dove θ è l angolo di rotazione ed il vettore rappresenta l asse di rotazione. Data una posizione p descritta dalle coordinate spaziali (p x, p y, p z ) per applicare la rotazione bisogna effettuare la seguente moltiplicazione: p xi + p yj + p zk = q(p x i + p y j + p z k)q (3.2) ove q è il coniugato di q: q = e 1 2 θ(p xi + p y j + p z k) = cos 1 2 θ (p xi + p y j + p z k) sin 1 2 θ (3.3) Inoltre due quaternioni possono essere combinati in un unica rotazione: q = q 2 q 1 (3.4) Ciò fornisce la rotazione risultato delle due rotazioni nella sequenza con cui vengono moltiplicate dato che tale operazione non è commutativa. Nella formula mostrata la rotazione si compone di una prima rotazione q 2 e una seconda rotazione q 1 applicata all oggetto successivamente. In tal modo l utilizzo dei quaternioni, oltre a risolvere il gimbal lock, 28

40 permette di facilitare la combinazione delle rotazioni. In computer grafica ciò è importante in quanto l animazione di una singola rotazione in realtà è la composizione di più 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 difficili da calcolare Funzionamento L introduzione delle nozioni viste finora permettono di capire il funzionamento dell ArcBall che può essere riassunto nei punti di seguito mostrati. Mappatura sulla sfera L oggetto da ruotare è virtualmente inserito al centro di una sfera su cui l utente può effettuare il drag. Quindi il primo passo è proiettare le coordinate di input in 2D sulla sfera in 3D. Ciò avviene quando l utente effettua il primo tocco sull Arcball, tale evento è definito solitamente click. Il click fornisce x ed y e si conosce il raggio della sfera, ciò che è ignoto è 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 è facile calcolare la coordinata z tramite il teorema di Pitagora (Fig. 3.4). 29

41 L unico problema è che il punto in 3D calcolato potrebbe non trovarsi sulla superficie se l utente effettua il tocco al di fuori del raggio della sfera, in tal caso la coordinata z sarà tale che il punto in 3D è il punto della superficie sferica più prossimo alle coordinate di tocco. Ciò che si ottiene non è semplicemente una posizione, bensì un vettore rappresentante l asse di partenza della rotazione selezionato dall utente. Al termine di questa fase tale vettore deve essere normalizzato per semplificare i calcoli successivi. Calcolo della rotazione corrente Quando l utente effettua il drag si vuole ottenere una rotazione della sfera. Durante il movimento di drag la sfera è toccata in diversi punti, ognuno di essi rappresenta un vettore nello spazio che combinato al vettore di click fornisce un asse 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 l asse di rotazione. Il prodotto scalare serve per determinare l angolo θ tra due vettori a e b nel seguente modo: θ = arccos(a b) (3.5) Quest ultimo calcolo è possibile solo se i vettori sono normalizzati (per il vettore di click ciò viene svolto nel punto precedente). A partire dall asse e dall angolo di rotazione appena calcolati è possibile ricavare il quaternione q ad essi associato attraverso le formule viste in precedenza. Esso rappresenta la rotazione corrente imposta all oggetto. Aggiornamento della rotazione globale La rotazione appena calcolata va a combinarsi con le precedenti applicate all oggetto. Si possono combinare le rotazioni moltiplicando i quaternioni ad esse associate nella giusta sequenza. 30

42 Tuttavia è bene calcolarne la combinazione in forma matriciale. Ciò è dovuto al fatto che le librerie di supporto grafico 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 finale. Un quaternione q può essere trasformato nella corrispondente matrice 4 4 nel seguente modo: 1 2q y q y 2q z q z 2q x q y 2q w q z 2q x q z + 2q w q y 0 2q x q y + 2q w q z 1 2q x q x 2q z q z 2q y q z 2q w q x 0 2q x q z 2q w q y 2q y q z + 2q w q x 1 2q x q x 2q y q y 0 (3.6) dove q x, q y, q z e q w rappresentano i rispettivi elementi di q. La matrice di rotazione ottenuta viene utilizzata per il calcolo della rotazione nella pipeline grafica, viene quindi moltiplicata per la matrice di ModelView. L aggiornamento della rotazione avviene ogni volta che viene calcolato un nuovo vettore dal movimento di drag e ciò 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ù aggiornato lo stato della rotazione che rimane fisso. Tutti gli step elencati si ripetono ad un nuovo evento di click. 31

43 3.4 Simulazione di corpi deformabili Una delle caratteristiche di maggior spessore di questo lavoro di tesi è la capacità di simulare un sistema fisico. Si vuole infatti creare una simulazione che permetta di rappresentare la deformabilità degli oggetti. Definire un sistema fisico di questo genere in computer grafica determina alcune difficoltà nella definizione della struttura degli oggetti e della loro rappresentazione. Nei successivi punti si enunciano i principi adottati definendo ogni aspetto che permette il realizzarsi della simulazione Metodo mass-spring In questa tesi si è utilizzato il metodo basato su particelle e vincoli (massspring) per la simulazione di deformabilità in quanto risulta il più 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à degli anni 80, per modellare il corpo di esseri viventi, tessuti e materiali molto deformabili come la gomma. Tale modellazione è basata su un modello analitico per rappresentare le caratteristiche meccaniche dei corpi, ma in maniera diversa rispetto a quella che si basa su elementi finiti [24]. Infatti questa tecnica viene utilizzata soprattutto per simulare la deformabilità 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 dell oggetto viene simulato imponendo che ciascuna particella interagisca con quelle adiacenti; l interazione 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, definiti dalla Scienza dei materiali. 32

44 Figura 3.5: Rappresentazione di un sistema mass-spring (Immagine presa da [24]) Nella simulazione mass-spring, il modello viene completato definendo 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 prefissati, separati da intervalli di piccola durata. Ad ogni istante, per ogni particella vengono determinate le forze agenti, sia quelle applicate dall esterno, 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 l integrazione di Verlet ed altri aspetti. La simulazione è infatti governata dai soli vincoli tra le particelle che permettono di modificare la struttura dell oggetto in modo coerente rispetto agli input esterni. I vincoli definiscono la composizione interna del corpo andando ad impostare ad esempio la lunghezza della distanza tra le particelle o il volume dell intero oggetto. Essi possono essere violati in un istante di tempo ma nei successivi instanti torneranno ad essere verificati. In sostanza ciò garantisce che la struttura non sia rigida, ma abbia una certa elasticità e possa evolvere in dipendenza ad esempio di input esterni. La tecnica descritta può essere molto utile a rappresentare tessuti dinamici o materiali elastici come si può osservare in Fig

45 Figura 3.6: Esempio di struttura di un oggetto rappresentante un tessuto Struttura degli oggetti Il modello fisico prevede che il sistema di particelle sia visto dall esterno come un elemento unico, un punto multidimensionale nello spazio. Dall interno, invece, questo è 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 definiscono la geometria principalmente attraverso vertici e facce. Nel sistema mass-spring le particelle sono definite come oggetti con una massa, una posizione, una velocità e un accellerazione. Rispondono alle forze a cui sono soggette, ma non hanno una dimensione fisica. 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à e accellerazioni che non sono utili agli obiettivi preposti, ogni vertice può essere visto come un punto materiale della mesh, importante a definirne la struttura e il comportamento nella simulazione. Le facce identificano 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 è molto importante per operare sulla struttura dell oggetto, infatti diventa molto semplice aggiungere eventuali vincoli grazie a queste informazioni. 34

46 3.4.3 Vincoli strutturali I vincoli strutturali vengono creati al momento della realizzazione dell oggetto e mai cancellati o modificati durante tutta la simulazione. Essi sono intrinsechi nella struttura del corpo e ne determinano la dinamica durante la simulazione. Ogni volta che un oggetto è soggetto a deformazioni, le particelle che lo compongono vengono mosse. Dopo questo spostamento la struttura dell oggetto potrebbe risultare alterata e i vincoli fanno sì che la struttura dell oggetto non risulti compromessa. Questi vengono risolti secondo il metodo iterativo Gauss-Seidel che serve per arrivare alla soluzione dell equazione non lineare generata da ogni vincolo [41]. L idea è di risolvere ogni vincolo in maniera indipendente uno dopo l altro. Tuttavia ciò non fa in modo che il calcolo per ogni vincolo diventi un operazione lineare. Per affrontare il problema della non linearità si è pensato di ripetere in maniera iterativa per un numero finito di volte lo spostamento di ogni particella in una posizione valida rispettando ogni singolo vincolo. Questa operazione è resa molto semplice dalla dinamica basata sulle posizioni. Lista degli edge Nel lavoro sviluppato una tipologia di vincoli è determinata in base ai cosiddetti edge o lati della mesh. Ogni edge non è altro che un lato di una o più facce che collega due vertici. La figura sottostante li mostra chiaramente. Figura 3.7: Edge (a sinistra) e facce (a destra) di una mesh raffigurante un parallelepipedo, ogni edge può essere condiviso da più di una faccia 35

47 Ogni edge è identificato principalmente dai due vertici che lo compongono, e ciò ne caratterizza l unicità all interno dell oggetto. Dato che bisogna caratterizzare un vincolo per ogni edge è importante definirli. Un file di una mesh può non contenere la lista degli edge, è il caso del tipo di file che il software in sviluppo supporta (OBJ). La struttura del file prevede la specificazione solo di vertici, facce e normali. Tuttavia si può ricavare l insieme dei lati grazie alle facce: in fondo ognuna di esse definisce i tre lati di cui è composta attraverso i suoi vertici. Il problema che evidentemente può sorgere è che alcuni edge sono condivisi tra due o più facce, bisogna evitare che uno stesso edge sia aggiunto più volte all insieme. Se ciò avvenisse, parallelamente l insieme dei vincoli crescerebbe inutilmente, dato che molti di questi sarebbero ripetuti. Creare dinamicamente una lista di edge unici è un operazione non lineare e ciò determina tempi lunghi per le computazioni soprattutto se il numero di facce della mesh è elevato. Per creare un insieme di elementi unici in tempistiche adeguate si può utilizzare un Hashset, ossia una struttura dati che consente l aggiunta di elementi in base ad una funzione di hash. Di ogni elemento viene calcolato il codice hash che si suppone essere unico nell insieme: se due elementi hanno lo stesso codice allora sono uguali e quindi l elemento non viene aggiunto. La scelta di questa rappresentazione è motivata dalle prestazioni in termini di complessità temporale nell aggiunta di elementi all insieme. Funzione di hash La funzione di hash è importantissima per definire la lista degli edge: una scelta non ottima potrebbe incentivare le collisioni. Avere una collisione nell aggiunta degli elementi implicherebbe ad esempio che due edge diversi vadano a collidere nella stessa posizione nell Hashset, si perderebbe quindi l informazione relativa a uno dei due. Ogni edge è 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

48 che effettui un mapping da un insieme N N ad un insieme N senza generare collisioni. La funzione di hash scelta è la funzione di parità di Cantor. Essa è la funzione π : N N N definita da: π(k 1, k 2 ) = 1 2 (k 1 + k 2 )(k 1 + k 2 + 1) + k 2 (3.7) dove k1 e k 2 sono due numeri interi. La parità di Cantor è molto affidabile e solitamente viene utilizzata in ambito informatico in problemi della tipologia descritta. Vincoli di distanza A partire dall insieme dei lati della mesh è possibile calcolare i vincoli di tipo distance che permettono di regolare la distanza tra le particelle. Ogni vincolo è creato solo in fase di inizializzazione e non viene alterato in seguito. Ciò che si modifica è 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ù volte. Figura 3.8: Rappresentazione grafica della risoluzione del vincolo di distanza tra due particelle: al centro è visualizzata la distanza corretta. 37

49 Per ogni lato dei triangoli che compongono l oggetto viene generato un vincolo di tipo distance secondo la funzione: C dist (p 1, p 2 ) = p 1 p 2 l 0 (3.8) Lo scalare l 0 è la distanza iniziale tra le due particelle nelle posizioni p 1 e p 2. 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ò 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) 2 pc(p) (3.11) che è un passo Newton-Raphson per le soluzioni iterative delle equazioni non lineari date da un singolo vincolo. Per la correzione della posizione p i di una particella si ha: p i = s pi C(p 1, p 2 ) (3.12) dove il parametro s è dato da: C(p 1, p 2 ) s = (3.13) pj C(p 1, p 2 ) 2 j Si noti che questo parametro è uguale per ogni particella. Considerando che le derivate rispetto alle due particelle in posizioni p 1 e p 2 sono rispettiva- 38

50 mente p1 C(p 1, p 2 ) = n e p2 C(p 1, p 2 ) = n con n = p 1 p 2, il parametro p 1 p 2 s è uguale a: p 1 p 2 l 0 2. Ed infine le correzioni da fare per far rispettare il vincolo di distanza sono pari a: p 1 = 1 ( p 1 p 2 l 0 )(p 1 p 2 ) 2 p 1 p 2 p 2 = 1 ( p 1 p 2 l 0 )(p 1 p 2 ) 2 p 1 p 2 (3.14) (3.15) I delta mostrati andranno rispettivamente a sommarsi alle posizioni attuali p 1 e p 2. Nell articolo di Muller [30] da cui si traggono questi calcoli si fa riferimento anche al parametro k dist dal valore in [0...1] che rappresenta una costante di rigidità del corpo. In pratica se si moltiplica tale parametro per il valore del delta si ottiene che la distanza da rispettare deve essere k dist volte l originale. Un valore di k dist pari ad 1 fa sì che la distanza tra p 1 e p 2 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 l 0 se sottoposte a forze che tendono a separarle. Le correzioni da applicare, tenendo conto del valore di k dist, sono dunque: p 1 = 1 ( p 1 p 2 l 0 )(p 1 p 2 ) k dist 2 p 1 p 2 (3.16) p 2 = 1 ( p 1 p 2 l 0 )(p 1 p 2 ) k dist 2 p 1 p 2 (3.17) Il problema di questo tipo di algoritmo è che a causa delle iterazioni multiple necessarie per risolvere le equazioni non lineari dei vincoli, anche l effetto di k dist non sarà lineare. Questo porta alla presenza di un errore in p per un numero di iterazioni molto grande. Per risolvere il problema si può moltiplicare p non per k dist, ma per k = 1 (1 k) 1 n s dove n s rappresenta il numero di iterazioni del solver. Questo approccio necessita di conoscere in anticipo il numero di step risolutivi, cosa non possibile per applicazioni inte- 39

51 rattive come questo lavoro di tesi dato che il numero di iterazioni condiziona il numero di frame per secondo e non è instaurabile a priori. Perciò il valore di k è ignorato e si utilizza il valore di k dist introdotto in precedenza. Per ottenere il comportamento descritto con le formule elencate si può 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 finale delle posizioni 1 delta = x2 - x1; 2 deltalength = sqrt(delta*delta); 3 diff = (deltalength-restlength)/deltalength; 4 x1 += delta*0.5*diff*k; 5 x2 -= delta*0.5*diff*k; Il codice si riferisce al caso monodimensionale ma può essere facilmente esteso in tre dimensioni. Il valore di restlength si riferisce alla distanza originale tra i due punti. L algebra 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à che dipende dalla differenza della distanza attuale rispetto a quella originale. Si noti che, per mantenere la simmetria, le due particelle verranno spostate sempre della stessa quantità. Infine si mostra nella seguente figura una rappresentazione grafica della risoluzione iterativa dei vincoli descritti. 40

52 Figura 3.9: Risoluzione di un sistema di vincoli di distanza tramite la tecnica di Gauss-Seidel: le immagini rappresentano ogni step dell iterazione e sono in successione, a partire dall alto 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ò 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ò 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 definito di overpressure a tutti gli N vertici che compongono una mesh. Questo vincolo sarà soggetto ad una funzione pari a: n triangoli C (p1,...,p N ) = ( (p t i p 1 t i ) p 2 t i ) k pressure V 0 (3.18) 3 i=1 Nella (3.18) il parametro k pressure rappresenta di quanto il volume corrente (il primo termine della differenza) può discostarsi dal volume originario V 0, mentre i termini p t i j rappresentano le coordinate dei vertici di ogni faccia della mesh. Il parametro k bilancia la deformazione dell oggetto ed è compreso nel range [0...1]. 41

53 Tramite questa funzione è possibile ricavare i gradienti dei vertici: p i C = j : t 1 j = i (p t j 2 p t j ) + 3 j : t 2 j = i ove j rappresenta l indice delle facce. (p t j 3 p t j ) + 1 j : t 3 j = i (p t j 1 p t j ) 2 (3.19) Il calcolo dei gradienti permette di calcolare il delta di spostamento per ogni vertice: p i = p i s k pressure (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 = dove C è la differenza tra i due volumi. C j p j 2 (3.21) 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 effettuati al caricamento della mesh in memoria. Ciò giova alle prestazioni real time dato che l unico calcolo più lungo da risolvere durante la simulazione è quello del volume corrente. Chiaramente l insieme di tutti i vincoli di overpressure per ogni particella determina un sistema non lineare e perciò la tecnica di risoluzione iterativa deve essere utilizzata anche in questo caso. 42

54 Figura 3.10: Esempio grafico dell effetto dei vincoli sul volume: risultato dell animazione da destra verso sinistra con al centro la massima distorsione applicata alla sfera (nella simulazione si utilizza un valore di k pari a 1) Interazione dell utente: risultati della deformazione Un sistema mass-spring mantiene il suo stato di quiete finchè una forza, una collisione o altri aspetti comportano dei cambiamenti all interno della struttura. Quando ciò avviene alcuni vincoli saranno violati e si dovranno risolvere in modo iterativo così da giungere all insieme di soluzioni che soddisfa tutti i vincoli espressi per l oggetto. Nel lavoro oggetto di questa tesi, l obiettivo è rendere il sistema liberamente perturbabile dall utente. Forze o collisioni non sono implementate e quindi l interazione è 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ò avviene ecco cosa accade all interno della struttura mass-spring: 1. gli edge dei vertici interessati dallo spostamento non hanno più le lunghezze prestabilite e il volume della mesh non è più analogo al volume originario; 2. con la tecnica del rilassamento il sistema mass-spring risolve ogni vincolo violato; 43

55 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 fisica e avviata quindi dall utente che e in grado di selezionare e trascinare i vertici in posizioni diverse dalle originali. In condizione di riposo il sistema mass-spring non modifica le posizioni finche l input dell utente non determina la violazione di qualche vincolo espresso per l oggetto. Chiaramente il sistema dei vincoli verra risolto ad ogni time step sia durante che dopo il trascinamento del vertice selezionato. Figura 3.11: Esempio di interazione con l utente: la freccia nella prima immagine a sinistra indica il punto di selezione e la direzione di trascinamento, al centro l utente smette di trascinare il vertice e quindi avviene il rilassamento dei vincoli che termina dopo un certo numero di time step come nell immagine piu a destra. 44

56 3.4.5 Picking La deformazione vista in precedenza è possibile se l utente è in grado di effettuare un picking dei vertici, ossia la selezione dei vertici da traslare. L operazione appare semplice ed intuitiva dal punto di vista dell utente ma presenta delle problematiche tecniche non indifferenti 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 è stata introdotta nella sezione 3.1. In generale le librerie grafiche creano ambientazioni 3D in cui le coordinate differiscono totalmente dalle coordinate dello schermo, ossia ciò che vede l utente. Ciò è dovuto principalmente al fatto che lo schermo è 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à una semplice area in due dimensioni bensì un certo volume della scena. Esistono diversi modi per gestire tale situazione secondo la libreria grafica utilizzata. Un esempio è dato dalle API di OpenGL, nella sua versione standard utilizzabile su computer. Il funzionamento del picking con OpenGL è molto semplice e può essere riassunto nei seguenti passi: 1. Ottenere le coordinate del mouse (si analizza il caso dei computer, ma ciò può essere esteso ad altri meccanismi di input indipendentemente da OpenGL); 2. Entrare in Selection Mode : una modalità di rendering speciale in cui il frame buffer (responsabile del disegno sullo schermo) non viene alterato, ossia l utente continua a visionare la scena come in precedenza; 3. Ridefinire il volume di vista in modo che solo una piccola porzione dello schermo attorno al cursore è utilizzata per il rendering; 45

57 4. Effettuare il render della scena, utilizzando solo le primitive che sono visibili nel volume di vista selezionato; 5. Uscire dal Selection Mode e identificare 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à Selection si collezionano solo le primitive che vengono disegnate nel volume di vista prossimo al cursore memorizzandone il nome e la profondità. Tale tecnica è molto utile ed è stato studiata una sua applicabilità in ambito mobile per lo sviluppo del picking. Purtroppo non è utilizzabile in quanto OpenGL ES non supporta la modalità Selection e quindi non permette l accesso al buffer contenente i nomi delle primitive interessate dal picking. Per ovviare a tali mancanze bisogna effettuare dei ragionamenti differenti che mettono in gioco la geometria della scena 3D di OpenGL. La tecnica utilizzabile è definita ray picking ed è 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 dell oggetto rappresentato (si veda Fig. 3.12). L intersezione della bounding box implica che la retta attraversi o sia vicina alla mesh visualizzata ed è quindi calcolabile quali sono i vertici più prossimi ad essa. Il vertice più vicino in assoluto e più prossimo al punto di osservazione sarà il risultato della selezione sullo schermo. 46

58 Figura 3.12: Rappresentazione grafica della tecnica del ray picking nello spazio 3D di OpenGL. Trasformazioni inverse L input del picking è chiaramente limitato a due dimensioni e ciò rende impossibile determinare quale sia la profondità del punto nello spazio corrispondente al pixel selezionato. Nella versione standard di OpenGL l istruzione glreadpixel consente di ottenere la profondità leggendone il valore nel Depth Buffer. Tuttavia quest ultimo non è accessibile in OpenGL ES e ciò giustifica la creazione della retta. Lo spazio geometrico rappresentato tramite OpenGL è 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ò calcolare l equazione della retta in tre dimensioni sfruttando le equazioni della geometria analitica. La proiezione di un punto dello schermo nello spazio tridimensionale implica l inversione della pipeline grafica di OpenGL. La sequenza delle trasformazioni nella terminologia di OpenGL e nel suo utilizzo standard comporta 47

59 i seguenti cambi di coordinate a partire dalle coordinate dell oggetto 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 dell oggetto (p) in coordinate di vista (v): Mp = v (3.22) Un altra matrice, la Projection (P ) consente la trasformazione in coordinate di clip (c): P v = 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): n = c c w (3.24) V n = s (3.25) Per la proiezione si devono effettuare i passi mostrati esattamente nell ordine opposto. Ci sono, tuttavia, due metodologie per effettuare 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 dell oggetto 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 l accesso diretto al buffer contenente le trasformazioni delle coordinate dei vertici, bisogna ricalcolare tali coordinate. Quindi per ogni vertice bisogna computare una moltiplicazione per la ModelVielw: la complessità temporale risulterebbe O(numero vertici). Il calcolo è parallelizzabile ma 48

60 dato che l applicazione è destinata a dispositivi mobili è opportuno risparmiare calcoli complessi sulla CPU che in alcuni casi è formata da un unico processore. Il secondo approccio è quindi quello più indicato e comporta la definizione della retta in coordinate dell oggetto. In questo modo le coordinate dei vertici possono essere lette direttamente dal file della mesh senza alcuna ulteriore computazione. Il primo step è la trasformazione delle coordinate sullo schermo in coordinate di clip, per farlo si utilizza la matrice V. Invertendo la (3.25): 2 s x w 1 c = 2 s y h 2s z 1 1 (3.26) dove s x, s y e s z sono le coordinate del punto selezionato sullo schermo e w e h sono relativi rispettivamente alla larghezza e all altezza dello schermo. Si ottengono direttamente le coordinate di clip in quanto la coordinata w è unitaria. In (3.26) si rende necessaria la coordinata z relativa alla profondità ma come descritto in precedenza essa non è rilevabile. Piuttosto dalla (3.26) si possono ricavare i due punti appartenenti alla retta sui due piani differenti near e far. La s z sarà 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 sull asse z proprio tra 0 e 1. Ripartendo dall equazione (3.26) si passa dalle coordinate di clip alle coordinate di vista in tal modo: P 1 c = v (3.27) e infine 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

61 mesh al punto selezionato dall utente, possibile grazie al fatto che le coordinate della retta e dell oggetto stesso sono relative allo stesso spazio. Tuttavia il modello può essere soggetto a rotazioni, traslazioni o trasformazioni di scaling. L approccio finora 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 è la retta stessa che deve essere ruotata o scalata secondo le trasformazioni della matrice di ModelView mentre l oggetto viene considerato fermo. I vantaggi sono evidenti: non si traformano tutti i vertici dell oggetto, 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 è fissata nelle sue coordinate di partenza senza alcuna trasformazione applicata. Quindi nella (3.28) la matrice di ModelView verrà prelevata dallo stack di OpenGL dopo aver computato tutte le trasformazioni applicate all oggetto. I calcoli da effettuare per giungere alle proiezioni sui due piani near e far sono molteplici ma le API di OpenGL ES offrono un utile istruzione che aiuta ad evitarli: gluunproject. L istruzione 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

62 dell utilizzo è opportuno trasformare la coordinata s y nel seguente modo: s y = h s y (3.29) Ciò poichè le coordinate dello schermo prelevate tramite una gestione dell input sul dispositivo in uso definiscono la posizione (0,0) in alto a sinistra, in OpenGL invece si ha l opposto ossia la posizione (0,0) è definita in basso a destra dello schermo. Figura 3.14: Differenza nelle coordinate dello schermo Dietro una singola istruzione ci sono quindi numerosi calcoli da effettuare che comunque sono veloci ed effettuati in poche occasioni. Piuttosto i calcoli più 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ù vicini alla retta, riducendo le computazioni e agevolando l interazione in tempo reale. Indicizzazione 3D all interno di una griglia La tecnica del ray picking non evita uno dei problemi più evidenti legati alla selezione di oggetti sullo schermo da parte dell utente: il calcolo delle distanze su ogni vertice. Infatti il numero dei vertici è generalmente elevato e il calcolo può risultare lungo e gravoso. 51

63 In molti casi il picking viene sfruttato per determinare la selezione di interi oggetti e perciò il problema si risolve enormemente dato che basta computare la distanza tra il centro di ogni oggetto e la retta per determinare quale sia l oggetto selezionato. Invece, in casi come quello in esame, anche su piattaforme hardware più performanti non è una buona pratica calcolare tutte le distanze soprattutto perchè la maggior parte di esse è elevata e perciò alcuni vertici non dovrebbero essere presi in considerazione. Si può 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 l oggetto, indicizzando tutti i vertici nelle rispettive celle della griglia; Figura 3.15: Griglia 3D con all interno la mesh. 2. si effettua un mapping della retta di picking sulla griglia; 52

64 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 figura 3.16 le celle in questione saranno comprese tra C s e C e. La griglia deve essere grande quanto la bounding box del modello al fine di racchiudere ogni possibile vertice. Inoltre essa deve contenere un numero di celle adeguato al modello stesso: ad esempio se un modello è molto grande (quindi ha una bounding box di grandi dimensioni), ma ha pochi vertici, è 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 vanificherebbe l ottimizzazione introdotta dalla griglia. In definitiva la dimensione sarà sempre uguale alla bounding box, ma il numero di celle sarà soggetto al numero di vertici, con il rispetto di una misura minima di diagonale di cella affinchè quest ultima non risulti troppo piccola per essere selezionata dall utente. Inoltre, dato che l applicazione oggetto della tesi è diretta a dispositivi dalla memoria ridotta si può pensare ad una ulteriore ottimizzazione ossia convertire la griglia da tre dimensioni a due. In pratica si rimuove la profondità della griglia, ma con alcuni accorgimenti per non condizionare il funzionamento dell evento di picking. Il vantaggio è evidente sia in termini 53

65 z = z 0 + tv z (3.30) 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 fine di non perdere l informazione relativa alla profondità: 1. Si calcolano i punti P 1 e P 2 in cui la retta interseca la griglia 3D. Data la massima z e la minima z dalla bounding box si utilizza l equazione parametrica della retta in uno spazio tridimensionale: x = x 0 + tv x y = y 0 + tv y dove v rappresenta il vettore direzionale della retta e (x 0, y 0, z 0 ) il punto della retta sul near plane. 2. Si mappano i punti P 1 e P 2 sulla griglia 2D, calcolando le celle che li contengono. Per ogni punto ci possono essere diversi casi: se è nel piano della griglia basta solo calcolare la cella in cui è 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 P 1 e P 2. Allo stato attuale è l algoritmo più usato per la rasterizzazione di linee, soprattutto per la sua bassa richiesta di risorse computazionali [42]. Esso è anche usato per il disegno di linee sulla griglia di pixel dello schermo e perciò è implementato in firmware di schede grafiche o su hardware. 54

66 Figura 3.17: Ray picking su griglia 2D: le celle selezionate sono comprese tra C s e C e calcolate con l algoritmo di Bresenham Calcolo delle distanze L obiettivo del ray picking è il prelevare il vertice più 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ò essere ampio ma non sarà mai eccessivo per le risorse computazionali del dispositivo in uso grazie all opportuna ottimizzazione introdotta dalla griglia stessa. Per determinare i vertici più 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 P 1 = (x 1, y 1, z 1 ), P 2 = (x 2, y 2, z 2 ) 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 = (x 2 x 1, y 2 y 1, z 2 z 1 ) u = (x x 1, y y 1, z z 1 ) 55

67 2. si calcola il prodotto vettoriale v u, la norma di tale prodotto rappresenta l area del parallelogramma formato da v ed u; 3. dato che v u è l area basta dividere questa quantità per la lunghezza del vettore v (la base) e si ricava l altezza 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ù prossimo alla retta. A questo punto è opportuno effettuare un ulteriore scrematura per definire l unico vertice da selezionare. Si ricorda che finora le coordinate dei vertici sono prelevate direttamente dal file della mesh lavorando quindi in coordinate oggetto. Perciò i vertici non hanno l informazione relativa alla trasformazione della matrice di ModelView applicata all oggetto e se non si operasse un ulteriore affinamento nel calcolo si otterrebbero un insieme di vertici che sono sia quelli più prossimi all utente che quelli più lontani, dal lato opposto, del punto di selezione. Figura 3.18: Vertici selezionati senza l informazione sulla trasformazione della ModelView: il vertice corretto è quello più vicino all utente ossia quello in alto a sinistra Si deve quindi necessariamente calcolare la coordinata z relativa alla profondità corrente per ognuno dei vertici rimasti. Viene moltiplicato ogni vertice per la matrice ModelView che definisce come i vertici sono rappresentati nella scena in base alla trasformazione di rotazione, di traslazione e di scaling corrente. 56

68 Alla fine si ottiene il vertice con la massima z, dato che il verso dell asse z è uscente dallo schermo. Si noti come il calcolo è effettuato per pochissimi vertici, uno per ogni cella della griglia che comprende la retta; ciò non richiede elevati tempi computazionali. Vincolo di picking Fino ad ora si è descritto come selezionare opportunamente e in maniera ottimizzata i vertici della mesh corrente senza menzionare effettivamente quale operazione sia prevista per il vertice interessato dal picking. Come mostrato nel precedente sottocapitolo l interazione dell utente riguarda lo spostamento del vertice selezionato per fare in modo che l oggetto si deformi. Non appena l utente termina la traslazione del vertice il sistema perturbato dei vincoli troverà una soluzione alle posizioni dei vertici che compongono la mesh. Ma come può avvenire la traslazione del vertice selezionato? Si pensi al dispositivo d utilizzo del presente lavoro di tesi: esso dispone di uno schermo tattile e quindi il modo più naturale per rappresentare tutto ciò è supportare l azione di trascinamento. In pratica l utente al primo tocco seleziona il vertice da traslare, e successivamente, senza lasciare lo schermo, muove il tocco nella direzione voluta. Al termine esso rimuoverà il tocco dallo schermo e il sistema mass-spring sarà 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 fisica creata e si utilizzerebbero le nozioni matematiche viste finora senza introdurre ulteriori concetti. Il vincolo definito dal picking è di una tipologia simile al vincolo di distanza sugli edge poichè l operazione di trascinamento può essere vista in un modo differente: essa non è altro che l insieme di molteplici tocchi sullo schermo. Se da ognuno di essi si costruisce una retta di proiezione si può 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

69 direzione della retta stessa. Per esprimere questo vincolo è opportuno riprendere i concetti espressi in relazione al vincolo di distanza sugli edge. Si può 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 definire il vertice della retta che è più vicino al vertice della mesh da traslare. Per farlo si definisce 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ò vuol dire che il vertice della retta non verrà realmente spostato ma solamente utilizzato per calcolare direzione e quantità dello spostamento del vertice selezionato. Il rispetto di tale vincolo è il primo ad essere garantito nel sistema massspring ad ogni iterazione poichè è il più importante: esso determina la violazione di tutti i vincoli precedentemente creati. In tal modo è l utente che avvia la simulazione e al rilascio dello schermo del dispositivo il vincolo semplicemente cessa di esistere. Quando ciò avviene i restanti vincoli determinano il progresso della simulazione verso una configurazione stabile. Figura 3.19: Rappresentazione dello spostamento del vertice selezionato durante il trascinamento del tocco sullo schermo. 58

70 Si noti infine come lo spostamento dei vertici comporta che quest ultimi debbano essere indicizzati di nuovo sulla griglia al fine di garantire che le successive operazioni di picking avvenghino in base alle nuove coordinate dei vertici e non rispetto alle coordinate originali Schema generale Figura 3.20: Schema generale del funzionamento del sistema mass spring 59

71 Lo schema in Fig ben rappresenta i collegamenti logici tra i vari elementi che permettono di costruire la simulazione fisica. Dalla mesh si ricavano i vincoli strutturali del sistema e la griglia attraverso un indicizzazione dei vertici. La gestione dell input consente di costruire una retta la cui proiezione sulla griglia permette di determinare il vertice selezionato. In definitiva si calcola il vertice più prossimo alla retta per determinare il vincolo di picking. L ottimizzazione mostrata permette di effettuare pochi calcoli real-time (distanze, volume corrente, retta di picking), e al caricamento della mesh è opportuno effettuare i calcoli più 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 è lineare ma la tecnica di rilassamento di Gauss-Seidel [41] permette di risolvere in real-time i vincoli in maniera semplice e lineare. In definitiva si mostra lo pseudocodice relativo alla risoluzione dei vincoli. 60

72 Algorithm 2: Risoluzione sistema mass-spring Data: posizioni attuali dei vertici, volume dell oggetto, distanze originali degli edge Result: Correzione finale delle posizioni in base a tutti i vincoli 1 foreach time-step do 2 if esiste un vertice selezionato then 3 risolvi vincolo distanza del vertice selezionato con retta di 4 end picking; 5 foreach edge do 6 risolvi vincolo distanza ; 7 end 8 foreach particella do 9 risolvi vincolo volume ; 10 end 11 //fase di update 12 foreach particella do 13 aggiorna posizione nel buffer di disegno; 14 end 15 end 61

73 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 grafiche offerte da OpenGL ES. Di quest ultima libreria si spiegano le differenze 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 file della mesh e rappresentare il tutto sullo schermo, soprattutto i suoi limiti e cosa è stato introdotto per rendere il software funzionale agli scopi. Infine si mostrano tutte le caratteristiche dell applicazione, l interfaccia grafica e l interazione con l utente. Oltre alla panoramica software si definiscono anche gli strumenti utilizzati per lo sviluppo. 4.1 Strumenti utilizzati L applicazione per sistema Android viene sviluppata su computer e compilata tramite il tool messo a disposizione insieme al SDK. L IDE supportato per lo sviluppo è Eclipse [43]. Per consentire la compilazione e l installazione del programma sul dispositivo occorre il plugin Android Development Tools 62

74 (ADT). Esso consente inoltre il supporto all editor dei file XML necessari ad alcune operazioni dell applicazione; la visualizzazione di una finestra di debug su computer, riportante gli eventi generati nell applicazione in esecuzione sul dispositivo; e la creazione del pacchetto APK che rappresenta il file di installazione del software. Il dispositivo di testing utilizzato nello sviluppo è 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à maggiore è stato effettuato 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 grafica, multi-core e prodotto dalla PowerVR [44] abbastanza potente da garantire il funzionamento dell applicazione. 4.2 Struttura dell applicazione Il software in sviluppo è 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 è 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 l operato di altre applicazioni. Un applicazione, tuttavia, può richiedere i permessi per accedere ad esempio a delle risorse condivise quali messaggi, output di sensori ecc. Tali permessi sono specificati in un file definito Manifesto : un documento XML che specifica anche altri dettagli. Inoltre il principio non vieta che un applicazione possa richiedere l avvio di un altra applicazione per assolvere una specifica funzione, per esempio scattare una foto o navigare su un sito web. La struttura del software è quindi differente rispetto ad altre piattaforme e si compone di: 1. componenti chiave; 63

75 2. file di manifesto; 3. risorse. Nei successivi punti si specifica il ruolo di ogni componente e come è stato sviluppato nel lavoro di tesi 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 differenti: 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 fine ultimo del lavoro in sviluppo. Ci si concentra quindi sul comprendere l importanza dell Activity che diviene il cuore del software. Un Activity (in seguito chiamata anche attività) è il componente che fornisce l interfaccia di una singola schermata, consente l esecuzione di determinati comandi o computazioni, permette la visualizzazione di scene 3D e al suo interno si gestisce l interazione dell utente. Attraverso di essa si crea una finestra grande quanto lo schermo e si definisce ogni componente grafico disegnato al suo interno. Un attività non è separata dalle altre e può richiamare altre attività che verranno quindi istanziate e mostrate a schermo. Durante questo processo la precedente attività sarà nascosta all utente e quindi entrerà in uno stato di pausa, rimanendo comunque in memoria. Differentemente se l utente preme il tasto Back, presente su tutti i device Android e solitamente indicato con una freccia diretta verso sinistra, l attività correntemente visualizzata verrà 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 è fine a se stessa ed è un esecuzione di determinato codice. Un attività, tuttavia, è legata anche ad una interfaccia e al fatto che essa sia visualizzata o meno sullo schermo. Infatti se la vista di un attività correntemente visualizzata viene nascosta dalla finestra di un altra attività, si mette in pausa il suo flusso di esecuzione tradendo quindi il 64

76 concetto di multi-threading. Ogni attività può essere, quindi, in diversi stati: ad esempio in pausa, o in stato di resume quando viene ripristinata. Ogni passaggio da uno stato all altro viene notificato tramite eventi e può essere ricavato con metodi definiti nell Activity 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 all altro. Figura 4.1: Stati possibili di un Activity con relativi metodi utili a catturare il passaggio da uno stato all altro 65

77 In aggiunta bisogna denotare che l interfaccia grafica di un attività non necessariamente deve essere analoga a tutte le altre attività. Tale interfaccia è formata da una gerarchia di oggetti di tipo View che permettono di disegnare pulsanti, testo ecc. Come nelle interfacce grafiche sviluppate su computer anche in Android ogni finestra (quindi ogni attività) può avere un particolare layout, ossia un ordine preimpostato dei vari elementi disegnati. Tutta la UI è configurabile attraverso documenti XML che figureranno come risorse dell applicazione come descritto in seguito. Per questo lavoro si rende necessaria in primo luogo un attività che gestisce la visualizzazione del modello e della scena 3D, e poi altre attività per la gestione ad esempio del caricamento del modello o delle preferenze dell utente riguardo il disegno. Queste ultime due sono necessariamente separate dall attività di visualizzazione in quanto presentano una UI e delle funzionalità completamente differenti. Le Activity da sviluppare sono le seguenti con specificate le relative funzionalità: View3DActivity: è l attività di partenza avviata all apertura dell applicazione, essa gestisce il caricamento del modello, quindi permette di accedere alla memoria secondaria del device, verificare la presenza del file specificato e avviare l attività di visualizzazione. Obj3DView: è l attività cuore dell intera 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 offre qui il supporto alle gesture dell utente e si richiama la simulazione del sistema fisico. La UI è minimale e la maggior parte della finestra visualizza la scena disegnata tramite OpenGL. SettingsActivity: è l attività responsabile della gestione delle preferenze dell utente. Essa viene richiamata dall attività di visualizzazione e permette la scrittura di un file di preferenze mantenuto permanentemente in memoria secondaria (anche dopo chiusura dell applicazione). La UI è semplificata e preimpostata. 66

78 4.2.2 Il file Manifesto Prima che il sistema operativo lanci un applicazione deve conoscerne le componenti leggendo il file AndroidManifest.xml salvato nel package dell applicazione stessa. Questo file consente di definire, attraverso una specifica nomenclatura XML, quali siano le attività dell applicazione e altre componenti importanti. Nel caso in sviluppo è quindi opportuno specificare le attività descritte in precedenza con allegate informazioni come ad esempio quale sia l attività di main e di launch, ossia l attività eseguita all apertura. Oltre alle attività è opportuno descrivere in tale file anche il package dell applicazione, la versione e il livello minimo delle API Android utilizzate. Riguardo questa specifica bisogna effettuare alcune premesse: il sistema operativo è oggi ancora in sviluppo e quindi periodicamente viene pubblicata una nuova versione del sistema con nuove API o le stesse rinnovate. Ciò da un lato giova al programmatore che si affaccia in questa realtà software ma dall altro determina una frammentazione nella diffusione delle versioni differenti di Android. Spesso i device non sono aggiornati all ultima versione del sistema disponibile e ciò determina il non utilizzo delle ultime API disponibili. Per tali motivi si è scelto di utilizzare come minima versione di Android la 2.1, in quanto la maggior parte dei dispositivi Android è oggi equipaggiato con una versione eguale o superiore. Si noti infine come l applicazione da sviluppare non utilizzi particolari sensori o necessiti di particolari permessi dato che essa deve solo gestire l accesso in lettura a file su memoria secondaria o l orientamento del device. Tali operazioni sono consentite di default ad ogni applicazione senza alcuna specifica nel manifesto Risorse dell applicazione Un applicazione Android non è composta solo di codice Java, essa richiede risorse esterne che possono ad esempio essere un file di immagine, un file audio, una specifica riguardo la UI ecc. Nel lavoro in esame chiaramente i file della mesh rappresentano risorse esterne all applicazione e devono essere caricate 67

79 da memoria secondaria. La memoria secondaria su device Android risulta divisa in più componenti: una riservata al sistema operativo e ai dati delle applicazioni, una memoria interna e una memoria esterna (scheda SD) per i file dell utente. La porzione di memoria riservata ai dati delle applicazioni non è visibile all utente che può 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 l applicazione in sviluppo è la memoria interna in quanto di solito offre prestazioni superiori in lettura rispetto all SD-card di cui peraltro alcuni dispositivi sono sprovvisti. Si accede alla cartella radice della memoria interna attraverso l istruzione: 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 file della mesh ma anche layout, menù e tutto ciò che concerne l interfaccia può essere specificato come risorsa. Questi file sono scritti in codice XML e permettono di definire in maniera molto semplice l interfaccia. Essi sono salvati nel package dell applicazione e sono disposti in cartelle che hanno una specifica nomenclatura. 68

80 4.3 Grafica 3D su dispositivi mobili Android include il supporto a prestazioni grafiche di alta qualità grazie alle librerie grafiche OpenGL. La particolare versione implementata, OpenGL ES, è una versione più leggera della libreria completa disponibile su computer e pensata appositamente per dispositivi con limitate risorse computazionali. Ci sono quindi notevoli differenze nell utilizzo di tale libreria rispetto alla libreria standard e nei successivi punti si mostrano quali di esse sono rilevanti per la costruzione dell applicazione. Inoltre si vuole mostrare come integrare in pratica il meccanismo del render di OpenGL nell attività pensata per la visualizzazione ossia Obj3DView. Per ulteriori informazioni riguardo le specifiche di OpenGL ES si rimanda al documento ufficiale [2] Vertex Buffer Object La principale differenza tra la versione ES e la versione standard di OpenGL è indubbiamente l uso forzato dei Vertex Buffer Object (VBO) per il disegno delle primitive. Mentre nella versione standard su computer questa è una tecnica utilizzabile o meno, su dispositivi mobili è obbligatoria grazie alle performance che offre 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 buffer su GPU e, durante l esecuzione, si leggono e si interpretano i dati secondo ciò che viene specificato nell istruzione di disegno. L uso e la struttura dei buffer dipendono solo dal programmatore che può decidere come memorizzare i dati al loro interno. I buffer 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ò creare un buffer contenente l array dei vertici e un altro buffer contenente gli indici nell ordine secondo cui le coordinate dei vertici devono essere lette e disegnate a schermo attraverso l istruzione gldrawelements. Il disegno di una mesh, quindi, è possibile se prima si è instanziato correttamente il buffer contenente i vertici della stessa. Ci sono essenzialmente 69

81 due modalità di creazione del buffer: 1. buffer contenente i vertici della mesh e buffer degli indici: in tale caso si deve instanziare un buffer con le coordinate dei vertici e un buffer con l informazione su come i vertici sono collegati. Ciò è possibile grazie alla lettura delle facce della mesh che contengono gli indici dei vertici che le compongono. L istruzione di disegno deve quindi sfruttare entrambi i buffer come descritto in precedenza. 2. buffer con i vertici ripetuti: in pratica si crea un unico buffer con tutti i dati in relazione alle facce del modello. Per ogni faccia f si genera nel buffer una locazione per ogni vertice v di f e all interno di ogni locazione si memorizza la posizione, le coordinate texture, il colore e le normali del vertice relativo. Dato che un singolo vertice può appartenere a più facce, si ottiene una ripetizione delle informazioni riguardanti il vertice nel VBO. Tra le due alternative la seconda è sfruttata dalla libreria Min3D utilizzata per il caricamento della mesh. Perciò il buffer dei vertici del modello in realtà possiede informazioni ripetute. Tale approccio risulta fondamentale in quanto il file 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 v 1 appartenente alle facce f 1,f 2 e f 3 può avere associate le coordinate texture vt 1,vt 2 e vt 3 e le normali vn 1,vn 2 e vn 3 relative a tali facce. Per memorizzare queste informazioni e ad esempio per non ricalcolare le normali di ogni faccia (dato che sono già esplicitate nel file), ogni vertice è rappresentato più volte con la sola informazione sulla normale o sulla coordinata texture cambiata e l informazione sulla posizione non alterata. Questo approccio non risulta un grande problema a livello di disegno in quanto la versione ES è ottimizzata per una lettura veloce del buffer, ma, come illustrato in seguito, ciò determina dei problemi quando si vanno a modificare le posizioni dei vertici nella simulazione fisica. 70

82 4.3.2 Integrazione delle API di OpenGL ES Ci sono due classi fondamentali nel framework di Android che consentono di gestire la grafica: GLSurfaceView e Renderer. La prima è la classe responsabile della creazione della finestra al cui interno si generano le operazioni di rendering. All interno di un attività si deve instanziare questa classe al fine di visualizzare la grafica 3D disegnata con OpenGL attraverso la finestra. GLSurfaceView utilizza l interfaccia EGL per gestire la visualizzazione nella finestra. La classe descritta permette anche il decoupling delle operazioni di rendering dalle operazioni di gestione della UI. Ciò è molto importante per motivi di performance: il disegno della scena 3D e il disegno dell interfaccia grafica avvengono in due thread separati e inoltre la gestione dell input avviene interamente nel thread della UI senza intaccare l esecuzione del rendering. Il Renderer è invece l interfaccia che definisce i metodi necessari al disegno con OpenGL. Questa interfaccia deve essere implementata e collegata all istanza di GLSurfaceView attraverso il metodo setrenderer. In particolare i seguenti metodi devono essere ridefiniti 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 definire tutti i parametri relativi all environment di OpenGL e tutto ciò che deve essere inizializzato solo una volta. Si noti che il metodo è richiamato anche dopo un evento di resume: ciò avviene, come descritto in precedenza, quando la Activity la cui vista ospita il GLSurfaceView è 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 è impostato in modo tale da avere un frame rate costante. Esso può variare secondo le performance del dispositivo e dipende dal tempo impiegato per le operazioni di rendering. In questo caso la simulazione fisica cambia frequentemen- 71

83 te le posizioni dei vertici e con tale metodo si può aggiornare il disegno con le nuove coordinate. onsurfacechanged: il sistema chiama questo metodo quando la geometria del GLSurfaceView cambia. Questo può avvenire quando ad esempio la dimensione della finestra cambia in base all orientamento del device. Durante tale evento si deve cambiare il vettore di View- Port dello stato di OpenGL poichè esso necessita dell altezza e della larghezza corrente della finestra in cui è 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 grafica 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 differenziano principalmente nelle specifiche e nei device che le supportano, in particolare la 1.1 e la 2.0. Alcuni device possiedono quindi un hardware più avanzato che supporta la versione 2.0, altri invece più datati e con hardware meno performante supportano solo la 1.1. Per l applicazione in sviluppo si è scelto di utilizzare la versione 1.1 in quanto maggiormente diffusa rispetto alla versione 2.0. Inoltre le specifiche dell ultima 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 dell utilizzo di librerie dedicate. Esistono diverse soluzioni multi piattaforma che offrono non solo supporto al caricamento ma anche alla gestione del modello, delle luci, dell ambientazione ecc. Una delle librerie di libero utilizzo poichè open source e utile agli scopi descritti in precedenza è Min3D. Essa non è disponibile per altre piattaforme ma rappresenta, tuttavia, un buon punto di partenza per capire l adattamento della grafica 3D su device Android. Consente di caricare e gestire sulla scena diversi modelli 3D 72

84 salvati in file di vari formati come OBJ e MAX3DS (estensione dei file creati con 3D Studio Max). Le classi della libreria sono interamente scritte in Java e possono essere inglobate nel progetto in sviluppo Moduli software I moduli software della libreria sono schematizzati in figura 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 nell ambiente di programmazione. Solitamente le strutture dei file 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ò contenere più istanze di Object3dContainer al suo interno. In questo modo si possono gestire più oggetti, letti da file diversi, contemporaneamente nella scena. Tutta la scena con i relativi oggetti viene utilizzata dalla classe Renderer per la rappresentazione sullo schermo. Tale classe è un implementazione dell interfaccia Renderer definita nel SDK e in essa quindi si realizzano tutti i metodi che sfruttano le API di OpenGL ES come precedentemente illustrato. 73

85 Figura 4.3: Schema generale dei moduli software della libreria Min3D RendererActivity Il ponte tra il disegno della scena e l interazione dell utente è rappresentato dall attività RendererActivity. Essa gestisce la finestra in cui il modello 3D è raffigurato e l attività Obj3dView ne è un implementazione. Infatti, tramite questa classe, si gestisce da un lato la UI e gli input e dall altro 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 fisica. Per gestire la grafica, 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

86 delle funzionalità 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 l illuminazione. Il parsing viene effettuato in questo metodo che viene richiamato dal Renderer solo la prima volta che viene raffigurata la scena. Ciò può avvenire anche in seguito a un evento di resume dovuto al fatto che un altra Activity è stata eseguita per un certo tempo oscurando la vista del RendererActivity. updatescene: si operano le trasformazioni geometriche a cui è sottoposto l oggetto. Ad esempio traslazioni e rotazioni vanno applicate in questo metodo in quanto esso è richiamato ad ogni aggiornamento del rendering. Il thread dedicato alla grafica richiama le istruzioni del metodo in questione in ondrawframe() ad ogni time-step. oninitscene e onupdatescene: i metodi sono gestiti, differentemente dai precedenti, dal thread della UI e richiamati al termine rispettivamente di initscene e updatescene. La loro funzionalità è quella di notificare l evento di termine dell esecuzione del rispettivo metodo da parte del thread grafico. Ad esempio il termine del metodo initscene implica che il modello è stato caricato con successo e quindi si può notificare ciò all utente tramite la UI. 75

87 Figura 4.4: modello Flussi di esecuzione separati dell attività di visualizzazione del Supporto alle texture, all illuminazione e agli shader La visualizzazione di una mesh spesso implica il caricamento e la visualizzazione anche di immagini. Quest ultime sono utilizzate per effettuare 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 l aliasing, e quindi aumentare la qualità complessiva dell immagine. Si noti che nonostante il supporto ad un numero indefinito 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à caricata dal Renderer e le restanti semplicemente ignorate. Oltre a ciò la libreria permette di gestire l illuminazione della scena consentendo l aggiunta di molteplici fonti di luce nella scena e calcolando la 76

88 giusta illuminazione dell oggetto grazie alle normali delle facce di cui si compone. Infine non sono direttamente implementati nuovi shader ma si utilizzano quelli già presenti in OpenGL ES, si offre comunque il supporto ad un eventuale introduzione di nuovi shader Limiti La libreria non è molto supportata ed inoltre non è completa per raggiungere tutti gli obiettivi di questo lavoro di tesi. In primo luogo è concesso il caricamento del modello e della texture solo da memoria interna dell applicazione: ciò implica che questi file devono essere salvati come risorse interne a tempo di compilazione. Anche le varie opzioni di rendering, ad esempio se disegnare la scena in modalità wireframe, non possono essere impostate durante l esecuzione. La gestione dell input è assente ma è facilmente integrabile nella RendererActivity grazie alle API del SDK. Piuttosto la difficoltà maggiore risulta la simulazione fisica 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 l operazione di parsing del file, la libreria mantiene in memoria solamente i buffer di vertici e facce che consentono il disegno (VBO). In particolare il buffer contenente le coordinate dei vertici è costruito col secondo metodo esposto in e il buffer 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ò basarsi sulle informazioni dei buffer salvati: essi contengono informazioni duplicate che genererebbero un numero doppio di computazioni. Si devono perciò operare dei cambiamenti nel codice della libreria per implementare in modo opportuno tutte le specifiche richieste. 77

89 4.5 Sviluppo L applicazione in esame deve da un lato gestire la rappresentazione grafica e dall altro gli input dell utente. 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à alcuni dei compiti prefissati. Nei successivi punti si spiegano le modifiche svolte al codice di partenza della libreria e le integrazioni inserite per ottenere il risultato finale Avvio dell applicazione Alla partenza dell applicazione la Activity avviata è View3dActivity la cui schermata è minimale e adatta ad introdurre gli unici comandi eseguibili inizialmente dall utente. La scena 3D non è ancora creata e quindi l utente può richiamare il caricamento del modello attraverso l opzione Load Model. Si noti che tale attività, essendo la prima ad entrare nello stack di memoria sarà anche l ultima ad uscirne. Ciò implica che essa rimarrà nello stato di pausa mentre la visualizzazione del modello è attiva in un altra Activity, e verrà richiamata quando tale Activity verrà chiusa. Tutto ciò rende l applicazione molto funzionale in quanto l utente può caricare diversi modelli durante l esecuzione senza chiudere definitivamente il software ogni volta. 78

90 Figura 4.5: Schermata visualizzabile all avvio del software Caricamento dei file La libreria non consente il caricamento da memoria secondaria, si introducono quindi delle integrazioni nel codice che consentono di accedere ai file specificati dall utente. Si possono gestire i file sulla memoria di massa conoscendone il path completo. Questo è costituito da due parti: la prima riguarda la posizione della memoria esterna all interno del file system, mentre la seconda riguarda la posizione del file scelto dall utente. Un esempio di path completo è il seguente: /storage/sdcard0/prova/model.obj La prima parte del path (/storage/sdcard0) va ricavata attraverso le API del SDK dato che non è fissa per ogni dispositivo. La seconda invece va richiesta all utente attraverso la UI. Esempi di interazione sono visibili nelle seguenti figure. 79

91 Figura 4.6: Interfaccia grafica per l inserimento dei path di modello e texture fine di: Per maggiore usabilità sono introdotti dei controlli sul path inserito al controllare che il file esista e possa essere letto; verificare che l ortografia della stringa sia corretta (per es. vuota). stringa Fase di parsing Il parsing del file è l operazione principale di impostazione della scena in quanto è qui che si inizializza la maggior parte delle istanze su cui si lavorerà in seguito durante l interazione dell utente e la simulazione fisica. La libreria Min3D offre supporto al parsing di diversi tipi di file ma si è posta maggiore attenzione nell estensione OBJ dato che è molto diffusa e utilizzata in questo ambito [12]. La struttura del file, come anticipato nel capitolo 2, è molto semplice e al suo interno sono scritte le posizioni dei vertici, le coordinate U,V 80

92 delle texture per ogni vertice, le normali e le facce. Per quest ultime si memorizzano gli indici dei vertici che le compongono in ordine orario rendendo l esplicitazione delle normali delle facce non necessaria. La lettura del file è perciò di facile comprensione e in questa fase si possono operare delle modifiche alla libreria al fine di recuperare e salvare l informazione 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 file di tipo MTL che specifica l illuminazione dei materiali o le texture [13] 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 l utente non effettui uno scaling adeguato tramite le gesture di zoom. Per tale motivo è opportuno traslare e scalare il modello in modo che si trovi al centro della finestra generata dall Activity 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 è anch esso non costante ed è 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 Sviluppo della simulazione fisica Soddisfacimento dei vincoli Per gestire la simulazione di oggetti deformabili si introducono diverse classi e metodi. La classe più importante che permette di gestire il soddisfacimento dei vincoli è 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

93 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 all occorrenza. I metodi sviluppati più 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 è detto che tutti i vincoli siano risolti, piuttosto si opera un passo verso la soluzione finale. Al termine del rilassamento parziale dei vincoli si effettua un aggiornamento delle posizioni dei vertici nel buffer da cui si effettua il rendering. Si ricorda che in tale buffer i vertici sono ripetuti perciò si deve aggiornare la posizione del vertice più volte. Questa operazione è lineare in quanto si sfruttano gli indici contenuti nel buffer delle facce per ricavare le posizioni dei vertici da aggiornare nel VBO dei vertici su GPU. Picking L operazione di selezione e trascinamento di un vertice del modello è 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 effettuare il test delle distanze dalla retta stessa. La costruzione della retta avviene nel Renderer perchè si deve leggere lo stato di OpenGL corrente, in particolare le matrici ModelView e Projection. La griglia invece può essere determinata in fase di inizializzazione del modello e diventa una proprietà dell oggetto 3D. 82

94 Il calcolo del vertice a distanza minima avviene sempre nel Renderer come descritto nella sezione e viene inviato al MassSpringSystem per la determinazione del vincolo di picking. Al termine del trascinamento del vertice e della risoluzione dei vincoli si effettua un nuovo mapping delle coordinate dei vertici sulla griglia dato che esse sono cambiate a causa della risoluzione dei vincoli. Ciò consente di effettuare una nuova operazione di picking sui vertici spostati Gestione dell input La natura touch screen dei dispositivi in cui l applicazione verrà eseguita porta a gestire in modo molto più accurato i diversi input dell utente. Come mostrato nel precedente capitolo i movimenti che l utente può effettuare sono diversi, secondo le funzionalità che si vogliono attivare. Tutta la gestione avviene nell attività 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 fino a dieci tocchi simultanei dello schermo ma chiaramente al massimo due verranno utilizzati in ogni occasione nel software in sviluppo. Inoltre è 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 affinchè l utente possa scegliere se ruotare o trascinare un vertice della mesh. La soluzione più semplice consiste nell implementare un opzione che permetta di disattivare o meno la rotazione. Se essa è disabilitata la simulazione fisica viene avviata e in ogni time-step viene richiamato il soddisfacimento dei vincoli nel MassSpringSystem prima del rendering. Se invece la rotazione è abilitata si sfrutta la matematica dell Arcball per computare la matrice di rotazione da moltiplicare alla ModelView corrente dell oggetto. In particolare sono introdotte una serie di classi con le quali è possibile effettuare i calcoli di rotazione dell ArcBall ed ottenere la matrice 83

95 di rotazione. Essa verrà poi passata allo stato di OpenGL tramite il metodo updatescene di Obj3dView. In aggiunta, per meglio identificare lo stato della rotazione corrente, si introduce il disegno dell Arcball in cui è idealmente racchiuso l oggetto durante la rotazione. Figura 4.7: Disegno dell Arcball per controllare visivamente la rotazione applicata al modello Il riconoscimento delle due modalità è molto utile non solo per la gestione dell input ma anche per la fase di rendering poichè durante la rotazione i calcoli da effettuare saranno sicuramente minori rispetto alla fase di simulazione fisica. Il movimento del pinch to zoom è 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à utilizzato dal thread del rendering per applicare la trasformazione con le API di OpenGL al modello Menù e preferenze L abilitazione o meno della rotazione e altre impostazioni sono raggiungibili attraverso la pressione del tasto menù. Le specifiche di Android hanno sempre 84

96 imposto la presenza di tale tasto fisico e solo ultimamente il sistema si è svincolato da questa proprietà e sui dispositivi più recenti esso appare sotto forma di tasto virtuale sullo schermo quando occorre. Su ogni device la pressione del tasto apre il menù ossia una serie di opzioni selezionabili dall utente. Per rendere più usufruibile l interfaccia, nel menù sono riposti solo i comandi utilizzati più frequentemente: opzione per disabilitare la rotazione ed opzione per ricaricare il modello con le coordinate originali. Il resto delle impostazioni selezionabili è riposto in una schermata separata apribile con il tasto Settings. Figura 4.8: Menù visualizzato in basso nella schermata di Obj3dView. Nella fascia in basso si può visualizzare anche il set di tasti virtuali tipico di dispositivi Android privi di tasti fisici, il tasto menù è quello più a destra. Gli elementi del menù sono definiti nel file menu.xml contenuto tra le risorse dell applicazione. La funzione di Reload è utile nel momento in cui l utente vuole ricaricare in memoria il modello. Si deve inizializzare di nuovo la scena richiamando il metodo initscene così da rieffettuare il parsing del file e ripristinare tutti i valori originali delle coordinate dei vertici. La pressione dell opzione Settings determina l apertura dell attività SettingsActivity che gestisce la schermata riguardante le preferenze dell utente. Ogni applicazione Android è corredata di un file all interno della memoria di sistema chiamato SharedPreference adatto proprio a mantenere i dati di preferenza dell utente in maniera consistente anche dopo la chiusura dell applicazione stessa. Si ha a disposizione, quindi, un metodo pratico per mantenere le impostazioni e l unico compito da svolgere è definire le opera- 85

97 zioni possibili dell utente e impostare quando e perchè leggere o scrivere le preferenze. Figura 4.9: Schermata delle impostazioni La definizione degli elementi selezionabili all interno della schermata delle impostazioni è sempre possibile attraverso un file XML chiamato preference. In tale schermata si vogliono gestire diverse funzionalità di contorno rispetto a quelle già 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 L utente può scegliere se visualizzare o meno la texture. Se l opzione non è selezionata la texture non viene considerata, sempre se esiste, nella lettura del file MTL. 86

98 Invece la selezione di Load texture from internal memory consente di immettere il path della nuova texture da caricare. Essa si andrà 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 è necessario rieffettuare il parsing per ottenere il modello con le nuove preferenze. Il file MTL collegato al modello non viene modificato, 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ò scegliere se visualizzare il modello ad esempio in modalità wireframe. La pressione dell opzione render type consente di cambiare la modalità di visualizzazione, scegliendo nell elenco dei parametri riportati secondo la terminologia di OpenGL. 87

99 Figura 4.11: Scelta della modalità di disegno della mesh Preferenze sulla rotazione La rotazione può essere disabilitata anche in questa schermata oltre che nel menù. L attivazione o disattivazione dell opzione rendono visibile una scritta contestuale che indica se la deformazione è attiva o meno. Inoltre l utente può indicare se visualizzare o meno il disegno dell ArcBall. Figura 4.12: Opzione di rotazione con informazione sull abilitazione contestuale della deformazione 88

100 Impostazione dei parametri della simulazione Attraverso le impostazioni si può modificare il valore dei parametri k pressure e k dist 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 modificati attraverso uno slider dall utente. Lo slider relativo al k dist può assumere valori compresi tra 0.1 e 1: il valore di default è 1 (le distanze ritornano al valore originale) mentre il valore minimo non scende al di sotto di 0.1 per non rimuovere totalmente l effetto del vincolo. Lo slider relativo a k pressure, invece, può assumere valori da 0 a 1: un valore 0 rimuove l effetto del vincolo di volume, 1 è invece il valore di default e comporta il ritorno dell oggetto al volume originario. Figura 4.13: Slider per il cambiamento del parametro k dist, il cambiamento del parametro k pressure avviene in maniera simile. 89

101 Salvataggio dello stato Per come è strutturata un applicazione Android il ritorno alla schermata di un Activity in pausa genera un evento di resume su tale attività che comporta un ridisegno della scena. La libreria, tuttavia, non è strutturata in modo tale da salvare tutto il contesto mentre la RendererActivity è in fase di pausa. Per tali motivi alla chiusura delle impostazioni la scena viene reinizializzata. Ciò può comportare tempi di attesa più 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ò, per non perdere l informazione riguardo i vertici traslati per la simulazione, la configurazione dei buffer viene salvata prima dello stato di pausa e all occorrenza ripristinata. 90

102 Capitolo 5 Test e risultati In questo capitolo si mostra un analisi sui risultati dell implementazione sviluppata su piattaforma Android per descrivere cosa permettono di ottenere le tecniche illustrate. Si effettua in primo luogo un indagine sui dati riguardanti l occupazione di memoria primaria che solitamente su piattaforma mobile è limitata. Quindi si descrivono le tempistiche necessarie per portare a termine le principali operazioni legate alla simulazione. Infine si mostrano i risultati pratici ottenibili lavorando sui parametri in gioco nella simulazione che permettono di modificare i vincoli sulle distanze tra le particelle e i vincoli sul volume complessivo della mesh. 5.1 Analisi delle prestazioni La seguente analisi prestazionale è effettuata su un Samsung Galaxy Nexus, dispositivo che vanta una piattaforma hardware comprendente un processore dual-core da 1200 Mhz con una scheda grafica 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 effettuare diverse operazioni del software. In particolare si espongono i tempi per effettuare la fase di parsing, la fase di picking e il tempo richiesto da uno step di risoluzione dei vincoli e il 91

103 conseguente aggiornamento in memoria delle nuove coordinate dei vertici. Oltre a ciò si espone l occupazione di memoria media. Per meglio effettuare 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 effettuate nei tre casi differenti e segue una discussione su ogni test effettuato. Modello 1 Modello 2 Modello 3 Vertici Facce Edge Occupazione memoria 21 MB 24 MB 30 MB Tempi parsing 608 ms 710 ms 2783 ms Tempi picking 4 ms 8 ms 32 ms Tempi risoluzione vincoli 12 ms 26 ms 250 ms Tabella 5.1: Analisi prestazionale: confronto tra tre modelli diversi Occupazione di memoria primaria L occupazione di memoria RAM è 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 dell applicazione Tempo della fase di parsing Nella fase di parsing le tempistiche dipendono sia dalla lunghezza del file della mesh da leggere che dai calcoli relativi all inizializzazione dei vincoli strutturali. E in tale fase infatti che si devono calcolare: la lista di vertici, 92

104 facce e degli edge; le lunghezze a riposo degli edge; i gradienti dei vertici; l indicizzazione dei vertici nella griglia; il volume originario della mesh oltre che allocare opportunamente i VBO. Non sorprende quindi che all aumentare della complessità del modello aumenta notevolmente il tempo di attesa per il caricamento in memoria Tempo per il picking L operazione di picking dei vertici non è banale e come illustrato in precedenza si compone di numerose computazioni. L introduzione 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ù prossimo allo schermo utilizzando la ModelView. In tutti e tre i casi si ottengono comunque risultati accettabili Tempo per uno step di risoluzione dei vincoli La risoluzione dei vincoli è un operazione 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 dell applicazione. In tabella sono riportati i tempi di un singolo step e non si riporta il tempo totale di risoluzione dei vincoli poichè 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 è elevato e ciò non garantisce un animazione convincente, il valore di fps è molto basso. In effetti le operazioni si complicano all aumentare 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è aumenta notevolmente se il numero di vertici e facce è elevato. 93

105 Il secondo modello, invece, rappresenta un caso di complessità geometrica in cui il valore di fps è ben al di sopra del valore minimo di 25 fps. Il software implementato riesce perciò a gestire efficacemente mesh il cui numero di vertici, edge e facce è 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 all interno della mesh e quindi di operare sui vincoli determinati in base a tale struttura. Il principio è lo stesso del ragdoll esposto nel secondo capitolo, ossia la mesh poligonale più complessa è legata al ragdoll la cui struttura è semplice e, conseguentemente, il numero di vincoli non risulta eccessivo. 94

106 5.2 Effetti della simulazione In questa sezione si mostrano, attraverso degli screenshot effettuati durante l esecuzione dell applicazione sul dispositivo, gli effetti della simulazione se si cambiano i parametri k dist e k pressure che vengono utilizzati per la risoluzione dei vincoli di tipo distance e di overpressure. Il valore di tali parametri è limitato nel range [0...1] e l utente può liberamente modificarli tramite la schermata delle impostazioni. Si ricorda che un valore molto basso per tali parametri in pratica rimuove l effetto del vincolo relativo, mentre un valore alto prossimo a 1 determina un ritorno dell oggetto ad una forma vicina all originale Simulazione 1: assenza dell effetto dei vincoli Nella simulazione di seguito mostrata si fa uso di k dist = 0.1 e k pressure = 0. Tali valori sono relativamente bassi e comportano una deformazione importante per l oggetto. Il vincolo sul volume è praticamente assente mentre il vincolo sulle distanze degli edge comporta che questi ultimi ritornino solo al 10 % della distanza originale. L oggetto utilizzato è una sfera in quanto consente di osservare in modo diretto i cambiamenti alla sua struttura dovuti alla simulazione. 95

107 Figura 5.1: Simulazione 1 con kdist = 0.1 e kpressure = 0: si parte dalla immagine (a), l utente puo modificare l oggetto 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 dell oggetto risulta compromessa. 96

108 5.2.2 Simulazione 2: indipendenza delle due tipologie di vincolo In questa simulazione si mostra l effetto del cambio dei valori di k dist e k pressure su una sfera: in particolare si parte da una deformazione con k dist = 0.1 e k pressure = 0, quindi si mostra la deformazione attivando i vincoli di volume con k pressure = 1, infine si mostra l effetto del cambio del parametro k dist a 1 mantenendo k pressure = 1. Quando si attivano i soli vincoli di overpressure sulle particelle si nota che il ritorno alla forma originale non è affatto garantito: l oggetto a causa della configurazione di partenza tende ad allungarsi per ritornare al volume originale. Figura 5.2: Simulazione 2: effetto del cambio dei parametri, prima k pressure e poi k dist. A sinistra k pressure = 0, k dist = 0.1; al centro k pressure = 1, k dist = 0.1; a destra k pressure = 1 e k dist = Simulazione 3: variazione del parametro di tipo distance Nella simulazione mostrata in Fig. 5.3 si parte con un oggetto deformato con k dist = 0.1 e k pressure = 1, quindi si procede ad aumentare il valore di k dist a 0.5 e a 1. Si vuole mettere in risalto il fatto che tali vincoli sono entrambi importanti per mantenere la struttura dell oggetto. Infatti, anche con un valore alto di k pressure, la forma dell oggetto risulta comunque compromessa 97

109 (si veda l immagine iniziale della seguente figura). Se si modifica opportunamente l oggetto, il volume rimane invariato anche se la forma è diversa dall originaria. Figura 5.3: Simulazione 3: variazione di k dist. A sinistra k pressure = 1, k dist = 0.1; al centro k pressure = 1, k dist = 0.5; a destra k pressure = 1 e k dist = Simulazione 4: variazione del parametro di tipo pressure Gli effetti mostrati nella seguente figura descrivono quanto il parametro k pressure condizioni la forma dell oggetto. Si passa da un valore di 0.1 a 0.5, quindi a 1, mantenendo il valore di k dist costante uguale a 1. Se si applicano delle modifiche alla struttura della sfera come nell immagine iniziale, aumentando il valore di k pressure si ottiene un rigonfiamento dell oggetto al fine di raggiungere il volume definito. 98

110 Figura 5.4: Simulazione 4: cambio del parametro kpressure da 0.1 (a sinistra), 0.5 (al centro) e 1 (a destra) Simulazione 5: influenza dei vincoli su una mesh complessa La seguente simulazione riporta gli effetti del cambio dei parametri su una mesh piu complessa. Da una situazione stazionaria si modifica l oggetto con kdist = 0.1 e kpressure = 0, quindi si attiva prima il vincolo di volume con kpressure = 1 e infine si aumenta il valore di kdist a 1. Nonostante si esegua una deformazione in molti punti della mesh, il sistema mass-spring riesce a ridefinire una struttura molto simile all originale 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 piu complessa come quella raffigurata in Fig. 5.5 che riprende le sembianze umane. 99

111 Figura 5.5: Simulazione 5: effetti del cambio dei parametri su una mesh piu 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.

112 5.2.6 Simulazione 6: ritorno alla forma originale Dalle precedenti simulazioni si è potuto notare che in alcune situazioni la mesh non ritorna alla esatta forma originale dopo la deformazione. In effetti le uniche tipologie di vincolo implementate non bastano a garantire che la forma sia rispettata. Nell articolo di Muller et al. [30] si definisce una tipologia aggiuntiva di vincolo che può preservare meglio questo aspetto. Il vincolo di bending in questione permette di controllare l angolo diedro tra due facce adiacenti e quindi non dipende dalla lunghezza dei lati dei triangoli. Garantendo che l angolo sia prossimo all originale la mesh risulterà meno deformata al termine della simulazione. Nella seguente figura si mostrano gli artefatti provocati dai vincoli implementati, in particolare si applica la stessa deformazione all oggetto in un caso con k pressure = 0 e nell altro con k pressure = 1 mantenendo sempre k dist =

113 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 all originale cerchiate. Si puo osservare come il rispetto dei vincoli di volume diminuisca il numero di deformazioni. 102