Sofia Pescarin, Bruno Fanini, daniele Ferdani, Guido Lucci ... · Aquae Patavinae. Montegrotto terme e il termalismo in italia ar C h e o l o g i a v i r t u a l e a mo n t e g r

Aquae Patavinae. Montegrotto terme e il termalismo in italia

arCheologia virtuale a montegrotto terme

Sofia Pescarin, Bruno Fanini, daniele Ferdani, Guido Lucci Baldassari

1. introDuzione

1.1 oBiettivi e requisiti

«the principles of the London Charter are valid wherever computer based visualization is applied to the research or dissemination of cultural heritage» [L.C. Principle 1]

L’archeologia virtuale è una disciplina, di recente definizione, che si occupa di studiare, simu-lare, ricostruire le differenti potenziali realtà del paesaggio archeologico ed antico, secondo un ap-proccio scientifico teorico esplicito1. Nonostante i principi su cui si fonda siano tuttora oggetto di discussione nell’ambito della comunità scientifica internazionale, in seguito all’accordo e alla pub-blicazione della Carta di Londra, nel 2006, sono stati definiti sei fondamenti di base, che possono essere considerati come punti di riferimento per ogni progetto di archeologia virtuale e più in ge-nerale di visualizzazione scientifica applicata al patrimonio culturale. I principi della Carta di Lon-dra, arrivata alla versione 2.1 pubblicata nel febbraio del 2009, sono stati presi come riferimento nel progetto Aquae Patavinae, che rientra nel più ampio quadro di riferimento del progetto PRIN («il termalismo in età romana tra conoscenza e valorizzazione»). Nei paragrafi successivi verrà descrit-to l’approccio seguito, prendendo come riferimento le indicazioni della Carta di Londra.

«A computer-based visualization method should normally be used only when it is the most appropri-ate available method for that purpose» [L.C. Principle 2]

L’area termale ai piedi dei Colli Euganei, soprattutto quella che ricade all’interno del comu-ne di Montegrotto Terme, è caratterizzata da un solo sito archeologico di primaria importanza aperto al pubblico (area archeologica di Via Scavi). Le altre emergenze archeologiche oggetto di studio e di scavo da parte della Soprintendenza e dell’Università di Padova, sebbene di grande interesse per la comprensione storica del territorio, non sono invece visitabili o visibili (come nel caso dell’area di Via Neroniana, dell’Hotel Terme Neroniane e di Turri). In altri casi ancora le evidenze sono disperse e non facilmente riconoscibili, emergendo esclusivamente dal lavoro di ricognizione, dai sondaggi, dall’interpretazione aerea e dallo studio storico. Il contesto stori-co si presenta quindi complesso, sfaccettato e di difficile interpretazione per gli stessi ricercato-ri. Per tali motivi risultava di fondamentale importanza definire uno strumento che consentis-se di raccogliere e integrare i diversi risultati delle ricerche, renderli disponibili ad un gruppo di ricerca multidisciplinare, anche creando dei momenti di lavoro condiviso, ed infine consentire un accesso per un pubblico più ampio ai risultati via via emergenti dagli studi.

Lo strumento più appropriato avrebbe dovuto dunque prevedere un approccio visivo; con-sentire l’elaborazione di dati reali (reality-based), spazialmente corretti, acquisiti sul campo; si-

1 renfreW, Bahn 1995; Calori, Camporesi, pesCarin 2009.


306 sofia pesCarin, Bruno fanini, Daniele ferDani, guiDo luCCi BalDassari

mulare a partire da tali dati una o più ricostruzioni potenziali; consentire di aggiornare in manie-ra rapida le simulazioni e le ricostruzioni in modo da fornire anche agli utenti “generici” sempre una versione scientificamente corretta. Tra gli strumenti a disposizione il team si è orientato verso lo sviluppo di un’applicazione di realtà virtuale GiS-based, basata su dati spaziali (vr webGiS), e accessibile on line. Accanto e a supporto di questa soluzione si è optato anche per “output” in-formatici lineari e non interattivi, quali rendering statici e filmati in computer grafica.

1.2 utenti, oBiettivi, stili ComuniCativi

La scelta di adottare una soluzione di visualizzazione tridimensionale e interattiva, inte-grandola con altri strumenti non interattivi, è stata presa per poter rispondere alle diverse esi-genze del progetto. Mentre il progetto Aquae Patavinae, infatti, ha come riferimento principale la comunicazione pubblica del paesaggio euganeo, il progetto PRIN ha invece un obiettivo più a lunga durata, quale quello dello studio e della comprensione degli ambiti termali salutiferi del-la penisola italiana in età romana, attraverso la ricerca e l’integrazione di diverse banche dati.

Da recenti studi nel campo della comunicazione e dell’analisi dei visitatori nel settore dei musei virtuali, è emerso come nella progettazione di un sistema informatico finalizzato alla co-municazione due sono gli elementi fondamentali che distinguono gli utenti: la presenza o l’as-senza di esperienza, sia nel campo specifico trattato dai contenuti (nel nostro caso l’archeologia romana), sia in ambito informatico (ad esempio l’uso di sistemi interattivi). Nella tabella 1 si è cercato di raccogliere, semplificando, i quattro possibili utenti del progetto Aquae Patavinae. I tipi 3 e 4 comprendono un sottotipo, ovvero gli utenti-utilizzatori che fanno parte del gruppo di ricerca e che devono poter condividere, modificare, aggiungere dati al sistema.

Un’applicazione di archeologia virtuale può avere le più svariate funzionalità. Nel progetto europeo V-MUST.NET (www.v-must.net) ne sono state individuate sei: formazione, edutain-ment, incremento dell’esperienza di visita (enhancement of visitor experience), divertimento, promozione e ricerca [Del. 2.1 accessibile on line]. Nel caso del progetto Aquae Patavinae due sono stati gli obiettivi primari: edutainment e ricerca. Nel primo caso l’obiettivo si è incentrato sulla realizzazione di un’applicazione in grado di fornire informazioni sulla storia e sull’evolu-zione del paesaggio archeologico, utilizzando le modalità del gioco finalizzate alla trasmissione delle informazioni2. Nel secondo caso si è tentato di costruire un sistema prototipale dal carat-tere innovativo, che potesse integrare dati di varia natura (3d, terreni, multimedia, informazioni testuali) in maniera collaborativa.

Per ogni tipo di utente e a seconda degli obiettivi del progetto dovrebbe essere sempre de-finito ed utilizzato uno specifico stile comunicativo. Se ne possono individuare principalmente tre: drammatizzazione, esposizione e narrazione [V-Must-Del. 2.1]. Nel primo caso (dramma-tizzazione) il messaggio viene consegnato al “ricevente” attraverso la ricostruzione e presen-tazione di eventi, racconti, azioni in modo profondamente coinvolgente. Nel secondo caso (esposizione) eventi, monumenti, azioni, oggetti vengono descritti, definiti, interpretati dall’ “emittente” che li consegna in maniera esplicita e conscia al “ricevente”, anche attraverso rap-presentazioni schematiche e concettuali. Nel terzo caso, infine, (narrazione) le informazioni su-gli eventi, sui monumenti, ecc., vengono messe insieme in sequenza (ad esempio cronologica), in modo da consegnare al “ricevente” un resoconto, utilizzando anche descrizioni e interpreta-zioni attraverso rappresentazioni schematiche.

