SVILUPPO CLIENT 3D OPENGL IN JAVA

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "SVILUPPO CLIENT 3D OPENGL IN JAVA"

Transcript

1 Relazione di Tirocinio anno accademico 2007/2008 SVILUPPO CLIENT 3D OPENGL IN JAVA Candidato: Michele Zangari Tutore Aziendale: Ing. Andrea Lagomarsini Tutore Accademico: Prof. Giuseppe Attardi

2 Indice Struttura della relazione Introduzione Le basi Tecnologie Java Java Monkey Engine AISAC OpenGL LWJGL Eclipse IDE, SWT e JFace Linux / Unix Fase di studio Concetti di grafica tridimensionale e caratteristiche del Java Monkey Engine Scenegraph Frustum Bounding System Spatials Picking RenderStates Lights ColorRGBA Controllers Struttura di AISAC Server Imaging Console 3D I primi passi con il Java Monkey Engine Test di base Test Luci I primi passi con AISAC Struttura del mondo Caricamento del mondo Runtime e Singleton pattern Verso gli obiettivi finali Integrazione di algoritmi di picking Gizmo Primi tentativi... 58

3 6.1.3 Eventi e loro gestione Ultimi test Soluzione finale Ciclo Giorno Notte Quaternion Ruotare un oggetto SpatialTransformer Suddivisione del tempo Colore della luce Gestione dell ora LevelLight e LevelLightController Editor Luci Conclusioni Indice figure e tabelle Bibliografia... 92

4 The light in the world comes principally from two sources: the sun, and the student's lamp. Christian Nestell Bovee (Scrittore)

5 Struttura della relazione Dopo aver introdotto il lavoro svolto e gli obiettivi preposti, la relazione verrà strutturata secondo il seguente schema: - Capitolo 2 : verranno descritte le tecnologie sfruttate e studiate nel corso del progetto. - Capitolo 3 : inizia la descrizione del lavoro svolto. Per prima cosa si illustrerà la fase di studio delle tecnologie e dei concetti con cui si è avuto a che fare. - Capitolo 4 : i primi passi con il motore grafico Java Monkey Engine. - Capitolo 5 : le prime prove con AISAC. - Capitolo 6 : le scelte realizzative; errori commessi, test effettuati e scelte definitive. - Capitolo 7 : conclusioni sul lavoro svolto e considerazioni su possibili alternative alle soluzioni implementate, future migliorie ed eventuali bug presenti. Esempi con codice sul risultato delle modifiche apportate ad AISAC saranno inseriti durante l analisi del percorso di sviluppo. Nelle ultime pagine presenti anche un indice delle figure e tabelle presenti e una bibliografia con tutti i riferimenti citati e utili ad approfondire gli aspetti trattati in tutta la relazione.

6 1. Introduzione L obiettivo del progetto è l estensione di un applicazione java in grado di rappresentare un mondo virtuale e capace di interagire con componenti lato server per la rappresentazione del mondo reale. Il lavoro è stato incentrato sull arricchire l applicazione con le seguenti nuove funzionalità: simulazione del ciclo giorno / notte basata sull'ora reale, locale o remota a seconda che si lavori offline - online. gestione dell illuminazione del mondo virtuale con possibilità di creare, modificare e rimuovere a piacimento, mediante interfaccia grafica, i tipi di luce messi a disposizione dal motore grafico. integrazione del picking di oggetti con una serie di algoritmi che permettono la manipolazione di oggetti tridimensionali presenti nel mondo virtuale. ed è stato svolto sotto la supervisione dell Ing. Lagomarsini presso l azienda APAI srl con sede a Fosdinovo (MS). L ambiente tranquillo e la disponibilità del personale di APAI hanno permesso di svolgere il lavoro in serenità e autonomia. Iniziato nel mese di Ottobre, il progetto è stato portato a termine nel corso del mese di Giugno con un interruzione del lavoro nei mesi di dicembre,gennaio e febbraio causa esami.

7 1.1 Le basi La base di partenza per il progetto è stata l applicazione AISAC (Apai Innovative System for Automation and Control), in fase di sviluppo interno presso APAI, e che definirei un ambizioso sistema di sorveglianza e monitoraggio mediante gestione di componenti domotici. 1 Per ciò che concerne la rappresentazione del mondo virtuale, AISAC si appoggia sin dall inizio al motore grafico open source JAVA MONKEY ENGINE, interamente basato su Java. 2 Le possibili estensioni esaminate inizialmente sono state: - introdurre la possibilità di usare modelli tridimensionali con scheletro - gestione di profili utente - inserimento di una camera ad inseguimento per il tracking di oggetti in movimento - algoritmi di picking per interazione con gli oggetti del mondo 3d - gestione dell illuminazione e dei tipi di luci - implementazione di un ciclo giorno/notte - uso di terreni 3d - caricamento dei modelli 3d tutto tramite xml, unificato al metodo di caricamento dei livelli - gestione delle ombre Alcuni di questi aspetti inizialmente presi in esame sono stati comunque trattati (la camera ad inseguimento ad esempio cosi come l uso di modelli con scheletro e il caricamento di modelli 3d via file xml) ma in fine tralasciati per concentrarsi su quelli considerati più rilevanti: 1 Vedere capitolo 2 Tecnologie per una descrizione più ampia. 2 Vedere capitolo 2 Tecnologie per una descrizione più ampia.

8 - l illuminazione del mondo con gestione completa di luci e implementazione del ciclo giorno/notte - l uso di algoritmi di picking che permettessero di selezionare e manipolare oggetti tridimensionali. Da una prima analisi si è potuto constatare come il reparto illuminazione del mondo virtuale di AISAC, fosse sì presente, ma basilare, con una luce globale con posizione fissa ad illuminare il tutto, così come gli algoritmi di picking per gli oggetti tridimensionali erano abbozzati ma non ancora integrati nell applicazione.

9 2. Tecnologie Di seguito un elenco delle principali tecnologie incontrate e utilizzate nel corso del processo di sviluppo: JAVA PROGRAMMING LANGUAGE JAVA MONKEY ENGINE AISAC OPENGL LWJGL SWT JFACE LINUX/UNIX ECLIPSE PLATFORM 2.1 Java Linguaggio di programmazione orientato ad oggetti, indipendente dalla piattaforma usata e contenente strumenti e librerie per il networking. Derivato dal C++ e creato da James Gosling e altri ingegneri della Sun Microsystems 3, la piattaforma di programmazione Java è fondata sul linguaggio stesso, sulla JAVA VIRTUAL MACHINE (una macchina virtuale che esegue i programmi prodotti della compilazione di sorgenti) e sulle API (application programming interface, ovvero un insieme di procedure rese disponibili al programmatore per facilitare la stesura di codice e l implementazione di funzioni nel proprio software). (1) E il linguaggio di programmazione usato per lo sviluppo del progetto. 3 Sito Web Ufficiale :

10 2.2 Java Monkey Engine Il Java Monkey Engine (jme d ora in avanti) è un API grafica altamente performante basata sul concetto di Scenegraph. Costruito con l intento di colmare la mancanza di motori grafici scritti in Java e con pieno supporto alle più moderne feature messe a disposizione da altri engine, permette di integrare qualsiasi sistema di rendering. Al momento è supportato LWJGL 4, con piani per un futuro supporto per JOGL 5. jme supporta differenti tipi di geometrie come superfici di Bezier, linee, punti, modelli 3D (Milkshape, MD2,ASE,3DS,OBJ ), così come molte primitive quali sfere, cilindri, esagoni, piramidi, ottaedri, dodecaedri. Presente anche il supporto a molti effetti di alto livello quali lens flare, sistemi particellari, bloom, GLSL shaders, simulazione di tessuti, bump mapping. Per gli scopi del progetto, la parte più interessante è certamente il sistema di illuminazione fornito dal jme. Questo permette di gestire fino a otto luci contemporaneamente e mette a disposizione utilità per la selezione ottimale delle stesse. I seguenti tipi di luce (che verranno ampiamente discussi nei capitoli successivi) : - Direzionale (DirectionalLight) - Puntuale (PointLight) - Spot (SpotLight) sono stati sfruttati per il conseguimento degli obiettivi preposti. jme è completamente open source sotto licenza BSD. 6 (2) 4 Lightweight Java Game Library 5 Java OpenGL 6 Famiglia di licenze permissive per software. Molte sono considerate libere ed open source.

11 2.3 AISAC Sistema di sorveglianza di terza generazione, AISAC si presenta come sistema integrato per la gestione di tutti gli impianti domotici, unendo la sicurezza alla comunicazione. Il sistema garantisce un assoluta capacità di controllo che, unita all automazione domotica, eliminano i problemi derivanti dal presidio dell uomo. L utilizzo della realtà virtuale rende il software uno strumento di gestione completo attraverso l utilizzo della telefonia mobile e fissa, di mms e sms e della posta elettronica. AISAC è un progetto tuttora in fase di sviluppo e in continua e rapida evoluzione OpenGL OpenGL è un API sviluppata da SGI 8 nel 1992 composta di circa 150 comandi che permettono di interfacciarsi con l hardware di accelerazione grafica del sistema, al fine di produrre applicazioni 3D interattive. È estremamente portabile, in quanto (al contrario di Direct3D, l architettura di rendering 3D integrata nelle DirectX) è utilizzabile su Mac OS, OS/2, UNIX, Windows 95/98, Windows 2000, Windows NT, Linux, OPENStep, e BeOS. Inoltre le sue funzionalità e comandi possono essere richiamati da ambienti di sviluppo basati su linguaggi molto differenti fra loro, quali Ada, C, C++, Fortran, Python, Perl e Java, fornendo inoltre una totale indipendenza dai protocolli e dalle tipologie di rete. 7 Sito Apai : 8 Silicon Graphics Incorporated -

12 (3) OpenGL è utilizzato nel progetto mediante l uso della libreria LWJGL descritta di seguito. 2.5 LWJGL La Lightweight Java Game Library è una soluzione mirata direttamente a programmatori Java, professionisti e non, per permettere lo sviluppo di titoli commerciali scritti in java. LWJGL fornisce agli sviluppatori l accesso a librerie crossplatform ad alte prestazioni come OpenGL e OpenAL 9 per giochi e suoni 3D allo stato dell arte. Addizionalmente LWJGL fornisce l accesso ai più svariati controllers, tutto in una semplice e diretta API. Non è pensata per rendere particolarmente facile lo sviluppo, ma piuttosto per permettere agli sviluppatori di accedere a risorse che sono semplicemente non disponibili o male implementate sull esistente piattaforma Java. LWJGL è disponibile sotto licenza BSD, open source e liberamente utilizzabile a nessun costo. (4) (5) È la libreria usata dal jme per il rendering di contenuto OpenGL. 2.6 Eclipse IDE, SWT e JFace Eclipse è una community open source i cui progetti sono finalizzati alla costruzione di una piattaforma estendibile e framework applicativi per realizzare, rilasciare e 9 Open Audio Library -

13 gestire software nel corso del proprio ciclo di vita. Fra la moltitudine di progetti realizzati e in fase di realizzazione il più conosciuto è certamente l Eclipse IDE, progettato per sviluppatori Java, che contiene tutto ciò di cui si ha bisogno per costruire un applicazione Java. Considerato da molti la miglior piattaforma di sviluppo Java disponibile, fornisce strumenti di validazione, compilazione incrementale, riferimenti incrociati, assistenza nella stesura del codice, editor XML e molto altro. (6) (7) È la piattaforma usata nel corso di tutto il progetto per la stesura del codice. L acronimo SWT sta per STANDARD WIDGET TOOLKIT, ovvero un insieme di strumenti software concepiti per facilitare e uniformare lo sviluppo di interfacce grafiche (GUI). I toolkit grafici Java si dividono in due categorie: Heavy Weight, i quali usano i widget forniti dal sistema operativo; Light Weight, che implementano i propri widget. SWT fa parte della prima. Originariamente sviluppato da IBM, è ora mantenuto dalla Eclipse Foundation insieme con il sopracitato Eclipse IDE. Scritto in Java, l implementazione di SWT accede alle librerie native GUI (Graphic User Interface) del sistema operativo usando JNI (Java Native Interface) in maniera simile ai programmi scritti usando API specifiche del sistema operativo. I programmi che usano SWT sono portabili ma l implementazione del toolkit, nonostante il fatto che sia scritta in Java, è unica per ogni piattaforma. JFace è un toolkit per interfacce utente con classi per la gestione dei più comuni aspetti inerenti la programmazione di interfacce, ed è indipendente dal gestore grafico del sistema operativo sia per API sia per implementazione. Designato per lavorare insieme con SWT, include gli usuali strumenti per comporre immagini e font, testo, finestre di dialogo, preferenze, report sul progresso di operazioni lunghe. Due dei suoi aspetti più interessanti sono le actions e i viewers.

14 Il meccanismo delle action permette ai comandi utente di essere definiti indipendentemente dalla loro esatta posizione nell interfaccia. I viewers sono invece usati per semplificare la presentazione di dati dell applicazione strutturati come liste, tabelle o alberi. SWT / JFACE è un progetto open source, pubblicato sotto licenza EPL (Eclipse Public License). (8) (9) Sono gli strumenti usati per la realizzazione dell interfaccia grafica di AISAC. 2.7 Linux / Unix Linux è un sistema operativo gratuito di tipo Unix originalmente creato da Linus Torvalds con l assistenza di sviluppatori di tutto il mondo. Si può pensare a Linux come diviso in due parti: un kernel, l interfaccia base fra l hardware e gli altri sistemi software, e le funzioni che vengono eseguite su di esso, come le interfacce grafiche e le generiche applicazioni. Sviluppato sotto licenza GNU GPL 10, è un software open source che può essere modificato e ridistribuito liberamente. Le differenti versioni disponibili di Linux sono dette distribuzioni. Per lo sviluppo di questo progetto si è lavorato sulla distribuzione Ubuntu. 11 (10) Tutte le tecnologie legate al contesto realizzativo vero e proprio qui descritte, (ad eccezione quindi di Linux e dell Eclipse IDE ), sono state scelte obbligate sin dall inizio, in quanto già presenti come parte integrante dell applicativo AISAC, reale base di partenza del tirocinio. Inoltre è da considerare che ad eccezione del 10 General Public License: 11 Sito web di riferimento :

