Tecnologie real time per la realtà virtuale -...

POLITECNICO DI TORINO Facoltà di Ingegneria

Corso di laurea in Ingegneria Elettronica

TESI DI LAUREA Tecnologie real time per la realtà virtuale

Applicazioni al turismo

Relatore Ing. Fulvio Corno

Candidato Dario Bonino

Aprile 2002

1

1 Introduzione

Il computer è attualmente uno strumento di lavoro irrinunciabile. È entrato

prepotentemente a far parte di quella cerchia di dispositivi utili a velocizzare e rendere “più

facili” certe operazioni, dalla scrittura di relazioni all’elaborazione di riprese

cinematografiche. Contemporaneamente lo stesso apparato si propone come oggetto di

svago, sono sempre più numerosi gli itinerari turistici, le enciclopedie, i corsi di lingue e i

giochi per computer.

Questi ultimi, in particolare, hanno raggiunto e stanno raggiungendo livelli qualitativi

sempre più elevati. A prescindere dalla tipologia dell’applicazione ludica, è indubbio che la

capacità di riprodurre alcuni aspetti della vita reale in un gioco per computer è

notevolmente migliorata. In numerosi videogiochi il realismo delle ambientazioni è

elevatissimo, in alcuni casi è veramente difficile stabilire una netta distinzione tra la scena

riprodotta nel videogioco e un’ipotetica scena reale ripresa con una telecamera.

2 1- Introduzione

Le caratteristiche tipiche di sistemi basati su elaboratori elettronici, in particolare la

versatilità e l’interattività, hanno offerto una buona spinta alla ricerca nel campo della

ricostruzione di situazioni reali.

A partire dai simulatori di volo per finire alle applicazioni più fantascientifiche di

tecnologie per la “realtà virtuale” si cerca sempre più di riprodurre sensazioni fisiche

“reali” in ambienti protetti, svincolati dalle sensazioni che si vogliono riprodurre. In un

simulatore di volo, ad esempio, si pilota un aereo virtuale con le stesse caratteristiche e le

stesse reazioni di un aereo reale, senza correre il rischio di precipitare a causa di manovre

errate. Anzi, si precipita e ci si schianta al suolo, ma successivamente si è in grado di

analizzare i motivi della caduta e di porre rimedio ai propri errori.

A partire da esigenze diverse, il divertimento da una parte e la riproduzione di situazioni

potenzialmente pericolose al fine di addestrare personale specializzato dall’altra, si sta

giungendo ad un risultato comune: la riproduzione fedele di diversi aspetti della vita e del

mondo reale.

La conseguenza più naturale è immaginare di sfruttare i risultati ottenuti in questi campi

per rivolgersi ad applicazioni ancora poco diffuse. In particolare, perché non sfruttare a fini

turistici le capacità sinora acquisite?

Poiché la tecnologia attuale permette la ricostruzione fedele di ambienti reali, è possibile

pensare di sfruttarla per offrire la visita di siti turistici particolari. Indipendentemente dalla

ragione per cui si può decidere di avvalersi di questo mezzo di presentazione (perché il

luogo turistico non è accessibile o perché si vuole offrire la possibilità di visita a casa)

sicuramente le possibilità offerte da una visita “virtuale” sono numerose, interessanti e

meritano un approfondimento.

In questa tesi di laurea si vogliono analizzare le tecnologie “real time” per la realtà virtuale

utilizzabili a fini turistici e si vuole studiare l’organizzazione di un sistema di visita

virtuale. Verranno analizzate le esigenze che un tale sistema deve soddisfare e le

funzionalità che possono essere offerte in questo campo di applicazione. Una volta chiariti

gli obiettivi a cui tendere verranno prese in considerazione le tecnologie attualmente

disponibili e si definirà un sistema di visita virtuale basato su di esse. Infine i risultati

saranno applicati ad un caso reale, la visita delle miniere di Traversella (TO), ottenendo un

software dimostrativo in cui saranno sintetizzati i vari aspetti trattati.

Il capitolo 2 della tesi si occupa dell’applicazione della realtà virtuale al turismo

individuando gli obiettivi da raggiungere, tracciando i possibili sviluppi futuri e

analizzando le soluzioni attualmente disponibili.

1- Introduzione 3

Nel terzo capitolo vengono analizzati in modo più approfondito i vari motori di rendering

disponibili, studiandone le caratteristiche in funzione di una applicazione turistica. Tra

questi, verrà scelto il più adatto ad una applicazione dimostrativa e verrà descritto

dettagliatamente.

Il quarto capitolo affronta la definizione dell’architettura software di un sistema di visita

virtuale basato sull’utilizzo del motore 3D selezionato nel capitolo 3. In ogni caso le

considerazioni effettuate saranno valide, almeno in parte, per qualunque motore di

rendering.

Nel capitolo 5 si illustrano alcune soluzioni tecniche da adottare per la costruzione di un

software di visita virtuale con Morfit 3D Engine, indipendentemente dal sito turistico che

si vuole ricostruire.

Nel capitolo 6 si studia un caso di applicazione reale: la visita virtuale alle miniere di

Traversella.

Il capitolo settimo illustra in modo più approfondito le tecniche utilizzate per la

realizzazione del software di visita alle miniere e il capitolo ottavo conclude la trattazione.

4 1- Introduzione

5

2 Applicazioni al turismo

Il termine realtà virtuale compare ormai in qualunque àmbito culturale e spesso si è

abusato dello stesso perdendo di vista il suo significato. Si utilizza tale termine per riferirsi

ad una simulazione di alcuni aspetti della realtà materiale, quella che possiamo percepire

con i nostri sensi, e quindi per riferirsi a un qualcosa “virtuale”, non vero.

Normalmente si parla di realtà virtuale riferendosi ad una ricostruzione al computer di

ambienti e/o comportamenti reali. Si utilizza questa accezione invece del termine

simulazione perché lo scopo tipico è ricreare un’ambientazione pseudorealistica con

caratteristiche percettibili simili alla realtà. L’offerta di contenuti e svaghi risulta infatti di

maggior effetto se si sfruttano alcune capacità innate di chi è destinato ad utilizzare il

servizio offerto, ad esempio l’orientamento, la capacità di percepire il senso di provenienza

dei suoni e la capacità di stimare le distanze in base alla “profondità” di un immagine.

Anche per applicazioni di visita virtuale l’oggetto di riferimento è un elaboratore

6 2-Realtà virtuale applicata al turismo

elettronico, eventualmente dotato di accessori adatti a garantire un certo comfort di

utilizzo. La tecnica di definizione della visita è sempre basata su una riproduzione della

realtà che sfrutta le caratteristiche percettive dell’essere umano, al fine di ricostruire un

ambiente reale di interesse turistico. Si vuole cioè rappresentare su computer, nel modo più

corretto possibile, un luogo reale con caratteristiche interessanti dal punto di vista

culturale, paesaggistico, umanistico, sociale, ecc.

Quando si vuole offrire un servizio di tipo turistico è utile, se non fondamentale, capire le

esigenze del destinatario, in modo da calibrare su di esse il servizio stesso. Nel caso della

visita turistica è probabile che si possano distinguere alcune esigenze primarie, che

dovranno essere giocoforza soddisfatte, da altre di importanza secondaria che

contribuiranno a rendere la visita interessante, divertente e che invoglieranno i visitatori a

ritornare e a visitare il luogo reale.

La prima fase del lavoro di ricostruzione di un ambiente reale a fini turistici è quindi

individuare queste esigenze e soddisfarle. Intanto, perché è necessario ricostruire un

ambiente reale? Sarebbe tutto più semplice, o perlomeno più soddisfacente se si visitasse

l’ambiente reale, è molto più bello, toccante vedere un paesaggio dal vero che non in foto,

è più interessante poter vedere un quadro, esaminarne le pennellate che non vedere una

riproduzione in una bacheca o su uno schermo televisivo. É utile rappresentare fedelmente

la realtà se la stessa non è disponibile, infatti certi luoghi non sono accessibili al grande

pubblico per svariati motivi, ad esempio una sala di un castello perché in fase di restauro,

un quadro perché l’atmosfera normale ne provocherebbe il deterioramento e ciò ne

impedisce la visita in prima persona. In questi casi è interessante essere in grado di fornire

una esperienza “quasi” reale, consentendo al turista la visita dei luoghi non accessibili

mediante ricostruzioni verosimili. Esiste poi un lato positivo nella visita “virtuale” di certi

luoghi, cioè la capacità di offrire alcune possibilità non concesse in una visita reale, ad

esempio: quante volte osservando un soffitto affrescato vorremmo aver la possibilità di

ammirarlo da vicino, quante volte vorremmo scegliere il percorso della nostra visita e

siamo invece costretti a seguire la guida turistica, quante volte osserviamo un manufatto,

un oggetto esposto, ci chiediamo come è stato costruito, a cosa serviva e non abbiamo a

disposizione chi risponda alle nostre domande. La ricostruzione degli ambienti reali

permette di soddisfare tutte queste esigenze garantendo un offerta turistica di elevata

qualità.

L’obiettivo non è sostituire l’esperienza reale, ma integrare la stessa con altre informazioni

non reperibili fisicamente al momento della visita.

2-Realtà virtuale applicata al turismo 7

2.1 Obiettivi primari La prima esigenza da soddisfare è la verosimiglianza dell’ambiente ricostruito, per avere

interesse turistico la qualità di riproduzione delle immagini dovrà essere fotografica, quindi

sarà necessario che quanto rappresentato sullo schermo non sia distinguibile da quanto può

essere ottenuto con tecniche fotografiche. Questo vale sia per eventuali zone di particolare

interesse che per quelle zone che si possono definire di transizione, passaggio da un

elemento centrale dell’offerta turistica a un altro. La riproduzione dell’ambiente reale

dovrà avere caratteristiche di tridimensionalità e non ridursi alla semplice presentazione di

sequenze di immagini. L’informazione fornita dovrà cioè avere la caratteristica di

rispecchiare la reale disposizione degli elementi e la percezione che abbiamo della stessa.

Una volta definita la qualità di riproduzione degli ambienti reali occorre stabilire le azioni

che il visitatore può compiere per usufruire del servizio, occorre cioè determinare cosa si

può e cosa si deve offrire a chi utilizzerà questa nuova possibilità di visita. Sicuramente si

vorrà avere la capacità di muoversi nella zona da visitare, come si farebbe realmente. In

questo caso esistono varie modalità possibili di visita che rispecchiano in un certo qual

modo l’offerta tradizionale, cioè la visita guidata, la visita autonoma, la visita per itinerari

predefiniti.

Spendiamo un attimo di tempo per descrivere più attentamente queste tre possibilità.

Nella visita guidata il turista si aspetta di avere una figura umana, una persona, che illustri

le caratteristiche del luogo visitato, risponda a qualunque domanda possa sorgere e che sia

in grado di dissipare qualunque dubbio assilli il visitatore stesso. La guida ideale dovrebbe

essere sempre disponibile, competente e avere una pazienza infinita. Naturalmente non è

possibile pretendere che un uomo abbia tutte queste qualità ma è sicuramente possibile che

le abbia una macchina programmata dall’uomo per soddisfare queste esigenze. In più la

guida deve conoscere alla perfezione il sito turistico per poter indicare il percorso ai

visitatori, senza mai perdere l’orientamento e lo stesso dovrà essere fatto dal suo alter ego

virtuale. Soffermandosi un attimo a pensare è facile accorgersi che molti luoghi turistici

hanno caratteristiche peculiari e interessanti sotto diversi aspetti e punti di vista, la guida

illustrerà tendenzialmente solo gli argomenti che la interessano personalmente mentre

sorvolerà quegli aspetti che le paiono di minor interesse. D’altra parte il turista interessato

a questi aspetti si accontenterà di una presentazione incompleta, comprendendo la

difficoltà di abbracciare in poco tempo un campo così vasto di argomenti. In una visita

virtuale questo non è accettabile, dato che per un motivo o per un altro non si può offrire la

realtà è quantomeno doveroso coprire le lacune evidenziate. Infatti, non esistono problemi


sulla quantità di informazioni da memorizzare, stiamo lavorando con una macchina che è

stata attrezzata allo scopo di eliminare questi problemi e per essere in grado di fornire

spiegazioni adeguate, chiarimenti, indicazioni, in modo corretto e completo, a prescindere

dall’aspetto cui è interessato il turista. In parole povere, lo strumento per la visita virtuale è

e deve essere in grado di conoscere e trattare tutti i possibili approcci alla visita stessa.

Passando al caso della visita autonoma, se già nel caso della visita guidata si sono

intraviste le grandi potenzialità di una visita virtuale, tali possibilità verranno qui estese e

raggiungeranno la capacità di rendere notevolmente più interessante la visita stessa.

Tutti sanno, dalla propria esperienza personale, quanto sia più istruttivo muoversi da soli

nell’ambiente da visitare, insieme alla potenza della scoperta come mezzo di

apprendimento, la possibilità di stabilire personalmente il proprio percorso rende la visita

più divertente, interessante e questo fa sì che la si ricordi con piacere. Dato che prima

ancora di essere un occasione di apprendimento, il turismo è un occasione di svago, è

necessario essere capaci di rendere attraente la visita dei siti turistici. In particolare, nel

caso di una ricostruzione della realtà è fondamentale liberare il turista dai legami, dai

vincoli della visita. Il visitatore deve potersi muovere liberamente in ogni posizione del

sito, senza limiti, nemmeno quelli che sono presenti nella realtà. In una ricostruzione non è

possibile pensare a zone ad accesso limitato, non esiste infatti alcuna possibilità che il

turista rovini i monumenti e che questi siano pericolosi per lo stesso. La visita virtuale

permette quindi la mobilità assoluta ai visitatori e deve essere organizzata in modo da

evitare che questa libertà diventi opprimente. Il visitatore potrebbe infatti perdersi, passare

troppo tempo alla ricerca di zone particolari da visitare, per assurdo annoiarsi. Pertanto è

utile prevedere un aiuto alla visita che il turista può richiedere in qualunque momento, una

sorta di genietto camaleontico in grado di fornire, a richiesta, qualunque informazione sia

culturale sia geografica, capace di portare il visitatore direttamente ove desidera, capace di

far vedere allo stesso la propria posizione nell’ambiente visitabile.

La visita in prima persona diventa allora molto più flessibile di quanto avvenga in realtà, in

ogni momento il visitatore sarà grado di richiedere informazioni come se avesse a

disposizione una guida e nello stesso tempo potrà muoversi a piacere senza paura di fare

danni o farsi male. Sarà come avere a disposizione una persona che soddisfa ogni curiosità

senza fare obiezioni, come essere eterei, capaci di fare per una volta ciò che veramente si

vuole. E questo, se correttamente sfruttato, può essere il vero vantaggio di una visita

virtuale.


Rimane da trattare la visita per itinerari predefiniti in cui il visitatore è vincolato a

muoversi entro zone ben definite del sito turistico che presentano caratteristiche comuni.

La visita potrà essere autonoma o “guidata” ma in ogni caso sarà limitata all’analisi del

luogo turistico sotto un particolare punto di vista. In realtà questa visita non offre

particolari spunti rispetto al caso reale essendo comunque un tipo di visita molto specifico,

organizzato che tende a limitare il visitatore all’analisi di particolari aspetti e che quindi ne

tralascia altri. L’unico vantaggio di cui si gode nella visita virtuale è la possibilità di

organizzare un numero teoricamente illimitato di percorsi tematici, ognuno corredato da

informazioni adeguate, complete per quanto possibile e la possibilità di stabilire

collegamenti tra gli stessi permettendo il passaggio da un percorso a un altro in qualunque

momento, senza restrizioni.

Gli obiettivi primari della visita virtuale che abbiamo illustrato possono essere riassunti

esaurientemente dicendo che il servizio di visita deve offrire, come requisito minimo, le

stesse possibilità che offre una visita reale (esclusa più o meno ovviamente la percezione

fisica dell’ambiente). Naturalmente si può immaginare di fare molto di più.

2.2 Obiettivi secondari Qui si vuole cercare di capire quali siano le offerte sussidiarie in grado di fare la differenza

tra una visita ordinaria e una visita “speciale”.

Pensiamo subito alla visita in prima persona, stiamo percorrendo le stanze di un castello ed

ecco che appare uno dei suoi antichi abitanti che, vestito di tutto punto, ci invita a

partecipare a un ballo nel salone delle feste. Impensabile, fantastico, potremmo chiedere ai

veri abitanti come era la vita di un castello o di qualunque altro luogo, potremmo sentire

raccontare da un giullare aneddoti sulla vita di corte, potremmo scoprire usanze e abitudini

che ignoravamo. Non solo, la possibilità di avere un’esperienza diretta delle stesse

contribuirà sicuramente a una loro memorizzazione. Anche se il discorso sembra un po’

irreale, con una visita virtuale è sicuramente possibile offrire questo tipo di esperienza, è

possibile cioè ricostruire la vita passata basandosi su quanto riportato dalla storia fino a

noi.

Immaginiamo adesso di visitare una miniera e di vedere i minatori al lavoro, di sentire i

loro racconti di come quella volta sono sfuggiti a un crollo. Tutto ciò rende l’esperienza di

visita diversa, migliore. Se poi pensiamo per un attimo di visitare un museo con manufatti

artigianali di una certa epoca avremo la possibilità di osservare l’utilizzo degli stessi,

infatti, in una visita virtuale, è relativamente facile associare a certi oggetti dei filmati che


ne illustrano l’utilizzo. E’ possibile con la stessa complessità concettuale fornire

indicazioni sul funzionamento di un mulino a vento e sui mezzi di trasporto del primo

novecento. Non solo, è vero che l’occhio vuole la sua parte, ma anche l’orecchio! Ecco che

allora si può pensare di associare suoni alla visita virtuale: il suono dell’acqua che gocciola

lungo le rocce di una miniera, il suono delle campane e dell’organo in una chiesa, il suono

del fuoco in un caminetto e quant’altro possa venire in mente per rendere la visita quasi

reale.

Un’altra possibilità di rendere la visita diversa è la capacità di offrire lo stesso trattamento

alle persone disabili o con problemi fisici. Se il problema è “solo” la mobilità esso viene

risolto automaticamente dato che per la visita virtuale non è richiesto alcun movimento se

non quello delle dita o della testa. Se il problema è uditivo verrà privilegiata

l’informazione visiva tralasciando quella sonora e viceversa nel caso di utenti non vedenti.

Sarà possibile integrare il sistema per la visita virtuale con i sistemi per il superamento

degli handicap fisici e in linea di principio in un futuro prossimo o remoto sarà possibile

muoversi nell’ambiente ricostruito con il solo pensiero.

Sarà possibile offrire la visita a distanza delle varie località turistiche utilizzando un

collegamento remoto (Internet in un futuro più o meno prossimo). Sarà anche possibile

offrire la visita dei luoghi turistici a casa distribuendo compact disc che contengono il

software di visita.

Infine sarà possibile offrire una visita differenziata per età in modo da garantire il

divertimento non solo dei grandi ma anche dei più piccini. Per questi ultimi si potranno

prevedere presentazioni con lo stile di un cartone animato (per fare un esempio, sulla falsa

riga del famoso cartone animato “Alla scoperta del corpo umano” ) e visite particolari, con

giochi educativi e tendenti ad attirare l’attenzione dei bimbi. Per i più grandicelli si potrà

invece offrire la visita sotto forma di vero e proprio videogioco organizzato in modo da

favorire l’apprendimento di notizie utili sui luoghi in cui è ambientato e avente come

premio finale non la semplice vittoria ma l’aver capito che si può imparare divertendosi e

che la cosa più importante alla fine non è l’aver vinto ma l’aver apprezzato la visita al

luogo turistico.