La tabella 1 sintetizza il lavoro di analisi iniziale in cui si sono definiti per ogni utente i re-quisiti di progetto e gli strumenti da sviluppare.

2 miChael, Chen, 2006.


arCheologia virtuale a montegrotto terme 307

utenti requisiti strumento

1: non esperto nei contenuti; non esperto di informatica

edutainment- richiede informazioni generali in maniera semplice, attraverso una visualizzazione realistica e stile drammatico/narrativo

lineare, narrativo, non interattivo

2: non esperto nei contenuti; esperto di informatica

edutainment- richiede informazioni generali, attraverso una visualizzazione realistica e stile drammatico/narrativo

lineare, narrativo, inter-attivo (con poche scelte possibili)

3: esperto nei contenuti; non esperto di informatica3a. ricercatore

edutainment/research- richiede informazioni specifiche in maniera semplice, attraverso una visualizzazione dinamica e stile espositivo

non lineare, espositivo, interattivo (con interfaccia utente semplificata)

4: esperto nei contenuti; esperto di informatica4a. ricercatore

edutainment/research- fornire informazioni specifiche, attraverso una visualizzazione di-namica e stile espositivo

non lineare, espositivo, interattivo

Dall’analisi condotta si è concluso che si sarebbero dovuti sviluppare due tipi principali di strumenti:

un museo virtuale on line (1 – front-end), incentrato sulle tematiche archeologiche e composto da due sottosezioni:

la prima multimediale, con interazione semplice e limitata a poche azioni possibili, final-a) izzata a fornire informazioni sui siti archeologici e su come potevano apparire attraverso ricostruzioni tridimensionali visibili attraverso immagini e video. Accanto alle ricostru-zioni vengono fornite informazioni sul processo interpretativo seguito. Questa sezione, basata su HTML standard è potenzialmente accessibile ad ogni tipo di utente, non espe-rto, interessato alla storia del territorio.la seconda sezione di realtà virtuale, interattiva (“b) device-based interaction”) , non immer-siva, con stile comunicativo espositivo, accessibile on line da utenti in possesso di PC o Mac di ultima generazione e accesso ad una rete veloce, attraverso un plug-in open source OSG4WeB (si veda paragrafo 3.2.2). Tale sezione è il risultato principale del lavoro del CNR nell’ambito del progetto.

un sistema interattivo on line di gestione dei contenuti digitali (2 – back-end) con interazione avanzata accessibile a soli utenti registrati che possono modificare i dati, aggiungerne di nuovi, integrarli e commentarli.

«in order to ensure the intellectual integrity of computer-based visualisation methods and outcomes, relevant research sources should be identified and evaluated in a structured and documented way». [L.C. Principle 3]

«Sufficient information should be documented and disseminated to allow computer-based visualiza-tion methods and outcomes to be understood and evaluated in relation to the contexts and purposes for which they are deployed». [L.C. Principle 4]

Ogni progetto di archeologia virtuale deve consentire l’identificazione delle fonti utilizzate nel-la ricostruzione tridimensionale del patrimonio culturale. Seguendo tale principio si è seguito un ap-proccio “assistito” alla ricostruzione (si veda paragrafo 2). Il percorso logico seguito e le fonti uti-lizzate sono state documentate in corso d’opera, messe in relazione ai modelli 3D ricostruiti. Tale documentazione è stata poi ripresa e organizzata in maniera più semplice e comunicativa in modo da costruire delle schede di riferimento pensate per essere una guida al visitatore. [L.C. Principle 3]

Il processo di documentazione dell’intero lavoro di acquisizione, interpretazione e rico-struzione è anch’esso stato oggetto di attenzione [L.C. Principle 4]. Si è previsto di integrare le schede di riferimento dei singoli edifici con indicazioni relative a:

tecnologia di acquisizione utilizzata, risoluzione, accuratezza, localizzazione del dato − “raw” originario



istituzione di riferimento, nome del/dei modellatore− specifiche di post-processing del dato acquisito, parametri di semplificazione, − localizzazione del dato finale ottenuto

Per quanto riguarda i modelli ricostruiti manualmente, si è optato per rendere esplicite le ipotesi interpretative consentendo di caricare il modello in trasparenza sul dato reale (si veda paragrafo 2.1.2). Si è poi preferito indicare nella scheda di riferimento:

tecnologia di modellazione adottata e localizzazione del modello− istituzione di riferimento, nome del/dei modellatore− fonti− grado di affidabilità della ricostruzione−

La decisione di inserire anche informazioni legate alla localizzazione dei dati “raw” origi-nari e di quelli elaborati nel corso di progetto è stata presa per venire incontro alle esigenze di sostenibilità del progetto e per evitare la perdita di dati digitali, che si traducono in termini di perdita intellettuale, sociale ed economica della comunità non solo scientifica ma anche civile [L.C. Principle 5]. La scelta di prevedere l’accesso on line a tali dati in modalità differenziate (per utenti registrati e non) e prendendo in considerazione le esigenze di protezione degli stessi (IPR) ha orientato lo sviluppo della sezione back-end del progetto. [L.C. Principle 6]

Sofia Pescarin

2. riCostruzione Del paesaggio arCheologiCo

La ricostruzione virtuale del paesaggio archeologico, ha rappresentato una delle mete più impegnative e complesse nell’ambito del progetto di ricerca, valorizzazione e divulgazione del territorio euganeo.

Come accennato, lo scopo principale del lavoro è stato quello di realizzare un’applicazione di realtà virtuale finalizzata alla ricostruzione tridimensionale dei maggiori siti archeologici di Montegrotto e alla creazione di un sistema interattivo destinato alla fruizione di questi all’inter-no di un ambiente immersivo generato su web in tempo reale. I siti in questione sono:

area archeologica di Via Scavi (teatro, terme, sistema di captazione e distribuzione delle − acque costituito da due norie e canaliz-zazioni);area archeologica di Via Neroniana (vil-− la di età imperiale);area archeologica di Turri (villa rustica − di età tardo repubblicana - imperiale)

Come spesso accade di fronte a reperti ar-cheologici, il dato fisico intero non esiste più, al suo posto rimangono tracce lacunose, com-prensibili solo da specialisti. Si è reso dunque indispensabile raggiungere l’obiettivo di ri-creare e rappresentare in uno scenario virtua-le il frutto di analisi ed interpretazione dei dati scientifici, cosa che ha richiesto un approccio multidisciplinare al lavoro, condotto da un équipe di ricercatori con differenti competen-ze tecniche, e l’impiego di metodologie e tec-nologie di recente sviluppo.

Fig. 1. Schema del flusso di lavoro adottato per la co-struzione dei modelli virtuali dei siti archeologici.

Daniele

Nota

Inserire citazione in nota: Bacelo, Forte, Sanders 2000.

Daniele

Evidenziato



