Università degli studi di Pisa - UCL Computer Science · Prof. Paolo Ancilotti Prof. Graziano...

Università degli studi di Pisa Facoltà di Ingegneria

Corso di Laurea in Ingegneria Elettronica

Tesi di Laurea

Progettazione e realizzazione di un sistema per la presentazione nello spazio 3D di reperti archeologici

modellati in ambiente virtuale

Candidato:

Andrea Brogni

Relatori: Controrelatore: Prof. Paolo Ancilotti Prof. Graziano Frosini

Prof. Massimo Bergamasco Prof.ssa Edda Bresciani

Anno Accademico 1996/97

Ai miei genitori

Ringrazio tutti coloro che mi sono stati vicini durante questi anni, ed in particolare Gaia e Simone.

Un ringraziamento particolare va al Prof. Massimo Bergamasco ed alla Prof.ssa Bresciani, che mi hanno sempre incoraggiato ed aiutato. Un grazie sincero a tutti i ragazzi del Laboratorio PERCRO, per la loro pazienza: a Monica e Silvia, a Stefano, Maurizio, Carlo, ed a tutti gli altri. Grazie Franco !

INTRODUZIONE

Negli ultimi anni stiamo assistendo ad una costante evoluzione della scienza archeologica, la quale, dalla sola registrazione dei dati sul calcolatore, sta accrescendo la propria collaborazione con le scienze tecnologiche.

Anche i Musei, nel loro intento di conservare e rendere accessibili le opere al loro interno, stanno sfruttando le nuove tecnologie, come la grafica 3D, evolvendo verso i cosiddetti Musei Virtuali.

Il lavoro presentato in questa tesi si propone proprio di sviluppare un

nuovo sistema per una completa fruibilità dell’opera d’arte, sfruttando le nuove tecnologie per interazione in ambiente virtuale.

È stato sviluppato e realizzato un sistema che utilizzasse un nuovo paradigma di interazione tra l’utente e l’oggetto virtuale rappresentato, e che impiega uno schermo portatile come finestra verso il mondo virtuale.

Il capitolo uno riguarda lo studio effettuato sullo stato dell’arte

nell’Archeologia Virtuale. Il capitolo due descrive la situazione attuale nei musei reali, ed il

possibile loro sviluppo nei futuri Musei Virtuali. Nel capitolo tre viene descritto il manufatto archeologico utilizzato

come soggetto della rappresentazione virtuale: un calice egizio del III sec. d.C..

Nel capitolo quattro sono analizzati gli attuali sistemi di navigazione in ambienti virtuali.

2

Il capitolo cinque descrive il sistema di rappresentazione sviluppato, il quale sfrutta un nuovo sistema a finestra mobile.

Con il capitolo sei, viene descritta l’intera applicazione, con lo sviluppo del codice implementato.

Lo studio e l’intera realizzazione di questo progetto di tesi sono stati

sviluppati presso il laboratorio PERCRO della Scuola Superiore S.Anna.

I

Sommario SOMMARIO .......................................................................................................... I INDICE DELLE FIGURE ......................................................................................... III INTRODUZIONE .........................................................................................................1 CAPITOLO 1 ..........................................................................................................3 VERSO L’ARCHEOLOGIA VIRTUALE ......................................................................3

1.1 Caratteri tecnologici e multidisciplinari dell’archeologia ...................................3 1.2 La rappresentazione virtuale .................................................................................5 1.3 Esempi di ricostruzioni virtuali ............................................................................7 1.4 Analisi dello stato attuale ...................................................................................19

CAPITOLO 2 ........................................................................................................22 I MUSEI VIRTUALI .....................................................................................................22

2.1 Introduzione ........................................................................................................22 2.2 Considerazioni sui Musei Virtuali del prossimo futuro .....................................24 2.3 Esempi di Musei Multimediali ...........................................................................27 2.4 Obiettivi della tesi ...............................................................................................28

CAPITOLO 3 ........................................................................................................30 IL CALICE ........................................................................................................30

3.1 Calice egizio della Collezione Schiff Giorgini ...................................................30 3.2 Informazioni storiche ..........................................................................................31 3.3 Collocazione attuale ............................................................................................33 3.4 Le decorazioni .....................................................................................................34 3.4 Modellazione grafica3D ......................................................................................38 3.4.1 Descrizione del software utilizzato ..............................................................38 3.4.2 Sviluppo del modello 3D .............................................................................39 3.4.3 Sviluppo delle texture ..................................................................................48 3.4.4 Rendering della scena ..................................................................................53

CAPITOLO 4 ........................................................................................................55 SISTEMI DI RAPPRESENTAZIONE E NAVIGAZIONE IN AMBIENTI VIRTUALI ...............................................................55

4.1 Introduzione ........................................................................................................55 4.2 Percorsi guidati ....................................................................................................58 4.3 Navigazione libera ...............................................................................................59 4.4 Sistemi di immersione .........................................................................................60 4.4.1 Introduzione .................................................................................................60 4.4.2 Head Mounted Display ................................................................................60

II

4.4.3 Head Coupled System ..................................................................................61 4.4.4 Spatially Immersive Display ........................................................................62 4.4.5 Virtual Model Display ..................................................................................62 4.5 Sistema a finestra mobile .....................................................................................64 4.6 Sistemi di tracker .................................................................................................65

CAPITOLO 5 ........................................................................................................67 IL SISTEMA DI RAPPRESENTAZIONE ....................................................................67

5.1 Una finestra reale sul mondo virtuale ..................................................................67 5.2 Struttura e descrizione dell’hardware utilizzato ..................................................71 5.3 Motivazione delle scelte hardware ......................................................................72 5.4 Descrizione del software utilizzato .....................................................................74 5.5 Motivazione delle scelte software .......................................................................77 5.6 Ultime modifiche ad hardware e software ...........................................................77

CAPITOLO 6 ........................................................................................................79 SVILUPPO DELL’APPLICAZIONE ............................................................................79

6.1 Descrizione della programmazione software ......................................................79 6.1.1 Obiettivi e struttura ......................................................................................79 6.1.2 Sviluppo del codice ......................................................................................86 6.1.1 Problemi particolari e soluzioni ...................................................................90

CONCLUSIONI ........................................................................................................94 APPENDICE A ........................................................................................................96 Funzioni di controllo per Polhemus, VRLib e GLUT ....................................................96 APPENDICE B ......................................................................................................104 Funzioni generali ......................................................................................................104 BIBLIOGRAFIA ......................................................................................................117

III

Indice delle figure Fig. 1.1 “volo d’uccello” sull’area di Saqqara .......................................................8 Fig. 1.2 sezione della tomba di Horemheb ............................................................9 Fig. 1.3 rilievi nell’ipogeo di Bakenrenef ..............................................................9 Fig. 1.4 ipogeo della tomba di Uage ....................................................................10 Fig. 1.5 tomba di Nefertari ...................................................................................11 Fig. 1.6 bassorilievi policromi nel tempio di Karnak ..........................................11 Fig. 1.7 facciata del Grande tempio di Abu Simbel .............................................11 Fig. 1.8 tempio di Zeus ad Olimpia .....................................................................11 Fig. 1.9 movimento del sole a Stonehenge ..........................................................12 Fig. 1.10 ricostruzione di Ebla ...............................................................................13 Fig. 1.11 la struttura urbana di Ur ..........................................................................13 Fig. 1.12 la Via dei Trionfi dell’antica Roma ........................................................14 Fig. 1.13 Calidarium nella condizione attuale .......................................................14 Fig. 1.14 ricostruzione virtuale del Calidarium .....................................................14 Fig. 1.15 Casa del Fauno a Pompei .......................................................................15 Fig. 1.16 ricostruzione virtuale della Casa del Fauno a Pompei ...........................15 Fig. 1.17 la città di Pechino in epoca mongola ......................................................16 Fig. 1.18 Templo Major a Mexico-Tenochtitlán ...................................................16 Fig. 1.19 Mexico-Tenochtitlán ..............................................................................16 Fig. 1.20 accampamento mongolo .........................................................................17 Fig. 1.21 allestimento di una sala del Louvre ........................................................18 Fig. 2.1 la Alte Pinakothek di Monaco ................................................................25 Fig. 3.1 calice della Collezione Schiff Giorgini ................................................31 Fig. 3.2 piantina della zona di Sedeinga .............................................................32 Fig. 3.3 calice nella teca del Museo ....................................................................33 Fig. 3.4 primo registro ........................................................................................34 Fig. 3.5 scena totale del registro principale ........................................................35 Fig. 3.6 dio Osiri .................................................................................................36 Fig. 3.7 primo offerente ......................................................................................36

IV

Fig. 3.8 secondo offerente ...................................................................................37 Fig. 3.9 terzo offerente ........................................................................................37 Fig. 3.10 terzo registro ..........................................................................................37 Fig. 3.11 calice separato in var pezzi ....................................................................40 Fig. 3.12 lucido con le misurazioni .......................................................................43 Fig. 3.13 wireframe di base e gambo ....................................................................44 Fig. 3.14 curve di rivoluzione ...............................................................................44 Fig. 3.15 wireframe della parte alta ......................................................................45 Fig. 3.16 calice: in wireframe e poligonale ..........................................................47 Fig. 3.17 l’interfaccia grafica di PowerAnimator .................................................48 Fig. 3.18 controllo della trasparenza della coppa .................................................49 Fig. 3.19 controllo della trasparenza della base ....................................................50 Fig. 3.20 le tre mappe per la trasparenza ..............................................................51 Fig. 3.21 le tre texture delle decorazioni ..............................................................52 Fig. 3.22 ray trace del calice .................................................................................54 Fig. 3.23 ray trace della visione planare ...............................................................54 Fig. 4.1 determinanti di Sheridan ........................................................................56 Fig. 4.2 sistemi di riferimento nell’ambiente virtuale ........................................57 Fig. 4.3 sistema SIDs ..........................................................................................62 Fig. 4.4 sistema VMDs .......................................................................................63 Fig. 4.5 sistema a finestra mobile .......................................................................64 Fig. 4.6 tracker meccanico ..................................................................................65 Fig. 5.1 canali di interazione tra utente e sistema ...............................................69 Fig. 5.2 schema dell’hardware ............................................................................71 Fig. 5.3 schema del software ..............................................................................75 Fig. 6.1 schema generale dell’applicazione ........................................................80 Fig. 6.2 scelta iniziale della lingua .....................................................................82 Fig. 6.3 menù generale ........................................................................................83 Fig. 6.4 riposizionamento del manufatto virtuale ...............................................85 Fig. 6.5 suddivisione dei file ...............................................................................86 Fig. 6.6 blocchi operativi ....................................................................................88 Fig. 6.7 main del codice ......................................................................................89 Fig. 6.8 funzioni ..................................................................................................90

3

CAPITOLO 1

Verso l'Archeologia Virtuale

1.1 Caratteri tecnologici e multidisciplinari dell'archeologia Da secoli, il lavoro degli archeologi è quello di esplorare, di riportare

alla luce dei reperti, e da quelli immaginare e capire il tempo passato. Il loro compito consiste nel ricostruire la vita di popoli scomparsi,

basandosi sul risultato delle loro ricerche. Una caratteristica importante per affrontare questi studi è sicuramente

la capacità di visualizzazione, che permette allo studioso di ricreare situazioni e paesaggi del passato.

Attualmente stiamo assistendo ad una lenta evoluzione della scienza archeologica, che comprende sia la registrazione al calcolatore di tutti i dati relativi allo scavo archeologico, sino all'ottenimento di ricostruzioni tridimensionali dei siti, nelle quali ai piani ed alle sezioni tradizionali si possono integrare rappresentazioni virtuali.

E` proprio questo uno degli aspetti più interessanti della nuova scienza archeologica: la possibilità di capire come scienze all'apparenza così diverse, quali quelle archeologiche e storiche e quelle tecnico-scientifiche, possano contribuire per fornire nuove possibilità di conoscenza.

L'avvicinamento progressivo degli archeologi verso le nuove tecnologie, come mezzo per immagazzinare dati ed elaborarli, o addirittura come mezzi d’indagine conoscitiva, ha portato ad una confluenza di diversi campi di ricerca: archeologi tradizionali, ingegneri

Verso l’Archeologia Virtuale

4

o geometri che si occupano di rilievi topografici, esperti di apparecchiature per il rilievo, geologi per studiare le stratigrafie, fisici, informatici e programmatori per modellare ed interpretare i dati, esperti di grafica di calcolatori che sviluppano tecniche 2D e 3D di alto rendering allo scopo di ottenere immagini fotorealistiche.

E` possibile pensare che con il passare del tempo, lo studioso del mondo antico avrà a disposizione strumenti sempre più sofisticati per ricostruire il passato.

La precisione con la quale questo processo potrà avvenire sarà sempre maggiore.

Lo scopo primario della metodologia archeologica è quello di riuscire a mantenere accessibili tutte le informazioni raccolte, sempre pronte per essere consultate, elaborate ed eventualmente aggiornate. Il problema principale è la lenta acquisizione dei dati da interpretare, per ottenerne una rappresentazione attendibile: il lavoro di ricerca e raccolta dei dati può a volte durare anni.

Con le normali attività di ricerca, la fase di scavo è quella che fornisce il maggiore numero di dati, ma presenta delle procedure particolari: scoprire significa rimuovere e distruggere, almeno in parte, la condizione attuale del sito, modificandone la storia; l'archeologo ha la necessità di scavare porzioni di terreno, strutture più recenti, stratigrafie, allo scopo di estrarre le maggiori informazioni sul luogo.[FORTE_96]

Lo scavo presuppone la presenza, accertata o presunta, di reperti in profondità, ma non è detto che durante i lavori non affiori qualcosa di imprevisto, mettendo l'archeologo nel dubbio, se continuare o proseguire nella fase di estrazione; non sono rari i casi di siti archeologici che nascondano in differenti strati, differenti reperti appartenenti a periodi storici diversi.

Il caso forse più famoso è il sito di Troia, che con i suoi nove strati copre un lasso di tempo dal 3000 a.C. sino all'età romana, e sarà difficile avere dati precisi sugli strati inferiori, perché richiederebbe la rimozione di quelli superiori.

La possibilità di elaborare graficamente i dati ottenuti dalla fase di scavo, e rappresentarli mediante modelli virtuali fornisce sicuramente un modo nuovo, non intrusivo, di studiare i siti archeologici.


5

La riproduzione virtuale si presenta come un potente strumento cognitivo, capace di comunicare in modo diretto e di agire da mediatore tra i reperti catalogati e rappresentati e lo studioso.

1.2 La rappresentazione virtuale Il problema della rappresentazione virtuale di dati archeologici, ha

molte analogie con quello della visualizzazione scientifica, perché in entrambi i casi vi è la necessità di fornire dati e risultati di ricerche, talvolta ad un livello di conoscenza molto alto, in maniera chiara ed interpretabile dall’utente finale, sia esso studioso che profano o semplice visitatore.

In archeologia i dati da mostrare non sono valori numerici, ottenuti da funzioni o calcoli matematici, ma derivano da un lungo e complesso processo di esplorazione, recupero e ripristino di oggetti e strutture fisiche; lo studio non si ferma al semplice componente, ma si sviluppa, cercando di valutarne le funzionalità e la collocazione in una precisa cultura e società del passato.

La ricostruzione storica completa non può fermarsi al recupero di manufatti e strutture, ma deve anche riscoprire le tecnologie che li hanno prodotti, al tipo di vita condotta da chi li ha pensati ed usati, alla loro importanza nella storia del periodo considerato.

Un approccio di rappresentazione virtuale porta sicuramente vantaggi, quali:

a) è possibile simulare una ricostruzione completa del manufatto o di strutture, partendo da parti danneggiate o dati incompleti;

b) utilizzare un’elevata qualità di rendering grafico, in particolare nella resa dei colori e delle texture che possono essere applicate ai modelli, rendendo più chiara la condizione ambientale originale nella quale si poteva trovare l'oggetto stesso;

c) la grande diffusione dei calcolatori, e la presenza di reti di collegamento, come Internet, danno la possibilità a chiunque di poter osservare il modello in luoghi geograficamente diversi e con presenza multipla di utenti;


6

d) l’eventuale inserimento del modello in un’applicazione multimediale consente di integrare l'immagine 3D ad informazioni di testo, filmati, o registrazioni audio, che integrano il sistema informativo.

e) attualmente la velocità dei computer permette di operare una simulazione di esplorazione: è possibile muoversi all'interno di un sito archeologico ricostruito virtualmente, osservandolo da diverse prospettive, e studiandolo con indagini non intrusive.

Ricreare virtualmente oggetti e costruzioni che sino ad ora sono rimasti solo sulla carta, od in modelli, difficilmente trasportabili, permette di modificare facilmente il modello, aggiornandolo alle nuove scoperte e teorie, e questo con difficoltà e costi molto inferiori (basti pensare al tempo ed alla tecnica necessari per costruire un modello in legno di un palazzo); la possibilità di affiancare più modelli virtuali dello stesso sito, aiuta a confrontare teorie, o fasi storiche diverse, e quindi a fare uno studio più accurato ed attendibile.

La maggiore diffusione della conoscenza archeologica e storica non è l'unico vantaggio portato dalla archeologia virtuale: la necessità di riprodurre modelli fedeli ha costretto anche gli studiosi a cercare notizie più dettagliate, a valutare anche fattori prima meno necessari.

La luce degli ambienti ricostruiti deve riprodurre più fedelmente possibile le condizioni originali, e quindi è necessario conoscere, per esempio, la disposizione di un palazzo rispetto al sole, le fonti di luce utilizzate in quella situazione, e dove potevano essere sistemate.

Anche la possibilità di manipolare facilmente le immagini, e di utilizzarle per riprodurre motivi decorativi o materiali, ha reso necessario uno studio più approfondito sui colori utilizzati, sulle tecniche di pittura e costruzione.

Ed è proprio in queste situazioni che l’utilità della rappresentazione virtuale si manifesta nella tridimensionalità delle strutture.

L’operazione di digitalizzazione degli edifici diviene una vera e propria costruzione in uno spazio geometrico 3D; l’archeologo è quindi costretto a porsi dei problemi sostanziali che sarebbero potuti rimanere nascosti nella tradizionale ricostruzione bidimensionale.

La costruzione, che può avvenire in maniera progressiva, permette di sciogliere dubbi o prospettare soluzioni diverse se i dati ricavati dall’operazione di scavo non sono univoci; la possibilità di cambiare


7

rapidamente il modello operando al calcolatore aiuta nella fase preliminare dello studio.

La ricostruzione di ambienti virtuali consente di avere un approccio completamente nuovo verso la storia e l'archeologia, anche per lo studente o per il semplice curioso, che si ritrovano immersi in un mondo che finalmente è più intuitivo da immaginare e da capire.

La visita di ambienti archeologici virtuali da parte di persone interessate ad apprendere, quali ad esempio studenti, e che sono quindi i destinatari ultimi delle informazioni contenute nel modello, presenta un problema fondamentale legato all'uso della computer grafica come supporto didattico.[MAZZEO_97]

Nel momento stesso in cui la ricostruzione virtuale è utilizzata non solo per rievocare oggetti o situazioni passate, ma anche per spiegare e mostrare dettagli di realtà esistite, il realizzatore si carica di grandi responsabilità, soprattutto per l'inevitabile lavoro di filtro che compie nel passare dall'opera reale ad un modello grafico.

Esiste il rischio che nella rappresentazione virtuale si riversino errori di misura o di colorazione, o semplificazioni del modello troppo spinte, con il risultato di fornire informazioni errate.

A questo proposito è necessario a priori stabilire quale sia lo scopo della riproduzione virtuale, e di conseguenza andare o meno a fondo nei dettagli.[SIMS_97]

In particolar modo nelle ricostruzioni ambientali, l'accuratezza di dimensioni e proporzioni può essere importante nella interpretazione di alcuni siti, anche tenendo conto che il modello virtuale viene ad essere l'unico riferimento complessivo di uno studio.

“Un buon modello può insegnare ed intrattenere, ma un modello spoglio può solo intrattenere; se insegna, porta confusione” H. Eiteljorg.


8

1.3 Esempi di ricostruzioni virtuali Da qualche anno, l'archeologia virtuale è diventata una strategia di

ricerca molto diffusa, e questo ha permesso di verificare le sue possibilità nelle più diverse discipline legate all’archeologia.

Gli studi storici che hanno beneficiato di aiuto “virtuale” vanno dalla ricostruzione di palazzi fino a quelle di intere città, toccando siti sparsi in tutto il mondo.

In molti casi, la rappresentazione di un sito è utile per studiare la zona da una prospettiva nuova, ad esempio dall’alto.

La tecnica di visualizzazione detta “a volo d’uccello” permette di avere una visione di insieme della zona, adatta per interpretare la funzionalità dei vari edifici, ed il progetto generale della costruzione (fig. 1.1).

La visita all’interno di tombe antiche è un momento denso di sensazioni, ma non sempre è possibile, sia perché è necessario recarsi sul posto, sia perché talvolta può essere difficoltoso accedervi.

La tomba di Horemheb (XVIII dinastia), in Egitto, è stata ricostruita virtualmente (fig. 1.2), ed è possibile visitarne l’interno, ma anche vederla in sezione dall’esterno, e renderci conto delle difficoltà incontrate per la sua costruzione e della funzione delle varie stanze.

fig. 1.1 "volo d'uccello" sull'area di Saqqara


9

fig. 1.2 sezione della tomba

di Horemheb