15 linguaggio Java, dell ambiente Linux / Unix e dell IDE Eclipse, non si aveva nessuna o quasi familiarità con esse. 3. Fase di studio La poca esperienza in ambito di programmazione 3d e soprattutto la vastità e complessità dell applicativo alla base del lavoro, hanno reso necessaria una prima e lunga fase di studio dello stesso e del motore grafico sfruttato per la gestione degli ambienti virtuali. Comprendere a pieno l intricata struttura di AISAC e individuare le funzionalità interessanti del motore grafico è stato l obiettivo di questa fase. Fase che si è rivelata anche come la parte più intricata del progetto di tirocinio e in realtà non ha mai avuto fine. Non è stato possibile infatti sviscerare tutti gli aspetti interessanti dall inizio, sia per la difficoltà di trovarsi di fronte a concetti del tutto nuovi sia per la complessità intrinseca di essi. Nel percorso successivo di sviluppo vero e proprio è capitato spesso di ritrovarsi di fronte a problematiche nuove che hanno richiesto ulteriori studi, test e approfondimenti. 3.1 Concetti di grafica tridimensionale e caratteristiche del Java Monkey Engine Prima di addentrarsi nello studio approfondito di Aisac, si è dovuto dedicare un po di tempo ad alcuni aspetti teorici di grafica tridimensionale, sia generali, sia più specifici del motore. Il nucleo di ogni applicazione grafica è il loop, ovvero una porzione di codice che viene eseguita più e più volte nell arco del ciclo di vita del programma. Questo loop è responsabile della coordinazione di un basilare ciclo di aggiornamento/disegno della scena. jme fornisce diverse implementazioni del loop e a diversi livelli di astrazione che permettono sia di effettuare test veloci (SimpleGame, dove ci si deve preoccupare

16 solo di inizializzare i dati della scena), sia di avere la possibilità di gestire direttamente anche la fase di aggiornamento e di rendering (BaseGame, l implementazione di base appunto). Tutte i tipi di implementazione seguono comunque lo stesso concetto di base, illustrato dalla seguente figura : Figura 1 : loop di base (single threaded) In sostanza dopo aver inizializzato il contenuto, si entra nel ciclo di aggiornamento / disegno dello scena fin tanto che l applicazione rimane in esecuzione. Prima di terminare vengono rilasciate le risorse occupate.

17 Per quanto riguarda la creazione e gestione della scena, uno dei primi argomenti affrontati in assoluto è stato il concetto di scenegraph Scenegraph È un modello concettuale di progettazione di applicazioni grafiche tridimensionali interattive. Uno scenegraph è un grafo diretto aciclico (DAG, Directed Acyclic Graph) in cui i nodi contengono le informazioni sugli oggetti della scena e le loro proprietà e gli archi rappresentano le relazioni fra i nodi. Il rendering di ogni elemento della scena, elemento normalmente posizionato in una foglia, si ricava con l attraversamento del grafo dalla radice alla foglia stessa, accumulando tutte le informazioni necessarie durante il cammino (che è unico). (11) Sfruttare questo modello permette di organizzare i dati in strutture ad albero, dove un nodo genitore può contenere qualsiasi numero di nodi figli, ma un nodo figlio ha un solo genitore. Nel contesto di un applicazione grafica, tipicamente un nodo rappresenta un entità o un oggetto che fa parte della scena, e un operazione applicata ad esso si propaga automaticamente a tutti i suoi figli. Questo tipo di organizzazione porta alcuni principali vantaggi: I dati delle scene da rappresentare, sono tipicamente molti e disposti in base alla loro locazione nello spazio. Questo permette di farsi facilmente un idea di come raggrupparli nel mondo 3d. Questa organizzazione gerarchica fornisce un punto di riferimento per la locazione spaziale degli oggetti. In sostanza, si è a conoscenza del fatto che un nodo genitore di un ramo del grafo, conterrà spazialmente tutti i figli. Quindi se non è possibile vedere il nodo, non saranno visibili nemmeno i figli, dando la possibilità di scartare parti dello scenegraph che non sono rilevanti, spendendo cicli di elaborazione solo sui rami che sono visibili.

18 Molti oggetti nel mondo sono già rappresentati secondo una struttura ad albero, con il risultato che è più semplice immaginarsene una rappresentazione mediante scenegraph. Si pensi ad una persona: un piede sarà dipendente direttamente dalla locazione e dall orientamento della caviglia, che a sua volta dipende dalla parte bassa della gamba e così via. Siccome la locazione e l orientamento dei nodi è ereditata a seconda di come è strutturato l albero, ruotare la gamba farà sì che venga ruotato anche il piede. È semplice esprimere il concetto di scenegraph mediante altri strumenti come per esempio l XML. Questo permette di creare scenari utilizzando altre utilità più immediate per poi essere facilmente caricati dal jme. Come già detto, i nodi sono organizzati, oltre che logicamente, anche in base alla loro locazione nello spazio, e questo da la possibilità di scartare velocemente interi rami dell albero durante l elaborazione dei dati che costituiscono la scena. In termini di programmazione grafica, il significato di scartare assume il concetto del cosiddetto culling (o clipping) dei dati, ovvero quel meccanismo per cui solo gli oggetti visibili nella scena vengono processati. Questo permette di ottimizzare il rendering di uno scenario complesso che può essere renderizzato velocemente evitando di processare dati non visibili all osservatore. La maggior parte di una scena, infatti, non è visibile completamente in un dato istante.

19 Ecco una possibile organizzazione di una scena costruita sul modello dello scenegraph: PALAZZO PIANO 1 PIANO n STANZA 1 STANZA n STANZA 1 STANZA n Oggetto 1 Oggetto Oggetto n Oggetto n Figura 2 : esempio di struttura basata su scenegraph Questo esempio permette di comprendere più facilmente i vantaggi portati da questo approccio in fase di rendering. Supponiamo che l osservatore sia nel nodo stanza 1, che fa parte del nodo piano 1, automaticamente si possono trascurare tutti gli altri nodi piano (e di conseguenza i relativi figli, cioè tutte le stanze e gli oggetti che le compongono ) e processare poi la stanza 1 con relativi figli. La struttura ad albero permette quindi di effettuare una partizione dello spazio secondo un preciso ordine gerarchico. Questo, unitamente al cosiddetto view frustum, risulta essere fondamentale nelle operazioni di culling.

20 3.1.2 Frustum Il frustum è un tronco di piramide costruito nel seguente modo: il vertice coincide con la posizione della telecamera (ovvero il nostro punto di osservazione). La piramide è tagliata da due piani paralleli fra loro e perpendicolari all asse del frustum. Questi due piani prendono rispettivamente il nome di near e far plane. La seguente figura illustra il concetto di frustum: Figura 3 : rappresentazione del frustum in 2D L idea è quella di far si che vengano renderizzati solo gli oggetti che si trovano, anche solo parzialmente, nel volume di spazio racchiuso dal viewing frustum (in giallo nella figura), così da ridurre il numero di oggetti che saranno elaborati dal processore grafico.

21 Stabilire se un oggetto è contenuto o meno nel frustum (frustum culling) è però un operazione dispendiosa dal punto di vista computazionale, in quanto va effettuata per tutti gli oggetti presenti nella scena e ad ogni fotogramma prima che questo venga disegnato. Strutturare la scena secondo il modello concettuale dello scenegraph permette, come visto nell esempio precedente, di avere un ordinamento gerarchico dello spazio, e quindi diminuire il numero di oggetti su cui effettuare questi calcoli, diminuendo di conseguenza il costo computazionale di queste operazioni. In sostanza l uso abbinato di scenegraph e frustum permette di effettuare il culling in maniera rapida ed efficiente, consentendo la rappresentazione di scene più complesse senza pagarne troppo in termini di prestazioni. (12) Bounding System Una delle chiavi per la velocità (in termini prestazionali) nel jme, direttamente legata al concetto di culling. Ogni geometria, dal modello 3d complesso alla primitiva più semplice, può essere racchiusa in un bounding volume, ovvero una geometria più semplice (che può essere una sfera, un cubo o un cubo orientato) che lo circondi. La figura 3 illustra un esempio di bounding volume. In questo caso è stata usata una sfera per racchiudere il modello 3d: Figura 4 : esempio di bounding volume

22 Questa soluzione permette a jme di effettuare test veloci e facili per determinare se l oggetto considerato è anche solo parzialmente visibile. Basti pensare al modello 3d di una figura umana. A livello computazionale, determinare se tale modello rientra o meno nel view frustum può essere decisamente dispendioso, in quanto il test andrebbe fatto su ogni poligono che lo compone. Per cui, un invisibile e matematicamente semplice volume come una sfera o un cubo, piazzato intorno al modello, rende possibile evitare di testare il modello complesso, basandosi invece sull oggetto semplice che lo include per determinarne la visibilità Spatials Uno spatial definisce la classe base per tutti gli elementi di uno scenegraph. Vi sono due principali tipi di Spatials : Geometry (le geometrie vere e proprie) Nodes (i nodi) Entrambi derivano da Spatial e in termini generali si può dire che Geometry è contenuta nei nodi foglia, mentre Node è contenuta nei nodi genitore (o nodi interni), di conseguenza la prima contiene effettivi dati grafici, mentre la seconda contiene gli elementi dello scenegraph. La classe Spatial è in grado di gestire collegamenti al genitore, trasformazioni locali e non, e bounding volumes. Mantiene anche una lista di RenderStates (usati per mantenere gli stati OpenGL degli Spatial) e Controllers (oggetti che permettono di controllare altri oggetti). Entrambi saranno definiti più accuratamente nei paragrafi successivi. Lo Spatial definisce in sostanza come una scena può essere costruita ed è l impalcatura sulla quale è costruito jme. (13) (14)

23 3.1.5 Picking Il picking è quel processo che permette di determinare quale oggetto del mondo è selezionato attraverso l interazione dell utente, per esempio con un click del mouse. Tipicamente, il picking implica la selezione di un oggetto tridimensionale dalla sua proiezione bidimensionale sullo schermo puntando e cliccando con il mouse. Questo processo viene gestito nel seguente modo: si crea un raggio (una linea che comincia in un punto A per continuare attraverso un punto B verso l infinito) da un punto selezionato sul piano di proiezione (ossia il piano bidimensionale che definisce lo schermo, dove tutti i vertici tridimensionali sono trasformati per creare l immagine da mostrare). Ogni oggetto che il raggio interseca dopo aver passato il piano di proiezione è un potenziale oggetto per la selezione. Il picking può essere considerato un caso specifico di Collision Detection (il processo che determina se due corpi sono entrati in contatto in un periodo di tempo relativamente breve). Il supporto per il picking in uno scenegraph gerarchico comporta l esame ricorsivo del grafo fino a che ogni nodo foglia è raggiunto o escluso. Per sfruttare i vantaggi dello scenegraph, se si determina che un Node non è selezionato, tantomeno lo saranno i suoi figli, che pertanto saranno esclusi dal test. Il picking fa un uso estensivo del metodo di intersezione presente nella classe Bounding Volume. jme fornisce un completo Picking System (sistema di Picking) costruito sulla base di tale funzionalità per rendere questa procedura più semplice. (15)

24 3.1.6 RenderStates Questi stati definiscono la qualità della Geometry che deve essere disegnata. Mentre quest ultima definisce i dati che devono essere renderizzati, un RenderState definisce l aspetto di tali dati. Questo include cose come il texture mapping (TextureState), i materiali (MaterialState), l illuminazione (LightState) etc. I RenderStates sono mantenuti secondo una struttura gerarchica. Di base, un figlio ha gli stessi stati del genitore (a meno che, ovviamente, il figlio non abbia un insieme specifico di stati settati). Questo permette il raggruppamento di oggetti simili e minimizza il costo computazionale del cambio di stato. Per esempio, se abbiamo una collezione di alberi localizzati nella stessa area generica, che condividono le stesse texture, si possono aggiungere questi alberi allo stesso genitore e settare il TextureState solo ad esso. Non solo questa soluzione è più veloce, ma conserva memoria creando un singolo TextureState per tutto il gruppo di oggetti. Ogni Spatial può avere un solo RenderState (uno per ogni tipo) in un dato momento e ogni RenderState può essere abilitato e disabilitato a tempo di esecuzione con una semplice chiamata al metodo opportuno. (16), (17) Ecco una descrizione dei tipi di RenderState usati in fase di sviluppo : TextureState definisce un RenderState che gestisce le texture associate ad uno Spatial. Può gestire più textures in un dato momento. Più precisamente il numero di texture che è possibile mantenere in un TextureState è pari al numero di unità di texture disponibile nel processore grafico (numero che può essere ottenuto mediante una semplice chiamata al metodo opportuno). Ogni texture può essere aggiunta allo state in una unità specifica (la cui numerazione parte da 0) e il TextureState si occuperà per l utente di tutte le

25 inizializzazioni richieste. Tutti gli attributi della texture sono invece gestiti dalla stessa classe Texture. Inoltre diversi TextureStates possono essere combinati attraverso lo scenegraph per creare dinamicamente un multitexture TextureState. Il modo in cui vengono combinati dipende dai settaggi scelti per lo Spatial interessato. Esistono diversi tipi di cosiddetti combine mode: - OFF : non viene applicata nessuna texture all oggetto. - INHERIT : eredita il combine mode dal genitore (default). - REPLACE : fa si che non vengano aggiunte altre texture, ma usate solo quelle del proprio TextureState. - COMBINE_FIRST : combina le textures partendo dal nodo radice muovendosi verso lo Spatial dato. Ignora gli stati disabilitati e si ferma quando il massimo numero di unità di texture è raggiunto. - COMBINE_CLOSEST : combina le textures partendo dal dato Spatial e muovendosi verso la radice. Ignora anch esso gli stati disabilitati e si ferma raggiunto il massimo numero di unità di texture. - COMBINE_RECENT_ENABLE : simile a COMBINE_CLOSEST, ma se raggiunge uno state disabilitato, si fermerà in quel punto (oltre a fermarsi se non ci sono altri stati da combinare o il numero massimo di unità di texture è raggiunto). (18) AlphaState È una proprietà di un nodo che influisce sulla sua trasparenza e traslucidità e su quella dei suoi figli. Permette di decidere quanto della geometria di un nodo sarà visibile. Per esempio si può far si che una finestra tinteggiata di

26 verde appaia leggermente verde e così tutti i nodi dietro di essa, con la camera in grado di vedere attraverso la finestra stessa gli oggetti dall altra parte. Mentre la trasparenza controlla la nostra visibilità attraverso gli oggetti, la traslucidità controlla le proprietà della luce e del colore che passa attraverso un oggetto e le irradia al di fuori di esso per influire anche sugli oggetti che lo circondano. L origine del termine Alpha ha a che fare con il fatto che il canale alpha di un immagine rappresenta proprio il canale dell opacità. Un pixel con un valore dello 0% nel suo canale alpha è completamente trasparente, mentre un valore del 100% lo rende completamente opaco. Valori compresi fra 0% e 100% permettono di vedere attraverso il pixel mostrando ciò che vi sta dietro. (19) CullState Determina quale parte, di un particolare triangolo (front, back, entrambe o nessuna) di un oggetto, sarà visibile quando questo è renderizzato. Per default entrambe le facce saranno visibili. Vi sono tre opzioni : - CS_FRONT - CS_BACK - CS_NONE Un tipico uso del CullState è quello di far si che il renderer non si preoccupi dei triangoli che sono rivolti lontano dalla camera (CS_BACK) per fornire un significativo aumento di velocità al processo. (20) ZBufferState Questo RenderState permette di definire come debbano essere renderizzati i pixel che sono sovrapposti. Un test di profondità controlla la posizione dei