2.3 Sviluppi futuri Qui si apre una parte davvero interessante e dagli sviluppi quantomeno incerti. Per il futuro

non è infatti difficile immaginare scenari di piena integrazione tra visitatore e apparato di

visita in grado di fornire un realismo finora impensato. Probabilmente non sarà difficile


integrare il sistema di visita con sistemi sensoriali in grado di riprodurre le sensazioni che

si provano visitando un qualunque luogo. Si può tranquillamente pensare di integrare il

sistema di visita con occhiali per la vista tridimensionale che siano in grado di fornire una

sensazione di tridimensionalità come quella del cinema 3D. A questi si potrà poi abbinare

un sistema di riproduzione sonora tale da ricreare la giusta provenienza dei suoni e dei

rumori fornendo un’ambientazione acustica molto simile alla realtà (ad esempio come

avviene per i film in formato dolby surround, o AC-3).

Se questi sono sviluppi realizzabili attualmente o in un futuro molto prossimo e con una

complessità non elevatissima, numerosi sono gli sviluppi futuri più fantasiosi che

richiederanno come minimo qualche anno prima di essere disponibili per queste

applicazioni. Ad esempio si può pensare a tute, guanti che siano in grado di fornire

sensazioni tattili e di contatto fisico, anche relativamente violento. Con attrezzature del

genere diventa facile pensare a ricostruzioni in cui il visitatore può effettivamente sentire,

toccare l’ambiente ricostruito, può urtare contro ostacoli e sentire l’impatto degli oggetti

con cui si scontra senza naturalmente tutte le conseguenze derivanti da uno scontro, come

il dolore e peggio ancora. Non solo, con opportuni accorgimenti si può pensare di integrare

in questi sistemi la capacità di far percepire i diversi gradi di temperatura e umidità degli

ambienti visitati. In questo modo sarà possibile riprodurre l’atmosfera, umida, un po’

opprimente di un cunicolo di una miniera con il suo odore di chiuso, di terra e roccia

oppure sarà possibile simulare il calore di un allegro fuoco scoppiettante oppure

l’atmosfera tetra e solenne di una chiesa o di un tempio, con odori di incenso e spezie che

si diffondono nell’aria. Abbiamo parlato anche di odori, non è un lapsus ma una possibilità

concreta, sembra infatti che sarà possibile riprodurre gli odori di un ambiente con la stessa

facilità con cui adesso siamo in grado di riprodurre i colori di un paesaggio in una

fotografia.

Anche per il movimento nell’ambiente tridimensionale è possibile immaginare nuovi

sviluppi. Ad esempio non è difficile pensare di creare una postazione di visita con tapis

roulant in grado di permettere la camminata e anche la corsa con il corrispondente

spostamento nell’ambiente ricostruito. Se poi questa postazione venisse dotata di appositi

attuatori si potrebbe pensare di simulare un terreno in pendenza e nel caso di una salita la

maggior difficoltà nel procedere innanzi. Fino a ora si è parlato sotto intendendo che la

visita dell’ambientazione tridimensionale avvenga a piedi, camminando, ma supponiamo

un attimo di dover visitare una miniera, in tal caso è possibile pensare di visitarla dentro a

un vecchio carrellino di trasporto dei minerali. Una postazione come quella descritta


permetterebbe di sentire tutti gli scossoni del carrellino che avanza sui binari rendendo la

visita molto, molto realistica.

In sostanza non è difficile immaginare un futuro più o meno prossimo in cui l’integrazione

tra visita reale e virtuale sarà così alta da rendere quantomeno difficoltosa la netta

separazione tra le due. Qui si porrà il problema di mantenere il contatto del visitatore con

la realtà, questo è un aspetto molto importante di cui tenere conto nel momento in cui si

studia la realizzazione un sistema di visita come quello descritto in questo paragrafo. E’

infatti essenziale che rimanga definito il confine tra realtà e ricostruzione anche se

quest’ultima tende e tenderà sempre di più a simulare fedelmente la prima.

2.4 Considerazioni finali Abbiamo descritto come dovrebbe essere una visita virtuale di una località turistica

cercando di trattare tutti gli aspetti della stessa. Si è visto che lo scopo di una visita virtuale

non è e non deve essere quello di soppiantare la visita reale ma è quello di sostituirsi ad

essa quando la stessa diventi difficoltosa per qualunque motivo. Si è anche visto che le due

possono coesistere in modo armonioso migliorando di molto la qualità del servizio

turistico. Adesso è necessario analizzare quali siano le tecnologie attualmente disponibili

sul mercato in modo da capire che cosa è effettivamente realizzabile ora e che cosa verrà

riservato per il futuro.

2.5 Analisi delle soluzioni attualmente disponibili Le tecniche di ricostruzione della realtà che si adattano agli obiettivi di un’applicazione

turistica si dividono in modo più o meno definito secondo due diversi approcci. Il primo è

quello più legato alla fotografia, in questo caso si tende a privilegiare la qualità della

ricostruzione a scapito dell’interattività della stessa. Si cercano di ottenere le massime

prestazioni qualitative nella riproduzione delle immagini, che hanno l’aspetto di una

fotografia, mentre si accetta che il movimento nell’ambiente lasci un po’ a desiderare. Il

risultato è un insieme di immagini di qualità decisamente elevata che sono unite tra loro da

un documento interattivo tipo pagina web. La navigazione vera e propria nell’ambiente

avviene selezionando con il mouse collegamenti ipertestuali che stabiliscono il corretto

ordine di presentazione delle immagini. Le informazioni sul luogo visitato sono riportate

nel documento ipertestuale che collega le immagini e così eventuali indicazioni

geografiche. E’ possibile aggiungere suoni e filmati raggiungibili con la stessa tecnica


delle immagini dell’ambiente ricostruito. E’ anche possibile l’utilizzo di foto panoramiche,

queste foto hanno la caratteristica di riprendere tutto il paesaggio che circonda un dato

punto e di permettere la rotazione di sé stesse in modo da simulare la sensazione di trovarsi

al centro dell’ambiente fotografato. Esempi classici di quest’approccio sono le visite

guidate a luoghi turistici offerte dalle enciclopedie multimediali, con questa tecnica è stata

realizzata la visita guidata della galleria degli Uffizi di Firenze. Manca però una vera

interattività utente – applicazione, non è infatti possibile, nell’ambiente ricostruito, ottenere

reazioni ad eventi che interessano l’ambiente stesso. La visita si limita al passaggio da un

collegamento ipertestuale ad un altro risultando piuttosto dispersiva. Da quanto detto nei

paragrafi precedenti è chiaro che non ci si può accontentare di questo approccio venendo a

mancare il requisito fondamentale della verosimiglianza, in particolare venendo a mancare

la possibilità di muoversi in modo assistito o completamente autonomo nella ricostruzione

e mancando anche, almeno in parte la tridimensionalità dell’ambiente ricostruito.

D’altra parte alcune soluzioni presentano un certo fascino, è infatti indubbia la capacità di

presentazione delle informazioni di una pagina web. In tali pagine, come noto, è possibile

includere testi, immagini, fotografie, suoni, che permettono di illustrare in modo piuttosto

efficace il luogo che il visitatore sta osservando. Non solo, la possibilità di avere

collegamenti ad altre immagini, ad altri testi, permette di allestire una presentazione

standard basata sulle esigenze dell’utente medio e di garantire un offerta più specifica,

dettagliata e completa per aree circoscritte di interesse (raggiungibili per l’appunto tramite

collegamenti ipertestuali).

Il secondo approccio è diametralmente opposto al primo ed è quello tipico dei videogiochi

di ultima generazione. Qui la capacità di ricreare ambienti tridimensionali è notevolmente

sviluppata e i risultati sono quantomeno interessanti. Il videogioco dal punto di vista

dell'applicazione turistica presenta numerosi aspetti positivi:

� Ha una spiccata capacità di generare e gestire ambienti tridimensionali anche di grandi

dimensioni, con una corretta rappresentazione prospettica dell’ambiente stesso.

� Non richiede capacità hardware irraggiungibili per il sistema di visita, aspetto finora

tralasciato ma di grande importanza realizzativa.

� Ha una buona gestione del movimento nello spazio tridimensionale, sia in prima sia in

terza persona e la capacità di causare movimenti automatici dei personaggi del gioco.

� Ha un notevole grado di interattività, è infatti possibile associare eventi a movimenti

particolari del giocatore, oppure associare reazioni ad azioni, che si verificano nel corso

di una partita. Ad esempio quando un giocatore colpisce l’avversario questi accusa il


colpo, quando il giocatore incontra una parete non può muoversi, quando il giocatore

seleziona un oggetto o ci passa sopra viene eseguita una certa azione.

Tutte queste qualità possono essere molto utili in una visita turistica a patto di

comprenderne il possibile utilizzo.

La capacità di creazione di scene tridimensionali permette di soddisfare il requisito

corrispondente prima formulato, la proprietà di non richiedere particolari sistemi

informatici va a vantaggio della semplicità e dei costi di creazione di un sistema di visita

virtuale. L’ottima gestione del movimento nello spazio tridimensionale permette la

fornitura di un numero relativamente alto di modalità di visita e soddisfa il requisito della

verosimiglianza, l’interattività permette di offrire alcuni servizi primari come la guida su

richiesta e numerosi servizi secondari come la presentazione, in determinate zone del luogo

di visita, di personaggi sintetici.

Se ci si fermasse qui sembrerebbe decisamente utile utilizzare un approccio stile

videogioco alla soluzione del problema, in realtà esistono altri aspetti che rendono

sconsigliabile l’uso di un tale metodo. Di questi quello di gran lunga più importante è la

bassa qualità degli ambienti ricostruiti.

Tali ambienti hanno ottime caratteristiche di tridimensionalità ma sono decisamente scarsi

dal punto di vista del realismo dell’ambiente riprodotto. Normalmente, in un videogioco si

privilegia la velocità di gioco a scapito del realismo degli ambienti di gioco. Per aumentare

la velocità di gioco si dipingono le pareti e gli oggetti tridimensionali con piccole immagini

semplici che vengono ripetute moltissime volte per dare una parvenza del materiale

dell’oggetto dipinto. Così un pezzo di legno verrà dipinto ripetendo migliaia di immagini

di una piccola parte di legno e così il resto dell’ambiente. E’ evidente che così facendo non

si ottiene certamente una qualità fotografica degli ambienti, per quanto le tecniche di

colorazione siano sofisticate l’immagine finale è formata in ogni caso da una o poche

semplici immagini ripetute. In un’applicazione turistica invece l’ambiente ricostruito deve

essere il più possibile fedele alla realtà. Se su un soffitto c’è un affresco è chiaro che questo

dev'essere visibile in modo nitido e dettagliato e non essere un’immagine strana che

sembra un po’ un puzzle.

In conclusione nessuno dei due metodi soddisfa i requisiti richiesti per la creazione di un

sistema di visita virtuale per ambienti turistici. Per risolvere il problema la tecnica migliore

è cercare un compromesso tra le esigenze contrapposte soddisfatte dalle due tecniche

illustrate in modo da ottenere la miglior qualità di visita possibile.


E’ quindi necessario stabilire come procedere per raggiungere un tale scopo, il punto di

partenza sarà ovviamente il videogioco, o meglio, la parte di base del videogioco che si

occupa della gestione degli ambienti, del movimento e delle azioni. Normalmente questa

parte viene indicata con il nome di motore di rendering e navigazione. Il rendering è

l’operazione di creazione delle immagini pseudorealistiche che formano lo scenario del

gioco mentre la navigazione è la parte che permette il movimento nell’ambiente di gioco.

Una volta individuato un motore di rendering e navigazione adeguato, è necessario cercare

di integrare lo stesso con un altra parte che si occupi della presentazione delle informazioni

in formato ipertestuale da associare alle varie scene, e quindi definire un punto di contatto

tra le due parti in modo da collegare il movimento nell’ambiente alla presentazione delle

informazioni e viceversa. Una volta ottenuto questo risultato occorrerà prevedere una terza

parte che si occuperà della presentazione degli ambienti e delle informazioni all’utente e

dell’interazione con l’utente stesso.

Il primo passo da fare è, allora, cercare un motore di rendering dalle caratteristiche

adeguate.

17

3 Motori di rendering e navigazione

Il capitolo inizia con una panoramica sui motori di rendering e navigazione

attualmente disponibili. Il primo problema da risolvere è come reperire informazioni

sugli stessi in modo da valutare se siano o meno adeguati per un’applicazione turistica.

La soluzione è una ricerca mirata su pagine www. Come ben noto una ricerca di questo

tipo è spesso dispersiva e richiede una notevole quantità di tempo e pazienza, in

particolare occorre aver ben presente cosa si vuole ottenere come informazioni per

evitare di fare ricerche a vuoto. Sicuramente sarà necessario tralasciare tutti quei

motori 3d la cui documentazione non sia accessibile, infatti per essi non sarà possibile

determinare se siano adeguati o meno ad applicazioni turistiche.

18 3-Motori di rendering e navigazione

3.1 Tipologie

Analizzando quanto risulta dalle ricerche sul Web si possono definire due principali

categorie di videogiochi e quindi di motori di rendering. La prima è più generale e

comprende giochi di svariata natura, dalle gare automobilistiche ai combattimenti aerei,

alle avventure stile “Tomb Raider”. La seconda è invece più specialistica ed è quella dei

giochi di ruolo o RPG (Role Playing Games). Questi prevedono che il giocatore si

immedesimi in un personaggio e lo conduca in un mondo fantastico alla ricerca di qualcosa

che lo renda migliore, il giocatore deve cioè condurre il personaggio come fosse se stesso e

comportarsi di conseguenza. Sfortunatamente questa divisione che risulta evidente

effettuando la ricerca, non è utile per decidere quali siano gli strumenti migliori per la

realizzazione di un sistema di visita virtuale. Entrambe le categorie, sembrano infatti essere

dotate di motori in grado di soddisfare le esigenze di una visita virtuale. Non resta quindi

che affinare la ricerca analizzando uno per uno i vari motori per capire se soddisfino i

corretti requisiti. Nel fare questo verranno scartati tutti quelli che risulteranno poco

documentati o che non soddisferanno in modo evidente tali requisiti in modo da ottenere

come risultato una rosa di possibili candidati fra cui scegliere il migliore.

A questo punto è importante parlare anche di una ulteriore grossa divisione che si è

evidenziata con il procedere della ricerca, la separazione tra motori di rendering 3d

freeware (liberi, non a pagamento) e quelli commerciali. Questa non è una cosa da tenere

in conto nel caso di una applicazione a scopo di lucro, ma nel caso di una tesi diventa

importante, dato che spesso i prezzi di tali programmi sono piuttosto elevati. Rimane da

questo punto di vista una piccola scappatoia costituita dalla licenza gratuita all’utilizzo non

commerciale (ovvero per studio) di alcuni di questi motori 3d. In ogni caso a parità di

prestazioni presunte o nel caso le differenze siano di lieve entità verranno ovviamente

privilegiate le applicazioni gratuite.

3.2 Caratteristiche

Prima di illustrare le caratteristiche di ogni singolo motore preso in considerazione è

importante fissare le qualità minime che questi devono possedere per diventare possibili

candidati all’utilizzo turistico. I motori 3d adatti dovranno essere relativamente semplici da

utilizzare, avere una chiara documentazione, avere la capacità di trattare immagini in

qualità fotografica, di gestire eventuali sequenze filmate, di sfruttare la possibilità di

3-Motori di rendering e navigazione 19

accelerazione hardware della rappresentazione tridimensionale, di gestire l’interazione tra

utente e ambiente 3d e dovranno offrire la capacità di visualizzare informazioni

testuali/ipertestuali o la possibilità di essere controllati da un’altra applicazione che si

occupi della presentazione di tali informazioni. In quest’ultimo caso sarà necessario poter

scambiare informazioni tra il motore 3d e l’applicazione in modo da rendere la

presentazione tridimensionale e quella testuale mutuamente dipendenti.

3.3 Motori 3d

In questo paragrafo verranno illustrate in modo più specifico le caratteristiche dei motori

3D che soddisfano i requisiti di un’applicazione turistica, rimandando il lettore

all’appendice A per le caratteristiche dei motori scartati per un motivo o per un altro. I

motori 3D che sembrano adeguati sono: 3D RAD, 3D Game Studio, Fly 3D, Auran Jet,

Phoenix 3D, Morfit 3D engine. Naturalmente ne sono disponibili molti altri ma non sono

stati presi in considerazione o perché non risultanti nella ricerca (chiaramente trovare tutti i

motori 3d disponibili non è proponibile in termini di tempo) oppure perché dotati di

documentazione frammentaria.

Nella descrizione delle caratteristiche dei motori 3d si farà spesso uso di termini inglesi

specifici delle applicazioni di grafica tridimensionale, per eventuali chiarimenti è possibile

riferirsi al glossario riportato in fondo all’appendice A.

Motori di rendering e navigazione: caratteristiche tecniche

Motore di

Rendering

Piattaforma

Visualizzazione

di filmati

Creazione di

ambienti

fotorealistici

Linguaggio di

programmazione

Librerie

3D

Documentazio

ne

3D RAD Win95/98 si si - DirectX

6.1

Solo dopo

l’acquisto

3D Game

Studio

Win95/98 si si WDL (derivato da

javascript)

- Solo dopo

l’acquisto

Fly 3D Win95/98 - si VC++ DirectX

6.1

OpenGL

1.1

Libera,

abbastanza

chiara


Motore di

Rendering

Piattaforma

Visualizzazione

di filmati

Creazione di

ambienti

fotorealistici

Linguaggio di

programmazione

Librerie

3D

Documentazio

ne

Phoenix

3D

Win95/98 - si - DirectX

6.1

Libera,

abbastanza

chiara

Morfit 3D

Engine

Win98 no si VC++, Visual

Basic, Borland

C++ Builder

OpenGl,

DirectX,

Glide

Libera,

abbastanza

chiara

Auran Jet Win95/98 si si VC++ OpenGL

DirectX

Libera,chiara

Tab. 3.1 –Caratteristiche Motori 3D/1-

Motori di rendering e navigazione: caratteristiche avanzate, tipi di licenza

Motore di

rendering

Riproduzione

suoni

Gestione

formati

modellazione 3D

Integrazione

in altre

applicazioni

Ottimizzazione

Licenza

Architettura

3D RAD si 3DS MAX - - Commerciale -

3D Game

Studio

si - - - Commerciale -

Fly 3D si 3DS MAX - Interni/esterni Commerciale,

licenza

studente

Plug-in

VC++

Phoenix

3D

si 3DS MAX,

Maya 3D,

LightWave

- - Commerciale -

Morfit 3D

engine

si 3DS MAX,

QUAKE,

VRML

si Interni/Esterni Freeware Libreria a

collegamento

dinamico

Auran Jet si 3DS MAX,

Maya 3D

- Interni/Esterni Commerciale,

licenza

studente

Librerie

dinamiche su

diversi livelli

di astrazione

Tab. 3.2 –Caratteristiche Motori 3D/2-


Ulteriori dettagli sono riportati in appendice A.

3.4 Selezione

Come può essere facilmente notato, tutti i motori 3d descritti per sommi capi hanno

caratteristiche tali da rendere perlomeno interessante il loro utilizzo in ambito turistico, uno

solo di questi dovrà essere selezionato. Come affermato nel paragrafo 3.1 eliminiamo

subito i motori commerciali che non abbiano edizioni ad uso gratuito. La scelta si riduce ai

motori Fly 3D, Morfit e Auran Jet. La scelta di uno di questi è decisamente più complicata

dato che tutti e tre soddisfano i requisiti di base e sono ad uso gratuito. E’ allora necessario

analizzare la capacità di offrire informazioni testuali/ipertestuali e/o di essere integrati in

