progetto

musealizzare
il virtuale

modello virtuale
della sala

postazioni

modello 3D
della cappella

Album

MODELLO 3D DELLA CAPPELLA

Ortofotomosaici
Requisiti tecnici del modello
Librerie grafiche OpenGL

Modello VRML della Cappella degli Scrovegni
(Visualizzatore consigliato: http://www.parallelgraphics.com/products/cortona/

ORTOFOTOMOSAICI

Gli ortofotomosaici sono stati realizzati dall' Istituto per le Tecnologie Aplicate ai Beni Culturali del CNR, in collaborazione con Aracnet.

Si ringrazia il Prof. Antonio Vettore dell'Università di Padova per aver messo a disposizione i dati del fotogrammetrico, poi ulteriormente elaborati dalla nostra equipe.

Parete sinistra
Parete destra
Abside
GiudizioUniversale
Volta

REQUISITI TECNICI DEL MODELLO

Il programma di realtà virtuale che realizzeremo sarà un software proprietario, utilizzerà la libreria grafica OpenGL e sarà scritto in linguaggio C++.

OpenGl richiede che le textures siano dimensionate secondo precise proporzioni:
la misura di ogni singolo lato deve corrispondere ad una potenza del n. 2 (2, 4, 8, 16, 64, 256, 512, 1024, 2048, le ultimissime schede supportano textures fino a 4096 x 4096). Le schede grafiche con drivers ottimizzati per OpenGL dispongono di una memoria autonoma (VRAM), che viene normalmente divisa in due parti: una per il frame buffer (buffer per i colori, buffer per il valore di profondità spaziale di ogni singolo vertice, e altri) e l'altra per il caricamento in memoria delle tessiture.
La scheda grafica che utilizzeremo in questo programma è la Wildcat 5110, che è il modello più professionale attualmente disponibile sul mercato. È dotata di 128 MB di VRAM totali, di cui 64 MB destinati alle tessiture.
Poiché, quindi, ciascuna tessitura non può superare una determinata dimensione in pixel (256 x 256, ….. fino 4096 x 4096), è necessario suddividere l'intera copertura fotografica in molte immagini, ottenendo un mosaico. Ciascuna texture deve essere attribuita ad una geometria a sé stante, perciò è necessario suddividere anche quest'ultima nel numero di porzioni corrispondente al numero delle textures.

Per il modello della Cappella degli Scrovegni abbiamo optato per un tipo di suddivisione che è indipendente dalla suddivisione logica del ciclio affrescato. È vero infatti che le singole scene saranno selezionabili e questo presupporrebbe una suddivisione logica degli oggetti in modo da farli corrispondere, appunto, alle scene ma per la selezione si è deciso di sovrapporre alle scene stesse delle altre geometrie trasparenti (invisibili) dalla grandezza esattamente corrispondente. L’utente avrà così l’impressione di cliccare sulla scena per selezionarla mentre invece l’imput del mouse sarà intercettato dalla corrispondente geometria (quad) invisibile. Questa soluzione semplifica enormemente il lavoro di scomposizione del modello e delle textures.

La nostra applicazione prevede due livelli di dettaglio:
1° livello:
Prevede la mappatura dell’intera superficie della cappella con le fotografie rettificate; l’intera copertura fotografica non può superare i 40 MB di VRAM.
L’utente è libero di navigare in tempo reale all’interno del modello, può osservare l’intera superficie parietale, la volta, il pavimento interamente mappati con le textures fotografiche.

Abbiamo calcolato che le dimensioni di ciascuna texture, in questo primo livello di dettaglio, non potranno superare i 512 x 512 pixel (ciascuna mappatura 512 x 512 ha un peso di 768KB a 24 bit).
Una parte della RAM video (i circa 25 MB rimanenti) sarà utilizzata per il mip mapping, un filtro che riesce ad evitare il flickering in caso di allontnamento, poiché riduce la tessitura in copie più piccole. Il chiaroscuro derivante dalla naturale disomogeneità di illuminazione della cappella, verrà inglobato, in questo primo livello di dettaglio, come dato raster nelle mappature stesse; il calcolo del light mapping (intensità di illuminazione sulle superfici affrescate) è troppo dispendioso in termini di VRAM per poter essere effettuato in tempo reale.

Essendo, in questo 1° livello di dettaglio, ciascuna texture 512 x 512, il grado di avvicinamento alla singola scena non potrà essere troppo elevato, in quanto da una vista troppo ravvicinatata essa risulterebbe sgranata. Quindi si imposterà un blocco all’avvicinamento.

2° livello:
Non si rimarrà nello spazio tridimensionale globale e navigabile, ma si avrà una sostituzione di gometria e di textures (occorrerà attendere 3 o 4 secondi per il caricamento): la scena prescelta potrà assumere una texture da circa 40 MB (con un livello di dettaglio eccezionale, si arriverà alla testa a pieno schermo di un personaggio). Sarà possibile avvicinarsi alla scena zoomandola, scorrerla a destra, sinistra, in alto e in basso.
La scelta di escludere, nel 2° livello di dettaglio, il modello di contesto è dovuta in parte alla considerazione che l'oggetto di interesse particolare è la scena e tutti i tematismi che essa offre, ma soprattutto lo imponeva l'economia generale di lavoro: sia l'elaborazione del modello geometrico della Cappella, sia l'infrastruttura del programma sarebbero diventati eccessivamente complessi ed avrebbero richiesto dei tempi di realizzazione estremamente lunghi.

La Wildcat 5110 supporta tessiture da 1024 x 1024 pixel. È quindi necessario scomporre ulteriormente anche la singola scena, in 12-16 oggetti circa per avere la stessa possibilità di avvicinamento.

LIBRERIE GRAFICHE OPENGL

L'OpenGL è una libreria grafica composta da circa 250 funzioni (istruzioni). Utilizzando queste istruzioni il programmatore ha la possibilità di accedere ai drivers OpenGL che il produttore della scheda video ha implementato. Questa architettura software consente di sfruttare le potenzialità di accelerazione grafica della scheda video (hardware) in modo da ottenere una accelerazione nella gestione di complessi contesti grafici 2D o 3D animati in tempo reale. La fluidità del movimento che si raggiunge risulta di gran lunga superiore a quanto si potrebbe ottenere attraverso il solo calcolo del processore.
La geometria del modello in una applicazione DVR non può superare in media i 150.000 poligoni, la fluidità del movimento in tempo reale può raggiungere anche i 60-70 frames al secondo, entrambe questi parametri dipendono comunque dalla potenza scheda video e del processore del computer su cui viene installata l'applicazione.

Implementazione dei dati
Per poter visualizzare un oggetto (cioè la rappresentazione virtuale di un territorio, un edificio, un monumento, ecc) in un contesto grafico OpenGL è necessario adempiere ai seguenti requisiti:

1) descrizione della geometria.
L'oggetto deve essere suddiviso in geometrie, definite "poligoni". Nel caso di una scansione 3D la nuvola di punti, risultante dalla rilevazione della stazione laser totale o dallo scanner laser 3D, viene trasformata in una mesh, cioè in una entità geometrica in cui ogni punto precedentemente rilevato diventa un vertice delimitante un poligono. Normalmente le mesh sono costitutite da un insieme di poligoni triangolari, chiamate "facce". Nel caso di modelli molto complessi è necessario ottimizzare la lista dei vertici affinchè si evitino ripetizioni di vertici condivisi da più facce adiacenti, allo scopo di semplificare la descrizione dell'oggetto e rendere più fluido e veloce il movimento in tempo reale.
All'interno dell'applicazione OpenGL la geometria dell'oggetto è descritta da una lista di vertici e da un indice delle facce ad essi corrispondenti.
Per dare un ordine di grandezza, una scena tridimensionale in un videogame viene rappresentata da un insieme di 20-25.000 facce.