Il continuo rapporto tra differenti le figure professionali del gruppo di lavoro, composto da informatici, modellatori, archeologi, architetti e storici, è stato uno dei momenti essenziali alla base del processo di ricostruzione. Il confronto, l’integrazione e la verifica delle rispettive atti-vità e risultati, ha permesso infatti di coordinare gli sforzi producendo una base scientifica forte e attendibile su cui strutturare il modello virtuale, cioè la descrizione formale tridimensionale di un oggetto, per la quale non viene utilizzato un dato fisico, ma “un’informazione virtuale”3.

Di seguito sono elencati tutti i passaggi del flusso di lavoro (fig. 1) e le competenze coinvol-te per realizzare il progetto:

Acquisizione dati1 – : Prima ed essenziale fase del lavoro, propedeutica all’elaborazione di mo-delli ricostruttivi, è quella in cui è stata acquisita tutta la documentazione esistente sui mo-numenti in questione e che può essere organizzata in due tipologie di dati:

Documentazione architettonica: come informazione geometrica di partenza per a) l’elaborazione dei modelli, sono stati impiegati dati provenienti da diverse attività e tec-niche di acquisizione 3D reality based (fotogrammetria e laser scanning) effettuate dal CNR-ITABC di Roma e rilievi 2D svolti dall’Università di Padova (stazione totale, rilievi archeologici). Documentazione storico-archeologica: come supporto alla ricostruzione filologica è b) stato fatto riferimento a tutte le fonti scritte ed iconografiche edite ed inedite riguardanti i siti, messe a disposizione dalla Soprintendenza per i Beni Archeologici del Veneto e dall’Università di Padova.

Confronto con referente scientifico2 – : I dati raccolti sono stati analizzati e discussi assieme ad un referente scientifico rappresentato dai funzionari e tecnici della Soprintendenza al fine formulare le prime proposte ricostruttive corrette delle architetture storiche simulando la situazione originaria degli edifici. Le ipotesi sono state strutturate seguendo due approcci:

approccio storico-archeologico: ipotesi ricostruttiva basata su analisi stratigrafiche degli a) elevati, analisi crono-tipologiche, analisi storico-artistiche, confronti stilistici;approccio architettonico: ipotesi ricostruttiva basata sulla metrologia romana, fonda-b) menti di architettura antica, analisi strutturali sulle evidenze archeologiche.

rappresentazione digitale delle ipotesi e validazione3 – . A questo livello operativo, è stata di fondamentale importanza la figura del “modellatore”, il quale, dopo aver ricevuto le diret-tive tecniche dal referente scientifico, ha costruito le prime versioni dei modelli 3D e resti-tuito ai resti archeologici una completezza architettonica e decorativa mediante “restauro virtuale”. Di seguito è stata condotta una seconda fase di discussione, verifica e selezione sulle precedenti ipotesi, ora “materializzate” digitalmente, nella quale gli esperti hanno nuo-vamente vagliato la bontà formale dei modelli. Da sottolineare questo passaggio nel flusso di lavoro, definito per “prove ed errori”4, in quanto momento determinante di confronto e integrazione fra le diverse professionalità5. In questa fase infine, è stato concordemente scelto e validato, sulla base dei dati in possesso, il modello ricostruttivo filologicamente più affidabile, scartando le ipotesi fallaci. Il 3D, oltre a strumento di comunicazione, si è dunque rivelato un grande supporto alla ricerca permettendo di analizzare visivamente e mettere a confronto differenti ipotesi6. Tale approccio è stato di particolare aiuto nello studio e nella scelta delle soluzioni di copertura e orientamento delle falde del teatro di Via Scavi e nella definizione dei peristilii della villa romana di Via Neroniana.

3 Borra 2000, p. 259. 4 Borra 2000, p. 260. 5 sCagliarini Corlaita, guiDazzoli, salmon Cinotti 2003, p. 240. 6 Sui modelli virtuali come mezzo di verifica di interpretazioni scientifiche, cfr. hynst et alii 2001; green,

Cosmass, itagaki 2001.



elaborazione dei Modelli 3d definitivi4 – . La modellazione del paesaggio archeologico è sta-ta condotta utilizzando due differenti tecniche e software di modellazione 3D: manuale e procedurale. Nel paragrafo successivo viene rimandata una descrizione più dettagliata delle tecniche e le scelte ricostruttive impiegate.

daniele Ferdani

2.1 moDellazione 3D

Di seguito vengono esposte le fasi operative e le scelte tecniche impiegate per la realizzazio-ne dei modelli destinati ad una fruizione real time.

2.1.1 Modellazione 3d del territorio

Un GIS è stato costruito come strumento di base del lavoro di ricostruzione territoriale, basato su software open source (GRASS e Quantum GIS). Qui sono stati fatti confluire tutti i dati raster e vettoriali provenienti dai diversi gruppi di ricerca. Il GIS è stato via via aggiorna-to e caricato su un repository FTP condiviso tra CNR e Università di Padova. La ricostruzio-ne del paesaggio archeologico ha utilizzato come dato di partenza il rilievo LIDAR messo a di-sposizione dalla Regione Veneto. Il DTM da esso derivato, insieme alle riprese aeree a 1 mt di risoluzione, è stato riproiettato nel sistema di coordinate prescelto (Gauss Boaga Fuso Ovest), e integrato con due DTM di dettaglio derivati da riprese da Drone disponibili per l’area di via Scavi e di via Neroniana. Il DTM è poi stato traslato all’interno del GIS attraverso un script che ha consentito di mantenere le caratteristiche del sistema di proiezione, modificandone soltan-to i parametri di false easting e false northing in modo da far ricadere il centro dell’area oggetto di studio in coordinate 0,0. Lo stesso script è stato utilizzato per riproiettare tutti i dati raster e vettoriali acquisiti ed inseriti nel GIS. Tale passaggio risulta di fondamentale importanza ogni qualvolta si debba passare da un sistema geografico ad un sistema di gestione in tempo reale dei dati o di modellazione tridimensionale, nei quali l’utilizzo di coordinate x,y con valori troppo alti risulta problematico. I dati GIS sono stati utilizzati per generale il territorio in tre dimen-sioni paginato con il tool OSGdem, della libreria OpenSceneGraph, e come base per la model-lazione procedurale dell’intero comune di Montegrotto.

Allo stato attuale si è provveduto a modellare solo il paesaggio archeologico, ovvero il pa-esaggio attuale in cui le emergenze archeologiche vengono contestualizzate diacronicamente. Nel proseguimento del progetto si prevede di ricostruire anche il paesaggio potenziale antico.

Sofia Pescarin

2.1.2 Modellazione 3d dei siti archeologici

La ricostruzione dei siti archeologici è stata condotta con approccio manuale adottando il metodo della modellazione solida poligonale ed utilizzando i software Blender e Autodesk 3dStudio Max. La procedura di modellazione dei diversi corpi di fabbrica si è basata princi-palmente sull’estrusione dei profili 2D degli elementi rilevati nelle piante e sezioni o di quelli ricavati dai modelli grezzi ottenuti da scansione 3D e ottimizzati per l’impiego in ambienti di computer grafica. Nella ricostruzione sono state mantenute le irregolarità geometriche origina-li più evidenti, mentre quelle dovute a fenomeni di assestamento o crollo, come i profili irrego-lari delle strutture e i fuori piombo delle pareti, sono state eliminate in quanto non rispondenti all’impianto originario. Per esigenze di schematizzazione dei modelli, le piccole irregolarità ar-chitettoniche sono state approssimate. Tutti i modelli sono stati realizzati utilizzando una mo-dellazione low poly, ovvero a basso numero di poligoni, tuttavia la topologia originaria dell’ar-