altre applicazioni. Nessuno dei tre offre la possibilità di visualizzare direttamente testi o

ipertesti, tutti permettono di visualizzare immagini in qualità fotografica, solo Auran Jet è

in grado di visualizzare direttamente filmati. In realtà tale capacità non può essere

discriminante perché, la possibilità di visualizzare filmati su comando dell’utente, può

essere offerta dall’applicazione che controlla il motore 3d. Rimane solo la possibilità di

essere integrati in una architettura software esterna per selezionare il motore adatto e in

questo caso la scelta ricade su Morfit. Questo perché gli altri due sembrano più difficili da

integrare in un altro programma avendo nel caso di Fly 3D la possibilità di essere

programmati tramite plug-in o nel caso di Auran Jet una architettura software definita,

proprietaria e non essendo ben chiaro se è possibile interagire con i due da un’altra

applicazione. Nel caso di Morfit è ben chiaro invece che il motore 3d non è altro che una

libreria di funzioni utilizzabili da un qualunque programma scritto in Visual Basic o in

Visual C++ e anzi che non può esistere in maniera autonoma ma deve avere comunque

un’applicazione che ne richiami le funzioni.

3.5 Morfit 3D Engine

Una volta deciso che il motore di rendering e navigazione da utilizzare sarà Morfit è utile

trattare in modo più approfondito le sue caratteristiche. Morfit è costituito da un insieme di

librerie e programmi applicativi. In particolare esiste una libreria a collegamento dinamico

(DLL) contente le funzioni del motore 3D che deve essere richiamata dall’applicazione che

incapsula il motore, sia essa gioco o applicazione turistica. Per farlo esiste un file

intestazione di Visual C++ in cui sono definite le funzioni disponibili e ne vengono


descritte le caratteristiche. Oltre alla libreria che forma il nucleo operativo del motore 3d

vengono fornite due applicazioni per la creazione degli ambienti tridimensionali da

utilizzare. La prima si chiama Terrain Builder e come suggerisce il nome permette la

creazione di paesaggi e ambienti esterni in cui posizionare altri elementi tridimensionali. Il

Terrain Builder serve quindi per creare il mondo di base in cui verrà ambientato il gioco

(nel nostro caso la visita). La creazione del paesaggio avviene a partire da un’immagine

bitmap in cui il colore dei singoli pixel rappresenta l’altezza degli stessi. A un colore scuro

corrisponde un punto basso e mano a mano che il colore diventa più chiaro l’altezza

aumenta. Ad esempio un’immagine costituita da cerchi concentrici con colori sfumati dal

nero al bianco darà origine a un ambiente 3d a cono. E’ possibile utilizzare immagini da

satellite o modelli numerici del terreno opportunamente elaborati per ricostruire ambienti

reali, dopodiché è possibile definire un’immagine da utilizzare per rivestire il terreno

creato in modo che questo sia più realistico.

L’altra applicazione si chiama World Builder e come suggerisce il nome viene utilizzata

per costruire l’ambientazione tridimensionale in cui si svilupperà il gioco ( o l’applicazione

turistica). E’ con questa applicazione che si inseriscono case, alberi, etc in un ambiente

esterno oppure muri, arredamenti, etc. in un ambiente interno. Non solo, qui si definiscono

anche oggetti particolari che permettono la visualizzazione del mondo 3d creato: le

telecamere. Una telecamera può essere posizionata in un qualunque punto dell’ambiente 3d

e può essere mossa per dare l’idea di esplorare fisicamente l’ambiente ricostruito. Tutti gli

oggetti 3d inseriti nel mondo virtuale devono essere colorati in modo da ricordare l’oggetto

reale che rappresentano, per farlo è possibile utilizzare immagini .bmp o .jpg e quindi

fotografie, questo permette di soddisfare il requisito della verosimiglianza dell’ambiente

ricostruito. Naturalmente tutti gli elementi che compongono il sistema di sviluppo Morfit

sono dotati di documentazione e di esempi facilmente comprensibili. E’ anche disponibile

un manuale in formato cartaceo dal titolo 3D Programming for Windows.

I requisiti di sistema del motore 3d sono facilmente raggiungibili anche da macchine non

professionali (questo è un vantaggio dal punto di vista del costo dell’apparato di visita).

Sono:

� Un sistema operativo compatibile con Windows95, Windows98, WindowsNT.

� Una scheda acceleratrice grafica che seppur non strettamente necessaria permette di

rendere più fluida e realistica la ricostruzione senza contare il fatto che alcuni effetti

sono visibili solo se essa è presente.


� Un sistema di sviluppo compatibile con il motore Morfit: Microsoft VisualC++ 6.0,

Microsoft VisualC++ 5.0,Borland C 5.0,Borland Builder, Delphi o Visual Basic.

L’ultimo requisito riguarda ovviamente solo il calcolatore utilizzato per sviluppare

l’applicazione e non il sistema di visita su cui l’applicazione deve essere eseguita.

Con l’ultima versione del motore 3D si è anche resa disponibile la capacità di trasferire e

includere in pagine web gli ambienti ricostruiti e questo può essere interessante per fornire

la possibilità di una visita a distanza degli ambienti ricostruiti.

L’ultima cosa da dire su questo motore 3d, che determinerà alcune scelte di realizzazione

di un prototipo dimostrativo di visita virtuale è la capacità di lavorare in due modalità

grafiche alquanto diverse: Editor Mode o Viewer Mode.

La scelta tra queste due modalità influenza notevolmente la programmazione della

ricostruzione 3d sia per quanto riguarda le funzioni da utilizzare che per quanto riguarda le

massime prestazioni ottenibili in termini di velocità.

Lavorando nella modalità Viewer Mode, la prima volta che viene caricato l’ambiente

tridimensionale ricostruito, il motore di rendering crea una struttura dati molto ampia detta

albero BSP (Binary Search Path). L’albero BSP viene utilizzato per decidere quali

superfici del mondo tridimensionale saranno visibili in ogni istante. Lavorando nella

modalità Viewer i calcoli relativi alle superfici nascoste sono molto più veloci che nella

modalità Editor, e quindi la velocità di rendering dell’ambiente tridimensionale espressa in

frame al secondo sarà più elevata. Non solo, nella modalità Viewer è possibile far sì che

certi oggetti si muovano in modo autonomo lungo un percorso predefinito o secondo le

leggi della fisica senza alcun intervento a livello di programmazione. Il problema è che il

Viewer Mode non permette la creazione e la distruzione di poligoni cioè di elementi

dell’ambiente 3d. Questo significa che l’intero ambiente ricostruito deve essere definito

tramite il World Builder e non può essere modificato dinamicamente dall’applicazione di

visita. L’Editor Mode invece permette la creazione da parte dell’applicativo di visita di

elementi tridimensionali e questo favorisce sia l’interattività della visita (possono essere

visualizzati ambienti diversi a seconda delle esigenze dell’utente) che la facilità di gestione

di grandi ambienti. In tal caso è possibile ricreare solo la zona attorno al visitatore

risparmiando risorse del sistema di visita e rendendo più veloce la ricostruzione degli

ambienti. Naturalmente questa maggior flessibilità si paga con una minore velocità di

rendering rispetto alla modalità Viewer Mode (perlomeno per ambienti di dimensioni

ridotte).


Uno dei problemi con cui ci si dovrà scontrare nella definizione dell’architettura software

del sistema di visita sarà proprio la scelta di utilizzare il motore 3d nel Viewer mode o

nell’Editor Mode.

3.6 Primi Compromessi

Dall’analisi delle caratteristiche dei vari motori di rendering e in particolare di Morfit pare

chiaro che sia possibile l’utilizzo di immagini per rivestire oggetti dell’ambientazione

tridimensionale e quindi che sia possibile ottenere una qualità di riproduzione degli

ambienti di tipo fotografico. Il problema è lo spazio e le risorse computazionali che

l’impiego massiccio di fotografie richiede. Si rischia infatti che per cercare di ottenere la

massima verosimiglianza possibile si penalizzi la fluidità di movimento nell’ambiente

tridimensionale non raggiungendo quindi l’obiettivo stesso del realismo. Si vogliono

realizzare scene pseudoreali ma al contempo visitabili, percorribili con un certo comfort e

questo non è purtroppo ottenibile lavorando costantemente in qualità fotografica.

Perlomeno il farlo richiederebbe l’utilizzo di apparati specifici, decisamente costosi e il

risultato non sarebbe sensibilmente migliore di quello che si può ottenere con un’abile

compromesso. Infatti, se per un attimo ci mettiamo nei panni di un possibile visitatore ci

rendiamo conto che in prima istanza, non è affatto necessario riprodurre in qualità

fotografica l’intero ambiente ricostruito ma solo quelle zone di effettivo interesse. In un

museo è importante ricostruire fedelmente i reperti, non certo i corridoi che portano da una

stanza ad un’altra. Si può allora pensare di riservare la massima qualità di ricostruzione ad

ambienti specifici, di dimensioni contenute e invece di limitarsi ad accettare una qualità di

ricostruzione soltanto buona nelle zone di passaggio che non presentano particolari

attrazioni. Accettare di avere una qualità soltanto buona significa sfruttare appieno le

tecniche di rendering e di texturing dei videogiochi con il risultato di avere zone

dell’ambiente ricostruito che ricordano molto da vicino le zone reali ma che non sono

identiche alle stesse. È molto importante conservare la corrispondenza tra ambiente reale e

ambiente ricostruito, così si può sfruttare il senso di orientamento del visitatore per evitare

di perdere il contesto della visita. Si può ottenere un rapporto di somiglianza simile a

quello che c’è tra un oggetto e il disegno dello stesso. Questo permette un notevole

risparmio di risorse computazionali del sistema di visita dato che le immagini utilizzate per

“dipingere” i particolari sono molto piccole e visto che se ne utilizzano poche, anche una

sola per ciascun elemento tridimensionale. Il risparmio di risorse si tramuta in un aumento

di velocità di esecuzione e quindi in una maggiore fluidità e un migliore realismo dei


movimenti nell’ambiente 3D. Probabilmente questo non sarà che il primo dei compromessi

da accettare, ma sembra utile trattarlo in questo capitolo dato che deriva da problemi

comuni a qualunque motore di rendering e navigazione e non dal tipo di ambiente da

ricostruire.

27

4 Architettura dell’applicazione di visita

Una volta scelto il motore di rendering e navigazione da utilizzare e esaminatone il

funzionamento, è necessario organizzare dal punto di vista della programmazione

l’applicativo di visita virtuale. Innanzitutto, occorre integrare nell’applicazione di

visita alcune funzionalità che il motore non offre (la visualizzazione di ipertesti, ad

esempio) e quindi, unire il motore stesso alla parte che le gestisce, contornando il tutto

con una presentazione all’utente semplice ed efficace. Poiché Morfit è programmabile

in Visual C++ rivolgeremo la nostra attenzione alle problematiche di questo linguaggio

nel lavoro di costruzione e organizzazione di un’applicazione di visita virtuale di un

sito turistico.

28 4-Architettura dell’applicazione di visita

4.1 Applicazione di visita: obiettivi reali

Dopo aver esaminato tutte le possibili modalità di realizzazione di una visita turistica

virtuale, nel secondo capitolo, si vuole ora studiare come realizzare una tale applicazione

software con lo scopo di dimostrare che è effettivamente possibile realizzare quanto detto e

che il risultato può essere di sicuro interesse. Naturalmente occorre stabilire degli obiettivi

da rispettare, obiettivi che non devono mirare alla creazione di un dispositivo di visita

perfettamente funzionante con tutte le possibilità del caso ma alla creazione di un sistema

dimostrativo per chiarire che l’argomento trattato sinora è fisicamente realizzabile e non

una semplice speculazione filosofica.

Vogliamo realizzare un’applicazione di visita virtuale che fornisca la possibilità di

presentare informazioni ipertestuali (testi, suoni, filmati,..) che riguardano l’ambiente di

interesse turistico che viene ricostruito. La qualità della ricostruzione non sarà fotografica,

ma la presentazione accurata verrà riservata ai soli luoghi di interesse.

Quanto alle modalità di visita si vuole fornire solamente un esempio di cosa sia possibile

ottenere in una ricostruzione di questo tipo e quindi saranno ovviamente un numero

ristretto. A tal riguardo sarà fornita la possibilità di visita in prima persona, libera, senza

alcun vincolo ai movimenti possibili, di visita assistita, in cui l’utente comanda

l’avanzamento nell’ambiente ricostruito ma viene vincolato nei movimenti a percorrere un

insieme di traiettorie parzialmente prefissate e infine, si prevede la realizzazione di una

modalità di visita automatica in cui l’utente viene condotto in modo automatico all’interno

dell’ambiente ricostruito secondo un percorso stabilito a priori. Dire che nella visita

assistita la traiettoria è parzialmente prefissata significa che in tale modalità di visita

l’utente viene mantenuto sempre al centro dell’ambiente che sta visitando evitando

fastidiosi scontri con elementi dell’ambiente e limitando al massimo lo sforzo

nell’apprendimento dei movimenti da effettuare per controllare la visita. Questo non

significa però che l’utente non conservi la capacità di scegliere il proprio percorso, egli

infatti potrà stabilire a piacimento la direzione da prendere ai vari incroci che si

presenteranno nella visita e in generale potrà provocare cambiamenti dell’itinerario di

visita ogni qual volta sia necessario. Per tutte le modalità di visita si vorrebbe visualizzare

in modo più o meno preciso la posizione dell’utente nell’ambiente ricostruito e dare la

possibilità allo stesso di spostarsi in un punto qualunque di tale ricostruzione,

semplicemente selezionandolo sulla mappa.

4-Architettura dell’applicazione di visita 29

Naturalmente per ottenere questi risultati è necessario affrontare e risolvere numerosi

problemi relativi alla programmazione e all’architettura software del sistema di visita.

4.2 Visualizzazione di ipertesti

Come finora discusso è necessario integrare le funzionalità del motore 3D con la capacità

di visualizzare ipertesti. Sicuramente si deve creare ex-novo una parte di software che

fornisca questa funzionalità. Non appare però intelligente cercare di creare a partire da zero

un modulo software in grado di gestire completamente la visualizzazione di ipertesti.

Poiché il sistema operativo per cui è stato creato il motore di rendering è Windows98 che

dispone di un browser web (Internet Explorer) in grado di visualizzare correttamente

ipertesti di complessità elevata, sembrerebbe più razionale trovare un modo per integrare lo

stesso nell’applicazione di visita, in modo da sfruttarne le capacità. Come spesso accade

nella programmazione esistono certamente più soluzioni valide, con diversi vantaggi e

svantaggi. In questo caso si è preferito cercare le eventuali soluzioni realizzabili con il

linguaggio Visual C++. La soluzione esiste ed è relativamente semplice: nella parte di

Visual C++ che si occupa di fornire accesso alle varie funzioni del sistema operativo esiste

un particolare tipo di struttura dati (classe) che, accompagnato da un certo numero di

funzioni ad essa associate, permette l’utilizzo di Internet Explorer all’interno di una

applicazione distinta. Prima di proseguire la discussione su come sfruttare questa

funzionalità occorre fornire alcuni cenni sulla programmazione Windows in Visual C++ o

meglio sull’architettura dei programmi che sfruttano le funzioni offerte dal sistema

operativo stesso.

4.3 Architettura documento/vista

La programmazione Windows in Visual C++ è basata sull’utilizzo di un insieme di classi

che incapsulano in modo più o meno evidente le funzioni offerte dal sistema operativo.

Queste classi sono note come MFC (Microsoft Foundation Classes) e sono proprietarie,

cioè non disponibili in altri ambienti di sviluppo. Le classi sono particolari strutture dati,

tipiche della programmazione ad oggetti che uniscono ai dati veri e propri le funzioni

necessarie ad elaborare gli stessi.


La programmazione Windows è sostanzialmente una programmazione ad eventi, un dato

programma non ha un vero e proprio flusso di operazioni autonomo, ma reagisce ai

comandi dell’utente. L’architettura dei programmi MFC definisce come deve essere

gestita l’interazione con l’utente, cioè quali parti di codice dovranno occuparsi di

rispondere ad azioni dell’utente, quali della visualizzazione delle informazioni, quali della

comunicazione con il sistema operativo.

La tipica architettura di una applicazione per Windows è nota come architettura

documento/vista.

È possibile iniziare lo studio delle architetture documento/vista focalizzando l’attenzione

sui numerosi oggetti coinvolti. La figura 4.1 illustra una rappresentazione schematica di

tale architettura.

Fig. 4.1 – architettura documento/vista

La finestra con frame è la finestra di livello superiore dell’applicazione e dispone

generalmente di una barra del titolo, un menu di sistema, e di pulsanti per ingrandire,

ridurre e chiudere la finestra stessa. La vista è una finestra secondaria adattata alla finestra

con frame in modo da diventarne a tutti gli effetti l’area utente. I dati dell’applicazione

vengono memorizzati nell’oggetto documento di cui la vista fornisce una rappresentazione

visiva. Le frecce rappresentano il flusso di dati tra i vari elementi di un’architettura

documento/vista. L’oggetto applicazione si occupa di ricevere i messaggi del sistema

operativo, relativi anche ad azioni dell’utente, e di smistarli verso gli oggetti competenti.

L’oggetto vista si occupa di tradurre le azioni effettuate dall’utente con mouse e tastiera in


operazioni sui dati del documento, il quale a sua volta fornisce i dati da visualizzare nella

vista.

L’utilità di un modello simile per lo sviluppo di un’applicazione per la visita virtuale di siti

turistici è data dal fatto che le MFC offrono una classe vista già pronta che incapsula in

modo completo le funzioni di Internet Explorer e che quindi permette di gestire in modo

semplice la presentazione di ipertesti. Questa classe dispone di varie funzioni che

permettono di controllare quali siano le parti dell’ipertesto selezionate dall’utente e

pertanto di reagire correttamente ad azioni dello stesso. Quello che resta da fare è trovare

un modo per utilizzare queste informazioni al fine di aggiornare correttamente la

ricostruzione tridimensionale dell’ambiente oggetto di visita. Per far questo è di nuovo

utile il modello documento/vista dei programmi Windows, qui, infatti esiste un oggetto, il

documento, che è in grado di comunicare in modo bidirezionale con una vista e quindi di

ricevere informazioni dalla stessa e di inviarle comandi. Questa è l’essenza del compito

dell’applicazione esterna che deve incapsulare il motore di rendering e navigazione. Infatti

tale applicazione deve riconoscere le azioni dell’utente nel mondo tridimensionale e

tradurle nella presentazione delle informazioni corrette e deve viceversa capire quali

informazioni siano state richieste ed aggiornare di conseguenza l’ambiente gestito dal

motore 3D. Occorre pertanto creare una nuova vista che chiameremo tridimensionale il cui

aggiornamento visivo sarà affidato al motore di rendering e navigazione. L’applicazione

completa disporrà quindi di una finestra con frame, un oggetto documento e due viste, la

vista tridimensionale e la vista per gli ipertesti (che d’ora in poi chiameremo vista HTML).

L’oggetto documento verrà utilizzato per raccogliere informazioni dalla vista attiva, su cui

sta agendo l’utente, e le utilizzerà per aggiornare la vista non attiva. Agirà quindi da canale

di comunicazione tra le viste in modo da poter fornire sempre una presentazione corretta

dell’ambiente ricostruito e delle informazioni associate.

Nel capitolo 2 si parlava di associare a certe zone del sito turistico immagini, suoni, filmati,

questo è possibile perché la vista HTML è in grado di gestire in modo autonomo un

documento HTML in cui è possibile includere tali risorse. Sarà quindi compito della vista

HTML il controllo della presentazione di filmati, suoni, immagini e nel caso essa non sia