27 pixel sullo schermo e deve poter determinare in caso di presenza di due (o più) pixel nella stessa locazione (e a profondità differenti) quale dei due deve essere disegnato prima. Intuitivamente andranno disegnati prima quelli più vicini all osservatore (la camera). È comunque possibile scegliere fra diversi valori in base all effetto che si vuole ottenere. MaterialState Definisce come la luce interagisce con l oggetto. Quindi come sarà riflessa, se un certo quantitativo di luce venga emanata dall oggetto, etc. Prima di introdurre in dettaglio i possibili attributi di un MaterialState, è bene specificare come effettivamente nel mondo reale reagiscano alla luce diversi tipi di superficie. Da (21) : Quando la luce colpisce una superficie, una parte di essa è assorbita, e una parte è riflessa. Se la superficie è opaca, assorbimento e riflessione coinvolgono tutta la luce che ha colpito la superficie. Se invece la superficie è traslucida, parte della luce è trasmessa attraverso il materiale e, una volta riemersa, andrà ad interagire con altri oggetti. Le interazioni fra luce e materiali possono essere classificate nei tre seguenti gruppi: 1. Le superfici speculari appaiono brillanti poiché la maggior parte della luce riflessa è diffusa in un intervallo molto ristretto di direzioni attorno alla direzione di riflessione. Gli specchi sono superfici perfettamente speculari. La luce incidente può essere parzialmente assorbita, ma tutta la luce riflessa emerge secondo un singolo angolo di riflessione, in accordo alla regola secondo cui l angolo di incidenza della radiazione luminosa è uguale all angolo di riflessione. 2. Le superfici diffusive sono caratterizzate dal fatto che la luce riflessa è diffusa in tutte le direzioni.

28 3. Le superfici traslucide lasciano penetrare parte della luce, che poi riemerge da un altro punto dell oggetto. Questo processo, chiamato rifrazione, caratterizza i materiali quali vetro e acqua. Una parte della luce incidente può anche essere riflessa dalla superficie. Figura 5 : superfici speculari, diffusive e traslucide Gli attributi principali di un materiale sono quindi : - Ambient Color (colore ambientale) Il colore dell oggetto quando nessuna luce punta su di esso. - Diffuse Color (colore diffusivo) Il colore dell oggetto quando la luce è equamente distribuita (per es. la luce del sole). - Specular Color (colore speculare) Il colore della luce riflessa dall oggetto quando vi si applica una luce diretta (per es. una luce di tipo spot). - Emissive Color (colore emissivo) Il colore che l oggetto, in un certo senso, emette (può anche essere considerato come il bagliore dell oggetto) Esiste poi un campo chiamato shininess, che rappresenta il coefficiente di brillantezza del cosiddetto modello di illuminazione di Phong (un semplice Inserire riferimento per modello di phong

29 modello diventato uno standard in computer graphics grazie al buon compromesso fra livello di approssimazione matematica dell interazione fisica luce-superfici e il costo computazionale) (22) e che va ad influire sulla luce speculare riflessa. Come spiegato in (21) : tanto più alto è il valore di tale coefficiente, tanto più la luce riflessa si concentra in una regione sempre più stretta centrata sull angolo di riflessione. Al limite, quando questo tende all infinito, il comportamento simulato è esattamente quello di uno specchio. I valori compresi nell intervallo [100,500] corrispondono a superfici metalliche, mentre valori inferiori a 100 corrispondono ai materiali che mostrano un ampia zona di massima lucentezza. L uso del MaterialState permette di raggiungere ottimi livelli di realismo, ma per poterlo sfruttare al meglio, deve essere usato in congiunzione con un LightState. LightState Necessario per poter aggiungere illuminazione ad uno scenegraph. Può contenere 0 o più Lights (luci). Un dato oggetto nello scenegraph può avere solo un LightState associato ma più LightStates possono essere incorporati (cosa che viene fatta di default) per illuminare un oggetto nella scena. Il modo in cui vengono combinate le luci che incidono su un oggetto dipende da come è settato il Light Combine Mode nello Spatial considerato. Vi sono sei differenti modi di gestire la combinazione di luci: - OFF Non illumina l oggetto e ignora tutti i lightstates.

30 - INHERIT Eredita il mode dal genitore (default). - REPLACE Non combina i lightstates, ma usa quello più recente. - COMBINE_FIRST Combina i lightstates incontrati partendo dal nodo radice e muovendosi verso lo Spatial considerato. Ignora gli states disabilitati e si ferma se non vi sono più states da combinare o si è raggiunto il massimo numero di luci consentite. - COMBINE_CLOSEST Combina i lightstates incontrati partendo dallo Spatial considerato e muovendosi verso la radice. Ignora gli states disabilitati e si ferma se non vi sono più states da combinare o si è raggiunto il massimo numero di luci consentite. - COMBINE_RECENT_ENABLED Simile al COMBINE_CLOSEST, con la differenza che si ferma quando incontra uno state disabilitato. Si ferma anche se non vi sono più states da combinare o si è raggiunto il massimo numero di luci consentite. È possibile anche attivare o disattivare a piacimento il Two-Sided Lighting (una funzione che permette di illuminare entrambe le facce di un poligono), che è significativamente più lenta dell illuminazione One-Side ma può essere utile nel caso di superfici visibili da entrambi i lati (una bandiera per esempio). Nel caso si stia utilizzando un CullState in modalità CS_BACK (vedi descrizione sopra) l utilizzo di questa funzionalità risulta inutile in quanto queste superfici non saranno disegnate comunque.

31 E possibile anche specificare un termine ambientale di luce globale (Global Ambient), ovvero un ammontare di luce da applicare a tutti gli oggetti influenzati da un light state, senza il bisogno di creare una luce per essi. I LightStates possono essere meglio controllati attraverso l uso dei LightNode, che permettono di controllare le luci come fossero oggetti dello scenegraph. (Solo gli oggetti che estendono Spatial possono essere attaccati allo scenegraph, e il fatto che LightNode sia un estensione della classe Node, che a sua volta è un estensione di Spatial, lo rende una specie di ponte fra Light e Spatial e fa sì che sia possibile attaccarlo direttamente allo scenegraph) Lights Gli oggetti di tipo Light (luce) sono usati in congiunzione con i LightState per aggiungere illuminazione ad una scena. Illuminare bene una scena risulta fondamentale per raggiungere un grado soddisfacente di realismo. Il reparto illuminazione, date le finalità del progetto, è stato la parte più importante sia in fase di studio che nella successiva parte di effettiva implementazione delle funzionalità richieste. Ci sono tre tipi di luci supportate in jme (che sono le stesse luci definite nella libreria OpenGL) : - PointLight sorgente di luce puntiforme con una posizione definita e che emette luce in tutte le direzioni. Si può pensare a questo tipo di luce come alla luce emessa da una lampadina.

32 - DirectionalLight una luce direzionale è definita come una luce proveniente da distanza infinita, tale che i raggi di luce che illuminano gli oggetti possono essere considerati paralleli fra loro. Definire la direzione di una DirectionalLight significa definire la direzione dalla quale ha origine la luce, il che rende semplice considerarla come la sua posizione. - SpotLight una spot light può essere definita come una luce posizionale in cui la luce emessa è concentrata al centro di un cono. L intensità della luce ricevuta da un punto della superficie è funzione dell angolo ф tra la direzione della sorgente e il vettore diretto al punto, ed è definita dalla funzione: dove l esponente e determina la velocità di decadimento dell intensità. In jme una SpotLight è definita da tre principali variabili: la sua posizione, la direzione verso cui è rivolta e l angolo di ampiezza. Inoltre è possibile definirne direttamente l esponente (con valori che vanno da 0 a 128). Ogni tipo di luce ha poi in comune alcuni attributi: - Ambient Light definisce come gli oggetti della scena appaiono senza che una luce li illumini direttamente effettivamente, ossia il colore e la luminosità dell oggetto quando si trova in ombra.

33 - Diffuse Light la luce che si staglia sull oggetto. È la luce (non diretta) proveniente da una particolare direzione che illumina l oggetto. - Specular Light la luce che si riflette sull oggetto, simile alla shininess (lucentezza). Addizionalmente, è possibile settare un valore per l attenuazione della luce, ovvero la caduta di intensità della luce rispetto alla distanza che l oggetto illuminato ha dalla sorgente. Per fare ciò viene calcolato un fattore di attenuazione secondo la seguente formula: Dove factor è appunto il fattore di attenuazione, constant è il coefficiente di attenuazione costante, linear è il coefficiente di attenuazione lineare e quadratic è il coefficiente di attenuazione quadratica. Per default, non c è attenuazione (factor = 1) e i valori di constant, linear e quadratic sono uguali rispettivamente a 1, 0 e 0. Per ottenere l effetto di attenuazione della luce rispetto alla distanza, è possibile settare valori dei coefficienti di attenuazione lineare e quadratica diversi da 0. Tipicamente più basso è il fattore di attenuazione, più vicina è la caduta di intensità della luce. (21) Per risultati migliori è possibile usare gli oggetti di tipo Light insieme ai MaterialStates, per avere un maggiore controllo su come i singoli oggetti reagiscono all illuminazione. Queste tre componenti possono tutti avere differenti valori sia per colore che per luminosità, mediante l uso di oggetti ColorRGBA.

34 3.1.8 ColorRGBA Definisce il valore di un colore nella libreria jme. Il colore è rappresentato dai valori di tre componenti: rosso, verde, blu. Un quarto componente, alpha, definisce la trasparenza del colore. Ognuno di questi componenti prende valori nell intervallo [0,1]. Qualsiasi valore al di sotto di 0 sarà sostituito automaticamente con 0, e qualsiasi valore al di sopra di 1 sarà sostituito con Controllers Come si può facilmente dedurre dal nome, i controllers controllano oggetti. Sono l equivalente dei Behavior di Java3D. (22) Ad ogni frame, per qualsiasi Spatial del grafo, prima che questi venga aggiornato, viene aggiornato il suo controller. Tipicamente vengono usati per settare rotazioni, traslazioni e scalature che cambiano nel corso del tempo. Un singolo controller può gestire uno o più oggetti e un oggetto può avere uno o più controller. Tutti i concetti, le classi e le utilità definiti in questi paragrafi sono stati usati estensivamente nell arco di tutto il processo di sviluppo. Nei capitoli successivi verranno ancora prese in esame e approfondite nel contesto delle funzionalità che sono state introdotte.

35 3.2 Struttura di AISAC AISAC è stato il passo successivo della fase iniziale di studio. È costituito da tre componenti distinte: Console 3D Imaging Server le quali si integrano a vicenda per realizzare le funzionalità del sistema, ovvero : Automazione e controllo Realtà Virtuale Comunicazione Il seguente schema illustra in maniera semplificata l architettura dell applicativo: da rivedere uno schema più completo ed esemplificativo Console 3D Server Imaging Figura 6 : uno schema semplificato di Aisac

36 3.2.1 Server Il lato server dell applicazione, gestisce tutto ciò che concerne i componenti domotici (luci,punti di automazione) le zone di allarme monitorate, ed effettua il tracking di oggetti attraverso l interazione con le telecamere collegate al sistema. Collabora con la console 3d fornendo le informazioni necessarie per avere una rappresentazione in tempo reale dell ambiente in cui è installato l impianto Imaging Questa sezione di AISAC contiene utility per la codifica e decodifica delle immagini video catturate dalle telecamere presenti nell impianto. Si occupa anche di effettuare lo streaming video in tempo reale. Essendo non strettamente legata ai fini del progetto di tirocinio, non è stato necessario analizzare oltre questa parte del sistema Console 3D Descrivere in maniera breve e semplice la console 3d non è impresa facile, data la moltitudine di aspetti di cui è composta e le tante funzionalità che offre. Lo scopo di questa parte del sistema è quello di dare una rappresentazione virtuale di ambienti reali in cui è installato l impianto. Può interagire con la componente server per ricavare informazioni in tempo reale sullo stato degli ambienti controllati dal sistema, restituendo all utente una visione 3D aggiornata dello stesso, oltre che permettere l interazione diretta (attraverso una comoda interfaccia utente) con i componenti dell impianto, siano essi luci, punti di automazione, sensori o zone di allarme. Per la gestione degli ambienti tridimensionali si appoggia alle funzionalità offerte dal motore grafico open source jme, mentre sfrutta le librerie SWT/JFACE per l interfaccia utente.

37 Ogni ambiente reale che deve essere rappresentato, viene virtualizzato ricavando le informazioni necessarie da un file XML (extensible Markup Language) che ne descrive la struttura. (23) Viene così creata un astrazione dell ambiente che viene ricostruito mediante una struttura a layers (strati). In quest ottica, ogni layer rappresenta un aspetto differente del mondo (per esempio ci sarà un layer per l illuminazione, un layer per il cielo, un layer per gli oggetti 3D presenti nella scena e così via) permettendo di avere una separazione logica dei diversi tipi di contenuto presenti nella scena. L insieme dei layer costituisce un livello, ovvero la rappresentazione finale su schermo dell ambiente reale. Questa soluzione conferisce una forte modularità all applicazione, facilitandone la manutenzione e la modifica nel corso del suo ciclo di vita. La console 3D (e tutto ciò che sta sotto di essa) è la parte dell applicazione studiata maggiormente ai fini del progetto. Tutte le estensioni e modifiche implementate riguardano infatti la gestione dell ambiente virtuale. Ecco alcuni aspetti interessanti: Utilizzo del singleton pattern (24) Struttura dei livelli definita mediante file XML Possibilità di caricare modelli 3d nei formati più diffusi Possibilità di creare zone di allarme virtuali e personalizzabili in tempo reale

38 4. I primi passi con il Java Monkey Engine Prima di pensare a possibili soluzioni da implementare in Aisac, si è voluto dedicare un po di tempo per prendere dimestichezza con il motore grafico e le sue funzionalità. Si è partiti con semplici applicazioni di test basilari per poi procedere a piccoli passi verso test più complessi. La presenza di una community molto attiva e la quantità di tutorials a disposizione che coprono un po tutte le principali caratteristiche del jme ha in parte facilitato questa fase. 4.1 Test di base Si è passati quindi dalla semplice creazione di una sfera: Figura 7 : il primo test effettuato con jme alla manipolazione diretta dei vertici delle primitive per creare semplici animazioni :

39 Figura 8 : jme - una sequenza di immagini che mostra la manipolazione diretta di vertici su primitive

40 L esempio seguente ha permesso di comprendere più a fondo il meccanismo di gestione dei nodi e come questi siano legati fra loro nella struttura ad albero. In particolare si è potuto provare con mano come gli effetti applicati a nodi genitore siano effettivamente propagati ai figli, concetto semplice ma fondamentale. Figura 9 : ecco la struttura dello scenegraph costruito con il nodo radice selezionato Figura 10 : la rotazione un nodo genitore, si propaga effettivamente anche ai nodi figli

41 Figura 11 : selezionando un nodo foglia, l'effetto della sua rotazione e traslazione è limitato allo stesso Si è poi giunti a costruire una piccola applicazione che comprendesse un po tutto. Partendo dalla generazione di terreni: Figura 12 : un terreno generato con il jme per poi passare alla creazione di uno skybox (un cubo a 6 facce, ad ognuna delle quali viene associata una texture. Queste vengono poi combinate per formare la