Daniele

Nota

Inserire citazione in nota: Pescarin, 2009.

Daniele

Evidenziato



chitettura è stata mantenuta al fine di garantire la coerenza col dato archeologico di base. Il basso numero poligonale è giustificato dalla necessità di impiegare, in ambienti real time (RT), modelli 3D “leggeri” al fine di migliore le performance grafiche e velocizzare il rendering nei motori RT. Per migliorare l’appeal grafico dei modelli e simulare un maggior dettaglio geome-trico, sono state utilizzate normal map e procedure di edge smoothing.

Per ciascun modello sopra elencato sono state realizzate 3 tipologie di modelli destinati alla navigazione di applicazioni 3D real time: Modello attuale; Modello interpretativo; Modello ri-costruttivo.

Modello attuale: riproduce la situazione odierna (2011) delle evidenze archeologiche e serve 1 – a mostrare comparativamente i corpi di fabbrica sopravvissuti ed il loro stato di conserva-zione. I modelli sono stati ottenuti partendo dalla mesh realizzata a seguito delle operazioni di post processing delle nuvole di punti acquisite con laserscanning e fotogrammetria. An-che in questo caso i modelli, originariamente costituiti da un elevatissimo numero di poligo-ni (oltre il milione per modello) sono stati sintetizzati, senza intaccarne la topologia e carat-teristiche morfologiche, mediante filtri di decimazione per renderli fruibili in contesti RT.Modello interpretativo: riproduce l’architettura dei singoli corpi di fabbrica completa delle 2 – parti lacunose. Graficamente si presenta “evanescente” con struttura wire o a “fil di ferro” del-le cornici e con superfici murarie semi trasparenti. Questo espediente grafico è stato pensato per permettere, all’interno dell’applicazione interattiva, di poter visualizzare questa tipologia di modello contemporaneamente alla precedente, consentendo all’utente di confrontare i due layers informativi, verificare il corretto posizionamento delle volumetrie e distinguere il dato reale (l’evidenza archeologica) da quello interpretato (l’anastilosi virtuale delle lacune).Modello ricostruttivo: riproduce correttamente l’architettura completa degli edifici, rico-3 – struendone l’aspetto ipotizzato, al I sec. d.C. (fig. 2) Al modello solido sono state applicate, come textures, immagini che opportunamente processate con software di fotoritocco, si-mulano i materiali di cui erano costituiti gli edifici (color map) e la rugosità delle superfici (bump map). Poichè le informazioni archeologiche riguardanti le decorazioni parietali e pa-vimentali sono poche e lacunose, nella rappresentazione realistica dei materiali si è preferito mantenere un profilo rappresentativo “basso”, riproducendo con certezza solo quelli su cui si può avere un buon grado di affidabilità come le coperture in cotto dei tetti, l’intonacatura delle pareti, il lastricato del fondo delle vasche. Tuttavia, per evidenti esigenze di contestua-lizzazione e completamento dei modelli, alcune superfici come i pavimenti o le volte, sui quali non si aveva alcun tipo di informazioni sui rivestimenti, così come per la presenza,

Fig. 2. Ricostruzioni 3D: rendering del teatro e di una delle vasche di via Scavi



certa ma non testimoniata da evidenze, di elementi architettonici di arredo come porte, finestre, statue, fontane ecc, si è scelto di inserire, per rappresentazione evocativa, elementi standardizzati e molto diffusi nella romanità del I sec. d.C. Come è normale dunque, quan-do si ricostruisce un monumento di cui si hanno solo dati parziali, la ricostruzione presenta differenti livelli di affidabilità, valutati dagli specialisti.

daniele Ferdani

2.2 moDellazione proCeDurale

Nel tentativo di rappresentare la realtà urbana nella sua complessità e al tempo stesso di ot-tenere modelli fruibili attraverso la rete, si è deciso di realizzare anche una modellazione sche-matica di Montegrotto attuale. Lo scopo è quello di migliorare il realismo della scena virtuale e contestualizzare i siti nel paesaggio archeologico attuale.

Per ottenere una ricostruzione verosimile dell’articolazione urbana e, allo stesso tempo, limitare i tempi di modellazione delle migliaia di edifici (circa 7000), è stato scelto come ap-proccio quello della modellazione procedurale utilizzando il software Cityengine. Questo ap-proccio utilizza procedure di modellazione assistite dal software e basate su algoritmi per la ge-nerazione automatica di realtà complesse7.

Il software di modellazione procedurale ha permesso di mantenere un grande controllo su tut-te le istanze generate nella gerarchia della scena 3D e di raggiungere un grande numero di edifi-ci costituiti a basso numero di poligoni e differenziati per tipologia edilizia (fig. 3). Per ricreare un modello verosimile della città, caratterizzato da una vasta gamma tipologica di edifici, è stata creata una shape grammar rule; questa contiene una serie di regole che definiscono e controllano le gran-dezze geometriche, le relazioni gerarchiche tra i vari elementi architettonici e le variabili che gene-rano casualità donando realismo ai modelli. Su questo set di regole definite dal modellatore, la ge-ometria e l’aspetto degli edifici vengono “costruiti” e visualizzati nello spazio 3D dal software.

Per definire la planimetria di ogni singola struttura si è fatto riferimento ad una mappa cata-stale mentre per attribuire le altezze ed il disegno superficiale delle facciate, è stata inserita nel-la rule una matrice di correlazione che assegna agli edifici, in maniera casuale, una texture scelta da un set di foto, acquisite direttamente sul sito e processate con appositi programmi di foto-

7 parish, muller 2001, pp. 301-308.

Fig. 3. Il panorama urbano di Montegrotto ricostruito digitalmente all’interno del software di modellazione proce-durale e struttura dello shape grammar visualizzata per nodi. Sono visibili le grandezze geometriche, le relazioni e la struttura gerarchica che determina l’aspetto degli edifici

file danneggiato: verificare accura-tezza



raddrizzamento. Questa matrice fa in modo che a ogni texture siano associate informazioni ge-ometriche proprie dell’edificio fotografato, cosicché quando il software la assegna, attribuisce contemporaneamente al modello anche le corrette proporzioni ed altezza.

Per ovvie ragioni è stato impossibile oltre che inutile attribuire a ciascuno dei 7000 edifici le fattezze originali. I modelli servono infatti a dare una rappresentazione schematica d’insieme dell’abitato urbano destinato ad un basso livello di dettaglio formale. All’interno del plug-in di navigazione interattiva del paesaggio di Montegrotto infatti, i modelli sono visibili solamente quando l’utente navigherà e visualizzerà il territorio utilizzando prospettiva area e dunque tro-vandosi ad un distanza tale da non permettere il riconoscimento del singolo edificio ma solo dell’articolazione del contesto. Solamente le zone poste in prossimità delle aree archeologiche, visibili anche quando l’utente si troverà ad esplorare i siti, sono state modellate con maggior dettaglio riproducendo con esattezza geometrica l’immediato contesto8.