in grado di farlo direttamente, il controllo di applicazioni apposite che si occupino della

presentazione (ad esempio Windows Media Player per i filmati).


4.4 Ricostruzione dell’ambiente di visita

La prima operazione da eseguire per creare l’applicazione di visita virtuale è ricostruire

l’ambiente da visitare. La soluzione migliore è disporre di un programma di modellazione

tridimensionale dedicato e utilizzarlo per disegnare, o meglio definire i vari elementi che

compongono l’ambiente da visitare. In questa fase verranno create le varie stanze (nel caso

di una visita in ambienti chiusi) e i vari oggetti di arredamento che in esse verranno

disposti, si definiranno i materiali che compongono gli oggetti e si coloreranno gli stessi in

modo da ottenere una rappresentazione verosimile. Se poi la zona che si ricostruisce è

interessante dal punto di vista turistico la rappresentazione sarà fotografica. Una volta

definiti i vari ambienti sarà sufficiente utilizzarli così come sono nell’applicazione di

visita. La tecnica è intelligente sia perché è possibile definire separatamente l’aspetto dei

singoli ambienti, sia perché è possibile affidare tale compito a persone competenti in grado

di ottenere risultati migliori di quelli ottenibili senza un addestramento specifico. Dal punto

di vista dell’applicazione è sufficiente accedere ogni volta all’ambiente corretto,

visualizzarlo e permettere il movimento dell’utente nello stesso. Tutto questo in linea di

principio è realizzabile con il motore di rendering selezionato, anzi permetterebbe il suo

utilizzo nella modalità Viewer che fornisce più alte prestazioni in termini di velocità di

ricreazione della scena 3D e di fluidità del movimento. Purtroppo però il programma

fornito con il motore per la creazione del mondo 3D non è sufficientemente potente e

semplice da utilizzare, per permettere la creazione agevole dei vari ambienti.

Sarebbe possibile utilizzare programmi migliori per la ricostruzione dell’ambiente

tridimensionale (TrueSpace, Maya3D, Lightwave, Extreme3D, 3DStudioMax) ma molti

dei formati da essi utilizzati per la memorizzazione delle informazioni non dispongono di

convertitori per il formato proprietario di Morfit, in più il convertitore da VRML (Virtual

Reality Modelling Language, formato che tutti i programmi citati sono in grado di

generare) non funziona per tutti gli oggetti definibili in VRML, in particolare per sfere,

cubi,...

Esiste un convertitore per i file generati da 3DS Max ma il problema è che questa

applicazione oltre a richiedere un notevole sforzo di apprendimento per un corretto

utilizzo, è a pagamento e si parla di cifre notevoli.

Sarà giocoforza necessario rinunciare all’utilizzo di questo modo di procedere e pensarne

un altro (in ogni caso qui si è scelto di continuare l’utilizzo di Morfit per svariati motivi sia

di semplicità di gestione che di apprendimento, nonché per motivi di costi, nulla però vieta


di provare ad utilizzare uno degli altri motori che soddisfano i requisiti richiesti e che

hanno la capacità di trattare file generati dalle applicazioni di disegno tridimensionale

citate).

La soluzione è generare all’interno dell’applicazione stessa i vari ambienti da ricostruire e

sfruttare due caratteristiche tipiche di ogni ambiente reale: la somiglianza che accomuna

diversi elementi di ambienti diversi (una lampada è tale in qualunque ambiente venga

posizionata) e il fatto che l’aspetto dell’ambiente dipende dalla nostra percezione e non

dalla sua effettiva composizione. Sappiamo sicuramente che molte zone dell’ambiente da

ricostruire saranno simili tra loro, ad esempio i corridoi che uniscono le zone interessanti

dal punto di vista turistico saranno molto simili ed è possibile pensare di accettare un

compromesso e di ricostruirli tutti allo stesso modo, perlomeno per quanto riguarda gli

elementi fondamentali (le pareti). Così facendo si evita di definire a livello di

programmazione ogni singolo ambiente nei minimi particolari ma è possibile limitarsi a

definire un modello generale da riutilizzare ogni volta che serve, con piccole modifiche

alle parti non fondamentali. Rimane da considerare il secondo aspetto citato, cioè il fatto

che la verosimiglianza dell’ambiente dipenda essenzialmente dalla percezione che ne

abbiamo. Facciamo un esempio, se costruiamo un parallelepipedo rettangolo e

sovrapponiamo allo stesso un prisma a base triangolare otteniamo una figura di questo

genere:

Fig.4.2 – costruzione di una casa: fase 1

x

y

z


Se però rivestiamo ciascuna singola faccia della figura che abbiamo costruito con

immagini adeguate otteniamo una casa dall’aspetto quasi reale.

Fig. 4.3 – costruzione di una casa: fase 2

Questo esempio ha lo scopo di dimostrare che è possibile ottenere oggetti dall’apparenza

complessa e quasi reale a partire da semplici elementi tridimensionali rivestendoli con

immagini opportune. In linea di principio è quindi possibile ricostruire una varietà enorme

di corridoi a partire da un parallelepipedo rettangolo, utilizzando ogni volta immagini

diverse per rivestirlo. Allo stesso modo un luogo interessante dal punto di vista turistico

può essere ricostruito creando una stanza circolare con soffitto a volta sui cui vengono

visualizzate le immagini dell’ambiente reale in qualità fotografica. Una volta effettuata tale

operazione non sarà più possibile capire qual è la foto utilizzata come rivestimento e qual è

l’elemento tridimensionale utilizzato, a patto di non avvicinarsi troppo all’elemento stesso.

La tecnica illustrata permette quindi di ricostruire ambienti anche piuttosto diversi a partire

da un insieme relativamente ristretto e riutilizzabile di elementi tridimensionali.

Si è scelto di generare a livello di codice questo insieme di elementi fondamentali a causa

della scarsa compatibilità di Morfit con i più diffusi formati di definizione di modelli

tridimensionali. Da questo punto di vista la soluzione migliore appare la creazione di una

serie di classi che rappresentano i singoli elementi tridimensionali raggruppate sotto una

classe principale che rappresenta un elemento 3d generico. In sostanza, la classe principale

si occuperà di offrire la memorizzazione delle informazioni valide per qualunque elemento

tridimensionale e i metodi per operare su tali informazioni, mentre le sottoclassi si

riferiranno a uno specifico elemento offrendo svariate possibilità di modifica sullo stesso.

Ad esempio nella classe principale verranno memorizzate informazioni come il nome

dell’elemento 3d, la posizione, etc. nelle sottoclassi invece, si memorizzeranno tutte le

informazioni necessarie alla costruzione di un singolo elemento 3d (un corridoio, una


galleria,…) come larghezza, altezza, immagini da utilizzare come rivestimento e verranno

forniti metodi per la costruzione e il posizionamento dello stesso. Per garantire una

maggiore modularità e riutilizzabilità si correderanno i singoli elementi di funzioni per la

creazione di particolari accessori che verranno utilizzati per diversificare gli elementi

tridimensionali ottenuti (ad esempio un corridoio con colonnato da uno senza).

Una volta definita l’infrastruttura che permette la creazione della ricostruzione

tridimensionale rimane da definire come questa debba essere utilizzata.

4.5 Organizzazione dell’applicazione di visita

Prima di definire nel particolare l’architettura dell’applicazione di visita, è necessario

immaginare quale sarà la possibile organizzazione della stessa, sia in termini visivi che in

termini operativi. Visivamente si può pensare ad una disposizione tale da garantire eguale

importanza e quindi eguale visibilità alla ricostruzione 3D e alla presentazione di

informazioni ipertestuali. Volendo poi che il passaggio dall’interazione con la prima a

quella con la seconda sia del tutto trasparente e privo di difficoltà, si giunge alla

conclusione che la miglior disposizione è quella formata da due aree di visualizzazione

affiancate. Devono ancora essere previste due aree che si occupino di offrire la

comunicazione tra utente e programma di visita. Una di queste rappresenterà l’interfaccia

grafica (pulsanti e/o menu) attraverso cui l’utente influenzerà la modalità e il percorso di

visita: in questa dimostrazione sono previste le modalità di visita automatica, assistita e

manuale (paragrafo 4.1). L’altra è quella nota come status bar e verrà utilizzata per fornire

varie informazioni all’utente, ad esempio l’indicazione della funzione di ciascun elemento

dell’interfaccia grafica. L’aspetto generale del programma di visita sarà organizzato come

in figura 4.4. Le due visualizzazioni affiancate verranno denominate viste, esse infatti

hanno la caratteristica di presentare all’utente le informazioni relative alla visita e quindi

offrono una “vista” dei contenuti da presentare ai visitatori.

Dal punto di vista operativo l’organizzazione può essere la seguente: le due viste saranno

aree attive della visualizzazione, esse saranno cioè in grado di rispondere alle azioni

dell’utente (movimento del mouse, pressione di determinati tasti). Dovrà essere garantita

una forma di comunicazione tra le due per mantenere sempre aggiornate e sincronizzate le

informazioni visualizzate. Il processo di comunicazione può essere così strutturato: la vista

che gestisce attualmente le azioni dell’utente (pertanto è attiva) e che deve provocare

l’aggiornamento della vista non attiva, imposta i parametri corretti di un oggetto


documento che garantisce un canale di comunicazione tra le viste e poi invia un messaggio

di aggiornamento alla vista non attiva. Quest’ultima, quando riceve il messaggio

(recapitatole dal documento), legge i parametri impostati dalla vista attiva nel documento e

aggiorna conseguentemente la propria visualizzazione.

Fig. 4.4 - layout dell’applicazione di visita

L’interfaccia grafica risponderà alle azioni dell’utente aggiornando coerentemente le

modalità di visita e/o l’aspetto di entrambe le viste.

4.6 Sincronizzazione vista 3d/vista HTML: Documento

La creazione dell’ambiente di visita avviene all’avvio dell’applicazione di visita ed è

realizzata nella prima funzione dell’oggetto documento che viene richiamata dal sistema

operativo all’avvio del programma. All’interno di questa funzione (OnNewDocument) si

utilizza l’infrastruttura offerta dalle classi degli elementi tridimensionali per la creazione

dei singoli elementi e il loro posizionamento. É possibile basare questa creazione su


informazioni memorizzate in un database, questo significa che l’aspetto dell’ambiente

ricostruito dipende dalle informazioni memorizzate nel database e che è sufficiente

modificare queste informazioni per ricostruire ambienti diversi, a seconda delle esigenze.

In linea di principio creando più voci in questo database è possibile accedere alle stesse in

risposta a particolari azioni dell’utente offrendo una forma per personalizzare l’ambiente

reale ricostruito e adattarlo alle esigenze del visitatore.

Nella stessa funzione verranno anche definiti i punti chiave del percorso di visita

automatico e l’URL del primo ipertesto da visualizzare.

L’oggetto documento si occuperà anche di permettere la comunicazione tra le viste

tridimensionale e HTML e di ridistribuire verso le stesse i messaggi di sistema che le due

devono trattare. Per farlo esistono diverse funzioni che il documento offre. La

ridistribuzione dei messaggi viene realizzata con una funzione particolare

(RouteCmdToAllViews) che come dice il nome si occupa di indirizzare i messaggi di

sistema prima verso la vista attiva e poi verso quella non attiva. Nel caso le due viste non

debbano trattare in modo specifico tali messaggi la stessa funzione richiama i metodi

standard MFC per la loro gestione. Per quanto riguarda la comunicazione tra le viste,

l’oggetto documento rende pubblico e disponibile un insieme di parametri che vengono

utilizzati dalle viste per scambiarsi informazioni, infatti entrambe possiedono la capacità di

accedere alle parti pubbliche dell’oggetto documento. Tra le informazioni che vengono

memorizzate per la comunicazione tra le viste, saranno compresi l’URL dell’ipertesto da

caricare in risposta a eventi controllati dalla vista 3d (movimento dell’utente nell’ambiente

3d, ad esempio) e il punto dove posizionare l’utente nel caso selezioni una specifica

locazione indicata nella mappa che la vista HTML si occupa di presentare.

4.7 Vista HTML

La programmazione della vista HTML è relativamente semplice dato che la maggior parte

delle funzioni richieste sono disponibili e riutilizzabili in modo chiaro e diretto. Esiste solo

una capacità da fornire in modo specifico: riconoscere il punto selezionato dall’utente

sulla mappa del sito turistico. La cosa è abbastanza facile, almeno concettualmente: quando

l’utente seleziona il punto sulla mappa viene inviata al nucleo di Internet Explorer la

richiesta di caricare la pagina associata a tale punto. A questo punto è sufficiente inserirsi

nel processo di comunicazione tra il browser e la vista, intercettare il nome della pagina

richiesta e in base allo stesso capire quale punto della ricostruzione 3d deve essere


visualizzato. Una volta fatto questo si aggiornano i parametri dell’oggetto documento

relativi alla posizione dell’utente nell’ambiente ricostruito e si provoca l’aggiornamento

della vista tridimensionale. La soluzione può apparire abbastanza complessa, in particolare

la parte che prevede l’inserimento nel processo di comunicazione vista/browser. In realtà

esiste una funzione MFC tipica della classe vista HTML (CHtmlView) che realizza proprio

quanto detto: quando la vista invia la richiesta di cambiare ipertesto al browser questa

funzione (OnBeforeNavigate) viene richiamata prima che avvenga il caricamento

dell’ipertesto e permette l’accesso al nome dello stesso. E’ allora sufficiente inserire

all’interno della funzione il codice necessario al riconoscimento del punto equivalente

nell’ambiente tridimensionale. Tale codice dovrà anche essere in grado di capire se il

collegamento selezionato dall’utente è un punto della mappa o no e in quest’ultimo caso

non aggiornare la vista 3d.

Infine, la vista HTML deve occuparsi della visualizzazione della prima pagina di

informazioni, che viene illustrata all’avvio del programma, chiedendo al nucleo del

browser la visualizzazione dell’ipertesto corrispondente quando viene creata e abilitata al

funzionamento dall’oggetto applicazione di cui abbiamo parlato nel paragrafo 4.3.

4.8 Vista tridimensionale

Questa vista dispone di funzionalità decisamente più complesse della vista HTML e del

documento, dato che si occupa della visualizzazione della ricostruzione dell’ambiente reale

e della gestione del movimento dell’utente nello stesso.

Il primo compito che la vista tridimensionale deve assolvere è visualizzare la prima

immagine della ricostruzione all’avvio dell’applicazione di visita. Prima però si dovranno

impostare tutti i parametri di rendering del motore 3D, parametri che rimarranno validi per

tutta la durata di funzionamento. Al momento della sua creazione la vista accede alla

telecamera (Morfit) che permette la visualizzazione del mondo tridimensionale, la

posiziona nel punto di partenza orientandola correttamente, dopodiché imposta la

risoluzione della visualizzazione 3d. Una volta fatto questo verifica la presenza, sulla

macchina utilizzata per permettere la visita virtuale, di una scheda acceleratrice hardware

per la visualizzazione di elementi tridimensionali. Se questa è presente, ne imposta i

parametri di funzionamento (profondità di colore, risoluzione, rendering in finestra e non a

tutto schermo), e quindi regola il colore dell’effetto atmosferico in modo che sia nero e lo

attiva. L’effetto atmosferico è quel particolare tipo di visualizzazione che ombreggia gli


oggetti più distanti dall’osservatore in modo che appaiano più scuri e meno distinti,

l’utilizzo di questa tecnica permette un notevole risparmio di risorse sull’apparato di visita

perché tutti gli elementi troppo distanti dall’utente non vengono visualizzati.

Se invece non è disponibile una scheda grafica 3d, la vista imposta il rendering software

(sfrutta il processore del computer utilizzato) e se è disponibile un versione

sufficientemente recente delle librerie DirectX o OpenGL emula il rendering hardware

(ottenendo la stessa qualità di rappresentazione con minore velocità di esecuzione). A

questo punto visualizza la prima immagine dell’ambiente ricostruito e termina la fase

iniziale di funzionamento.

La vista 3d si occupa della visualizzazione dell’ambiente ricostruito, pertanto, una volta

definiti i parametri di rendering ed effettuata la prima visualizzazione, deve aggiornare la

visualizzazione stessa ogni qual volta sia necessario, cioè quando l’utente si muove oppure

quando seleziona un punto del sito turistico, sulla mappa. Appare quindi chiaro che la vista

dovrà occuparsi della gestione del movimento e dato che esistono varie modalità di visita

dovrà adattarsi alle stesse. Offrirà pertanto un’interfaccia verso l’utente per permettere la

selezione della modalità di visita. L’interfaccia dovrà essere semplice ed intuitiva (esempio

in fig. 4.5), e sarà gestita da apposite funzioni che si occuperanno di aggiornare lo stato

dell’interfaccia stessa e di impostare un indicatore che permetta alla vista stessa di

identificare la modalità corrente di visita (automatica, assistita o manuale: paragrafo 4.1).

Fig.4.5 - selezione modalità di visita -

In base alla modalità di visita prescelta la vista reagirà in modo diverso alle azioni

dell’utente. Nella visita manuale la vista offrirà all’utente tutte le capacità di movimento

possibili e dovrà riconoscere i comandi utilizzati dall’utente per i movimenti, aggiornando

di conseguenza la visualizzazione. Naturalmente dovrà anche effettuare un completo


controllo di collisione per impedire che l’utente possa attraversare “come un fantasma” gli

elementi della scena 3d.

Nel caso della visita assistita l’utente avrà a disposizione un numero minore di controlli di

movimento, ossia avrà a disposizione un sottoinsieme dei controlli della visita manuale. In

questo caso il controllo di collisione non è strettamente necessario perché il movimento

dell’utente è vincolato ad una traiettoria prefissata. Dovranno però essere resi disponibili

dei comandi aggiuntivi per la scelta della direzione da prendere nei punti dell’ambiente

ricostruito in cui è possibile definire più traiettorie (bivi, incroci,…).

La visita automatica esclude quasi completamente le azioni eseguite dall’utente, essa infatti

offre una visita predeterminata e non modificabile dell’ambiente tridimensionale in cui non

è richiesto alcun intervento da parte del visitatore (che può comunque agire sulla vista

HTML). Nella modalità automatica di visita è prevista la possibilità di distribuire lungo il

percorso più punti di sosta, in corrispondenza di zone particolari dell’itinerario. Durante la

sosta potrà essere proposta la proiezione di un filmato, la descrizione vocale dei particolari

di importanza rilevante dal punto di vista turistico e sarà anche possibile offrire una

panoramica della zona interessante con uno o più movimenti della telecamera che riprende

l’ambientazione tridimensionale.

Per tutti i tipi di visita esisterà un modulo di codice che si occuperà del riconoscimento del

locale attualmente oggetto di visita in modo da poter inviare correttamente i messaggi di

aggiornamento alla vista HTML. Deve anche essere prevista la presenza di un modulo che

si occupi della gestione del “teletrasporto” cioè di spostare l’utente quando questi seleziona

un punto dell’ambiente ricostruito, sulla mappa riportata nella vista HTML.

La vista dovrà infine occuparsi di gestire correttamente il passaggio da una modalità di

visita ad una altra e di effettuare eventuali riposizionamenti dell’utente per garantire una

visita corretta.

4.9 Ipertesti

La parte di creazione di ipertesti è completamente indipendente dalla definizione

dell’applicazione a livello di programmazione. Gli ipertesti utilizzati sono delle normali

pagine HTML con tutti gli elementi che possono includere. La loro realizzazione può

essere tranquillamente affidata a professionisti o ad esperti del sito turistico che sappiano

organizzare in modo efficace le varie informazioni da presentare. Per integrarle

nell’applicazione di visita sarà sufficiente assegnare il nome corretto ai file .htm che


devono essere visualizzati ogni qualvolta si accede ad un determinato ambiente. Oppure,