Fino a poco tempo fa, le decorazioni interne delle tombe egizie

venivano recuperate e riprodotte in 2D, sulle pareti virtuali, ma recentemente ci sono stati esempi di ricostruzione tridimensionale.

Nell’ipogeo di Bakenrenef (VII sec. a.C.), nella zona di Saqqara, vi sono molte decorazioni in rilievo, che sono state riprodotte, sperimentando vari algoritmi per la resa della profondità e dei giochi di luce ed ombra, necessari a far risaltare l’opera degli scultori (fig. 1.3).

fig. 1.3 rilievi di Bakeurenef


10

La grande sala ipogea della tomba di Uage a Khelua, in Egitto, (inizio

del II millennio a.C.) è stata ricostruita, riportando sui vari pilastri i bassorilievi a colori, ed illuminando l’ambiente in modo naturale.

L’immagine ottenuta è di grande effetto (fig. 1.4).

fig. 1.4 ipogeo della tomba di Uage

La magnifica tomba di Nefertari, nella valle delle regine, in Egitto,

completamente decorata con rilievi a colori, è stata restaurata di recente, e le visite sono limitate, per non rischiare di compromettere il delicato microclima che ne permette la conservazione.

Una soluzione alternativa che è stata scelta è quella della ricostruzione virtuale (fig. 1.5), che ne ha permesso la visione a molte persone.

Un altro esempio di bassorilievi policromi riportati alla visita in modo virtuale è quello del tempio del dio Amon a Karnak; la riproduzione mostra come dovevano apparire i bassorilievi policromi che ornavano le varie pareti del tempio (fig. 1.6).

Per lo stesso tempio sono state elaborate delle animazioni, che oltre a rendere l’idea del luogo, forniscono informazioni funzionali, riguardanti l’uso delle stanze e le cerimonie che vi si svolgevano: una di queste animazioni mostra il corteo dei sacerdoti che trasporta fuori dal tempio il simbolo dell’imbarcazione sacra.


11

fig. 1.5 tomba di Nefertari

fig. 1.6 bassorilievi policromidel tempio diKarnak