daniele Ferdani

2.3 ottimizzazione Dei moDelli 3D per il real time

In questa fase del flusso di lavoro i dati 3D vengono preparati per poi attraversare alcuni processi di ottimizzazione prima della pubblicazione finale sul web. Scegliendo come piattafor-ma di visualizzazione e interazione con il mondo virtuale il framework opensource OpenSce-neGraph, i dati devono essere convertiti nei formati nativi sotto forma di nodi ed è necessario organizzare la scena in un grafo. I risultati migliori per la scena sono ottenuti utilizzando grafi bilanciati, organizzati quindi in strutture come quad-tree, che permettono solamente a porzio-ni della scena (chiamate “pagine” o “tiles”) di venire richieste e trasmesse dal server remoto ver-so il client, in base all’esplorazione e alla posizione spaziale dell’utente. I livelli di dettaglio per-mettono una rappresentazione multi-risoluzione della geometria del terreno e dei modelli 3D, permettendo la visualizzazione e la gestione di ambienti virtuali e paesaggi anche molto com-plessi e di grandi dimensioni. Poiché l’attenzione è rivolta alla ricostruzione di aree specifiche distribuite nel paesaggio virtuale, come ad esempio il teatro di via Scavi e la villa di via Neronia-na, è stato scelto un approccio modulare: alcuni modelli particolarmente complessi sono stati

8 Per esempi di modellazione procedurale applicati a contesti archeologici, cfr. maim et alii 2007.

Fig. 4. Ottimizzazione geometrica e separazione in componenti paginate del teatro romano ricostruito. a) visualiz-zazione wireframe b) visualizzazione real-time



suddivisi in diverse componenti, bilanciando in questo modo il carico web su più file (in gene-re 15-20), con un notevole incremento dell’organizzazione spaziale e della precisione riguardo agli algoritmi di illuminazione e ombre (fig. 4).

Per molti di questi parametri, esiste un ampio livello di personalizzazione, ad esempio ge-stire livelli di dettaglio e parametri di illuminazione durante fasi di walk-mode durante l’esplo-razione dei siti di Montegrotto, sgravando il carico di lavoro dal sistema e aumentando la preci-sione su oggetti molto vicini all’osservatore. Essendo questo scenario basato su web, una serie di strumenti semi-automatici sono stati sviluppati per produrre e gestire strutture molto com-plesse come la città attuale di Montegrotto: singoli edifici prodotti da Cityengine (circa 7.000 edifici in formato obj) sono stati importati e riorganizzati in sezioni per ottimizzare lo scarica-mento di porzioni spaziali. Lo stesso approccio è stato utilizzato per la generazione di foreste, per le quali è stato sviluppato uno strumento per il posizionamento della vegetazione in tempo reale (fruttato ad esempio per produrre la vegetazione all’interno dei giardini della villa di Via Neroniana). Lo strumento consente di ottimizzare la dimensione dei file in base alle tipologie di vegetazione tramite la creazione di istanze. Il grafo di scena riguardante il progetto di Monte-grotto è stato quindi ristrutturato rispettando percorsi bilanciati su grafi e minimizzando chia-mate a cambi di stato, incrementando sia le performance a livello di rendering real-time, sia ot-timizzando la dimensione dei file richiesti al server (fig. 5).

3. esplorazione interattiva Del paesaggio arCheologiCo on line

3.1 l’appliCazione osg4WeB

3.1.1 introduzione

OSG4WEB è un’applicazione che consente agli utenti di interagire con mondi tridimen-sionali in maniera interattiva all’interno di un browser web, come ad esempio Mozilla Firefox o Safari. Applicazioni 3D interattive e applicazioni basate su web sono sempre state collegate, fin dall’era del VRML e successivamente X3D: linguaggi di mark-up che tentavano di fornire uno standard per descrivere contenuti 3D. Attualmente nell’ambito della visualizzazione di conte-nuti tridimensionali sul web all’interno di un browser, non è presente una soluzione che sia sta-ta ampiamente adottata in modo da diventare uno standard “de facto” e fornire una contropar-te 3D ben definita all’HTML. Durante lo sviluppo di questo tipo di applicazioni quindi, diversi parametri sia qualitativi che quantitativi devono essere presi in considerazione, in particolare:

Fig. 5. Riorganizzazione spaziale e ottimizzazione della città attuale di Montegrotto in porzioni paginate e grafi quad-tree a) visualizzazione wireframe b) visualizzazione real-time

Daniele

Evidenziato



performance− di rendering: qua-lità visiva e framerate;performance− di rete: tempo di attesa per una visualizzazione ottimale dei dettagli e carico di lavoro sulla banda;distribuzione: quanto sempli-− ce sia distribuire la piattaforma sui browser web attuali e quale hardware sia necessario.

Per realizzare un’esplorazio-ne real-time completa dei model-li e dell’ambiente virtuale 3D, è sta-to quindi sviluppato e notevolmente esteso il pre cedente progetto “OSG4WeB”: un plug-in basato sull’efficiente framework OpenSce-neGraph, utilizzato in precedenza anche per il progetto “virtual rome” (www.virtualrome.it), che permetteva di inserire un componente di visualizzazione 3D all’interno di una pagina web. Il pro-getto di Aquae Patavinae ha richiesto un ulteriore sviluppo sia in termini di usabilità e di interfac-cia utente, che di qualità dell’immagine e di realismo. Per aumentare quest’ultimo conservando una fluidità accettabile, sono state implementate nuove funzionalità internamente al cuore del plug-in.

Comportamenti specifici come walk-mode e complesse funzionalità di navigazione, sono stati ampiamente rivisitati: l’esplorazione è stata arricchita con effetti di Fisica come attriti e adat-tamento a superfici, oltre a un nuovo sistema di collisioni. Alcune recenti novità nel framework di OpenSceneGraph hanno permesso inoltre l’implementazione di algoritmi efficienti per illumi-nazioni avanzate e ombre real-time (fig. 6), in particolare con supporto ad ambienti virtuali molto vasti utilizzando approcci multi-risoluzione e un buon livello di personalizzazione.

La sorgente di luce primaria (sole) può essere infatti impostata in maniera interattiva durante l’esplorazione del mondo virtuale, con la possibilità di simularne la posizione nelle diverse ore del giorno. Questo tipo di approccio, inoltre, supporta completamente l’utilizzo di oggetti dinamici o elementi animati nella scena virtuale, poiché non esiste alcun problema di pre-computazione sui modelli (fig. 7). L’interfaccia è stata completamente rivista: ogni elemento (icone, bussola, mini-mappa, area informativa, etc..) è trattato come un oggetto appartenente alla scena tridimensiona-le, che può essere caricato da locale o da remoto e personalizzato in base alle esigenze di proget-to. Per quanto riguarda le interazioni è stato implementato un ulteriore strato software in grado di gestire eventi complessi attivabili dall’utente. In questo modo, ogni oggetto in scena è in grado di contenere comandi da eseguire, per produrre comportamenti e azioni all’interno della realtà si-