42 rappresentazione del cielo, dando anche l illusione di un mondo più grande e più realistico): Figura 13 : uno skybox e infine al caricamento di modelli 3d con possibilità di controllo diretto mediante input da tastiera e camera ad inseguimento (chiamata ChaseCamera, usata per ottenere una visuale costantemente alle spalle dell oggetto) Figura 14 : ecco come si presenta l'ultima applicazione di test creata in questa fase di studio

43 Sebbene alcune di queste cose possano sembrare superflue e meno legate agli obiettivi finali, hanno permesso di acquisire dimestichezza coi meccanismi di gestione della scena del jme. Ovviamente, l apprendimento di tali meccanismi, non è stato così immediato come potrebbe sembrare riassunto qui in poche pagine. Si è dovuto trattare infatti con concetti e tecnologie totalmente nuovi. 4.2 Test Luci Successivamente ci si è potuto concentrare maggiormente sugli aspetti più inerenti a ciò che si voleva sviluppare. In particolar modo sul reale funzionamento del sistema di illuminazione. La base per illuminare una scena, oltre che la luce stessa, come spiegato nel paragrafo dedicato alle luci ( [3.1.7 Lights] ), è il LightState che viene associato ai nodi. Ogni nodo del grafo può avere il proprio lightstate cosi come ereditarlo direttamente dal genitore. Associare un lightstate al nodo radice equivale quindi ad associarlo a tutta la scena. Ecco come si presenta una semplice sfera con lightstate non abilitato (influenzata solo dalla luce ambientale globale) : Figura 15 : una sfera senza l'influenza di una luce diretta

44 ed invece con un lightstate abilitato: Figura 16 : una sfera illuminata da una luce di base È sufficiente questo semplice esempio per comprendere l importanza che va attribuita all illuminazione. Nella prima immagine, la sfera appare praticamente piatta, quasi bidimensionale, nonostante sia a tutti gli effetti un oggetto 3d. La sola e semplice aggiunta di una luce di base fa in modo che la forma tridimensionale della primitiva venga resa in modo soddisfacente. Per creare effetti più realistici, come già accennato in precedenza, un LightState può essere combinato con un MaterialState. Questo permette di avere un controllo maggiore su come gli oggetti della scena reagiscano effettivamente alla luce.

45 Ecco i risultati ottenuti con una serie di test effettuati per studiare gli effetti della combinazione dei due RenderState: Figura 17 : primo test MaterialState e LightState Figura 18 : altri test su MaterialState e LightState Nel primo test, alla prima sfera è stato associato un materiale con solo un colore diffuso (blu), niente colore ambientale, niente colore speculare, nessun valore di

46 shininess. La seconda sfera ha invece, oltre al colore diffuso, anche un colore speculare (bianco) con un basso valore di shininess. Infine alla terza sfera è associato lo stesso materiale della seconda ma con un valore alto di shininess. La figura 15 mostra gli effetti ottenuti usando anche un colore ambientale ed uno emissivo sul materiale. Proseguendo nello studio, fra le utilità che poi si sono rivelate più utili vi è il cosiddetto LightControllerManager, una sorta di gestore che permette di tenere traccia delle luci presenti nella scena cosi come facilitare la creazione di lightstate per oggetti di tipo Spatial. Importantissima la possibilità di usare nodi come contenitori di luce e quindi di usare le luci come elementi attivi dello scenegraph. Ne esistono di due tipi ed entrambi permettono di piazzare una luce nel mondo e muoverla influenzando così l intera scena. - SimpleLightNode gestisce solo la luce che gli viene associata, non si occupa direttamente di eventuali lightstate. - LightNode gestisce sia la luce, sia il lightstate che gli viene associato. Inoltre necessita che sia definito un target che verrà influenzato dalla luce (sia esso il nodo radice per far illuminare tutta la scena oppure un nodo particolare per creare effetti di luce specifici su un oggetto). Durante il processo di update dello scenegraph, le luci sono aggiornate per riflettere la posizione e l orientamento correnti dei nodi che le contengono. L immagine seguente mostra, a scopo di test, la creazione di un numero casuale di luci (in questo caso tutte di tipo PointLight) e di primitive che ne vengono influenzate.

47 Le sfere più piccole rappresentano la posizione delle luci mentre quelle più grandi sono semplicemente le primitive caricate nella scena. Figura 19 : un esempio di uso di LightNode

48 5. I primi passi con AISAC Sebbene i primi test con jme non siano stati del tutto indolori, fronteggiare un applicativo come AISAC si è rivelato da subito un impresa decisamente più complicata. Se per il jme ci si è potuti appoggiare su una discreta presenza di documentazione, di articoli e tutorial che illustrassero teorie e pratica, con AISAC ci si è trovati piuttosto spaesati nel dover sviscerare più di 150 packages contenenti in totale più di righe di codice (per la sola Console3d). Prima di pensare ad un qualsiasi tipo di soluzione in base a ciò che appreso nello studio del jme, dunque, è stato speso moltissimo tempo in sessioni di debugging e di studio del codice per cercare di comprendere quali fossero realmente le componenti più importanti e come svolgessero i loro compiti. Di seguito verranno esaminate le classi e gli aspetti che da questo studio sono risultati più rilevanti. Per prima cosa, si è cercato di capire in che modo fosse strutturato il mondo, come questo venisse caricato insieme con i modelli 3d che vanno a comporre la scena. 5.1 Struttura del mondo La composizione dell ambiente virtuale è implementata logicamente a due differenti livelli: Astratto (AbstractLevel) Contiene l implementazione di base, con tutte le componenti necessarie ad avere una rappresentazione standard della scena. Concreto (Level) L implementazione specifica di un livello. Estende AbstractLevel, ed oltre ad implementare funzioni come il salvataggio e l apertura da file di un nuovo livello, permette, potenzialmente, di aggiungere ulteriori funzioni specifiche.

49 La classe LevelWorld3d, invece, ha la funzione di contenitore generale. Una delle sue variabili è infatti proprio l AbstractLevel, che a sua volta contiene tutte le altre componenti. Si è già parlato dei vantaggi di strutturare il mondo in modo che venga costruito mantenendo un approccio modulare nei suoi vari aspetti, ma quali sono concretamente gli elementi che vanno a comporre questi strati? Dall analisi del package, del file xml letto in fase di inizializzazione e delle classi che si occupano di caricare gli elementi della scena, si è potuta avere una prima e sufficientemente chiara idea di quali siano le fette che vanno a comporre il mondo. Sebbene effettivamente siano presenti altre componenti (LevelFog, LevelSound, LevelLensFlare,.), lo schema che segue illustra le principali e più importanti, in quanto, allo stato attuale dello sviluppo, non tutte sono utilizzate: LEVELWORLD3D LevelLut LevelSky AbstractLevel Level LevelLight LevelAlarm LevelAutomation Figura 20 : il mondo 3d di AISAC schematizzato

50 Ecco una breve descrizione di ognuna: LevelLut Permette di gestire la configurazione delle telecamere dell impianto rispetto al contesto della console3d. LevelAutomation Permette la gestione dei componenti di automazione. LevelSky Contiene il cielo, inteso come skybox, del livello. LevelLight L illuminazione del mondo. Da questa base sarà svolto il lavoro di implementazione del ciclo giorno/notte. LevelAlarm Permette di gestire tutto ciò che riguarda le zone di allarme che è possibile definire. Inoltre si è constatato come tutti gli oggetti 3d siano mantenuti in una lista di cosiddetti LayerObj, anch essa contenuta nel LevelWorld3d. Ogni LayerObj rappresenta quindi un modello tridimensionale che va a comporre la rappresentazione visiva della scena. Sia esso il modello di una persona, di un edificio o di un mobilio. Dalle fasi successive di studio, è emerso come LevelLut, LevelAutomation e LevelAlarm siano aspetti dell applicazione che vengono sfruttati solo nel caso in cui sia attiva una connessione al server, in quanto richiedono uno scambio di informazioni sullo stato attuale dell impianto e comunque di relativo interesse per lo sviluppo delle funzionalità richieste.

51 5.2 Caricamento del mondo Come accennato in precedenza, tutte le informazioni necessarie all inizializzazione del mondo sono contenute in un file XML. La difficoltà maggiore nell analisi di questo aspetto è stata la presenza di una serie di chiamate a cascata che hanno reso abbastanza intricato comprendere il percorso di questa sorta di lunga catena che a partire dalla lettura delle informazioni va effettivamente a caricare i vari elementi del livello. Ogni componente infatti necessita un inizializzazione differente e questo comporta il coinvolgimento di svariate classi utili durante questa fase. In linea generale, si può dire che l implementazione di questa funzionalità, vede la presenza dei seguenti passi: - Lettura e riconoscimento delle tag usate nel file XML per distinguere quale componente del livello si voglia caricare e in quale layer. Tutte le tag usate sono presenti in un file che ha la funzione di contenitore per esse e i cui campi sono accessibili staticamente. - Smistamento alle classi opportune per l inizializzazione dei singoli componenti. Dopo aver letto tutti i parametri necessari dal XML, vengono chiamate in causa le utility specifiche che realizzano l effettivo caricamento. - Creazione di ogni layer o componente caricato con le componenti per andare a comporre la struttura del livello. - Inizializzazione di tutti i listeners necessari per la gestione degli eventi a tempo di esecuzione. - Registrazione dei layer che compongono il livello.

52 Ecco come si presenta il mondo di AISAC una volta caricata la scena : Figura 21 : il mondo di AISAC 5.3 Runtime e Singleton pattern Per ciò che riguarda il contenuto dell applicazione, l approccio di gestione utilizzato è quello del singleton pattern, il quale permette di assicurare che una classe abbia un unica istanza attiva in un dato momento e che questa sia globalmente accessibile in un punto ben noto. In sostanza si ha, a tempo di esecuzione, una specie di unico e grande contenitore attivo che permette di richiamare la moltitudine di funzioni disponibili e coordinare i vari aspetti del sistema. La classe Runtime di AISAC è una delle classi designate a rappresentare questo concetto. Da qui è possibile accedere alle varie componenti del mondo 3D e alla loro gestione, siano esse le entità presenti, o quelle selezionate, o i vari layer che compongono i livelli.

53 Accedibile staticamente in qualsiasi momento, contiene anche il nodo radice dello scenegraph. Una caratteristica inizialmente non notata, ma che poi si rivelerà fondamentale, è data da una proprietà che permette di definire in che modalità l applicazione si debba utilizzare. Questo dà luogo ad una serie di differenti stati e sottostati in cui si possono svolgere compiti differenti. I tipi di Runtime disponibili sono: Editor Game La modalità Game non viene in realtà mai utilizzata allo stato attuale delle cose. La modalità Editor è invece il tipo di Runtime di base, che a sua volta permette di definire ulteriori modi di utilizzo. RUNTIME EDITOR ENTITIES EDITING TERRAIN EDITING LUT EDITING AUTOMATION EDITING ALARMZONE EDITING Figura 22 : uno schema dei possibili stati del runtime Entities Editing Permette il controllo diretto delle entità del livello, è la modalità in cui verranno integrati gli algoritmi di picking presenti.

54 Terrain Editing Al momento non usata. Lut Editing Permette di definire le corrispondenze fra punti del mondo reale visualizzati dalle telecamere dell impianto e i punti corrispondenti nel mondo 3d. Automation Editing Usato per la gestione dell impianto di automazione, fornisce l interazione con punti luce (interruttori in pratica) e i vari componenti domotici. Alarmzone Editing Permette di creare e modificare nell ambiente virtuale le zone di allarme controllate dall impianto. Proseguendo nello studio e salendo nella gerarchia dell architettura della console3d, si sono individuate altre classi interessanti: AISAConsole3D La classe principale in esecuzione, si occupa di lanciare l inizializzazione dell interfaccia grafica e di tutti i suoi componenti. Inizializza anche il Runtime, (definendone il nodo radice) e le componenti jme. AsbGUI Mandata in esecuzione dalla classe principale, mantiene le componenti jme del canvas così come tutti i listeners ad essi associati. Tutto quello che riguarda l interfaccia utente, dal menu principale alle barre di stato, è creato in questa classe. Scene3dCanvas È il canvas principale che si occupa del rendering del contenuto 3d all interno dell interfaccia. Tutte le funzionalità dell interfaccia legate al jme sono qui incluse.

55 Scene3dCanvasListener Classe che implementa tutti i generici tipi di listeners per gli eventi generati nel canvas 3d. Fondamentale per la gestione di questi ultimi a tempo di esecuzione. LevelManager Un altro singleton. Si occupa della fase iniziale del caricamento del mondo, creando un istanza del livello e lanciando l attivazione dello stesso. LevelReader Legge tutti i tag del file xml che descrive la struttura del mondo, smistando le chiamate per l inizializzazione dei vari componenti alle classi opportune.

56 6. Verso gli obiettivi finali Tutte le ore spese in fasi di debug del codice e di studio precedentemente descritte, hanno permesso di farsi una prima idea di quali fossero i compiti della console3d e come questi venissero svolti nello stato iniziale dell applicativo. A questo punto si è cominciato a porsi domande maggiormente orientate a ciò che si voleva realizzare. Come per la fase di studio, anche in questo caso il lavoro è stato organizzato in maniera graduale, partendo da idee e soluzioni semplici, e procedendo a piccoli passi (e intoppi) verso l obiettivo finale. Come primo obiettivo, si è pensato di tentare la strada dell integrazione di algoritmi di picking in AISAC. Di seguito verrà descritto tutto il percorso di sviluppo effettuato, comprese le difficoltà incontrate, gli errori commessi, considerazioni sul lavoro e risultati finali a cui si è arrivati. 6.1 Integrazione di algoritmi di picking La prima domanda che ci si è posti è stata : quale aspetto esaminato nella fase di studio può tornare utile adesso?. Il fatto che la risposta non sia stata per niente immediata, unito alla sensazione che evidentemente ci si fosse perso qualcosa di importante, può dare forse l idea di come, nonostante le tante ore spese a studiare e comprendere svariati argomenti fondamentali e in sessioni di debug del codice, si avesse la sensazione di dover quasi ripartire da capo. Questa considerazione personale rende evidente le principali difficoltà dell intero progetto. Non solo infatti era necessario studiare soluzioni di una certa complessità, ma era anche difficile capire come integrarle in AISAC senza stravolgerne l ormai consolidata struttura.

57 Inizialmente, non si era a conoscenza del fatto che gli algoritmi fossero già abbozzati, fino a quando un ulteriore analisi del codice, ha portato alla scoperta di un package con una classe chiamata Gizmo Gizmo Presente in un package sfuggito alla fase di studio iniziale, rappresenta un utilità che dovrebbe permettere di manipolare oggetti della scena sullo stile di strumenti presenti in programmi quali 3DStudioMax 12 e Blender 13. Analizziamo la sua struttura. Anzitutto è possibile definire tre modalità di funzionamento: Traslazione (Motion_Gizmo) Permette di muovere l oggetto selezionato nei tre assi del sistema di riferimento tridimensionale. Rotazione (Rotation_Gizmo) Permette di ruotare localmente (ovvero in base al proprio sistema di riferimento) l oggetto selezionato. Per la gestione di questo tipo di interazione, vengono usate delle matrici di rotazione messe a disposizione dal jme (Matrix3f ) (25) (26) Scalatura (Scale_Gizmo) Permette di scalare le dimensioni dell oggetto selezionato. Nel contesto di AISAC, il Gizmo può essere considerato come una entità particolare, con un proprio nodo al quale viene attaccata, a tempo di esecuzione, un altra entità (quella correntemente selezionata, mediante l uso di un metodo setowner(spatial) che definisce quale sia l entità proprietaria del Gizmo) per poterla manipolare. 12 Sito Web Ufficiale : 13 Sito Web Ufficiale :