nel caso la definizione dell’ambiente tridimensionale sia memorizzata in un database sarà

sufficiente associare all’interno dello stesso la pagina che compete ad ogni elemento

dell’ambiente.

4.10 Architettura dell’applicazione di visita

L’architettura complessiva dell’applicazione di visita viene illustrata nella figura 4.6.

Come si vede, il documento interagisce con il motore 3D in modo unidirezionale perché

controlla la sola creazione dell’ambiente tridimensionale. Invece interagisce in modo

bidirezionale con le due viste agendo da canale di comunicazione tra le due.

La vista HTML visualizza le informazioni della pagina HTML corretta e corrispondente

all’ambiente visitato dall’utente. La vista 3D interagisce in modo bidirezionale con il

motore 3D dato che ne imposta i parametri di rendering, ne controlla la visualizzazione e lo

utilizza per identificare il punto in cui è posizionato il visitatore. L’interfaccia grafica

permette all’utente la scelta della modalità di visita e nel caso di visita assistita offre

l’accesso ai comandi di direzione aggiuntivi. Sia la vista 3D, sia la vista HTML sono

sensibili alle azioni dell’utente e reagiscono con le modalità illustrate nei paragrafi

precedenti. Nel caso le informazioni di ricostruzione siano memorizzate in un database il

documento ha la capacità di accedere allo stesso e di leggere tali informazioni. Si può

vedere che l’architettura utilizzata è sufficientemente generale da poter essere applicata a

qualunque sito turistico sia esso all’aperto o all’interno di luoghi chiusi. A tal fine la

capacità di incapsulare il motore 3D si è rivelata di vitale importanza, permettendo un

controllo completo sullo stesso e il suo utilizzo mirato, senza limitazioni di sorta.


Fig. 4.6 – architettura dell’applicazione di visita

Database

Oggetto Documento

Motore 3D

Sottosistema Audio

Vista 3D

Vista HTML Pagina

HTML

Suoni Testo

Suoni

Immagini

Filmati Utente

43

5 Soluzioni tecniche adottate

Finora si è descritto in modo generale la struttura e il funzionamento dell’applicazione di

visita ma, limitandosi al livello di astrazione utilizzato, non è possibile rendersi conto dei

numerosi problemi da risolvere per giungere al risultato illustrato. Allora in questo piccolo

capitolo vorremmo dare un’idea della complessità dell’applicazione di visita indicando

alcuni dei problemi più importanti che si presentano e la loro soluzione ( e/o non

soluzione).

5.1 Localizzazione dell’utente

Uno di questi, forse il più evidente nella presentazione fatta è come riconoscere il punto

occupato dall’utente nella ricostruzione. Concettualmente la cosa sembra molto semplice,

44 5-Soluzioni tecniche adottate

è sufficiente avere una mappa del sito turistico e individuare il punto ove si trova il

visitatore. In questa applicazione però si è scelto di non creare una struttura dati che si

occupi di rappresentare la disposizione degli ambienti ricostruiti. Una soluzione alternativa

potrebbe prevedere la memorizzazione della posizione iniziale dell’utente (nota) e il

calcolo della sua posizione attuale in base agli spostamenti effettuati e alla loro direzione.

La cosa però ha una complessità oltremodo elevata e non appare quindi una soluzione

efficace. Esiste un modo molto più razionale per localizzare il visitatore ed è il seguente. Il

movimento autonomo nell’ambiente tridimensionale richiede la presenza di un controllo di

collisione per capire quando l’utente incontra elementi solidi del mondo stesso. Si può

pensare di utilizzare il controllo di collisione per individuare la posizione dell’utente. Si

definisce per ogni elemento tridimensionale visitabile (corridoi, stanze) un’entità che deve

essere in ogni caso attraversata per accedere agli stessi, come una porta, e la si utilizza

come soglia per segnalare alla vista 3D l’ingresso dell’utente in una data zona della

ricostruzione. Una soglia simile verrà posizionata all’uscita della zona visitabile in modo

da capire quando il visitatore l’abbandona. Così facendo la vista non deve mai interrogare

il motore 3D per capire quale sia la posizione dell’utente, ma viene informata

automaticamente ogni qualvolta questi cambia ubicazione.

Fig. 5.1- esempio di disposizione delle soglie di localizzazione

ingresso

stanza1

stanza 2

stanza 3stanza 4

stanza 5 sogliasoglia

soglia

soglia

soglia

soglia

5-Soluzioni tecniche adottate 45

La figura 5.1 fornisce un esempio di planimetria di un ipotetico sito turistico ed evidenzia

alcuni dei punti in cui posizionare le soglie. Maggiore sarà il numero di soglie, maggiore

sarà l’accuratezza nel calcolo della posizione e maggiore il tempo perso per reperire tali

informazioni. Occorre quindi cercare il compromesso migliore tra precisione nella

localizzazione e velocità nella raccolta delle informazioni e quindi velocità di

rigenerazione della scena 3D (la scena 3D, infatti, non può essere aggiornata fino a quando

l’elaborazione dei messaggi relativi alle soglie non è terminata).

5.2 Controllo di collisione

Un altro problema che è legato al motore di rendering e navigazione e che nel caso

specifico non presenta soluzioni valide è la gestione delle collisioni. La gestione delle

collisioni è come illustrato nel paragrafo precedente strettamente legata alla soluzione del

problema relativo alla localizzazione dell’utente. Il controllo di collisione che offre il

motore di rendering e navigazione è piuttosto primitivo, non troppo accurato. Per

controllare se l’utente incontrerà sul suo cammino degli ostacoli, il motore 3d controlla la

distanza dagli elementi tridimensionali posti di fronte al visitatore. Se questa è più piccola

dello spazio che viene percorso con un passo, segnala la collisione.

Fig. 5.2 - Controllo di collisione Morfit

Osservando la figura 5.2 si può capire facilmente quanto tale sistema di controllo collisione

sia poco efficace. Nel caso l’utente si muova esattamente nella direzione indicata dalla

freccia la collisione viene rilevata correttamente e lo spostamento sarà impedito dal

controllo di movimento. Se però il visitatore si muoverà in diagonale il controllo di

collisione non rileverà alcuna collisione. Il movimento del visitatore non sarà impedito e

Utente

ostacolo

direzione percui viene effettuatoil controllo dicollisione


poiché il visitatore non è puntiforme attraverserà parte dell’ostacolo “come se fosse un

fantasma”.

Fig. 5.3 - Controllo di collisione errato

Questo non è accettabile dato che uno dei requisiti fondamentali di una visita turistica

virtuale è la verosimiglianza. Il controllo di collisione migliore da utilizzare sarebbe del

tipo “bounding sphere”, e funziona così: attorno al visitatore viene creata una sorta di sfera

trasparente, quando questa incontra uno degli elementi dell’ambiente tridimensionale si

verifica la collisione. Ciò impedirebbe il verificarsi di quanto visto prima.

E’ però difficile implementare un controllo di questo genere a partire da zero e utilizzarlo

in sostituzione di quello fornito con il motore di rendering.

Fig. 5.4 - Controllo bounding sphere

Una soluzione percorribile sarebbe quella di sfruttare il controllo di collisione del motore

3D e di ripetere lo stesso per diverse direzioni prima di abilitare il movimento. Se nel caso

illustrato prima si fosse effettuato il controllo di collisione anche a 45° a destra e a 45° a

Utente

ostacolo

direzione per cui viene effettuatoil controllo di collisione

Ostacolo

BoundingSphere


sinistra della direzione del visitatore si sarebbe rilevato correttamente l’ostacolo. In

sostanza si genera una discretizzazione molto grossolana del controllo bounding sphere

limitando la verifica di collisione alle otto direzioni fondamentali (Fig. 5.5).

Fig. 5.5 - Discretizzazione controllo bounding sphere

Così facendo si possono rilevare correttamente le collisioni, e si ha una complessità ridotta

a livello di programmazione. Purtroppo però la funzione di controllo di collisione del

motore di rendering è piuttosto lenta e il suo utilizzo ripetuto provoca il mancato

riconoscimento della ripetizione dei tasti premuti. In pratica per avanzare nell’ambiente

tridimensionale non è più sufficiente tenere premuto il pulsante di avanzamento ma è

necessario premerlo e rilasciarlo per avere l’avanzamento di un passo. La cosa non è certo

comoda dal punto di vista di chi utilizza il sistema di visita per cui, a meno di utilizzare

sistemi con ripetizione automatica del comando di avanzamento (come ad esempio avviene

con alcuni joystick), è necessario rinunciare a questa tecnica di controllo e affidarsi alla

modalità più semplice offerta direttamente dal motore di rendering. Al fine di evitare i

problemi descritti o almeno di ridurli conviene aumentare di un certo fattore, da valutare in

modo sperimentale, la distanza a cui viene riconosciuta la collisione.

Ostacolo

Direzioniper ilcontrollodi collisione


5.3 Creazione di ambienti fotorealistici

La caratteristica di avere una qualità di riproduzione degli ambienti fotografica è come

convenuto limitata alle zone di particolare interesse. Qui è necessario rivestire interamente

l’elemento tridimensionale con una vera e propria fotografia. La cosa non è proprio di

immediata soluzione, infatti il modo tipico di lavorare di un motore 3D è l’utilizzo di

piccole tessere colorate (texture) che ripetute su tutta la superficie dell’elemento

tridimensionale ne definiscono l’aspetto. Morfit mette a disposizione una funzione che

dovrebbe ricoprire tutta la superficie di un singolo elemento 3D con una immagine, l’unico

neo è che questa funzione lavora bene solo su superfici piane. Poiché si è deciso di

rappresentare i luoghi di interesse con ambienti emisferici o quasi, diventa difficile

utilizzare tale funzione. Fortunatamente il motore 3D ci permette di risolvere

elegantemente il problema, infatti ad ogni poligono che compone l’elemento

tridimensionale in oggetto vengono associate delle coordinate relative che individuano

l’orientamento dell’immagine da utilizzare per rivestirlo.

Fig. 5.6 - Effetto delle coordinate di bitmap

All’angolo in alto a sinistra dell’immagine corrispondono le coordinate 0,0 e a quello in

basso a destra le coordinate 1,1, gli altri due angoli avranno coordinate 0,1 e 1,0. Se ad

ogni poligono si assegnano delle coordinate di “bitmap” calcolate ad “hoc” è possibile

ricoprire un intero elemento tridimensionale con una sola immagine. Ad esempio se un

corridoio ha le pareti formate da tanti rettangoli e si vuole utilizzare una sola immagine per

parete, il procedimento per calcolare le corrette coordinate è il seguente.

Immagine

0,0 0,1

1,0 1,1

0,0 0,1

1,0 1,1

0,0 0,5

1,0 1,1

Immagine Imm


Fig. 5.7 - Colorazione delle pareti di un corridoio

Detta L la lunghezza del corridoio e l quella dei singoli rettangoli (supponendo che siano

tutti uguali) l’incremento delle coordinate y di bitmap per ciascuno di essi al fine di

ricoprire tutta la parete con una sola immagine è:

�l = lL �n_ripet_immagine

Dove n_ripet_immagine sarà pari a uno (e maggiore di uno se si vuole ripetere l’immagine

più di una volta). Questa tecnica applicata all’intero insieme dei poligoni del luogo di

interesse permette la ricostruzione in qualità fotografica.

5.4 Visita Automatica

Nella visita manuale il controllo di movimento è molto semplice, l’applicazione deve

limitarsi a verificare eventuali collisioni e a localizzare il visitatore, il modo in cui questi si

muove è lasciato al suo piacere. Nella visita automatica è l’applicazione di visita, o meglio

la vista 3d che deve curare il movimento dell’utente in ogni dettaglio, dovrà quindi essere

nota la traiettoria da far seguire ai visitatori. Il primo problema è che la visita manuale non

richiede la conoscenza della traiettoria del visitatore per cui non esiste nessun elemento che

ne tenga conto. La soluzione è memorizzare in una struttura dati apposita (ad esempio un

vettore dinamico) una serie di punti chiave attraverso cui il visitatore dovrà

obbligatoriamente passare e forzare il movimento dello stesso da un punto all’altro

secondo un ordine prestabilito (corrispondente all’itinerario della visita automatica).

Naturalmente non è possibile limitarsi a spostare la telecamera utente da un punto all’altro

perché si perderebbe la fluidità dei movimenti: tra un punto e l’altro la telecamera verrà

mossa costantemente a una velocità pari a quella di un visitatore che cammina. La

traiettoria seguita sarà la retta che unisce i punti entro cui la telecamera è compresa e per

far sì che la cosa avvenga, ad ogni passo in avanti si orienta la telecamera verso il prossimo

L=lunghezza corridoio

l=lunghezza rettangolox1,y1 x1,y2


punto in ordine di percorrenza. L’entità del singolo spostamento viene calcolata in base

alla velocità della camminata e alla velocità della macchina su cui viene eseguita

l’applicazione in modo da essere pressoché costante e pari a quella della visita manuale.

Nella visita automatica è anche prevista la possibilità di definire punti dell’itinerario di

visita in cui l’avanzamento dell’utente viene interrotto per permettere la presentazione di

particolari informazioni. Si può sfruttare la parte di codice che si occupa di rilevare il

passaggio su un punto chiave della visita per individuare i punti di sosta a patto che gli

stessi facciano parte dell’elenco dei punti chiave.

Con questa ipotesi, quando un punto chiave viene identificato come punto di sosta si

interrompe il timer di avanzamento automatico, se necessario si generano dei movimenti

della telecamera utente ed eventualmente si può provocare la visualizzazione di un filmato

nella zona di schermo destinata alle informazioni ipertestuali. Essendo nota la durata del

movimento e la durata del filmato, è possibile riattivare il timer di avanzamento automatico

in corrispondenza della fine del filmato stesso. Se per la visita automatica è prevista una

colonna sonora la riproduzione della stessa può essere interrotta oppure il volume di

riproduzione può essere abbassato a un livello tale da consentire l’ascolto di eventuali

contenuti audio del filmato.

5.5 Visita assistita

La visita assistita richiede un livello di complessità ancora superiore rispetto alla visita

automatica, bisogna infatti impedire che il visitatore si allontani dal centro dell’ambiente

visitato ma al contempo permettere all’utente di ruotare su sé stesso, di guardare in alto e

in basso a piacere e di scegliere la direzione ove possibile. Non è possibile riutilizzare i

punti chiave definiti per la visita automatica perché essi sono ordinati secondo il percorso

stabilito e perché non è possibile capire dove si possono prendere direzioni diverse

basandosi solo sui punti memorizzati. La soluzione migliore non è definire una traiettoria

fissa ma una traiettoria consigliata a cui deve tendere il movimento del visitatore

nell’ambiente. Sostanzialmente si procede in questo modo, prima di tutto si disabilitano i

comandi per la traslazione laterale che in questo tipo di visita non è richiesta, poi si fa in

modo che la pressione del pulsante di avanzamento provochi il riallineamento dell’utente

con la traiettoria consigliata, qualunque sia il movimento precedentemente effettuato. In

pratica qualunque sia l’azione effettuata dall’utente prima dell’avanzamento (escluso il

caso in cui sia un avanzamento) viene annullata per riprendere la traiettoria corretta.


Appare allora chiaro che si dovrà fornire una serie di controlli aggiuntivi che permettano la

scelta della direzione, qualunque rotazione prima dell’avanzamento verrà infatti annullata.

Questi controlli dovranno permettere la svolta a destra, a sinistra, la prosecuzione in linea

retta e l’inversione di marcia. Una volta selezionato uno dei controlli sarà l’applicazione a

gestire il cambio di traiettoria e all’utente spetterà la sola pressione del tasto di

avanzamento. Il primo passo per far tendere il movimento ad una traiettoria ideale è

l’annullamento di tutti i movimenti che la possano perturbare, il secondo è la definizione

della stessa. Per definire la traiettoria cui tendere si sfrutta la presenza delle soglie di

localizzazione all’interno di ogni spazio dell’ambiente ricostruito. Queste soglie sono

elementi tridimensionali particolari che oltre ad essere completamente trasparenti, sono

direttamente accessibili da parte dell’applicazione. In sostanza, il programma di visita può

reperire ogni informazione necessaria su di esse a partire dal loro nome, nome che è

studiato in modo da poter essere generato a partire dal nome dell’elemento del mondo a cui

appartengono. Una volta noto il nome della soglia l’applicazione potrà utilizzarlo per

risalire all’elemento stesso e a tutte le sue caratteristiche.

Poiché è possibile conoscere tutte le caratteristiche delle soglie è anche possibile conoscere

la posizione del loro punto centrale (rispetto al volume che occupano), tale posizione viene

utilizzata per orientare il movimento dell’utente. Quando il visitatore attraversa la soglia di

ingresso di un dato elemento, la telecamera utente viene orientata verso il punto centrale

della soglia di uscita. Se l’elemento è una curva viene calcolato l’angolo di rotazione che

dovrà avere la telecamera ad ogni passo per poter uscire dall’elemento tridimensionale in

corrispondenza o nelle vicinanze, del centro della soglia di uscita. Per rendere ancora più

precisa la traiettoria, ogni volta che si incontra la soglia di ingresso di un elemento, la

telecamera viene riposizionata al centro della soglia, prima di essere orientata verso la

successiva.

Rimane da fugare il seguente dubbio: come è possibile definire una soglia di ingresso e una

di uscita dato che in generale gli elementi possono essere percorsi in più direzioni?

Semplicemente, la prima soglia che si incontra in un elemento diventa la soglia di ingresso

e l’altra la soglia di uscita. Nel caso di particolari elementi come i bivi in cui a un ingresso

corrispondono due uscite l’applicazione sceglierà sempre una delle due (ad esempio quella

a destra) contando sul fatto che sarà l’utente a specificare la direzione voluta.

Potrebbe ancora esserci una perplessità: come deve essere gestito il movimento nelle zone

comprese tra una soglia di uscita e una di ingresso? Conviene evitare di complicare

ulteriormente le cose e memorizzare semplicemente la direzione della telecamera in


corrispondenza della soglia di uscita in modo da essere in grado di conservarla, annullando

eventuali rotazioni, fino al raggiungimento di un’altra soglia di ingresso.

53

6 Caso di studio:

Miniere di Traversella

La descrizione fatta sinora di un sistema per la visita virtuale di località turistiche si è

limitata ad aspetti generali che interessano qualunque località, e che sono necessari per

avere uno strumento flessibile ed applicabile a diverse situazioni. É però importante sapere

che ciascuna singola applicazione avrà caratteristiche peculiari che verranno trattate in

modo specifico e probabilmente gli accorgimenti utilizzati non saranno applicabili altrove.

Risulta utile avere un obiettivo reale di applicazione in modo da venire per la prima volta a

contatto con una situazione reale e con le esigenze di chi visita e di chi offre la visita. Nel

far questo è necessario trovare qualche ente turistico che abbia la pazienza e la voglia di

seguire nuovi progetti la cui applicazione può non essere immediata.

Qui si inserisce la figura del comune di Traversella con il Sindaco e il dott. Stefano Roletti

che con disponibilità hanno dato fiducia a questo progetto, offerto numerosi suggerimenti e

il materiale su cui sviluppare una visita virtuale.

54 6- Caso di studio: Miniere di Traversella

É pertanto doveroso porre loro i ringraziamenti del caso e trattare in modo dettagliato il

sito turistico delle Miniere di Traversella.

6.1 Traversella

Posto all’estremità occidentale dell’Alta Valchiusella, il territorio di Traversella (TO) è

decisamente montuoso: oscilla tra i 700 m dei bassi piani alluvionali, ai confini con la zona

di Vico, ed i 2820 m del Monfandì. L’abitato si estende, in bella posizione soleggiata, sulla