2) Illuminazione
Per ottenere un effetto di illuminazione reale su un oggetto è necessario che ciascuna faccia disponga della sua normale.
Per normale si intende il vettore perpendicolare al piano della faccia, rivolto verso l'esterno, che ha origine dal centro della faccia stessa.
L'angolo che si crea tra la normale della faccia e il vettore di incidenza del raggio luminoso genera l'intensità della luce su quella faccia.
Per ottenere una maggior precisione nell'ombreggiatura dell'oggetto si possono utilizzare per ogni singola faccia tre normali (anzichè una) aventi origine da ciascuno dei tre vertici.
Allo stesso modo dei vertici, anche le normali vengono descritte, all'interno dell'applicazione, da una lista.

3) Applicazione delle tessiture
Per conferire l'aspetto realistico alla mesh è necessario rivestirla con una immagine raster (bitmap) che può essere una fotografia del mondo reale che si vuole rappresentare, oppure una rappresentazione grafica simbolica (materiale).
Attraverso le coordinate di tessitura si adatta la bitmap alla geometria dell'oggetto;
all'interno dell'applicazione le coordinate di tessitura sono descritte da una lista di valori che determina la posizione della bitmap per ogni singolo vertice.

I dati relativi alle liste dei vertici, delle facce, delle normali e delle coordinate di tessitura vengono inglobati in un formato di file proprietario. L'applicazione costruisce le sue visualizzazioni riferendosi a tali files.

OpenGl richiede che le textures siano dimensionate secondo precise proporzioni:
la misura di ogni singolo lato deve corrispondere ad una potenza del n. 2 (2, 4, 8, 16, 64, 256, 512, 1024, 2048). Le schede grafiche con drivers ottimizzati per OpenGL dispongono di una memoria autonoma (VRAM), che viene normalmente divisa in due parti: una per il frame buffer (buffer per i colori, buffer per il valore di profondità spaziale di ogni singolo vertice, e altri) e l'altra per caricamento in memoria delle tessiture.
Poichè le dimensioni di ciascuna tessitura non dovrebbero superare normalmente i 512 x 512 pixel, (per un peso singolo di 768 KB, a 24 bit), è necessario suddividere l'intera copertura fotografica in molte immagini, ottenendo un mosaico. Poichè ciascuna texture deve essere attribuita ad una geometria, è necessario suddividere anche quest'ultima nel corrispondente numero di porzioni.

4) sviluppo dell'applicazione
Sebbene siano disponibili diversi motori di rendering in OpenGL (librerie di funzioni già scritte), può essere preferibile sviluppare un software proprietario dotato di una infrastruttura generale in C++ o in MFC con un contesto di visualizzazione dei dati spaziali in OpenGL.
Questa scelta può essere motivata dall'ottenimento di una maggiore efficenza delle prestazioni e dalla necessità di implementare funzioni altrimenti non facilmente riscontrabili o non altrettanto flessibili a determinate esigenze.

a) Implementazione nel programma di RV dei tools di navigazione per consentire all'utente di spostarsi in tempo reale all'interno del modello.
b) Sviluppo di altre forme di interattività che consentono di interagire con il mondo virtuale in modo complesso: selezionare oggetti, cambiare le tessiture alle geometrie per creare nuovi tematismi, richiamare altri oggetti o mondi tridimensionali, spostare le luci in tempo reale, misurare distanze lineari, superfici o volumi, aprire filmati, immagini, suoni, testi e altri elementi multimediali da mettere in relazione con il contesto 3D, ecc.