E` difficile poter visualizzare grossi nel pieno del loro splendore, e soprattutto con le colorazioni originali.

Ad Abu Simbel, nella Nubia, vi è il Grande tempio, con una facciata intagliata nella roccia alta circa 30 metri e larga 35 ed ornata da quattro colossali statue alte quasi venti metri e raffiguranti il faraone; originariamente queste erano colorate, ma solo la ricostruzione virtuale, ambientata sul luogo, ha consentito di riportare i colori su questi capolavori (fig. 1.7).

La ricostruzione di templi è stata utilizzata anche ad Olimpia, in Grecia, dove il tempio di Zeus Olimpio è stato riprodotto virtualmente, con le decorazioni sulle colonne, sulle metope e sul frontone, nonché la ricostruzione delle statue, compresa la colossale statua crisoelefantina realizzata da Fidia (fig. 1.8); la visione prospettica rende merito alla grandiosa imponenza del monumento, che doveva timore e rispetto nel visitatore.

fig. 1.7 facciata del Grande

Tempio di Abu Simbel

fig. 1.8 tempio di Zeus adOlimpia


12

L’analisi funzionale di un sito ha ricavato molte informazioni dai

modelli virtuali, in quanto è stato possibile integrarli con l’ambiente circostante, e talvolta riprodurre le condizioni nel quale era attivo.

Un esempio significativo è lo studio svolto su Stonehenge, nell’Inghilterra meridionale.

Le teorie sul ruolo sacro o pagano del luogo sono molte, ma è stato possibile verificarne alcune, grazie a simulazioni nelle quali è stata riprodotta anche la volta celeste contemporanea, con il periodo di alzata e calata del sole (fig. 1.9); simulando il movimento del sole, sono state notate molte coincidenze tra momenti importanti della giornata o dell’anno, con le posizioni delle pietre, e ciò ha rafforzato le ipotesi che vedono Stonehenge come un luogo sì di culto, ma anche di osservazione astronomica e di indicatore del calendario delle stagioni.

fig. 1.9 movimento del sole aStonehenge


13

Lo studio di intere città, nel loro complesso, nei vari periodi storici, ma anche nei palazzi, nelle strade urbane è un campo nel quale ha molto successo la rappresentazione virtuale.

L’antica città di Ebla, in Siria, è giunta a noi solo a livello di fondamenta, perché la qualità delle strutture murarie e gli agenti atmosferici ne hanno distrutto la struttura originaria; grazie ad alcune iscrizioni antiche, ed all’aiuto di varie scienze, come l’ingegneria civile, che con calcoli complessi ha fornito le probabili dimensioni delle mura partendo dalle dimensioni e la forma delle fondamenta, è stato possibile costruirne un modello virtuale, che ha aiutato gli studiosi a stabilire le funzioni di vari edifici all’apparenza simili (fig. 1.10).

Gli scavi compiuti nella città di Ur, nella Mesopotamia orientale, hanno portato alla luce una vera e propria metropoli del 2000 a.C., che può essere apprezzata nella sua complessa struttura urbana, grazie ad un modello virtuale (fig. 1.11).

fig. 1.10 ricostruzione diEbla

fig. 1.11 struttura urbanadi Ur

Anche Roma è stata naturalmente oggetto di ricostruzioni virtuali, sia

nel suo complesso, che per edifici di particolare importanza (fig. 1.12). Dove queste rappresentazioni sono veramente servite, è stato per

edifici dal passato splendente, ma ormai distrutti; il netto contrasto tra la condizione attuale e la ricostruzione virtuale fa apprezzare l’importanza del nuovo mezzo tecnologico (fig. 1.13 e fig. 1.14); i marmi pavimentali e le decorazioni murarie danno sicuramente più l’idea della grandezza della città, rispetto a muri ormai sgretolati dal tempo.


14

fig. 1.12 la Via dei trionfi dell'anticaR

fig. 1.13 Calidarium nellacondizione attuale

fig. 1.14 ricostruzionevirtuale del Calidarium

Un luogo che ha fornito molte informazioni sulla vita quotidiana nel I sec. d.C. è Pompei; la tremenda eruzione del Vesuvio, che nel 79 d.C. distrusse la cittadina, ha in pratica fermato la vita su una istantanea, fornendo agli studiosi luoghi civili e sacri nel momento del loro utilizzo, quindi con arredi e decorazioni.


15

fig. 1.15 casa del Fauno aPompei

fig. 1.16 ricostruzionevirtuale della casa del

Fauno a Pompei

Nello sviluppare una ricostruzione virtuale, ci sono stati quindi molti

vantaggi. L’effetto ottenuto è ugualmente molto suggestivo: in particolare si

possono ammirare di nuovo intere costruzioni, ormai composte solo da mura perimetriche (fig. 1.15 e fig. 1.16), e vedere di nuovo le composizioni di splendide pareti decorate; a partire dal 1994, è disponibile una ricostruzione di buona parte della città, che permette sia la visita virtuale tra le strade principali, sia l’ingresso nelle case più importanti, nelle quali è possibile osservare gli arredi di un tempo.

L’operazione è stata compiuta grazie ad una tecnica detta “sistema stereo G”, che prevede l’utilizzo di riprese fotografiche stereoscopiche, digitalizzate ed integrate graficamente.

Una bella immagine “a volo d’uccello” mostra Pechino in epoca mongola (fig. 1.17), e fornisce chiare indicazioni sulla sua struttura a griglia, con le strade orientate sugli assi nord-sud ed est-ovest; nella rappresentazione è facilmente distinguibile la Città Proibita, il lago di Bohai, la zona urbana ed i campi coltivati.

Ci sono casi nei quali non è più possibile ricostruire fedelmente strutture ormai distrutte, perché l’evoluzione umana ha portato nuove costruzioni sulle vecchie, rendendo molto difficile stabilire la posizione e l’identità degli oggetti sottostanti.

Un esempio è Mexico-Tenochtitlán, che ormai è completamente sostituita dalla attuale Mexico, e dalle paludi circostanti.

Tecniche di composizione tra immagini reali e grafiche danno un’idea di dove si trovasse ad esempio il Templo Major (fig. 1.18).


16

fig. 1.17 Pechino in epoca mongola

fig. 1.18 Templo Major aMexico-Tenochtitlán

Fig. 1.19 Mexico-Tenochtitlán

Questa città, nota come la “Venezia americana”, sorgeva sulla laguna

di Mexico, era caratterizzata da immensi giardini galleggianti ed era collegata con la terraferma da tre grandi strade (fig. 1.19); la ricostruzione virtuale di tutto il sito permette una visione di insieme che ormai è stata persa.

Lo studio di una località presuppone la presenza di reperti, ma non sempre questi sono chiari ed inequivocabili come per un palazzo od una città; la presenza di resti umani od animali, o di piccole costruzioni in


17

legno, può significare che il sito era abitato, in forma di villaggio, o di accampamento.

La simulazione di un sito archeologico permette una visione di insieme, che può aiutare lo studioso, il quale può trarne informazioni importanti e modificare la sua campagna di scavo, indirizzandola nelle zone giuste.

fig. 1.20 accampamento mongolo

Una ricostruzione di un accampamento mongolo (fig. 1.20),

estremamente regolare nella disposizione delle costruzioni, mostra evidenti analogie con la Pechino contemporanea: comparazioni come queste possono aiutare gli studiosi nella datazione di siti anche distanti, ma riconducibili ad origini comuni, facilmente rilevabili da rappresentazioni tridimensionali.

Gli esempi visti sinora hanno descritto lo stretto rapporto tra archeologia e mondo virtuale, ma il contatto con la tecnologia non si ferma qui.

Tecniche utilizzate in altri campi si sono rivelate molto preziose nel settore della ricerca storica.

L’allestimento dei pezzi nei musei non è una cosa semplice, ed il museo del Louvre ha pensato di realizzare delle ricostruzioni virtuali di alcune sale, per studiare l’inserimento di alcuni elementi della decorazione dei palazzi di Susa (fig. 1.21); in questo modo i restauratori hanno potuto provare varie soluzioni e scegliere quella più idonea ai pezzi, tenendo conto della stanza, della luce e degli spazi a disposizione.


18

L’operazione ha richiesto sicuramente meno fatica dello spostare realmente più volte i pezzi, oppure studiare la cosa su carta, ed in definitiva ha dato risultati certamente migliori.

fig. 1.21 studio dell'allestimentodi una sala del Louvre

Nel settembre del 1991, sulle Alpi Venoste, nei pressi di Similaun, fu

trovato il corpo mummificato di un uomo di circa 5000 anni fa. In questo caso la scoperta ha permesso a varie di discipline di

confluire verso l’obiettivo comune di ricostruirne la storia, ed ancora una volta la tecnologia è stata di grande aiuto per l’archeologia; sono state condotte ricerche biologiche sui resti dei vestiti e su alcuni tessuti biologici; medici hanno potuto constatare la presenza di fratture o malattie in corso al momento della morte; esami radiologici e TAC hanno fornito indicazioni sugli organi interni, ancora ben conservati.

Si è avuto così un quadro abbastanza completo, peraltro tuttora in corso di realizzazione, grazie a questa nuovo approccio interdisciplinare all’archeologia. Grazie alla grafica è stato possibile, sfruttando i dati della TAC e di altri esami non intrusivi, fornire poi modelli virtuali del cranio, dell’ossatura, ed aiutare nell’elaborazione di varie ipotesi.


19

Un caso interessante per il contributo decisivo all’affermazione di una tesi archeologica è stato quello relativo alla tomba di Filippo II, padre di Alessandro Magno.

I dubbi sull’identità dei resti cremati, rinvenuti in una tomba presso il palazzo di Ege, in Macedonia, furono dissolti grazie ad esami medici, che confermarono le fratture sul cranio come avvenute in vita.

La tradizione dice che Filippo II perse l’occhio destro durante un assedio, e la ricostruzione di un calco del cranio, poi ricoperto di plastilina con una particolare tecnica che riproduce le fasce muscolari, ha permesso di ricostruire il volto del condottiero macedone, confermando la leggenda dell’occhio, ma soprattutto dissipando tutti i dubbi sull’identità del corpo rinvenuto.

L’informatizzazione dei dati ha permesso la datazione delle tavole degli archivi reali di Ebla, i quali, con scrittura cuneiforme, riportavano testi di carattere contabile, economico ed amministrativo, ma raramente una datazione interna.

L‘informatizzazione completa dei toponimi, dei nomi di migliaia di dignitari, dei nomi divini, ha permesso di stabilire in maniera sistematica una serie di relazioni, che hanno portato alla collocazione cronologica dei vari personaggi, e quindi dei carteggi, anche di quelli che non contengono alcun riferimento temporale.

1.4 Analisi dello stato attuale Tra tutti gli esempi visti, vi è un elemento in comune: la riproduzione

virtuale è utilizzata essenzialmente per opere del tutto o parzialmente distrutte.

Città ormai scomparse, palazzi crollati, templi ridotti ad un cumulo di colonne, tutto questo rinasce nella realtà virtuale, nel modello da consultare ed utilizzare: raramente sono riprodotti oggetti, manufatti, ancora esistenti, al solo scopo di renderli più visibili, più accessibili alla gran massa della gente.

Un museo non si preoccupa di riprodurre virtualmente un oggetto, lo espone, e questo basta.


20

Le opere riprodotte spesso si occupano di progetti famosi, di grande impatto culturale, e vi è la scarsa propensione ad occuparsi di manufatti: la riproduzione virtuale è preferita su grandi opere, e raramente si occupa del singolo oggetto, non inteso come arredamento della scena virtuale, ma come fonte autonoma di informazione, integrata nell’ambiente e con un suo valore archeologico e divulgativo.

Lo studio di un manufatto, della sua fabbricazione e del suo utilizzo, implica sicuramente lo studio della società che lo ha prodotto ed usato, del luogo nel quale è stato rinvenuto; diviene così un elemento di partenza per una ricerca più ampia.

Questo è un approccio che sicuramente l’archeologo tradizionale ha sempre sfruttato, e che è alla base delle sue ricerche.

Nella maggior parte dei casi attualmente gli storici sfruttano le tecnologie per rappresentare il risultato dei loro studi; sono ancora pochi i casi nei quali lo studioso parte da una base storica, ma lavora in parallelo con il tecnico o con lo scienziato che gli mette a disposizione nuove tecnologie come strumento di ricerca.

Grande collaborazione vi è stata nello scavo di Ebla, nello studio di Stonehenge, nella ricerca sull’uomo di Similaun, ed in pochi altri casi, ma è possibile osservare che quando ciò è avvenuto ha portato a svolte decisive nella campagna archeologica.

Le tecniche utilizzate per le ricostruzioni sono molto simili, e partono dalle planimetrie e dai dati reali, passando per gli alzati tridimensionali, fino a giungere a colorazioni aggiunte in base a fotografie o rilievi diretti.

Escono da questo schema, peraltro molto funzionale e di grande risultato, le ricerche più specifiche, quali la datazione delle tavole cuneiformi o la resa tridimensionale dei bassorilievi, che hanno implicato l’opera di matematici per sviluppare algoritmi di lavoro appositi.

E’ importante notare come la collaborazione interdisciplinare sia utile e redditizia in ogni fase del lavoro, dallo studio del territorio, all’interpretazione dei dati o la verifica di ipotesi, sino alla rappresentazione finale dei risultati.

Il fine ultimo è la divulgazione dei risultati, che in questo caso si presentano su un supporto informatico, in forma di modello, ma come è possibile consultarlo ?


21

Normalmente i modelli vengono utilizzati per mostrare varie visioni prospettiche del soggetto, elaborate con lunghi tempi e tecniche di alto rendering; la visione di un interno di un palazzo, con le sue decorazioni e le sue luci, implica lunghi tempi di calcolo, e di conseguenza viene preferita una rappresentazione fissa; oppure esistono forme di animazione guidata, con i singoli frame già calcolati con un ottima resa.

Attualmente è possibile viaggiare all’interno di alcuni modelli più semplici, magari di palazzi o città, dove la definizione è affidata alle texture sovrapposte alle pareti od agli oggetti; sono in commercio molti CDROM che permettono questo processo, ed anche su Internet vi sono siti con modelli in VRML visitabili con un adeguato programma.

Purtroppo la tecnologia attuale non permette ancora di muoversi in grossi ambienti virtuali con grandi effetti fotorealistici, ed è necessario trovare il giusto compromesso tra prestazioni e resa grafica.

Le tecniche di rappresentazione 3D non sono immediate, e richiedono computer ad elevate prestazioni, quindi è raro trovare archeologi che sfruttano in tempo reale e sul campo le ricostruzioni che via via ottengono dai reperti scavati.

Vi sono però molti archeologi che sfruttano le tecnologie all’avanguardia, per guidare il loro lavoro: fotogrammetrie dall’alto prima delle campagne di scavo, sensori di profondità per verificare la presenza di anfratti tra le mura, o scanner laser 3D per rilevare oggetti ritrovati.

Alcune tecnologie hanno permesso di sondare delle zone di deserto in modo non intrusivo, rivelando il luogo e la profondità di possibili siti archeologici sepolti.

La situazione attuale, come presentato, è in continua fase di evoluzione, con un rapporto sempre più stretto tra scienze interdisciplinari. Un tale approccio promette grandi sviluppi, sia nella fase di ricerca ed interpretazione, sia soprattutto nella fase divulgativa, settore ancora di pertinenza dei musei di tipo tradizionale.

CAPITOLO 2 I Musei Virtuali 2.1 Introduzione

L’avvento ed il recente sviluppo di tecnologie multimediali hanno portato alla nuova definizione di Museo Virtuale.

Questo concetto, analizzando le realizzazioni allo stato dell’arte, può prestarsi ad una duplice interpretazione:

i) replica simulata dello spazio fisico del Museo reale, intesa quindi come copia architettonica virtuale 3D del Museo esistente, nel quale vengono riprodotte le stesse entità, questa volta in modo simulato, visitabili nel Museo reale;

ii) nuova realizzazione di uno spazio 3D astratto, nel quale vengono sempre presentate le copie di opere note e conservate in musei reali.

In entrambe i tipi di Musei Virtuali la presentazione delle opere

all’utente dell’Ambiente Virtuale sfrutta soprattutto la modalità sensoriale visiva, cioè l’utente immerso nell’ambiente virtuale è in grado di muoversi all’interno di esso dove alcune opere, quindi quadri o sculture, gli vengono presentate secondo gli stessi criteri utilizzati per la disposizione in un museo reale.

Sia nel caso i) che nel ii) l’utente si muove in ambiente simulato e le opere risultano copie 2D (nel caso di quadri) o 3D (nel caso di sculture) delle opere reali. Per l’utente, cioè il visitatore del Museo Virtuale così

I Musei Virtuali

23

concepito, il meccanismo di fruizione dell’opera d’arte rimane praticamente inalterato rispetto al caso relativo al museo reale.

Un approccio di questo tipo non aggiunge niente quindi alle modalità di fruizione, anzi proprio in tali casi la “qualità” di presentazione dell’opera viene sminuita a causa degli inevitabili problemi legati al senso di presenza e di controllo sull’ambiente, caratteristici di un Ambiente Virtuale.

Unica nota di merito di un tale approccio riguarda la funzione simulata legata al fatto che, avendo una copia dell’opera d’arte a livello di simulazione, non è necessario recarsi nel museo reale per poterla osservare.

Si può notare come, secondo gli approcci proposti, il concetto di Museo Virtuale attualmente in uso non comporti l’utilizzo di nuovi paradigmi d’interazione con l’opera d’arte. Infatti le tecnologie multimediali, in particolare le tecniche di grafica al calcolatore, vengono sfruttate unicamente come strumento di “rappresentazione” dell’opera d’arte, non aggiungendo alcuna caratteristica ai meccanismi di fruizione utilizzati in un museo reale.

Ci si trova quindi ad avere un sottoutilizzo funzionale di queste tecnologie che, ancora una volta, tendono a sfruttare un nuovo media, cioè il calcolatore, per implementare lo stesso paradigma di interazione con l’opera d’arte già utilizzato nell’ambito del media convenzionale, il museo reale, che intendono sostituire.

Il concetto vero di Museo Virtuale dovrebbe invece muoversi verso la creazione, progettazione e realizzazione di nuovi sistemi informatici che consentano il pieno sfruttamento delle capacità tecniche del nuovo media sia in termini di rappresentazione/visualizzazione dell’opera d’arte, sia in termini di nuovi paradigmi di interazione che consentano di attivare meccanismi conoscitivi della stessa opera ancora oggi non concepiti.

Il presente lavoro di tesi si colloca in questo ambito di ricerca avendo come obiettivo la creazione di un nuovo paradigma di interazione visiva ed il conseguente sviluppo di un sistema di fruizione multimediale capace di implementarlo.

I Musei Virtuali

24

2.2 Considerazioni sui Musei Virtuali del prossimo futuro

Una caratteristica essenziale di un museo reale riguarda la capacità di sistemare le entità di interesse (che siano opere d’arte o reperti archeologici) secondo sequenze di visita opportunamente studiate. Ciò è testimoniato anche dall’osservazione, non casuale, della tipica disposizione nella quale si vengono a trovare i visitatori di un museo: di solito si possono infatti osservare delle “file” di persone che si muovono da una stanza all’altra.

La progettazione di un museo è sempre stata, proprio da un punto di vista architettonico, un compito legato allo studio della relazione che intercorre tra la disposizione di bacheche o stazioni che presentano gli oggetti di interesse ed un corretto ed efficiente sistema di circolazione dei visitatori.

In musei localizzati in palazzi o costruzioni antiche questo problema è stato risolto fondamentalmente sfruttando la sistemazione degli oggetti di interesse secondo disposizioni regolari, spesso simmetriche, che recuperino spazi come gallerie od ampie sale rettangolari nelle quali il visitatore può entrare e, seguendo un percorso stabilito di tipo perimetrale, eventualmente uscire dallo stesso punto di ingresso. Un esempio tipico, quale la Alte Pinakothek di Monaco, progettata da Leo von Klenze nel secolo scorso, viene riportato nella pagina seguente (fig. 2.1).

Esempi più recenti considerano invece percorsi diversi, quali ad esempio percorsi a traiettoria elicoidale posizionati attorno ad un ampio spazio interno: tipico esempio è il Guggheneim Museum di New York progettato da Frank Lloyd Wright, nel quale i visitatori salgono con un’ascensore sino all’ultimo piano e scendono a piedi per la visita lungo il percorso elicoidale.

Un compito del progettista e curatore del museo risulta quindi quello di ordinare in modo coerente e significativo il materiale espositivo secondo gli spazi appena descritti.

I Musei Virtuali

25

Fig. 2.1 la Alte Pinakothek di Monaco

I Musei Virtuali

26

I criteri che vengono seguiti per la disposizione possono riprendere sia aspetti di evoluzione temporale, che una sequenza di tipo “geografico”, sia la presentazione di diverse “scuole” artistiche, sia aspetti tassonomici specifici della scienza o disciplina considerata.

Se si va invece a considerare la progettazione di un Museo Virtuale, si vede come l’esigenza della progettazione di uno spazio 3D fisico in cui “sistemare” le varie opere vada a cadere.

L’esigenza di spazio fisico dove mostrare gli oggetti di interesse è ora sostituita dalla necessità di avere sempre maggiori “spazi” sul disco rigido del calcolatore, per la memorizzazione di modelli delle diverse opere, sia 2D come quadri, dipinti o fotografie, sia 3D come veri modelli di sculture.

Il materiale da esibire in un Museo Virtuale può essere mantenuto in un server appositamente installato in modo tale che più utenti, localizzati in luoghi geografici distinti, ne possano fruire anche contemporaneamente. Quindi il problema viene spostato dalla necessità di volume dello spazio reale della galleria alla capacità crescente delle memorie di massa dei server ed alla grandezza di banda della rete di comunicazione informatica.

Inoltre il problema dell’ordinazione e della presentazione del materiale espositivo viene spostato, per un Museo Virtuale, dalla progettazione di adeguate bacheche o spazi reali allo sviluppo di software adeguato, spesso con caratteristiche di elevato rendering grafico. In più ogni oggetto esposto può avere dei link, o relazioni di diversa tipologia e funzionalità, con altri oggetti o manufatti o opere d’arte, secondo criteri diversi.

Risulta quindi evidente come l’opportuno sfruttamento delle capacità multimediali offerte dal calcolatore consentano di implementare delle performance di presentazione e di esplorazione dell’opera d’arte che vanno ben al di là di quelle offerte da un museo reale.

I Musei Virtuali

27

2.3 Esempi di Musei Multimediali

La maggior parte degli esempi di Musei Virtuali attualmente reperibili é costituita da una visualizzazione digitale tramite la rete Internet di musei esistenti.

La possibilità di installare un proprio sito virtuale sulla rete è stata sfruttata come un mezzo per fornire agli utenti un’archivio fotografico degli oggetti conservati nel museo stesso, sia che si trattino di sculture, sia di opere pittoriche.

Un esempio in questo senso è dato dal sito sulla Cupola di Santa Maria in Fiore di Firenze (http://www.firenze.net/giudizio.universale), nel quale è possibile osservare l’intero ciclo pittorico del Giudizio Universale, completamente restaurato di recente.

Il visitatore del museo virtuale può accedere ad una serie di informazioni, che vanno dalla completa visione delle singole scene rappresentate nell’affresco, alle notizie relative il restauro; informazioni testuali sono disponibili in parallelo alle immagini e completano il quadro informativo; vi è la possibilità di scaricare dalla rete musiche sacre, associate dai curatori del sito alle singole scene rappresentate.

Il grande vantaggio di un museo di questo tipo è la possibilità che viene data a chi opera su un calcolatore, anche molto lontano da dove fisicamente si trova la Cupola, di vederne i capolavori contenuti; il difetto rimane quello di utilizzare tecnologie nuove per una presentazione già sfruttata, perché una serie di immagini possono essere disponibili anche su un catalogo, od un filmato, in questo caso cambia solo il supporto.

Un esempio significativo di Museo Virtuale che invece propone un sistema effettivamente nuovo di interagire con gli oggetti rappresentati è fornito dal “USC’s Interactive Art Museum at Fisher Gallery”, sviluppato presso la University of Southern California (http://digimuse.usc.edu/museum.html).

L’obiettivo principale del progetto è stato quello di sviluppare un museo interattivo sulla rete, nel quale il visitatore potesse vedere immagini 2D, ma potesse anche utilizzare un dispositivo robotico comandabile a distanza, provvisto di telecamera, che riprende oggetti

I Musei Virtuali

28

3D reali. In tempo reale è possibile comandare i movimenti del robot, e modificare la vista del soggetto, operando così una sorta di teleoperazione visiva.

La difficoltà di gestione del sistema non permette però l’uso contemporaneo di più utenti, e deve essere centrata su un solo oggetto: non è possibile quindi per il visitatore scegliere l’opera da osservare.

Il controllo dei movimenti della camera avviene tramite un semplice browser.

Il sistema presenta sicuramente dei limiti di utilizzo, ma è un tentativo per offrire un nuovo sistema di consultazione degli oggetti virtuali.

Alla Fisher Gallery vengono periodicamente predisposte delle esibizioni interattive sulla rete, incentrate su nuovi sistemi di comunicazione, gestione delle informazioni e della loro accessibilità al grande pubblico.

2.4 Obiettivi della tesi Dallo studio della situazione attuale riguardante i Musei Virtuali, si è

sentita la necessità di progettare un sistema di consultazione per oggetti virtuali, che permettesse all’utente di interagire con l’ambiente virtuale in modo nuovo.

La presentazione dei manufatti, in forma di modello virtuale 3D, e la loro accessibilità al visitatore deve essere sviluppata su un sistema che consenta una fruizione completa dell’opera d’arte.

Il manufatto deve essere rappresentato come modello 3D, per fornire un’idea precisa riguardante la sua forma, le sue dimensioni e per permettere al visitatore del Museo Virtuale di osservarlo da ogni prospettiva; le rappresentazioni tipiche dei Musei Virtuali analizzati sono normalmente in 2D, in forma di fotografia o riproduzione grafica, e questo è sicuramente molto limitativo; un oggetto tridimensionale permette invece un’osservazione completa.

Il visitatore deve sentirsi presente nell’ambiente virtuale, muoversi in esso, avendo però dei reali riscontri fisici, che lo aiutino nel movimento.

I Musei Virtuali

29

Le informazioni fornite devono essere precise e complete, quindi è di fondamentale importanza proporre un modello virtuale dell’opera più fedele possibile all’originale; la caratteristica multimediale del sistema implica la necessità di fornire l’utente della possibilità di accedere anche ad informazioni riguardanti il manufatto; occorre quindi completare l’informazione visiva con testi adeguati, mappe ed eventualmente completare la modellazione dell’ambiente virtuale con scenari legati al manufatto, creando così un’ambientazione completa.

La fruizione dell’opera diviene così un processo attivo, da parte del visitatore, il quale può decidere i tempi ed i modi di consultazione, osservare l’oggetto da prospettive prima difficilmente disponibili (per esempio, il retro di una grande statua posizionata lungo una parete in un museo tradizionale), ma contemporaneamente avere la sensazione di interazione spaziale con l’ambiente virtuale: un fattore importante si rivela perciò la necessità di realizzare un sistema, hardware e software, che permetta la consultazione e la navigazione nell’ambiente virtuale in tempo reale.

CAPITOLO 3

Il Calice 3.1 Calice egizio della Collezione Schiff Giorgini

L'oggetto della rappresentazione virtuale di questa tesi è un flute di vetro blu trasparente, della Collezione Schiff Giorgini, attualmente conservato al Museo Egittologico dell'Università di Pisa, in Via S.Frediano (fig. 3.1).

Il calice è alto 20,1 cm, ed è diviso in tre parti disinte: base, gambo e coppa.

La base presenta un diametro massimo di 6,4 cm, e tende a restringersi sino ad un minimo di 2 cm; il gambo, alto 1,09 cm ha una forma quasi cilindrica, con un diametro iniziale di 2 cm, ed in alto di 1,8 cm.

La coppa è alta 17,44 cm, e raggiunge un diametro massimo di 6,2 cm alla bocca del calice; partendo dal basso, la coppa comincia ad allargarsi, arrivando all’inizio delle decorazioni ad un diametro di 4,8 cm; la fascia centrale varia intorno ad un diametro di 2,7 cm, con molte irregolarità; ad una altezza di18,65 cm, è presente un piccolo bordino in rilievo, alto circa un millimetro, che gira tutto intorno al calice.

La decorazione é posizionata da un’altezza di 5,23 cm sino a 18,15, divisa in tre fascie rispettivamente di 2,4 cm, 8 cm e 2,4 cm.

Il Calice

31

fig. 3.1 calice della CollezioneSchiff Giorgini

3.2 Informazioni storiche

Dal 1963 al 1966, l'archeologa Michela Schiff Giorgini attuò una serie di campagne di scavo intorno alla zona di Sedeinga, in Sudan, tra la seconda e la terza cateratta del Nilo.

Furono rinvenuti siti molto importanti, quali il tempio di Tii, ed una vicina necropoli di età mereoitica, di grande ampiezza; poco distante, verso ovest, su un kom isolato furono scoperte altre nove tombe dello stesso periodo, ed è proprio da questo settore che proviene la quasi totalità della collezione Schiff Giorgini.

Il Calice

32

Nella tomba denominata WT8 furono trovati due calici gemelli di vetro blu trasparente, uno dei quali è quello in esame (fig. 3.2).

fig. 3.2 piantina della zona di Sedeinga

Questa tomba risale alla seconda metà del III sec. d.C., quindi alla fase

finale della necropoli. Accoglieva i resti di un uomo che, a giudicare dalla ricchezza e dalla

qualità del corredo funerario, doveva essere di rango molto elevato. Nella tomba sono stati ritrovati ben tremila frammenti di vetro, dai

quali si sono potuti ricostruire circa trenta recipienti di forme molto diverse.

L'intera raccolta, una delle più eccezionali collezioni di vetri antichi esistenti, fu trasferita al Museo di Khartoum, con l'unica eccezione del calice di vetro blu, che fu donato all'Università di Pisa.

Entrambi i calici gemelli sono stati ricostruiti completamente, da circa settanta frammenti, rinvenuti uno all'interno della tomba, e l'altro all'esterno, presso la porta d'ingresso .[LECLANT_73]

Il Calice

33

I posti diversi, ed il tipo di frattura, indicano che i calici furono infranti in modo violento, volontariamente, nel corso di particolari riti funebri che avvennero nella tomba al momento del seppellimento del defunto.

L'iscrizione, "Bevi e possa tu vivere", probabilmente rivolta al defunto, è in caratteri greci squadrati, e costituisce uno dei più antichi esempi, in un contesto sicuramente pagano, di questa formula, che troverà poi grandissima diffusione in ambito cristiano.

Il tipo particolare di lavorazione presuppone l'opera di maestranze molto qualificate, ed evidenziano forti influenze alessandrine, alle quali si affiancano innegabili componenti indigene e temi della più pura tradizione faraonica. 3.3 Collocazione attuale

Attualmente i due calici gemelli sono separati, l'uno al Museo di Khartoum, e l'altro al Museo Egittologico a Pisa, gestito dal Dipartimento di Scienze Storiche del Mondo Antico - Egittologia, nella persona della Prof.ssa Bresciani, che con la Dott.ssa Silvano ha costituito la componente archeologica fondamentale per questo progetto.(fig. 3.3)

fig. 3.3 calice nella teca del Museo

Il Calice

34

Recentemente, in una lunga mostra sul mondo arabo, intitolata “Sudan, Royaumes sur le Nil”, tenutasi presso l’Institut du MondeArabe a Parigi, sono stati riuniti i due calici, per un diretto confronto. 3.4 Le decorazioni

Il calice presenta un'originale decorazione dipinta, a smalto e con foglia d'oro applicata, la quale si svolge su tre registri, separati da motivi geometrici.

Il primo registro è posto in alto, direttamente sotto un piccolo bordino in rilievo, e mostra un'iscrizione in lettere greche squadrate "Bevi e possa tu vivere" ("ΠIE ZHCEN") (fig. 3.4).

fig. 3.4 primo registro

Il registro principale raffigura una scena sacra, dove il dio Osiri,

seduto su un trono è in atto di ricevere i doni da tre offerenti, una donna e due uomini (fig. 3.5).

Il dio si trova su un trono dorato con un basso schienale decorato con motivo a linee incrociate; porta sul capo una corona atef e stringe tra le

mani le sue insegne tradizionali: il flagello neheh e lo scettro heqa (fig. 3.6).

Il Calice

35

fig. 3.5 scena totale del registro principale

Al collo porta un largo collare ed ha il corpo avvolto in una guaina dorata, segnata sul torso da losanghe ottenute con linee rosso chiaro e nella parte inferiore da quadrati punteggiati, indicati in rosso più scuro.

Davanti al dio avanza una figura femminile, abbigliata con una lunga veste aderente; il viso, le braccia e le gambe sono di colore verde (fig. 3.7) e porta sul capo un'ampia parrucca, sormontata da un disco contornato da un cerchio ed al collo una larga collana rossa punteggiata di giallo.

Con la mano sinistra trattiene per le corna un'antilope, che alza le zampe anteriori; con la mano destra sorregge un vassoio sul quale poggiano due mazzi di fiori ed una piccola figurina inginocchiata con la mano alzata in gesto di saluto o di adorazione.

Di seguito si trova un personaggio maschile, anch'esso ha sul capo una calotta sormontata da un disco contornato di giallo; indossa una larga collana rossa punteggiata di giallo e sopra il corpo dorato indossa un corsetto verde ed un gonnellino nero, bianco e rosso.(fig. 3.8)

Il braccio destro è teso in avanti e tiene in evidenza un vaso da libagione-hes ; con il braccio sinistro trascina un cervo, stringendolo per le zampe anteriori.

L'ultimo degli offerenti è ancora un personaggio maschile che porta sulle spalle un'antilope dipinta in bianco (fig. 3.9). La parte superiore del corpo, le braccia e le gambe della figura sono nude e dorate; anche lui ha il capo coperto da una calotta sormontata da un disco contornato da un cerchio ed al collo porta un largo collare composto da due fasce rosse

Il Calice

36

punteggiate di bianco. Il torso è coperto da un corsetto verde ed una cintura dorata sostiene un gonnellino rosso, nero e bianco.

Nella mano sinistra porta tre oche tenendole per la punta della coda, usando un laccio, mentre i volatili tentano di sfuggirgli di mano.

fig. 3.6 dio Osiri fig. 3.7 primo offerente

Il terzo registro, costituito da una serie di fiori a quattro petali, chiude

in basso il campo decorativo (fig. 3.10).[BRESCIANI_92] Gli esami effettuati hanno dimostrato che furono adoperati per la

decorazione sette colori base (giallo, bianco, rosso opaco, grigio, marrone, nero e verde chiaro) dei quali almeno cinque, sottoposti ad una seconda cottura, assunsero l'aspetto di veri e propri smalti.

Il Calice

37

fig. 3.8 secondo offerente fig. 3.9 terzo offerente

fig. 3.10 terzo registro di decorazione

Dopo avere tracciato i contorni sia delle figure che delle fasce

decorative con il giallo opaco ed il grigio, si procedette all'applicazione della foglia d'oro nelle figure, nelle lettere e nelle due fasce che delimitavano il registro principale della decorazione; in seguito furono aggiunti gli altri colori, ultimo tra tutti il nero che con ogni probabilità non è stato sottoposto a cottura.

Il Calice

38

Per quanto riguarda il colore verde, certo fu aggiunto nella fase finale, semplicemente dipinto, probabilmente come correttore.

Naturalmente la sequenza cromatica non è assoluta, perché in certi casi l'artista , a seconda delle necessità che gli si presentavano via via nel corso della composizione, tornava ad utilizzare un colore che aveva già applicato in precedenza.[BRILL_91]

3.5 Modellazione grafica 3D

3.5.1 Descrizione del software utilizzato Per la modellazione del calice, sono stati utilizzati programmi della

Alias|Wavefront, quali PowerAnimator 8.5 e StudioPaint3D 4.0. PowerAnimator è un potente programma di modellazione e

rendering, che permette la modellazione tramite NURBS o poligoni di nuovi oggetti, esportandoli poi nel formato più idoneo per l’uso che ne deve essere fatto.

Vi è la possibilità di definire le luci più adatte all'ambiente simulato, e di associare le texture più varie ai singoli oggetti.

Un’ottima caratteristica del programma è relativa alla definizione di texture complesse, con proiezioni di immagini, creazione di frattali, mappature di rumore, e possibilità di utilizzare bump-mapping, tecnica che in fase di rendering fornisce l'illusione di un rilievo guidato dalla mappa inserita.

In PowerAnimator esiste anche una tecnica più avanzata, detta displacement, la quale produce, sempre in fase di rendering, una reale modifica della mesh di superficie, creando rilievi anche complessi.[ALIAS2_98]

Una fase importante di ogni ricreazione di ambiente virtuale è il rendering; le due principali tecniche offerte da PowerAnimator sono il ray cast ed il ray trace.

Il ray cast offre sfumature più morbide nelle scene con ombre, ma non fornisce una resa totalmente realistica, come invece il ray trace, che

Il Calice

39

sfrutta algoritmi per la riflessione e la rifrazione dei raggi luminosi, ma richiede tempi di calcolo molto lunghi.

Un grosso aiuto nella creazione delle texture viene fornito da StudioPaint3D, che gestisce immagini grafiche bidimensionali, applicabili a modelli 3D.

I due programmi interagiscono perfettamente, ed è possibile importare un modello 3D di PowerAnimator in StudioPaint3D, e poi modificare le texture dipingendo direttamente sul modello, oppure estraendole e per poi modificarle a parte.

Il sistema utilizzato per la gestione delle texture prevede la divisione in varie mappe, ognuna relativa ad una caratteristica del materiale, quali colore, trasparenza, bump o displacement, incandescenza o capacità di riflessione, e queste possono essere modificate separatamente ed applicate poi ai vari canali, ottenendo così effetti molto precisi.

3.5.2 Sviluppo del modello 3D L'oggetto da ricostruire ha una forma simmetrica rispetto all’asse

verticale. E' stato deciso di costruire il modello non come un unico solido di

rivoluzione, ma come composizione di solidi, per motivi sia di realismo sia di miglioramento delle prestazioni.

Il calice non ha una forma perfetta, ma è deformato in vari punti. La base presenta delle piccole prominenze, e non è perfettamente

simmetrica, come non lo è il gambo, che esce dall'asse centrale. Il corpo risente poi della ricostruzione dai frammenti, e di una

dissimetria di fabbricazione, e quindi pende da un lato, inoltre il raggio della coppa varia lungo l'asse.

Suddividendo il calice in vari pezzi, è stato possibile correggerli uno ad uno, avvicinandosi il più possibile alla forma reale del calice.

Le diverse decorazioni, sui vari registri, ed i diversi gradi di trasparenza nei singoli pezzi, hanno contribuito a scegliere questa strategia di ricostruzione.

Il calice è stato così diviso in otto parti: base, gambo, parte bassa, decorazione bassa, decorazione centrale, decorazione alta, parte alta, ed interno (fig. 3.11).

Il Calice

40

fig. 3.11 Calice separato in vari pezzi

Base e gambo presentano imperfezioni di forma, ed una trasparenza

molto più bassa del resto del calice. Le tre zone con la decorazione permettono di gestire le texture in

maniera autonoma dalla colorazione generale. La parte alta è stata isolata perché presenta superfici con angoli molto

acuti, ed un rilievo circolare sottile, quindi era preferibile averla da sola, anche in previsione di modificare tutte le superfici in poligoni, e poterne dedicare un numero maggiore dove serviva.

La strategia di modellazione ha risentito molto dell'obiettivo finale, che era quello di rappresentare il modello in tempo reale.

Tutte le tecniche di rendering di alta qualità, offerte da PowerAnimator, non servono in queste applicazioni, perché richiedono tempi improponibili (alla fine del progetto erano necessari circa 45 minuti per ottenere un’immagine dell’oggetto con un rendering in raytrace); la soluzione adottata è stata quella di utilizzare le librerie VRLib in fase di sviluppo nel laboratorio, che sfruttano le OpenGL.

Per il formato nel quale caricare il modello, è stato scelto l'RTG, fornito da PowerAnimator, ed utilizzato per l'animazione di modelli 3D nei giochi.

Il Calice

41

Questo permette di trasformare un modello NURBS in poligonale, oppure salvare il modello già poligonale, inserendo tra le informazioni le coordinate delle texture associate ai vari oggetti, il colore dei materiali e quello dei vertici; infatti una funzione, detta prelight, permette di valutare il colore di ciascun vertice di un modello poligonale, in base alle fonti di luce nell'ambiente.

Proprio questa possibilità ha aiutato ad aumentare le prestazioni dell'applicazione, perché è stato possibile salvare tutto in prelight, ed evitare di mettere le luci: essendo la scena da visitare fissa, e muovendosi solo l'utente, l'illuminazione degli oggetti non cambia, ed è quindi possibile usare quella calcolata con il prelight.

Un grosso problema che si è presentato è stato quello di ottenere delle misure precise per la ricostruzione del modello.

Inizialmente è stata valutata la possibilità di ottenere la forma del calice tramite una operazione di fotogrammetria: questa consiste nel ricomporre via software immagini 3D, sfruttando i dati forniti da varie fotografie del soggetto da varie angolazioni.

Questa tecnica è normalmente utilizzata per ottenere mappe morfologiche del terreno, da fotografie aeree o satellitari.

Questa soluzione non era però adatta al calice, perché le ridotte dimensioni dell’oggetto rendevano molto difficoltoso trovare dei punti di riferimento sulle immagini, fondamentali per una corretta ricostruzione.

Un secondo tentativo è stato fatto utilizzando la TAC (Tomografia Assiale Computerizzata), che è un esame tipicamente medico, non intrusivo, e che sfrutta i raggi X per ottenere, anche in questo caso via software, un’immagine tridimensionale della zona del corpo analizzata.

Il problema principale, in questo caso, è costituito dalla bassa risoluzione del modello ottenibile, in quanto la TAC è un esame destinato a soggetti umani, mediamente alti almeno un metro e settanta, quindi è sufficiente una definizione dell’ordine dei 2-3 mm, troppo grande per un oggetto alto circa venti centimetri.

Una soluzione sicuramente buona poteva essere l’uso di uno scanner laser, che girasse intorno al calice, fornendo poi un modello dettagliato, anche nel valore degli spessori delle decorazioni esterne; essendo il calice di grande valore e di difficile e costoso trasporto, questa soluzione

Il Calice

42

è stata attualmente scartata, ma non esclusa per un possibile miglioramento futuro del modello.

Le misure sono state quindi prese da fotografie scattate direttamente al calice, nella sala del Museo.

È importante notare che tutte queste metodologie per ottenere il modello, non escludevano comunque la necessità di fotografare il calice per ottenere il colore delle decorazioni, in quanto gli eventuali modelli ottenibili con fotogrammetria, scanner laser o TAC, sarebbero comunque stati colorati in scala di grigio, senza indicazioni sui colori.

Le foto sono state scattate in asse con il calice, ed una ogni 45 gradi, ottenendo così otto fotografie nitide del soggetto; per ogni posizione sono state scattate tre foto, una in alto, una nel mezzo ed una in basso, per ottenere poi una composizione più precisa delle decorazioni.

Dalle foto si è passati a lucidi con i profili da varie angolazioni, sui quali è stato possibile ricavare le misure necessarie per correggere la prima bozza del modello (fig. 3.12).

Inizialmente è stato fatto un modello, in base ai dati raccolti, e poi le tecniche di manipolazione delle superfici di PowerAnimator hanno permesso le giuste correzioni.

La base è stata costruita come solido di rivoluzione: tracciata una adeguata curva nello spazio, è stata fatta ruotare intorno all'asse, ottenendo il solido; la correzione è avvenuta spostando singolarmente dei punti della superficie, nelle zone interessate.[ALIAS1_98]

Il gambo è molto irregolare, quindi è stato preferito costruirlo con una tecnica più complessa e precisa: seguendo le indicazioni fornite dai dati raccolti, sono stati costruiti alcuni cerchi, a varie altezze lungo l’asse, i quali sono stati poi spostati dall’asse centrale per ricreare la forma irregolare; il solido che costituisce il gambo è stato costruito creando una superficie che passasse da tutti i cerchi, unendoli in un unico blocco; il solido così ottenuto è stato poi spostato leggermente ed inclinato, per raggiungere la conformazione reale (fig. 3.13).

Tutti gli altri pezzi sono stati costruiti con solidi di rivoluzione derivanti da una adeguata curva, e tutti combacianti, per formare un'apparente unico oggetto (fig. 3.14, 15, 16, 17).

Il Calice

43

Fig. 3.12 lucido con le misurazioni

Il Calice

44

fig. 3.13 wireframe di base e gambo

fig. 3.14 curve di rivoluzione

Il Calice

45

fig. 3.15 wireframe della parte alta

Per una facile gestione del tutto, i singoli pezzi sono stati legati tra

loro, per i movimenti o gli ingrandimenti. Una volta finito l’oggetto in NURBS, è stato necessario convertirlo in

poligonale, per poi salvarlo nel formato scelto, l’RTG.[ALIAS4_98] Questo è un formato studiato dalla Alias|Wavefront in particolar

modo per la programmazione e la modellazione di oggetti destinati ai giochi; il file che si ottiene è in formato ASCII, quindi facilmente modificabile, e semplice da gestire da un aventuale programma che vuole importarlo. Descrive la geometria degli oggetti come una successione di poligoni, specificando le coordinate dei vertici e quelle della mappatura della texture; è possibile anche inserire varie mappature di texture, sia per il colore, sia per la trasparenza, sia per ogni altro canale dei valori caratteristici del materiale di base dell’oggetto, quali diffusione, riflessione o lucentezza.

È stato possibile, agendo su determinati valori, che permettono di scegliere la densità della maglia di vertici, trasformare le singole superfici NURBS in una serie di poligoni.

Dovendo lavorare in real time, era necessario limitare il numero di poligoni allo stretto necessario, per non appesantire il sistema; la divisione in pezzi è tornata utile per destinare grosse quantità di vertici

Il Calice

46

nelle zone più complesse, come la parte alta, e meno poligoni in parti più regolari, come la fascia centrale esterna, che è quasi un cilindro.

La scelta del numero definitivo di poligoni componenti il calice è stata fatta dopo aver provato alcuni modelli nell’ambiente virtuale, valutando il framerate ottenuto durante la loro visualizzazione: è stato aperta sullo schermo una finestra per OpenGL di 800x600 pixel, del tutto simile a quella poi utilizzata nell’applicazione finale, nella quale sono stati visualizzati i singoli modelli, caricandovi le texture, e sono stati poi fatti ruotare automaticamente in maniera ciclica; una funzione inserita internamente forniva in tempo reale il framerate al quale il modello si muoveva.

Le prove sono state compiute su una workstation SiliconGraphics Indigo2 R10000 HighImpact, con 64 Mbytes di RAM.

I parametri di velocità raccolti sono esposti nella seguente tabella: n° poly definizione framerate ----------------------------------------------------- 1106 molto scarsa 86 (frame/secondo) 2078 scarsa 72 3997 buona 36,5 6284 molto buona 18,1 8248 ottima 10,5 L’oggetto finale è composto da 3997 poligoni, così ripartiti: base 912, gambo 304, parte bassa 336, decorazione bassa 224, decorazione centrale 192, decorazione alta 192, parte alta 1316, parte interna 521. Nello scegliere il numero finale di poligoni è stato tenuto conto anche

del fatto che il valore registrato come framerate, nelle prove sopra descritte, non era quello definitivo dell’applicazione, perché oltre al

Il Calice

47

calice sarebbero stati rappresentati anche altri oggetti, costituenti l’ambiente virtuale nel quale è inserito l’oggetto, e quindi il valore di framerate sarebbe sicuramente sceso: l’indicazione della prova è stata tuttavia molto significativa, perché il calice costituisce circa il novanta per cento dei poligoni rappresentati durante la visualizzazione virtuale.

Il calice non è stato quindi l’unico oggetto creato, perché è stato necessario rappresentare anche un piedistallo sul quale poggiarlo, ed una lastra per una visione planare delle decorazioni.

Il piedistallo è stato composto con 240 poligoni, sufficienti per una buona rappresentazione, ma non troppi da rallentare il sistema, essendo un elemento sempre presente nella visualizzazione.

L’applicazione permette la visione di una lastra rettangolare sulla quale sono sviluppati i tre registri decorativi, per avere un’idea d’insieme; per questa sono state usate le stesse texture, ma applicate ad un parallelepipedo di 304 poligoni.

fig. 3.16 calice: in wireframe e poligonale

Il Calice

48

fig. 3.17 l’interfaccia grafica di PowerAnimator

3.5.3 Sviluppo delle texture La realizzazione delle texture si è svolta in due fasi, una generale per

tutto il calice su PowerAnimator, ed una più dettagliata per le decorazioni con StudioPaint3D.

Il primo passo è stato quello di stabilire dei valori di colorazione di fondo e trasparenza che rendessero la ricostruzione del calice più vicina possibile alla realtà.

Il colore è stato valutato analizzando le fotografie fatte al calice, inserendole sul calcolatore tramite uno scanner, e misurando i valori cromatici RGB (Red Green Blue) che corrispondevano al colore blu di fondo; questo valore è stato utilizzato come base di partenza, perché era importante valutare l’effetto combinato dei colori dei materiali e delle fonti di luce dirette sull’oggetto. Questa verifica è stata fatta

Il Calice

49

visualizzando il calice nella finestra finale openGL, dalla quale era possibile avere un riscontro oggettivo della resa finale: la visualizzazione tramite rendering automatico di PowerAnimator avrebbe fornito sicuramente un effetto più realistico, ma non corrispondente a quello dell’applicazione finale, perché vi sono utilizzate tecniche di rendering più sofisticate, non applicabili durante una rappresentazione in tempo reale.

La determinazione del valore della trasparenza è stata raggiunta controllando la rappresentazione del calice, combinato con un oggetto virtuale di riferimento: è stato rappresentato un cilindro di colore scuro, posizionato all’interno della coppa del calice, e, tramite varie visualizzazioni di rendering, sono stati provati alcuni valori per la trasparenza, il quale viene controllato tramite un quarto numero, detto alpha, che viene aggiunto alla terna RGB, e che varia su una scala da zero (oggetto totalmente opaco) ad uno (completa trasparenza) (fig. 3.18).

fig. 3.18 controllo della trasparenza della coppa

Per stabilire il corretto valore della trasparenza della base del calice, è

stata applicata un'immagine sul ripiano del piedistallo che lo sostiene, in modo da poter vedere attraverso l’oggetto; anche in questo caso sono state fatte alcune prove, che hanno portato ai valori finali (fig. 3.19).

Il Calice

50

I valori scelti sono diversi per le varie parti del calice, perché la densità reale nelle varie zone provoca differenti gradi di trasparenza: per quanto riguarda la base ed il gambo è stato applicato un valore di alpha pari a 0.1; per tutta la parte relativa alla coppa, alpha è uguale a 0.25.

fig. 3.19 controllo della trasparenza della base

Un discorso a parte meritano le decorazioni, nelle quali la trasparenza

doveva essere resa solo nelle zone senza pittura, quindi in maniera molto articolata; questo è stato possibile creando una copia delle texture, in scala di grigio, che mappasse esattamente il grado di trasparenza punto per punto, lungo tutte le decorazioni; come accennato in precedenza, il formato RTG prevede la possibilità di modulare la trasparenza tramite un file, che viene caricato, ed i suoi valori vengono associati ai vertici della mappa della texture come alpha (fig. 3.20).

Una volta stabiliti questi valori generali, era indispensabile creare le decorazioni, le quali hanno reso necessario l'uso di StudioPaint3D.

Sono stati importati i singoli pezzi modellati in 3D, e da quelli sono state estratte le texture, completamente omogenee, del colore di base; su queste sono state ricostruite le decorazioni, estraendole dalle foto, dopo averle manipolate.

Il Calice

51

fig. 3.20 le tre mappe per la trasparenza

Una fotografia di un cilindro chiaramente distorce le immagini che vi

sono rappresentate, e quindi solo una piccola parte centrale delle foto era utilizzabile.

Con una tecnica, detta di warp, è stato possibile tagliare una fetta centrale maggiore, e poi "stirarla" per punti, per recuperare la distorsione.

Tutto questo è stato fatto a mano e con molte ore di lavoro, arrivando a comporre le decorazioni, le quali sono state ritoccate per eliminare le fratture tra i vari pezzi.(fig. 3.21)

Nello sviluppare le varie decorazioni, è stato tenuto conto delle reali fasi di fabbricazione del calice, e sono state ricreate le texture adatte a rappresentarle, con l'ordine dei colori specificato dagli studi sulle tinte.

Il Calice

52

Un grosso problema che si è presentato è stato quello di rimappare le texture sui poligoni.

fig. 3.21 le tre texture delle decorazioni

Nella definizione delle texture su di tipo NURBS è possibile operare una proiezione della texture sulla superficie dell’oggetto; nel caso del calice è stata adoperata una proiezione cilindrica, che permettesse un completo ed omogeneo sviluppo dell’immagine intorno ai singoli pezzi, tutti di forma quasi cilindrica.

Al momento di passare ai poligoni, la mappatura della texture non corrisponde più, per la diversa conformazione dell’oggetto; è necessario quindi creare una mappa direttamente sull’oggetto poligonale.

Ogni superficie NURBS ha delle coordinate, dette U e V, che ne identificano ogni punto, e che sono usate anche per la mappatura delle texture; negli oggetti poligonali, questa parametrizzazione non esiste, ed il posizionamento della texture avviene quasi casualmente.

Il Calice

53

La soluzione adottata è stata quella di rimappare completamente le coordinate delle texture sui vertici dei poligoni.[ALIAS3_98]

Innanzi tutto sono state rimosse tutte le coordinate delle texture presenti, per non rischiare problemi di sovrapposizione ed errore.

Utilizzando come sorgente la stessa proiezione usata con la NURBS, sono state ricalcolate automaticamente le coordinate UV, adeguandole ai poligoni; per limitare l’effetto di frattura della texture avvolta sul cilindro, sono state normalizzate le coordinate, da (0,0) a (1,1), e operato un effetto di filtro sugli spigoli tra i vertici.

Questa operazione è stata fatta sui tre pezzi del calice con le decorazioni, agendo più o meno nello stesso modo.

Sulla lastra planare, non è stato necessario operare la nuova mappatura, perché la proiezione delle texture è stata planare, senza alcuna proiezione correttiva, sia sulle NURBS, sia soprattutto sui poligoni.

3.5.4 Rendering della scena

Come è stato già detto, la necessità di lavorare in tempo reale ha

portato alla scelta del formato RTG, per il modello 3D, quindi il rendering della scena dipende solo dalla piattaforma OpenGL, e dalle prestazioni tecniche dell'hardware utilizzato.

Per quanto riguarda le texture, è stato scelto di fornirle nel formato ppm, perché risulta un buon compromesso tra una dimensione non eccessiva ed un buon mantenimento della definizione dell'immagine.

Seguono alcune immagini del calice, elaborate con il rendering ray trace, per dare un'idea dell'oggetto.

Il Calice

54

fig. 3.22 ray trace del calice

fig. 3.23 ray trace della visione planare

55

CAPITOLO 4 Sistemi di Rappresentazione e Navigazione in Ambienti Virtuali 4.1 Introduzione

Il concetto di Ambiente Virtuale va inteso essenzialmente come un ambiente riprodotto graficamente in tre dimensioni, nel quale l’utente abbia la possibilità di interagire totalmente con il mondo che lo circonda: può muoversi lungo ogni direzione, ed osservare l’ambiente da ogni prospettiva e può interagire fisicamente con gli oggetti virtuali, toccandoli e maneggiandoli come farebbe nell’ambiente reale.

È necessario quindi fornire all’utente un alto livello di senso di presenza, all’interno dell’ambiente virtuale.

Il senso di presenza può essere visto come il risultato di tre fattori indipendenti: la quantità d’informazioni fornite dall’ambiente (per esempio, il numero di sensori, o la quantità di dati che ogni sensore fornisce all’osservatore), controllo sul movimento dei sensori nell’ambiente (per esempio, la possibilità per l’osservatore di modificare il suo punto di vista) e possibilità di modificare l’ambiente (per esempio, la possibilità di spostare gli oggetti nell’ambiente virtuale). [SHERIDAN_92]

Questi determinanti possono essere rappresentati su tre assi ortogonali (fig. 1.1) ed essere valutati indipendentemente in relazione al sistema analizzato; è possibile individuare un punto di “presenza

Sistemi di Rappresentazione e Navigazione in Ambienti Virtuali

56

perfetta” nello spazio 3D del grafico, identificato dai massimi valori per i tre determinanti.

Il raggiungimento del valore massimo è molto difficile, perché nonostante si possa aumentare al massimo la quantità di informazioni sull’ambiente, difficilmente si riesce a raggiungere un perfetto controllo sia degli oggetti sia del movimento nell’ambiente; le linee di flusso di informazione costante indicano che è sempre maggiore il numero di informazioni ottenute rispetto al grado di controllo.

Fig. 4.1 determinanti di Sheridan

Da questa valutazione, risulta evidente, perché la sensazione di

presenza sia sufficiente, la necessità di potersi muovere liberamente nello spazio virtuale, ma anhe di poter modificare il proprio punto di vista rispetto all’oggetto di interesse.

Dobbiamo quindi considerare nello spazio virtuale tre sistemi di riferimento strettamente collegati tra di loro: uno assoluto dell’ambiente, uno relativo dell’oggetto ed uno relativo dell’osservatore (fig. 4.2).

Consideriamo un sistema di riferimento assoluto Oο_xο.yο.zο associato all’ambiente, e nel quale sono posizionati e si muovono


57

l’oggetto e l’osservatore; definiamo anche un sistema di riferimento Oa_xa.ya.za legato all’oggetto ed uno O_x.y.z legato all’utente, che vuole muoversi ed osservare l’oggetto.

Fig. 4.2 sistemi di riferimentonell’ambiente virtuale

La funzionalità legata ai singoli sistemi di riferimento varia a seconda

del tipo di interazione cercata tra utente ed oggetto: se è ricercato il contatto fisico, il sistema O_x.y.z sarà associato alla mano dell’utente, e la realzione tra i due riferimenti comporterà un ritorno di informazioni verso l’utente di tipo tattile o di ritorno di forza; nel caso di esplorazione visiva dell’ambiente virtuale, il sistema O_x.y.z è in realtà il punto di vista dell’osservatore, che varia a seconda delle indicazioni fornite dai sensori, relative alla posizione rispetto a Oa_xa.ya.za, ed alla sua inclinazione.

È necessario allora stabilire delle leggi che regolino il movimento relativo di un sistema rispetto all’altro, e le modalità tecniche che le implementano: in questo modo possiamo garantire il buon funzionamento del sistema che permetta all’utente di osservare un oggetto in un ambiente virtuale.


58

4.2 Percorsi guidati

Oltre all’indispensabile fase di ricostruzione e presentazione di un ambiente virtuale, nella progettazione di un sistema di interazione con l’ambiente virtuale, che determina il tipo di applicazione: la tecnica di navigazione.

Come viene offerta la possibilità all'utente di viaggiare in questo nuovo mondo ? in che direzioni ? con che velocità e libertà di movimento?

Vi sono chiaramente molte strategie per risolvere questo problema, ed ognuna è dedicata ad un preciso utilizzo della ricostruzione virtuale.

Molte applicazioni comuni permettono al visitatore una navigazione controllata, perché sono improntate maggiormente sulla divulgazione dell'opera ricostruita, e quindi hanno bisogno di fornire immagini ad alto rendering.

Molti siti Internet permettono una visita di ambienti in VRML, attraverso browser, ma costringono il visitatore a muoversi attraverso un predefinito cammino di stanze e rappresentazioni.

Sulla rete è possibile trovare molti "musei virtuali", che però si limitano a fornire una planimetria del museo, permettendo di vedere alcune foto delle opere conservate al loro interno.

In questi casi non si può parlare di navigazione, né tanto meno di realtà virtuale, ma solo di musei digitali.

All'estremo di questa strategia di navigazione guidata, troviamo le animazioni virtuali, alle quali lo spettatore assiste passivo, senza poter intervenire né sui tempi di movimento né sulla prospettiva dalla quale è osservata la scena.

La definizione di questo tipo di ricostruzioni è altissima, essendo realizzate in postproduzione, ed ottenendo la massima resa realistica di ogni frame dell'animazione, magari impiegandoci giorni.

Per il film "Toy Story", il tempo medio di calcolo per ciascun fotogramma è stato di circa tre ore, per alcuni particolarmente complessi anche ventiquattro ore, ed il tutto con piattaforme SiliconGraphics ad altissime prestazioni.[DELORENZO_96]


59

Si capisce facilmente come una modifica dell'immagine virtuale in tempo reale, non sia possibile ottenerla nelle applicazioni real time con lo stesso grado di definizione.

4.3 Navigazione libera

I sistemi che permettono una navigazione più libera all'interno dell'ambiente virtuale, possono essere distinti in due classi: da una parte quelli che comunque fanno riferimento a rappresentazioni bidimensionali su normali monitor della ricostruzione, e quelli cosiddetti ad immersione, che forniscono una visione tridimensionale degli oggetti virtuali.

Le rappresentazioni su normali monitor sono esplorate grazie a programmi dedicati, i browser, che forniscono i comandi per muovere la telecamera virtuale nell'ambiente rappresentato.

Un esempio ne è il sito della Learning Sites Inc. (www.learningsites.com), nel qual è possibile vedere la ricostruzione della Vari House, antica costruzione del sud-est della Grecia, presso il mare Egeo.[ROEHL_97]

Su molti CDROM è possibile visitare siti archeologici completamente ricostruiti virtualmente, quali il tempio azteco di Tenochtitlán, la piana di Giza con le grandi Piramidi, o le città di Roma antica e Pompei.[FORTE_96]

La totale libertà di navigazione negli ambienti virtuali si ha però con i sistemi ad immersione, che modificano totalmente l'ambiente intorno al visitatore.

La ditta Infobyte di Roma, specializzata in realtà virtuale, ha ricostruito la basilica di San Francesco ad Assisi, con la sua architettura e gli affreschi di Giotto; tutto questo è ambientato con un apparecchio, il BOOM3C della Fakespace, che è un tipico esempio dei sistemi ad immersione HSC (fig. 4.1).[ROEHL_97]


60

4.4 Sistemi d’immersione 4.4.1 Introduzione

Le attuali tecnologie permettono di avere una visione completamente nuova di un modello grafico 3D; è possibile dare una forma spaziale all'oggetto, fornendo un'immagine tridimensionale nello spazio davanti all'osservatore, e ricostruire anche tutto l'ambiente intorno a lui, immergendolo completamente in un mondo virtuale.

Questi sistemi sono detti immersivi. Ci sono quattro principali configurazioni di sistemi immersivi: Head

Mounted Display (HMD), Head Coupled System (HCS), Spatially Immersive Display (SIDs) e Virtual Model Display (VMDs).[WALTZ_97] 4.4.2 Head Mounted Display

Il sistema a Head Mounted Display è stato ideato per raggiungere il

massimo livello di immersione nella scena virtuale, perché l'utente vede il mondo intorno a se solo attraverso questo mezzo, e non ha alcuna percezione visiva del mondo reale che lo circonda.

L'immagine virtuale viene mandata ai due piccoli schermi presenti all'interno, ed allineati con gli occhi, con una tecnica detta stereoscopica, che tiene cioè conto della distanza oculare, e sfrutta lo stesso fattore della vista umana, per dare la sensazione di profondità.

La grande capacità di immersione ha portato ad una grande diffusione del sistema, con sviluppi sempre più sofisticati.

La variazione delle immagini da inviare agli schermi è controllata da un sensore che segue il movimento di rotazione della testa, e quindi del sistema di riferimento O_x.y.z (fig. 4.2), mentre il movimento di rotazione può essere ottenuto in modi diversi, a seconda del campo di applicazione, ma non è comunque un movimento virtuale: ad esempio in una simulazione nella quale l’osservatore scorre lungo una strada ricostruita virtualmente, il movimento nei due sensi di marcia può essere guidato da un joystick a più gradi di libertà.


61

Troviamo molti esempi di utilizzo del HMD nel campo artistico, e tutti sfruttano le sue qualità per inserire il visitatore in un grande ambiente virtuale, per guardarlo e visitarlo nella più completa libertà.

Questa soluzione ha però ancora dei limiti di utilizzo, dovuti a fattori sia tecnici sia fisici: la visione stereoscopica non è ancora controllata perfettamente, e si rivelano spesso distorsioni, curvature del campo di vista ed aberrazioni cromatiche.

Un grosso difetto si presenta con l'uso prolungato del HMD, perché possono nascere problemi di stress agli occhi, mal di testa e difficoltà legate all'apparato digerente; questo naturalmente pone dei limiti di tempo e di persone, alle quali permetterne l'uso, e lo sconsiglia per applicazioni che richiedono un lungo periodo di consultazione da parte dell'utente.

4.4.3 Head Coupled System

Questa configurazione è uno sviluppo dell’HMD, e tende ad eliminarne i problemi già indicati, anche se con alcune limitazioni anch'esso.

La visione è fornita da un binoculare, che l'utente può tenere vicino agli occhi, come fosse un cannocchiale, e sfrutta anche qui la stereoscopia, per ottenere un ottimo effetto di tridimensionalità e profondità.

La migliore qualità dell'immagine è possibile grazie a visori migliori e più grandi, ma più pesanti, e questo rende necessario l'utilizzo di uno strumento di sostegno per l'HCS, normalmente composto da un braccio articolato che sostiene il visore, collegato ad una testa mobile.

L'utente tiene in mano il sistema, lo avvicina agli occhi ed osserva il mondo virtuale in tutte le direzioni, ed ha una certa libertà di movimento limitata dal braccio, che è legato a terra.

Il sistema meccanico serve anche per seguire i movimenti e gli orientamenti dell’HCS, e gestisce la navigazione virtuale.


62

4.4.4 Spatially Immersive Display

Il sistema SIDs appare come quello con più resa immersiva, perché prevede la rappresentazione avvolgente intorno all'utente, proiettando immagini su una cupola od un grosso schermo panoramico (fig. 4.3).

L'osservatore si ritrova completamente inserito nell'ambiente virtuale in qualunque direzione rivolga lo sguardo, provando sicuramente una forte esperienza di "presenza virtuale".

fig. 4.3 sistema SIDs

I movimenti di traslazione e rotazione del sistema di riferimento

legato all’osservatore O_x.y.z (fig. 4.2) sono effettivamente reali, e si svolgono nello spazio reale racchiuso dalle pareti del sistema di schermi.

Questi sistemi, normalmente chiamati Cupole, o CAVE, o VR Enviroments, hanno grandi potenzialità di applicazione; attualmente il loro uso è prevalente nell'industria dell'intrattenimento o per la rappresentazione di planetari, ma si sta sviluppando anche nel settore artistico, legato ai musei ed alle visite immersive in ambienti storici ricostruiti virtualmente.

Tra le prime ditte a sviluppare sistemi di questo tipo, la VisionDome produce attualmente una Cupola che contiene circa dieci persone, e permette la visione di oggetti 3D grafici proiettati su schermi curvi, che ne ricoprono le pareti.

4.4.5 Virtual Model Display


63

I sistemi VMDs permettono all'utente di vedere e lavorare con oggetti

3D che sono proiettati su superfici piatte. L'utente indossa degli occhiali particolari, chiamati 3D glasses, i quali

permettono di vedere proiettato nello spazio davanti allo schermo l'oggetto rappresentato.

L'uso principale riguarda essenzialmente modellazione e disegno di oggetti o componenti tecnici, e la loro forza sta principalmente nel costo, sicuramente inferiore alle tecnologie descritte precedentemente, e nella tecnologia utilizzata, che non è così sofisticata e di difficile gestione, come per i sistemi SIDs (fig. 4.4).

fig. 4.4 sistema VMDs

Spesso queste stazioni sono accompagnate da elementi di interazione

virtuale, quali trackball o guanti di presenza, che danno all'utente la possibilità di manipolare l'oggetto rappresentato, spostandolo e ruotandolo.[FORSBERG_97]

Ultimamente questa tecnologia viene utilizzata anche per studiare rappresentazioni tridimensionali di specifiche zone del corpo umano, ottenute con la combinazione di varie indagini mediche, quali raggi X, risonanza magnetica, tomografia assiale computerizzata; le diagnosi possono così essere fatte guardando una riproduzione 3D più fedele possibile della parte interessata.[KING_97]


64

4.5 Sistema a finestra mobile

La soluzione adottata durante questo progetto prevede l’utilizzo di una finestra mobile, rappresentata da uno schermo portatile, per interagire visivamente con l’ambiente virtuale (fig. 4.5).

Fig. 4.5 sistema a finestra mobile

Il sistema O_x.y.z è associato direttamente alla finestra, e quindi al

punto di vista dell’osservatore; sia i movimenti di rotazione che quelli di rotazione sono controllati da un sensore ad inseguimento e quindi sono reali in uno spazio di lavoro ridotto, e riportati fedelmente nell’ambiente virtuale.


65

4.6 Sistemi di tracker

I sistemi di tracker servono per seguire ad ogni istante un determinato

punto in movimento nello spazio reale. I metodi più utilizzati si riconducono a tre tipologie di inseguitori,

quelli meccanici, quelli ottici, e quelli elettromagnetici. I sensori meccanici forniscono la posizione del punto B, in funzione

dell'origine del sistema, il punto A, calcolandola dagli angoli tra i vari pezzi del braccio meccanico (fig. 4.6).

Nell'ambito del quale trattiamo, e nel quale c'è la necessità di un movimento libero del punto da controllare, non è molto indicata questa soluzione; è spesso utilizzata in ambito robotico, dove le articolazioni di un braccio meccanico possono essere mappate ed utilizzate per avere valori di riferimento.

fig. 4.6 tracker meccanico

A

B

I sistemi ad inseguimento ottico permettono la mappatura dei

movimenti di un punto, senza collegamenti fisici. Questo avviene grazie ad una serie di telecamere speciali che rilevano

la posizione nello spazio di marker luminosi posti nei punti da seguire, e da un software che sfrutta queste informazioni per ricavare un andamento tridimensionale rispetto ad un riferimento fisso.

Questo tipo di mappatura è molto costoso, ed attualmente non garantisce risultati molto precisi, anche per la necessità di un controllo totale della luce, nell'ambiente nel quale vengono fatte le misure.

I sensori magnetici utilizzano campi a bassa frequenza per determinare posizione ed orientamento di oggetti in movimento.


66

Il sistema è composto da un trasmettitore, ed un ricevitore, il quale tramite una centralina elettronica converte le variazioni dei campi in valori numerici.[BURDEA_94]

Tra i sensori ad inseguimento elettromagnetici, i più utilizzati sono sicuramente quelli prodotti dalla Polhemus, e tra questi c'è anche il Fastrak Polhemus, che è quello utilizzato nella realizzazione di questa tesi.

Il Fastrak utilizza un’architettura DSP (Digital Signal Processing), per limitare al massimo i problemi di rumore agli estremi del raggio d'azione del sensore.

Il segnale indotto dalla bobina del ricevitore è spedito ad un amplificatore differenziale a basso rumore, la cui uscita è multiplexata con segnali di calibrazione ed inviata a tre convertitori A/D in parallelo.

Qui i canali vengono campionati ad una frequenza molto maggiore della portante, con il risultato di un netto miglioramento del rapporto segnale rumore.

Il framerate di campionamento può arrivare anche a 120 data sets/sec, secondo le modalità di funzionamento del sensore.

Questi sensori permettono una buona libertà di movimento, e forniscono un accettabile precisione dei dati, ma richiedono fra trasmettitore e ricevitore uno spazio libero da oggetti ferromagnetici o non schermati, che muterebbero la configurazione del campo, danneggiando i dati.

67

CAPITOLO 5

Il Sistema di Rappresentazione 5.1 Una finestra reale sul mondo virtuale

Il sistema studiato per la rappresentazione del calice sfrutta un nuovo paradigma di interazione con la ricostruzione di manufatti archeologici; è stato cercato un nuovo modo, oltre ai tradizionali già visti, per dare all’utente un’esperienza immersiva nello scenario virtuale.

Abbiamo spostato la rappresentazione virtuale su un leggero schermo portabile, proponendo così una finestra reale verso il mondo virtuale.

Lo schermo è tenuto in mano dal visitatore, e puntato verso la posizione reale dello spazio, dove l’oggetto dovrebbe essere; in questo modo l’utente ha un riscontro diretto ed immediato della posizione e dimensione fisica del manufatto rappresentato ( vedi precedente fig. 4.5).

La rappresentazione funziona naturalmente in real time, e l’esatta prospettiva e dimensione di rappresentazione dell’oggetto virtuale sullo schermo è controllata seguendo posizione ed orientamento dello schermo stesso con un sensore ad inseguimento.

Il sistema permette una accesso totale alle informazioni riguardanti il manufatto rappresentato, tramite un ambiente a finestre e pulsanti (Graphic User Interface), che permette all’utente di interagire e modificare il modo di consultazione.

Tutta l’applicazione è stata sviluppata intorno al calice, ma va pensata come una piattaforma utilizzabile per qualunque manufatto, magari

Il Sistema di Rappresentazione

68

ambientato nel luogo più idoneo, che sia la tomba dove è stato trovato, nel caso oggetti funerari, o l’edificio che lo ospitava, nel caso per esempio di una statua.

Lo schermo può essere utilizzato come una lente di ingrandimento elettronica, grazie alla quale è possibile avvicinare ogni particolare dell’oggetto, così da vederlo meglio ( per esempio il volto di una statua alta una decina di metri).

Il campo nel quale sfruttare questo schermo è naturalmente molto ampio, e non si ferma solo all’ambito archeologico.

È possibile visualizzare non solo oggetti o statue, ma anche sarcofagi, templi, palazzi e città intere; l’utente può visitare una città attraverso lo schermo, e viaggiarvi sopra come un gigante camminando per la stanza e puntando lo schermo verso il basso, renderci conto così delle distanze relative e delle dimensioni dei monumenti.

Contemporaneamente possiamo interagire con il sistema ed ottenere anche informazioni storiche o d’altro tipo.

La necessità di collegare il monitor all’unità centrale tramite dei cavi, uno per il segnale ed uno per la seriale del touch-screen, comporta sicuramente una limitazione nella libertà di movimento nello spazio reale dell’utente; utilizzando l’applicazione per la visualizzazione di manufatti, questo problema è meno restrittivo, per le dimensioni limitate del oggetto rappresentato, ed il raggio di movimento di circa due metri intorno al manufatto virtuale risultano sufficienti per una completa fruizione dell’opera.

Una possibile soluzione a questo problema potrebbe essere di avere un collegamento via radio tra schermo e unità centrale; questo suggerisce un museo inteso come una sala vuota, dove all’ingresso forniscono uno schermo personale ed ogni visitatore si muove liberamente vedendo attraverso la propria “finestra” le rappresentazioni virtuali che gli sono proposte.

Naturalmente altre soluzioni potrebbero limitare gli spazi fisici nei quali il visitatore può muoversi, in altre parole potremmo disporre gli oggetti virtuali sempre al centro della zona dedicata ad un utente, limitando il suo raggio di azione.

Questi sono in ogni modo problemi risolvibili, ma da affrontare in sede di progettazione e installazione della stazione virtuale nel museo;


69

per ora ci limitiamo allo studio di una postazione via cavo per dedicarci totalmente alla gestione dell’interazione grafica.

L’interazione con il sistema, da parte dell’utente, avviene su due canali paralleli, uno direttamente controllabile dal visitatore, ed uno esterno, indiretto (fig. 5.1).

fig. 5.1 canali di interazione tra utente e sistema

touchscreen

sensore

sistemadi

controlloschermo

posizioneorientamento

comandi immagini

Il visitatore comunica i suoi comandi tramite una serie di pulsanti rappresentati direttamente sullo schermo, ed attivabili grazie ad un touch screen solidale al monitor; questi sono di forma auto esplicativa, in posizioni laterali, facilmente raggiungibili con le dita anche tenendo in mano lo schermo.

Contemporaneamente il sensore ad inseguimento fornisce tutte le informazioni relative al movimento nell’ambiente al sistema centrale, che adopera questi dati per elaborare la nuova immagine secondo il nuovo punto di vista.

La grossa differenza con i tradizionali sistemi di navigazione in ambienti 3D tramite browser consiste nel fatto che, in questi, l’utente comunica dove vuole andare ed il sistema cambia il punto di vista nella finestra di osservazione; invece in questa nuova metodologia, l’utente si sposta fisicamente insieme alla finestra.

Le modalità di comunicare le informazioni sono molte, e vasto è anche il tipo di notizie che possono essere date; per questo è permesso a chi ha in mano lo schermo, mentre si muove e vede l’oggetto 3D, chiedere in tempo reale altre notizie o passare da un tipo di consultazione ad un altro.


70

La forte interazione è permessa dalla presenza di un touch-screen che consente di rappresentare i pulsanti necessari direttamente sullo schermo, integrati completamente con la rappresentazione in corso.

A seconda della funzionalità attiva in quel momento, sullo schermo appariranno pulsanti diversi con funzioni diverse, che permetteranno all’utente un completo controllo della situazione.

Per esempio, nel nostro sistema, la presenza di uno schermo con touch screen permetterà all’utente di ottenere, con una leggera pressione di un dito in una determinata zona dello schermo, informazioni sulle singole decorazioni del calice e di conoscere le varie fasi di fabbricazione dell’oggetto, vedendole in sequenza sullo schermo.

La contemporanea possibilità di interagire con lo spazio fisico reale, e di controllare attivamente l’applicazione sono il punto di forza del sistema, che si propone come un’alternativa meno costosa di sistemi a immersione ad alto costo.


71

5.2 Struttura e descrizione dell’hardware utilizzato

Il sistema hardware è composto da quattro blocchi principali, che interagiscono tra loro (fig. 5.2).

Il nucleo centrale è costituito dalla workstation, che raccoglie le informazioni provenienti dai due blocchi di interazione con l’esterno, le elabora e definisce la corretta immagine da rappresentare sullo schermo.

TRACKER TOUCH-SCREEN

WORKSTATION

MONITOR

fig. 5.2 schema dell'harware

La workstation utilizzata è una SiliconGraphics Indigo2 con

processore audio IP28 a 195 MHz, CPU MIPS R10000 ed FPU MIPS R10010 a virgola mobile; ha una struttura a pipeline parallelo, con data cache di 32 Kbytes, instruction cache di 32 Kbytes, secondary unified instruction/data cache di 1 Mbyte ed una RAM di 64 Mbytes.

La scheda grafica è una High Impact con 1 Mbyte di texture memory ed 8 Mbytes di DRAM; ha una risoluzione massima di 1280 x 1024, e


72

sfrutta un double buffer a 32 bit con Z-buffer a 24 bit alla risoluzione di 1024 x 768.

L’interazione con il mondo esterno avviene tramite due blocchi di ingresso: un sensore ad inseguimento ed un touch screen.

Il sistema ad inseguimento fornisce le indicazioni relative alla posizione dell’utente nello spazio reale ed alla prospettiva dalla quale osserva l’oggetto; è composto da un sensore Fastrack della Polhemus, che si basa sulla rilevazione di campi elettromagnetici.

Tramite un driver in C++ sono letti i valori forniti dal sensore alla porta seriale della workstation e questi sono poi utilizzati via software.

Il secondo blocco di ingresso è costituito dal touch screen posto sul monitor, e fornisce indicazioni sulle modalità attraverso le quali l’utente intende consultare il sistema.

Il tipo di informazioni riguarda quale parte dell’applicazione l’utente intende consultare e con che modalità; i vari pulsanti per scegliere le possibili consultazioni del sistema, quali la visione 3D o quella planare dell’oggetto, oppure pulsanti per modificare l’immagine, come lo zoom, ne sono un esempio.

Anche questo blocco è interfacciato con la workstation tramite un driver che legge i dati di pressione dello schermo.

Il blocco di uscita è costituito da un monitor ultra piatto a cristalli liquidi, che presenta un basso consumo di energia (circa 15 W), ed assenza di distorsioni geometriche, per permettere una buona visione da ogni angolo.

L’ingresso è di tipo analogico standard, con connettori DB-15HD, ed il segnale è in SVGA, composto dalla terna di colori RGB e dai sincronismi orizzontale e verticale, ognuno su un cavo separato.

5.3 Motivazione delle scelte hardware

La scelta di questi elementi è stata fatta in base a varie considerazioni. Attualmente il corpo centrale del progetto è costituito dalla

workstation, perché permette prestazioni di altissimo livello, per quanto riguarda il controllo del sensore e la grafica in tempo reale.


73

Non è sicuramente un sistema economico, ma prestazioni molto vicine, e sicuramente sufficienti, potranno presto essere raggiunte da personal computer potenziati per la grafica con schede acceleratrici.

Il sistema rendeva necessario utilizzare uno strumento di consultazione facilmente manovrabile e non ingombrante; sia per le sue ridotte dimensioni ed il suo peso, sia per la facile adattabilità a tutti i tipi di utenti, la scelta è caduta su tipo di monitor già descritto.

E’ stata valutata la possibilità di utilizzare un head mounted display (HMD), che consente un visione sicuramente più immersiva, ma non rispettava alcune specifiche fondamentali necessarie per l’applicazione: la prima necessità era quella di sviluppare un sistema che permesse una consultazione anche prolungata, durante la quale l’utente può richiedere le informazioni, muoversi nello spazio virtuale, ed avere tutto il tempo per esaurire la sua visita; in un museo tradizionale, questo è garantito dalla sua stessa struttura, perché nessuno vieta al visitatore di sostare davanti ad una vetrina fino a che non è soddisfatto.

Attualmente l’utilizzo del HMD ha invece una limitazione di tempo, in quanto dopo un certo periodo alcuni leggeri disturbi, ed è consigliabile evitare sedute prolungate.

Altro fattore importante è la possibilità data all’utente di interagire con l’applicazione, e questo viene fatto con il touch screen, direttamente dal monitor: è possibile consultare il sistema tenendo in mano lo schermo, e le sue dimensioni sono tali da permettere un agevole contatto con il touch-screen. L’HMD implica l’utilizzo di un altro strumento di interazione, un joystick od un altro sistema a controllo manuale, ma che non permette all’utente di vederlo direttamente, perché immerso completamente nell’ambiente virtuale; in alcune applicazioni il problema è stato risolto replicando virtualmente l’interfaccia di controllo, in modo da fornire un riferimento spaziale sulla sua posizione all’utente.

Il monitor è un elemento commerciale, che può essere estratto dalla sua base, mantenendo tutti i collegamenti direttamente sullo châssis; questa soluzione lo alleggerisce sino a livelli accettabili (il peso complessivo dello schermo completo di touch-screen è di circa 2 Kg), e permette una consultazione anche di lunga durata ad un utente, senza che il peso lo stanchi o ne renda faticose alcune posizioni di


74

consultazione, come ad esempio osservare verso l’alto, tenendo sollevato il monitor.

L’interazione con l’utente, in un primo momento, era stata organizzata tramite pulsanti ai lati dello schermo, o tramite una trackball sostenuta da un supporto posto intorno al monitor.

Queste soluzioni, sicuramente più economiche rispetto a quella finale, risentono però di alcune limitazioni.

Innanzi tutto sarebbe stato necessario studiare un supporto esterno, per sostenere pulsanti o trackball, il quale combaciasse con il monitor, non lo appesantisse troppo, e che lo rendesse ancora facilmente maneggiabile.

In questo senso la soluzione del touch screen è ottima, perché il peso che aggiunge è molto limitato, ed il suo collegamento è giá fatto in sede di produzione, in maniera solidale con lo schermo.

Un altro fattore importante è la possibilità di ampliare le funzionalità dell’applicazione e di modificarla adeguandola alle esigenze dell’oggetto rappresentato.

La scelta dei pulsanti è molto limitativa in questo senso, perché l’interazione è legata al loro numero, e quindi il primo sistema studiato è quello che lo impone, difficilmente modificabile in seguito, se non con lo studio di una nuova struttura esterna di controllo.

L’uso della trackball è più versatile, in quanto permette l’interazione con i pulsanti rappresentati sullo schermo, come un mouse; resta il problema della struttura di sostegno, e la difficoltà oggettiva di manipolare una sfera con precisione sostenendo il monitor.

5.4 Descrizione del software utilizzato

L’ambiente nel quale è operativa l’applicazione è il sistema UNIX della SiliconGraphics IRIX 6.2, e quindi tutto è stato programmato su questa piattaforma.

Tutta l’applicazione è sviluppata con linguaggio di programmazione C++, sfruttando varie librerie a seconda delle necessità, e le principali sono Xforms, OpenGL, GLUT e VRLib.


75

Il blocco principale del sistema è costituito da una interfaccia grafica, che visualizza le varie schermate ed i pulsanti, gestisce l’interazione con il sensore e stabilisce quali immagini rappresentare sullo schermo.

Tutto questo è stato programmato in ambiente Xwindow, grazie alle librerie Xforms.

Applicazione

GLUT

Monitor

OpenGL

VRLib

Xforms

C++

fig. 5.3 schema del software

Queste permettono di costruire un’interfaccia grafica a finestre con

pulsanti, barre di scorrimento, campi di input, etc., sviluppate tramite un codice C, modificabile ed utilizzabile anche in C++.[ZHAO_97]

L’elemento base delle Xforms è la form, nella quale sono rappresentati tutti gli oggetti, che poi possono interagire, richiamando delle funzioni a loro associate o testando il loro stato; vi sono molte classi di oggetti che il programmatore può utilizzare, e poi modificare a seconda delle sue esigenze, non solo nella forma e nel colore, ma anche e soprattutto nelle funzionalità interne.

Le OpenGL (Graphics Library) sono un’interfaccia software dedicata alla grafica; sono strutturate un modo da essere indipendenti dalla piattaforma hardware nella quale operano, anche perché non presentano


76

comandi per la gestione di finestre grafiche, e sfruttano quindi i supporti presenti nel sistema che viene usato dal programmatore.

Vi sono comandi di basso livello, che permettono di gestire graficamente la rappresentazione di primitive geometriche, quali linee o poligoni, ma anche scene più complesse, con più oggetti, grazie alla versatilità dei comandi base: intere superfici, ad esempio, sono viste come l’unione di molti triangoli, e come tali gestite.

La gestione di tutte le funzionalità grafiche di alto livello, è affidata ad una parte di codice che sfrutta la libreria VRLib.

Questa è stata sviluppata all’interno del Laboratorio PERCRO, della Scuola S.Anna, ed è in continua evoluzione, per raggiungere prestazioni sempre maggiori nel campo della realtà virtuale.

Lo scopo della libreria VRLib è quello di permettere al programmatore di visualizzare in maniera semplice scene complesse, composte da più oggetti, e manipolarle, modificandole durante la rappresentazione stessa, e viaggiando all’interno di esse con telecamere totalmente mobili; tutto questo, naturalmente in tempo reale.

Questo permette di rappresentare l’oggetto rappresentato all’interno di una stanza e di modificare le immagini sul monitor in maniera fluida.

La libreria VRLib si interfaccia all’hardware grafico tramite le OpenGL.

Queste ultime si occupano esclusivamente della gestione degli oggetti, ma non della loro rappresentazione sullo schermo; questo perché la gestione del rendering delle immagini è diversa per ogni piattaforma di lavoro, e quindi ogni utente utilizzare il proprio sistema.

E’ necessario quindi un gestore del rendering, cioè una finestra OpenGL, che deve essere aperta sullo schermo, per interagire con le librerie.

Le GLUT sono la libreria che si occupa di questo [DAVIS_97]. L’apertura di una Xwindow che rispetti la mappa dei colori necessari

per un buon rendering, non è una cosa di facile gestione e quindi si è utilizzato le librerie GLUT, che con pochi e semplici comandi possono aprire e gestire una OpenGLWindow.

La libreria GLUT (OpenGL Utility Toolkit) è un semplice GUI di basso livello, sviluppato appositamente per le OpenGL [KILGARD_97].


77

Questa fornisce semplici comandi per la gestione di finestre grafiche, pulsanti e menu, permette di controllare le funzioni dei pulsanti del mouse e di avere ottime prestazioni in tempo reale.

Con pochi comandi riusciamo ad aprire e gestire un finestra per OpenGL, ed è molto più semplice da gestire che una finestra Xwindow pura.

5.5. Motivazione delle scelte software

L’applicazione finale doveva avere due particolarità principali: facilità di utilizzo e possibilità di diffusione.

Queste due caratteristiche hanno influito nella scelta di come sviluppare il software, certamente insieme alla necessitá di operare in tempo reale.

Nello sviluppare il sistema si è tenuto conto delle possibilità future, e quindi era necessario basarsi su librerie che fossero disponibili su tutte le piattaforme, e non solo su UNIX.

Le Xforms e le OpenGL hanno loro versioni sia per Window95, sia per NT che per UNIX o Linux, e questo permette di riutilizzare lo stesso codice, con solo alcune inevitabili modifiche di compilazione o di ottimizzazione.

Le stesse GLUT esistono in versioni per varie piattaforme, e già molte applicazioni le utilizzano per interagire con le OpenGL, o come GUI di basso livello.

La libreria VRLib è stata progettata per essere totalmente compatibile sia su workstation sia su PC, ed è quindi indipendente dalla piattaforma utilizzata.

5.6 Ultime modifiche ad hardware e software

Durante la realizzazione del sistema si sono presentati alcuni

problemi, che hanno rese necessarie delle modifiche rispetto al progetto originale.


78

Al momento di collegare il monitor dotato di touch-screen alla workstation della Silicon Graphics, si sono presentati problemi relativi al tipo di segnale disponibile: la scheda grafica utilizzata, una High Impact, permette la definizione della risoluzione solo fino ad un limite di 1024x768, e non inferiore.

Il segnale SVGA riceve una definizione massima di 800x600, quindi, a meno di progettare un convertitore per modificare la frequenza dei sincronismi, i due blocchi non sono collegabili.

La soluzione scelta è stata quella di accelerare il processo di evoluzione del sistema, che era già stato previsto, ma in una fase successiva.

L’applicazione è stata modificata per essere totalmente compatibile ad una piattaforma WindowNT.

Le librerie utilizzate su UNIX sono state installate anche su un computer con il sistema NT, ed il codice è stato modificato per poter funzionare.

L’unica aggiunta che è stata necessaria è l’installazione sulla macchina di un X-Server, ovvero un emulatore di finestre Xwindow, necessario per il corretto funzionamento delle Xforms; il server scelto è stato scaricato gratuitamente dalla rete, e quindi rimane coerente con la scelta iniziale di utilizzare solo strumenti di facile ed economica reperibilità.

Attualmente il codice funziona su entrambe le piattaforme, sia UNIX sia WindowNT, basta solo specificare la piattaforma al momento della compilazione.

E’ stata mantenuta la possibilità di compilarlo anche su UNIX, perché esistono monitor LCD che supportano una definizione di 1024x768, e quindi collegabili alle workstation della SiliconGraphics, ma sono ancora dai costi e dalle dimensioni troppo elevate.

79

CAPITOLO 6

Sviluppo dell’Applicazione

6.1 Descrizione della programmazione software 6.1.1 Obiettivi e struttura

L'obiettivo di questa tesi è stato quello di realizzare un'applicazione che corrispondesse ad una ben precisa serie di requisiti.

Innanzitutto il sistema doveva essere di facile utilizzo, qualunque fosse l'utente, e presentare un sistema di navigazione tra le sue modalità molto intuitivo.

Un visitatore che consulti l'applicazione deve essere in grado di capire subito cosa può fare e come, senza dover chiedere lunghe spiegazioni o fare tentativi inutili.

A questo proposito, si è pensato che fosse necessario ridurre il numero dei pulsanti presenti in ogni schermata, a vantaggio della loro dimensione sullo schermo, e della chiarezza del loro scopo; altro elemento importante, ai fini di un rapido apprendimento, è stato quello di inserire la possibilità di consultare l'applicazione in diverse lingue, ed allo stato attuale sono disponibili solo italiano ed inglese.

L'utente ha la possibilità di impostare la lingua preferita alla partenza del sistema, ma è possibile anche modificare questa scelta in corsa, in qualunque momento; la modifica della lingua, implica la traduzione di tutti i testi informativi presenti all'interno, e di tutte le etichette sui pulsanti delle varie funzioni.


80

TITOLO

Scelta dellalingua

PRESENTAZIONE

MENUCambio

dellalingua

Aiuto

Chiusurasistema

Fasi difabbricazione

Visione 3Ddell'oggetto

VisionePlanare

dell'oggetto

Bibliografia enotiziegenerali

fig. 6.1. schema generale dell'applicazione

Un'altra importante necessità era quella di poter fornire anche

informazioni dettagliate sull'oggetto rappresentato, quali notizie storiche, archeologiche e documentazioni fotografiche sui luoghi di origine; per questo motivo è stata inserita la possibilità di attingere a queste informazioni in maniera molto semplice, ed in qualunque momento, sempre tramite pulsanti sullo schermo.

Una sezione è dedicata alle notizie relative alla fabbricazione dell'oggetto, con la descrizione delle varie fasi.

Naturalmente la parte principale del sistema è quella che si occupa della navigazione virtuale in tempo reale, che permette la visione dell'oggetto rappresentato; all'interno di questa sezione vi sono le


81

possibilità di aumentare o ridurre la scala dell'oggetto, muoversi all'interno dello spazio virtuale ed avere informazioni più dettagliate del particolare che viene osservato in quel momento.

Le alte prestazioni necessarie in questo caso sono state raggiunte grazie alle capacità del hardware, ma anche sfruttando un serie di librerie di programmazione grafica, che verranno descritte successivamente.

Vediamo adesso come tutte queste funzionalità sono consultabili attraverso l'applicazione, in altre parole entriamo nei singoli blocchi dello schema generale (fig. 6.1).

Dopo una schermata puramente introduttiva, l'utente deve scegliere la lingua di consultazione, prima di entrare nel sistema (fig. 6.2).

A questo punto appare una finestra nella quale si spiega brevemente che funzioni ha il sistema e sono date alcune informazioni sull'oggetto da vedere.

Toccando lo schermo in un punto qualunque, appare il menu' generale, che è il centro dell'applicazione, e dal quale partono tutte le varie funzionalità (fig. 6.3).

Vi sono due gruppi di pulsanti, posti ai lati dello schermo, e divisi per funzionalità: sulla sinistra vi sono quelli che permettono di modificare il sistema, e quindi il cambio della lingua in corsa, le schermate di aiuto, ed il pulsante per chiudere l'applicazione; in questa sezione troviamo anche il pulsante per la consultazione della bibliografia e delle notizie generali sull'oggetto.

Alla destra troviamo i pulsanti di interazione veri e propri, per la visione tridimensionale dell'oggetto, oppure per una sua versione planare, svolta, per avere la possibilità di vedere meglio le decorazioni presenti.

Vi è infine la possibilità di vedere le varie fasi di fabbricazione dell'oggetto.


82

Fig. 6.2 scelta iniziale della lingua


83

Fig. 6.3 menu’generale


84

La funzione di aiuto permette di consultare una serie di schermate che spiegano i singoli menu che possono essere incontrati, durante l'uso dell'applicazione.

In accordo con gli esperti archeologi, la procedura di fabbricazione è stata divisa in cinque fasi, ad ognuna delle quali è stato associato un testo esplicativo e delle immagini virtuali che mostrano il calice a quel punto di lavorazione.

La necessità di fornire il massimo numero di informazioni al visitatore, ha portato a creare una schermata di consultazione, nella quale è possibile leggere notizie generali sul manufatto e vedere alcune immagini relative al luogo di ritrovamento.

Il nucleo centrale di tutta l'applicazione è la parte relativa alla visione 3D del manufatto.

La schermata si presenta dominata da una finestra verso il mondo virtuale, attraverso la quale l'utente vede il manufatto; l'interazione con il mondo reale avviene anche attraverso alcuni tasti rapresentati sullo schermo ed attivabili con una pressione del touch screen.

Vi sono due pulsanti a freccia che permettono di avvicinare od allontanare l'obiettivo virtuale della camera, ed altri due tasti con diverse funzioni.

Azionando gli ingrandimenti, è possibile svariare in un range che va da un minimo di 1:1 ad un massimo di 10:1 (da 20 cm a 2 m, per quanto riguarda le dimensioni virtuali dell'oggetto), in questo modo l’utente può sempre essere sicuro di quale siano le dimensioni reali del calice, perché è sufficiente che lui abbassi al minimo l'ingrandimento.

Questa operazione di scala avrà come centro di espansione il punto osservato in quel momento, fornitoci dalla normale allo schermo che incontra il calice; l’utente avrà così la sensazione di avvicinarsi all’oggetto, ed è molto più intuitivo di un ingrandimento che tenga fisso nello spazio un punto preciso del calice.

Un tasto permette di riposizionare il manufatto virtuale nella posizione di partenza, perche è possibile che le operazioni di ingrandimento, abbinate allo spostamento fisico del visitatore, portino l'oggetto in una posizione virtuale scomoda da consultare(fig. 6.4).

Un altro tasto presente in questa schermata permette di avere notizie sulla parte di manufatto che l'utente sta guardando.


85

Le decorazioni, presenti sul calice preso in esame in questa tesi, sono state suddivise in base al loro significato, e ad ognuna di esse è associato un testo descrittivo; al momento della pressione del pulsante, viene temporaneamente bloccata la consultazione virtuale, ed è mostrato il testo relativo alla decorazione osservata.

fig.6.4 riposizionamento del manufatto virtuale

Un'altra possibilità di consultazione virtuale del manufatto è la

visione planare, studiata appositamente per il calice in esame, e che permette di vedere uno svolgimento planare della sua parte centrale, e consente di osservare le decorazioni in maniera completa.

Questa è una funzionalità che puo essere modificata facilmente a seconda del manufatto da presentare, seguendo le necessità e i motivi di interesse archeologico legati ad esso.

Per un oggetto cilindrico, quale il calice, era interessante rendere possibile la visione dell'intera scena rappresentata, ma per altri oggetti potrà essere utile mostrare altri aspetti; per esempio per un sarcofago, è possibile sfruttare la seconda possibilità di rappresentazione per la mummia che vi era contenuta, o per alcuni oggetti rinvenuti nella stessa tomba.

Naturalmente da ogni schermata è possibile tornare indietro fino al menù generale, e cominciare un'altra consultazione.


86

6.1.2 Sviluppo del codice

Il codice del sistema è stato interamente sviluppato con linguaggio C++, per poter sfruttare le librerie grafiche disponibili, ed avere le migliori prestazioni in tempo reale.

L'applicazione è stata divisa in molti file, a seconda della loro funzione, e delle librerie che sfruttano(fig. 6.5).

file.h

file.cc

XFORMS

main.h

main.cc

MAIN

funzOpenGL.h

funzOpenGL.cc

VRLIB-OPENGLGLUT

SENSORE

funzioni.cc

callback.cc

fig. 6.5 suddivisione dei file

FUNZIONI

foto

testi

modelli3D

DATI

Come si vede dalla figura, vi è un blocco di file che serve a definire tutte le form utilizzate per la costruzione del GUI (Graphic User Interface), sfruttando le librerie delle Xforms.


87

Questi file contengono la dichiarazione e la definizione degli oggetti utilizzati, quali finestre di testo, immagini e pulsanti, e costituiscono la parte "statica" dell'applicazione, in altre parole quella che viene richiamata inizialmente per l'inizializzazione del sistema, ma che poi non partecipa alle varie funzionalità.

Questo compito è affidato ai tre file che contengono le funzioni operative, sia per la gestione grafica (VRLib, OpenGL, GLUT e Sensore), sia per le operazioni interne, affidate a funzioni generali e callback legate ai pulsanti.

Il main definisce l'ordine delle varie operazioni, dal titolo alla scelta della lingua, dalla presentazione al menù generale, ed è strutturato come un semplice elenco cronologico delle funzioni necessarie ai vari scopi.

Tutti questi blocchi fanno riferimento, per la gran parte delle loro operazioni, ai dati, che saranno di volta in volta immagini grafiche, fotografie, testi italiani ed inglesi, oppure modelli tridimensionali.

Vediamo adesso in che modo è strutturato il codice. Possiamo identificare quattro blocchi operativi principali, ognuno dei

quali si occupa di uno specifico settore dell'applicazione (fig. 6.6). Il primo è relativo alle Xforms, e si occupa di tutto ciò che riguarda la

creazione e la gestione delle varie schermate, dei pulsanti, in pratica di tutta l'interfaccia grafica.

Le varie funzionalità dei pulsanti sono gestite da funzioni dette callback , le quali possono essere create ed associate ai singoli tasti; queste sono racchiuse in un unico file, ed identificate dal prefisso "f_".

Gli altri tre blocchi cooperano per l'obiettivo finale, che è quello di rappresentare la visita virtuale in tempo reale.


88

XFORMScreazione formsgestione delle finestrecontrollo pressione pulsanti

VRLIB-OPENGLcaricamento modellilettura dati ingrandimentolettura dati del sensorevisualizzazione

GLUT

SENSORE

aperura finestra OpenGLgestione del Loop di controllogestione visualizzazione in tempo reale

attivazione del sensorecalcolo posizione e orientamentofiltraggio valori

fig. 6.6 blocchi operativi

Innanzitutto vi è un modulo che gestisce il sensore elettromagnetico,

lo attiva ne legge i valori di posizione ed orientamento, si preoccupa di filtrare questi dati da eventuali disturbi ambientali, e li inserisce in variabili globali, utilizzabili da qualunque funzione.

L'intera sezione relativa alla visualizzazione dell'immagine virtuale è gestita dalle librerie GLUT e VRLib, che si occupano di aprire la finestra grafica e rappresentare in tempo reale il manufatto dalla giusta prospettiva, usando i valori dati dalla scala e dal sensore di posizione.

Il main del codice è composto in maniera modulare, e permette agevolmente di capire come viene gestita l'applicazione; vi sono una serie di funzioni, le quali hanno compiti ben precisi nello svolgersi del sistema.


89

#include "mainACCA.h"

// Global variablesint LANG, SCALA;float XPOS, YPOS, ZPOS;float YAW, PITCH, ROLL;

int main(int argc, char *argv[]){rescale (argv[1]);initGLUT(&argc, argv);initXFORMS(&argc, argv);

carica3D();

showTitle();chooseFirstLang();

creation();

presentation();freeing();

general();

return 0;}

fig. 6.7 main del codice

Inizialmente vengono inizializzate le librerie Xforms e Glut, che servono per ogni operazione (initGLUT e initXFORMS).


90

FUNZIONI GENERALI

fig. 6.8 funzioni

FUNZIONI PER VRLIB

FUNZIONI PER GLUT

FUNZIONI PER SENSORE

caricamento immagini (carica3D)settaggio immagine (idle)

gestione finestra (initGLUT)controllo generale (display)

attivazione del sensore (init_tracker)disattivazione (deactive_tracker)lettura dati (tracker)

inizializzazione Xforms (initXFORMS)caricamento testi (calltext)modifica scala (writeSCALA)cambio lingua (newLang)presentazione varie schermate

callback dei vari pulsanti

Prima di qualsiasi schermata che segni l'inizio dell'applicazione, si è

pensato di caricare i modelli 3D dei manufatti (carica3D), operazione lenta, e che rallenterebbe il sistema se fatta al momento della prima visualizzazione.

Le funzioni successive si occupano di scegliere la lingua da utilizzare e caricare i giusti testi per pulsanti e informazioni varie (showTitle, chooseFirstLang e creation), ed a questo punto avviene la presentazione con notizie tecniche e storiche sull'oggetto (presentation).

Prima di arrivare al menù principale, nucleo dell'applicazione (general), ci siamo preoccupati di alleggerire la memoria, liberandola dalle form che non sarebbero più state utilizzate(freeing), ed aumentando le prestazioni.

Al momento della chiusura del sistema, alcune funzioni si occupano di chiudere le schermate e disattivare il sensore.

6.1.3 Problemi particolari e soluzioni

Con l'avanzare della programmazione si sono naturalmente incontrati alcuni problemi, che hanno determinato la struttura del codice.

Il primo ostacolo che si è presentato è stato quello di fornire all'utente la possibilità di cambiare la lingua di consultazione in corsa.


91

La soluzione adottata prevede l'uso di una variabile globale, LANG, che vale 0 oppure 1, e che identifica la lingua; ad ogni variazione di questa, cosa possibile solo da una callback (f_language), per evitare contaminazioni, vengono richiamate una serie di funzioni (newLang_), che hanno il compito di richiamare i testi giusti; le newLang sono una per ogni form del sistema.

La possibilità di modificare la scala con la quale la telecamera virtuale riprende il manufatto è permessa da un'altra variabile globale, SCALA.

Questa è modificabile dalla schermata di visualizzazione virtuale tramite due pulsanti, ed il range è limitato da 1 a 10; il fatto che sia globale permette al modulo di visualizzazione di leggerla, e di modificare l'immagine immediatamente, dopo ogni ciclo di controllo.

Il problema principale che è stato incontrato è quello di aprire e gestire una finestra OpenGL, adatta alla visualizzazione in tempo reale.

Come è gia stato detto questa fase viene gestita sfruttando contemporaneamente le due librerie GLUT e VRLib.

La creazione ed il controllo avvengono nel modo seguente: Inizialmente il sistema è gestito da una funzione di controllo delle

Xforms (fl_do_forms), ma al momento della prima visualizzazione virtuale, viene richiamata una callback (f_vision), che cede il controllo di tutto alla funzione di controllo delle GLUT.

In entrambe queste librerie, è possibile gestire una funzione idle, che viene eseguita automaticamente ogni volta che il sistema non ha niente da fare; in questo modo riusciamo a leggere i dati forniti dal sensore e dalla scala, e modificare la nuova immagine da rappresentare, il tutto con un framerate sufficiente per una rappresentazione in tempo reale.

Si crea però un conflitto tra le due librerie, perché entrambe hanno la loro idle, ed i loro controlli, ed è necessario stabilire delle priorità: a questo fine è stato deciso di utilizzare la idle delle GLUT, durante la visualizzazione, ma inserendoci all'interno un controllo delle Xforms che testa le sue form in quell'istante (fl_check_forms).

In questo modo, ad ogni ciclo della funzione idle delle GLUT, si ha una lettura dei dati necessari, una riformulazione della scena da rappresentare, un nuova rappresentazione, ed un test di controllo XFORMS sui pulsanti presenti sulla schermata.

Un modulo del codice molto delicato è quello che controlla il sensore, che per limitare al massimo problemi di gestione è stato deciso di


92

attivarlo alla prima visualizzazione richiesta dall'utente, e di disattivarlo solo alla chiusura dell'applicazione (init_tracker e deactive_tracker).

Durante la idle, una funzione (tracker) si occupa di leggere i valori di posizione (XPOS, YPOS, ZPOS) e di orientamento (YAW, PITCH, ROLL) del sensore, e li mette in sei variabili globali, a disposizione del modulo di visualizzazione.

I sensori ad inseguimento elettromagnetici, come il Polhemus Fastrak utilizzato, hanno spesso distorsioni ed imprecisioni.

Gli errori, derivanti da disturbi magnetici ambientali o da imprecisioni nel sistema di rilevamento, risultano estremamente sensibili alla distanza tra sorgente e ricevitore, ed oltre il metro e mezzo cominciano ad essere sensibili.[BRYSON_92]

Si è reso così necessario verificare se l'ambiente nel quale il progetto veniva portato avanti provocasse disturbi rilevanti ai fini dell'applicazione.

Il breve raggio d'azione intorno all'oggetto virtuale e l'uso di un monitor LCD, a bassa emissione, hanno permesso di utilizzare direttamente i valori filtrati dal driver di controllo.

All’interno del sistema di controllo del Polhemus è presente una EPROM, nella quale è possibile riprogrammare due filtri passabasso per i valori di posizionamento e di rotazione; questa riprogrammazione deve essere fatta al momento dell’attivazione del sensore e rimane valida durante tutto la sessione di lavoro. I valori utilizzati per la definizione del filtro sono quelli consigliati per default direttamente dalla Polhemus.

Per sicurezza è stato inserito un passaggio di filtro lineare, immediatamente all'interno della funzione che legge i dati (tracker), che fornisce in uscita sempre la media degli ultimi tre valori letti dal sensore: essendo il framerate di circa 120 dati al secondo, questo non provoca scorrimenti e ritardi dell'immagine, ma tutela da aumenti di rumore.

Durante la visita virtuale, è possibile che l'utente desideri avere informazioni su una parte dell'oggetto inquadrato, e nel caso del calice egizio, a proposito delle decorazioni o delle singole figure rappresentate.

Premendo un apposito pulsante, viene interrotta la visione virtuale, ed appare una schermata con una foto e dettagli storici sulla parte osservata.


93

Questo è possibile grazie ad una funzione (wichComment), che stabilisce la direzione nella quale è puntato lo schermo, e sceglie il giusto commento.

La funzione calcola vettorialmente la direzione di vista, sfruttando i dati del sensore e la posizione nota del calice; in questo modo è possibile controllare se lo schermo è rivolto verso l'oggetto, ed eventualmente verso quale parte.

In uscita la funzione fornisce un valore che identifica foto e commenti relativi alla zona osservata.

Partendo dai valori di posizione del sensore, e quindi della camera, e del vettore di puntamento della camera, disponibile tramite un funzione apposita delle VRLib, viene calcolato il punto di intersezione tra la direzione della camera ed un piano di riferimento; questo piano identifica uno dei quattro lati del parallelepipedo che costituisce la bounding box del modello del calice e viene scelto in base a quale settore del piano XZ si trova la camera.

Dal valore delle coordinate spaziali del punto di intersezione viene valutato se questo rientra nella bounding box dell’oggetto, ed eventualmente in quale zona, per identificare la figura osservata, e quindi il commento da mostrare.

Come in precedenza accennato, nell’ultima fase dello sviluppo del progetto, è sorta la necessità di modificare il codice per permetterne un utilizzo anche su piattaforme WindowNT.

Sono state inserite due variabili diverse in sede di compilazione, una per identificare il sistema WindowNT ed una per la piattaforma SiliconGraphics; il compilatore C++ discrimina le parti corrette per la piattaforma sulla quale sta girando, e fornisce un eseguibile adattato.

Le principali differenze consistono nella definizione delle variabili di settaggio del sensore Polhemus, riguardanti la porta seriale con la quale comunicare, ed il modo di funzionamento.

La sintassi diversa per specificare i vari path di ricerca dei file immagini e di testo sono stati anch’essi descritti in due opzioni separate, in base alla piattaforma utilizzata.

94

CONCLUSIONI

Lo studio ed il lavoro svolto per questa tesi hanno portato alla realizzazione di un sistema completo di presentazione di manufatti archeologici.

L’obiettivo di sfruttare il nuovo paradigma di interazione è stato raggiunto, sviluppando una finestra mobile verso il mondo virtuale.

L’applicazione riproduce il calice egizio di vetro blu, oggetto preso ad esempio per questa tesi, rispettandone le caratteristiche cromatiche e materiali, quali trasparenza e riflessione.

La fruizione dell’artefatto avviene sia attraverso canali visivi, come la

rappresentazione virtuale, sia per mezzo di testi storici. La stazione di consultazione è stata sottoposta a costante controllo da

parte di esperti del settore archeologico, i quali, a lavoro ultimato, ne hanno confermato la validità.

Il lavoro di sviluppo è già iniziato durante l’ultima fase di lavorazione,

operando un porting dalla piattaforma UNIX a quella per WindowNT: un ulteriore sviluppo può essere l’ottimizzazione dell’applicazione per sistemi più economici, come appunto WindowNT, per abbassarne i costi.

La possibilità di utilizzare il sistema di presentazione anche per altri manufatti, modificando solo le procedure di richiamo dei modelli 3D, rende l’applicazione molto duttile, ed offre molte possibilità di utilizzo all’interno di un sistema informatico di un futuro museo virtuale.

96

Appendici Appendice A: Funzioni di controllo per Polhemus, VRLib e GLUT /* ********************************************************************* *** OPEN GL ** *** funzioni relative alle open gl e VRLIB ** ********************************************************************* */ /******** INCLUDE PER IL SISTEMA ****************************** ***********************************************************************/ #include "mainACCA.h" #include "funzOpenGL.h" //#include "vrlib.cpp" // variabili globali extern float XPOS, YPOS, ZPOS; extern float YAW, PITCH, ROLL; extern int SCALA; extern double VH,VL; int WHAT; #define FRAMES 100 // ******************************************************************** // ******************************************************************** // *********** VR LIB **************** // ******************************************************************** SCENE3D scena; MESH *flute, *plate, *pedestal; OBJ *objFlute, *objPlate, *objPedestal; LIGHT *luce, *luce2, *luce3; CAMERA *cam; TEXTURE_TABLE *Texture_table; int pavi; // ****************************************** void idle() { fl_check_forms(); // settaggio della camera #ifdef POLHEMUS // lettura dati dal Polhemus tracker(); cam->SetPosition(XPOS,YPOS,ZPOS); cam->SetRotation(ROLL+90,0,1,0);

97

cam->Rotate(PITCH,0,0,1); cam->Rotate(YAW,1,0,0); #endif cam->SetGlobalScale(SCALA,SCALA,SCALA); scena.Begin(); cam->Setup(); glDisable(GL_LIGHTING); glDisable(GL_CULL_FACE); glColor3f(0.8,0.8,0.8); glEnable(GL_TEXTURE_2D); Texture_table->SetActiveTexture(pavi,NORMAL); glBegin(GL_QUADS); glTexCoord2f(10,-10); glVertex3f(100,-10,-100); glTexCoord2f(10,10); glVertex3f(100,-10,100); glTexCoord2f(-10,10); glVertex3f(-100,-10,100); glTexCoord2f(-10,-10); glVertex3f(-100,-10,-100); glEnd(); glEnable(GL_LIGHTING); glDisable(GL_TEXTURE_2D); //glEnable(GL_CULL_FACE); glEnable(GL_NORMALIZE); objPedestal->Draw(); // disegna il piedistallo if (WHAT) objPlate->Draw(); // disegna la lastra else objFlute->Draw(); // disegna il calice scena.End(); glutSwapBuffers(); } void carica3D(void) { // definisco gli oggetti da rappresentare ******* flute = scena.AddMesh(); objFlute = scena.AddObj(); plate = scena.AddMesh(); objPlate = scena.AddObj(); pedestal = scena.AddMesh(); objPedestal = scena.AddObj();

98

luce =scena.AddLight(DIRECTIONAL); luce->SetDirection(-0.5,0.5,-1); luce->SetDiffuseColor(1,1,1); luce2 =scena.AddLight(DIRECTIONAL); luce2->SetDirection(0,-1,1); luce2->SetDiffuseColor(1,1,1); luce3 =scena.AddLight(DIRECTIONAL); luce3->SetDirection(0.5,0.5,-1); luce3->SetDiffuseColor(1,1,1); cam = scena.GetCameraAddress(); // carico il pavimento Texture_table= scena.GetTextureTableAddress(); #ifdef __SGI pavi = Texture_table->LoadPixmap("/artspeople/indigo/pennello/tesi/MODELLI3D/pavi.ppm"); #endif #ifdef _WIN32 pavi = Texture_table->LoadPixmap("modelli3d\\pavi.ppm"); #endif // NO_TEXTURE non carica le texture // con 0 zero le carica // carico il calice ******************************** #ifdef __SGI //flute->LoadShape("/artspeople/indigo/pennello/tesi/MODELLI3D/calice.rtg",0); flute->LoadShape("/artspeople/indigo/pennello/tesi/MODELLI3D/calice.rtg",0); #endif #ifdef _WIN32 flute->LoadShape("modelli3d\\calice.rtg",NO_TEXTURE); #endif flute->Normalize(1); objFlute->LinkToMesh(flute); objFlute->SetTextureMode(NORMAL); objFlute->SetShading(SMOOTH); objFlute->SetPosition(0,0.95,0); objFlute->SetRotation(-90,1,0,0); // carico la lastra ********************************** #ifdef __SGI plate->LoadShape("/artspeople/indigo/pennello/tesi/MODELLI3D/lastra.rtg",0); #endif #ifdef _WIN32 plate->LoadShape("modelli3d\\lastra.rtg",0); #endif plate->Normalize(3);

99

objPlate->LinkToMesh(plate); objPlate->SetTextureMode(NORMAL); objPlate->SetShading(SMOOTH); objPlate->SetPosition(0,2,0); objPlate->SetRotation(180,0,1,0); objPlate->Rotate(-90,1,0,0); // carico il piedistallo ******************************** #ifdef __SGI pedestal->LoadShape("/artspeople/indigo/pennello/tesi/MODELLI3D/piedistallo.rtg",0); #endif #ifdef _WIN32 pedestal->LoadShape("modelli3d\\piedistallo.rtg",0); #endif pedestal->Normalize(11); objPedestal->LinkToMesh(pedestal); objPedestal->SetTextureMode(NORMAL); objPedestal->SetShading(SMOOTH); objPedestal->SetPosition(0,1,0); objPedestal->SetRotation(-90,1,0,0); scena.SetClearColor(0.37,0.6,0.62); cam->SetPosition(0,3,20); #ifndef POLHEMUS cam->LookAt(0,2,0); #endif } /* ************************************************************** *** funzione di inizializzazione del sistema ** *** initGLUT per la finestra GLUT ** *** display ** ************************************************************** */ void initGLUT(int *argc,char *argv[]) { glutInit(argc,argv); glutInitDisplayMode(GLUT_DOUBLE|GLUT_RGB|GLUT_DEPTH); //#ifdef __SGI // glutInitWindowSize(1140,910); //#endif #ifdef _WIN32 glutInitWindowSize(705,510); #endif glutCreateWindow("Tesi Andrea Brogni - Laboratorio PERCRO - SSSUP"); glutDisplayFunc(display); glutIdleFunc(idle); #ifdef __SGI

100

glutFullScreen(); #endif } // *********************** void display(void) { cout << "aperta finestra GLUT" << endl; #ifdef __SGI glutPositionWindow(140,50); #endif #ifdef _WIN32 glutPositionWindow(92,50); #endif scena.Init(); } // ******************************************************************** // **** funzioni usate nel TRACKER ******************************* // ******************************************************************** static void framerate() { #ifdef __SGI static long lastt=0; static int frames=0; struct tms buf; long t, et; #endif #ifdef _WIN32 static DWORD lastt=0; static int frames=0; DWORD t, et; #endif float rate; if(lastt==0) { #ifdef __SGI lastt=times(&buf); #endif #ifdef _WIN32 lastt=GetTickCount(); #endif return; } if(++frames>=FRAMES) { #ifdef __SGI t=times(&buf); #endif #ifdef _WIN32 t=GetTickCount(); #endif et=t-lastt;

101

rate=((float)(frames*HZ))/et; frames=0; lastt=t; // cerr << "Packets per second: " << rate << "; \n"; fprintf(stderr, "Packets per second: %f \n", rate); } } // *********************************************************************************** // Mode | Receivers Fastrak_Mode Codying Buffering_Strategy framerate // --------------------------------------------------------------------------------- // 1 | 1 continous Binary FIFO ~ 120 // 2 | 1 single Binary NA (Not Appliable) // 3 | 1 continous Ascii FIFO // 4 | 1 single Ascii NA (Not Appliable) // 5 | 1 continous Binary LAST RECENTLY ARRIVED ~ 50 // metto tutto esterno altrimenti non lo vedo da TRACKER #ifdef __SGI int ftrack_mode = 5; #endif //__SGI #ifdef _WIN32 int ftrack_mode = 2; #endif //_WIN32 #ifdef POLHEMUS #ifdef __SGI fastrak ftrack(ftrack_mode, "/dev/ttyd2", 38400); #endif //__SGI #ifdef _WIN32 fastrak ftrack(ftrack_mode, "COM1:", 38400); #endif //_WIN32 #endif //POLHEMUS int IN_FLAG; // serve a TRACKER, INIT_TRACKER e a DEACTIVE_TRACKER // ************************************************************************ void init_tracker() { cout << "attivazione del sensore in modalità " << ftrack_mode << endl; // controlli #ifdef POLHEMUS

102

#ifdef __SGI if ((IN_FLAG = fcntl(STDIN_FILENO, F_GETFL)) == -1) cerr << "Error writing on file stdin;" << endl; if ((fcntl(STDIN_FILENO, F_SETFL, O_NONBLOCK) ) == -1) cerr << "Error writing on file stdin;" << endl; #endif //__SGI #ifdef __SGI // attivazione continous_mode ftrack.continous_mode_active(1); // DA COMMENTARE SE ftrack_mode = 2 OR 4 #endif //__SGI //settaggio dei filtri ftrack.fixed_metal_compensation(1); ftrack.attitude_filter_parameters(0.2, 0.2, 0.8, 0.8); ftrack.position_filter_parameters(0.2, 0.2, 0.8, 0.8); #endif // POLHEMUS } // ******************************************************************* // da mettere solo se ho settato il continous mode (con 5 ) void deactive_tracker() { cout << "DEattivazione del sensore" << endl; #ifdef POLHEMUS #ifdef __SGI // DEattivazione continous_mode del sensore Polhemus ftrack.continous_mode_active(0); // DA COMMENTARE SE ftrack_mode = 2 OR 4 #endif //__SGI #endif } // ******************************************************************* // il dati sono forniti : posizione in METRI in vec_3D pos // orientamento in RADIANTI in vec_3D ori // ******************************************************************* float Xtemp[3], Ytemp[3], Ztemp[3], YAtemp[3], PItemp[3], ROtemp[3]; int STEPtemp; void tracker() { #ifdef POLHEMUS vec_3d pos, ori; ftrack.get_position(pos, ori); //framerate(); // scrive il framerate del Polhemus

103

// FILTRO prendo come valore la media degli ultimi 3 arrivati ++STEPtemp; if (STEPtemp > 2) STEPtemp = 0; // posizione // i valori finali sono in millimetri con due decimali Xtemp[STEPtemp] = -pos.z(); Ytemp[STEPtemp] = pos.x(); Ztemp[STEPtemp] = -pos.y(); XPOS = ((float)((int)((Xtemp[0] + Xtemp[1] + Xtemp[2])*1000/3)))/100; YPOS = ((float)((int)((Ytemp[0] + Ytemp[1] + Ytemp[2])*1000/3)))/100; ZPOS = ((float)((int)((Ztemp[0] + Ztemp[1] + Ztemp[2])*1000/3)))/100; // orientamento // la divisione finale deviva da (1/3)(180/3.14)(10) // i valori finali sono in gradi con un solo decimale YAtemp[STEPtemp] = ori.x(); PItemp[STEPtemp] = -ori.y(); ROtemp[STEPtemp] = ori.z(); YAW = ((float)((int)((YAtemp[0] + YAtemp[1] + YAtemp[2])*600/3.14)))/10; PITCH = ((float)((int)((PItemp[0] + PItemp[1] + PItemp[2])*600/3.14)))/10; ROLL = ((float)((int)((ROtemp[0] + ROtemp[1] + ROtemp[2])*600/3.14)))/10; // controllo finale sulla lettura dal Polhemus #ifdef __SGI if (fcntl(STDIN_FILENO, F_SETFL, IN_FLAG) == -1) cerr << "Error writing on file stdin;" << endl; #endif //__SGI #endif //POLHEMUS }

104

Appendice B: Funzioni generali /* ******* definizioni delle funzioni utilizzate ****************************** *************************************************************************** **/ #include <stdlib.h> #include <string.h> #include <stdio.h> #include <iostream.h> #include <fstream.h> #include "mainACCA.h" #include "funzOpenGL.h" extern int LANG; extern int SCALA; // variabili per il sensore extern float XPOS, YPOS, ZPOS; extern float YAW, PITCH, ROLL; extern float Xtemp[], Ytemp[], Ztemp[], YAtemp[], PItemp[], ROtemp[]; extern int STEPtemp; //variabili per il ridimensionamento delle finestre extern double VH,VL; extern int SIZE1, SIZE2, SIZE3, SIZE4; extern CAMERA *cam; /* ************************************************************** *** funzione per il ridimensionamento delle ** *** finestre in base al monitor ** ************************************************************** ** scelta | definizione del monitor ------------------------------------- 1 | 1280 x 1024 (Ubik) 2 | 1024 x 768 3 | 800 x 600 (LCD) default | 1280 x 1024 (Ubik) ------------------------------------- ********************************** */ void rescale(void) { static int FONTS[]={FL_SMALL_SIZE, FL_NORMAL_SIZE, FL_MEDIUM_SIZE, FL_LARGE_SIZE, FL_HUGE_SIZE}; int i; #ifdef __SGI i = 0; VH = 1; VL = 1; cout << "Applicazione per SGI ... finestra 1280 x 1024" << endl; #endif // *********** #ifdef _WIN32 i = -1; VH = 0.625; // 800/1280 = 0.625

105

VL = 0.586; // 600/1024 = 0.5859375 cout << "Applicazione per WindowNT ... finestra 800 x 600" << endl; #endif SIZE1 = FONTS[++i%5]; SIZE2 = FONTS[++i%5]; SIZE3 = FONTS[++i%5]; SIZE4 = FONTS[++i%5]; } /* ************************************************************** *** funzione di pulizia delle variabili ** *** globali ** ************************************************************** */ void clearAll(void) { LANG = 1; SCALA = 1; XPOS = 0; YPOS = 0; ZPOS = 0; YAW = 0; PITCH = 0; ROLL = 0; STEPtemp = 0; for (int i = 0; i > 2; i++) { Xtemp[i] = 0; Ytemp[i] = 0; Ztemp[i] = 0; YAtemp[i] = 0; PItemp[i] = 0; ROtemp[i] = 0; } } /* ************************************************************** *** funzione di inizializzazione del sistema ** *** initXFORMS per le Xforms ** ************************************************************** */ void initXFORMS(int *argc,char *argv[]) { fl_initialize(argc,argv,0,0,0); create_the_forms0(); create_the_forms11(); } /* ************************************************************** *** CALLTEXT richiama nella stringa FRASE il testo del file ** *** specificato e nella lingua scelta ** *** dal main deve essere lanciata con calltext(testo,frase) ** *** e ritorna il puntatore FRASE, che va inserito come label **

106

*** nell`oggetto della form ** ************************************************************** */ void calltext(char *nomef, char *a) { char ch; int i=0; fstream file; #ifdef __SGI char pat[50]; // path per arrivare alla directory DATA pat = "/artspeople/indigo/pennello/tesi/DATA/"; #endif #ifdef _WIN32 char pat[29]; // path per arrivare alla directory DATA strcpy(pat, "data\\"); #endif char est[5]; if (LANG == 1) strcpy(est, ".ITA"); // estensioni dei file if (LANG == 0) strcpy(est, ".ENG"); char *fname; fname = new char[70]; sprintf(fname, "%s%s%s", pat, nomef, est); // FNAME e` il nome completo del file cout << "il file da aprire e` " << fname << endl; // apre il file file.open(fname,ios::in); if ( !file ) { cerr << "non e` stato aperto correttamente il file " << fname << endl; exit(1); } file.seekg(223, ios::beg); // mi posiziono dopo l`intestazione di 4 linee // operazioni while(file.get(ch)) { a[i] = ch; i++; } a[i] = '\0'; // scrivo la fine in fondo alla stringa di caratteri // chiusura dei file file.close(); return; } /* ****************************************************************** *** SHOWTITLE **

107

*** prima schermata, nella quale viene mostrato il titolo ** ******************************************************************* */ void showTitle(void) { fl_show_form(intestazione,FL_PLACE_POSITION,FL_NOBORDER,NULL); fl_show_form(titolo,FL_PLACE_POSITION,FL_NOBORDER,NULL); image0place(); // piazza le immagini fl_do_forms(); } /* ********************************************************************* *** CHOSEFIRSTLaNG ** *** seconda schermata, nella quale viene scelta la lingua ** ********************************************************************* */ void choseFirstLang(void) { FL_OBJECT *obj; fl_hide_form(titolo); fl_show_form(accensione,FL_PLACE_POSITION,FL_NOBORDER,NULL); obj = fl_do_forms(); if (obj == vaieng) LANG = 0; // LANG=0 lingua scelta INGLESE if (obj == vaita) LANG = 1; // LANG=1 lingua scelta ITALIANO fl_set_object_color(obj,FL_COL1,FL_COL1); fl_set_object_boxtype(obj,FL_ROUNDED3D_DOWNBOX); image0kill(); // modifica le immagini } /* ********************************************************************* *** WRITESCALA ** *** scrive nella finestra il valore cambiato della scala ** *** ed eventualmente spedisce il valore al blocco di visualizzazione ** ********************************************************************* */ void writeSCALA(int from) { char per[5] = ":1"; char *wscala; wscala = new char[10]; double dSCALA; // decide quale zoom e` stato usato e modifica i valori if (from == 0) { dSCALA = fl_get_scrollbar_value(Zoom); SCALA = (int)((10 * dSCALA)+ 0.1); fl_set_scrollbar_value(ZoomPL,dSCALA); } else { dSCALA = fl_get_scrollbar_value(ZoomPL);

108

SCALA = (int)((10 * dSCALA)+ 0.1); fl_set_scrollbar_value(Zoom,dSCALA); } // scrive il testo del rapporto di scala sprintf(wscala, "%d%s", SCALA, per); fl_set_object_label(ScalaNumero,wscala); fl_set_object_label(ScalaNumeroPL,wscala); fl_set_object_label(testoScala,wscala); cout << "zoom al " << wscala << endl; } /* ********************************************************************* *** CREATION ** *** lancia le funzioni di creazione di tutte le form ** ********************************************************************* */ void creation() { create_the_forms1(); create_the_forms2(); create_the_forms22(); create_the_forms3(); create_the_forms4(); create_the_forms5(); create_the_forms6(); create_the_forms7(); //create_the_forms8(); create_the_forms9(); create_the_forms10(); create_the_forms12(); } /* ********************************************************************* *** FREEING ** *** libera la memoria dalla form ormai inutile ** ********************************************************************* */ void freeing() { fl_free_form(accensione); fl_free_form(titolo); // da usare solo se e` cancellato il titolo dal fondo } /* ********************************************************************* *** PRESENTATION ** *** show/hide delle forme di presentazione ** ********************************************************************* */ void presentation() { char frase[MAXFRASE]; // richiamo testo di benvenuto calltext("benvenutoUP",frase); fl_set_object_label(benvUP,frase); calltext("benvenutoDOWN",frase); fl_set_object_label(benvDOWN,frase);

109

fl_hide_form(accensione); fl_show_form(benvenuto,FL_PLACE_POSITION,FL_NOBORDER,NULL); fl_hide_object(butMappe); fl_do_forms(); //attende pressione dello schermo // segnalazione di avvenuta pressione dello schermo fl_set_object_lcol(benvUP,FL_RED); // modifica immagine sulla cornice in alto fl_free_pixmap_pixmap(figDX); #ifdef __SGI fl_set_pixmap_file(figDX,"/artspeople/indigo/pennello/tesi/FOTO/vassoino.xpm"); #endif #ifdef _WIN32 fl_set_pixmap_file(figDX,"foto\\vassoino.xpm"); #endif fl_hide_form(benvenuto); } /* ********************************************************************* *** GENERAL ** *** impostazione menu generale e controllo ** ********************************************************************* */ void general() { char frase[MAXFRASE]; calltext("bibliografiaUP",frase); // richiamo testo della bibliografia fl_set_object_label(benvUP,frase); calltext("bibliografiaDOWN",frase); fl_set_object_label(benvDOWN,frase); fl_set_object_lalign(benvUP,FL_ALIGN_LEFT_TOP); // restyling di testi sulla bibliografia fl_set_object_lsize(benvDOWN,SIZE2); fl_set_object_lstyle(benvDOWN,FL_TIMES_STYLE); fl_show_object(textMenu); fl_free_pixmap_pixmap(textMenu); #ifdef __SGI fl_set_pixmap_file(textMenu,"/artspeople/indigo/pennello/tesi/FOTO/IVESlittle.xpm"); #endif #ifdef _WIN32 fl_set_pixmap_file(textMenu,"foto\\IVESlittle.xpm"); #endif fl_show_form(menu_generale,FL_PLACE_POSITION,FL_NOBORDER,NULL); fl_do_forms(); // tolto per riparare il problema di conflitto con il glutMainLoop }

110

/* ********************************************************************* *** PLACE IMAGE 0 ** *** piazza le immagini nelle form Intestazione e Accensione ** *** usata in choseFirstLang ** ********************************************************************* */ void image0place() { cout << "piazzo le immagini iniziali" << endl; fl_show_object(figDX); fl_show_object(figSX); fl_show_object(figCENTRO); fl_free_pixmap_pixmap(figDX); fl_free_pixmap_pixmap(figSX); fl_free_pixmap_pixmap(figCENTRO); #ifdef __SGI fl_set_pixmap_file(figSX,"/artspeople/indigo/pennello/tesi/FOTO/sinistra1.xpm"); fl_set_pixmap_file(figDX,"/artspeople/indigo/pennello/tesi/FOTO/fiori.xpm"); fl_set_pixmap_file(figCENTRO,"/artspeople/indigo/pennello/tesi/FOTO/doppio.xpm"); #endif #ifdef _WIN32 fl_set_pixmap_file(figSX,"foto\\sinistra1.xpm"); fl_set_pixmap_file(figDX,"foto\\fiori.xpm"); fl_set_pixmap_file(figCENTRO,"foto\\doppio.xpm"); #endif } /* ********************************************************************* *** KILL IMAGE 0 ** *** cancella le immagini nelle form Intestazione e Accensione ** *** usata in choseFirstLang ** ********************************************************************* */ void image0kill() { fl_free_pixmap_pixmap(figDX); #ifdef __SGI fl_set_pixmap_file(figDX,"/artspeople/indigo/pennello/tesi/FOTO/bordino.xpm"); #endif #ifdef __WIN32 fl_set_pixmap_file(figDX,"foto\\bordino.xpm"); #endif } /* ********************************************************************* *** WICHCOMMENT ** *** scelta della figura da commentare ** ************************************************************************

111

*** la retta che descrive la direzione della telecamera e` scritta ** *** come d2*x1- ** *** d3*x1- ** *** passante per il punto (a1 a2 a3) e parallela a (d1 d2 d3) ** ********************************************************************* */ char* wichComment() { #ifndef POLHEMUS const char *Cscelta; char *scelta; fl_show_form(sceltaCOM,FL_PLACE_CENTER,FL_FULLBORDER,NULL); fl_do_forms(); fl_hide_form(sceltaCOM); Cscelta = fl_get_choice_text(MenuCOM); scelta = (char *)Cscelta; #endif // non POLHEMUS #ifdef POLHEMUS char *scelta; scelta = ""; float a1,a2,a3,d1,d2,d3; float direzCam[3]; // impostazione variabili cam->GetDirection(direzCam); a1 = XPOS; a2 = YPOS; a3 = ZPOS; d1 = direzCam[0]; d2 = direzCam[1]; d3 = direzCam[2]; // determino il settore dove si trova la camera float x1, x2, x3; int A; if ((a1>0)&&(a3<0)) { A = 0; x1 = (d3*a1-d1*a3-d1)/(d3-d1); x3 = x1 - 1; } else if ((a1>0)&&(a3>0)) { A = 1; x1 = (d3*a1-d1*a3+d1)/(d3+d1); x3 = 1 - x1; } else if ((a1<0)&&(a3>0)) { A = 2; x1 = (d3*a1-d1*a3+d1)/(d3-d1);

112

x3 = 1 + x1; } else { A = 3; x1 = (d3*a1-d1*a3-d1)/(d3+d1); x3 = -1 - x1; }; x2 = (d2*x1-d2*a1+d1*a2)/d1 + 2; // controllo se e` dentro la sfera modulo 1 if ((sqrt(x1*x1+x3*x3))<3) { // controllo su quale fascia si trova float H1 = 0.25; float H2 = 0.38; float H3 = 0.78; float H4 = 0.92; static char *FIGURE[]={"Osiri","Ancella","Guerriero","Santino"}; if ((x2>H1)&&(x2<H4)) { scelta = "Decorazioni"; if ((x2>H2)&&(x2<H3)) scelta = FIGURE[A]; } } #endif //POLHEMUS return scelta; } /* ********************************************************************* *** NEWLANG ** *** sono le funzioni di settaggio della lingua nelle label ** ********************************************************************* */ void newLang2() { cout << "caricamento testi form commenti" << endl; char *torna = "Ritorno\n\nalla\n\nEsplorazione\n\nVirtuale"; if (LANG == 0) { torna = "Return\n\nto the\n\nVirtual\n\nExploration"; } fl_set_object_label(back_to_image,torna); } // ******************************************************* void newLang3() {

113

cout << "caricamento testi form generale" << endl; char *aiuto = "AIUTO"; char *lingua = "CAMBIO\nDELLA\nLINGUA"; char *biblio = "BIBLIOGRAFIA\n\nNOTIZIE\nGENERALI"; char *chiudi = "USCITA \nDAL\nSISTEMA"; char *fabbrica = "FASI DI\nFABBRICAZIONE"; char *vplanare = "VISIONE\nPLANARE"; char *v3D = "VISIONE\n3D"; if (LANG == 0) { aiuto = "HELP"; lingua = "CHANGE\nTHE\nLANGUAGE"; biblio = "BIBLIOGRAPHY\n\nGENERAL\nINFORMATIONS"; chiudi = "QUIT"; fabbrica = "STEPS OF\nMANUFACTURING"; vplanare = "PLANAR\nVISION"; v3D = "3D\nVISION"; } fl_set_object_label(butCLOSE,chiudi); fl_set_object_label(butLANG,lingua); fl_set_object_label(butHELP,aiuto); fl_set_object_label(butV3D,v3D); fl_set_object_label(butPLANAR,vplanare); fl_set_object_label(butMAKE,fabbrica); fl_set_object_label(butBIBLIO,biblio); char frase[MAXFRASE]; calltext("bibliografiaUP",frase); // richiamo testo della bibliografia fl_set_object_label(benvUP,frase); calltext("bibliografiaDOWN",frase); fl_set_object_label(benvDOWN,frase); } // ****************************************************** void newLang4() { cout << "caricamento testi form cambio lingua" << endl; char *butITA = "Premendo\nquesto pulsante si sceglie\ncome lingua\n\n\nITALIANO"; char *butENG = "Premendo\nquesto pulsante si sceglie\ncome lingua\n\n\nINGLESE"; char *titolo = "CAMBIO DELLA LINGUA DI CONSULTAZIONE"; if (LANG == 0) { butITA = "This button is to\nchose as language\n\n\nITALIAN"; butENG = "This button is to\nchose as language\n\n\nENGLISH"; titolo = "CHANGE OF THE CONSULTATION LANGUAGE"; } fl_set_object_label(scegliENG,butENG); fl_set_object_label(scegliITA,butITA); fl_set_object_label(cambioLtesto,titolo);

114

} // ****************************************************** void newLang5() { cout << "caricamento testi form menu help" << endl; char *ritorna = "RITORNA AL\n\nMENU\n\nGENERALE"; char *gener = "MENU\n\nGENERALE"; char *vis3 = "VISIONE 3D"; char *vplan = "VISIONE\n\nPLANARE"; char *fabbr = "FASI DI\n\nFABBRICAZIONE"; char frase[MAXFRASE]; if (LANG == 0) { ritorna = "BACK\n\nTO\n\nMAIN MENU"; gener = "MAIN MENU"; vis3 = "3D VISION"; vplan = "PLANAR\n\nVISION"; fabbr = "STEPS OF\n\nMANUFACTURING"; } fl_set_object_label(ReturnToMenu,ritorna); fl_set_object_label(butGENER,gener); fl_set_object_label(butVIS3D,vis3); fl_set_object_label(butVISPLAN,vplan); fl_set_object_label(butFABBR,fabbr); } // ****************************************************** void newLang6() { cout << "caricamento testi form conferma close" << endl; char *torna = "NO\n\nRITORNA\n\nAL\n\nMENU\n\nGENERALE"; char *richiesta = "Sei sicuro di voler uscire\n\ndal sistema di consultazione ?"; char *vai = "SI\n\n\n\nCHIUSURA\n\nDEL\n\nSISTEMA"; if (LANG == 0) { torna = "NO\n\n\nBACK\n\nTO\n\nMAIN\n\nMENU"; richiesta = "Are you sure\n\nyou really want\n\nquit the system ?"; vai = "YES\n\n\n\n\nQUIT\n\nTHE\n\nSYSTEM"; } fl_set_object_label(testoConf,richiesta); fl_set_object_label(butYESclose,vai); fl_set_object_label(butNOclose,torna); } // *******************************************************

115

void newLang7() { cout << "caricamento testi form pulsanti 3D" << endl; char *centra = "CENTRA\n\nCALICE"; char *torna = "MENU\n\nGENERALE"; char *testo = "COMMENTO\n\nIMMAGINE"; if (LANG == 0) { centra = "CENTRE\n\nFLUTE"; torna = "MAIN\n\nMENU"; testo = "IMAGE\n\nCOMMENT"; } fl_set_object_label(butCENTRA,centra); fl_set_object_label(butRetMenu,torna); fl_set_object_label(butCOMMENTO,testo); } // ****************************************************** void newLang9() { cout << "caricamento testi form fabbricazione" << endl; char *fs1 = "FASE\n\n1"; char *fs2 = "FASE\n\n2"; char *fs3 = "FASE\n\n3"; char *fs4 = "FASE\n\n4"; char *fs5 = "FASE\n\n5"; if (LANG == 0) { fs1 = "PHASE\n\n1"; fs2 = "PHASE\n\n2"; fs3 = "PHASE\n\n3"; fs4 = "PHASE\n\n4"; fs5 = "PHASE\n\n5"; } fl_set_object_label(butFASE1,fs1); fl_set_object_label(butFASE2,fs2); fl_set_object_label(butFASE3,fs3); fl_set_object_label(butFASE4,fs4); fl_set_object_label(butFASE5,fs5); } // ******************************************************* void newLang10() { cout << "caricamento testi form pulsanti planari" << endl; char *torna = "MENU\n\nGENERALE"; char *testo = "CENTRA\n\nCALICE"; if (LANG == 0) {

116

torna = "MAIN\n\nMENU"; testo = "CENTRE\n\nFLUTE"; } fl_set_object_label(butMenuPL,torna); fl_set_object_label(butCentraPL,testo); } // ****************************************************** void newLang12() { cout << "caricamento testi form mappe" << endl; char *m1 = "Calice gemello"; char *m2 = "Mappa de Sudan"; char *m3 = "Luogo del ritrovamento"; char *m4 = "Calice nel Museo"; char *but = "R I T O R N O"; char *butMap = "M\nA\nP\nP\nE"; if (LANG == 0) { m1 = "The twin flute"; m2 = "Map of Sudan"; m3 = "Place of the discovery"; m4 = "Flute in the Museum"; but = "R E T U R N"; butMap = "M\nA\nP\nS"; } fl_set_object_label(corniceMappa1,m1); fl_set_object_label(corniceMappa2,m2); fl_set_object_label(corniceMappa3,m3); fl_set_object_label(corniceMappa4,m4); fl_set_object_label(butM1,but); fl_set_object_label(butM2,but); fl_set_object_label(butMappe,butMap); // e` il pulsante che si trova nella form // BENVENUTO del file t01_intro } // ******************************************************