Fig. 6. Ombre real-time multi-risoluzione (Light-Space Perspective Shadows) all’interno della villa di via Neroniana ricostruita

Fig. 7. Effetti particellari e illuminazione volumetrica real-time (vapore vasche termali)



mulata (ad esempio cambi di illuminazione, posizionamento camera, aggiunta/rimozione di mo-delli 3D), aumentando la qualità di interazione e quindi l’esperienza dell’utente finale.

3.1.2 Windows

Essendo questo tipo di applicazione Frontend fortemente basato sul modello open source, gli sforzi si sono concentrati maggiormente su:

integrazione del componente in un − browser;funzionalità specifiche nel − Frontend;strumenti di − Backend per conversione e ottimizzazione modelli.

Il primo prototipo del componente OSG4WeB è stato sviluppato per il sistema operativo Windows, applicato al progetto “virtual rome”: è stato incapsulato un viewer OpenSceneGra-ph (componente standard fornito per la visualizzazione base dei modelli) in un plug-in per il browser Firefox. Successivamente, il componente è stato fortemente rivisitato ed il processo de-dicato alla visualizzazione del virtual world gestito in modo separato: questa scelta ha compor-tato una maggiore stabilità grazie all’indipendenza del plug-in rispetto al processo del browser, favorendo quindi una composizione più modulare e solida anche con più istanze (fig. 8).

Bruno Fanini

3.1.3 Mac

Negli ultimi anni la diffusione delle piattaforme OSX e iOS, hanno visto un rapido incre-mento. L’impatto dell’hardware Apple sul mercato non può più essere ignorato da chi voglia sviluppare applicazioni informatiche in grado di raggiungere la più ampia platea di utenti; la na-tura stessa di questo progetto, che si basa sull’idea del web come mezzo universale per la diffu-sione di contenuti, ci ha portato a prendere in considerazione lo sviluppo di una soluzione an-che per questa fascia di utenza.

Purtroppo, nonostante i sistemi Windows e Max OSX stiano diventando esteriormente sempre più simili, permangono numerose e notevoli differenze al di sotto della superficie. Que-ste, insieme ai recenti sviluppi nel campo della tecnologia dei browser, ci hanno spinti a conside-rare alcune modifiche al progetto originario del plug-in, mantenendo nella nostra applicazione

le medesime funzionalità e gli stes-si comportamenti sia per gli utiliz-zatori, che per i produttori di con-tenuti, a prescindere dal sistema e dall’architettura sottostante, allo scopo di avere una maggiore coe-renza divulgativa.

Prima di tutto si è trattato di decidere quale dei framework si avvicinasse maggiormente alle no-stre esigenze. Agli sviluppatori, Apple offre un vasto set di librerie e alcune di queste sono quasi spe-culari tra loro, cioè offrono prati-camente le stesse funzionalità per chi sviluppa, ma in linguaggi dif-ferenti: la libreria (“umbrella fra-mewrok”) Carbon per chi usa il Fig. 8. OSG4WEB come processo separato rispetto al browser.



linguaggio C++, e la libreria Cocoa a chi scrive in Objective C e Objective C++. Quando ab-biamo iniziato il lavoro di estensione del progetto a Mac OSX, Apple aveva già annunciato che avrebbe dismesso il supporto della libreria Carbon per le architetture a 64 bit. In considerazio-ne di una maggiore longevità e portabilità del nostro lavoro, abbiamo deciso di utilizzare il fra-mework Cocoa. Un altro punto che abbiamo voluto prendere in considerazione all’inizio del nostro percorso di sviluppo, è stata l’evoluzione tecnologica che i maggiori software di naviga-zione del web avrebbero avuto nel tempo, in base agli annunci dei relativi team di sviluppo. Al giorno d’oggi ormai quasi ogni browser supporta nativamente, anche se in maniera non del tut-to stabile, il paradigma “out of process plugin”. All’inizio del lavoro di porting questa tecnologia era ancora ad uno stadio sperimentale, ma Cocoa ci ha offerto la possibilità di usufruire di que-sta nuova opportunità abbastanza facilmente.

Un altro aspetto che abbiamo preso in considerazione è stata la tecnologia da usarsi per in-terfacciare il browser con il plug-in. Il software di navigazione presente al momento dell’acqui-sto su qualsiasi Mac è Safari, che si basa sul motore di rendering WebKit, per cui è (era) dispo-nibile anche un framework di sviluppo. Probabilmente questa sarebbe stata la scelta più facile e performante per sviluppare un plug-in su architettura Machintosh, data anche l’esistenza di una documentazione decisamente migliore. Per contro questa decisione ci avrebbe limitati dal pun-to di vista della portabilità, dato che questo framework non veniva supportato in alcun modo da Mozilla Firefox. Abbiamo quindi scelto di usare nPAPi (netscape Plugin APi), anche per per questioni di compatibilità, perché supportata da un numero maggiore di browser, fra cui anche Firefox. Questa si è rivelata anche una scelta decisamente lungimirante, dato che Apple, con il lancio del nuovo sistema operativo 10.7 Lion, ha dismesso completamente la possibilità di uti-lizzare plug-in sviluppati usando la tecnologia WebKit, sul suo browser di ultima generazione.

Si è cercato di studiare quindi una soluzione che potesse soddisfare i nostri requisiti. Abbiamo usato la nuova tecnologia Core Animation, contenuta nella libreria Cocoa, in sinergia con la più te-stata e conosciuta libreria nextStep (di cui in particolare abbiamo utilizzato la libreria per la visua-lizzazione dei contenuti OpenGL), per derivarne due nuove classi, ed abbiamo modificato il no-stro visualizzatore dinamico basato sulla libreria OpenSceneGraph, costruendo infine sulla base di questi tre componenti, una struttura di oggetti basati sul pattern model-viewer-controller.

La sottoclasse derivata da Core Animation è responsabile per il contesto grafico a partire dalla sua creazione; quella derivata da nSOpenGLview invece è incaricata della visualizzazio-ne e della gestione degli eventi, infine il nostro viewer ha il compito di costruire e controllare la scena. Tutte queste componenti sono controllate direttamente dal browser attraverso l’inter-faccia nPAPi, e l’architettura dell’intero sistema è progettata per offrire la possibilità di svilup-pare anche una interfaccia JavaScript.

Questa soluzione che abbiamo sviluppato offre: piena compatibilità con i contenuti svilup-pati per il plug-in Windows e stesse funzionalità; buone performance di visualizzazione; com-patibilità con sistemi a 64 bit; paradigma “out of process plug-in”; funzionamento su differenti applicativi per la navigazione del web; funzionalità JavaScript; possibilità di migrare in futuro alla piattaforma Firebreath.

Guido Lucci Baldassarri

3.2 interfaCCia

3.2.1 interazioni