dorsale tra il valloncello del Bersella, un tempo zona estrattiva piuttosto nota, ed il torrente

Chiusella. Le vecchie case sono in gran parte allineate ai lati della strada principale che

porta al fondovalle, ma salgono anche a monte di questa, dove si trovano alcune nuove

costruzioni. Non distante dal ponte sul Bersella si trovano ancora tre vecchi mulini, ora

smantellati, molto attivi nei secoli scorsi, che utilizzavano le acque del torrente.

Nel paese oltre alle case dai tetti a “lose” con archi e “lobbie”, alle scolorite meridiane,

notevoli sono le chiese: l’attuale parrocchiale dedicata a S. Croce dall’imponente facciata

neoclassica che domina la piazzetta del paese, l’antica chiesa di S. Croce con accanto

l’elegante campanile in pietra della seconda metà del 700; la Cappella di Cali, all’imbocco

del paese. La località era nota già ai tempi dei Romani per la presenza di miniere di ferro, il

luogo sembra tragga il nome dall’aggettivo “traverso”, nel senso di “obliquo rispetto al

sole” o di “attraversamento”.

Fig. 6.1 – Traversella

6- Caso di studio: Miniere di Traversella 55

6.2 Miniere

Le miniere di Traversella sono antiche quanto quelle di Brosso (altro comune della

Valchiusella), il giacimento di minerali veniva già sfruttato nel tempo feudale quando ogni

famiglia aveva il suo “croso” (buco dal quale estraevano il minerale). A trasportare il

minerale erano solitamente le donne e i ragazzi, che con enorme fatica lo portavano fuori

dalla zona di estrazione per ammucchiarlo nel piazzale antistante.

L’escavazione divenne con il tempo indiscriminata e vi furono parecchi crolli che

causarono la perdita di numerose vite umane. Con l’andar del tempo le piccole imprese

legate all’attività mineraria scomparvero, anche perché il minerale in media profondità era

divenuto scarso e non riusciva più a soddisfare le esigenze della popolazione.

La miniera di Traversella tornò alla ribalta con la gestione FIAT, durante l’ultima guerra.

Fig 6.2 – Minere di Traversella: complesso di lavorazione del minerale

Si scavarono nuovi livelli e si ampliò il tunnel del Livello 779 Anglosarda dove esistevano

alcune zone estrattive (coltivazioni Bertolino), si costruì il grande ascensore alto circa

cento metri che portava il minerale fino al livello 890 sul piazzale Bracco Giorgio, da dove

veniva inviato al frantoio e alle separatrici magnetiche. Durante questo periodo vennero

ampliati tutti i livelli (cinque) più un livello superiore a quota 913 che non era servito

dall’ascensore. La chiusura delle miniere determinò un impoverimento storico della zona e

la scomparsa della figura del minatore nel Canavese, rimane ancora, nella gente di queste

valli, un profondo rispetto per quel periodo che diede inizio alla grande industrializzazione.


6.3 Itinerario di visita

Il sito minerario di Traversella ha una notevole estensione sia in lunghezza che in

profondità, si articola su almeno cinque livelli di gallerie identificate tipicamente da un

nome e dall’altezza a cui sono posizionate rispetto al livello del mare. Per la

sperimentazione di un percorso di visita virtuale non ha senso coprire l’intera estensione

delle miniere ma è sufficiente individuare un itinerario di visita significativo, di

ragionevole estensione, di cui si abbia una buona documentazione, in parte fotografica, in

parte cartografica. È inoltre utile disporre di informazioni relative alle zone di particolare

interesse turistico del percorso in modo da offrire una presentazione organica delle stesse

in accordo con la ricostruzione tridimensionale. A tal scopo è stato individuato un percorso

di visita che presenta diverse caratteristiche peculiari che ne rendono interessante la

ricostruzione. Di seguito è riportata una planimetria che indica la disposizione di una parte

delle gallerie che compongono la miniera, le zone evidenziate indicano l’itinerario

prescelto.

Fig. 6.3 – Miniere di Traversella: galleria.


Fig 6.4 – Miniere di Traversella: planimetria e itinerario di visita


Il percorso di visita comprende la galleria Bertolino 890 che si posiziona a 890 metri sul

livello del mare, una discenderia che porta al livello 860, la galleria Bertolino 860 che

termina in un pozzo di estrazione alto circa 100 m.

Fig. 6.5 – Miniere di Traversella: sezione longitudinale

Di qui, percorrendo alcune rampe di scale oppure utilizzando uno dei due ascensori per il

trasporto dei minerali, si raggiunge la galleria Bracco Giorgio a 890 m s.l.m.

La galleria Bertolino 890 presenta una zona di particolare interesse, una vasta caverna con

dimensioni quasi da cattedrale che deriva dall’unione di diverse gallerie di estrazione, la

zona nota come massa Bertolino offre un colpo d’occhio fantastico e dovrebbe essere

ricostruita in qualità fotografica. Purtroppo non esiste una documentazione fotografica

della stessa perciò non comparirà nel percorso di visita dimostrativo. Altre zone

interessanti del percorso sono la discenderia al livello 860 (parzialmente allagato) e il

pozzo di estrazione. Quest’ultimo offre uno spunto particolare per la ricostruzione 3d

perché al suo interno sono localizzati diversi elementi particolari come gli ascensori, che

devono comportarsi esattamente come nella realtà (nella fattispecie salire e/o scendere da

un livello all’altro).

Lungo tutto l’itinerario prescelto si incontrano moltissime mineralizzazioni con

caratteristiche che verranno illustrate durante la visita, sono anche presenti notevoli

variazioni della tonalità del colore delle rocce che dovranno essere riprodotte più o meno

fedelmente nella ricostruzione virtuale. Le gallerie della miniera sono scavate nella roccia

e presentano in corrispondenza delle zone più friabili, sostegni lignei per la volta noti come

imboscamenti (o centinatura). Una galleria con centinatura ha sostanzialmente la struttura

indicata nella figura 6.6. I sostegni verticali sono realizzati con pali di legno disposti come

in figura 6.6, sopra e di fianco a tali sostegni sono posizionati numerosi listelli di legno noti

come infilaggi. Quando si costruisce la centinatura di una galleria si riempie lo spazio tra la


roccia friabile e gli infilaggi con materiale sterile, cioè con gli scarti di estrazione del

minerale, il tutto crea un insieme stabile in grado di rendere sicuri questi tratti.

Fig. 6.7 – centinatura di una galleria

Percorrendo le gallerie si può notare che sul pavimento sono ancora presenti i binari che

permettevano il passaggio dei carrellini di metallo per il trasporto dei minerali verso la

superficie, ogni tanto si incontrano piccoli mucchi di pietre che intralciano il cammino e

testimoniano il perenne movimento della roccia soprastante e talvolta travi pronte per

essere utilizzate ove richiesto. Alcuni tratti di galleria sono allagati e sul pavimento scorre

un ruscello, saltuariamente si incontrano dei crolli più consistenti con mucchi di detriti di

medie dimensioni.

6.4 Integrazione delle modalità di visita

Avendo definito il percorso e illustrato le modalità di visita, confrontando i diversi punti di

vista di chi realizza la ricostruzione 3D e di chi gestisce l’accesso alla miniera si è giunti a

ritenere utile l’introduzione di una serie di punti di sosta all’interno di quella che è stata

definita come visita automatica. In corrispondenza di questi punti il sistema di visita dovrà

offrire la presentazione di contenuti particolari, ad esempio filmati, e/o offrire una

panoramica della zona.

61

7 Caso di studio: Soluzioni tecniche adottate

Nel capitolo 5 sono stati illustrati alcuni problemi che influenzano un’applicazione di visita

virtuale basata sul motore di rendering Morfit, la caratteristica comune a tutti è la

sostanziale indipendenza dal tipo di applicazione a cui ci si riferisce. In questo capitolo

verranno invece presentate alcune delle soluzioni adottate per la ricostruzione virtuale

dell’itinerario che si snoda all’interno delle Miniere di Traversella. Verrà posta particolare

attenzione alle tecniche di creazione dell’ambiente tridimensionale e alle politiche di

gestione della visualizzazione 3D.

Nel primo paragrafo si illustreranno le tecniche adottate per la definizione degli elementi

tridimensionali che compongono la ricostruzione. In particolare si focalizzerà l’attenzione

sulle modalità di costruzione dei singoli elementi, sui problemi che ne derivano e sulle

soluzioni adottate. Nel secondo paragrafo si studierà il posizionamento degli elementi 3D

62 7- Caso di studio: Soluzioni tecniche adottate

di base e quindi la tecnica che permette di ottenere l’itinerario di visita a partire dagli

elementi stessi.

In sostanza l’applicazione di visita è strutturata in modo da creare i singoli elementi

tridimensionali che compongono l’itinerario, in un punto dello spazio ben definito e

distante da dove viene ricostruito l’ambiente delle miniere. Questo tipo di comportamento

permette l’assunzione di notevoli semplificazioni nella creazione dei vari elementi, come si

vedrà nel caso della curva.

Una volta creato un elemento in ogni suo particolare, l’elemento stesso dovrà essere

posizionato in un punto ben definito del percorso di visita. A tal fine i singoli elementi 3D

sono costruiti come “mattoncini del Lego”: ogni elemento dispone di poligoni particolari,

uno per ciascuna “apertura” che permettono di ancorare l’elemento stesso ad un altro

elemento. Dopo aver costruito il primo elemento esattamente nel punto in cui deve essere

posizionato è sufficiente collegare gli altri “pezzi” fino a costruire completamente

l’itinerario di visita.

I paragrafi 3 e 4 tratteranno rispettivamente le tecniche di visualizzazione dell’ambiente

tridimensionale e l’inserimento di contenuti multimediali all’interno dell’applicazione di

visita. In particolare nel paragrafo 3 si studieranno i problemi relativi al rapporto tra qualità

dell’ambiente ricostruito e prestazioni in termini di fluidità del movimento, e i due

approcci generali alla soluzione degli stessi. Nel paragrafo 4 si illustrerà come è possibile

inserire contenuti multimediali nell’applicazione di visita e come possa essere stabilita una

connessione tra eventi nella ricostruzione 3D e presentazione dei suddetti contenuti.

7.1 Elementi Tridimensionali

La ricostruzione delle gallerie avviene a partire da un certo numero di oggetti base che

vengono di volta in volta “personalizzati” in modo da adattarsi alla realtà senza che la

struttura dell’applicazione perda di generalità. Tutti gli elementi di base avranno delle

caratteristiche comuni tipiche di un oggetto tridimensionale qualunque. Tali caratteristiche

devono essere memorizzate in modo tale da non dipendere dalla tipologia dell’elemento

allo scopo di evitare la duplicazione di informazioni. Esisterà una classe, ossia un insieme

di dati e funzioni, generale, comune, di cui tutti gli elementi di base condivideranno le

caratteristiche (discenderanno cioè da tale classe) che verrà denominata Element3D.

7- Caso di studio: Soluzioni tecniche adottate 63

#include "mrft_api.h"#define MORFIT#define AUTO 134#define MANUALE 135#ifndef AVANTI#define AVANTI 10000#endif#ifndef INDIETRO#define INDIETRO -10000#endifclass element3D{protected:

enum tipo_elemento{GALLERIA,INCROCIO,INTERESSE,CURVA,INGRESSO,BIVIO,DISCENDERIA,TINCROCIO,POZZO,FINEGALLERIA} tipo;DWORD handle;char posizione;DWORD ingresso;DWORD uscita;DWORD sound;DWORD sound_a;DWORD groups_to_render_avanti[10];DWORD groups_to_render_indietro[10];int n_groups_avanti;int n_groups_indietro;double larghezza_gallerie;double altezza_gallerie;CString url;

public:

//inserire qui le dichiarazioni delle funzioni membro della classe

DWORD get_handle(); // restituisce l’handle dell’elemento 3D

DWORD get_ingresso(); // restituisce l’handle del poligono di ingresso

DWORD get_uscita(); //restituisce l’handle del poligono di uscita

DWORD get_sound(int type=MANUALE); //restituisce l’handle del suono//associato all’elemento 3d per la//visita automatica o per la visita//manuale/assistita

DWORD get_group_to_render(int n_gruppo,int direzione=AVANTI); //restituisce//gli handle dei gruppi da visualizzare

void set_sound(char *nomesuono,DWORD gruppo=NULL,int type=MANUALE);// imposta il suono associato//all’elemento per la visita automatica//o manuale/assistita

void add_group_to_render(DWORD gruppo,int direzione=AVANTI);// aggiunge un elemento 3d alla lista//degli elementi da visualizzare

int get_n_groups_to_render(int direzione=AVANTI);// restituisce il numero di elementi 3d//da visualizzare


int get_tipo(); // restituisce il tipo di elemento 3D che discende da//questa classe

CString get_url(); //restituisce l’URL del documento HTML associato a//questo elemento 3d

void set_url(CString indirizzo); //imposta l’URL del documento HTML//associato a questo elemento

};

Fig. 7.1 – Codice di definizione della classe Element3D

Le variabili dichiarate come protected sono accessibili direttamente solo da parte dei

“discendenti” di questa classe generale e identificano le caratteristiche comuni di ogni

singolo elemento come la larghezza delle gallerie, l’altezza, il suono da riprodurre quando

si entra nei vari elementi (sound, sound_a) più un parametro per identificare il tipo di

elemento che “eredita” questi parametri. Alle variabili sono associati dei metodi, delle

funzioni che permettono l’accesso alle stesse da parti dell’applicazione non discendenti da

tale classe. Dalla classe generale derivano i vari componenti fondamentali dell’itinerario di

visita: galleria, curva, incrocio, incrocio a T, discenderia, pozzo, galleria interrotta. Tutti

questi elementi di base sono costruiti dal programma di visita secondo le modalità descritte

nei paragrafi seguenti.

7.1.1 GALLERIE Le gallerie della miniera vengono generate a partire da un elemento di base costituito da un

semicilindro appoggiato su due pareti rettangolari, la zona semicilindrica viene creata

unendo più rettangoli opportunamente inclinati (Fig. 7.2).

Fig. 7.2 – Costruzione di una galleria


Quanto più è alto il numero di rettangoli utilizzato per la creazione della volta, tanto

maggiore sarà l’accuratezza della stessa. L’estensione in lunghezza della galleria può

essere coperta dimensionando correttamente i due rettangoli che formano le pareti, oppure

si possono affiancare più sezioni di galleria di dimensioni fisse fino a raggiungere la

lunghezza desiderata. È possibile utilizzare un metodo di generazione basato sulla seconda

possibilità poiché la prima è un caso particolare della stessa, in tal caso si ha la possibilità

di scegliere due modalità di creazione con un unico metodo.

Per passare da una ricostruzione di tipo “wireframe” a una ricostruzione pseudorealistica

occorre “rivestire” le pareti della galleria con immagini adeguate per dare l’apparenza di

un tunnel scavato nella roccia. Si individua, pertanto, un’immagine adeguata e la si ripete

per tutta la superficie interna della galleria. Per evitare l’effetto mosaico si utilizzano in

realtà più immagini (due almeno) in modo da evitare il ripetersi della stessa “tessera” su

tutte le pareti. Così facendo si ottiene la ricostruzione di una galleria scavata nella roccia

(Fig. 7.3).

Fig. 7.3 - Galleria

Anche il pavimento viene realizzato come un singolo rettangolo rivestito con la ripetizione

di una o più immagini adeguate. Come si vede nella figura 7.3 all’elemento base verranno

poi associati degli elementi accessori che permetteranno di differenziare i vari tratti di

galleria che compongono l’itinerario di visita. Analizzando la morfologia delle gallerie


della miniera si può concludere che questi elementi devono sicuramente comprendere i

binari, le traversine che sostengono i binari, la centinatura, le pozzanghere e i mucchi di

detriti. La generazione dei binari è piuttosto semplice: è sufficiente posizionare due

parallelepipedi rettangoli sul pavimento della galleria, distanziati fra di loro e rivestirli con

una o più immagini che diano l’apparenza di un binario metallico arrugginito. Anche le

traversine sono molto semplici da ricostruire, non sono altro che parallelepipedi rettangoli

posizionati a intervalli regolari e colorati in modo da sembrare di legno. La costruzione dei

tratti centinati è lievemente più complessa, le travi di sostegno (pedritti e traverse) sono

parallelepipedi a base quadrata posizionati opportunamente e ripetuti a distanza prestabilita

per tutta la lunghezza della galleria, i listelli di legno che sostengono la volta (infilaggi)

sono invece costruiti come semplici rettangoli con il lato più lungo che si estende per tutta

la galleria. La lunghezza apparente degli infilaggi dipende dal numero di ripetizioni

dell’immagine utilizzata per rivestirli. Pozzanghere e mucchi di detriti sono elementi

particolari che richiedono maggiore attenzione nella definizione: le pozzanghere sono

ottenute come poligoni rettangoli rivestiti di un’immagine particolare a forma di

pozzanghera. La particolarità di questa immagine è che essa viene riprodotta dal motore di

rendering in modo che alle zone più scure corrisponda un alto livello di trasparenza mentre

ai toni chiari corrisponde maggiore opacità.

Fig. 7.3 – Pozzanghera

I mucchi di pietre sono creati supponendo che la loro formazione sia dovuta a piccolissimi

crolli della volta e delle pareti, pertanto essi saranno localizzati lungo le pareti stesse e


avranno forma di cono in modo da simulare per quanto possibile la reale disposizione degli

stessi. Anche qui occorre fare attenzione all’immagine utilizzata per rivestire il cono in

modo da ottenere un aspetto più realistico possibile.

7.1.2 CURVE

La tecnica di costruzione di una curva è per molti versi simile a quella illustrata

dettagliatamente per la galleria, anche qui i binari, le traversine e la centinatura sono

realizzati componendo opportunamente parallelepipedi rettangoli mentre cambia la

disposizione dei singoli elementi che deve seguire l’andamento della curva. Una curva è

formata da diverse sezioni trapezoidali di “galleria” che accostate formano la curva stessa,

maggiore sarà il numero di sezioni utilizzate a parità di angolo di curvatura, maggiore sarà

l’accuratezza della curva.

Fig. 7.4 – Creazione di una curva

Il numero di sezioni è legato all’angolo di curvatura da coprire e quindi a quella che

potremmo definire “risoluzione” della curva in gradi. In ogni caso tale numero deve essere


intero e sufficientemente alto da assicurare la non percettibilità della divisione in sezioni

della curva. Non è possibile determinare un valore minimo di sezioni (ovvero una minima

risoluzione) sufficiente a garantire un realismo adeguato perché la percezione degli spigoli

della curva è legata sia al raggio di curvatura che all’angolo di curvatura. Si è visto

sperimentalmente che una risoluzione della curva che si aggira intorno ai due gradi è tale

da garantire un realismo adeguato per tutte le curve dell’itinerario. È anche possibile

stimare la migliore risoluzione utilizzabile in ciascuna curva, separatamente, in modo da

ottenere un buon compromesso tra realismo e numero di poligoni necessari (fattore

pesantemente correlato alle prestazioni dell’applicazione di visita in termini di fluidità dei

movimenti).

La complessità insita nella costruzione della curva è la necessità di creare curve verso

destra e verso sinistra, e quindi con angoli di curvatura di segno opposto, a partire dallo

stesso metodo costruttivo. Per dare un’idea di come questo si traduca a livello di

programmazione viene riportato di seguito lo spezzone di pseudo-codice che si occupa di

questa operazione.

//Inizio creazione curvaper ciascuna sezione della curva{

// calcolo delle coordinate fondamentali per la costruzione dei// poligoni che formeranno la curva

il centro di rotazione della curva è il centro del poligono di ingressodella curva con z=0 e con il valore di y = y centro ingresso + raggio dicurvatura