117

Bibliografia

Si adotta la seguente convenzione per i riferimenti bibliografici: si indica il cognome del autore seguito dalla data di stampa. Se il testo è stato scritto da più persone viene usato solo il primo cognome.

[ALIAS1_98] AA.VV. NURBS modelling in Alias Alias|Wavefront Silicon Graphics - 1998 [ALIAS2_98] AA.VV. Rendering in Alias Alias|Wavefront Silicon Graphics - 1998 [ALIAS3_98] AA.VV. Polygonal modelling in Alias Alias|Wavefront Silicon Graphics – 1998 [ALIAS4_98] AA.VV. Games Data Transfer Alias|Wavefront Silicon Graphics - 1998 [BRESCIANI_92] E. Bresciani, F. Silvano

118

La collezione Schiff Giorgini Ed. Giardini - 1992 [BRILL_91] R.H. Brill Scientific investigations of some glasses from Sedeinga JGS 33 - 1991 [BRYSON_92] S. Bryson Measurement and calibration of static distortion of position data from 3D trackers RNR Tecnical Report - 1992 [BURDEA_94] G. Burdea - P. Coiffet Virtual Reality Technology Wiley - Interscience - 1994 [DAVIS_97] T. Davis The GLUT Library Innovation3 - summer 1997 [DELORENZO_96] A. De Lorenzo Toy Story Dossier Computer Grafica - giu./sett. 1996 [FORSBERG_97] A.S. Forsberg, J.J. LaViola, L. Markosian, R.C. Zeleznik Seamless interaction in virtual reality Computer Graphics and Application - IEEE - nov./dec. 1997