L’interazione con il mondo virtuale da parte dell’utente avviene tramite nodi speciali pre-senti nella scena chiamati “Action nodes” contenenti comandi da eseguire quando attivati. Lo sviluppo di questi nodi speciali e la possibilità di richiamarne altri in successione all’interno del mondo virtuale, ha portato alla creazione di un grafo di interazione, incrementando notevol-mente la scalabilità e la portabilità del progetto corrente. Ogni nodo è in grado di incapsula-

Daniele

Nota

Sostituzione: inserire "ci ha permesso di sfruttare" al posto di "ci ha offerto la possibilità di usufruire di"

Daniele

Evidenziato



re uno o più comandi che vengono eseguiti tramite interazione dell’utente: un model-lo, un’icona o un “pin” possono contenere azioni come cambi di illuminazione, cari-camento modelli e attivazione di compor-tamenti specifici per un’area o un sito in particolare. Nel progetto di Montegrotto, ad esempio, un Action node comune a tut-ti i siti archeologici viene eseguito quando l’utente interagisce con una delle icone o uno degli hotspot relativi all’area, attivando ad esempio walk-mode, impostando vinco-li di navigazione ed altri parametri (fig. 9).

L’icona “home” richiede l’attivazio-ne del fly mode e una posizione specifica di partenza, mentre altre configurazioni ri-guardanti ad esempio illuminazione e fo-schia, sono state raggruppate in altri Ac-tion nodes richiamati solo durante l’avvio dell’applicazione. Questo approccio ha di-mostrato diversi vantaggi, in particolare la flessibilità e l’adattamento rapido in occa-sione di cambiamenti nei requisiti attuali o futuri del progetto.

3.2.2 Frontend e Backend

OSG4WEB prevede due componenti: un Frontend e un Backend. Il Frontend è il compo-nente web pubblico, in grado di inserire un “canvas” 3D all’interno della pagina web, cioè di apri-re la “finestra” sul mondo virtuale. Questo componente PHP gestisce l’inizializzazione del “can-vas” e un grande numero di parametri che vengono invitati al motore di rendering, ad esempio impostare il nodo principale della scena (radice) e abilitare effetti di gravità, collisioni, illumina-zione, ecc. Il Frontend supporta un ulteriore strato software per l’ascolto e la gestione delle inte-razioni ed eventi interni al mondo virtuale tramite Actionnodes e un altro strato completamente adattabile in base alle esigenze dell’utente in grado di gestire icone, bussola, mini-mappa del terri-torio e oggetti 3D completa-mente personalizzabili (over-lay, loghi, pulsanti, etc...) con la possibilità di associa-re azioni di ogni tipo (fly-to, cambi di illuminazione, abili-tazione walk/fly mode, mes-saggi a schermo, caricamento modelli, etc..) interpretabili dal plug-in (fig. 10)

Il componente Backend, anch’esso basato su web, è uno strumento riservato a un team con opportuni privilegi

Fig. 9. Grafo di interazione utilizzato nel progetto di Monte-grotto. 1) Sequenza di attivazione Action Nodes con ingresso dalla vista principale 2) Sequenza di attivazione Action No-des con ingresso dal sito A (area archeologica di via Scavi)

Fig. 10. Interfaccia web del BackEnd: libreria dei modelli 3D



(username e password), offrendo un insieme di servizi web in grado di gestire uno o più data-base di terreni, modelli 3D e il grafo di scena completo. In base ai dati e modelli inseriti nel da-tabase, tramite l’interfaccia web, e la definizione del mondo virtuale, il server genera il grafo di scena, pronto per essere caricato da un componente Frontend. La portabilità dei servizi del Ba-ckend nel caso del progetto di Montegrotto è stata inoltre garantita dalla virtualizzazione della macchina server, producendo buoni risultati in termini di efficienza e carico di lavoro durante lo streaming dei dati e dei contenuti 3D.

Bruno Fanini

4. ConClusioni e sviluppi futuri

4.1 prospettive Di progetto

Come si è detto, il progetto fin qui descritto è arrivato ad un primo risultato sia dal punto di vista dello sviluppo dei contenuti (ricostruzione paesaggio archeologico), che dal punto di vista dello sviluppo degli strumenti software. Come parte integrante di un progetto nazionale PRIN, finanziato dal MIUR, esso prevede un ulteriore sviluppo, integrando nel futuro anche il lavoro di simulazione e ricostruzione del paesaggio potenziale antico, che avrà un suo accesso on line sia lato front-end che back-end. Il progetto di archeologia virtuale di Aquae Patavinae è inoltre stato recentemente selezionato come uno dei migliori progetti di Archeovirtual, mostra che si svolge ogni anno a Paestum, nell’ambito della BMTA (Borsa Mediterranea del Turismo Arche-ologico). In occasione di tale evento sono in corso alcune sperimentazioni di seguito descritte, rivolte a rendere sempre più immersiva e coinvolgente l’esperienza di visita.

Sofia Pescarin

4.2 stereosCopia e interfaCCe touCh

Il plug-in ha dimostrato una grande espandibilità sia come componente all’interno del browser, sia come componente stand-alone. Le possibilità stereo fornite dalla libreria Open-SceneGraph hanno permesso la visualizzazione anaglifa e, dove l’hardware grafico lo permette, l’abilitazione di stereo passivo o attivo. Le modalità stereo permettono all’utente una maggiore immersività nella realtà simulata, in particolare per quanto riguarda installazioni. L’interfaccia 3D e il sistema di navigazione sono stati recentemente rimodellati per supportare interazioni di tipo touch e multi-touch, aggiungendo elementi di feedback visivo e nuove modalità di esplora-zione del territorio e dei siti archeologici ricostruiti. La strada delle interfacce naturali avanza-te è una strada interessante con un gran numero di potenzialità per fornire nuovi approcci alla fruizione dei contenuti 3D, oltre ad essere un obiettivo futuro del plug-in (fig. 11)

Fig. 11. a) Stereo anaglifo; b) Interfaccia di navigazione/interazione touch; c) Navigazione tramite iPod touch con multi-touch gestures nella ricostruzione delle vasche termali.



4.3 vita artifiCiale

Nella ricostruzione di paesaggi nel campo del Virtual Heritage, spesso lo sforzo è concen-trato sulla visualizzazione e sulla rappresentazione 3D di siti e modelli, in generale fornendo un sistema di navigazione adatto al mondo virtuale. I recenti avanzamenti nel campo dell’hardwa-re grafico e delle tecnologie hanno reso la rappresentazione dei mondi virtuali sempre più reali-stica, ma con la crescente necessità di introdurre elementi dinamici, come ad esempio agenti vir-tuali. Alcuni progetti sviluppati in questo contesto9 rappresentano un altro degli obiettivi futuri che permetterebbero di introdurre vita artificiale in una realtà simulata su larga scala nel plug-in OSG4WeB. Questo tipo di modelli basati su agenti sono rappresentazioni di sistemi composti da diversi attori in grado di interagire tra loro e compiere azioni all’interno dell’ambiente. L’obietti-vo è quello di disporre entità indipendenti, la cui fondamentale abilità sia quella di prendere deci-sioni ed evolvere alcuni attributi interni. Il comportamento può variare da reazioni di base fino ad alcune più complesse, includendo attitudini relative a un raggio sociale, oppure reazioni provoca-te da stimoli esterni o l’intervento dell’utente stesso. Uno strato dinamico che si evolve in manie-ra autonoma e reagisce alle interazioni dell’utente in base a hotspot, mappe evolutive, tipologie di agenti, geo-morfologia e trasmissione delle informazioni, aumentando la conoscenza del territo-rio e dello strato informativo riguardanti progetti relativi a questo contesto.