x_0 = segno del raggio di curvatura * (x del centro dirotazione – raggio interno * sin (angolo iniziale dellasezione di curva).

x_1 = segno del raggio di curvatura * (x del centro dirotazione – raggio esterno * sin (angolo iniziale dellasezione di curva).

x_2 = segno del raggio di curvatura * (x del centro dirotazione – raggio esterno * sin (angolo finale dellasezione di curva).

x_3 = segno del raggio di curvatura * (x del centro dirotazione – raggio interno * sin (angolo finale dellasezione di curva).

// le coordinate x saranno le stesse sia che il raggio di// curvatura sia positivo (curva a dx) che il raggio di// curvatura sia negativo (curva a sx)per la presenza del segno// stesso che moltiplica la coordinata x del punto.


y_0 = y del centro di rotazione - raggio interno * cos(angoloiniziale della sezione di curva).

y_1 = y del centro di rotazione – raggio esterno * cos(angoloiniziale della sezione di curva).

y_2 = y del centro di rotazione – raggio esterno * cos(angolofinale della sezione di curva).

y_3 = y del centro di rotazione – raggio interno * cos(angolofinale della sezione di curva).

// le coordinate y avranno segno dipendente dal raggio di// curvatura, se questo è negativo tenderanno ad assumere// valori incrementali negativi: curva verso sx altrimenti// avranno valori che aumentano per ogni sezione di curva:// curva dx

//inizializzazione poligoni dei muriper z da 0 ad altezza dei muri verticali{

definisci punti poligoni dei muri con le coordinatecalcolate sopra

poligono interno:(x0,y0,zbasso|x3,y3,zbasso|x3,y3,zalto|x0,y0,zalto)

poligono esterno:(x1,y1,zbasso|x2,y2,zbasso|x2,y2,zalto|x1,y1,zalto)

registra i poligoni}//fine creazione muri

..continua con la creazione della volta, del pavimento, etc. ..

Fig. 7.5 – pseudo-codice per la creazione di una curva

I punti dei vari poligoni che compongono la curva sono posizionati sulla superficie

“ideale” della curva stessa (quella che si otterrebbe se le pareti e la volta non presentassero

spigoli) e vengono calcolati in modo da appartenere a tale superficie. Osservando lo

pseudo-codice si può notare che il problema del segno dell’angolo di curvatura viene

risolto cambiando di segno il valore delle coordinate x nel caso l’angolo sia negativo.

Questa soluzione è valida se e solo se la curva viene costruita assumendo che la rotazione

avvenga intorno ad un asse verticale e che l’ingresso della stessa sia posizionato su una

linea parallela all’asse y e appartenga al piano xy. L’ipotesi non è generale ma ogni curva

viene creata con questa configurazione. Dopo la creazione la curva dovrà essere

posizionata correttamente e per farlo si usa la tecnica illustrata nel paragrafo 7.2.


7.1.3 INCROCI

L’elemento incrocio viene utilizzato per rappresentare un quadrivio, ovvero l’intersezione

a 90° tra due gallerie, i punti che definiscono i poligoni dell’incrocio non sono calcolati

come punti di intersezione tra due gallerie per qualunque angolo di intersezione ma solo ed

esclusivamente per un angolo di intersezione di 90°. Così facendo si raggiunge un

compromesso tra perdita di generalità nella costruzione dell'elemento e minore complessità

della stessa. Nel caso delle miniere il compromesso è accettabile perché gli incroci a

quattro vie tra gallerie sono tutti più o meno riconducibili a un incrocio a 90°. La figura 7.4

illustra la tecnica di costruzione:

Fig. 7.6 – Costruzione di un incrocio a 90°

Quando un incrocio reale tra gallerie non è a 90° esso viene ricostruito collegando alle

uscite dell’incrocio a 90° dei piccoli spezzoni di curva. Se le aperture dell’incrocio sono

molto vicine al corpo dell’incrocio stesso la differenza tra incrocio reale e virtuale è

trascurabile, ammesso che l’angolo di intersezione tra le gallerie che formano l’incrocio

non sia troppo discosto da novanta gradi.

Fig. 7.7 – Incrocio non a 90° approssimato


Il tutto viene infine rivestito con immagini adeguate per ottenere un aspetto più o meno

realistico.

Fig. 7.8 – Incrocio a 90°

7.1.4 INCROCIO A T

Viene realizzato come un incrocio normale a cui manca una delle uscite:

Fig. 7.9 –Costruzione di un incrocio a T


Si ottiene il seguente risultato finale.

Fig. 7.10 – Incrocio a T

7.1.5 FINE GALLERIA

L’elemento fine galleria non è nient’altro che una galleria con una delle due estremità

sbarrata e chiusa da una parete rocciosa.

7.1.6 DISCENDERIA

Nella definizione degli elementi di base è stato scelto di denominare discenderia

l’elemento di collegamento tra un tratto di galleria orizzontale e un tratto di galleria

inclinato (a salire o a scendere). Una discenderia reale sarà allora formata da due elementi

discenderia e un elemento galleria. L’elemento discenderia condivide la stessa tecnica

costruttiva della curva ma la rotazione avviene intorno al pavimento o meglio intorno ad un

asse trasversale rispetto all’elemento.

Fig. 7.11 – composizione di una discenderia reale

discenderia

discenderia


Anche per la discenderia il metodo di creazione deve essere indipendente dal segno

dell’angolo di inclinazione rispetto all’orizzontale.

Fig. 7.12 –Costruzione di una discenderia-

7.1.7 POZZO DI ESTRAZIONE

Il pozzo di estrazione serviva per portare in superficie i minerali estratti nella miniera,

proprio per questo sono numerose le gallerie che si affacciano sullo stesso.

All’interno del pozzo di estrazione sono presenti rampe di scale che portano ai vari livelli

di gallerie e due ascensori. Nella ricostruzione uno solo dei due ascensori viene riprodotto,

come una grossa piattaforma con ringhiere di legno, in grado di muoversi verticalmente da

un livello all’altro. Le rampe di scale vengono costruite utilizzando due parallelepipedi

rettangoli che fanno da sostegno per gli scalini ottenuti come rettangoli a due facce. Le

rampe di scale sono elementi che presentano sempre le stesse caratteristiche per tutta

l’estensione del pozzo e che quindi si prestano bene ad essere costruite richiamando

ciclicamente lo stesso spezzone di codice.

Finchè il numero di rampe non è zero{

crea i montanti del primo tratto di scala (in avanti)

per i da 0 a numero di scalini per rampa{

crea uno scalino}

crea primo pianerottolo

decrementa di uno numero rampe

se numero rampe non è zero


{

crea i montanti del secondo tratto di scala

(all’indietro)

per i da 0 a numero di scalini per rampa{

crea uno scalino}

crea secondo pianerottolo

decrementa di uno numero rampe

}

}

Lo pseudo-codice riportato evidenzia come sia possibile ottenere elementi grafici

complessi a partire da un insieme di funzioni molto semplici che vengono ripetute un

numero adeguato di volte. Non vale la pena perdersi in dettagli inutili così come non è

utile approfondire di più la creazione del pozzo a livello di codice. Il risultato finale è il

seguente.

Fig. 7.13 – Pozzo di estrazione


7.2 Posizionamento degli elementi 3D di base

Come accennato nell’introduzione di questo capitolo i singoli elementi tridimensionali

vengono creati in una zona specifica dello spazio tridimensionale e successivamente

vengono posizionati correttamente. L’obiettivo del posizionamento è prendere un elemento

nuovo e spostarlo in modo da portare a coincidere una delle aperture dello stesso con

un’apertura di un elemento già in posizione. La precisione nell’accostamento deve essere

tale da rendere impossibile l’identificazione del punto di connessione.

Fig. 7.14 – Posizionamento degli elementi 3D di base

Il posizionamento sarà corretto se e solo se le due aperture combaceranno perfettamente,

ovvero se i due poligoni che definiscono le aperture sono sovrapposti, paralleli e se non vi

è alcuna rotazione dell’elemento da posizionare rispetto all’elemento già in posizione.

La tecnica di posizionamento è concettualmente molto semplice: una volta noto il poligono

di “ancoraggio” dell’elemento da posizionare (A), si sposta l’elemento stesso fino a far

coincidere il centro di tale poligono con il centro del poligono di ancoraggio dell’elemento

già in posizione (B) a cui l’elemento attuale deve essere connesso (Fig. 7.15).

Quindi, si ruota l’elemento attorno ad un asse passante per il punto di ancoraggio in modo

da portare a coincidere le facce dei poligoni A e B. In generale la direzione dell’asse di

rotazione che permette di portare a coincidere le due facce dei poligoni non è nota, perciò,

in pratica, non si fa altro che portare a coincidere le direzioni calcolate facendo uscire dal

centro di ciascun poligono un vettore perpendicolare al piano in cui il poligono è

Itinerario

Elemento in posizione

Elemento da posizionare


posizionato (il verso del vettore dipende dall’ordine di generazione dei punti che

compongono il poligono) (Fig.7.16).

Fig. 7.15 – Posizionamento: si portano a coincidere i punti di ancoraggio-

Fig. 7.16 - Posizionamento: rotazione per far coincidere i due poligoni di ancoraggio

Rimane però un grado di libertà nel movimento: è possibile che i due punti di ancoraggio

coincidano, la direzione perpendicolare ai poligoni sia la stessa e che l’elemento non sia

posizionato correttamente. Infatti nelle condizioni specificate è possibile continuare a

soddisfare i requisiti indicati (ancoraggio e direzione dei poligoni) per qualunque rotazione

dell’elemento da posizionare attorno ad un’asse perpendicolare al poligono di ancoraggio,

passante per il centro dello stesso (Fig. 7.17).

Fig. 7.17 – risultato di un posizionamento senza vincoli sulla direzione delle pareti

Elemento da posizionare

Elemento già in posizione

Poligono A

Poligono B


Occorre imporre ancora un vincolo: la direzione delle perpendicolari alle pareti degli

elementi 3D deve essere la stessa nelle vicinanze del punto di congiunzione. Ecco la

traduzione in pseudo-codice di quanto detto finora.

//Posiziona: serve per posizionare correttamente , secondo quanto indicato//dai parametri passati la galleria costruita dichiarando un elemento//galleria

funzione di posizionamento per una galleria (poligono_di_ancoraggio,posizione del centro del poligono di ancoraggio, poligonoanteriore/posteriore){

//per posizionare la galleria si utilizza la stessa tecnica che//permette di posizionare uno qualunque dei discendenti di element3D

//fase1

//si sposta la galleria fino a far coincidere il centro del poligono//di ancoraggio del nuovo elemento con il centro del poligono di//ancoraggio dell’elemento già in posizione

richiedi al motore 3d la posizione del centro del nuovo elemento.

Se devono coincidere i poligoni anteriore del nuovo elemento e ilpoligono di ancoraggio dell’elemento già in posizione.{

Posiziona il centro del nuovo elemento in modo tale che il centrodel poligono anteriore corrisponda con il centro del poligono diancoraggio.

}

Altrimenti{

Posiziona il centro del nuovo elemento in modo tale che il centrodel poligono posteriore corrisponda con il centro del poligono diancoraggio.

}

//fase2

//si imposta come asse di rotazione il punto in cui i due elementi da//allineare si toccano

Imposta come punto di riferimento per la rotazione il punto diancoraggio dell’elemento già in posizione.

//fase3

//si ruota la galleria fino a far coincidere il poligono di ingresso//della stessa con il poligono di uscita dell'elemento cui deve//essere connessa

indica al motore 3d di ruotare la galleria da posizionare in modo dafar combaciare le direzioni dei poligoni di ancoraggio.

// controllo di rotazione, se la galleria non è posizionata//correttamente recupera la rotazione rispetto all’asse passante per


//il centro del poligono di ancoraggio

////////////////// ripristino assetto orizzontale///////////////

calcola l’angolo di rotazione da recuperare rispetto alla posizionecorretta.

indica al motore 3d di ruotare la galleria di un angolo pariall’angolo di rotazione calcolato, intorno all’asse passante per ilcentro del poligono di ancoraggio e per il centro del poligono opposto(l’uscita).

///////////////// fine ripristino assetto orizzontale/////////////

richiedi al motore 3d la posizione del centro del poligono diancoraggio della galleria utilizzato per la connessione con l’elementogià in posizione.

Se non coincide con la posizione del centro del poligono di ancoraggiodell’elemento già in posizione

indica al motore 3d di spostare la galleria fino a farlicoincidere.

//fine posizionamento

}

Fig. 7.18 – pseudo-codice per il posizionamento di un elemento galleria

La funzione di posizionamento è sostanzialmente analoga per i vari elementi

tridimensionali, cambiano ovviamente i poligoni di ancoraggio a cui fa riferimento (sia

come nome che come numero).

7.3 Tecniche di rendering

La velocità di esecuzione, la fluidità dei movimenti e il realismo dell’ambiente ricostruito

dipendono strettamente dalle tecniche di rendering utilizzate. Come indicato nel paragrafo

4.4 si è scelto di generare autonomamente, all’interno dell’applicazione di visita i modelli

tridimensionali, ciò comporta l’utilizzo di Morfit 3D Engine nella modalità EDITOR, più

lenta. Il massimo frame rate ottenibile sarà più basso di quanto si raggiungerebbe

lavorando in modalità VIEWER, è quindi importante fare attenzione alle modalità di

rendering utilizzate per evitare di raggiungere velocità troppo basse e conseguentemente

bassa fluidità dei movimenti e poco realismo.


Il valore di frame rate da raggiungere per ottenere una fluidità di movimento accettabile si

aggira intorno ai 12-15 f.p.s..

Per raggiungere tale valore si possono adottare due diverse tecniche tra loro

complementari. La prima prevede il controllo e la corretta regolazione della

visualizzazione 3D generata dal motore di rendering mentre la seconda interviene sulle

modalità di costruzione e gestione dei modelli tridimensionali.

Nel primo caso si indicano al motore di rendering le caratteristiche dei vari elementi

tridimensionali agendo in particolar modo sulle proprietà di assorbimento della luce degli

stessi, sulla visione prospettica dell’ambiente e sul processo di identificazione delle

superfici visibili. Si ottiene una buona variazione della qualità della scena 3D riprodotta ma

un ridotto cambiamento delle prestazioni. Riferendosi ad un esempio concreto,

nell’applicazione di visita con questo approccio, a parità di altri fattori, il passaggio da

massima qualità a massime prestazioni si traduce nel passaggio da un frame rate di 6-7

f.p.s a un frame rate di 8-9 f.p.s..

Chiaramente il miglioramento di prestazioni che si può ottenere non è particolarmente alto

e non è sufficiente a garantire i requisiti di fluidità indicati.

La velocità del processo di rendering è strettamente legata al numero di poligoni da

visualizzare perché il motore di rendering deve calcolare la posizione e la visibilità di

ciascuno in modo da generare una rappresentazione corretta.

Il secondo approccio prevede l’intervento sul numero di poligoni che compongono la scena

tridimensionale, si sviluppa secondo due strategie e permette di ottenere un notevole

incremento di prestazioni a parità, o quasi, di qualità dell’ambiente ricostruito. Ritornando

allo stesso esempio di prima, l’applicazione di questa tecnica offre a parità di altri fattori il

passaggio da un frame rate di 8-9 f.p.s. a un frame rate di 18-20 f.p.s..

I parametri che vengono controllati e regolati con la prima tecnica sono noti, in gergo

tecnico come: atmosferic effect o fog, culling depth, far object color accuracy e zoom

angle.

L’effetto atmosferico (fog) permette di definire quanto rapidamente, i singoli elementi

tridimensionali assumono il colore dello sfondo, all’aumentare della distanza

dall’obbiettivo della “telecamera” che permette la visualizzazione della scena 3D. La

velocità di generazione della scena tridimensionale dipende strettamente dal numero di

poligoni da visualizzare, per ciascuno, infatti, il motore di rendering deve calcolare la

posizione e la visibilità per decidere come rappresentarlo. Impostando un valore alto di

atmosferic effect si fa in modo che gli oggetti 3D diventino indistinti a breve distanza dalla


telecamera, così si ottiene una riduzione del tempo di rigenerazione della scena perché

molti poligoni coinvolti non dovranno essere presi in considerazione nei calcoli di

posizione: essi assumeranno comunque il colore dello sfondo. L’effetto visivo è simile alla

nebbia, pertanto è necessario trovare un buon compromesso tra effetti benefici in termini

prestazionali e realismo dell’ambiente ricostruito.

Il parametro culling depth serve per indicare al motore 3D qual è la distanza dalla

telecamera oltre la quale gli elementi tridimensionali possono non essere disegnati.

Riducendo il numero di elementi da disegnare aumentano le prestazioni in termini di

fluidità e velocità di riproduzione della scena. Questo parametro permette, utilizzato

insieme al fog, di ottenere un incremento delle prestazioni senza perdite apprezzabili nella

qualità dell’ambiente ricostruito. Chiaramente non si può eccedere altrimenti si rischia di

vedere gli oggetti che compongono l’ambiente, apparire improvvisamente dal nulla e la

cosa non è per niente realistica.

Altro parametro che va abbinato a quelli visti sinora per ottenere un aumento delle

prestazioni senza perdite apprezzabili di qualità, è l’accuratezza con cui vengono riprodotti

i colori degli oggetti distanti dalla telecamera (far object color accuracy) . Gli oggetti

ancora visibili ma abbastanza distanti dall’obbiettivo della telecamera possono essere

colorati con colori uniformi invece che con le immagini utilizzate per definirne l’aspetto

ottenendo un ulteriore incremento delle prestazioni. Se il valore di distanza oltre cui si

passa da immagine a colore pieno è sufficientemente alto non si nota alcun peggioramento

della scena 3D. Basti pensare che anche nella realtà all’aumentare della distanza gli oggetti

visibili diventano sempre più indistinti. Anche in questo caso è comunque necessario

cercare il miglior compromesso tra velocità e qualità delle scene tridimensionali.

Ultimo parametro da regolare per variare le prestazioni della ricostruzione tridimensionale

è l’angolo di apertura dell’obbiettivo della telecamera (zoom angle). Aumentando questo

valore aumenta la visione periferica della scena 3D e conseguentemente aumenta il numero

di oggetti che appaiono distanti e che possono quindi rientrare nella zona di effetto del fog

e poi del culling depth (aumento di prestazioni). Contemporaneamente cambia la visione

prospettica dell’ambiente ricostruito che tende a “schiacciarsi” all’aumentare dell’angolo

di apertura (minore qualità di ricostruzione). Occorre pertanto trovare, come al solito, il

giusto compromesso.

L’intervento sul numero di poligoni previsto dalla seconda tecnica si articola, come già

evidenziato, su due azioni complementari: ridurre i poligoni che compongono i singoli

elementi 3D e ridurre i poligoni che devono essere visualizzati. La riduzione dei poligoni


che compongono i vari oggetti 3D deve essere calcolata in modo da ottenere il massimo

realismo possibile con il minor numero di poligoni possibili. Ad esempio nella galleria le

pareti sono realizzate come un poligono unico, rettangolare lungo come la galleria stessa,

la volta come l’insieme di soli 4 rettangoli anch’essi lunghi come la galleria. Considerando

che per il pavimento occorre ancora un poligono si vede che è possibile ottenere una

galleria di base utilizzando solo 4+2+1=7 poligoni. La bassa accuratezza con cui viene

costruita la volta circolare non è evidente nella rappresentazione dell’ambiente 3D grazie

ad una tecnica opportuna di colorazione (texturing). Così facendo si ottiene un buon

incremento delle prestazioni che nel solito esempio sopra raggiungono i 13,00 f.p.s. . È

però chiaro che questa tecnica da sola non può bastare, avere il più basso numero di

poligoni possibile, equivale ad avere il minor numero di elementi tridimensionali possibili

e quindi minor realismo. Non solo, nel caso di ambienti ricostruiti di grandi dimensioni (è

il caso della visita virtuale) il vantaggio così ottenuto è destinato ad avere comunque un

basso impatto sulle prestazioni a causa dell’elevato numero di elementi tridimensionali che

compongono la ricostruzione. Si vorrebbe invece un incremento stabile delle prestazioni,

indipendente dall’estensione delle zone da ricostruire e tale da permettere l’inserimento di

alcuni elementi accessori all’interno degli elementi tridimensionali di base, in modo da

ottenere un buon realismo della scena 3D definitiva. La tecnica utilizzata si abbina

perfettamente a quella appena illustrata: l’unico modo per aumentare notevolmente la

velocità di rigenerazione della scena tridimensionale è ridurre il numero di poligoni che

partecipano alla sua creazione, è sufficiente allora limitare il numero di poligoni da

prendere in considerazione in ciascuna rigenerazione, non eliminandoli ma indicando al

motore di rendering che non devono essere presi in considerazione. Sostanzialmente ad

ogni oggetto tridimensionale di base viene associata una struttura dati (vettore di puntatori)

in cui memorizzare gli elementi adiacenti che partecipano alla generazione dell’immagine

dell’ambiente ricostruito. Così facendo partecipano ai calcoli di rendering solo quelle entità

tridimensionali che sono in prossimità dell’utente indipendentemente dall’intera estensione

dell’ambiente da ricostruire. L’incremento delle prestazioni è notevole senza danni di sorta

per il realismo così come ottenuto finora. La tecnica ammette ancora un lieve

miglioramento che consiste nel limitare gli elementi che partecipano al rendering

ammettendo solo quelli davanti alla telecamera utente, è richiesto però un lieve aumento

nella complessità della gestione del movimento nello spazio 3D perché è necessario sapere

in ogni istante in che direzione si sta muovendo il visitatore in modo da selezionare

correttamente le entità da visualizzare. Ritornando all’esempio dell’applicazione di visita si


ottiene un frame rate che oscilla tra i 18 e i 20 f.p.s. decisamente soddisfacente rispetto ai

limiti stabiliti.

In realtà il tempo di rendering misurato in queste condizioni permetterebbe di ottenere

frame rate ancora più elevati (intorno a 22-25 f.p.s.) ma le prestazioni dell’applicazione di

visita sono limitate dall’architettura della stessa o meglio dall’architettura MFC utilizzata.

Per la visita automatica si sfrutta infatti la presenza dei timer di sistema per ottenere la

rigenerazione continua delle scene e il movimento della telecamera utente, purtroppo il

minimo intervallo che può passare tra un intervento del timer e il successivo è valutabile

intorno ai 50 ms a cui corrisponde un frame rate pari a 20 (si può superare questo limite

utilizzando i timer multimediali che permettono di avere intervalli minimi intorno al

millisecondo).

Per quanto riguarda la visita assistita e manuale la situazione è ancora peggiore perché, a

quanto pare, il sistema di messaggi Windows per la gestione della tastiera non permette di

superare i 13,50-14,00 f.p.s. (rientra comunque nel limite indicato per una buona fluidità di

movimento), perlomeno questa è la conclusione a cui si perviene dopo aver analizzato il

codice per il movimento dell’applicazione di visita, sostanzialmente identico per tutti i casi

citati (si dovrebbero quindi raggiungere i 18,00 f.p.s. anche nella visita assistita e

manuale).

7.4 Contenuti Multimediali

Il realismo e il grado di coinvolgimento del visitatore nella ricostruzione virtuale è legato

anche alla presenza di elementi multimediali. Nel caso di questa applicazione di visita

esistono almeno due modi per inserire contenuti di questo tipo, in particolare per quanto

riguarda la riproduzione di effetti sonori.

Il motore di rendering (controllato dalla vista 3D) offre un supporto completo alla gestione

e alla riproduzione di suoni in formati standard (.mp3, .wav, cd audio). È possibile

riprodurre suoni bidimensionali e tridimensionali, i primi non hanno alcuna caratteristica

dipendente dall’ambiente ricostruito, possono essere utilizzati come colonna sonora e in

corrispondenza di particolari punti dell’itinerario di visita, i secondi possono invece essere

associati ad un elemento “sorgente” e la loro intensità e il bilanciamento tra canale destro e

sinistro dipenderanno dalla posizione dell’utente rispetto alla sorgente.

La tecnica privilegiata per l’inserimento di contenuti multimediali è però basata

sull’utilizzo della vista HTML.


Come indicato nel capitolo 4 essa incapsula completamente le funzionalità di Microsoft

Internet Explorer, pertanto la tecnica da utilizzare per inserire risorse di vario tipo (audio,

video, testo, etc.) è la stessa che viene usata per la creazione di pagine web. Tutte queste

risorse possono essere usate nel programma di visita semplicemente includendole in una

pagina HTML.

Poiché la presentazione delle varie pagine di informazione (HTML) è correlata ad azioni

ed eventi del mondo tridimensionale visualizzato è possibile coordinare l’offerta dei

contenuti con la visita, in modo da ottenere una buona corrispondenza tra movimento

nell’ambiente 3D e informazioni visualizzate. La potenza di questa tecnica di

presentazione è notevole e permette di svincolare completamente il lavoro di

programmazione del software di visita dalla quantità e dal tipo di contenuti da inserire.

La definizione e la gestione dei contenuti stessi può essere affidata completamente a chi

dispone di dettagliate informazioni sul sito turistico e può quindi essere organizzata

secondo esigenze specifiche diverse, offrendo diversi spunti tematici alla stessa visita

virtuale.

Rimane solo una piccola ambiguità da chiarire, infatti poiché sia la vista 3D che la vista

HTML possono causare la riproduzione di suoni è necessario coordinare le azioni delle due

in modo da evitare la sovrapposizione di contenuti audio. I suoni generati dalle due viste

vengono infatti riprodotti in modo indipendente e se entrambe richiedono la riproduzione

di suoni, questi vengono sovrapposti. Il risultato può non essere sempre piacevole e poiché

i suoni associati alla vista HTML non sono noti a priori (dipendono dalle pagine HTML

che vengono visualizzate) conviene assegnare un qualche forma di priorità a quest’ultima

in modo tale da interrompere o perlomeno ridurre l’intensità dei suoni riprodotti dalla vista

3D quando questo sia necessario per evitare spiacevoli cacofonie.

7.5 Valutazione dei risultati ottenuti

L’applicazione di visita virtuale delle miniere di Traversella offre un buon spunto per trarre

alcune valutazioni sul lavoro svolto nella sua creazione. L’idea alla base della stessa è

interessante e i risultati ottenuti permettono di capire quanto sia probabile e utile

l’integrazione di un apparato di visita virtuale con le tecniche più tradizionali di visita. Nel

caso specifico le prestazioni ottenute devono essere inquadrate e giudicate a partire dagli

obiettivi iniziali.


Sono state ricostruite circa 1 km di gallerie in parte non accessibili perché franate, su due

livelli verticali distanziati di 30 m. Tradotto in termini di elementi tridimensionali di base,

l’itinerario si compone di 63 gallerie, 1 incrocio a quattro vie, 6 incroci a T, 4 bivi, 4

discenderie e un pozzo di estrazione. Fare una valutazione accurata del numero totale di

poligoni coinvolti non è utile ma si può stimare che il loro numero si aggiri attorno a

qualche decina di migliaia di elementi. Il frame rate raggiunto è pari, mediamente, a 18,5

f.p.s. nella visita automatica e 13,00 f.p.s nelle visite assistita e manuale. Queste

prestazioni sono essenzialmente indipendenti dall’estensione dell’itinerario e pertanto è

ragionevole aspettarsi che rimangano pressoché costanti al variare del numero di percorsi

considerati. La durata della visita completa è pari a circa 7 min. valore che non conviene

superare di molto per mantenere alto l’interesse da parte del visitatore.

Le dimensioni del programma di visita sono relativamente ridotte (circa 320 kByte)

rispetto allo spazio necessario alla memorizzazione di tutte le risorse necessarie (texture,

suoni, pagine HTML,…). La complessità a livello di codice è relativamente elevata: allo

stato attuale la visita è completamente definita e controllata con circa 30000 righe di

codice.

Sicuramente si è dimostrato che è possibile ottenere un sistema di visita virtuale interattivo

in cui alla classica presentazione di informazioni sul sito turistico si affianca la possibilità

di visita dello stesso, in modo autonomo, senza la necessità di una guida, con tutta la

libertà offerta dalla visita di un ambiente reale.

D’altra parte il realismo ottenuto non è di grande impatto ed è certamente possibile fare di

meglio. Utilizzando i programmi di modellazione tridimensionale attualmente disponibili

si possono ottenere risultati qualitativamente migliori e al limite tali da rendere difficile la

divisione tra zone in bassa qualità (stile videogioco) e zone in qualità fotografica.

L’utilizzo di tali possibilità è però legato al tipo di motore 3D che si utilizza, esso infatti

deve essere in grado di riprodurre gli ambienti così generati garantendo una buona fluidità

di movimento.

Le prestazioni in termini di velocità sono soddisfacenti, il movimento nell’ambientazione

tridimensionale è generalmente fluido e le possibilità offerte sono tali da rendere semplice

e soddisfacente la visita stessa. È possibile muoversi nella ricostruzione a piacere: in modo

automatico, se si è interessati ai contenuti e ad una panoramica dell’itinerario di visita, in

modo assistito se si vuole scegliere il proprio percorso senza rinunciare alla semplicità di

utilizzo del sistema di visita e in modo completamente autonomo se si preferisce avere il

controllo completo dei movimenti. Le informazioni presentate sono solamente quelle che


competono ad un programma dimostrativo più che ad un programma di visita definitivo,

ma permettono già di capire quale sia la potenza del mezzo sia in termini di chiarezza che

di vastità di contenuti. L’ambientazione sonora è relativamente primitiva ma in grado di

offrire sensazioni sufficienti a rendere più realistica la visita.

Il vero tallone d’Achille di tutto il software di visita è il motore 3D Morfit: l’utilizzo di

formati proprietari per la definizione degli elementi tridimensionali e la sostanziale

inesistenza di convertitori adeguati da formati più diffusi, ha imposto il suo utilizzo nella

modalità EDITOR, con prestazioni troppo scadenti. La necessità di generare all’interno

dell’applicazione di visita i modelli 3D limita eccessivamente le variazioni di aspetto

dell’ambiente ricostruito e non permette di raggiungere elevati livelli di realismo. La

capacità ridotta di trattare un elevato numero di poligoni comporta una riduzione obbligata

del numero di oggetti che compongono l’ambiente ricostruito. La difficile cooperazione tra

motore 3D e schede acceleratrici per immagini tridimensionali e la scarsa adattabilità del

motore di visita alle capacità di visualizzazione delle schede stesse, rendono Morfit non

utilizzabile seriamente per un’applicazione di visita definitiva. Si rende pertanto necessario

il reperimento di un nuovo motore di rendering e navigazione nel caso si voglia

un’applicazione “commerciale” di questa visita virtuale. Naturalmente l’utilizzo di un

nuovo motore comporta una nuova fase di apprendimento dell’utilizzo dello stesso e una

riscrittura completa del software di visita essendo lo stesso basato pesantemente

sull’utilizzo di funzioni di generazione 3D, dipendenti dal motore di rendering e

navigazione. L’architettura generale del software di visita rimane valida così come rimane

valido lo sforzo di analisi delle tecniche di gestione della visita e di integrazione tra

ambiente 3D e informazioni ipertestuali.

In conclusione la visita virtuale delle miniere di Traversella e così di altri siti turistici è

possibile, interessante e fornisce una buona integrabilità con le modalità di visita classiche

a patto di utilizzare dei mezzi sufficienti e di individuare correttamente quanto ci si aspetta

dall’applicazione di visita stessa.

7.5.1 Caratteristiche dell’apparato con cui sono stati misurati i valori di velocità espressi in frame al secondo

Processore: AMD Athlon 1200 MHz.

Memoria: 256 Mb 133MHz.

Scheda Video: ATI RadeonVE (2 DAC 300MHz).

Memoria Video: 32Mb DDR.


Harddisk: IBM 40Gb ULTRA ATA 100 7200 r.p.m.

Sistema operativo: Microsoft Windows 98.

87

8 Conclusioni

Lo studio di una possibile applicazione delle tecniche della realtà virtuale applicate al

turismo si è rivelato di interesse particolare, superiore forse a quanto preventivato. La

possibilità di integrare capacità interattive e grafiche delle ultime tecnologie per

videogiochi con contenuti e ambienti turistici genera un ottimo ausilio alla visita in prima

persona dei siti turistici stessi. In particolare la ricostruzione in realtà virtuale raggiunge il

massimo delle sue possibilità quando rende possibile, attraente e fruibile la visita di siti

non accessibili al pubblico. Siano essi miniere, sotterranei di città, aree archeologiche

ancora in fase di scavo, la possibilità di offrirne comunque una visita costituisce uno

spunto, un vantaggio notevole sia per i promotori turistici locali che per i visitatori.

Riferendosi al caso particolare delle miniere di Traversella l’applicazione di visita presenta

tutti i suoi svantaggi ma fornisce un’idea abbastanza chiara di cosa si può ottenere. Meglio

ancora la creazione di un’applicazione pratica, funzionante a tutti gli effetti permette di


individuare meglio quali siano i punti di forza e i difetti di una visita virtuale. Il caso

pratico comporta alcuni problemi da risolvere che difficilmente sono apprezzabili con un

approccio di tipo puramente teorico, la soluzione degli stessi porta a focalizzare meglio

l’attenzione sui veri obiettivi della visita e permette di distinguere i vari livelli di

importanza da associare a tali obiettivi. Si è dimostrato che è effettivamente possibile

integrare tecnologie real-time per la realtà virtuale e turismo ma non si è certo trattato in

modo completo l’intero campo di applicazione. Anzi quanto sviluppato sinora a livello

poco più che embrionale offre lo spunto per andare avanti e ottenere risultati sempre

migliori. In particolare, è di sicuro interesse nonché di rapida applicazione la generazione

di ambienti tridimensionali foto-realistici, visitabili con un elevato grado di interattività.

La creazione di un’applicazione di visita virtuale funzionante apre la strada alla creazione

di visite virtuali di una vasta tipologia di ambienti. Le conoscenze acquisite in questo

studio di fattibilità consentono una migliore scelta dei motori di rendering e di navigazione

da utilizzare per generare software di visita. La comunicazione continua con chi si occupa

effettivamente del sito turistico (nel caso specifico le Miniere di Traversella) mette in

evidenza numerosi aspetti che appaiono secondari al programmatore ma che sono di vitale

importanza per chi offre il servizio turistico. L’interesse e la fiducia dimostrati da chi si

occupa di gestire le miniere di Traversella lascia ben sperare per una possibile diffusione di

questi sistemi di visita. Il futuro riserverà probabilmente numerose sorprese in questo

campo e l’integrazione tra visite virtuali e reali sarà sempre più stretta. In conclusione

l’argomento non solo è interessante ma offre soluzioni utilizzabili e merita certamente un

ulteriore approfondimento. La visita virtuale è uno strumento potentissimo finora poco

utilizzato, sarà sicuramente utile in moltissimi casi ma non si potrà mai perdere di vista lo

scopo della stessa e confondere realtà e finzione. Non si vuole e non si deve sostituire la

visita reale dei siti turisti, si vuole integrarla con queste nuove tecnologie per renderla più

fruibile, per tutti, vicini e lontani.

89

A Appendice: Motori di Rendering e Navigazione

Vengono qui riportati i nomi e le indicazioni per reperire i vari motori di rendering 3D presi

in considerazione per la realizzazione del programma di visita virtuale di un sito turistico.

MOTORE

3D

TIPO DI

LICENZA

SITO INTERNET DOCUMENTAZIONE NOTE

Dark Basic Freeware www.darkbasic.com Buona: Manuale in

formato doc.

-

3D Rad Commerciale www.3drad.com Disponibile completa

solo dopo l’acquisto

-

Klick & Play - www.Klick&Play.com - Non utilizzabile

90 Appendice A –Motori di rendering-

Adventure

game studio

- Members.xoom.com/

dosuser/ac.htm

Buona: Manuali in

formato pdf.

Non utilizzabile

3D Game

Studio

Commerciale www.3dgamestudio.com Buona: Manuali in

formato pdf.

-

Blender Freeware www.blender.nl Sufficiente: esitono

alcuni tutorial in formato

pdf.

-

Game Basic Versione

alpha

www.GamesBasic.com Non disponibile -

Pie 3D Commerciale www.pie3d.com Buona Non utilizzabile

RPG Toolkit - Rpgtoolkit.com - Non utilizzabile

Scramm Commerciale www.scramm.org

Ca3D - home.t-

online.de/home/Carstenfuc

hs/engine.html

- -

Fly3D Commerciale www.paralelo.com.br/

fly7

Buona -

Genesis 3d Commerciale www.genesis3d.com - -

Magic 3d - Come.to/magic3d - -

Phoenix3d Commerciale www.4xtechnologies.com/

phoenix3d.htm

Buona -

Blitz Engine - thesauce.3dfiles.com/Blitz/ - -

gxReality

Engine

- www.light-cube.com - -

WTK Commerciale www.sense8.com - -

Revolution

3d

- www.revolution3d.net

TrueVision Commerciale www.truevision3dsdk.com

Auran Jet Commerciale www.auran.com Buona: (formato doc) -

Tutti i motori 3d per cui compare la dicitura “Non utilizzabile” nella sezione Note non sono

utili per la realizzazione di un’applicazione di visita virtuale per diversi motivi: i motori 3D

per lo sviluppo di RPG (Role Playing Game) perché offrono solo una rappresentazione

Appendice A –Motori di rendering- 91

assonometrica dell’ambiente ricostruito (non accettabile dal punto di vista del realismo), altri

a causa della impossibilità a essere integrati in una applicazione più generale, etc..

Per motori per cui non viene indicata la qualità della documentazione o non è ben chiaro se

essa sia disponibile oppure è disponibile solo dopo l’acquisto e quindi non è valutabile.

A volte il tipo di licenza non è chiaramente indicato nella pagina Internet di descrizione del

motore di rendering, in tal caso si è lasciato un trattino nella casella corrispondente.

Glossario

Motori di rendering:

insieme di strutture dati e funzioni che si occupano di offrire un approccio semplice

alla generazione di ambienti tridimensionali e alla gestione dell’interazione tra

oggetti diversi all’interno degli ambienti stessi.

Piattaforma:

tipo di computer e/o di sistema operativo per cui è stato previsto il funzionamento di

un dato programma.

Librerie Grafiche:

insieme di comandi e funzioni accessibili con un dato linguaggio di programmazione

che permettono di sfruttare in modo “diretto” le capacità grafiche di un dato sistema.

Frame Rate:

velocità di generazione delle scene tridimensionali espressa in frame (riquadri) al

secondo.

Rendering:

processo di visualizzazione su schermo di un ambiente tridimensionale.

Modellazione:

memorizzazione di informazioni sufficienti a definire un dato oggetto (nel caso

specifico un’entità tridimensionale) in modo chiaro ed univoco.

Ottimizzazione:

nel caso specifico dei motori di rendering, esistono motori studiati per lavorare

meglio in determinate condizioni (ottimizzazione) e in grado pertanto di offrire le

prestazioni migliori solo per modalità di costruzione particolari, ad esempio

ambienti interni.

Tecnologie real time per la realtà virtuale -...

Documents

Transcript of Tecnologie real time per la realtà virtuale -...