58 Vi è una unica istanza di Gizmo che viene inizializzata durante la creazione della scena ed è accessibile dalla classe Runtime. La scoperta del Gizmo e la comprensione della sua struttura,comunque, non è stato altro che la base di partenza per tutto il lavoro svolto successivamente. Ora bisognava infatti addentrarsi maggiormente nel meccanismo degli eventi che permettessero di selezionare un entità della scena, per capire come e soprattutto se, venissero di fatto già gestiti in qualche modo Primi tentativi Il primo passo effettuato è stato quello di caricare nel mondo una semplice primitiva e tentare di capire come fosse possibile selezionarla. Controllando quali eventi venissero gestiti (click del mouse, passaggio del mouse su una entità o oggetto della scena), ci si è accorti come effettivamente questi venissero sì generati, ma l entità su cui andavano a ricadere era sempre la camera. In sostanza la primitiva non veniva riconosciuta. Sfruttando il fatto che la classe che implementa il livello dà accesso ad una lista delle entità presenti, si è quindi testato se la primitiva caricata fosse contenuta in tale lista e il risultato è stato positivo. Dal momento che non si aveva ancora sufficiente dimestichezza con la gestione di eventi, si è tralasciata per un po l idea di selezionare direttamente una entità al click del mouse. Il successivo tentativo è stato quello di scorrere la lista di entità del livello al termine della fase di inizializzazione e caricamento della primitiva, allo scopo di vedere se era possibile associargli direttamente il Gizmo. L esito di questo test è stato più confortante (ovviamente è stato solo un primo passo, ma pur sempre un risultato tangibile), in quanto effettivamente il Gizmo

59 veniva associato all oggetto mediante la seguente chiamata, che sfrutta il fatto che ogni entità creata e caricata nella scena viene sempre registrata nel Runtime: Runtime.getRuntime().getScaleGizmo().setOwner( Runtime.getRuntime().getLastRegisteredEntity()); La prima parte della chiamata di metodo (getruntime()) permette di accedere all unica istanza del Runtime in esecuzione ed ottenere l entità Gizmo che si occupa della scalatura (getscalegizmo()) per poi definire quale entità sia da associare ad esso (setowner()). In questo modo si è potuto subito testare gli effetti dell uso del Gizmo. Il secondo passo è stato quello di tentare di cambiare il tipo di Gizmo sulla selezione corrente. Per fare ciò, si è dovuto necessariamente mettere mano alla gestione degli eventi nella classe Scene3dCanvasListener; nello specifico si è provato a gestire il cambio mediante il doppio click del mouse. Si è pensato di cambiare il tipo di Gizmo in maniera ciclica (ad ogni click del mouse si passava ad un tipo differente, quindi dalla scalatura alla traslazione, per poi passare alla rotazione e cosi via). Anche in questo caso l esito del test è stato positivo e tutti e tre i tipi di Gizmo hanno funzionato correttamente. Proseguendo su questa linea, la prova successiva è stata quella di caricare due primitive e tentare di cambiare la selezione, ovvero associare il Gizmo, mediante il doppio click del mouse, alternativamente all una e all altra entità. Anche in questo caso si è cercato di mantenere un approccio che fosse il più semplice possibile, modificando l evento doppio click in modo che con il tasto destro si cambiasse l associazione, e con il sinistro il tipo di Gizmo. Il risultato è stato positivo anche con questo test, ma poi le cose si sono un po complicate.

60 È evidente come il cambio di selezione non potesse certamente essere gestito ciclando fra le entità del livello, in quanto non si aveva un reale controllo su ciò che veniva scelto per la selezione e inoltre non veniva minimamente sfruttato il vero concetto di picking. L obiettivo a questo punto era quello, idealmente, di riuscire, passando il mouse sopra ad una entità a far sì che questa venisse riconosciuta e a quel punto selezionata con un semplice click. Si è pensato quindi che fosse indispensabile avere una visione più completa degli eventi generati e della loro possibile gestione Eventi e loro gestione SWT fornisce una serie di interfacce atte ad essere implementate per la gestione di tutti gli eventi generabili a tempo di esecuzione. Le più rilevanti sono : KeyListener Per la gestione di eventi generati dalla pressione dei tasti della tastiera. Tali eventi possono essere : - keypressed quando un tasto viene premuto. - keyreleased quando un tasto viene rilasciato. MouseListener Per la gestione di eventi generati alla pressione dei tasti del mouse. Questi possono essere : - mousedoubleclick quando un bottone del mouse è premuto due volte in un intervallo di tempo specificato dal sistema operativo.

61 - mouseup quando un tasto del mouse viene premuto. - mousedown quando un tasto del mouse viene rilasciato. MouseMoveListener Per la gestione di eventi generati quando il puntatore del mouse viene mosso. Un unico evento è presente in questo caso : - mousemove MouseTrackListener Le implementazioni di questa interfaccia forniscono metodi per la gestione di eventi generati quando il puntatore del mouse passa su un oggetto. Gli eventi possibili sono : - mouseenter quando il puntatore del mouse entra nell area dello schermo coperta da un oggetto. - mouseexit quando il puntatore del mouse esce dall area dello schermo coperta da un oggetto. - mousehover quando il puntatore del mouse si sofferma nell area dello schermo coperta da un oggetto per un certo periodo di tempo. Ognuno di questi metodi prende in ingresso come parametro un oggetto di tipo Event, che rappresenta appunto il tipo di evento generato. Una volta avuta un idea generale, si è cercato di capire come e dove, nel contesto di AISAC, avvenisse la gestione di tali eventi. Ne è emerso che ogni entità viene creata con un proprio gestore di eventi, estendendo le classi base del package SWT.

62 Non tutti questi eventi vedono le loro funzionalità implementate, motivo per cui, sicuramente, non si riusciva nei test precedenti a fare in modo che il passaggio del mouse o il click venissero generati effettivamente sull entità voluta. Oltre alla già citata classe Scene3dCanvasListener, poi, esiste un altra classe chiamata SWTEventDispatcher, di importanza fondamentale, in quanto rappresenta il ponte fra gli eventi generici SWT e gli eventi specifici delle entità. In sostanza, come intuibile dal nome, è effettivamente mediante le funzionalità qui presenti che si possono smistare tutti gli eventi generati ai gestori specifici di questi ultimi. Riassumendo, idealmente, la gestione degli eventi dovrebbe avvenire seguendo una sorta di catena: generazione dell evento smistamento dell evento da parte del Scene3dCanvasListener mediante l uso del dispatcher SWT gestione specifica dell evento da parte dell entità su cui è stato generato Ultimi test Successivamente si è proceduto ad effettuare ulteriori test con risultati purtroppo non sufficientemente soddisfacenti. Nonostante i tentativi di implementare la gestione degli eventi specifici per le entità, inizialmente non si è riusciti a venire a capo del perché tali entità non venissero riconosciute. Una prima idea che ci si è fatta, è che l algoritmo usato per il controllo delle entità sulle quali si genera l evento, non fosse del tutto funzionante. (Il concetto è lo stesso espresso nel paragrafo dedicato al picking nel capitolo 3).

63 Giunti quindi ad una fase di stasi, ci si è chiesti se effettivamente fosse questo il funzionamento ideale di tale funzione nel contesto di AISAC, o se ci fosse qualche altra soluzione Soluzione finale Un fatto da evidenziare è che in tutte le prove effettuate, ci si è concentrati troppo sull obiettivo specifico che si voleva raggiungere, perdendo la visione d insieme dell applicazione. In questo modo si è commesso l errore di non dare molto peso ad una delle prime caratteristiche notate nel Runtime, ovvero le varie modalità di utilizzo possibili. La chiave per la soluzione scelta sta proprio in questo aspetto, i tipi di Runtime e il Gizmo infatti sono strettamente legati fra loro. Da aggiungere anche che tutti i test sono stati effettuati con la console in modalità offline. Quando si è provato a connettersi al server si è potuto constatare come in effetti potesse essere gestita la possibilità di manipolare oggetti della scena. Analizzando la parte di codice relativa all interfaccia grafica che permette di gestire le componenti domotiche, si è compreso come la strada da seguire dovesse essere quella del cambiamento di tipo del Runtime. Inoltre, ne è emerso che il funzionamento ideale di questo aspetto nel contesto di quello che è AISAC, non doveva necessariamente prevedere la possibilità di manipolare ogni oggetto della scena, ma solo quelle entità che rappresentassero nella console3d i componenti domotici presenti nell impianto. Tali componenti vengono presentati nell interfaccia mediante una lista di oggetti. La soluzione, prevede che selezionando un oggetto da tale lista, e usando il menu contestuale per modificarlo, questo venga effettivamente caricato nel mondo virtuale e automaticamente selezionato e associato al Gizmo. Dopodiché deve essere possibile manipolarlo mediante rotazioni, traslazioni, scalature e posizionarlo nel punto voluto.

64 Sempre da interfaccia deve essere possibile cambiare il tipo di Gizmo e salvare o annullare le modifiche effettuate. Questa soluzione è risultata pertanto quella scelta come obiettivo finale in quanto va incontro alle esigenze specifiche dell applicazione e inoltre comporta la necessità di effettuare solo modifiche di minore importanza, sfruttando in gran parte le utilità già presenti. In linea generale, l implementazione risulta seguire alcuni semplici passi: Quando si seleziona la modifica di un oggetto della lista, il tipo di Runtime viene cambiato in ENTITIES_EDITING (vedi descrizione capitolo 5 paragrafo 3) e di default il tipo di Gizmo viene settato per la traslazione. Inoltre viene notificata automaticamente durante il caricamento dell oggetto la selezione dello stesso mediante una chiamata al metodo setselectedentity(entita) Di seguito alcune immagini che mostrano il gizmo durante il suo utilizzo: Figura 23 : gizmo per la traslazione

65 Figura 24 : gizmo per la rotazione Figura 25 : gizmo per la scalatura (1)

66 Figura 26 : gizmo per la scalatura (2) Figura 27 : gizmo per la scalatura (3)

67 6.2 Ciclo Giorno Notte Raggiunto l obiettivo di integrare gli algoritmi di picking, si è cominciato a pensare ad una soluzione su come implementare una simulazione plausibile del ciclo giorno notte. La base presente vedeva implementata l illuminazione del mondo con la presenza di una luce direzionale fissa. Partendo da queste fondamenta, la prima idea è stata quella di chiedersi come fare per far sì che la luce ruotasse. Per prima cosa quindi, è stata creata un applicazione a parte per capire come si potesse automaticamente ruotare un generico oggetto nel corso del tempo. jme mette a disposizione diverse soluzioni per le rotazioni. Si può infatti fare uso delle classiche matrici di rotazione (classe Matrix3f) così come di quaternioni (classe Quaternion). La scelta è ricaduta sin da subito sui quaternioni. Vediamo perché Quaternion Come descritto in (27), i quaternioni definiscono un sottoinsieme di un complesso sistema numerico e permettono una rappresentazione compatta di rotazioni, o in maniera corrispondente, di orientamenti, in uno spazio tridimensionale. Con soli quattro valori di tipo float è possibile rappresentare l orientamento di un oggetto, dove con una matrice di rotazione ne occorrerebbero nove. Inoltre richiedono minori operazioni aritmetiche per la concatenazione e permettono una facile interpolazione fra due rotazioni. Inoltre la rotazione locale di uno Spatial è mantenuta proprio in un Quaternion. Se in dettaglio i quaternioni sono di difficile comprensione, jme ci viene incontro fornendo una serie di convenienti metodi che permettono di usarli senza dover necessariamente conoscere tutti i calcoli matematici alla base di essi.

68 Le rotazioni si possono rappresentare in diversi modi 14 : - usando tre angoli dove ogni angolo rappresenta la rotazione su di un singolo asse. Passando come parametro un array di tre float per esempio, il primo elemento sarà l angolo di rotazione sull asse X, il secondo sull asse Y e il terzo sull asse Z. - usando i tre assi per rappresentare la rotazione dove i valori usati definiscono rispettivamente quale sia l asse sinistro, quello rivolto verso l alto e quello direzionale. In questo caso è possibile usare un metodo ( fromaxes ) per generare un Quaternion. - usando una matrice che definisce una rotazione. È infatti possibile mantenere una rotazione in una matrice, creare un Quaternion in base a tale matrice, ruotare il Quaternion e riottenere la matrice. Il metodo fromrotationmatrix si preoccupa di creare il Quaternion appropriato basato sulla matrice data. - usando una coppia angolo/asse definendo così l asse di rotazione e l angolo con cui ruotare su tale asse. Il metodo fromangleaxis si occupa di creare un Quaternion partendo da questa coppia di valori (questa soluzione sarà quella usata nei successivi test). Per tutti questi motivi e grazie all immediatezza con cui era possibile sfruttarli, l uso dei quaternioni è sembrata la scelta più conveniente per i test sulle rotazioni Ruotare un oggetto Il primo passo è stato semplice. Senza ancora andare a manipolare direttamente le luci, ma creando una scena con solo una sfera e ridefinendo la fase di aggiornamento, è andato tutto come ci si aspettava. 14 Gli angoli sono espressi in radianti.

69 Di seguito la parte di codice usata durante la fase di aggiornamento della scena in questo primo test per ruotare la sfera: angle++; if (angle > 360) { angle = 0; } } rotquat.fromangleaxis(angle, axis); sphere.setlocalrotation(rotquat); dove angle rappresenta l angolo di rotazione, rotquat un istanza di Quaternion, axis l asse su cui ruotare, e il metodo setlocalrotation che permette di definire la rotazione di un oggetto usando come parametro proprio il Quaternion. Procedendo verso un idea più vicina a ciò che si sarebbe poi voluto realizzare con la luce direzionale, si sono effettuati alcuni test per tentare di ruotare un oggetto intorno ad un punto fisso. Partendo sempre da un idea semplice, si è creato uno scenegraph con la seguente struttura: - un nodo radice - un nodo che chiameremo pivot (il punto fisso intorno al quale ruotare) attaccato al nodo radice - una sfera attaccata al nodo pivot Ancora una volta è stato importante capire come si relazionassero i nodi dello scenegraph. Inizialmente (ed erroneamente) si applicava, come nell esempio precedente, la rotazione alla sfera, con il risultato che questa ruotava semplicemente su se stessa. Per poter far sì che ruotasse intorno al nodo pivot, anzitutto si è dovuto spostare la sfera in modo che avesse una certa distanza dal nodo genitore.