119

[FORTE_96] M. Forte - A. Siliotti ( a cura di) Archeologia: percorsi virtuali nelle civiltà scomparse Mondadori - 1996 [KILGARD_97] M.J. Kilgard The OpenGL Utility Toolkit (GLUT) Programming Interface - API Version 3 Silicon Graphics, Inc. - 1997 [KING_97] C.F. King Medical Volume Visualization Innovation3 - summer 1997 [LECLANT_73] J. Leclant Glass from the Meroitic necropolis of Sedeinga JGS - 1973 [MATTHIAE_95] P. Matthiae Ebla - Un impero ritrovato Einaudi - 1995 [MAZZEO_97] F. Mazzeo Architettura al calcolatore Computer Grafica - ott./nov. 1997 [ROEHL_97] B. Roehl Virtual Archaeology Innovation3 - summer 1997

[SHERIDAN_92] T.B. Sheridan

120

Telerobotics, Automation and human supervisory control The MIT Press - 1992 [SIMS_97] D. Sims Archaeological Models: pretty pictures or research tools ? Computer Graphics and Application - IEEE - jan./feb. 1997 [WALTZ_97] M. Waltz New immersive display heat up high-end visualization Innovation3 - summer 1997 [ZHAO_97] T.C. Zhao Forms Library - A Graphical User Interface Toolkit for X Department of Physics, University of Wisconsin- Milwaukee 1997.

Università degli studi di Pisa - UCL Computer Science · Prof. Paolo Ancilotti Prof. Graziano...

Documents

Transcript of Università degli studi di Pisa - UCL Computer Science · Prof. Paolo Ancilotti Prof. Graziano...