Bruno Fanini

glossario

Edge smoothing: espediente utilizzato nella modellazione poligonale per simulare a livello vi-sivo e non poligonale la smussatura delle superfici in prossimita degli angoli.

Shape Grammar: set di regole che consente di generare, secondo processi additivi, forme 2d e 3DLow Poly, Modello: Modello 3D costituito da un basso numero di poligoniNormal map: immagine RGB che simula illuminazione e rilievo di un oggetto; impiegata in ge-

nere su modelli low poly per aggiungere dettaglioQuad-Tree: struttura in cui ogni nodo in un grafo possiede quattro figli, particolarmente ef-

ficiente per l’organizzazione dei dati in una scena. I nodi terminali (senza ulteriori figli) vengono chiamati “foglie”.

Rendering: processo di generazione di un immagine a partire da una descrizione matematica di una scena tridimensionale

Texture: o tessitura, immagine che simula il materiale che costituisce la superficie del model-lo. Esistono varie sottocategorie di texture. tra quelle citate: Color Map, simula il colore RGB del materiale; Bump Map, simula la rugosita del materiale

Walk-mode: Letteralmente “Modalità di Camminata”. Termine utilizzato nelle applicazione interattive di navigazione in prima o terza persona per indicare il punto di vista e veloci-tà di spostamento dell’utente, all’interno del mondo virtuale, simile a quello di un uomo. Si differenzia da Fly-mode che indica invece un punto di vista aereo e velocità di sposta-mento maggiori.

Wire: “filo di ferro”, parola comunemente usata nella Computer Grafica per indicare il tipo di visualizzazione a griglia del modello 3D

9 fanini 2009.



riassunto

aBstraCt

The paper deals with a new approach for the reconstruction of archaeological urban contexts and its implementation on web. Starting from archaeological information, geospatial and topographic data, we adopted a successful work-flow from data generation to online real-time visualization and in-teractive content exploration. The pipeline involves semi-automatic steps to provide a multidisci-plinary team with a set of tools aiming at the final publication of massive landscape reconstructions and simulated environments: the optimized resulting and well-structured 3D world has in fact the primary goal of web accessibility and a fulfilling user experience within exploration of such large datasets, especially in a virtual archaeology context. Our main aim is to recreate entire ancient ur-ban contexts and landscape and making them accessible via web. To achieve this goal, we are going to use, with success, a procedural approach, with the software CityEngine, for low poly modeling of a huge number of buildings. Within real-time applications, dealing with large reconstructed cities and virtual landscapes is always a challenge. The rendering of large amount of buildings, architec-tural elements and objects can be addressed with level-of-detail techniques, scene-graphs algorithms and spatial partitioning of the virtual world, allowing scalable approach in different scenarios with paging support for huge databases, locally or remotely located. The solid hierarchical structure gen-erated from modules developed on top of opensource OpenSceneGraph framework, allows in fact a clean and efficient load balance among the virtual world data, with the purpose of maintaining a light footprint on client system resources and 3D rendering application, especially dealing with the goal of web transfer minimization through a 3D-enabled browser. We adopted this pipeline in the project of reconstruction and enhancement of archaelogical sites of Montegrotto City Aquae Patavinae and in the project PRIN “Il termalismo in età romana tra conoscenza e valorizzazione” coordinated by University of Padova. Initial data, method and software used, will be shown in the paper.

MANCARIASSUNTO

Daniele

Nota

Vedi foglio word allegato alla e-mail



BiBliografia

BaCelo J.A., forte M., sanDers D. 2000, virtual reality in Archaeology, BAR International Series 843, Oxford.

Borra D. 2000, La modellazione virtuale per l’architettura antica. un metodo verso l’isomorfi-smo percettivo, in ACalc, 11, pp. 259-272.

Calori l., Camporesi C., pesCarin s., 2009. virtual rome: A FOSS approach to WeB3d. in 3d technologies for the World Wide Web, in Proceedings of the 14th International Con-ference on 3D Web Technology, Darmstadt, pp. 177-180.

fanini B. 2009, An Agent-based Architecture for large virtual Landscapes, in CiPA Symposium Proceedings, Kyoto.

green D., Cosmass J., itagaki T. 2001, A real time 3d Stratigraphic visual Simulation Sys-tem for Archaeological Analysis and Hypothesis testing (VAST 2001), in Proceedings of International Symposium on Virtual Reality, Archaeology and Cultural Heritage (Atene, Glyfada, 28-30 Novembre 2001), a cura di D. Arnold, A. Chalmers, D. Fellner, New York, pp. 289-294.

hynst et alii 2001 = hynst S., gervautz M., graBner M., shinDler K. 2001 A work-flow and data model for reconstruction, management, and data visualization of archaeologi-cal sites, VAST 2001, in Proceedings of International Symposium on Virtual Reality, Ar-chaeology and Cultural Heritage (Atene, Glyfada, 28-30 Novembre 2001), a cura di D. Arnold, A. Chalmers, D. Fellner, New York, pp. 45-54.

maim et alii 2007 = maim J., haegler S., yersin B., muller P., thalmann D., van gool L. 2007, Populating Ancient Pompeii with Crowds of virtual romans, VAST 2007, in Pro-ceedings of International Symposium on Virtual Reality, Archaeology and Cultural Her-itage, a cura di D. Arnold, F. Nicolucci, A. Chalmers, New York, pp.109-116

miChael D., Chen S. 2006, Serious games: Games that educate, train, and inform, Boston.pesCarin S. 2009, reconstructing Ancient Landscapes, Budapest.parish Y., muller P. 2001, Procedural Modeling of the Cities, in Association for Computing

Machinery (ACM) Siggraph, New York, pp. 301-308.renfreW C., Bahn P. 1995, Archeologia. teorie. Metodi. Pratica, Bologna.sCagliarini Corlaita D., guiDazzoli A., salmon Cinotti T. 2003, Archeologia virtuale e

supporti informatici nella ricostruzione di Pompei, in ACalc, 14, pp. 237-274.

pagine internet

London Charter. Disponibile on line all’indirizzo: http://www.londoncharter.org/fileadmin/templates/main/docs/london_charter_2_1_en.pdf

V-must-Del. 2.1- V-MUST.NET project deliverables. Disponibile on line all’indirizzo: http://www.v-must.net/download

non citato

non citato

Daniele

Nota

vedere nel testo sopra le note con la posizione delle citazioni (pp 308 e 310)

Documents

Sofia Pescarin, Bruno Fanini, daniele Ferdani, Guido Lucci ... · Aquae Patavinae. Montegrotto terme e il termalismo in italia ar C h e o l o g i a v i r t u a l e a mo n t e g r