70 Dopodiché, l effetto dell applicazione della rotazione al nodo pivot è stato proprio quello di far ruotare la sfera nel modo voluto: Figura 28 : test di rotazione intorno ad un punto Ora però era necessario cominciare a lavorare realmente sulle luci. La luce direzionale, per sua natura considerata come infinitamente distante, è rimasta la scelta definitiva per rappresentare la luce solare. Sin dall inizio l obiettivo è stato quello di cercare di sfruttare i tipi di nodi LightNode e SimpleLightNode in modo da poter trattare la luce come elemento attivo dello scenegraph. Muovendo (traslando o ruotando) il nodo che contiene la luce, le si cambia automaticamente direzione (nel caso di luce direzionale). Ci si è poi posti la questione se fosse meglio traslare o ruotare la luce, o meglio il nodo contenitore. La scelta è ricaduta sulla rotazione ed è dipesa soprattutto da motivi di complessità: il calcolo della posizione in cui muovere il nodo nel corso del tempo risulta essere decisamente più complicato della gestione di una rotazione completa dello stesso in un arco di tempo definito (considerati anche gli strumenti a disposizione) e i risultati finali non si discosterebbero più di tanto fra loro. Si è quindi provato ad aggiungere una luce direzionale alla scena, usando una sfera per avere una rappresentazione visiva di dove fosse, un nodo contenitore di tipo

71 SimpleLightNode e il solito nodo pivot che rappresentasse il mondo intorno a cui far girare la luce. La struttura dello scenegraph diventa quindi la seguente: Root Node SferaMondo Pivot Node SimpleLightNode Luce Direzionale SferaLuce Figura 29 : scenegraph primi test rotazione luce

72 Quindi ruotando il nodo pivot, si ottiene il risultato di far ruotare sia il SimpleLightNode (e quindi la luce ad esso associata), sia la sfera attaccata ad esso. Fino a qui è risultato tutto abbastanza chiaro e intuitivo. Nel passo successivo si è cominciato a cercare una soluzione per ruotare la luce nel contesto di un ciclo di 24 ore. Tornando quindi a metter mano su AISAC, la prima idea è stata quella di tentare di affidare il compito ad un thread specifico che si occupasse ad intervalli di tempo regolari di ruotare la luce di un certo angolo e su di un determinato asse. Questa soluzione, oltre che concettualmente sbagliata, si è rivelata poi anche totalmente inefficiente e inconcludente. Il thread veniva fatto partire in fase di inizializzazione del mondo e (a scopo di testi) veniva fatto in modo che ogni 5 secondi facesse ruotare la luce. I motivi per cui questa soluzione è stata velocemente accantonata, sono diversi. Primo fra tutti, la sua difficile gestione. Sin dai primi tentativi è emerso come non sarebbe stato possibile avere il controllo desiderato su questa funzionalità, inoltre si voleva cercare di sfruttare maggiormente alcune funzionalità offerte dal jme. È tornata in mente infatti, una delle utilità studiate nella fase iniziale, ovvero i Controllers. Avendo a disposizione un vero e proprio nodo che si occupasse di gestire la luce e aggiornarla, si è pensato di poter fare uso di uno specifico tipo di controller da associare a tale nodo, lo SpatialTransformer SpatialTransformer Come già accennato nel capitolo introducendo il concetto alla base dei Controllers, questi permettono di gestire animazioni nel corso del tempo. SpatialTransformer è una classe che estende Controller. Per animare gli oggetti ad esso associati (l uso tipico è comunque di un oggetto per SpatialTransformer), devono essere definite le trasformazioni volute (che rotazione, traslazione, scalatura deve avere l oggetto) e il momento in cui queste debbano verificarsi.

73 Mediante una chiamata al metodo interpolatemissing() prima di mandare in esecuzione il controller, questi si occupa di interpolare le rotazioni/traslazioni/scalature mancanti nell intervallo temporale definito per la durata dell animazione. È possibile poi settare la durata dell animazione a piacimento (in secondi) e decidere in quale punto cui far iniziare o proseguire l animazione, che può essere attivata e disattivata a piacimento in qualsiasi momento. Tutte queste peculiarità sembravano essere decisamente adatte allo scopo, pertanto si è proseguito su questa strada con l intento di personalizzare poi il processo di aggiornamento per ottenere i risultati voluti. Bisognava però pensare a come suddividere il tempo perché si potesse simulare una giornata di 24 ore Suddivisione del tempo Nell arco di un giorno, la luce deve ruotare di 360, per cui come prima idea,si è semplicemente suddiviso l intervallo di tempo in sezioni di 6 ore ciascuna. Ogni 6 ore la rotazione del nodo doveva aumentare di 90 rispetto a quella iniziale: Intervallo Ciclo Giorno Notte ore 0-6. ore 6-12 ore ore Figura 30 : suddivisione iniziale del tempo nel ciclo giorno notte

74 Mantenendo la stessa struttura del test precedente per la rotazione intorno ad un punto, il primo tentativo è stato quello di aggiungere un oggetto SpatialTransformer a cui affidare il nodo pivot da ruotare (posto al centro del mondo come punto di riferimento). Si sono create le 4 rotazioni (90,180,270,360 ), poi poste a intervalli regolari per la durata del ciclo (che nei primi test ovviamente è stata settata su valori bassi) come le rotazioni che l oggetto dovesse assumere. Il risultato è stato positivo e la luce ruotava costantemente di 360 intorno all origine. La suddivisione temporale ha necessitato però di una revisione in quanto l idea di base era un po troppo semplicistica e si è notato come la luce andasse a trovarsi sotto il mondo troppo presto, con la conseguenza che già ad un ora corrispondente al tardo pomeriggio (17-18) questi divenisse troppo buio. Effetto causato dal fatto che si era suddivisa la giornata in 4 parti uguali, mentre sarebbe stato più vicino alla realtà far corrispondere alla fascia oraria notturna una durata minore. Dai vari test effettuati si è raggiunto un buon compromesso modificando le fasce orarie in questo modo: 270 Intervallo Ciclo Giorno Notte ore 0-6. ore 6-12 ore ore Figura 31 : suddivisione finale intervalli di tempo del ciclo giorno notte

75 Oltre alla rotazione della luce solare, per avere una simulazione più plausibile, si è voluto tentare di cambiarne anche il colore sempre basandosi sull ora Colore della luce Per implementare questa funzionalità aggiuntiva, si è partiti dall idea di definire quali fossero i colori da assegnare alla luce nei vari momenti della giornata, in modo che rappresentassero il più fedelmente possibile ciò che accade nella realtà. Mantenendo la suddivisione pensata inizialmente per l intervallo di tempo delle 24 ore, si sono definite 4 fasce orarie ognuna delle quali ha una durata di 6 ore e un colore di partenza così come un colore di arrivo. I 4 colori definiti sono : - colore della luce all alba è stato scelto un arancione chiaro - colore della luce al tramonto per semplicità si è mantenuto lo stesso colore dell alba - colore della luce di notte è stato scelto il nero - colore della luce in pieno giorno (ore 12) il momento di massima luminosità, quindi è stato scelto il bianco e si è cercato un modo di interpolarli fra loro per avere un cambio di colore graduale nel trascorrere della giornata. Per ideare una soluzione, si è ragionato in questo modo: ogni fascia oraria ha 6 ore, questo significa che in tale intervallo di tempo, dovrà avvenire un incremento o decremento dei valori del colore di partenza per raggiungere i valori del colore finale. Per esempio ci sarà un incremento nelle fasce orarie che vanno dalle 6 alle 12 e dalle 0 alle 6 (si passa infatti da un colore più scuro ad uno più chiaro). Fra le 12 e le 18 e

76 le 18 e le 24 avremo invece un decremento (si passa da un colore più chiaro ad uno più scuro). Per ognuna delle fasce orarie, il colore considerato di base, cioè quello su cui vengono effettuati i calcoli, è quello dell alba tramonto. Nel caso dell incremento il calcolo effettuato è il seguente: vcp + (( vca vcp) / 6) curtime - startime dove vcp sta per valore colore di partenza, vca è il valore del colore di arrivo, curtime è l ora corrente e startime è l ora di inizio della fascia oraria in cui ci si trova. Andiamo per gradi. Facendo la differenza fra il valore del colore di partenza e il valore del colore di arrivo avremo come risultato l incremento totale che si dovrà ottenere nell arco delle 6 ore. Dividendo questa differenza per 6 avremo i singoli incrementi da assegnare ogni ora, ma il colore deve cambiare continuamente, e non solo ogni ora, per cui il valore dei singoli incrementi viene moltiplicato per quella che è la differenza fra l ora corrente e l ora di inizio della fascia oraria in cui ci si trova. Questo prodotto fornisce un valore corretto da sommare al valore iniziale del colore, in quanto permette di stabilire precisamente in quale punto dell intervallo ci si trovi. Questa operazione viene effettuata per ogni canale del colore, ovvero la componente rossa, quella blu, quella verde e il valore alpha.

77 6.2.6 Gestione dell ora Sia per avere il massimo controllo sull animazione stessa che per aggiornare correttamente il colore della luce, si è reso necessario trovare il modo di mettere in relazione l ora reale con il punto corrispondente dell animazione. La durata di quest ultima viene definita in secondi, per cui simulare un intera giornata (24 ore), significherà far durare l animazione secondi. Considerato però che l animazione viene calcolata in intervalli di mentre l ora di 0-60 si sono definiti dei metodi che calcolassero la proporzione fra i due e che permettessero di passare dall uno all altro semplicemente usando come parametri l ora corrente reale in un caso e il tempo corrente dell animazione nell altro. 15 Inoltre si aveva la necessità di rendere la gestione del ciclo indipendente dalla durata dell animazione. La soluzione ideata vede due fasi distinte: la prima relativa al tempo trascorso nel contesto dell animazione; la seconda atta a trasformare il tempo trascorso in tempo reale (in pratica calcola l ora corretta). Per realizzare correttamente questa funzionalità, sono state definite alcune variabili: - cyclelength la durata in secondi del ciclo giorno notte, definibile a piacimento. - realtime il tempo reale trascorso nell animazione. - starttime l ora di partenza del ciclo. - timeelps fornisce il tempo trascorso dall inizio dell animazione in base al valore di cyclelength. 15 Il codice completo di questi metodi è presente nelle appendici.

78 - hourofday l ora reale corrente. - curtime il tempo corrente nell animazione. Nella fase di aggiornamento implementata nel controller, si effettuano le seguenti operazioni: si calcola prima di tutto quanto tempo è passato dall inizio dell animazione in relazione ad un ciclo di 24 ore : timeelps = (curtime / cyclelength) * 24; poi si controlla se il tempo trascorso sia maggiore o minore di 24 ore. Se è maggiore, il tempo reale (sempre relativo all animazione) corrisponderà al tempo trascorso modulo 24: if(timeelps > 24) realtime = timeelps % 24; altrimenti il tempo reale sarà semplicemente uguale al tempo trascorso: else realtime = timeelps; Successivamente la variabile realtime viene processata da un metodo apposito per ottenere l ora corretta formattata secondo il formato HH.mm e assegnato il valore restituito alla variabile hourofday che sarà poi il valore usato per poter aggiornare il colore della luce : hourofday = getworldtime(realtime); updateworldlightcolor(hourofday); A questo punto è stato necessario mettere insieme tutti i pezzi per andare ad implementare definitivamente la simulazione del ciclo giorno notte.

79 6.2.7 LevelLight e LevelLightController Tutto quello che concerne l illuminazione del mondo è stato implementato in queste due classi, somma del lavoro svolto durante la fase di progettazione e studio descritta nei paragrafi precedenti. La LevelLight si occupa della creazione e dell inizializzazione della luce direzionale che rappresenta il sole. La LevelLightController rappresenta invece l utilità che si occupa della sua animazione. All atto della creazione del layer di illuminazione durante la costruzione del mondo, viene passata come parametro l ora corrente (locale) in modo da far partire l animazione dal punto corretto. Nel caso in cui si lavori offline la situazione rimane tale, altrimenti se ci si collega al server, questi in fase di login setta un valore che corrisponde all orario remoto (o locale al server) allineando correttamente il ciclo. In fase di inizializzazione viene anche creata una luce di tipo SpotLight (in una posizione di default che permetta di illuminare almeno la zona centrale del mondo) che viene accesa quando si entra nella fascia oraria notturna (21 24) e spenta durante la fascia oraria del giorno (più precisamente quando l ora corrisponde alle 7 del mattino). Questo accorgimento è stato apportato per evitare di avere un mondo troppo buio durante la notte, quando la luce sostanzialmente si trova sotto di esso. Durante la fase di aggiornamento, inoltre, viene mandato un segnale anche al layer che contiene lo skybox, che aggiorna la tinta delle texture che lo compongono a seconda dell ora corrente, sulla stessa base usata per calcolare il colore della luce. E stata creata anche una comoda interfaccia per avere il controllo sulla durata del ciclo e per poter settare a piacimento l ora corrente. Utile sia in fase di dimostrazione che soprattutto durante tutto lo sviluppo di questa funzionalità per effettuare veloci test.

80 Di seguito alcune immagini dei risultati ottenuti con l implementazione finale del ciclo giorno notte: Figura 32 : i controlli inseriti per la gestione del ciclo Figura 33 : il mondo dall'alto, ore 5

81 Figura 34 : ore 8 Figura 35 : ore 12

82 Figura 36 : ore 12 da un altro punto di vista Figura 37 : ore 15

83 Figura 38 : ore 18 Figura 39 : ore 21 con luce notturna

84 Figura 40 : ore 00 con luce notturna Figura 41 : l'effetto della luce del sole su una superficie speculare

85 Figura 42 : comparazione fra illuminazione globale di base e illuminazione del ciclo giorno notte

86 6.3 Editor Luci Nel corso dello sviluppo, inizialmente con l intento di aiutare a sveltire la moltitudine di test effettuati sulle luci, si è creato anche un basilare strumento per caricarle, a tempo di esecuzione, in AISAC. Caricando una luce, questa può venire associata ad una primitiva cosi come ad un modello 3d per poi essere manipolata direttamente mediante gli algoritmi per la selezione, picking, traslazione, rotazione e scalatura. Allo stato attuale, l editor di luci non è del tutto completo, ma permette di caricare solo luci di tipo SpotLight e di modificarne i valori di angolo ed esponente. Il colore associato alla luce viene creato automaticamente e non è ancora possibile cambiarlo da interfaccia. In futuro sarà possibile estenderne le funzionalità per caricare gli altri tipi di luce disponibili e creare così un illuminazione ambientale più completa e personalizzata. Di seguito alcune immagine che mostrano il lavoro svolto: Figura 43 : come si presenta l'editor di luci

87 Figura 44 : menu con le opzioni per le singole luci Figura 45 : informazioni sulla luce

Interazione luce - materia

Interazione luce - materia Interazione luce - materia 1 Modelli di illuminazione Il modello di illuminazione descrive l interazione tra la luce e gli oggetti della scena Descrive i fattori che determinano il colore di un punto della

Dettagli

Di Blasi Gianpiero - D.M.I. - Università di Catania. Lezione 6. Luci

Di Blasi Gianpiero - D.M.I. - Università di Catania. Lezione 6. Luci Di Blasi Gianpiero - D.M.I. - Università di Catania Java3D Lezione 6 Luci Cosa impareremo oggi? Il modello di illuminazione di Java3D Come creare luci Come fare interagire gli oggetti visuali con le luci

Dettagli

Introduzione alla Computer Graphics

Introduzione alla Computer Graphics Introduzione alla Computer Graphics Informatica Grafica CdLS a ciclo unico in Ingegneria Edile-Architettura a.a. 2008/09 Computer Graphics e Image Processing Image processing Insieme di teorie ed algoritmi

Dettagli

Realizzare la VR: i software. Piattaforme per la VR: VRML. Il più diffuso: VRML (Virtual Reality Modeling Language)

Realizzare la VR: i software. Piattaforme per la VR: VRML. Il più diffuso: VRML (Virtual Reality Modeling Language) Lezione 5.1 Realizzare la VR: i software Piattaforme per la VR: VRML Il più diffuso: VRML (Virtual Reality Modeling Language) Rappresentazioni 3D interattive anche per web Rendering di poligoni tridimensionali

Dettagli

Realtà Virtuali Prof. Raffaella Folgieri, aa 2013/2014. Realizzare la VR: i software

Realtà Virtuali Prof. Raffaella Folgieri, aa 2013/2014. Realizzare la VR: i software Realtà Virtuali Prof. Raffaella Folgieri, aa 2013/2014 Realizzare la VR: i software Piattaforme per la VR: VRML Il più diffuso: VRML (Virtual Reality Modeling Language) Rappresentazioni 3D interattive

Dettagli

OpenSceneGraph & OSG4Web

OpenSceneGraph & OSG4Web OpenSceneGraph & OSG4Web Parte 1 OpenSceneGraph Introduzione alla creazione di una Applicazione 3D e OpenGL Basi di OpenSceneGraph Demo e prove pratiche Parte 2 Navigazione e Virtual Worlds su larga scala

Dettagli

Lezione1. Cos è la computer grafica. Lezione del 10 Marzo 2010. Michele Antolini Dipartimento di Ingegneria Meccanica Politecnico di Milano

Lezione1. Cos è la computer grafica. Lezione del 10 Marzo 2010. Michele Antolini Dipartimento di Ingegneria Meccanica Politecnico di Milano Lezione1 Informatica Grafica Cos è la computer grafica Lezione del 10 Marzo 2010 Grafica OpenGL vs Direct Dipartimento di Ingegneria Meccanica Politecnico di Milano 1.1 Tubo a Raggi Catodici Cathode Ray

Dettagli

Software. Definizione, tipologie, progettazione

Software. Definizione, tipologie, progettazione Software Definizione, tipologie, progettazione Definizione di software Dopo l hardware analizziamo l altra componente fondamentale di un sistema di elaborazione. La macchina come insieme di componenti

Dettagli

Architetture Applicative

Architetture Applicative Alessandro Martinelli alessandro.martinelli@unipv.it 6 Marzo 2012 Architetture Architetture Applicative Introduzione Alcuni esempi di Architetture Applicative Architetture con più Applicazioni Architetture

Dettagli

Informatica Grafica. Prof. Massimiliano Dellisanti Fabiano Vilardi. (2a parte) a.a. 2011/2012

Informatica Grafica. Prof. Massimiliano Dellisanti Fabiano Vilardi. (2a parte) a.a. 2011/2012 Informatica Grafica (2a parte) a.a. 2011/2012 Prof. Massimiliano Dellisanti Fabiano Vilardi 1 Grafica 3D Con Grafica 3D si indicano quelle tecniche informatiche finalizzate alla descrizione (e rappresentazione

Dettagli

Lezione 19: Grafica in tempo reale. I problemi del Real Time. I problemi del Real Time. I problemi del Real Time. I problemi del Real Time

Lezione 19: Grafica in tempo reale. I problemi del Real Time. I problemi del Real Time. I problemi del Real Time. I problemi del Real Time I problemi del Real Time Lezione 19: Grafica in tempo reale Come visto nelle precedenti lezioni, i calcoli necessari a generare immagini 3D sono numerosi e complessi. I programmi di grafica 3D impiegano

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Computer Graphics. La disciplina fornisce metodi per creare elaborare memorizzare visualizzare. immagini di oggetti o scene mediante un computer

Computer Graphics. La disciplina fornisce metodi per creare elaborare memorizzare visualizzare. immagini di oggetti o scene mediante un computer Computer Graphics La disciplina fornisce metodi per creare elaborare memorizzare visualizzare immagini di oggetti o scene mediante un computer Image Processing La disciplina fornisce metodi per acquisire

Dettagli

Corso di Alfabetizzazione Informatica

Corso di Alfabetizzazione Informatica Corso di Alfabetizzazione Informatica Lezione 6 a.a. 2010/2011 Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono: diversi

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Il Sistema Operativo Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela Fogli Cos

Dettagli

Dalla Sfera a Luigi del film Cars L Algoritmo di Ray Tracing

Dalla Sfera a Luigi del film Cars L Algoritmo di Ray Tracing Dalla Sfera a Luigi del film Cars L Algoritmo di Ray Tracing Ing. Federico Bergenti E-mail federico.bergenti@unipr.it Telefono +39 0521 90 6929 Sintesi di Immagini Digitali Generazione automatica di immagini

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono:

Dettagli

Modulo 3. Rappresentazione di solidi mediante forntiera e strutture dati collegate.

Modulo 3. Rappresentazione di solidi mediante forntiera e strutture dati collegate. Modulo 3. Rappresentazione di solidi mediante forntiera e strutture dati collegate. Nel precedente modulo abbiamo presentato le modalità di rappresentazione di un solido mediante enumerazione o mediante

Dettagli

Calcolo numerico e programmazione. Sistemi operativi

Calcolo numerico e programmazione. Sistemi operativi Calcolo numerico e programmazione Sistemi operativi Tullio Facchinetti 25 maggio 2012 13:47 http://robot.unipv.it/toolleeo Sistemi operativi insieme di programmi che rendono

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

Classificazione del software

Classificazione del software Classificazione del software Classificazione dei software Sulla base del loro utilizzo, i programmi si distinguono in: SOFTWARE Sistema operativo Software applicativo Sistema operativo: una definizione

Dettagli

Fondamenti di Informatica

Fondamenti di Informatica Fondamenti di Informatica Il software Dipartimento di Ingegneria dell Informazione Universitàdegli Studi di Parma SOFTWARE I componenti fisici del calcolatore (unità centrale e periferiche) costituiscono

Dettagli

Il sistema operativo

Il sistema operativo Il sistema operativo Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Cos è un Sistema Operativo? Per capirlo, immaginiamo inizialmente

Dettagli

WebGL. Lezione 18: 15 Maggio 2014

WebGL. Lezione 18: 15 Maggio 2014 WebGL Lezione 18: 15 Maggio 2014 Cronologia: Grafica 3D nell Hardware In principio (giurassico informatico) postazioni specializzate La Silicon Graphics si afferma come produttrice di workstation grafiche

Dettagli

Introduzione a API e game engine per la programmazione grafica

Introduzione a API e game engine per la programmazione grafica Introduzione a API e game engine per la programmazione grafica OpenGL e WebGL Davide Gadia Corso di Programmazione Grafica per il Tempo Reale Laurea Magistrale in Informatica per la Comunicazione a.a.

Dettagli

Lezione 16: Animazione (2)

Lezione 16: Animazione (2) Lezione 16: Animazione (2) Informatica Multimediale Docente: Umberto Castellani Sommario Introduzione Origini Produrre animazioni Animazione tradizionale (2D) Animazione digitale 2 Animazione 3D Animazione

Dettagli

RADIOSITY TUTORIAL. versione originale su: http://www.mvpny.com/radtutmv/radiositytut1mv.html

RADIOSITY TUTORIAL. versione originale su: http://www.mvpny.com/radtutmv/radiositytut1mv.html RADIOSITY TUTORIAL La "Profondità Diffusione" che si imposta nella finesta Settaggi Radiosity (render- >parametri rendering->radiosity) stabilisce quante volte una fonte di illuminazione andrà a riflettersi

Dettagli

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

Dettagli

Funzioni del Sistema Operativo

Funzioni del Sistema Operativo Il Software I componenti fisici del calcolatore (unità centrale e periferiche) costituiscono il cosiddetto Hardware (ferramenta). La struttura del calcolatore può essere schematizzata come una serie di

Dettagli

La Pipeline Grafica. Vediamo come avviene il rendering, ovvero la visualizzazione di oggetti. Introduzione. La Pipeline Grafica.

La Pipeline Grafica. Vediamo come avviene il rendering, ovvero la visualizzazione di oggetti. Introduzione. La Pipeline Grafica. La Pipeline Grafica Vediamo come avviene il rendering, ovvero la visualizzazione di oggetti. Introduzione La Pipeline Grafica Spazio vista Spazio 3D-screen Shading Rasterizzazione Rimozione delle facce

Dettagli

Introduzione INTRODUZIONE

Introduzione INTRODUZIONE INTRODUZIONE INTRODUZIONE 15 Introduzione Contenuti: Come usare questa guida all uso Cos è una animazione? Gli elementi della animazione 3D Apprendere le capacità di un Animatore 3D Quanto tempo si impiega

Dettagli

Indice. Indice vi- III. Unità 1 Il personal computer, 1. Unità 2 AutoCAD, 9

Indice. Indice vi- III. Unità 1 Il personal computer, 1. Unità 2 AutoCAD, 9 Percezione Costruzioni e comunicazione geometriche Indice vi- III Indice Unità 1 Il personal computer, 1 1.1 Struttura del personal computer, 2 1.2 Il software, 5 1.3 I dispositivi informatici di stampa,

Dettagli

Progettazione e realizzazione di una GUI multi-piattaforma per applicazioni mediche in 2D

Progettazione e realizzazione di una GUI multi-piattaforma per applicazioni mediche in 2D UNIVERSITÀ DEGLI STUDI DI BOLOGNA FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea in Scienze dell Informazione Progettazione e realizzazione di una GUI multi-piattaforma per applicazioni

Dettagli

Il software impiegato su un computer si distingue in: Sistema Operativo Compilatori per produrre programmi

Il software impiegato su un computer si distingue in: Sistema Operativo Compilatori per produrre programmi Il Software Il software impiegato su un computer si distingue in: Software di sistema Sistema Operativo Compilatori per produrre programmi Software applicativo Elaborazione testi Fogli elettronici Basi

Dettagli

LA SIMULAZIONE ILLUMINOTECNICA CON RADIANCE MEDIANTE ECOTECT

LA SIMULAZIONE ILLUMINOTECNICA CON RADIANCE MEDIANTE ECOTECT A02 059 Laura Bellia Carla Di Martino Gennaro Spada LA SIMULAZIONE ILLUMINOTECNICA CON RADIANCE MEDIANTE ECOTECT L ILLUMINAZIONE DI UNA CHIESA DI INTERESSE STORICO ARTISTICO Copyright MMX ARACNE editrice

Dettagli

Grafica 3D Interattiva

Grafica 3D Interattiva Informatica Grafica ][ Marco Gribaudo marcog@di.unito.it Grafica 3D Interattiva sono una libreria di funzioni a basso livello per facilitare la scrittura di videogiochi e di applicazioni multimediali.

Dettagli

Strumenti per lo sviluppo del software

Strumenti per lo sviluppo del software Lo sviluppo del software Strumenti per lo sviluppo del software Lo sviluppo del software è l attività centrale del progetto e ha lo scopo di produrre il codice sorgente che, una volta compilato e messo

Dettagli

Introduzione ai Sistemi Operativi

Introduzione ai Sistemi Operativi Introduzione ai Sistemi Operativi Sistema Operativo Software! Applicazioni! Sistema Operativo! È il livello di SW con cui! interagisce l utente! e comprende! programmi quali :! Compilatori! Editori di

Dettagli

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

Dettagli

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO IL SOFTWARE L HARDWARE da solo non è sufficiente a far funzionare un computer Servono dei PROGRAMMI (SOFTWARE) per: o Far interagire, mettere in comunicazione, le varie componenti hardware tra loro o Sfruttare

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A1 - Interfacce grafiche 1 Prerequisiti Utilizzo di un sistema operativo Programmazione elementare ad oggetti Concetto di macchina virtuale Tipi di interfaccia Riferimento

Dettagli

Elementi del calcolatore: CPU

Elementi del calcolatore: CPU Elementi del calcolatore: CPU Elementi del calcolatore: Memoria Elementi del calcolatore: Memoria Elementi del calcolatore: Hard Disk Antefatto Sistema Operativo Come il computer appare Il calcolatore

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

Sistemi operativi I: Windows. Lezione I

Sistemi operativi I: Windows. Lezione I Sistemi operativi I: Windows Lezione I Scopo della lezione Richiamare le principali funzionalità di un sistema operativo Esemplificarle descrivendo la loro implementazione in Windows Introdurre alcuni

Dettagli

Realizzazione di uno strumento web-based per la simulazione remota di reti di sensori senza filo

Realizzazione di uno strumento web-based per la simulazione remota di reti di sensori senza filo tesi di laurea Realizzazione di uno strumento web-based per la simulazione remota di reti di sensori senza filo Anno Accademico 2009/2010 relatore Ch.mo prof. Marcello Cinque correlatore Ing. Catello di

Dettagli

GeoGebra vers.5 - vista Grafici 3D

GeoGebra vers.5 - vista Grafici 3D GeoGebra vers.5 - vista Grafici 3D Marzo 2015 (manuale on-line, con aggiunte a cura di L. Tomasi) Questo articolo si riferisce a un componente della interfaccia utente di GeoGebra. Viste Menu Vista Algebra

Dettagli

Infrastrutture Software

Infrastrutture Software Infrastrutture Software I componenti fisici di un sistema informatico sono resi accessibili agli utenti attraverso un complesso di strumenti software finalizzati all utilizzo dell architettura. Si tratta

Dettagli

Informatica e Bioinformatica: Sistemi Operativi

Informatica e Bioinformatica: Sistemi Operativi Informatica e Bioinformatica: Sistemi Operativi 11 marzo 2013 Macchina Hardware/Software Sistema Operativo Macchina Hardware La macchina hardware corrisponde alle componenti fisiche del calcolatore (quelle

Dettagli

Capitolo 8 Rendering Globale. Dal modello locale ai modelli globali. Cap. 8 - Contenuti. Rendering Locale. Sezione 8.1. Limitazioni del modello locale

Capitolo 8 Rendering Globale. Dal modello locale ai modelli globali. Cap. 8 - Contenuti. Rendering Locale. Sezione 8.1. Limitazioni del modello locale Cap. 8 - Contenuti Capitolo 8 Rendering Globale 8.1 Dal modello locale ai modelli globali Limitazioni del modello locale, effetti globale e modi per approssimarli in un contesto locale 8.2 Ray-tracing

Dettagli

La specifica del problema

La specifica del problema 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Software e Sistemi Operativi Prof. Maurizio Naldi A.A. 2015/16

Software e Sistemi Operativi Prof. Maurizio Naldi A.A. 2015/16 Software e Sistemi Operativi Prof. Maurizio Naldi A.A. 2015/16 Cosa vedremo Il software applicativo Categorie di SW Il sistema operativo Gestione programmi in esecuzione (processi) Gestione memoria Gestione

Dettagli

Le ombre in OpenGl. Daniele Varin LS Ing. Informatica Corso di Elementi di Grafica Digitale http://varindaniele.altervista.org

Le ombre in OpenGl. Daniele Varin LS Ing. Informatica Corso di Elementi di Grafica Digitale http://varindaniele.altervista.org Le ombre in OpenGl Daniele Varin LS Ing. Informatica Corso di Elementi di Grafica Digitale http://varindaniele.altervista.org Punto di partenza In OpenGl le luci non proiettano ombre 2 Perché si introducono

Dettagli

Benvenuti a Maya Introduzione alla grafica 3D e al mondo

Benvenuti a Maya Introduzione alla grafica 3D e al mondo Introduzione Benvenuti a Maya Introduzione alla grafica 3D e al mondo della Computer Graphics. Questo volume introduttivo, dedicato indifferentemente a coloro che affrontano per la prima volta il mondo

Dettagli

Capitolo 1 Introduzione a Gambas

Capitolo 1 Introduzione a Gambas Capitolo 1 Introduzione a Gambas Gambas è stato creato inizialmente da Benoit Minisini, un residente della periferia di Parigi. Secondo Benoit, Gambas è un linguaggio Basic con estensioni per la programmazione

Dettagli

INFORMATICA CORSI DELL'INDIRIZZO TECNICO CLASSI PRIME AMMINISTRAZIONE - FINANZA E MARKETING

INFORMATICA CORSI DELL'INDIRIZZO TECNICO CLASSI PRIME AMMINISTRAZIONE - FINANZA E MARKETING INFORMATICA CORSI DELL'INDIRIZZO TECNICO CLASSI PRIME AMMINISTRAZIONE - FINANZA E MARKETING Modulo propedeutico Le lezioni teoriche sono sviluppate sui seguenti argomenti: Struttura dell elaboratore: CPU,

Dettagli

Visualizzazione in ambienti di Realtà Virtuale di scenari fotorealistici basati su dati e calcoli illuminotecnici. Applicazione agli Esterni Urbani

Visualizzazione in ambienti di Realtà Virtuale di scenari fotorealistici basati su dati e calcoli illuminotecnici. Applicazione agli Esterni Urbani Agenzia Nazionale per le Nuove Tecnologie l Energia e lo Sviluppo Economico Sostenibile RICERCA DI SISTEMA ELETTRICO Visualizzazione in ambienti di Realtà Virtuale di scenari fotorealistici basati su dati

Dettagli

uomo Software (sistema operativo) hardware

uomo Software (sistema operativo) hardware uomo Software (sistema operativo) hardware 1 Sistema operativo Insieme di programmi che svolgono funzioni essenziali per l uso del sistema di elaborazione Questi programmi sono i primi ad essere eseguiti

Dettagli

Benvenuti in Maya 7 e nel mondo della Computer

Benvenuti in Maya 7 e nel mondo della Computer Introduzione Benvenuti in Maya 7 e nel mondo della Computer Generated Imagery (CGI). Indipendentemente dal fatto che il lettore sia un principiante delle immagini 3D o un esperto di altre applicazioni

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

UNIVERSITÀ DEGLI STUDI DI SIENA

UNIVERSITÀ DEGLI STUDI DI SIENA UNIVERSITÀ DEGLI STUDI DI SIENA FACOLTÀ DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria Informatica, orientamento Robotica ed Automazione Tesi di Laurea Interazione Visuo-Aptica con Oggetti Deformabili

Dettagli

Introduzione ad Unreal Technology

Introduzione ad Unreal Technology Informatica Grafica ][ Introduzione ad e' il nome dato al motore grafico utilizzato in numerosi videogiochi commerciali. Una delle caratteristiche fondamentali di tale prodotto, e' quella di avere uno

Dettagli

Sistemi Operativi. Modulo 2. C. Marrocco. Università degli Studi di Cassino

Sistemi Operativi. Modulo 2. C. Marrocco. Università degli Studi di Cassino Sistemi Operativi Modulo 2 Schema di un Sistema di Calcolo Programmi Dati di Input Calcolatore Dati di output Modello di von Neumann Bus di sistema CPU Memoria Centrale Memoria di Massa Interfaccia Periferica

Dettagli

Fondamenti di Informatica Laurea in Ingegneria Civile e Ingegneria per l ambiente e il territorio

Fondamenti di Informatica Laurea in Ingegneria Civile e Ingegneria per l ambiente e il territorio Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Fondamenti di Informatica Laurea in Ingegneria Civile e Ingegneria per l ambiente e il territorio Il software di base Software

Dettagli

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI Il Software Software di Base Sistema Operativo (Software di base essenziale) Software di base non essenziale Utility Driver Software applicativi (Applicazioni)

Dettagli

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Sistema operativo Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Architettura a strati di un calcolatore

Dettagli

il Mac e lo studio legale: primi passi in EasyLex

il Mac e lo studio legale: primi passi in EasyLex _tutorial Come approcciare il software per la gestione degli studi legali che accompagna gli utenti della Mela dai lontani tempi di Mac OS Francesco Pignatelli il Mac e lo studio legale: primi passi in

Dettagli

Open Source 3D Engine. OpenGL Rendering System. Il Framework

Open Source 3D Engine. OpenGL Rendering System. Il Framework Open Source 3D Engine OpenGL Rendering System Il Framework I moderni mezzi di programmazione, consentono a noi sviluppatori di utilizzare librerie avanzate e testate che si prestano eccellentemente allo

Dettagli

Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET)

Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET) Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET) Ipotesi di partenza: concetti di base del networking Le ipotesi di partenza indispensabili per poter parlare di tecniche di accesso

Dettagli

Software. Algoritmo. Algoritmo INFORMATICA PER LE DISCIPLINE UMANISTICHE 2 (13042)

Software. Algoritmo. Algoritmo INFORMATICA PER LE DISCIPLINE UMANISTICHE 2 (13042) INFORMATICA PER LE DISCIPLINE UMANISTICHE 2 (13042) Gli elaboratori utilizzano memoria per Dati da elaborare Istruzioni eseguite dall elaboratore software differenti risoluzione problemi differenti Algoritmo

Dettagli

Abilità Informatiche A.A. 2010/2011 Lezione 4: SoftWare. Facoltà di Lingue e Letterature Straniere

Abilità Informatiche A.A. 2010/2011 Lezione 4: SoftWare. Facoltà di Lingue e Letterature Straniere Abilità Informatiche A.A. 2010/2011 Lezione 4: SoftWare Facoltà di Lingue e Letterature Straniere Software È un insieme di programmi che permettono di trasformare un insieme di circuiti elettronici (=

Dettagli

Corrado Malanga ARCHETIPI E NUMERI

Corrado Malanga ARCHETIPI E NUMERI Corrado Malanga Nel precedente lavoro ho parlato degli archetipi, ne ho fornito le definizioni ed ho descritto cosa i suddetti archetipi siano, come funzionino e perché siano legati ad alcuni numeri e

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

Information Visualization

Information Visualization Information Visualization Introduzione alla CG Prof. Andrea F. Abate abate@unisa.it http://www.unisa.it/docenti/andreafrancescoabate/index CG e VR: cosa sono e a cosa servono Con il termine Computer Graphics,

Dettagli

Strutture dei Sistemi Operativi

Strutture dei Sistemi Operativi Strutture dei Sistemi Operativi Componenti di sistema Servizi del sistema operativo Chiamate di sistema Programmi di sistema Struttura del sistema Macchine virtuali Progetto e implementazione di sistemi

Dettagli

Facoltà di Ingegneria

Facoltà di Ingegneria Università degli studi di Roma Tor Vergata Facoltà di Ingegneria Laurea in Ingegneria Informatica Creazione e animazione interattiva di grafica tridimensionale Relatore Ing. Francesco Martinelli Candidato

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Informazioni Tecniche su TachyCAD

Informazioni Tecniche su TachyCAD Informazioni Tecniche su TachyCAD Le seguenti pagine danno una panoramica dettagliata dei possibili utilizzi di TachyCAD. Per ulteriori domande o commenti, contattateci direttamente. Kubit Italia Topotek

Dettagli

RisPlan Pianificazione risorse

RisPlan Pianificazione risorse RISNOVA Pianificazione risorse RisPlan Pianificazione risorse Sistema modulare per la pianificazione delle risorse. RISNOVA In Muntagna 4 6528 Camorino www.risnova.com Tel. +41 91 252 00 55 info@risnova.com

Dettagli

Grafica al Calcolatore Fotorealismo - 1. Introduzione

Grafica al Calcolatore Fotorealismo - 1. Introduzione Fotorealismo Dove si elecano trucchi sagaci ed effetti speciali che servono ad aumentare con poca spesa il fotorealismo. Introduzione Environment map Light map Ombre geometriche Trasparenza Multi-pass

Dettagli

INTRODUZIONE ALLE PIATTAFORME

INTRODUZIONE ALLE PIATTAFORME INTRODUZIONE ALLE PIATTAFORME Android ios Windows Phone 8 Android 2 Cos è Android? Un moderno open-source sistema operativo Componenti: Linux kernel Java Core applications 3 Perché è stato un successo

Dettagli

Il Sistema Operativo (1)

Il Sistema Operativo (1) E il software fondamentale del computer, gestisce tutto il suo funzionamento e crea un interfaccia con l utente. Le sue funzioni principali sono: Il Sistema Operativo (1) La gestione dell unità centrale

Dettagli

1.2.1.1 DEFINIZIONE DI SOFTWARE

1.2.1.1 DEFINIZIONE DI SOFTWARE Software 1.2 1.2.1.1 DEFINIZIONE DI SOFTWARE Il computer non è in grado di svolgere alcun compito autonomamente Esso può eseguire svariati compiti soltanto se viene opportunamente istruito Ciò avviene

Dettagli

ScuolaSI computer grafica 3d

ScuolaSI computer grafica 3d ScuolaSI computer grafica 3d pagina stampata dal sito ScuolaSI http://www.scuolasi.it pubblicato il 22/04/2011 Grafica - La computer grafica 3D è un ramo della computer grafica che basa la creazione di

Dettagli

Illuminazione avanzata

Illuminazione avanzata Informatica Grafica per le arti Illuminazione avanzata E' possibile applicare una bitmap ad una luce. Una luce a cui e' applicata una bitmap proietta l'immagine associata nello spazio. Marco Gribaudo marcog@di.unito.it

Dettagli

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione.

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione. C6. REALIZZAZIONE DEL FILE SYSTEM Struttura del file system Un file è analizzabile da diversi punti di vista. Dal punto di vista del sistema è un contenitore di dati collegati tra di loro, mentre dal punto

Dettagli

Appunti lezione Database del 07/10/2015

Appunti lezione Database del 07/10/2015 Appunti lezione Database del 07/10/2015 Nelle lezioni precedenti si è visto come qualunque applicazione informativa è almeno formata da tre livelli o layers che ogni progettista conosce e sa gestire: Livello

Dettagli

Luci/Ombre. YAFARAY motore di rendering Open Source. Federico Frittelli aka fredfrittella. SUTURA-studio di progettazione.

Luci/Ombre. YAFARAY motore di rendering Open Source. Federico Frittelli aka fredfrittella. SUTURA-studio di progettazione. Luci/Ombre YAFARAY motore di rendering Open Source Federico Frittelli aka fredfrittella SUTURA-studio di progettazione LinuxDay, 2010 fredfrittella (SUTURA-studio di progettazione) Luci/Ombre 23 Ottobre

Dettagli

Il software. Il Sistema Operativo

Il software. Il Sistema Operativo Il software Prof. Vincenzo Auletta 1 Il Sistema Operativo Software che gestisce e controlla automaticamente le risorse del computer permettendone il funzionamento. Gestisce il computer senza che l utente

Dettagli

Introduzione a ARCHICAD

Introduzione a ARCHICAD Introduzione a ARCHICAD Politecnico Di Bari Ingegneria Edile - Architettura Corso di Informatica Grafica A.A. 2004/2005 Docente del Corso: Marcello Castellano Assistente: Oronzo Tavani Pre-requisiti Pre-requisiti:

Dettagli

Ricostruzione e visualizzazione 3D di un cervello da acquisizioni manuali di sezioni istologiche

Ricostruzione e visualizzazione 3D di un cervello da acquisizioni manuali di sezioni istologiche Ricostruzione e visualizzazione 3D di un cervello da acquisizioni manuali di sezioni istologiche Sergio Demelio e Enrico Gobbetti CRS4 Centro di Ricerca, Sviluppo e Studi Superiori in Sardegna VI Strada

Dettagli

Parte 3. Sistemi Operativi. Sistema operativo. Il sistema operativo (Operating System - OS): offre le operazioni base necessarie per:

Parte 3. Sistemi Operativi. Sistema operativo. Il sistema operativo (Operating System - OS): offre le operazioni base necessarie per: Parte 3 Sistemi Operativi Sistema operativo Il sistema operativo (Operating System - OS): offre le operazioni base necessarie per: l uso efficace del computer mediante funzionalità che non sono fornite

Dettagli

Lezione 3: Grafica 3D*

Lezione 3: Grafica 3D* Lezione 3: Grafica 3D* Informatica Multimediale Docente: Umberto Castellani *I lucidi sono tratti da una lezione di Maura Melotti (m.melotti@cineca.it) Sommario Il processo grafico La modellazione 3D Rendering

Dettagli

1 Introduzione 1. Ottica Geometrica

1 Introduzione 1. Ottica Geometrica 1 Introduzione 1 1 Introduzione Ottica Geometrica 1.1 Estratto Lo scopo di questa esperienza è quello di apprendere come la luce interagisce con elementi ottici quali le lenti, e come, in sequito alla

Dettagli

www.type3.com SCOPRITE Discover TYPE EDIT V12 Italiano 04-2014 1

www.type3.com SCOPRITE Discover TYPE EDIT V12 Italiano 04-2014 1 www.type3.com SCOPRITE Discover TYPE EDIT V12 Italiano 04-2014 1 Scoprite TYPE EDIT V12, la nuova versione del nostro software CAD/CAM per applicazioni industriali e artistiche dedicate alle macchine CNC.

Dettagli

Corso Android Corso Online Programmatore Android

Corso Android Corso Online Programmatore Android Corso Android Corso Online Programmatore Android Accademia Domani Via Pietro Blaserna, 101-00146 ROMA (RM) info@accademiadomani.it Programma Generale del Corso Modulo Uno - Programmazione J2ee 1) Programmazione

Dettagli

WP4 Sviluppo: Realizzazione motore di render dello storytelling MESI 9-21

WP4 Sviluppo: Realizzazione motore di render dello storytelling MESI 9-21 WP4 Sviluppo: Realizzazione motore di render dello storytelling MESI 9-21 A seguito della completa messa a punto delle specifiche funzionali, si e' passati allo sviluppo del software vero e proprio. Di

Dettagli