progettazione e realizzazione di una libreria basata su opengl per il ...

UNIVERSITÀ DEGLI STUDI DI MILANO
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea Triennale in Informatica
PROGETTAZIONE E REALIZZAZIONE
DI UNA LIBRERIA BASATA SU
OPENGL PER IL CARICAMENTO E LA
GESTIONE IN TEMPO REALE DI
MODELLI TRIDIMENSIONALI DAL
FORMATO 3DSTUDIO
Relatore: Prof. Daniele MARINI
Correlatori: Dott. Stefano MOTTURA
Dott. Giovanni Paolo VIGAN Ò
Anno Accademico 2002-2003
Tesi di Laurea di:
Alessandro MULLONI
Matricola n. 654024

Ringraziamenti
Ringrazio il direttore dell’ITIA-CNR Prof. Francesco Jovane
per aver messo a mia disposizione tutte le strutture e le
strumentazioni dell’ITIA-CNR;
il Dott. Stefano Mottura per la sua pazienza nel seguirmi
durante l’intero periodo di tesi;
il Dott. Giampaolo Viganò per i consigli e i suggerimenti
che hanno chiarito molti dubbi;
il Dott. Emanuele Travaini e il Dott. Luca Greci
per la gentilezza, la simpatia e la disponibilità dimostrate;
il Dott. Marco Sacco per la sua cordialità;
il Prof. Daniele Marini per il sostegno accademico che dà
alla grafica 3D ed al game programming.
Ringrazio il papà Roberto e la mamma Angela
per il continuo supporto che sempre mi hanno fornito,
per tutti i sogni che tale supporto ha realizzato,
per tutti i sogni che realizzerà.

Indice
Indice i
Elenco delle figure v
1 Prefazione 1
2 La realtà virtuale 3
2.1 Origine del termine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Gli esordi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 L’evoluzione negli anni successivi . . . . . . . . . . . . . . . . . . . . 5
2.4 Gli anni ’80: la prima commercializzazione della realtà virtuale . . . . 6
2.5 Realtà virtuale negli anni ’90 . . . . . . . . . . . . . . . . . . . . . . 7
2.6 La realtà virtuale ai nostri giorni . . . . . . . . . . . . . . . . . . . . 9
2.7 Il sistema di realtà virtuale . . . . . . . . . . . . . . . . . . . . . . . . 10
3 La grafica 3D in tempo reale 13
3.1 La nascita e l’evoluzione delle librerie grafiche 3D . . . . . . . . . . . 13
3.1.1 Il Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Il GKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 Le altre librerie alla fine degli anni ’80 . . . . . . . . . . . . . 15
3.1.4 OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.5 Direct3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Le librerie di visualizzazione . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 I modelli e i loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 I loader 3DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
i

INDICE ii
4 Introduzione al lavoro di tesi 21
5 Il Loader 24
5.1 L’interfaccia e il runtime binding . . . . . . . . . . . . . . . . . . . . 24
5.2 La struttura di un file 3DS . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Il Loader 3DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 L’inizializzazione prima del parsing . . . . . . . . . . . . . . . . . . . 28
5.5 Le tre fasi di parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5.1 I materiali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5.2 Gli oggetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5.3 La gerarchia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6 Il postprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6.1 La correzione degli errori . . . . . . . . . . . . . . . . . . . . . 36
5.6.2 L’applicazione delle trasformazioni geometriche . . . . . . . . 38
5.6.3 La collocazione di queste operazioni . . . . . . . . . . . . . . . 39
6 La gestione della gerarchia 40
6.1 Le funzionalità per l’utilizzo della gerarchia . . . . . . . . . . . . . . . 40
6.2 L’importanza di una gerarchia . . . . . . . . . . . . . . . . . . . . . . 41
6.3 Bounding box e centro di un oggetto . . . . . . . . . . . . . . . . . . 43
6.4 Il culling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.5 Le trasformazioni geometriche in tempo reale . . . . . . . . . . . . . . 55
6.6 L’ordinamento dei figli . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7 La gestione del rendering 62
7.1 Le funzionalità a supporto del rendering . . . . . . . . . . . . . . . . 62
7.2 Le texture supportate . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2.1 Texture di colore diffusivo . . . . . . . . . . . . . . . . . . . . 65
7.2.2 Mappa di riflessione ambientale . . . . . . . . . . . . . . . . . 66
7.2.3 Texture di colore speculare . . . . . . . . . . . . . . . . . . . . 68
7.2.4 Mappa di riflessività . . . . . . . . . . . . . . . . . . . . . . . 69
7.2.5 Texture di colore emissivo . . . . . . . . . . . . . . . . . . . . 70
7.2.6 Bump mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.2.7 Mappa di luminosità . . . . . . . . . . . . . . . . . . . . . . . 72

INDICE iii
7.2.8 Mappa di opacità . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.3 Il rendering multipassata . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.3.1 Lo stencil buffer . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.3.2 Lo z-buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.3.3 Il blending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.3.4 L’algoritmo utilizzato . . . . . . . . . . . . . . . . . . . . . . . 78
7.3.5 L’ordine delle texture . . . . . . . . . . . . . . . . . . . . . . . 80
7.4 I materiali trasparenti . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8 Demo e Benchmark 84
8.1 Il programma dimostrativo . . . . . . . . . . . . . . . . . . . . . . . . 84
8.2 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9 Conclusioni e sviluppi futuri 89
9.1 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
9.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A Il formato 3DS 91
A.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.2 I chunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
B Le estensioni OpenGL 100
B.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.2 Elenco delle estensioni presenti . . . . . . . . . . . . . . . . . . . . . 100
B.3 Utilizzare le estensioni OpenGL . . . . . . . . . . . . . . . . . . . . . 101
B.4 Le estensioni utilizzate nella presente libreria . . . . . . . . . . . . . . 101
C Il frustum culling 104
C.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C.2 Il calcolo del frustum . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
C.3 Il frustum culling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
D Il bump mapping 110
D.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
D.2 La texture di bump mapping . . . . . . . . . . . . . . . . . . . . . . . 111

INDICE iv
D.3 L’embossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
E L’algoritmo di ordinamento 120
E.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
E.2 Distanza fra un poligono ed il punto di vista . . . . . . . . . . . . . . 120
E.3 Distanza fra un nodo della gerarchia ed il punto di vista . . . . . . . 122
E.4 L’algoritmo di ordinamento . . . . . . . . . . . . . . . . . . . . . . . 122
F I quaternioni e la rotazione 125
F.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
F.2 Matematica base dei quaternioni . . . . . . . . . . . . . . . . . . . . 127
F.3 Rotazione con i quaternioni . . . . . . . . . . . . . . . . . . . . . . . 128
G Screenshot della demo realizzata 129
G.1 Demo 1: la gerarchia e le trasformazioni geometriche in tempo reale . 129
G.2 Demo 2: bump mapping . . . . . . . . . . . . . . . . . . . . . . . . . 131
G.3 Demo 3: trasparenza e modifica delle texture in tempo reale . . . . . 133
G.4 Demo 4: mappe di luminosità ed integrazione fra modelli importati
da formati differenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Bibliografia 136

Elenco delle figure
2.1 Il Sensorama di Morton Heilig, 1956 . . . . . . . . . . . . . . . . . . . . 4
2.2 L’HMD di Evans e Sutherland . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Il Videoplace di Myron Krueger . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Il DataGlove della VPL . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 CAVE Automatic Virtual Environment . . . . . . . . . . . . . . . . . . 8
2.6 ImmersaDesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7 Occhiali per proiezione attiva (a sinistra) e passiva (a destra) . . . . . . . 10
2.8 Un esempio di sistema di realtà virtuale . . . . . . . . . . . . . . . . . . 11
3.1 Un’immagine generata tramite PHIGS . . . . . . . . . . . . . . . . . . . 16
3.2 La scena di figura 3.1 ricreata con OpenGL . . . . . . . . . . . . . . . . 17
4.1 La divisione fra formato e semantica . . . . . . . . . . . . . . . . . . . . 22
5.1 Il late binding nella classe Loader . . . . . . . . . . . . . . . . . . . . . 25
5.2 La struttura base di un file 3DS . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Le tre fasi della procedura load file . . . . . . . . . . . . . . . . . . . . . 29
5.4 Le tre fasi di parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5 La struttura di un materiale . . . . . . . . . . . . . . . . . . . . . . . . 32
5.6 La struttura di un oggetto . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.7 La struttura di un nodo della gerarchia . . . . . . . . . . . . . . . . . . 35
6.1 Le trasformazioni geometriche su un nodo si diffondono sul suo sottoalbero 42
6.2 Con una semplice operazione logica si può sostituire l’oggetto Automobile
1 con l’oggetto Automobile 2 lasciando invariato il resto della gerarchia . . 44
6.3 Bounding box minima (in grigio) e di rapida computazione (in nero) . . . 45
v

ELENCO DELLE FIGURE vi
6.4 Il culling scarta la porzione di scena che non cade all’interno del campo di
vista. La parte di scena non scartata è stata scurita . . . . . . . . . . . . 51
6.5 La pipeline grafica OpenGL. Informazioni geometriche (Vertex data) e
informazioni raster (Pixel data) dopo varie operazioni computazionalmente
costose convergono a formare il frame che verrà visualizzato (contenuto nel
Framebuffer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.6 Culling di punti e di poligoni: P0 viene mantenuto, P1 è scartato. T0 è
mantenuto interamente, T1 solo parzialmente, T2 è scartato (in grigio le
parti mantenute) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.7 Un parallelepipedo con i lati paralleli ai tre assi definisce su ciascun asse
un intervallo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.8 Trasformazione da coordinate della vista a Clipping Coordinate . . . . . . 54
6.9 Blending errato (in alto) e corretto (in basso) fra due oggetti . . . . . . . 60
7.1 La modulazione fra il riflesso diffusivo e la texture di colore diffusivo (A)
ricrea l’oggetto (B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2 Si nota come l’immagine della texture originale applicata su una semisfera
(A) appaia come riflessa sul modello 3D (B) se lo si inscrive all’interno
della semisfera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3 Si nota come l’immagine delle sei texture originali applicate su un cubo
(A) appaiano come riflesse sul modello 3D (B) se lo si inscrive all’interno
del cubo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.4 La modulazione fra il riflesso speculare e la texture di colore speculare (A)
ricrea l’oggetto (B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.5 La riflessività dell’etichetta sull’estintore a destra è stata annullata per
mezzo di una mappa di riflessività . . . . . . . . . . . . . . . . . . . . . 69
7.6 I fanali di un automobile appaiono accesi nell’immagine di destra grazie
all’uso di una texture di colore emissivo . . . . . . . . . . . . . . . . . . 70
7.7 Una superficie senza (a sinistra) e con (al centro e a destra) bump mapping
(si noti nelle ultime due immagini come le ombre dei mattoni in rilievo
varino in funzione della posizione della luce) . . . . . . . . . . . . . . . . 71
7.8 Il bump mapping su un materiale lucido è quasi impercettibile (A) se non
si utilizza la simulazione di ruvidità (B) . . . . . . . . . . . . . . . . . . 73

ELENCO DELLE FIGURE vii
7.9 Nei poligoni l’illuminazione calcolata per vertice (A) in base ai vettori
normali non è precisa quanto quella calcolata per pixel (B) . . . . . . . . 74
7.10 Illuminazione in tempo reale (a sinistra) e precalcolata (a destra) (si noti
la migliore resa delle ombreggiature nella seconda) . . . . . . . . . . . . . 75
7.11 La trasparenza di un pannello di vetro decorato (A) può essere modulata
in maniera non uniforme per mezzo di una mappa di opacità (B) . . . . . 75
7.12 Interpretazione grafica dei valori scritti nello stencil buffer dall’algoritmo
implementato durante il rendering (0 = nero, 1 = bianco) . . . . . . . . . 77
8.1 Un modello 3DS rappresentante una vasta zona rurale . . . . . . . . . . . 87
9.1 Un’ambientazione caricata per mezzo del loader di file BSP . . . . . . . . 90
A.1 La struttura a blocchi dei file 3DS . . . . . . . . . . . . . . . . . . . . . 91
A.2 I chunk caricati dalla classe Loader3DS . . . . . . . . . . . . . . . . . 93
C.1 I sei piani che definiscono il volume del frustum di vista . . . . . . . . . . 108
C.2 Solamente i poligoni completamente all’interno di uno semispazio negativo
vengono eliminati. Per questo motivo la bounding box B0 viene scartata
dal frustum culling, mentre B1 viene mantenuta . . . . . . . . . . . . . . 109
D.1 Una texture di bump mapping per il pianeta Terra . . . . . . . . . . . . 111
D.2 La somma fra la texture di bump mapping e la sua inversa genera una
texture uniforme grigia . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
D.3 Se la texture di bump mapping viene scostata rispetto alla sua inversa la
loro somma genera due dislivelli di colore, uno più scuro ed uno più chiaro 113
D.4 Un triangolo con le coordinate di texture dei vari vertici . . . . . . . . . . 114
D.5 Sono stati i calcolati i versori di avanzamento delle coordinate di texture
D.6
per il triangolo di Figura D.4 (sono mostrati solo quelli per P 0) . . . . . . 116
È necessario calcolare il versore con direzione uguale a quella della luce
e verso opposto. Calcolando la norma della sua proiezione sul versore
di avanzamento della coordinata di texture si ottiene lo scostamento da
applicare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

ELENCO DELLE FIGURE viii
E.1 Sistema di riferimento globale (A) e sistema di riferimento della vista (B).
La trasformazione della vista porta il punto di vista nell’origine degli assi
ed orienta la direzione della vista lungo l’asse z . . . . . . . . . . . . . . 121
F.1 Rotazione con i tre angoli di Eulero (A) e con un angolo ed un asse generico
(B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
F.2 Una doppia rotazione di 90 ◦ eseguita su (A) causa la sovrapposizione di
due assi (B) con la perdita di un grado di libertà . . . . . . . . . . . . . 126
G.1 Un modello rappresentante una vasta area rurale. Esso è composto da
23519 facce triangolari memorizzate in una gerarchia formata da 2902 nodi
(cfr. Capitolo 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
G.2 Un nodo della gerarchia viene aggiunto e modificato senza influenzare il
resto del modello (cfr. Capitolo 6) . . . . . . . . . . . . . . . . . . . . . 130
G.3 I due mezzi appaiono in movimento sulla strada grazie all’applicazione in
tempo reale di una traslazione variabile nel tempo (cfr. 6.5) . . . . . . . . 130
G.4 Quando la luce si sposta le ombre su un pavimento con bump mapping
abilitato variano (cfr. 7.2.6) . . . . . . . . . . . . . . . . . . . . . . . . 131
G.5 Quando la luce si sposta le ombre su un muro di mattoni con bump
mapping abilitato variano (cfr. 7.2.6) . . . . . . . . . . . . . . . . . . . 132
G.6 Un pannello semitrasparente posto al centro di una stanza rivestita di
piastrelle (cfr. 6.6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
G.7 La texture del pannello trasparente viene modificata in tempo reale in
maniera da simulare la proiezione di una animazione su di esso (cfr. 7.2) . 133
G.8 La trasparenza del pannello è uniforme nell’immagine a sinistra, modulata
in maniera non uniforme per mezzo di una mappa di opacità nel pannello
di destra (cfr. 7.2 e 7.2.8) . . . . . . . . . . . . . . . . . . . . . . . . . 134
G.9 Nella scena di sinistra l’illuminazione è calcolata in tempo reale, nella scena
di destra sono sfruttate le mappe di luminosità (cfr. 7.2.7) . . . . . . . . 134
G.10 L’ambiente è stato importato da un file BSP (cfr. 9.2) mentre la teiera è
stata importata da un file 3DS (cfr. 3.4). Come si può notare l’indipen-
denza dal formato di provenienza delle classi Group e Object (cfr. Capitolo
4) consente una totale integrazione fra modelli provenienti da tipi di file
differenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

CAPITOLO 1
Prefazione
Il presente lavoro di tesi è stato svolto presso l’Istituto di Tecnologie Industriali e
Automazione del Consiglio Nazionale delle Ricerche (ITIA-CNR), la cui attività si
colloca nella ricerca applicata per l’automazione industriale e per il sostegno dell’in-
novazione dell’impresa. Le problematiche su cui l’ITIA lavora variano dal campo
della progettazione, alla robotica e l’automazione.
All’interno dell’istituto opera il gruppo VME (Virtual Manufacturing Environment),
che focalizza la propria attività sullo studio, l’ideazione e la realizzazione di ambienti
immersivi di realtà virtuale. Gli ambienti immersivi sono utilizzati per seguire varie
fasi di sviluppo di un prodotto, a partire dal design sino alla gestione dell’impian-
tistica della catena di montaggio. Le applicazioni sviluppate fanno ovviamente un
uso intensivo di grafica 3D in tempo reale.
Fino a qualche anno fa i calcolatori utilizzati dall’ITIA per le applicazioni 3D im-
mersive erano tutti macchine Silicon Graphics. Tali computer, in quanto prodotti
specialistici ad alte prestazioni (ne fanno uso anche aziende cinematografiche e di
grafica non in tempo reale per le loro elevate potenzialità di rendering), erano e sono
tuttora venduti a prezzi piuttosto elevati. Anche i costi del software risultavano inci-
sivi, poiché un gruppo di ricerca con un vasto ambito di pertinenza come il VME non
può limitarsi ad un utilizzo a lungo termine di un unico pacchetto software specifico
in quanto tale specificità è in conflitto con l’elevata variabilità degli obiettivi nel
tempo. Il software che veniva eseguito era principalmente della Multigen-Paradigm,
una ditta fornitrice di prodotti professionali che necessitano di un continuo rinno-
vamento di licenze d’uso, talvolta non solo da parte dello sviluppatore ma anche da
parte dell’utente finale.
1

CAPITOLO 1. PREFAZIONE 2
Negli ultimi tempi l’avvento di schede grafiche per PC e librerie che sfruttino le loro
potenzialità – in grado di competere sul rapporto prestazioni/prezzo con le macchine
e gli ambienti di sviluppo precedentemente utilizzati dall’ente – ha fatto nascere
all’interno del team di sviluppo il desiderio di muoversi verso nuove metodologie più
economiche e più flessibili per la realizzazione dei propri applicativi. Già da qualche
anno il VME si è perciò dotato di alcuni Personal Computer – che ora operano al
fianco delle workstation Silicon Graphics – e dedica parte dei suoi sforzi allo studio
e l’implementazione di nuove soluzioni utilizzando le librerie grafiche OpenGL.
Lo spostamento graduale verso questi nuovi ambienti ha apportato la necessità di
una base software che, operando ad un livello leggermente superiore alle OpenGL,
ma facendolo in maniera trasparente, fornisca delle funzioni elementari per la ge-
stione di ambienti tridimensionali. Uno degli scopi principali di tale libreria – creata
internamente all’istituto per l’istituto – è di non riproporre le limitazioni inevitabil-
mente imposte da un pacchetto software commerciale prodotto da terzi, prima fra
le quali la bassa possibilità di interazione con gli strati software sottostanti.
All’interno di questo progetto si colloca questo lavoro di tesi, integrandosi con una
precedente parte della libreria incaricata della gestione di telecamere, luci, gerarchie
della scena e posizionamento degli oggetti nello spazio, con lo scopo di fornire agli svi-
luppatori routine per un’agevole importazione e rendering di modelli tridimensionali
nelle applicazioni.

2.1 Origine del termine
CAPITOLO 2
La realtà virtuale
Il termine Virtual Reality (Realtà Virtuale) fu coniato nel 1989 da Jaron Lanier –
fondatore della VPL Research – programmatore, inventore e artista. Egli presentava
la realtà virtuale come “il primo medium che non limiti l’anima dell’uomo” (J.
Lanier). A quei tempi VR indicava unicamente la Immersive Virtual Reality (Realtà
Virtuale Immersiva), un sottoinsieme di ciò che oggi comunemente si intende quando
si utilizza la medesima parola.
Fra i sinonimi utilizzati nel corso del tempo si possono citare in ordine cronologico
Realtà Artificiale (Myron Krueger, anni ’70), Cyberspazio (William Gibson, 1984) e
i più recenti Mondi Virtuali e Ambienti Virtuali (anni ’90). [BEI03, BAC00]
2.2 Gli esordi
Gli studi di ricerca nel campo della realtà virtuale risalgono in realtà ad un paio
di decenni prima della VPL. Il primo dispositivo in grado di fornire un’esperien-
za immersiva al suo utente era il Sensorama, una macchina dotata di proiezione
stereoscopica, suono stereo, simulatore di vento e diffusore di odori. Tutto era pre-
registrato, per cui questa prima esperienza risultava piuttosto passiva. Il Sensorama
era stato progettato da un cinematografo di Hollywood, Morton Heilig e riprodu-
ceva varie situazioni realistiche – fra cui un viaggio in motocicletta per le strade di
Brooklyn – coinvolgendo artificialmente gran parte dei sensi di chi vi si sedeva di
3

CAPITOLO 2. LA REALTÀ VIRTUALE 4
Figura 2.1: Il Sensorama di Morton Heilig, 1956
fronte e offrendogli “la realtà per un nichelino” (M. Heilig). Era a tutti gli effet-
ti un videogioco di realtà virtuale. Tuttavia né i videogiochi né la realtà virtuale
esistevano ancora.
L’Head Mounted Display (Schermo posizionato sulla testa) fu presentato nel 1968 da
Ivan Sutherland, cofondatore della Evans & Sutherland, azienda ancora in attività
ed esperta nel settore di simulazioni grafiche immersive per addestramenti. Esso
funzionava sovrapponendo immagini in wireframe alla realtà circostante 1 , e posse-
deva anche un sistema di tracciamento della posizione della testa, disponibile sia
meccanico che a ultrasuoni.
Negli stessi anni nascevano anche i primi sistemi tattili. Il GROPE dell’Università
del North Carolina consisteva in un braccio robotico con sei gradi di libertà dotato
di motori. I motori erano attivati dall’ambiente virtuale per simulare i campi di
forza fra atomi presenti nelle molecole, che venivano mostrate in 3D su un display.
1 Questo tipo di sistema è denominato “realtà aumentata” ed è caratterizzato dalla sovraimpressione
di elementi virtuali alla realtà circostante.

CAPITOLO 2. LA REALTÀ VIRTUALE 5
Figura 2.2: L’HMD di Evans e Sutherland
La navigazione avveniva tramite il medesimo braccio. [COH00, STE01]
2.3 L’evoluzione negli anni successivi
La ricerca dei due decenni che seguirono fu incentrata sullo sviluppo delle tecniche di
tracciamento, visualizzazione e interfacciamento tattile sviluppate dai pionieri degli
anni ’60.
Fra i più celebri risultati ottenuti si possono elencare i Virtual Pushbuttons (Pulsanti
virtuali) di Knowlton (1975), una tastiera inclinata su cui ad una certa distanza era
posto un vetro semitrasparente per la proiezione di immagini virtuali, in maniera tale
che l’utente avesse l’illusione di premere ciò che era proiettato, e non la pulsantiera
sottostante; il LEEP (Large Expanse, Extra Perspective), un binocolo in grado di
fornire un campo di vista sul mondo virtuale di 140 ◦ ; la Videopostazione di Krueger,
che tramite una telecamera consentiva all’utente di interagire con il mondo virtuale
per mezzo di gesti. [COH00]

CAPITOLO 2. LA REALTÀ VIRTUALE 6
Figura 2.3: Il Videoplace di Myron Krueger
2.4 Gli anni ’80: la prima commercializzazione della realtà
virtuale
Le ricerche nel campo della realtà virtuale continuavano e apportavano nuovi prodot-
ti quali il Virtual Cockpit (Cabina di pilotaggio virtuale) e altri strumenti immersivi.
Nel frattempo qualcos’altro si stava però muovendo in un ambiente fino ad allora
abbastanza lontano dalla VR: le aziende. La fondazione della VPL da parte di
Jaron Lanier è datata 1985. Essa era la prima società che si dedicasse a progetti
di realtà virtuale. I prodotti della VPL spaziavano dagli strumenti di input tattile
(DataGlove) all’output visivo (EyePhone) e sonoro (AudioSphere).
Un ulteriore filone si andava evolvendo: erano da poco sorti i primi videogiochi di
avventura, basati su interfacce testuali e perciò apparentemente totalmente scollegati
da ciò che a quei tempi era la realtà virtuale. Essi modellavano però a tutti gli effetti
degli ambienti virtuali, senza dubbio più interattivi di quelli del Sensorama. Una

CAPITOLO 2. LA REALTÀ VIRTUALE 7
Figura 2.4: Il DataGlove della VPL
particolare branca dei videogiochi era quella dei MUD 2 in cui l’interazione avveniva
anche con altri esseri umani, sempre all’interno di un mondo fittizio.
A tutto questo si aggiungeva la cinematografia. Il manifesto di Tron (Disney, 1982)
parlava di “un mondo all’interno del computer dove l’uomo non è mai stato, mai
prima d’ora”. Tron narrava la storia di un ragazzo imprigionato all’interno di un
computer e costretto a cercare la libertà in un mondo virtuale dove gli stessi program-
mi erano esseri umani. Nel 1987 esordiva Star Trek, con il suo Holodeck, strumento
immaginario di visualizzazione 3D basato su ologrammi. [COH00, STE01]
2.5 Realtà virtuale negli anni ’90
I lavori sulla realtà virtuale procedevano sui due filoni della ricerca e della commer-
cializzazione.
Nel 1992 il CAVE (CAVE Automatic Virtual Environment) veniva alla luce. Esso
era composto da una stanza cubica di cui 4 facce erano utilizzate come display.
L’utente poteva interagire con l’ambiente, mentre la sua posizione veniva tracciata
2 Multi User Dungeon, ovvero Segreta Multiutente. Dungeon non è in realtà legato ad una prigione
sotterranea, ma deriva da un omonimo gioco d’avventura a giocatore singolo. Il primo MUD voleva
appunto ricreare l’atmosfera di quel gioco aggiungendo la possibilità di multiutenza.

CAPITOLO 2. LA REALTÀ VIRTUALE 8
Figura 2.5: CAVE Automatic Virtual Environment
con 6 gradi di libertà, e i fotogrammi proiettati sulle pareti variavano in funzione di
essa.
Sempre nel 1992 usciva anche Wolfenstein 3D (ID Software), primo vero video-
gioco con ambientazione virtuale tridimensionale (in realtà utilizzava delle sprite 3
animate).
Due anni dopo, nel Novembre 1994, veniva redatta la prima bozza delle specifiche
del VRML 1.0, un linguaggio per la descrizione di scenari tridimensionali virtuali e
delle possibili interazioni con essi.
Nel frattempo erano commercializzati altri strumenti di supporto alla progettazio-
ne fra cui l’ImmersaDesk (1995), una scrivania virtuale che consentiva di creare e
visualizzare i risultati del proprio lavoro tridimensionalmente.
Contemporaneamente la ricerca sulla realtà virtuale si stava espandendo anche in
altri settori, fra cui la medicina (chirurgia, ortopedia, ecc.) e le simulazioni inge-
gneristiche (ad esempio per studiare le conseguenze di forti eventi atmosferici su un
ponte). [COH00, STE01]
3 Una sprite – nel gergo dei videogiochi – è un’immagine bidimensionale sovrapposta ad uno sfondo
in base a determinati criteri di trasparenza, utile su certi hardware poiché non è necessario dover
ridisegnare lo scenario completo ad ogni fotogramma. La maggior parte dei videogame moderni
utilizzano modelli poligonali al posto delle sprite.

CAPITOLO 2. LA REALTÀ VIRTUALE 9
Figura 2.6: ImmersaDesk
2.6 La realtà virtuale ai nostri giorni
In quasi 40 anni dove è giunta la realtà virtuale? Ben lungi dall’essere ancora un pro-
dotto esclusivamente immersivo e riservato ai ricercatori e pochi altri, oggi la realtà
virtuale – supportata dai nuovi hardware e software capaci di buone prestazioni sulla
grafica 3D a un costo molto più contenuto rispetto a qualche tempo fa – è presente
in molti settori, fra cui quelli medico, ingegneristico, educativo, videoludico, ed è
anche più semplicemente utilizzata come semplice supporto per la visualizzazione
di dati. Sono oggi disponibili varie soluzioni per la resa dell’immersività e per il
tracciamento.
Gli strumenti di proiezione più moderni si suddividono in passivi e attivi. La tec-
nologia dei proiettori passivi si basa sulla polarizzazione delle onde luminose 4 e gli
occhiali per visualizzare la scena tridimensionale sono meno costosi, in quanto for-
mati unicamente da due membrane trasparenti che filtrino la luce polarizzata. Nella
4 La luce è prodotta da cariche elettriche vibranti in tutte le direzioni, nella luce polarizzata
linearmente queste vibrazioni sono limitate ad un piano. [HR94, SIC58]

CAPITOLO 2. LA REALTÀ VIRTUALE 10
proiezione attiva sono invece gli occhiali a ricreare una visione tridimensionale chiu-
dendo alternativamente la lente sinistra o destra in sincronia con l’immagine sul
display 5 . I supporti per la proiezione spaziano da semplici scrivanie analoghe all’Im-
mersaDesk ai nuovi sistemi CAVE con proiezione su tutte le pareti del cubo. Inoltre
è disponibile anche una vasta gamma di HMD.
Figura 2.7: Occhiali per proiezione attiva (a sinistra) e passiva (a destra)
L’evoluzione tecnologica ha portato al quasi totale abbandono dei sistemi di traccia-
mento meccanici, rimpiazzati dagli strumenti elettromagnetici, ad ultrasuoni oppure
ottici. I guanti moderni utilizzano sensori elettrici oppure fibre ottiche e si differen-
ziano fra loro sostanzialmente per i gradi di libertà rilevati, per il numero di sensori
presenti su ogni dito e infine per l’interfaccia fra il guanto e il calcolatore.
Per quanto concerne invece l’udito, il suono 3D è oggi simulato piuttosto efficien-
temente, e impianti in grado di gestirlo sono disponibili anche a prezzi abbastanza
bassi (piccoli impianti di home video ottengono già un elevato livello di tridimen-
sionalità), mentre i cinema più professionali – in combinazione con i moderni film –
permettono esperienze sonore immersive.
2.7 Il sistema di realtà virtuale
Tutti gli strumenti presentati finora non sono solamente macchinari a sé stanti. Un
sistema di realtà virtuale comprende difatti vari hardware e un software che supporti
la loro intercomunicazione.
Il ponte fra l’uomo e l’ambiente virtuale è realizzato dal sottosistema di interazio-
ne. Le soluzioni utilizzabili sono molteplici, principalmente collocabili nei due filoni
dell’interazione passiva e attiva. Nell’interazione passiva l’utente è monitorato da
5 Per questo motivo sono spesso chiamati “shutterglasses”, ovvero gli occhiali che chiudono.

CAPITOLO 2. LA REALTÀ VIRTUALE 11
Figura 2.8: Un esempio di sistema di realtà virtuale
un sistema di tracciamento che ne identifica la posizione con un certo numero di
gradi di libertà e una certa precisione variabili. L’interazione attiva avviene invece
tramite qualche strumento di input gestito direttamente dall’utente, quale potrebbe
essere una tastiera, un joystick oppure un guanto. Interazione passiva e attiva non
sono fra loro esclusive.
Il software sviluppato e utilizzato è responsabile della corrispondenza fra l’input
dell’utente e l’output. L’elaborazione dei segnali provenienti dal sottosistema di
interazione modificano lo stato del programma, e questa variazione viene evidenziata
nel rendering della scena tridimensionale. La visualizzazione dell’ambiente generato
dal programma può avvenire tramite i già citati sistemi CAVE, HMD o altri.
A questo quadro generale di un sistema base di realtà virtuale immersiva si possono
aggiungere una moltitudine di altri strumenti fra cui impianti di output sonoro 3D,
oppure bracci meccanici che consentano di percepire un feedback come la resistenza
alla pressione.
Queste sono dunque attualmente le componenti base di un sistema di realtà virtuale:
• un sottosistema di input (guanti, tracciamento, joystick, . . . );
• un sottosistema di output (HMD, CAVE, . . . );

CAPITOLO 2. LA REALTÀ VIRTUALE 12
• un software intermedio che converta le informazioni ricevute come input in
dati utili per l’output.
Il fondamentale software intermedio deve perciò contenere necessariamente parti di
codice per:
• l’interpretazione dell’input e il conseguente aggiornamento delle strutture dati
del programma;
• la lettura di tali strutture dati e la renderizzazione delle informazioni in esse
contenute.
In un sistema di realtà virtuale immersiva la renderizzazione deve essere tridimensio-
nale e in tempo reale. Le tecnologie attuali per questo tipo di grafica sono presentate
nel Capitolo 3.

CAPITOLO 3
La grafica 3D in tempo reale
3.1 La nascita e l’evoluzione delle librerie grafiche 3D
3.1.1 Il Core
Quando nel 1974 lo SIGGRAPH (Special Interest Group for Computer Graphics)
dell’ACM (Association for Computing Machinery) si riunì per l’annuale conferen-
za lo scenario del supporto alla programmazione grafica era molto frammentato.
La competitività dei prodotti hardware era strettamente legata anche alle routine
software che li accompagnavano, e negli anni precedenti era perciò sorta una mol-
titudine di librerie proprietarie – create dalle stesse case produttrici – che nel loro
complesso risultavano estremamente ridondanti. Questo non favoriva la portabilità
dei programmi da un sistema hardware all’altro, perché la mancanza di uno stan-
dard rallentava la conversione del codice. I programmatori – che oramai avevano
assaporato i vantaggi di un linguaggio di alto livello – non erano molto desiderosi di
ritornare all’utilizzo intensivo dell’Assembly. Fu istituito un comitato con il compito
di analizzare il problema e presentarlo ad una delle conferenze successive.
Tre anni più tardi tale comitato presentò al convegno SIGGRAPH del 1977 la sua
proposta per un “Core” di subroutine grafiche che sarebbero dovute essere fornite da
ogni produttore di hardware. Alcune delle idee alla base di questo processo di uni-
formazione provenivano dalla conferenza dell’anno precedente organizzata dall’IFIP
(International Federation of Information Processing) in Francia. Fra le caratteristi-
che fondamentali di una libreria grafica emerse a quel convegno le più importanti
erano:
13

CAPITOLO 3. LA GRAFICA 3D IN TEMPO REALE 14
• la necessità di mantenere separate le funzioni di input e di output, per facilitare
la comprensibilità del codice e l’intuitività dell’utilizzo delle routine. Fino ad
allora erano state spesso implementate procedure che svolgessero entrambi i
compiti a seconda dei parametri ricevuti.
• l’indipendenza dallo specifico hardware in maniera tale che il codice rispettante
lo standard fosse il più possibile portabile;
• la separazione fra coordinate del mondo e coordinate della periferica per man-
tenere una distinzione fra lo spazio del problema e lo spazio di uno specifico
strumento di output.
Il Core non ebbe molta fortuna e non diventò mai uno standard. Innanzitutto inclu-
deva anche varie funzioni per la grafica 3D e per questo motivo non si adattava bene
al ruolo di libreria base per dispositivi di output prevalentemente bidimensionale.
Inoltre non si adeguò – neppure dopo la revisione del 1979 – ai nuovi dispositi-
vi raster 1 che avevano proprio in quegli anni rimpiazzato gran parte dei display
vettoriali 2 . [LAF99]
3.1.2 Il GKS
Nel frattempo in Europa nasceva EUROGRAPHICS (l’associazione europea per la
computer grafica). Era il 1980. A settembre dello stesso anno si tenne la prima
conferenza dell’ente, e si parlò molto del problema di una standardizzazione delle
librerie grafiche. Il sollevamento di queste problematiche portò a successive discus-
sioni dalle quali nacque la proposta per il GKS (Graphische KernSystem 3 ), ispirata
in parte anche alle idee del Core. Il GKS fu presentato nel 1982 come bozza, e venne
approvato dalla ISO (International Standard Organization) tre anni più tardi, con
le specifiche ISO 7942 del 1985. [ISO85]
1 Un dispositivo raster mantiene un copia dell’immagine da visualizzare in memoria e la utilizza
per aggiornare lo schermo senza che sia necessario ridisegnare tutto ad ogni fotogramma. La
copia è sostanzialmente una matrice di elementi (denominati pixel) corrispondenti ai singoli punti
colorati che compongono un’immagine discreta. I dispositivi raster si contrappongono ai dispositivi
vettoriali, nei quali l’immagine non è discretizzata in una matrice di punti ma è composta da
primitive definite geometricamente e ridisegnate interamente ad ogni fotogramma.
2 Cfr. Nota 1.
3 Sistema grafico nocciolo.

CAPITOLO 3. LA GRAFICA 3D IN TEMPO REALE 15
Rispecchiando le idee dell’IFIP sì seguì il principio dell’astrazione dall’hardware.
Vennero ideate delle entità denominate Workstation utilizzabili come periferiche
virtuali permettendo al programmatore di non doversi preoccupare della gestione di
tutte le possibili strumentazioni differenti. Qualsiasi Workstation era difatti utiliz-
zabile in maniera analoga a tutte le altre. Un altra particolarità interessante dello
standard era la completa indipendenza da qualsiasi linguaggio di programmazione:
le implementazioni per i linguaggi allora più comuni furono definite in successive
specifiche ISO (ISO 8651). [ISO88A]
A differenza della proposta fatta dal SIGGRAPH, questo standard prevedeva so-
lamente funzioni per l’output grafico bidimensionale, per un totale di un paio di
centinaia di routine. L’approccio stratificato impiegato per definire le necessarie
funzionalità del sistema – sia per l’input che per l’output – lasciava però ampio spa-
zio allo sviluppo di procedure di livello superiore che implementassero funzioni per
la grafica 3D.
Questa possibilità fu sfruttata fin da subito, e già nel 1988 un nuovo standard, GKS-
3D (ISO 8805, 1988), si affiancò alla libreria base, aggiungendole funzionalità per la
grafica tridimensionale. [LAF99, SAA95, ISO88B]
3.1.3 Le altre librerie alla fine degli anni ’80
Parallelamente al GKS-3D si andavano evolvendo anche altri progetti. I più impor-
tanti portarono alla nascita di PHIGS e Iris GL.
PHIGS (Programmer’s Hierarchical Interactive Graphics System) definiva uno stan-
dard (ISO 9592, 1989) per la manipolazione e la visualizzazione di oggetti grafici
bidimensionali e tridimensionali. La gestione di questi modelli avveniva tramite
l’inserimento nel PHIGS graphics database di display lists, particolari strutture dati
per la memorizzazione della geometria da renderizzare. La visualizzazione veniva
poi gestita dal database stesso, indifferentemente su una o più periferiche di output.
Come il GKS, anche PHIGS utilizzava delle Workstation che astraevano dallo speci-
fico hardware. PHIGS era privo di molti metodi per il fotorealismo, e lo scrupoloso
rispetto dedicato alle specifiche rallentava spesso le prestazioni rendendolo un pro-
dotto più adatto alla visualizzazione ingegneristica e industriale che ad altri campi
come la grafica in realtime. [ISO89]

CAPITOLO 3. LA GRAFICA 3D IN TEMPO REALE 16
Figura 3.1: Un’immagine generata tramite PHIGS
PHIGS affiancò Xlib (e il protocollo PEX 4 fu accostato al già utilizzato protocollo
X) come libreria per lo sviluppo di applicazioni grafiche in ambiente Unix. [SMI95]
Fra la fine degli anni ottanta e l’inizio degli anni novanta la Silicon Graphics Incorpo-
rated realizzò Iris GL come supporto per la programmazione grafica sulle omonime
macchine che essa stessa produceva. Oltre alle funzioni utili per le geometrie 2D
e 3D, Iris GL forniva anche un supporto per il facile utilizzo di altre funzioni del
sistema operativo, fra cui la creazione e modifica delle finestre.
3.1.4 OpenGL
Nel 1992 da Iris GL nacque OpenGL (Open Graphic Library). Questo passaggio
segnò un cambiamento radicale della libreria, in quanto volutamente non si badò
alla garanzia di compatibilità all’indietro. Venne scardinata dalle specifiche tutta la
sezione troppo strettamente legata all’implementazione del sistema operativo, fra cui
le funzioni di gestione delle finestre. Ciò che rimaneva era un nocciolo di procedure
grafiche che grazie all’elevata portabilità ed all’astrazione dalla configurazione hard-
4 PHIGS Extension for X (Estensione PHIGS per X).

CAPITOLO 3. LA GRAFICA 3D IN TEMPO REALE 17
ware erano in grado di funzionare – seppure con le ovvie variazioni di performance
– su mainframe così come su PC.
Figura 3.2: La scena di figura 3.1 ricreata con OpenGL
Il controllo dello sviluppo di OpenGL fu affidato esternamente e la libreria – non più
di proprietà della SGI – è da allora rilasciata senza necessità di licenze. Fin da subito
l’organo competente per l’evoluzione di OpenGL è stato l’ARB (Architecture Review
Board) ai cui vertici si trovano i rappresentanti delle maggiori case produttrici di
hardware per la grafica. L’ARB si occupa anche del monitoraggio delle estensioni
alla libreria create dalle singole aziende per supportare meglio le caratteristiche
hardware delle proprie periferiche (cfr. Appendice B). L’ARB aggiunge inoltre
nuove funzionalità alle specifiche, standardizzando le estensioni più diffuse.
La versione attuale è OpenGL 1.5, rilasciata il 29 Luglio 2003. [OPE03]
3.1.5 Direct3D
Direct3D è un sottoinsieme di una più vasta libreria chiamata DirectX e sviluppata
da Microsoft a partire dal 1995. Lo scopo che portò alla sua creazione fu il tentati-
vo di spostare l’ambiente utilizzato dai programmatori grafici da DOS a Windows.
Prima di allora gran parte degli sforzi degli sviluppatori erano dedicati all’implemen-

CAPITOLO 3. LA GRAFICA 3D IN TEMPO REALE 18
tazione di codice complesso che potesse supportare la maggior parte degli hardware
in commercio. Le DirectX implementano la metodologia di astrazione del sistema
fisico sottostante utilizzata anche dalle altre librerie.
Per l’utilizzo di questa libreria non sono necessarie licenze, ma il supporto è garantito
solamente sui sistemi operativi Microsoft. La versione attuale è DirectX 9, rilasciata
nell’estate del 2003. [EG01]
3.2 Le librerie di visualizzazione
Ad un livello superiore delle librerie grafiche 3D, e solitamente posando le proprie
fondamenta su di esse, si collocano le librerie di visualizzazione. Esse sono spesso
dei pacchetti software specializzati dedicati alla facilitazione della programmazione
in un settore preciso (realtà virtuale, progettazione ingegneristica, ecc.).
Alcune fra quelle attualmente utilizzate nel settore della realtà virtuale sono le
librerie offerte da Multigen-Paradigm e da SGI.
OpenInventor e OpenGL Performer sono prodotti Silicon Graphics. OpenInventor
è un ambiente di sviluppo orientato agli oggetti per la creazione di applicazioni 3D
interattive, OpenGL Performer – membro di una più grande suite di ausilio alla
programmazione (OpenGL Shader, Optimizer, Volumizer, ecc.) – è un supporto per
gli sviluppatori di applicativi di realtà virtuale orientati alle prestazioni. Si basano
entrambi su OpenGL.
Vega (Multigen-Paradigm) è una libreria per la creazione e la simulazione in tempo
reale di ambienti virtuali.
È supportata da un’interfaccia grafica per modificare i
parametri dell’applicazione anche in fase di esecuzione (LynX). Solo di recente è
stata commercializzata anche in una versione per Windows, ma fino a poco tempo
fa era disponibile solamente per le workstation IRIX della Silicon Graphics. Vega è
basata su OpenGL Performer.
Il problema legato a queste librerie d’alto livello è spesso la loro troppo elevata
chiusura in se stesse, che rende difficile l’interazione con gli strati sottostanti. Se da
un lato la programmazione è resa facile dai costrutti più intuitivi e più potenti messi
a disposizione dello sviluppatore, dall’altro lato è spesso molto complesso riuscire a
modificare un particolare stato del sottostrato di rendering di basso livello.
A questo si aggiunge anche la necessità economicamente onerosa dell’acquisto e

CAPITOLO 3. LA GRAFICA 3D IN TEMPO REALE 19
il mantenimento continuo nel tempo di licenze per l’utilizzo, in quanto – a diffe-
renza delle librerie 3D – questi software di visualizzazione di più alto livello sono
solitamente a pagamento.
3.3 I modelli e i loader
Qualsiasi applicazione 3D necessita di modelli da visualizzare, siano essi dei semplici
triangoli oppure rappresentazioni più articolate di oggetti del mondo che ci circonda.
Spesso le necessità di realismo visuale impongono oltre alle specifiche dei vertici
anche l’impiego di materiali (texture o più semplicemente colori), vettori normali e
altri dati. Le modalità per ottenere oppure creare queste informazioni all’interno
di un applicativo sono varie, e non sono fra loro esclusive. Quale scegliere per un
particolare oggetto o insieme di oggetti è a discrezione dello sviluppatore.
La metodologia più elementare – ma più scomoda quando la complessità dei modelli
aumenta – è quella di definire manualmente all’interno del programma tutto ciò
che è necessario per descrivere la geometria e i materiali. Se questo può essere
soddisfacente quando si ha bisogno di poche forme geometriche, certamente non lo
è quando si necessita di qualcosa di più dettagliato.
Sicuramente è più comodo per molte applicazioni utilizzare una definizione mate-
matica o algoritmica dell’oggetto da modellare. Questo metodo è molto pratico
per applicazioni che facciano uso di figure e solidi geometrici, ma anche curve e
superfici (Spline, NURBS, ecc.) nonché frattali. Tali applicazioni non si limita-
no a software di ricerca scientifica, ma possono essere programmi appartenenti a
qualsiasi settore (dalla prototipazione di carrozzerie di automobile alla generazione
automatica di alberi per un ambiente virtuale). I limiti di questo approccio sono
evidenti: non è possibile adottarlo qualora sia necessario un modello non definibile
matematicamente o algoritmicamente.
Il sistema più flessibile è creare l’oggetto con un programma di modellazione 2D o
3D esterno ed importarlo nella propria applicazione. Questo è reso possibile da un
loader. Un loader è una particolare porzione di programma in grado di importare
all’interno del programma stesso delle particolari informazioni da una sorgente di
provenienza; in questo caso si tratta dell’importazione di modelli geometrici da file.
Un loader può essere creato appositamente dallo stesso programmatore che ne farà

CAPITOLO 3. LA GRAFICA 3D IN TEMPO REALE 20
uso oppure prodotto esternamente da terzi che possono distribuirlo a pagamento
oppure gratis. Anche il formato di input può essere un formato standard e accessibile
a tutti (ad esempio VRML oppure XML) oppure proprietario (ad esempio FLT di
OpenFlight della Multigen-Paradigm).
3.4 I loader 3DS
Per quanto concerne il formato 3DS 5 sono già disponibili vari loader, sia a pagamento
che gratuiti. Entrambe le tipologie hanno delle limitazioni.
I loader a pagamento sono solitamente soggetti a problemi di bassa possibilità di
interazione con i livelli sottostanti e necessità di mantenimento delle licenze. I
loader più noti di questo tipo sono quelli integrati nelle librerie di visualizzazione,
per esempio nel già citato OpenGL Performer. 6 .
I loader gratuiti sono invece nella maggior parte dei casi delle demo software fini
a se stesse, e il tentativo di integrarli all’interno di un’applicazione è spesso mol-
to difficoltoso. OpenGL è infatti una macchina a stati, e questi loader – essendo
progettati per la semplice visualizzazione dei modelli e non per l’utilizzo all’interno
di un più vasto applicativo – sono soliti modificare gli stati senza ripristinare poi i
valori precedenti, con conseguenze catastrofiche sulla renderizzazione del rimanente
ambiente che circonda il modello caricato.
Un ultimo appunto sui loader reperibili esternamente è il fatto che talvolta durante
l’importazione vengano tralasciati alcuni particolari attributi del modello – ritenuti
non interessanti dallo sviluppatore – ma che per l’applicazione che ne fa uso possono
essere molto utili, se non indispensabili.
5 Il formato 3DS è il formato di esportazione di Autodesk 3DStudio (http://www.discreet.com); di
recente è stato affiancato dal nuovo formato MAX.
6 Cfr. 3.2 a pagina 18.

CAPITOLO 4
Introduzione al lavoro di tesi
Lo scopo del presente lavoro di tesi è la progettazione e lo sviluppo di un loader per
il formato 3DS che:
• sia facilmente integrabile all’interno di applicazioni di realtà virtuale basate su
OpenGL, ovvero non comporti la necessità di apprendere nuovi linguaggi di
programmazione o di scripting;
• non causi perturbazioni degli stati OpenGL e perciò non influenzi il rendering
complessivo dell’ambiente virtuale;
• importi in maniera il più possibile completa i modelli presenti all’interno di un
file 3DS, in particolare le informazioni relative ai sistemi di coordinate locali
dei singoli oggetti ignorate dalla maggior parte dei loader;
• permetta all’utente di abilitare e disabilitare in tempo reale (quindi in fase di
esecuzione) le caratteristiche dei materiali consentendo di scegliere di volta in
volta il compromesso fra frame rate e fotorealismo desiderato.
Il loader è stato implementato in ANSI C++, e si colloca all’interno di un più grande
progetto dell’ITIA per la creazione una libreria di strumenti per la programmazione
grafica in tempo reale (è stata di recente sviluppata come lavoro di tesi di due colleghi
la parte responsabile della gestione delle telecamere, delle luci e del posizionamento
dei modelli nel mondo). Il codice si basa su OpenGL, in quanto dovrà essere integrato
in applicazioni che faranno uso di tale libreria grafica.
21

CAPITOLO 4. INTRODUZIONE AL LAVORO DI TESI 22
Figura 4.1: La divisione fra formato e semantica

CAPITOLO 4. INTRODUZIONE AL LAVORO DI TESI 23
In fase di progettazione si è deciso di mantenere la suddivisione logica fra formato e
semantica. Sono state perciò ideate due parti software indipendenti, una specializ-
zata nella lettura dei dati dal formato di salvataggio ma ignorante il significato di
ciò che legge, l’altra conscia unicamente del senso delle informazioni lette e ignara
della loro provenienza (cfr. Figura 4.1).
Si è giunti perciò alla creazione di due classi separate incaricate di svolgere questi
compiti. Una classe è stata denominata Loader, l’altra ha preso come nome Object.
La classe Loader presentata nel Capitolo 5 contiene un parser di file che si occupa
anche del riempimento delle strutture dati di una istanza della classe Object con ciò
che legge. Una volta terminata la scansione del file viene restituito all’applicazione
un puntatore a tale istanza e viene cancellato dalla memoria del loader qualsiasi
frammento di dato residuo.
La classe Object presentata nel Capitolo 7 contiene metodi per l’impostazione della
geometria e dei materiali. Al momento della creazione una sua istanza è difatti
vuota, ed è necessario inserirvi dati dall’esterno. Possiede anche dei metodi in
grado di configurare automaticamente gli stati ed invocare il motore di rendering
OpenGL, per agevolare la renderizzazione dei propri modelli. Gestisce infine anche
le informazioni sulla gerarchia ad albero della scena, memorizzando puntatori ai
propri figli e al proprio padre. Per risparmiare memoria è stata creata anche una
classe Group con un sottoinsieme delle funzionalità di Object. Un’istanza della
classe Group contiene infatti i dati riguardanti la gerarchia, ma è priva di geometria
e materiali. La classe Group è presentata nel Capitolo 6.

CAPITOLO 5
Il Loader
5.1 L’interfaccia e il runtime binding
In fase di progettazione si è deciso di creare innanzitutto una interfaccia generale
per rappresentare il generico loader. Si è inoltre fatto in modo che qualsiasi altro
loader più specialistico si debba attenere rigorosamente allo standard definito da
questa interfaccia. Tale scelta ha portato alla implementazione della classe astratta
Loader.
La classe Loader è composta da un unico metodo load file che riceve un nome di file
come input e restituisce al programma un puntatore ad un oggetto di tipo Group con-
tenente l’intero albero della scena importato da tale file. Essendo una classe astratta
non può essere istanziata. Inoltre il suo unico metodo deve essere obbligatoriamente
ridefinito da qualsiasi classe figlia.
Questo rappresenta tutto ciò che è necessario conoscere per utilizzare le specializ-
zazioni di questa classe: qualsiasi loader per un formato specifico è difatti gestibile
come se fosse un oggetto di tipo Loader, senza preoccuparsi che venga invocata di
volta in volta la procedura corretta.
Il trucco che permette questa semplificazione di utilizzo deriva direttamente dalle
potenzialità di un linguaggio orientato agli oggetti come il C++, che consente di
ottenere dei particolari comportamenti del programma senza troppi sforzi. Fra le
peculiarità del linguaggio c’è la possibilità di scegliere facilmente fra due modalità
di binding 1 :
1 Per binding si intende l’associare alla chiamata di una funzione la corrispondente locazione di
memoria contenente la routine da eseguire.
24

CAPITOLO 5. IL LOADER 25
• l’early binding, che avviene da parte del compilatore e del linker, semplicemente
salvando in fase di compilazione i nomi delle funzioni 2 e i relativi indirizzi di
memoria all’interno di una tabella e quindi sostituendo nel codice macchina le
chiamate di funzione con salti a quegli indirizzi 3 ;
• il late binding, detto anche runtime binding, che avviene in fase di esecuzione.
I linguaggi e i compilatori che lo supportano usano metodologie differenti per
implementarlo. I compilatori C++ di solito introducono automaticamente al-
l’interno delle classi un array di puntatori contenente gli indirizzi delle funzioni
che necessitano di late binding, e aggiungono anche istruzioni per istanziare
questo vettore correttamente in funzione della classe a cui appartiene.
Figura 5.1: Il late binding nella classe Loader
2 In realtà non vengono solitamente salvati i reali nomi, ma dei nomi simbolici. La funzione
int f(int a, char b) verrà salvata internamente da un compilatore C come f, mentre un compilatore
per C++ – linguaggio che supporta l’overloading delle funzioni, ovvero l’esistenza di più
funzioni con lo stesso nome ma parametri diversi – la salverà internamente come qualcosa di simile
a f int char.
3 Questa è ovviamente una semplificazione, poiché un salto di questo tipo non viene tradotto solamente
con una jmp ma deve essere necessariamente posto in una cornice di salvataggio e ripristino
del contesto.

CAPITOLO 5. IL LOADER 26
Il metodo load file è stato definito virtual, e questo fa sì che sia soggetto a late
binding, sia nella classe Loader che nelle classi che specializzino tale interfaccia, come
illustrato in Figura 5.1. Una di queste è la classe Loader3DS, realizzata all’interno
del lavoro di tesi per l’importazione dei modelli dal formato 3DS. [ECK98]
5.2 La struttura di un file 3DS
In Autodesk 3D Studio l’intera scena (che comprende modelli, luci e telecamere) è
gestita per mezzo di un unico grande albero. I file 3DS – nei quali viene esportata
tale scena – rispecchiano questa conformazione ad albero.
La particolarità del formato realmente utilizzato nell’esportazione è data dal fatto
che i dati siano presenti unicamente sulle foglie. Per questo motivo la struttura
dei file è composta da blocchi innestati, a partire dal blocco maggiore – grande
quanto il file e rappresentante la radice dell’albero – sino a giungere ai piccoli blocchi
contenenti le informazioni vere e proprie. Tutti questi blocchi sono solitamente
chiamati chunk 4 .
Figura 5.2: La struttura base di un file 3DS
I chunk sono suddivisi all’interno del file in due grandi categorie:
• i chunk che definiscono i modelli e le loro proprietà, denominati chunk dell’e-
ditor;
• i chunk che definiscono la posizione degli oggetti nello spazio (e nel tempo, nel
caso in cui sia presente all’interno del file anche un’animazione) e la gerarchia,
denominati chunk del keyframer.
4 Chunk indica in inglese un “grosso pezzo” (di legno, . . . ).

CAPITOLO 5. IL LOADER 27
La sezione dell’editor si suddivide a sua volta in due chunk minori, denominati
rispettivamente il chunk dei materiali e il chunk degli oggetti (contenente i modelli,
le luci e le telecamere).
I chunk saranno presentati più in dettaglio nell’Appendice A.
5.3 Il Loader 3DS
Da questa panoramica sulla struttura che il loader 5 dovrà caricare è facile intuire
che il parser sviluppato debba essere composto da procedure nidificate.
È stata così
implementata una serie di metodi specializzati in grado di scorrere il contenuto dei
chunk di propria competenza e:
• richiamare, per ogni sottoblocco individuato all’interno del proprio chunk, il
metodo opportuno;
• salvare i dati contenuti all’interno del proprio chunk in un buffer temporaneo
ed inviarli alla classe Object oppure Group a cui appartengono.
Il secondo punto introduce il concetto che ha avuto un ruolo fondamentale nella fase
di progettazione del loader: l’indipendenza del loader dalla semantica dei dati letti.
In base a questo principio ogni metodo del loader è a conoscenza della dimensione
e del formato in cui sono riposti i dati, nonché dell’identità dell’oggetto che dovrà
riceverli. Questo è tutto ciò che gli serve sapere per svolgere il proprio compito,
mentre altre classi (Group e Object, presentate nei Capitoli 6 e 7) sono preposte
all’utilizzo dei dati letti.
Questa, se non correttamente analizzata, può sembrare una estremizzazione del-
l’approccio orientato agli oggetti, con nefasti effetti su un aspetto più importante
all’interno di un programma di grafica in tempo reale quale la performance. Al
contrario un’implementazione di questo tipo consente:
• il riutilizzo del loader all’interno dello stesso programma per caricare poten-
zialmente un’infinità di modelli.
È quindi sufficiente istanziare una sola volta
5 D’ora in avanti ci si riferirà al “loader di file 3DS”, implementato nella classe Loader3DS,
semplicemente con il termine “loader”.

CAPITOLO 5. IL LOADER 28
ogni loader specifico, minimizzando lo spreco di risorse. Ogni qualvolta verrà
caricato un file, il loader restituirà una struttura opportuna contenente i mo-
delli importati e ripristinerà il proprio stato iniziale senza tener traccia di ciò
che è stato caricato in precedenza.
• l’indipendenza della gestione dei modelli dal caricamento che permette di dover
intervenire unicamente sulla classe del loader per caricare modelli da formati
differenti, senza dover modificare anche le classi addette alla memorizzazione e
utilizzo di geometria e materiali, che rimangono utilizzabili indipendentemente
dalla sorgente di importazione.
Questa suddivisione fra formato e semantica è spesso sottovalutata oppure ignorata
nei loader gratuiti, all’interno del cui codice sono difficilmente separabili le parti
dedicate al caricamento da quelle incaricate di gestire il rendering.
L’esecuzione del metodo load file della classe Loader3DS avviene in tre stadi suc-
cessivi: l’inizializzazione, il parsing del file e il postprocessing.
5.4 L’inizializzazione prima del parsing
Il codice eseguito dalla classe Loader3DS prima che venga invocato il parser è piutto-
sto elementare. Il lavoro necessario si limita infatti alla inizializzazione delle strut-
ture dati necessarie per contenere temporaneamente i vari dati che verranno poi
inviati ai vari oggetti, oppure utilizzati per gestire alcuni aspetti dell’elaborazione
seguente il parsing, fra cui ad esempio la creazione di un albero della gerarchia da
restituire al programma che ha richiesto il caricamento di un file, come spiegato in
5.6.
Viene innanzitutto istanziato un nuovo oggetto di tipo Group, a cui è assegnato come
nome quello del file che si sta caricando, per consentire allo sviluppatore che farà
uso della libreria di ritrovare rapidamente il modello desiderato fra i tanti caricati
da file differenti. Questo oggetto sarà utilizzato in seguito come radice dell’intera
gerarchia.
Si salva inoltre il percorso da cui si sta caricando il file, così da poter reperire i file
contenenti le texture anche per i modelli non collocati nella directory in cui è in
esecuzione il programma che utilizza il loader.

CAPITOLO 5. IL LOADER 29
Figura 5.3: Le tre fasi della procedura load file

CAPITOLO 5. IL LOADER 30
Sono infine resettati correttamente gli array e i contatori che serviranno al mante-
nimento temporaneo in memoria dei materiali, delle texture e degli oggetti caricati
dal file, in attesa della fase di postprocessing esplicata nella sezione 5.6 poco oltre
all’interno del capitolo.
5.5 Le tre fasi di parsing
Il parsing segue sequenzialmente i tre grandi blocchi dello standard 3DS già illustrati
nella Figura 5.2, inviando quanto più possibile direttamente agli oggetti proprietari
dei dati, ma mantenendo temporaneamente in memoria alcuni dati condivisi che –
se opportunamente utilizzati – consentono non solo un minor spreco di risorse ma
anche una migliore performance.
Per ulteriori informazioni più dettagliate concernenti tutti i dati caricati dai file 3DS
si rimanda all’Appendice A.
5.5.1 I materiali
Nella prima fase di parsing ci si occupa del chunk contenente un numero variabi-
le di materiali, ciascuno di essi contraddistinto da un nome unico all’interno del
file. Questo particolare è fondamentale per la successiva fase di riconoscimento e
assegnazione dei materiali corretti a ciascun oggetto.
Ogni materiale è definito da uno o più chunk maggiormente specializzati che si
occupano ciascuno di una particolare caratteristica.
I chunk del colore memorizzano le proprietà cromatiche del materiale, definendo
• il colore ambientale;
• il colore diffusivo;
• il colore speculare;
• il colore emissivo.
Sono quindi reperibili altre proprietà del materiale fra cui i suoi livelli di riflessività
(che influisce sulla quantità di colore speculare visibile) e di trasparenza (che definisce
l’opacità del materiale).
Sono infine presenti i chunk delle texture, che possono definire

CAPITOLO 5. IL LOADER 31
Figura 5.4: Le tre fasi di parsing

CAPITOLO 5. IL LOADER 32
Figura 5.5: La struttura di un materiale
• una texture diffusiva, utile per modulare non uniformemente il colore diffusivo;
• una mappa di riflessione d’ambiente, per simulare il riflesso dell’ambiente
circostante sull’oggetto;
• una texture speculare, utile per modulare non uniformemente il colore specu-
lare;
• una mappa di riflessività, per i materiali che non riflettono specularmente la
luce in maniera uniforme;
• una texture di colore emissivo, utile per modulare non uniformemente il colore
emissivo;
• una texture di bump mapping, per simulare i dislivelli e la rugosità dei mate-
riali come l’asfalto oppure un materiale con delle scanalature;
• una mappa di luminosità, per materiali sui quali non si applica l’illuminazione
in tempo reale ma una illuminazione precalcolata;
• una mappa di opacità, per materiali trasparenti in maniera non uniforme.
Tutte queste texture possono essere presenti al più una volta per ciascun materiale.
Le modalità con cui ciascuna di esse è utilizzata nella presente libreria sono chiarite
dettagliatamente in 7.2.

CAPITOLO 5. IL LOADER 33
Nessuno dei chunk citati è obbligatorio, e l’assenza di uno di essi comporta sempli-
cemente l’utilizzo di un valore di default per l’attributo corrispondente. Lo stesso
blocco dei materiali è facoltativo, in quanto a un modello non deve necessariamen-
te essere assegnato un materiale (in tal caso la presente libreria utilizza per tale
modello un materiale grigio di default).
L’intera fase può perciò non venire eseguita per taluni file.
5.5.2 Gli oggetti
Una volta caricati gli eventuali materiali si passa al parsing degli oggetti. Sono
possibili file 3DS senza alcun modello al proprio interno; in tal caso il loader non
eseguirà questa fase e restituirà una gerarchia vuota costituita dalla sola radice del-
l’albero, mantenendo la consistenza nel comportamento. Se – come è più probabile
che sia – vi fossero invece degli oggetti all’interno del file verrebbero importati i dati,
un oggetto alla volta.
Figura 5.6: La struttura di un oggetto
Per ciascun oggetto è obbligatoria la presenza di alcuni blocchi:
• il nome, fondamentale per individuarlo nella fase seguente quando sarà neces-
sario ricostruire l’albero della scena;
• i vertici, memorizzati come una lista di coordinate;
• le facce, rigorosamente triangolari, salvate nel file come triplette di indici.
Questi indici si riferiscono all’array di vertici caricato precedentemente;

CAPITOLO 5. IL LOADER 34
• il sistema di riferimento locale, ovvero il centro e gli assi del sistema di coor-
dinate locale dell’oggetto, spesso differente dal sistema di riferimento globale.
Questo insieme di dati consente di definire una semplice mesh di triangoli 6 senza
alcun materiale ma con una collocazione nell’ambiente virtuale.
Ulteriori dati facoltativi sono reperibili in questa sezione, fra cui il materiale asso-
ciato a ciascuna delle facce appartenenti all’oggetto e le coordinate delle texture per
ciascun vertice.
Per minimizzare lo spreco di memoria, e per evitare un flusso di dati troppo elevato
fra la RAM e la memoria della scheda video (che ridurrebbe notevolmente le pre-
stazioni), le texture vengono caricate una sola volta e condivise fra tutti gli oggetti
che ne fanno uso.
5.5.3 La gerarchia
Le ultime informazioni reperibili all’interno del file sono quelle riguardanti la gerar-
chia. Gli oggetti finora importati sono stati memorizzati in un array in attesa che
venga ricreata la struttura ad albero che c’era al momento in cui furono esportati
da 3DStudio.
Gli oggetti sono individuati all’interno dell’array grazie al proprio nome. Ciascun
nodo dell’albero della gerarchia presente in questo chunk deve obbligatoriamente
aver definiti in questa sezione i seguenti dati:
• un numero identificativo unico all’interno del file, utilizzato dai figli per indi-
viduarlo come proprio padre;
• il numero identificativo del proprio padre;
• le tre trasformazioni geometriche che influiscono sull’oggetto (e sui suoi figli):
la traslazione, la rotazione su un’asse arbitrario, il ridimensionamento sui tre
assi (non necessariamente uniforme).
In questa fase vengono anche introdotte le entità che giustificano la presenza del-
la classe Group, ovvero i gruppi. I gruppi non compaiono nella fase di parsing
6 Triangle mesh (maglia di triangoli) è un termine comunemente utilizzato per identificare un modello
complesso formato dall’unione di più triangoli.

CAPITOLO 5. IL LOADER 35
Figura 5.7: La struttura di un nodo della gerarchia
degli oggetti e perciò non contengono né geometria né materiali. Essi sono nodi
contraddistinti da un nome particolare 7 e utilizzati per:
• raggruppare oggetti e altri gruppi, in base a un criterio di composizione pratico
in caso di modelli complessi definibili tramite sottoparti più semplici;
• applicare le proprie trasformazioni a tutti i figli.
Una volta introdotti anche i gruppi nell’array degli oggetti il lavoro di ricreazione
dell’albero della scena è elementare. È infatti sufficiente scorrere il vettore, un
elemento alla volta, leggere il numero identificativo dei padri, reperirli e aggiungervi
come figli gli elementi individuati come tali.
5.6 Il postprocessing
Una volta ottenuta la gerarchia completa del modello importato dal file si esegue
la precomputazione di tutte le trasformazioni, nodo per nodo. Questo è opportuno
7 Nel blocco del nome è infatti presente la stringa $$$DUMMY, mentre il reale nome del gruppo si
trova in un successivo blocco dedicato (cfr. Appendice A).

CAPITOLO 5. IL LOADER 36
per limitare le operazioni da eseguire su ogni vertice in tempo reale, migliorando
notevolmente le prestazioni in fase di rendering.
Ciò non preclude comunque la possibilità di utilizzare trasformazioni geometriche
in tempo reale, come verrà spiegato nella sezione 6.5, ma elimina il sovraccarico
computazionale non necessario in realtime in quanto generato da oggetti statici, sui
quali cioè non influiscono trasformazioni geometriche variabili nel tempo.
I vertici all’interno di un file 3DS sono solitamente memorizzati già trasformati, ma
non sempre nella maniera corretta. Solo dopo un’attenta analisi del contenuto di
vari file si è giunti a capire il problema dell’errata memorizzazione dei vertici, che si
è rivelata avvenire nel caso in cui la terna di assi del sistema di riferimento locale
dell’oggetto non sia identica a quella del sistema di riferimento globale.
È stato quindi necessario sviluppare due metodi: uno per trasportare correttamente
i vertici dal sistema locale al sistema globale eliminando gli errori e uno per trasfor-
marli in base ai dati caricati dal file nella terza fase del parsing. Tradurre questo
in codice non si è rivelato però sufficiente, in quanto si è notato che gli errori si
tramandano di figlio in figlio sino alle foglie dell’albero della scena. Lo stesso vale
anche per le trasformazioni geometriche corrette, che sono da applicare all’intero
sottoalbero avente come radice l’oggetto a cui si riferiscono.
5.6.1 La correzione degli errori
La corretta metodologia per eliminare gli errori consiste nel calcolare la trasforma-
zione che, applicata al sistema di riferimento locale dell’oggetto, lo trasformi nel
sistema di riferimento globale. A questo punto è sufficiente applicarla all’oggetto e
a tutti i suoi figli, e infine per ciascun figlio eseguire lo stesso algoritmo dall’inizio,
effettuando in pratica una sorta di scansione in pre-order 8 dell’albero, poiché gli
errori del nodo padre vengono corretti prima di quelli relativi ai suoi sottoalberi. Se
8Esistono tre modalità di scansione di un albero binario: pre-order (per ciascun nodo viene prima
scandito il nodo stesso, quindi il sottoalbero sinistro e quello destro), in-order (viene scandito il
sottoalbero sinistro, poi il nodo stesso e infine il sottoalbero destro) e post-order (vengono scanditi
i due sottoalberi e infine il nodo stesso). I nostri non sono necessariamente alberi binari, per cui
questa terminologia non è totalmente corretta. È stata tuttavia utilizzata perché si ritiene che
renda bene l’idea di come operi l’algoritmo. [SED93]

CAPITOLO 5. IL LOADER 37
si parte dalla radice, al termine della computazione l’intera scena sarà correttamente
preparata per la successiva applicazione delle trasformazioni importate dal file.
Per il calcolo delle matrici si adopera un metodo diverso da quello spiegato, in quanto
in realtà si utilizza l’inversa della matrice che trasforma il sistema di riferimento
globale in quello locale. Supponendo che il sistema di riferimento locale, con i tre
assi normalizzati, sia
<
⎛
⎜
⎝
xx
xy
xz
⎞
⎛
⎟ ⎜
⎠ , ⎝
yx
yy
zz
⎞
⎛
⎟ ⎜
⎠ , ⎝
e rammentando che quello globale è semplicemente
0
0
1
zx
zy
zz
⎞
⎟
⎠ >
⎛ ⎞ ⎛ ⎞ ⎛ ⎞
1 0 0
⎜ ⎟ ⎜ ⎟ ⎜ ⎟
< ⎝ 0 ⎠ , ⎝ 1 ⎠ , ⎝ 0 ⎠ >
è elementare calcolare (passando alle coordinate omogenee9 ) la matrice
⎛
⎞
⎜
M = ⎜
⎝
xx yx zx 0
xy yy zy 0
xz yz zz 0
0 0 0 1
tale che ⎛
⎞
xx
⎜ xy ⎜
⎝ xz
yx
yy
yz
zx
zy
zz
0
⎟
0 ⎟
0
⎟
⎠
0 0 0 1
×
⎛ ⎞
1
⎜ ⎟
⎜
0 ⎟
⎜
⎝ 0
⎟
⎠
0
=
⎛
⎜
⎝
⎛
⎞
xx
⎜ xy ⎜
⎝ xz
yx
yy
yz
zx
zy
zz
0
⎟
0 ⎟
0
⎟
⎠
0 0 0 1
×
⎛ ⎞
0
⎜ ⎟
⎜
1 ⎟
⎜
⎝ 0
⎟
⎠
0
=
⎛
⎜
⎝
9 Le coordinate tridimensionali omogenee sono nella forma (x, y, z, w) T . La quarta coordinata è
utile per vari scopi; agevola ad esempio la proiezione e consente di applicare ridimensionamenti e
traslazioni per mezzo di matrici. [MOR89]
⎟
⎠
xx
xy
xz
0
yx
yy
yz
0
⎞
⎟
⎠
⎞
⎟
⎠

CAPITOLO 5. IL LOADER 38
⎛
⎞
xx
⎜ xy ⎜
⎝ xz
yx
yy
yz
zx
zy
zz
0
⎟
0 ⎟
0
⎟
⎠
0 0 0 1
×
⎛ ⎞
0
⎜ ⎟
⎜
0 ⎟
⎜
⎝ 1
⎟
⎠
0
=
⎛
⎜
⎝
Per la sua inversione è infine sufficiente applicare il metodo del determinante, otte-
nendo la matrice associata alla trasformazione desiderata, che è
M −1 ⎛
⎞
det00/D
⎜
= ⎜
−det01/D
⎜
⎝ det02/D
−det10/D
det11/D
−det12/D
det20/D
−det21/D
det22/D
−det30/D
⎟
det31/D ⎟
−det32/D
⎟
⎠
−det03/D det13/D −det23/D det33/D
dove i detij sono i determinanti delle sottomatrici 3 × 3 ottenute togliendo da M la
riga i e la colonna j, mentre D è il determinante della matrice M. [ABA96]
Se per un nodo si ha che Mp è la matrice per la correzione degli errori del padre,
e Mf è quella atta a correggere gli errori del nodo stesso, su tale nodo Mp verrà
applicata prima di Mf. Nulla ovviamente impedisce il fatto che Mp sia a sua volta
una matrice ottenuta per composizione di due o più altre matrici.
5.6.2 L’applicazione delle trasformazioni geometriche
Al termine dell’operazione di correzione degli errori è possibile applicare le tra-
sformazioni geometriche (traslazione, rotazione e ridimensionamento) corrette, che
sono state importate e memorizzate temporaneamente nella terza fase di parsing.
Per simmetria con la sezione precedente questa operazione deve essere effettuata
tramite una specie di scansione in post-order 10 sull’albero.
Il ridimensionamento è applicato per primo, quindi avviene la rotazione su un asse
arbitrario ed infine la traslazione.
Per la rotazione sono stati utilizzati i quaternioni, vettori quadridimensionali compo-
sti da uno scalare e da un vettore tridimensionale che sono in grado di rappresentare
un angolo di rotazione e l’asse su cui deve avvenire tale rotazione. Dato l’angolo θ
e l’asse normalizzato (ax, ay, az) T è difatti possibile definire i due quaternioni
10 Cfr. nota a piè di pagina 8.
zx
zy
zz
0
⎞
⎟
⎠
q = (cos θ
2 , [ax · sin θ
2 , ay · sin θ
2 , az · sin θ
2 ])

CAPITOLO 5. IL LOADER 39
q ′ = (cos θ
2 , [ax · (− sin θ
2 ), ay · (− sin θ
2 ), az · (− sin θ
2 )])
e rappresentare il punto (x, y, z) T da ruotare con la notazione
per poter ottenere il punto ruotato
p = (0, [x, y, z])
p ′ = qpq ′ = (0, [x ′ , y ′ , z ′ ]) = (x ′ , y ′ , z ′ ) T
Si rimanda all’Appendice F per chiarimenti riguardanti la modalità di esecuzione
della rotazione tramite quaternioni. [KDL98]
Il ridimensionamento consiste in una moltiplicazione delle tre coordinate del punto
(x, y, z) T per il coefficiente corrispondente preso dal vettore (sx, sy, sz) T , portando a
(x ′ , y ′ , z ′ ) T = (sx · x, sy · y, sz · z) T
L’applicazione della traslazione è una semplice somma del punto (x, y, z) T con il
vettore dello spostamento (tx, ty, tz) T , da cui si ottiene il nuovo punto
(x ′ , y ′ , z ′ ) T = (x + tx, y + ty, z + tz) T
Tutte queste trasformazioni sono applicate in maniera inversa rispetto a quelle della
fase precedente, per cui se per un nodo P si ha che la matrice Tp è associata alle
trasformazioni del padre e la matrice Tf è associata a quelle del nodo stesso, verrà
applicata al nodo prima Tf e poi Tp. Anche in questo caso nulla impedisce a Tp di
essere a sua volta una composizione di due o più matrici associate a trasformazioni.
5.6.3 La collocazione di queste operazioni
Queste procedure di postprocessing sono effettivamente un ibrido intermedio fra
l’importazione dal formato 3DS e la gestione dei dati, e risultano perciò una parzia-
le violazione al principio di separazione fra formato e semantica. Tuttavia introdurle
all’interno di Group e Object anziché in Loader3DS sarebbe stato ugualmente errato,
in quanto avrebbe introdotto conoscenze sul formato di provenienza all’interno delle
due classi designate a gestire unicamente la semantica. Per motivi di ottimizzazione
dell’utilizzo della memoria – in quanto l’eliminazione degli errori e l’applicazione del-
le trasformazioni avvengono unicamente in fase di loading del file – le due procedure
sono perciò state introdotte nella classe Loader3DS.

CAPITOLO 6
La gestione della gerarchia
6.1 Le funzionalità per l’utilizzo della gerarchia
3DStudio mantiene in memoria un albero contenente la gerarchia dell’intera scena,
e la esporta nei suoi file 3DS. Tale gerarchia viene importata dal loader 3DS e ri-
creata grazie ai metodi implementati all’interno delle classi Group e Object, ovvero
quelli per l’aggiunta e la rimozione dei figli e per la modifica del padre di un nodo.
È quindi possibile gestire la gerarchia utilizzando gli stessi metodi sopracitati per
modificare, unire e dividere a piacimento gli alberi; sono inoltre stati implementati
ulteriori metodi per invocare il rendering dell’intero albero, per applicare trasfor-
mazioni geometriche in tempo reale sui vari nodi e per ordinare gli stessi nodi in
base alla loro distanza dal punto di vista. Tutto questo sarà analizzato in maniera
dettagliata nel corso del capitolo.
Viene utilizzato anche per la gestione della gerarchia il runtime binding 1 . Entram-
be le classi mantengono i collegamenti con il padre e i figli tramite puntatori a
Group, indipendentemente dalla reale istanziazione (Group o Object) di tali nodi;
l’esecuzione del metodo corretto è di volta in volta assicurata dal binding in fase di
esecuzione.
Le classi Object e Group sono state create con lo scopo di gestire la gerarchia dei
modelli e favorire la renderizzazione dell’intero albero di oggetti per mezzo di sem-
plici chiamate a metodi. Le funzionalità implementate fanno in gran parte uso di
procedure a cascata che, a partire dal nodo su cui sono state invocate, si diramano
su tutti i figli e giungono sino alle foglie del sottoalbero.
1 Cfr. 5.1 a pagina 24.
40

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 41
La classe Group sviluppa un oggetto che può fungere da nodo attivo dell’albero, in
quanto al suo interno sono implementati tutti i principali metodi per l’utilizzo di
una struttura di questo tipo, primi fra i quali quelli per aggiungere e rimuovere i
figli e per impostare il padre. Sono inoltre presenti funzionalità più avanzate quali
il culling e l’ordinamento dei nodi figli in base alla loro distanza dal punto di vista,
molto utili in fase di rendering. La classe Object estende Group, e possiede perciò
anche tutti i metodi della classe padre.
6.2 L’importanza di una gerarchia
Come accennato parte delle funzionalità implementate sono dedicate alla creazione
ed alla gestione della gerarchia. Lo scopo principale di tali funzionalità è permet-
tere una ricostruzione fedele della gerarchia presente nei file 3DS da essi importata
per mezzo del loader. La memorizzazione della gerarchia direttamente all’interno
dei nodi consente però delle possibilità che non si limitano alla creazione di una
mera copia statica del contenuto dei file 3DS. Tramite i metodi per l’aggiunta e la
rimozione dei figli e per la reimpostazione del padre è possibile infatti modificare
la gerarchia a proprio piacimento in tempo reale. Questo approccio modulare in
cui ciascun nodo è conscio della propria posizione all’interno dell’albero gerarchico
permette, tramite i sopracitati metodi, di avere fra le mani un vero e proprio editor
della gerarchia utilizzabile in realtime all’interno degli applicativi.
Ma perché è importante una gerarchia? La risposta è semplice. Perché all’interno
di un albero gerarchico si possono effettuare interventi al livello di specializzazione
desiderato, lavorando mentalmente come facciamo nel mondo reale. Siamo soliti
difatti pensare agli oggetti nel loro complesso, salvo poi scendere ad un maggiore
livello di particolarizzazione per motivi di precisione. È sufficiente pensare alla
differenza fra un automobile dal punto di vista di un automobilista medio e dal punto
di vista di un meccanico che deve effettuare una riparazione. Grazie alla gerarchia
in un programma possiamo applicare una trasformazione geometrica all’automobile
intera (per muoverla come farebbe l’automobilista medio) e possiamo sostituire un
nodo del sottoalbero avente come radice la stessa automobile (per effettuare una
riparazione come farebbe il meccanico).
La gerarchia ha quindi un duplice compito:

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 42
Figura 6.1: Le trasformazioni geometriche su un nodo si diffondono sul suo sottoalbero
• facilita la comprensibilità della scena rappresentandola come un’albero nel
quale il livello di specializzazione cresce man mano che si discende verso le
foglie;
• implementa una struttura a nodi utile per la rappresentazione di un sistema
cinematico con vincoli, come quello presente nei file 3DS, ovvero un sistema
nel quale sono presenti trasformazioni geometriche definite su un nodo ma che
influiscono sull’intero sottoalbero avente tale nodo come radice, come nel caso
del braccio in Figura 6.1.
Per soddisfare tali scopi sono state progettate e realizzate le funzionalità della classe
Group. La gerarchia implementata è mantenuta dagli stessi nodi per mezzo di
puntatori al padre ed ai figli. Grazie a questa stuttura modulare è quindi facile –
tramite i già citati metodi per l’aggiunta e la rimozione dei figli e per l’impostazione
del padre – unire fra loro vari alberi importati da file differenti. Può ad esempio
essere pratico utilizzare nei programmi un gruppo globale nel quale inserire come
figli tutti i modelli 3D caricati di volta in volta da vari file 3DS. Potrebbe anche

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 43
essere altrettanto utile caricare un’automobile da un file separato e aggiungerla
come oggetto figlio all’interno di un modello di una città complessa; sarebbe in
tal caso elementare variare il modello dell’automobile mantenendo intatta la città
circostante, come mostrato in Figura 6.2.
Per mezzo dei citati metodi è possibile anche la creazione di grafi, ma l’utilizzo di tale
funzionalità è deprecato in quanto induce problemi di loop infinito nell’esecuzione
degli algoritmi a cascata. Non viene effettuato automaticamente un controllo sulla
presenza di cicli – ma si pone tale verifica a carico dell’utente – per ovvi motivi di
performance.
Grazie alle funzionalità riguardanti la gerarchia è stato infine possibile implementare
una serie di metodi orientati agli interi sottoalberi aventi come radice il nodo su cui
vengono invocati. Essi consentono l’applicazione e la modifica in tempo reale delle
trasformazioni geometriche (cfr. 6.5), il culling a più livelli di profondità (cfr. 6.4),
molto performante soprattutto nel caso di oggetti dettagliati ovvero con molti vertici
piuttosto vicini fra loro, e l’ordinamento di tutti i nodi figli in funzione della loro
distanza dal punto di vista (cfr. 6.6).
6.3 Bounding box e centro di un oggetto
Appoggiandosi sulla gerarchia sono state implementate delle funzionalità per calco-
lare e mantenere in memoria anche una rappresentazione semplificata dei vari nodi,
ovvero la bounding box e il centro di ciascuno di essi. Entrambi i dati sono parti-
colarmente importanti sia per il culling (presentato in 6.4), che viene eseguito sulle
bounding box, sia per le trasformazioni in tempo reale (cfr. 6.5) e l’ordinamento dei
nodi (cfr. 6.6) in base alla loro distanza dal punto di vista, che fanno uso del centro.
Per bounding box di un oggetto si intende il più piccolo parallelepipedo contenente
tutti i suoi vertici. Sono tuttavia spesso utilizzati (e denominati ugualmente boun-
ding box) dei parallelepipedi non minimi ma rispettanti la proprietà di contenenza
e caratterizzati da una più rapida calcolabilità.
Nel caso di questa libreria, appunto per motivi di velocità computazionale, l’algo-
ritmo sviluppato non calcola il parallelepipedo più piccolo fra tutti, ma solamente
il minore in volume fra quelli aventi i lati paralleli ai tre assi (cfr. Figura 6.3).
La creazione di una bounding box si riduce quindi alla estrazione fra tutti i vertici

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 44
Figura 6.2: Con una semplice operazione logica si può sostituire l’oggetto Automobile 1
con l’oggetto Automobile 2 lasciando invariato il resto della gerarchia

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 45
Figura 6.3: Bounding box minima (in grigio) e di rapida computazione (in nero)
dell’oggetto dei valori minimi e massimi sulle tre coordinate; dati questi sei valori è
elementare ricreare il parallelepipedo.
Extract Min(Array[0..n-1]):
1: Minimo = Array[0]
2: for i from 1 to n - 1 do
3: if Array[i] < Minimo then Minimo = Array[i] endif
4: endfor
Tabella 6.1: Estrazione del minimo
Trattandosi di un semplice algoritmo di estrazione di minimi e massimi (analogo a
quello nella Tabella 6.1), si può notare facilmente come esso sia linearmente dipen-
dente dal numero di elementi nell’array, che nel caso della bounding box equivale
al numero di vertici presenti nell’oggetto. Essendo il sovraccarico computazionale
per la generazione degli otto vertici del parallelepipedo (dati i tre minimi ed i tre
massimi) di peso costante, si può dire che la complessità dell’algoritmo per calcolare

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 46
la bounding box di un oggetto sia
O(6n) + O(c) = O(6n) = O(n) (6.1)
dove n è il numero dei vertici e c è la costante per la computazione del parallelepipedo
dati i minimi e i massimi. La complessità dell’algoritmo per estrarre la bounding
box di un oggetto dipende quindi linearmente dalla quantità di vertici nel modello.
Nella realtà della gerarchia però non è sufficiente operare solo in funzione dei vertici
in quanto la bounding box di un nodo contiene non solo tutti i vertici del nodo
ma anche tutte le bounding box dei figli. L’algoritmo diventa perciò quello esposto
tramite pseudocodice nella Tabella 6.2.
Calculate Bounding Box:
1: scorri tutti i vertici ed estrai i valori minimi e massimi delle coordinate
2: for i from 0 to numero di figli diretti - 1 do
3: figli diretti[i].Calculate Bounding Box
4: endfor
5: for i from 0 to numero di figli diretti - 1 do
6: if un valore di figli[i].BoundingBox > un massimo then
7: salvo il valore aggiornato del massimo
8: endif
9: if un valore di figli[i].BoundingBox < un minimo then
10: salvo il valore aggiornato del minimo
11: endif
12: endfor
13: calcolo gli otto vertici del parallelepipedo
Tabella 6.2: Calcolo della bounding box per ogni nodo
Si può dimostrare che l’esecuzione di questo algoritmo sulla radice di un albero
corrisponde all’esecuzione del metodo Calculate Bounding Box esclusa la chiamata
a cascata sui figli una ed una sola volta su ciascun nodo del suo sottoalbero. Questo
equivale a dimostrare che il ciclo delle righe 2-4 causa una scansione dell’albero,
sulla cui radice è stata invocata Calculate Bounding Box, di complessità lineare sul
numero dei nodi contenuti in tale albero.
Ricordando che ci troviamo in presenza di un albero con radice, si ha per costru-
zione un orientamento degli archi dalla radice alle foglie. Ogni nodo dell’albero ha

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 47
quindi un solo arco entrante proveniente dal padre (ad eccezione della radice, che
non ha padre) e un numero di archi uscenti pari a quello dei suoi figli (1). La chia-
mata da parte dell’utente del metodo Calculate Bounding Box avviene, sempre per
costruzione, una sola volta sulla radice dell’albero (2).
Supponiamo ora che il metodo venga eseguito più di una volta su un generico nodo x.
Definendo come p la funzione “padre di” si può notare come Calculate Bounding Box
venga invocata nello pseudocodice delle righe 2-4 su ciascun nodo n solamente dal pa-
dre, ovvero dal nodo p(n), ad eccezione della radice sulla quale è invocata dall’utente
della libreria.
Se x è la radice si giunge subito ad un assurdo, in quanto Calculate Bounding Box
non può essere stata invocata dal nodo padre di x (non esiste per (1)). Essa è perciò
stata invocata più di una volta dall’utente, il che contraddice (2).
Se invece x non è la radice, su di esso la procedura è invocata per la prima volta da
p1 = p(x), quindi una seconda volta da p2 = p(x), e così via. Le possibilità sono ora
tre:
• p1 �= p2, perciò il nodo x ha due archi entranti, il che è assurdo perché viola
(1);
• p1 = p2 ed è la radice dell’albero; è un assurdo che Calculate Bounding Box
venga eseguita due volte sulla radice, in quanto in tal caso l’utente avrebbe
invocato due volte tale metodo (la radice non ha un nodo padre per (1)).
Questo viola (2);
• p1 = p2 e non è la radice; in tal caso si risale l’albero applicando la presente
dimostrazione al nodo p1, finché non si giunge ad uno dei due precedenti
assurdi.
Si è quindi dimostrato che la procedura Calculate Bounding Box venga eseguita al
più una volta su ciascun nodo dell’albero.
Siccome un albero è per definizione un grafo connesso, ovvero un grafo nel quale
esiste un percorso fra qualsiasi coppia di nodi a lui appartenenti, per ciascun nodo
nell’albero della gerarchia esiste un percorso dalla radice ad esso [CLR98]. Questo
implica che per ogni nodo x si abbia che radice = p(p(· · · p(x) · · ·)). Il nodo generico

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 48
x sarà perciò raggiunto sempre dalla chiamata a cascata di Calculate Bounding Box,
tramite il cammino dato appunto da radice = p(p(· · · p(x) · · ·)).
Questo e la dimostrazione precedente assicurano che su ciascun nodo dell’albero
Calculate Bounding Box sia eseguito una e una sola volta. Ciò significa che la chia-
mata a cascata all’interno di Calculate Bounding Box esegue una scansione lineare
dell’albero venendo eseguita esattamente una volta su ogni nodo.
Analizziamo ora la complessità delle rimanenti righe dello pseudocodice:
• la complessità di esecuzione della riga 1 è
O(n) (6.2)
dove n è il numero di vertici del nodo su cui stiamo eseguendo il metodo;
questo poiché si tratta di una estrazione di tre minimi e tre massimi, ovvero
una semplice scansione lineare di tutti i vertici, come chiarito nell’equazione
6.1;
• la complessità del ciclo delle righe 5-12 è
m�
(O(k)) (6.3)
i=1
con m numero di figli del nodo e k costante, poiché le istruzioni eseguite nelle
righe 6-7 e 9-10 prendono tempo costante O(k) ma vengono iterate una volta
per ciascun figlio;
• la complessità dell’ultima riga è
O(c) (6.4)
con c costante, poiché il calcolo di otto vertici dati i tre minimi e i tre massimi
è un’operazione dal numero di istruzioni fisso.
Da 6.2, 6.3 e 6.4 si può derivare come sommatoria la complessità dell’algoritmo
eseguito su un generico nodo x, che è
mx �
O(nx) + (O(k)) + O(c) (6.5)
i=1

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 49
ove nx è il numero di vertici presenti in x, mx è il numero dei suoi figli, e O(k) è il
tempo costante impiegato per il confronto fra i valori della bounding box del figlio i-
esimo e i minimi e massimi correntemente memorizzati. O(c) è l’usuale sovraccarico
computazionale per la creazione dei vertici del parallelepipedo. Si noti però come
mx �
i=1
(O(k)) =
mx volte
� �� �
O(k) + · · · + O(k) = O(k · mx) = O(mx) (6.6)
in quanto k è costante. Anche c è costante, perciò O(c) è un termine eliminabile.
Applicando un’ulteriore sommatoria per ottenere la complessità dell’esecuzione del-
l’algoritmo su tutti i nodi del sottoalbero otteniamo
M�
(O(nj) + O(mj)) (6.7)
j=1
dove nj è il numero di vertici nel nodo j-esimo, e mj il numero dei suoi figli e M
il numero totale di nodi presenti nell’albero. Da questa sommatoria, rammentando
che in un albero ciascun nodo ha uno ed un solo padre (ad eccezione della radice
che non ha padre) e perciò la somma del numero di figli di tutti i nodi equivale al
numero totale di nodi nell’albero meno la radice, si giunge alla complessità
O(N) + O(M − 1) = O(N) + O(M) = O(N + M) (6.8)
con N numero totale di vertici nell’albero e M numero di nodi nell’albero.
La complessità dell’algoritmo per il calcolo delle bounding box dell’intera gerarchia
è quindi linearmente dipendente sia dal numero di vertici che dal numero di nodi
presenti nell’albero.
Un ulteriore elemento utile per la rappresentazione semplificata dell’oggetto è il suo
centro. Sono state implementate due modalità di definizione del centro di un nodo.
La prima consiste semplicemente in un inserimento manuale delle tre coordinate del
punto tramite metodi adibiti a tale scopo. La seconda invece consente di calcolarlo
automaticamente per mezzo di una media fra i punti della bounding box. In tal
caso il centro viene quindi definito come
P0 + P1 + P2 + P3 + P4 + P5 + P6 + P7
8

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 50
dove gli otto vertici della bounding box sono i Pi (con i = 0 . . . 7).
Sul centro e sulla bounding box di un oggetto si basano alcune funzionalità imple-
mentate nella presente libreria, ovvero il culling, le trasformazioni geometriche in
tempo reale e l’ordinamento dei figli. Queste funzionalità saranno presentate una ad
una nel corso del capitolo.
6.4 Il culling
Il volume di spazio visibile dall’utente, denominato frustum 2 di vista, è definito per
mezzo di sei piani:
• near e far, che sono collocati di fronte all’utente e costituiscono rispettivamente
il minimo e il massimo fra le distanze visibili da esso (cfr. Figura 6.4);
• left, right, top e bottom, che limitano la visibilità dello spazio a sinistra, destra,
sopra e sotto all’utente.
Solamente la porzione di geometria collocata internamente al frustum è visibile, e
perciò solo essa è presente nel prodotto finale della fase di rendering, ovvero il fra-
me.
È detto culling (in inglese significa selezione) il procedimento in base al quale
vengono eliminate porzioni di scena totalmente esterne al frustum di vista prima che
giungano al termine della pipeline grafica, come spiegato poco più avanti. Grazie al
culling si evita l’inutile sovraccarico computazionale causato dal passaggio di questa
geometria nella pipeline grafica in quanto verrebbe comunque successivamente scar-
tata; così facendo si alleggerisce molto il processo di rendering quando l’ambiente
virtuale è articolato e perciò non tutti gli oggetti sono sempre visibili.
Siccome in generale le applicazioni che faranno uso della presente libreria necessi-
teranno di molti file 3DS si è posto il problema della troppo elevata complessità di
rendering. Si è perciò ritenuto opportuno che fosse sviluppata la funzionalità del
culling.
È stato perciò implementato un algoritmo di culling sulle bounding box,
fondato sulla proprietà che esse hanno di contenere l’intero sottoalbero sulla cui
radice sono definite. Il culling è attivabile e disattivabile in tempo reale tramite un
apposito parametro del metodo della libreria che invoca il rendering OpenGL.
2 Frustum significa “tronco di solido”, in questo caso di piramide.

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 51
Figura 6.4: Il culling scarta la porzione di scena che non cade all’interno del campo di
vista. La parte di scena non scartata è stata scurita
In questa sezione verranno presentati e messi a confronto il culling per poligono a
basso livello, implementato da OpenGL, e il culling per oggetto operante ad un più
alto livello di astrazione, che è stato implementato all’interno di questo lavoro di
tesi. Verranno in particolar modo sottolineati i miglioramenti di performance che il
culling per oggetto introduce nel rendering.
Il culling OpenGL è collocato in una fase già avanzata della pipeline grafica. Riferen-
doci all’immagine 6.5 possiamo osservare in alto il percorso compiuto da un vertice
(proveniente dal disco Vertex Data) prima di giungere alla rasterizzazione (Rasteri-
zation). Ignorando i Valutatori (Evaluators) – che vengono utilizzati solo qualora
il vertice sia stato definito matematicamente (ad esempio in una spline) – il primo
passaggio fondamentale compiuto è denominato Operazioni per vertice e assemblag-
gio delle primitive. Nel caso della presente libreria le primitive sono unicamente
triangoli, come detto nella sezione 5.5.2.
Il culling OpenGL avviene proprio in questa fase, fra le operazioni sui vertici e la
ricostruzione dei poligoni poiché
• è effettuato sia sui vertici (che vengono scartati oppure no), sia sui poligoni, che

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 52
Figura 6.5: La pipeline grafica OpenGL. Informazioni geometriche (Vertex data) e informazioni
raster (Pixel data) dopo varie operazioni computazionalmente costose convergono
a formare il frame che verrà visualizzato (contenuto nel Framebuffer)
possono venire scartati, mantenuti interamente, oppure parzialmente tagliati;
tagliare un poligono significa eliminare alcuni vertici e introdurne di nuovi,
con le relative modifiche sui lati (cfr. Figura 6.6);
• è in questo momento che i vertici sono in funzione del Clipping Coordinate
System (Sistema di coordinate di clipping), un particolare sistema nel quale
il campo di vista viene trasformato in un parallelepipedo e il procedimento di
culling risulta molto più facile che in precedenza poiché non deve più essere
eseguito su un frustum, come chiarito poco più avanti.
Prima di giungere a questo stadio ciascun vertice è stato infatti modificato da:
• la trasformazione del modello, che porta ogni vertice dalle proprie coordina-
te locali alle coordinate globali del mondo; serve per posizionare gli oggetti
all’interno del mondo;
• la trasformazione della vista, che porta ogni vertice dalle coordinate del mon-
do alle coordinate della vista; solitamente serve a trasformare il punto di vista

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 53
Figura 6.6: Culling di punti e di poligoni: P0 viene mantenuto, P1 è scartato. T0 è
mantenuto interamente, T1 solo parzialmente, T2 è scartato (in grigio le parti mantenute)
nell’origine e ad orientare la direzione dello sguardo su uno degli assi del si-
stema di riferimento. In questo modo si può operare nelle fasi successive in
maniera indipendente dalla posizione del punto di vista, poiché dopo questa
trasformazione esso si trova sempre in un punto di default;
• la trasformazione della proiezione, che porta ogni vertice dalle coordinate della
vista al sistema di coordinate di clipping (Clipping Coordinate System); con
questa trasformazione il frustum di vista diventa un parallelepipedo con i lati
paralleli ai tre assi del sistema di riferimento globale (cfr. Figura 6.8). Un
parallelepipedo con i lati paralleli agli assi definisce degli intervalli su tali
assi poiché i sei piani che lo formano sono definiti come x = xmin e x =
xmax, y = ymin e y = ymax, z = zmin e z = zmax, come illustrato nella
Figura 6.7. Per verificare se un punto sia all’interno oppure all’esterno di
un frustum è necessario comparare la sua posizione con tutti i sei piani che
identificano il frustum, se al posto di un frustum si ha un parallelepipedo
con i lati paralleli agli assi è sufficiente analizzare se le tre coordinate del
punto si trovino all’interno degli intervalli definiti dai piani che formano tale
parallelepipedo.

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 54
Figura 6.7: Un parallelepipedo con i lati paralleli ai tre assi definisce su ciascun asse un
intervallo
Figura 6.8: Trasformazione da coordinate della vista a Clipping Coordinate

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 55
Ciò significa che, prima che un modello interamente esterno alla scena venga scar-
tato, sarà necessario che tutti i suoi vertici vengano moltiplicati – uno ad uno –
perlomeno per le matrici associate alle trasformazioni sopracitate. Queste compu-
tazioni sono completamente inutili, in quanto avvengono su vertici che non sono
visibili. Le bounding box forniscono un semplice metodo per limitare questi calcoli
superflui.
È infatti sufficiente eseguire tali trasformazioni solamente sugli otto vertici del pa-
rallelepipedo, poiché se esso non è nel frustum della vista non lo sarà neppure il
modello in esso contenuto. Se invece la bounding box è parzialmente o totalmente
all’interno della scena visibile, il contenuto del nodo verrà inviato al motore di ren-
dering e il culling verrà riproposto sui figli, in quanto anche essi sono provvisti di
una propria bounding box minore o uguale rispetto a quella del nodo padre.
Il sovraccarico introdotto da questa procedura è variabile. Se il modello è un sem-
plice cubo all’interno del campo visivo, le trasformazioni fino al Clipping Coordinate
System avranno durata doppia in quanto saranno effettuate due volte, la prima vol-
ta sulla bounding box e la seconda sui vertici del cubo. Quando – come accade
solitamente in ambienti immersivi di realtà virtuale – i modelli (e i vertici) sono
molti e circondano l’utente dell’ambiente virtuale, in maniera tale che solamente
una porzione di essi sia visibile in ogni momento, il sistema viene alleggerito di tutte
le trasformazioni che sarebbero state applicate anche ai vertici non visibili.
L’algoritmo utilizzato per il culling è presentato nell’Appendice C. [FAR00, STE02]
6.5 Le trasformazioni geometriche in tempo reale
È importante limitare le trasformazioni geometriche (traslazioni, rotazioni e ridi-
mensionamenti) applicate sui modelli in tempo reale, in quanto ciascuna di esse
comporta un sovraccarico computazionale talvolta evitabile. Il metodo per evitarlo
è difatti quello di calcolare in fase di inizializzazione tutte le trasformazioni non va-
riabili nel tempo. Questo è esattamente il compito svolto dal loader 3DS e presentato
nella sezione 5.6.2.
Ci sono però casi particolari in cui emerge il bisogno di poter utilizzare trasformazioni
in tempo reale su alcune parti della scena. La motivazione principale è solitamente
la necessità di animare i modelli in tempo reale. A supporto di questa funzionalità

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 56
è stata sviluppata una parte di codice dedicata alla impostazione e applicazione di
tali trasformazioni in realtime.
Per la definizione su ciascun nodo della traslazione, della rotazione e del ridimensio-
namento in realtime sono state implementate due metodologie, entrambe con i propri
pregi. Una metodologia permette di definire tutte le trasformazioni con un’unica
matrice, ed è perciò pratica nel caso in cui la matrice associata alla trasformazione
che si desidera sia di formato noto e i suoi parametri facilmente calcolabili. L’altra
metodologia permette di definire le trasformazioni (traslazione, ridimensionamento
e rotazione) una ad una, ed è utile poiché non è necessario dover calcolare di volta in
volta la matrice associata alla trasformazione; un’ulteriore caratteristica di praticità
di questo secondo metodo è il fatto che la rotazione sia definita su un’asse generico,
un metodo di definizione in certi casi più flessibile di quello usuale che richiede i tre
angoli di rotazione sugli assi del sistema di riferimento.
La prima metodologia di definizione utilizza matrici 4 × 4. Tutti i vertici sono
infatti in coordinate omogenee, ovvero nel formato (x, y, z, w) T , ove w è una quarta
coordinata introdotta per facilitare alcune operazioni (ad esempio la proiezione dei
vertici dalle tre dimensioni allo spazio bidimensionale dello schermo) e per altri
motivi di praticità (grazie alla quarta coordinata è ad esempio possibile eseguire
le traslazioni per mezzo di matrici, cosa che lavorando con tre sole coordinate non
sarebbe possibile).
Il vertice e la matrice vengono moltiplicati all’interno della pipeline OpenGL in
questa maniera 3
⎛
⎜
⎝
a11 a12 a13 a14
a21 a22 a23 a24
a31 a32 a33 a34
a41 a42 a43 a44
⎞
⎟
⎠ ×
⎛ ⎞
⎜
⎝
x
y
z
w
⎟
⎠ =
⎛
⎜
⎝
3È importante ricordare che le matrici 4 × 4 memorizzate in OpenGL sottoforma di array di 16
elementi sono in un formato column-major, ovvero i primi 4 elementi corrispondono alla prima
colonna della matrice [NDW94]. Un array di 16 elementi del tipo [a0, . . . , a15] rappresenta perciò
la matrice 4 × 4 ⎛
⎞
⎜
⎝
a0 a4 a8 a12
a1 a5 a9 a13
a2 a6 a10 a14
a3 a7 a11 a15
⎟
⎠
x ′
y ′
z ′
w ′
⎞
⎟
⎠

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 57
Per eseguire una traslazione (tx, ty, tz) T è quindi necessario utilizzare la matrice
⎛
⎞
⎜
⎝
1
0
0
0
1
0
0
0
1
tx
ty
tz
⎟
⎠
0 0 0 1
I valori di ridimensionamento sui tre assi sono sulla diagonale, per cui la matrice
utilizzabile se i coefficienti sono sx, sy e sz è
⎛
⎞
sx
⎜
0
⎜
⎝ 0
0
sy
0
0
0
sz
0
⎟
0 ⎟
0
⎟
⎠
0 0 0 1
mentre per la rotazione si usano le usuali matrici con seno e coseno (utilizzando la
sottomatrice 3 × 3 da a11 a a33), ovvero
⎛
⎞ ⎛
⎞ ⎛
⎞
1
⎜
0
⎜
⎝ 0
0
cos α
sin α
0
− sin α
cos α
0 cos α
⎟ ⎜
0 ⎟ ⎜
⎟ ⎜
0
0
⎟ ⎜
⎠ ⎝ − sin α
0
1
0
sin α
0
cos α
0 cos α
⎟ ⎜
0 ⎟ ⎜
⎟ ⎜
sin α
0
⎟ ⎜
⎠ ⎝ 0
− sin α
cos α
0
0
0
1
0
⎟
0 ⎟
0
⎟
⎠
0 0 0 1 0 0 0 1 0 0 0 1
rispettivamente per la rotazione sull’asse x, sull’asse y e sull’asse z. [MOR89]
La seconda metodologia consente invece di specificare una ad una le trasformazioni
desiderate, per mezzo di:
• un vettore (tx, ty, tz) T nel caso della traslazione, che viene sommato ad ogni
vertice (x, y, z) T per ottenere il suo trasformato (x ′ , y ′ , z ′ ) T = (x+tx, y+ty, z +
tz) T ;
• un angolo α e un asse (ax, ay, az) T nel caso della rotazione, che è perciò definita
come un angolo di rotazione su un asse arbitrario anziché come tre angoli di
rotazione sui tre assi del sistema di riferimento;
• tre coefficienti sx, sy e sz nel caso del ridimensionamento, utilizzati per mol-
tiplicare i valori di ciascun vertice (x, y, z) T per ottenere il suo trasformato
(x ′ , y ′ , z ′ ) T = (x · sx, y · sy, z · sz) T .

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 58
Non è necessario usare tutte e tre le trasformazioni ogni volta ed è certamente
più performante utilizzare solo le non nulle; la libreria applica infatti unicamente
le trasformazioni definite. L’ordine in cui esse vengono eseguite è rigorosamente:
ridimensionamento, rotazione, traslazione. La matrice di trasformazione della prima
metodologia, se definita, viene applicata prima di queste trasformazioni.
Tutte le trasformazioni avvengono sul centro del nodo della gerarchia su cui sono de-
finite, tramite il classico approccio basato sullo spostamento temporaneo del sistema
di riferimento spesso usato in computer graphics. Per effettuare tale spostamento
vengono applicate all’oggetto due traslazioni inverse fra loro (la loro somma è il vet-
tore nullo), atte a spostare il centro del nodo nell’origine del sistema di riferimento
globale e viceversa, come illustrato nella Tabella 6.3.
Apply Transformations:
1: Translate(−centrox, −centroy, −centroz)
2: if matrice valida then Apply(matrice) endif
3: if ridimensionamento valido then Scale(sx, sy, sz) endif
4: if rotazione valida then Rotate(angolo, assex, assey, assez) endif
5: if traslazione valida then Translate(tx, ty, tz) endif
6: Translate(centrox, centroy, centroz)
Tabella 6.3: Applicazione delle trasformazioni geometriche su un nodo avente come
centro C = (centrox, centroy, centroz) T
È importante osservare come tutte le trasformazioni si applichino all’intero sottoal-
bero avente come radice il nodo su cui sono definite. Esse inoltre si accumulano di
nodo in nodo, e vengono applicate partendo dalle foglie sino a giungere alla radice.
Questo significa che se su un nodo è definita una trasformazione N e la trasforma-
zione definita sul suo nodo padre è P , sul nodo in questione verrà applicata P N
(ovviamente P può essere a sua volta una trasformazione composta). L’applicazione
delle trasformazioni avviene prima che venga invocato il motore di rendering per il
nodo, e prima che la chiamata di rendering discenda anche ai figli.
Nel caso della presenza di trasformazioni in tempo reale non è garantito il corretto
comportamento del culling, poiché la bounding box può variare continuamente e

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 59
non viene aggiornata in realtime per non aumentare drasticamente il sovraccarico
computazionale.
6.6 L’ordinamento dei figli
Quando nella scena sono presenti degli oggetti trasparenti risulta molto importante
l’ordine nel quale viene eseguito il rendering dei modelli. La resa della trasparenza si
basa infatti sul blending, una particolare funzionalità che consente di “mescolare” fra
di loro il colore del pixel da scrivere in una locazione e il colore del pixel già presente
in tale locazione. La libreria sviluppata utilizza il formato di memorizzazione dei
colori RGBA (acronimo di Red, Green, Blue, Alpha) a quattro canali da 8 bit
ciascuno. La particolare tipologia di blending impiegata nella presente libreria è
denominata alpha blending in quanto utilizza il canale dei colori denominato canale
alpha per modulare il livello di trasparenza dei materiali.
Il blending opera sui singoli pixel e consiste in una somma pesata dei colori ottenuti
per il medesimo pixel nel corso del rendering; i pesi utilizzati nell’alpha blending
non sono costanti ma sono dati dal valore del canale alpha del pixel, che può variare
in funzione del colore RGBA definito per i vari poligoni. Se il colore di un pixel già
presente nel framebuffer è (rd, gd, bd, ad) T e dobbiamo applicare un blending con il
colore (rs, gs, bs, as) T la particolare formula utilizzata nella presente libreria ci farà
ottenere ⎛
⎜
⎝
rfinale
gfinale
bfinale
afinale
⎞
⎟
⎠ =
⎛
⎞
⎜
⎝
as · rs + (1 − as) · rd
as · gs + (1 − as) · gd
as · bs + (1 − as) · bd
⎟
⎠
as · as + (1 − as) · ad
come colore finale. Si può facilmente notare il peso di as sul risultato finale.
Se come in Figura 6.9 abbiamo due oggetti trasparenti con un valore di trasparenza
del 60%, e ci appaiono posti uno dietro all’altro, nella zona in cui sono sovrapposti si
vedrà un colore pari al 60% dell’oggetto più vicino a noi sommato al 40% dell’oggetto
coperto 4 . Questo è vero se viene eseguito il rendering dell’oggetto posto sul retro, e
in seguito il blending con l’oggetto in fronte. Se però l’ordine della renderizzazione è
4 In realtà questo colore è pari al 60% del reale colore sommato al 40% del colore dello sfondo.

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 60
Figura 6.9: Blending errato (in alto) e corretto (in basso) fra due oggetti

CAPITOLO 6. LA GESTIONE DELLA GERARCHIA 61
il contrario, il colore che erroneamente comparirà sarà il 40% del colore dell’oggetto
posto davanti sommato al 60% del colore dell’oggetto dietro.
Questo esempio mostra come sia necessario che nel caso in cui vi siano degli oggetti
trasparenti essi siano renderizzati sempre nell’ordine corretto. Il metodo implemen-
tato ordina i figli di un nodo, consentendo al programmatore di scegliere il livello
di profondità a cui applicare l’ordinamento; il livello di profondità 1 causa l’ordina-
mento dei soli figli diretti, il livello 2 farà sì che vengano ordinati anche i figli dei
figli, e così via.
L’algoritmo utilizzato è un merge sort, di complessità O(n log n), e opera in fun-
zione della distanza fra il punto di vista e il centro dell’oggetto ordinando i nodi
dal più lontano al più vicino. Un’approfondimento su tale algoritmo è presente
nell’Appendice E. [CLR98]

CAPITOLO 7
La gestione del rendering
7.1 Le funzionalità a supporto del rendering
A fianco delle funzionalità riguardanti la gerarchia nella classe Object – contenente
geometria e materiali – sono anche presenti metodi per la gestione del rendering.
È importante notare come il rendering, orientato alle singole primitive, sia effettuato
da OpenGL. La libreria sviluppata nel presente lavoro opera ad un livello superiore
– orientato agli oggetti – e si occupa di impostare tutti i materiali e le texture,
modello dopo modello, ed infine inviare i dati alla libreria OpenGL sottostante.
Non è stato perciò implementato un motore di rendering, bensì uno strumento di
automatizzazione per l’utilizzo del preesistente motore OpenGL.
I modelli gestibili tramite questa classe si limitano alle mesh di triangoli, ovvero
dei reticoli composti unicamente da triangoli; i modelli contenuti all’interno di un
file 3DS sono sempre mesh di triangoli (cfr. 5.5.2). I triangoli sono difatti le figure
geometriche gestibili più facilmente dai moderni hardware grafici e solitamente le
librerie che supportano anche poligoni con un numero di lati maggiore di tre im-
plementano algoritmi di tessellazione che li riducano automaticamente a insiemi di
triangoli prima di inviarli alla pipeline grafica.
La classe Object supporta gli usuali colori dei materiali (ambientale, diffusivo, spe-
culare ed emissivo). Supporta inoltre una vasta gamma di texture, ciascuna con il
proprio particolare effetto visivo, che saranno presentate una ad una nelle successive
sezioni, con le relative modalità di applicazione ed esempi dei risultati finali. Questa
varietà di texture garantisce una elevata corrispondenza con la versione originale
del modello importato. Esse sono difatti tutte definite all’origine all’interno del file
62

CAPITOLO 7. LA GESTIONE DEL RENDERING 63
3DS e da esso vengono caricate per mezzo del loader sviluppato. Un semplice me-
todo consente l’attivazione, la disattivazione e la reimpostazione in tempo reale di
ciascuna di queste texture, indipendentemente dalla loro presenza all’interno del file
importato.
Di seguito viene quindi presentato l’algoritmo sviluppato per poter utilizzare tutte
le texture desiderate contemporaneamente. Esso sfrutta blending e stencil buffer
per effettuare rendering in più passate.
Sono infine chiarite le modalità per mezzo delle quali è possibile utilizzare anche
materiali trasparenti.
7.2 Le texture supportate
Una texture è una matrice bidimensionale in cui ciascun elemento contiene la descri-
zione di un colore, nel caso della presente libreria memorizzato in 32 bit nel formato
RGBA come illustrato nella sezione 6.6. Con i termini “texture” e “mappa” si
identifica però spesso anche la mappatura della texture, il procedimento che consiste
nell’identificare le corrispondenze fra i vertici del modello e gli elementi della tex-
ture (intesa qui come matrice) e nel decidere in base a tali corrispondenze i colori
da assegnare ai pixel durante la fase di rendering di tale modello. Nel seguito del
capitolo i termini texture e mappa saranno utilizzati indifferentemente con uno o
l’altro significato; l’interpretazione corretta sarà però di volta in volta comprensibile
dal contesto.
Il rendering viene tipicamente eseguito per vertice perciò solamente i vertici attraver-
sano la pipeline grafica; il colore viene calcolato su essi ed interpolato nello spazio
che li divide. Esiste però un’altra modalità più realistica (e computazionalmente
molto più pesante) di rendering: quella per pixel; in questa modalità sono tutti i
pixel ad attraversare la pipeline grafica, ed il colore di ciascuno di essi non deriva
quindi da una interpolazione bensì da una vera e propria rasterizzazione 1 .
L’utilizzo delle texture all’interno di un motore di rendering per vertice come quello
OpenGL consente un approccio di rendering che si avvicina per alcune caratteristiche
1 Per rasterizzazione si intende il processo che trasforma una scena definita geometricamente su un
intervallo continuo (la geometria 3D è definita su R 3 ) in una matrice di pixel dalle dimensioni
fissate, quindi definita su un intervallo discreto.

CAPITOLO 7. LA GESTIONE DEL RENDERING 64
a quello per pixel. La luminosità viene sempre calcolata per vertice (a meno che non
si utilizzi una mappa di illuminazione, come spiegato in 7.2.7), ma la cromaticità
dei pixel deriva dall’interpolazione fra i valori di colore presenti nella texture, non
solo quelli definiti sui vertici, e consente quindi una maggiore precisione sull’output
del rendering.
Per una migliore resa visiva dei modelli è necessario poter definire una moltitudine
di proprietà dei materiali, che talvolta sono addirittura connesse fra loro. Le tex-
ture forniscono un metodo abbastanza semplice per impostare gran parte di queste
caratteristiche.
Se l’applicazione di alcune texture è banale (ad esempio una semplice texture di
colore), l’utilizzo di altre richiede formule più complesse definibili unicamente con
il supporto delle estensioni OpenGL; esse sono delle porzioni di codice sviluppanti
funzionalità avanzate non facenti parte del nocciolo OpenGL definito dallo standard
di Silicon Graphics, ma fornite dalle case produttrici delle schede grafiche all’interno
dei driver delle periferiche. Le estensioni utilizzate in questo lavoro sono
• GL ARB multitexture, che permette il multitexturing, ovvero la possibilità di
utilizzare contemporaneamente più di una texture sullo stesso poligono;
• GL ARB texture env add, che permette di sommare il colore della texture
con quello del materiale o della texture precedente, anziché sostituirlo oppure
moltiplicarlo secondo le due modalità standard OpenGL;
• GL ARB texture env combine, che permette un controllo molto più avanzato
sulle formule che definiscono le operazioni per pixel fra i colori delle texture e
dei materiali.
Le tre estensioni OpenGL utilizzate sono presentate in dettaglio nell’Appendice
B. Se qualche estensione non è presente tutte le funzionalità della libreria che
necessitano di essa vengono ovviamente disabilitate.
Le texture il cui supporto è stato implementato all’interno della libreria – assieme
alla spiegazione delle modalità con le quali sono applicate dalla libreria prima del
rendering – sono introdotte di seguito.
Si rammenta infine che tutte queste texture possono essere presenti all’interno dei file
3DS e, se presenti, vengono importate dal loader e mantenute grazie alle funzionalità

CAPITOLO 7. LA GESTIONE DEL RENDERING 65
della classe Object.
È comunque possibile – indipendentemente dalla loro presenza
nei file importati – attivarle, disattivarle e ridefinirle in tempo reale grazie ai metodi
implementati nella libreria.
7.2.1 Texture di colore diffusivo
È la texture più comune, e viene utilizzata in sostituzione del colore diffusivo del
materiale nel caso in cui si abbiano oggetti non uniformi cromaticamente.
Figura 7.1: La modulazione fra il riflesso diffusivo e la texture di colore diffusivo (A)
ricrea l’oggetto (B)
La modalità di applicazione della texture di colore diffusivo non utilizza estensioni.
Il colore diffusivo base del materiale viene sostituito dal colore bianco, in maniera
tale che i riflessi diffusivi sugli oggetti possano variare dal bianco al nero. Questi
livelli di luminosità vengono quindi modulati dal colore della texture diffusiva, così
da riportare su essa stessa le varie sfumature delle ombre, come illustrato in Figura
7.1.

CAPITOLO 7. LA GESTIONE DEL RENDERING 66
7.2.2 Mappa di riflessione ambientale
Talvolta per ricreare l’effetto tipico dei materiali molto lucidi, specialmente quelli
metallici, è necessario simulare la riflessione dell’ambiente circostante su di essi.
Questo è fattibile tramite le mappe di riflessione ambientale.
Le coordinate di texture vengono solitamente assegnate a priori a ciascun vertice;
nel caso del loader 3DS vengono ad esempio importate una ad una dal file (cfr.
5.5.2). A differenza delle altre texture, le coordinate per la mappa di riflessione
ambientale non sono precalcolate bensì computate per ogni vertice in tempo reale
dipendentemente dal sistema di coordinate di vista anziché quello dell’oggetto (cfr.
6.4). Ci sono varie modalità per generare delle coordinate di riflessione d’ambiente,
le più utilizzate sono:
• il cylindrical mapping, in cui la texture dell’ambiente da riflettere viene ap-
plicata alla superficie di un cilindro invisibile che circoscrive il modello. Le
coordinate della texture vengono calcolate per ogni vertice in base al punto di
intersezione fra il cilindro ed il vettore normale su tale vertice. C’è un evidente
problema quando le normali dei vertici sono parallele all’asse del cilindro, in
quanto è un caso particolare per il quale non esistono intersezioni fra le normali
e il cilindro (del quale non si considerano le basi);
• lo spherical mapping, simile al cylindrical mapping, nel quale si utilizzano
ugualmente le normali ma si ricerca la loro intersezione con una sfera, elimi-
nando il caso particolare presente nella precedente modalità. Non è in realtà
utilizzata una sfera bensì la semisfera tagliata dal piano perpendicolare all’asse
ottico 2 passante per il centro come illustrato in Figura 7.2;
• il cubic mapping, nel quale le texture d’ambiente sono sei anziché una, e ven-
gono applicate ciascuna ad una delle sei facce di un cubo, come illustrato in
Figura 7.3.
È molto preciso ma anche molto dispendioso computazionalmen-
te; inoltre ancora poche schede lo supportano in hardware, a differenza dello
spherical mapping.
2 L’asse ottico è la retta passante per il punto di vista ed il fuoco (il punto su cui è concentrato lo
sguardo). [J ÄH93]

CAPITOLO 7. LA GESTIONE DEL RENDERING 67
Figura 7.2: Si nota come l’immagine della texture originale applicata su una semisfera
(A) appaia come riflessa sul modello 3D (B) se lo si inscrive all’interno della semisfera
Figura 7.3: Si nota come l’immagine delle sei texture originali applicate su un cubo (A)
appaiano come riflesse sul modello 3D (B) se lo si inscrive all’interno del cubo

CAPITOLO 7. LA GESTIONE DEL RENDERING 68
La libreria utilizza lo spherical mapping e i metodi di generazione automatica delle
coordinate già integrati in OpenGL. Sono messe a disposizione dell’utente due ti-
pologie di environment mapping, una più rapida ma meno accurata dell’altra, come
sarà chiarito nella sezione 7.3.
7.2.3 Texture di colore speculare
Come è possibile rimpiazzare il colore diffusivo con una texture, così è possibile
farlo anche con il colore speculare. Il colore speculare è però spesso molto meno
visibile di quello diffusivo, e solitamente gli è cromaticamente molto vicino. Questa
texture è perciò utile soprattutto nei materiali con riflessi di colore differente da
quello primario del materiale.
Figura 7.4: La modulazione fra il riflesso speculare e la texture di colore speculare (A)
ricrea l’oggetto (B)
La metodologia di applicazione è simile a quella utilizzata per la texture di colore
diffusivo. In questo caso è però il colore speculare del materiale anziché quello dif-

CAPITOLO 7. LA GESTIONE DEL RENDERING 69
fusivo ad essere sostituito con il bianco. La texture è quindi utilizzata per modulare
l’intensità del riflesso speculare sul materiale bianco, come illustrato in Figura 7.4.
7.2.4 Mappa di riflessività
Può essere talvolta necessario variare non uniformemente il livello di riflessività spe-
culare di un materiale, ovvero la quantità di riflesso speculare visibile (per esempio
in un materiale metallico non perfettamente lucidato).
Figura 7.5: La riflessività dell’etichetta sull’estintore a destra è stata annullata per mezzo
di una mappa di riflessività
La mappa di riflessività è una texture che viene utilizzata come modulatore per il
colore speculare oppure la texture di colore speculare e per la mappa di riflessione
d’ambiente, se attivata. Se non è usata per il colore speculare è però necessaria
l’estensione OpenGL per il multitexturing (comunque largamente supportata) in
quanto devono essere utilizzate due texture contemporaneamente (cfr. Appendice
B). Il valore cromatico finale, pixel per pixel, è uguale al colore speculare sul pixel
(dato dal colore del materiale oppure da quello della texture) moltiplicato per il
colore della mappa di riflessività sul medesimo pixel.
Nella maggior parte dei casi questa texture è in scala di grigi (ovvero i tre canali

CAPITOLO 7. LA GESTIONE DEL RENDERING 70
rosso, verde e blu assumono valori uguali sullo stesso pixel) ma è possibile utilizzare
anche texture a colori; in tal caso ciascuno dei canali della mappa andrebbe a mo-
dulare il corrispettivo nel colore speculare. Una mappa di riflessività con gamma
cromatica variante dal nero al rosso puro eliminerebbe ad esempio i canali verde e
blu dal riflesso speculare del materiale.
7.2.5 Texture di colore emissivo
Come per gli altri colori – ad esclusione di quello ambientale – è possibile modulare
non uniformemente anche il colore emissivo. La texture che consente di farlo è
denominata anche mappa di autoilluminazione in quanto definisce una luminosità
non riflessa dal materiale bensì introdotta artificialmente nella scena dall’oggetto
stesso. L’artificiosità è data dal fatto che in realtà tale luminosità non interagisce
con gli altri oggetti, ma è visibile solamente sul modello che la emette.
Figura 7.6: I fanali di un automobile appaiono accesi nell’immagine di destra grazie all’uso
di una texture di colore emissivo
Questa texture viene applicata per mezzo di una particolare estensione OpenGL,
GL ARB texture env add, che opera semplicemente sommando pixel per pixel il co-
lore risultante dall’applicazione di questa texture al colore già presente sul fram-
mento (cfr. Appendice B). La texture è utilizzata senza nessuna influenza da parte
delle luci presenti nell’ambiente, in quanto il colore che modula è colore emesso e
non riflesso.

CAPITOLO 7. LA GESTIONE DEL RENDERING 71
7.2.6 Bump mapping
Spesso è utile simulare la ruvidità di una superficie, ad esempio su pavimenti e pareti.
Talvolta è possibile utilizzare texture di colore diffusivo con elevato contrasto per
ottenere un valido effetto di questo tipo. Quando però sul materiale in questione
influisce una luminosità variabile nel tempo le ombre dei particolari in rilievo devono
spostarsi in realtime in funzione della posizione del punto di luce.
È allora possibile
adoperare un metodo più valido per rappresentare le asperità dei materiali che fa
uso della texture di bump mapping, una particolare texture che definisce per mezzo
di livelli di grigio le scabrosità presenti sulla superficie.
Figura 7.7: Una superficie senza (a sinistra) e con (al centro e a destra) bump mapping
(si noti nelle ultime due immagini come le ombre dei mattoni in rilievo varino in funzione
della posizione della luce)
Il particolare algoritmo di bump mapping implementato nel presente lavoro è deno-
minato embossing 3 e necessità dell’estensione GL ARB multitexturing (cfr. Appen-
dice B). Utilizza infatti la texture di bump mapping ed una sua copia con i colori
invertiti 4 applicandole contemporaneamente sul modello lievemente scostate fra loro
in funzione della posizione della luce e quindi sommando i loro colori; i coefficien-
3 Emboss significa scolpire, stampare in rilievo.
4 Per invertire un colore si rimpiazza per ciascun canale il valore presente v con il nuovo valore
massimo valore − v. Nel caso della presente libreria, siccome si utilizza il formato RGBA da 8 bit
per canale, il massimo valore è 2 8 − 1 = 255 perciò il valore invertito è 255 − v.

CAPITOLO 7. LA GESTIONE DEL RENDERING 72
ti di scostamento sono calcolati in tempo reale per vertice, utilizzando l’algoritmo
presentato nell’Appendice D.
I risultati ottenibili sono buoni solamente per materiali rugosi come l’asfalto oppure
la buccia di un’arancia, dove le irregolarità sulle superfici sono poco rilevanti ma ben
marcate. Per materiali poco scabri come la ceramica decorata sono invece necessari
altri algoritmi per pixel non utilizzati nella libreria in quanto molto dispendiosi e
quindi poco adatti ad applicazioni realtime.
É stata inoltre implementata un’ulteriore funzione di simulazione di ruvidità, atti-
vabile e disattivabile in tempo reale a piacimento, che utilizza la texture di bump
mapping per modulare la riflessione speculare e la riflessione d’ambiente. Questa
applicazione della texture di bump mapping è stata ideata ed implementata per far
fronte al basso realismo che si riscontrava nei materiali con molti riflessi speculari
e bump mapping abilitato, che apparivano lucidi in maniera uniforme nonostante
l’irregolarità della superficie. Questa funzionalità non ha alcuna precisione mate-
matica – a differenza degli algoritmi per pixel – ma è un semplice artifizio visivo
che richiede poche risorse computazionali a fronte di un netto aumento del realismo,
come si può notare in Figura 7.8.
7.2.7 Mappa di luminosità
Una parte notevole della computazione eseguita durante il rendering in tempo reale
è investita nel calcolo della luminosità dei vertici. L’approccio solitamente utiliz-
zato nella grafica in tempo reale, in quanto computazionalmente affrontabile dagli
attuali hardware, è difatti quello di calcolare il livello di luce riflessa su ogni verti-
ce e di assegnare ai pixel intermedi un valore di luminosità ottenuto interpolando
linearmente questi valori. Le limitazioni dell’illuminazione per vertice sono legate
alla grandezza dei poligoni: più i poligoni impiegati sono grandi minore è il realismo
dell’illuminazione (come si può constatare nella Figura 7.9), e minore è la possibilità
di calcolare in maniera realistica le ombre reciproche fra gli oggetti (del resto calco-
labili in tempo reale solamente con un grande dispendio di risorse computazionali).
Se si calcola la luminosità in realtime il realismo può aumentare solo se si utilizzano
algoritmi per pixel, nei quali cioè il livello di luce riflessa è calcolata pixel per pixel

CAPITOLO 7. LA GESTIONE DEL RENDERING 73
Figura 7.8: Il bump mapping su un materiale lucido è quasi impercettibile (A) se non si
utilizza la simulazione di ruvidità (B)

CAPITOLO 7. LA GESTIONE DEL RENDERING 74
senza interpolazioni; la pesantezza di calcolo di questi algoritmi è già stata esposta
nella sezione 7.2.
Figura 7.9: Nei poligoni l’illuminazione calcolata per vertice (A) in base ai vettori normali
non è precisa quanto quella calcolata per pixel (B)
Se per motivi legati alla necessità di esecuzione in tempo reale non è quindi pos-
sibile abbandonare l’algoritmo per vertice in favore di un algoritmo per pixel più
lento, tuttavia si può talvolta abbandonare l’illuminazione in tempo reale. Essa è
necessaria quando le luci o i modelli che devono essere illuminati sono in movimen-
to, ma se entrambi non si muovono è possibile adottare un metodo che garantisca
più rapidità e precisione in fase di rendering, ovvero precalcolare la luminosità delle
facce e salvarla in una texture utilizzata per la mappa di luminosità. La mappa di
luminosità non presenta i problemi sopracitati per l’illuminazione in tempo reale.
Utilizzare mappe di luminosità quando i modelli e le luci non variano la loro po-
sizione reciproca nel tempo può risultare spesso più realistico e suggestivo – oltre
che meno pesante per il motore di rendering che non deve calcolare in tempo reale
l’illuminazione per ciascun vertice – come si può notare in Figura 7.10.

CAPITOLO 7. LA GESTIONE DEL RENDERING 75
Figura 7.10: Illuminazione in tempo reale (a sinistra) e precalcolata (a destra) (si noti la
migliore resa delle ombreggiature nella seconda)
Figura 7.11: La trasparenza di un pannello di vetro decorato (A) può essere modulata in
maniera non uniforme per mezzo di una mappa di opacità (B)

CAPITOLO 7. LA GESTIONE DEL RENDERING 76
7.2.8 Mappa di opacità
Alcuni materiali possono essere trasparenti in maniera non uniforme, ad esempio nel
caso di oggetti di vetro con dei disegni decorativi. In tal caso è possibile modulare
il canale alpha del materiale per mezzo di una mappa di opacità.
L’applicazione di questa mappa avviene grazie ad una particolare estensione Open-
GL, GL ARB texture env combine, che consente di utilizzare per il materiale i tre
canali cromatici di una texture ed il canale alpha di un’altra texture (cfr. Appendice
B).
7.3 Il rendering multipassata
Le texture sono state presentate una ad una, ma l’algoritmo implementato nella
presente libreria consente di utilizzare allo stesso momento tutte quelle desiderate.
L’utilizzo di più texture contemporaneamente sullo stesso insieme di poligoni è de-
nominato multitexturing. La maggior parte delle schede grafiche moderne è in grado
di gestire il multitexturing, ma il numero massimo di texture utilizzabili contem-
poraneamente è spesso limitato a due, con alcune eccezioni (alcune schede grafiche
supportano al più quattro texture).
Per poter utilizzare un maggior numero di texture contemporaneamente, è stato
necessario implementare un meccanismo a più passate di rendering 5 , funzionante
tramite stencil buffer, z-buffer e blending (presentati uno ad uno in seguito), in
grado di mescolare fra di loro in maniera stratificata i risultati di più rendering.
7.3.1 Lo stencil buffer
Lo stencil buffer è una matrice bidimensionale di dimensioni identiche a quella sulla
quale si esegue il rendering (il frame buffer). Il numero di bit disponibili per ciascun
elemento dello stencil buffer dipende dalla scheda video. Non è, a differenza del frame
buffer, un buffer visibile. Gli elementi dello stencil buffer sono invece utilizzabili
come flag (una per pixel) utili per svariate operazioni.
5 Per rendering multipassata si intende l’esecuzione di più rendering dello stesso modello (variando
le sue caratteristiche di materiale) e la fusione dei risultati di tutti questi rendering per ottenere
l’immagine finale.

CAPITOLO 7. LA GESTIONE DEL RENDERING 77
Figura 7.12: Interpretazione grafica dei valori scritti nello stencil buffer dall’algoritmo
implementato durante il rendering (0 = nero, 1 = bianco)
Per ciascun pixel scritto sul frame buffer è possibile eseguire un’operazione elementa-
re (azzeramento, incremento, decremento) sul corrispondente elemento dello stencil
buffer.
È possibile eseguire anche l’operazione di testing (denominata stencil test),
ovvero decidere se disegnare o meno un pixel sul frame buffer a seconda del valore
presente al momento del rendering nella locazione corrispondente dello stencil buffer.
L’algoritmo implementato sfrutta queste funzionalità impostando ad uno i valori
dello stencil buffer corrispondenti ai pixel scritti durante il primo rendering e a zero
i rimanenti, con effetti analoghi a quelli mostrati nella Figura 7.12, ed utilizzando
lo stencil test per i rendering successivi, come spiegato dettagliatamente in seguito.
7.3.2 Lo z-buffer
Il depth buffer – denominato anche z-buffer a causa del fatto che in computer gra-
phics solitamente l’asse z sia quello posto a misurare la profondità – è come lo
stencil buffer una matrice delle dimensioni del frame buffer, adibita però a contene-
re le profondità degli oggetti renderizzati. Per profondità di un oggetto si intende la
sua distanza dal punto di vista. Questa distanza è calcolata durante il rendering per
pixel e memorizzata nelle opportune locazioni dello z-buffer. La profondità è spesso
normalizzata nell’intervallo [0, 1], dove 0 e 1 corrispondono ai limiti posti dai piani
near e far del frustum di vista (cfr. 6.4).
È definibile una operazione di testing (denominata depth test) che utilizzi lo z-
buffer. Per mezzo del depth test è possibile decidere se tenere oppure scartare un
pixel durante la fase di rendering. Il metodo più utilizzato (e adoperato anche

CAPITOLO 7. LA GESTIONE DEL RENDERING 78
nell’algoritmo implementato) è quello di visualizzare per ogni locazione solamente
il pixel con distanza minore fra tutti quelli corrispondenti alla medesima locazione
dello z-buffer, ovvero quello posto dinanzi a tutti gli altri rispetto alla posizione
dell’osservatore. I criteri di testing sono comunque definibili a piacimento anche in
tempo reale.
7.3.3 Il blending
Il blending è già stato introdotto nella sezione 6.6.
È un particolare meccanismo che
consente di mescolare fra loro, con coefficienti definibili in tempo reale, il colore che
deve essere scritto in un pixel e il colore già presente in tale pixel.
7.3.4 L’algoritmo utilizzato
L’algoritmo implementato invia gli oggetti al motore di rendering OpenGL, un ma-
teriale alla volta. All’interno di ciascun materiale è presente una lista di puntatori
alle facce che lo utilizzano. L’ordine in cui vengono scelti i vari materiali è quello
in cui sono stati inseriti, ad eccezione dei materiali trasparenti che vengono sempre
presi per ultimi, come spiegato nella sezione 7.4.
Vi sono sostanziali differenze fra le impostazioni utilizzate per la prima passata
e quelle impiegate per tutte le successive. Queste differenze sono dovute al fatto
che al primo passaggio si debba unicamente disegnare il modello, mentre in tutti i
seguenti stadi è necessario un più fine lavoro di mescolamento dell’ultimo rendering
con l’oggetto già presente nel frame buffer.
Il rendering viene difatti applicato in maniera stratificata, ed ogni passaggio non
deve sovrascrivere totalmente ciò che è stato fatto in precedenza, ma amalgamarsi
correttamente con esso.
La prima passata
Nel primo passaggio lo z-buffer è utilizzato con la modalità tipica che permette la
visualizzazione solamente dei pixel più vicini all’osservatore. Così facendo si ottiene
che gli oggetti si coprano fra di loro in maniera corretta, ovvero che i più prossimi
all’osservatore nascondano porzioni degli oggetti posti dietro. I materiali trasparenti
fanno una piccola eccezione, poiché per loro il buffer viene disabilitato in scrittura,

CAPITOLO 7. LA GESTIONE DEL RENDERING 79
in modo che possano passare il test di profondità anche i pixel retrostanti ma visibili
a causa della loro non totale opacità.
All’inizio di questa fase lo stencil buffer viene impostato totalmente al valore 0;
quindi le funzioni OpenGL sono configurate in maniera tale che per ogni pixel scritto
sul frame buffer venga impostata la locazione corrispondente dello stencil buffer a
1. Questo ci permetterà al termine della fase di rendering di avere uno stencil buffer
composto da 1 e 0 raffiguranti la zona del frame buffer nella quale il modello è stato
disegnato con successo (come illustrato nella Figura 7.12). Avere questi dati nello
stencil buffer è importante perché tutte le altre passate devono intervenire su tutti
e soli i pixel disegnati in questo passaggio, per evitare sbavature causate da pixel
non visibili in tutti i rendering ma solo in alcuni.
Il blending è in questo momento disabilitato, ad eccezione dei materiali trasparenti
nei quali è utilizzato per modellare l’opacità del materiale e non per motivi inerenti
l’algoritmo.
Le successive passate
In tutti i successivi passaggi si fa innanzitutto in modo che i pixel che vengono scritti
si limitino alla zona già utilizzata nella prima passata. Questo è possibile grazie allo
stencil buffer, che a questo punto contiene già un’immagine composta da tanti 1 e
raffigurante la porzione di schermo in cui è presente il modello. Lo stencil test viene
impostato in maniera tale che solamente i pixel posti in locazioni presenti nella zona
riempita di 1 vengano disegnati.
C’è una piccola variazione nell’utilizzo dello z-buffer: i pixel accettati sono qui tutti
quelli con profondità minore oppure uguale a quella scritta nel buffer.
È necessario
che sia così poiché sono già presenti i valori impostati nella prima passata che risulta-
no, per le facce visibili, certamente uguali a quelli calcolati in questa fase. Utilizzare
unicamente il minore comporterebbe quindi scartare anche i pixel in primo piano,
mentre la presenza dell’uguale garantisce che essi vengano accettati. Le facce non
visibili vengono invece correttamente scartate in quanto aventi profondità maggiore
rispetto ai pixel visibili, condizione non contemplata nella formula impiegata.
Il blending è qui abilitato per consentire il mescolamento con i rendering precedenti.
Le impostazioni del blending variano però a seconda del tipo di texture utilizzate
nella passata.

CAPITOLO 7. LA GESTIONE DEL RENDERING 80
I problemi dei materiali trasparenti
Se l’algoritmo funziona molto bene per i materiali opachi, non si può dire che faccia
lo stesso per i materiali trasparenti. Per essi è difatti sempre consigliabile utilizzare
un’unica passata, in quanto il blending fra le varie fasi non avviene in maniera
corretta.
Negli oggetti non trasparenti sono visibili solamente le facce in primo piano, e il
blending fra le varie passate di rendering è possibile perché ogni pixel su cui viene
eseguito non è il frutto di un precedente blending fra più facce. Nel caso di materiali
trasparenti sono invece visibili tutte le facce dell’oggetto, anche quelle che negli altri
casi sarebbero mascherate in quanto retrostanti, e ciò implica che il blending fra le
passate causi una stratificazione di più facce non corrispondenti fra loro, in maniera
erronea.
Questa è una limitazione degli algoritmi che eseguono il rendering multipassata su
insiemi di poligoni, irrisolvibile se non utilizzando algoritmi differenti più dispen-
diosi computazionalmente. Una soluzione a questo problema sarebbe ad esempio
implementare un algoritmo che operi per faccia anziché per materiale, ma ciò segne-
rebbe un netto calo delle prestazioni in quanto richiederebbe di impostare tramite
le funzioni OpenGL tutti gli stati relativi ai materiali una volta per ogni triangolo,
un’operazione molto pesante.
Si è scelto perciò di mantenere questa strategia e di consigliare l’utilizzo di una
singola passata nel caso di materiali trasparenti.
7.3.5 L’ordine delle texture
Come esposto nelle sezioni precedenti tramite il rendering a più passate è possibile
ottenere effetti più realistici grazie all’utilizzo di un numero elevato di texture sullo
stesso poligono. Potendo però utilizzare al più due texture per passata (questo è il
limite massimo imposto al multitexturing dalla maggior parte delle correnti schede
grafiche) è necessario effettuare una selezione fra le varie texture abilitate e definire
su di esse un ordine temporale di utilizzo.
Non esiste però un ordine univoco di applicazione delle varie texture, in quanto i
risultati delle varie passate vengono semplicemente sommati pixel per pixel fra loro,
e la commutatività della somma non permette di ottenere un’ordine di esecuzione

CAPITOLO 7. LA GESTIONE DEL RENDERING 81
assoluto fra le varie passate. L’unica eccezione è il caso del bump mapping, che deve
essere sempre eseguito per primo: questo vincolo è stato imposto dal blending e sarà
chiarito in seguito.
La scelta dell’ordine di applicazione delle texture è stata perciò effettuata soggettiva-
mente, selezionando una fra le varie possibili permutazioni delle passate. L’algoritmo
implementato esegue quindi le passate nel seguente ordine:
1. bump mapping, una passata per ciascuna delle luci utilizzabili in OpenGL (se
ovviamente è attivato il bump mapping per tale luce). Per default è abilitato
il bump mapping solamente sulla prima luce. Questo passaggio deve essere
eseguito per primo perché il blending fra le passate di bump mapping eseguite
per le varie luci non deve essere influenzato dalle passate successive;
2. colore diffusivo oppure texture diffusiva, e la prima texture attivata (se ve ne
è una) fra
• mappa di luminosità;
• mappa di opacità;
• riflessione ambientale (modalità rapida);
• texture di colore emissivo.
Se non sono state attivate ulteriori texture oltre a quelle utilizzate in questa
fase vengono qui renderizzati anche i colori ambientale, speculare ed emissivo;
3. colore speculare oppure texture speculare, con la prima texture attivata (se ve
ne è una) fra
• mappa di opacità;
• texture di bump mapping, per la simulazione di ruvidità;
• mappa di riflessività;
• riflessione ambientale (modalità rapida), se non è stata già utilizzata nella
fase precedente.
4. texture di riflessione ambientale, nella sua modalità più precisa ma più lenta,
modulata dalla prima texture attivata (se ve ne è una) fra

CAPITOLO 7. LA GESTIONE DEL RENDERING 82
• mappa di opacità;
• texture di bump mapping, per la simulazione di ruvidità;
• texture di colore speculare.
5. texture di colore emissivo, se attivata ma non già utilizzata nella seconda fase,
modulata dalla mappa di opacità se attivata.
Solamente la seconda fase è eseguita sempre, mentre le rimanenti sono attivabili e
disattivabili in tempo reale per mezzo della impostazione delle texture da utilizzare
(e delle luci nel caso del bump mapping). Ogni passata introduce una maggiore
pesantezza computazionale, a scapito del frame rate ma a giovamento della qualità
visiva.
La differenza sostanziale fra la riflessione d’ambiente rapida e la riflessione d’ambien-
te lenta è che la seconda è più precisa ma introduce un’ulteriore passata di rendering
mentre la prima – se sono attivate poche texture – può venire visualizzata anche in
un’unica passata, ad esempio assieme alla texture di colore diffusivo.
7.4 I materiali trasparenti
Come la presenza di più oggetti trasparenti nella scena richiede una particolare at-
tenzione, così anche all’interno dello stesso oggetto i materiali trasparenti necessitano
di maggiori cure.
Innanzitutto è opportuno renderizzare prima tutte le facce aventi un materiale non
trasparente, e solo in seguito quelle trasparenti. Questo perché per i materiali tra-
sparenti si deve disabilitare la scrittura sullo z-buffer, siccome è necessario che si
vedano anche le facce retrostanti che in un materiale completamente opaco sareb-
bero coperte quindi invisibili. Ordinando i materiali in questa maniera si è invece
certi che le facce non trasparenti non coprano erroneamente frammenti trasparenti
visibili, e che quelle trasparenti vengano renderizzate solamente dove il depth te-
st, abilitato solamente in lettura e quindi in funzione dei valori inseriti durante il
rendering dei materiali opachi, venga passato.
Anche all’interno dello stesso materiale è necessaria una accortezza: ordinare in
tempo reale le facce in maniera tale che il rendering avvenga sempre dalla più lontana

CAPITOLO 7. LA GESTIONE DEL RENDERING 83
alla più vicina.
È opportuna questa operazione affinché il blending fra le facce
dell’oggetto avvenga correttamente, come già chiarito nella sezione 6.6.
All’interno della libreria la procedura di gestione del rendering implementata si
preoccupa automaticamente di invocare innanzitutto il rendering delle facce non
trasparenti e solo in seguito quello delle facce trasparenti. Tutte le facce di ciascun
materiale trasparente vengono inoltre ordinate fra loro dalla più lontana alla più
vicina senza che sia necessario l’intervento dell’utente. Così come per l’ordinamen-
to degli oggetti, anche l’algoritmo per l’ordinamento delle facce è un merge sort,
presentato nell’Appendice E.

CAPITOLO 8
Demo e Benchmark
8.1 Il programma dimostrativo
Parallelamente allo sviluppo del presente lavoro di tesi è stato creato un programma
dimostrativo volto al testing delle varie funzionalità della libreria implementata.
Al termine del lavoro si è quindi giunti ad avere anche un completo applicativo di
testing.
Questo applicativo è composto da vari scenari tridimensionali, ciascuno opportuna-
mente selezionato per collaudare un particolare gruppo di funzionalità. L’interazione
con la libreria avviene tramite la pressione di vari tasti, ma è opportuno notare come
il gestore degli eventi relativi ai tasti premuti invochi direttamente le procedure della
presente libreria. Si sottolinea quindi come le funzionalità visibili e testabili tramite
pulsanti all’interno del programma dimostrativo siano le stesse funzionalità utiliz-
zabili tramite chiamate a metodi dagli sviluppatori che faranno uso della presente
libreria.
Gli ambienti virtuali utilizzati sono:
• una vasta area rurale composta da molti poligoni suddivisi in un gran numero
di nodi della gerarchia. Questo test è utile per collaudare la gerarchia ed il
culling (cfr. 6.4) che su di essa si basa. Sono stati inseriti dei modelli in movi-
mento all’interno di questo ambiente per verificare il corretto funzionamento
delle procedure per aggiungere e rimuovere nodi dalla gerarchia (cfr. 6.1) e per
impostare in tempo reale le trasformazioni geometriche (cfr. 6.5). Sul modello
della zona rurale sono inoltre presenti varie texture (cfr. 7.2).
muoversi liberamente nell’ambiente virtuale;
84
È possibile

CAPITOLO 8. DEMO E BENCHMARK 85
• una stanza con 4 pareti laterali di mattoni e pavimento e soffitto in cemento
rugoso. Questo test è volto a collaudare il bump mapping (cfr. 7.2.6), in quan-
to è possibile spostare il punto di luce ed osservare gli effetti di tali spostamenti
sulle sei pareti che compongono la stanza.
anche all’interno di questo ambiente virtuale;
È possibile muoversi liberamente
• una stanza piastrellata con una lastra di vetro semitrasparente sospesa al cen-
tro. Questo test è volto a collaudare la trasparenza e l’ordinamento degli
oggetti (cfr. 6.6). Sul vetro viene proiettato un filmato utilizzando le funzioni
per l’impostazione delle texture in tempo reale (cfr. 7.1). Si può infine decide-
re se abilitare una mappa di opacità (cfr. 7.2.8) per modellare la trasparenza
del pannello;
• un modello di un ambiente caricato da un file BSP (cfr. 9.2) che utilizza
mappe di luminosità (cfr. 7.2.7) ed un modello di una teiera importato da un
file 3DS per verificare la facile integrabilità fra modelli importati da formati
differenti, grazie alla separazione delle classi Group e Object dal formato di
importazione, come spiegato nel capitolo 4.
Nell’Appendice G sono presenti vari screenshot della demo implementata.
8.2 Benchmark
Sono stati eseguiti vari test per verificare il corretto comportamento della libreria e
per stimare la velocità del rendering. I due test più significativi per questo secondo
parametro sono stati effettuati su cinque macchine presentate in ordine crescente di
potenza:
1. un Athlon 1GHz con 256Mb di RAM; la scheda video è una Savage Twister K
integrata con 32Mb di RAM condivisa, la risoluzione dello schermo è 800×600;
2. un Pentium 3 800MHz con 256Mb di RAM; la scheda video è una Matrox
G450 con 32Mb di RAM dedicata, la risoluzione dello schermo è 1024 × 768;
3. un Pentium 4 1.8GHz con 512Mb di RAM; la scheda video è una nVidia
Quadro 2 EX con 32Mb di RAM dedicata, la risoluzione dello schermo è
1280 × 1024;

CAPITOLO 8. DEMO E BENCHMARK 86
4. un Pentium 4 3.2GHz con 1Gb di RAM; la scheda video è una nVidia Quadro
FX 1000 con 128Mb di RAM dedicata, la risoluzione dello schermo è 1280 ×
1024;
5. un doppio Xeon a 2.4GHz l’uno con 1Gb di RAM; la scheda video è una nVidia
Quadro 4 900 XGL con 128Mb di RAM dedicata, la risoluzione dello schermo
è 1280 × 1024.
Il primo test mette a confronto le performance della libreria con il culling (cfr. 6.4)
abilitato e disabilitato su un modello rappresentante una vasta area rurale (cfr.
Figura 8.1). Il modello è composto da 23519 facce triangolari memorizzate in una
gerarchia formata da 2902 nodi. I risultati del test, esposti in frame per secondo,
sono i seguenti:
Culling abilitato Culling Disabilitato
Athlon 1GHz 20fps circa 8fps
P3 800MHz fra i 25fps e i 30fps 14fps
P4 1.8GHz fra i 28fps e i 33fps 22fps
P4 3.2GHz fra gli 80fps e i 130fps 42fps
Doppio Xeon 2.4GHz fra gli 80fps e i 150fps 44fps
I frame per secondo sono variabili quando il culling è abilitato in quanto dipendono
dalla percentuale di geometria che viene scartata prima di essere inviata alla pipeline
grafica, come spiegato nella sezione 6.4.
Per il secondo test è stato invece utilizzato il modello 3D di una teiera già visto più
volte nei capitoli precedenti, composto da 1024 facce. Su di esso è stato applicato un
numero via via crescente di texture in maniera tale da poter analizzare le variazioni
indotte dall’aumento del numero di passate di rendering da eseguire (cfr. 7.3) nel
frame rate. I risultati sono i seguenti:
1 passata 2 passate 3 passate 4 passate
Athlon 1GHz 30fps 19fps 12fps 11fps
P3 800MHz 44fps 28fps 16fps 15fps
P4 1.8GHz 44fps 29fps 22fps 21fps
P4 3.2GHz 264fps 186fps 142fps 133fps
Doppio Xeon 2.4GHz 507fps 340fps 184fps 164fps

CAPITOLO 8. DEMO E BENCHMARK 87
Figura 8.1: Un modello 3DS rappresentante una vasta zona rurale

CAPITOLO 8. DEMO E BENCHMARK 88
Il rendering multipassata non è una caratteristica fondamentale della libreria, bensì
un’utilità aggiuntiva che è stata implementata allo scopo di migliorare il fotoreali-
smo dell’immagine finale, ove l’hardware e la complessità dell’ambiente virtuale lo
permettono. Solitamente l’applicazione di molte texture per aumentare il realismo
avviene su piccoli oggetti sui quali è concentrata l’attenzione o sui quali si vuole
ricreare un particolare effetto visivo, pressoché mai essa avviene sull’intero mondo
virtuale.
Due considerazioni emergono da questi test:
• è possibile con una passata di rendering utilizzare la libreria anche su hardware
dalle medio/basse prestazioni nella grafica 3D (come la Savage Twister K
integrata) raggiungendo soddisfacenti frame rate che non scendono di molto
sotto al limite minimo percettibile dall’uomo, fissato fra i 20 e i 30 frame al
secondo;
• l’utilizzo di quattro passate di rendering su un singolo oggetto di dimensioni
limitate è possibile sulle macchine potenti attualmente in commercio come il
Pentium 4 3.2GHz oppure il doppio Xeon, e consente di ottenere un frame rate
ampiamente superiore ai 20/30fps.
Un computer con la potenza del Pentium 4 3.2GHz oppure il doppio Xeon utilizzati
per questo benchmark possono risultare effettivamente piuttosto cari per un uso
domestico, ma sono un investimento affrontabile per un’ente come ITIA avvezzo
all’acquisto delle costose macchine SGI. Se a questo si aggiunge la differenza di
prezzo fra OpenGL (gratuita) e le onerose librerie a pagamento precedentemente
utilizzate da ITIA, fra cui Vega e Performer, il risparmio a livello aziendale appare
molto evidente.

CAPITOLO 9
Conclusioni e sviluppi futuri
9.1 Conclusioni
Inizialmente era stato posto l’obiettivo di realizzare una libreria basata su OpenGL
per il caricamento e la gestione di modelli tridimensionali. Il progetto iniziale era
incentrato sull’importazione dei modelli presenti nei file 3DS esportati da Autodesk
3DStudio.
Durante il lavoro è venuta gradualmente alla luce una infrastruttura di classi molto
flessibili; tali classi sono in grado non solo di importare e gestire efficacemente tutte
le proprietà dei modelli e della gerarchia presenti all’interno di un file 3DS, ma
anche di permettere all’utente della libreria di intervenire in tempo reale su tali
proprietà. Questa flessibilità lascia inoltre spazio aperto allo sviluppo di altri loader
che carichino modelli 3D da formati differenti da 3DS e li gestiscano per mezzo delle
classi già implementate nel presente lavoro di tesi.
Sin dall’inizio del lavoro è stata data un’elevata importanza alla facilità di integra-
zione della presente libreria all’interno di più grandi applicativi di realtà virtuale
basati su OpenGL. A dimostrazione del raggiungimento di questo scopo è stato
sviluppato un programma dimostrativo in OpenGL nel quale il Loader 3DS è sta-
to integrato facilmente e senza turbare il rendering globale dell’ambiente virtuale;
alcuni screenshot di tale programma sono presenti nell’Appendice G.
La libreria è stata infine corredata di una documentazione dettagliata fornita di
indice analitico, ad uso degli sviluppatori dell’ITIA a cui è stata consegnata. Tale
documentazione contiene una spiegazione di tutti i metodi implementati ordinati per
classe di appartenenza (Loader3DS, Group e Object). Per ciascun metodo è chiarita
all’interno della documentazione la metodologia d’uso, i parametri necessari in input
e l’output ottenibile, oltre a precisazioni sulle funzionalità del metodo ove necessario.
89

CAPITOLO 9. CONCLUSIONI E SVILUPPI FUTURI 90
9.2 Sviluppi futuri
L’interfaccia implementata dalla classe Loader e presentata nella sezione 5.1 e le
classi Group (cfr. Capitolo 6) e Object (cfr. Capitolo 7) indipendenti dal formato
di provenienza dei modelli 3D hanno lasciato ampio spazio per la creazione di nuovi
loader che importino file da formati differenti dal 3DS.
Figura 9.1: Un’ambientazione caricata per mezzo del loader di file BSP
È già in fase di sviluppo un loader di file BSP (Binary Space Partition), un formato
utilizzato dal famoso gioco Quake III della ID Software. All’interno di un file BSP
è memorizzata una geometria rappresentante degli ambienti (muri, porte, . . . ) cor-
redata di texture di colore diffusivo (cfr. 7.2.1) e mappe di luminosità (cfr. 7.2.7).
La versione ancora in fase di sviluppo del loader BSP è stata utilizzata per ottenere
l’immagine 9.1.
Il progetto di questo loader BSP è tuttora aperto e continuerà presso l’ITIA anche
in seguito ed al di fuori della tesi.

A.1 Introduzione
APPENDICE A
Il formato 3DS
Il formato 3DS è un formato binario. Un file 3DS è composto da blocchi nidificati
denominati chunk, come illustrato nella Figura A.1.
Figura A.1: La struttura a blocchi dei file 3DS
Ogni chunk è formato da un header contenente un suo identificativo a 16 bit e la
lunghezza in byte del chunk:
struct chunk_header {
};
unsigned short int ID;
unsigned int size;
L’header è seguito dal contenuto del chunk, la cui lunghezza in byte è
chunk_header.size - sizeof(chunk_header)
91

APPENDICE A. IL FORMATO 3DS 92
Nel corso di questa Appendice verrà presentato solamente l’insieme dei chunk che
sono caricati dalla classe Loader3DS (cfr. 5.3), una sottoparte dell’insieme di tutti
i chunk reperibili in un file 3DS, assieme al loro identificativo a 16 bit. I chunk
scartati contengono difatti informazioni non rilevanti per la presente libreria, ad
esempio dati riguardanti le luci e le telecamere oppure le animazioni. I chunk di
interesse per la libreria sono presentati nella Figura A.2.
Si può facilmente osservare come essi si suddividano in due grandi gruppi: i chunk
dell’editor e i chunk del keyframer. L’editor e il keyframer sono due sottoparti di
3DStudio che interagiscono strettamente ma sono concettualmente separate. L’e-
ditor è utilizzato per creare gli oggetti, che possono essere modelli 3D, luci oppure
telecamere.
È utilizzato anche per creare i materiali, impostare le loro texture e as-
segnare ai modelli i vari materiali. Il keyframer è invece utilizzato per gestire l’intera
scena, posizionare i modelli dell’editor in funzione del sistema di riferimento globale,
creare fra loro una gerarchia, impostare animazioni modificando le trasformazioni
geometriche che intervengono sui vari oggetti in funzione del tempo. I contenuti dei
due chunk rispecchiano questa suddivisione.
Sono considerati anche altri due chunk, RGB e AMOUNTOF, che possono essere
presenti in varie parti del file. [PVVF97]
A.2 I chunk
RGB (0x0011)
Contiene un colore in formato RGB (Red Green Blue), con ciascuno dei tre canali
memorizzato in un singolo byte.
AMOUNTOF (0x0030)
Contiene un intero di due byte utilizzato per vari scopi.
MAIN (0x4D4D)
Corrisponde all’intero file, e contiene un chunk di tipo EDITOR ed un chunk di tipo
KEYFRAMER.

APPENDICE A. IL FORMATO 3DS 93
MAIN (0x4D4D)
+-EDITOR (0x3D3D)
| +-EDITOR_MATERIAL (0xAFFF)
| | +-EDITOR_MATERIAL_NAME (0xA000)
| | +-EDITOR_MATERIAL_AMBIENT (0xA010)
| | +-EDITOR_MATERIAL_DIFFUSE (0xA020)
| | +-EDITOR_MATERIAL_SPECULAR (0xA030)
| | +-EDITOR_MATERIAL_GLOSSINESS (0xA040)
| | +-EDITOR_MATERIAL_SHININESS (0xA041)
| | +-EDITOR_MATERIAL_TRANSPARENCY (0xA050)
| | +-EDITOR_MATERIAL_2_SIDED (0xA081)
| | +-EDITOR_MATERIAL_EMISSION (0xA084)
| | +-EDITOR_MATERIAL_TEXTURE_DIFFUSE (0xA200)
| | +-EDITOR_MATERIAL_TEXTURE_OPACITY (0xA210)
| | +-EDITOR_MATERIAL_TEXTURE_BUMP (0xA230)
| | +-EDITOR_MATERIAL_TEXTURE_SPECULAR (0xA204)
| | +-EDITOR_MATERIAL_TEXTURE_SHININESS (0xA33C)
| | +-EDITOR_MATERIAL_TEXTURE_SELF_ILLUMINATION (0xA33D)
| | +-EDITOR_MATERIAL_TEXTURE_ENVIRONMENT (0xA220)
| | +-EDITOR_MATERIAL_TEXTURE_FILE (0xA300)
| | +-EDITOR_MATERIAL_TEXTURE_U_SCALING (0xA354)
| | +-EDITOR_MATERIAL_TEXTURE_V_SCALING (0xA356)
| | +-EDITOR_MATERIAL_TEXTURE_U_OFFSET (0xA358)
| | +-EDITOR_MATERIAL_TEXTURE_V_OFFSET (0xA35A)
| +-EDITOR_OBJECT (0x4000)
| +-EDITOR_OBJECT_MESH (0x4100)
| +-EDITOR_OBJECT_MESH_VERTICES (0x4110)
| +-EDITOR_OBJECT_MESH_FACES (0x4120)
| +-EDITOR_OBJECT_MESH_MATERIAL (0x4130)
| +-EDITOR_OBJECT_MESH_TEXTURE_COORDS (0x4140)
| +-EDITOR_OBJECT_MESH_SMOOTHING_GROUPS (0x4150)
| +-EDITOR_OBJECT_MESH_LOCAL_AXES (0x4160)
+-KEYFRAMER (0xB000)
+-KEYFRAMER_OBJECT (0xB002)
+-KEYFRAMER_OBJECT_FATHER (0xB010)
+-KEYFRAMER_OBJECT_NAME (0xB011)
+-KEYFRAMER_OBJECT_PIVOT_OFFSET (0xB013)
+-KEYFRAMER_OBJECT_TRANSLATION (0xB020)
+-KEYFRAMER_OBJECT_ROTATION (0xB021)
+-KEYFRAMER_OBJECT_SCALING (0xB022)
+-KEYFRAMER_OBJECT_NUMBER (0xB030)
Figura A.2: I chunk caricati dalla classe Loader3DS

APPENDICE A. IL FORMATO 3DS 94
EDITOR (0x3D3D)
Contiene i chunk che definiscono i materiali e gli oggetti presenti nella scena. Contie-
ne anche i chunk che definiscono le telecamere e le luci, ma questi vengono ignorati
dal loader in quanto non interessanti ai fini dell’applicazione.
EDITOR MATERIAL (0xAFFF)
Questo chunk corrisponde ad un particolare materiale e contiene i chunk con prefisso
EDITOR MATERIAL che definiscono le proprietà del materiale (non tutti i chunk
sono obbligatori).
EDITOR MATERIAL NAME (0xA000)
Contiene una stringa terminata dal carattere nullo, che corrisponde al nome del
materiale definito nel chunk padre di tipo EDITOR MATERIAL.
EDITOR MATERIAL AMBIENT (0xA010)
Contiene un chunk RGB al cui interno è memorizzato il colore ambientale del
materiale.
EDITOR MATERIAL DIFFUSE (0xA020)
Contiene un chunk RGB al cui interno è memorizzato il colore diffusivo del materiale.
EDITOR MATERIAL SPECULAR (0xA030)
Contiene un chunk RGB al cui interno è memorizzato il colore speculare del mate-
riale.
EDITOR MATERIAL GLOSSINESS (0xA040)
Contiene un chunk AMOUNTOF al cui interno è memorizzato il livello di atte-
nuazione dei riflessi speculari sulla superficie. Una maggiore attenuazione comporta
riflessi piccoli dai contorni più marcati, una minore attenuazione al contrario implica
riflessi speculari più estesi e più sfocati.

APPENDICE A. IL FORMATO 3DS 95
EDITOR MATERIAL SHININESS (0xA041)
Contiene un chunk AMOUNTOF al cui interno è memorizzato il livello di specularità
del materiale, utilizzabile come modulatore del colore speculare.
EDITOR MATERIAL TRANSPARENCY (0xA050)
Contiene un chunk AMOUNTOF al cui interno è memorizzato il livello di opacità
del materiale. Maggiore è questo livello, minore è la trasparenza.
EDITOR MATERIAL 2 SIDED (0xA081)
È un chunk vuoto la cui presenza è utilizzata come flag. Se presente ogni poligono
che usa questo materiale è considerato come composto da due facce sovrapposte,
ciascuna delle due avente le normali invertite rispetto all’altra.
EDITOR MATERIAL EMISSION (0xA084)
Contiene un chunk AMOUNTOF al cui interno è memorizzato il livello di emissione
del materiale, utilizzabile come moltiplicatore del colore diffusivo per ottenere il
colore emissivo.
EDITOR MATERIAL TEXTURE DIFFUSE (0xA200)
EDITOR MATERIAL TEXTURE OPACITY (0xA210)
EDITOR MATERIAL TEXTURE BUMP (0xA230)
EDITOR MATERIAL TEXTURE SPECULAR (0xA204)
EDITOR MATERIAL TEXTURE SHININESS (0xA33C)
EDITOR MATERIAL TEXTURE SELF ILLUMINATION (0xA33D)
EDITOR MATERIAL TEXTURE ENVIRONMENT (0xA220)
Contengono i chunk identificati dal prefisso EDITOR MATERIAL TEXTURE. Cia-
scuno di loro identifica un particolare tipo di texture, facilmente intuibile dal nome
stesso del chunk.

APPENDICE A. IL FORMATO 3DS 96
EDITOR MATERIAL TEXTURE FILE (0xA300)
Contiene il nome del file contenente la texture, sotto forma di stringa terminata da
un carattere nullo.
EDITOR MATERIAL TEXTURE U SCALING (0xA354)
EDITOR MATERIAL TEXTURE V SCALING (0xA356)
Contengono il valore di scaling della texture sulle sue due coordinate. Questo va-
lore viene impiegato negli oggetti che utilizzano questa texture come moltiplicatore
per le coordinate di texture reperibili nel chunk EDITOR OBJECT MESH TEX-
TURE COORDS.
EDITOR MATERIAL TEXTURE U OFFSET (0xA358)
EDITOR MATERIAL TEXTURE V OFFSET (0xA35A)
Contengono il valore di offset della texture sulle sue due coordinate. Questo valore
viene impiegato negli oggetti che utilizzano questa texture sommandolo alle coordi-
nate di texture reperibili in EDITOR OBJECT MESH TEXTURE COORDS.
EDITOR OBJECT (0x4000)
Identifica un oggetto della scena. Contiene una stringa terminata dal carattere
nullo che memorizza il nome dell’oggetto. A questa fanno seguito un chunk EDI-
TOR OBJECT MESH oppure altri chunk se l’oggetto è una luce o una telecamera.
Questi ultimi due casi sono però ignorati dal loader, in quanto irrilevanti ai fini del
caricamento dei modelli 3D.
EDITOR OBJECT MESH (0x4100)
Identifica una mesh di triangoli. Contiene i chunk identificati dal prefisso EDI-
TOR OBJECT MESH.

APPENDICE A. IL FORMATO 3DS 97
EDITOR OBJECT MESH VERTICES (0x4110)
Contiene un intero di 2 byte che indica il numero di vertici presenti in questo chunk.
Sono quindi memorizzate tante triplette (x, y, z) di floating point da 4 byte l’uno
quante indicate nell’intero da 2 byte.
EDITOR OBJECT MESH FACES (0x4120)
Contiene un intero di 2 byte che indica il numero di facce presenti in questo chunk.
Sono quindi memorizzati, per ogni faccia, i 3 vertici che la compongono (ciascuno
sotto forma di intero da 2 byte) e ulteriori 2 byte utilizzati come insieme di flag.
Nella presente applicazione si utilizzano solo i primi 3 byte di tale flag (flag & 0x01,
flag & 0x02 e flag & 0x04) nella modalità wireframe come indicatori della visibilità
dei tre segmenti che compongono la faccia triangolare.
EDITOR OBJECT MESH MATERIAL (0x4130)
Contiene una stringa terminata dal carattere nullo che corrisponde al nome del mate-
riale reperibile in EDITOR MATERIAL NAME. A questa stringa fanno seguito un
intero da 2 byte che indica il numero di facce che utilizzano questo materiale, ed in se-
guito tanti indici da 2 byte all’array reperibile in EDITOR OBJECT MESH FACES
quanti indicati dall’intero da 2 byte.
EDITOR OBJECT MESH TEXTURE COORDS (0x4140)
Contiene un intero di 2 byte che indica il numero di coordinate di texture (uguale al
numero di vertici) presenti in questo chunk. Sono quindi memorizzate tante coppie
(u, v) di floating point da 4 byte l’uno quante indicate nell’intero da 2 byte.
EDITOR OBJECT MESH SMOOTHING GROUPS (0x4150)
Gli smoothing groups sono gruppi di facce fra le quali vengono interpolate le nor-
mali. Questo chunk contiene tanti interi da 4 byte quante sono le facce in EDI-
TOR OBJECT MESH FACES. Ciascuno di questi interi è utilizzabile come insie-
me di 32 flag da un bit; un bit i-esimo impostato a 1 indica che il numero dello
smoothing group a cui appartiene la faccia corrispondente è i.

APPENDICE A. IL FORMATO 3DS 98
EDITOR OBJECT MESH LOCAL AXES (0x4160)
Contiene quattro triplette (x, y, z) di floating point da 4 byte l’uno. Le prime tre
triplette costituiscono la terna d’assi del sistema di riferimento locale dell’oggetto,
la quarta il centro di tale sistema di riferimento.
KEYFRAMER (0xB000)
Contiene i chunk che definiscono la gerarchia e le animazioni sotto forma di tra-
sformazioni geometriche in funzione del tempo. Ai fini della presente libreria ci si
interessa solamente della gerarchia, mentre per le animazioni si leggono solamente
le trasformazioni geometriche del primo fotogramma e si ignorano le successive.
KEYFRAMER OBJECT (0xB002)
Contiene un nodo della gerarchia. Al suo interno sono presenti i chunk contraddi-
stinti dal prefisso KEYFRAMER OBJECT.
KEYFRAMER OBJECT FATHER (0xB010)
Contiene una stringa terminata dal carattere nullo che memorizza il nome del no-
do. Per gli oggetti tale stringa corrisponde a quella reperibile in uno dei chunk
EDITOR OBJECT. Per i gruppi la stringa è invece “$$$DUMMY”, mentre il reale
nome del gruppo è reperibile nel seguente chunk KEYFRAMER OBJECT NAME.
Seguono 4 byte di dati ignorati, ed infine un intero da 2 byte che corrisponde al
numero reperibile in KEYFRAMER OBJECT NUMBER del nodo padre (oppure
-1 se il nodo è figlio della radice).
KEYFRAMER OBJECT NAME (0xB011)
Contiene una stringa terminata dal carattere nullo che memorizza il nome del
gruppo. Non è presente negli oggetti.
KEYFRAMER OBJECT PIVOT OFFSET (0xB013)
Contiene una tripletta (x, y, z) di floating point da 4 byte ciascuno. Tale tripletta
identifica lo scostamento del centro del sistema di riferimento locale dell’oggetto dal
centro della sua bounding box.

APPENDICE A. IL FORMATO 3DS 99
KEYFRAMER OBJECT TRANSLATION (0xB020)
Contiene 20 byte di dati ignorati, quindi una tripletta (x, y, z) che identifica il vettore
di traslazione che influisce sul nodo. I rimanenti dati fino al termine del chunk sono
ignorati in quanto nel presente lavoro non ci si interessa dell’animazione dell’oggetto.
KEYFRAMER OBJECT ROTATION (0xB021)
Contiene 20 byte di dati ignorati, quindi un floating point da 4 byte ed una tripletta
(x, y, z) che identificano l’angolo e l’asse della rotazione che influisce sul nodo. I
rimanenti dati fino al termine del chunk sono ignorati in quanto nel presente lavoro
non ci si interessa dell’animazione dell’oggetto.
KEYFRAMER OBJECT SCALING (0xB022)
Contiene 20 byte di dati ignorati, quindi una tripletta (x, y, z) che identifica i tre
coefficienti del ridimensionamento che influisce sul nodo. I rimanenti dati fino al
termine del chunk sono ignorati in quanto nel presente lavoro non ci si interessa
dell’animazione dell’oggetto.
KEYFRAMER OBJECT NUMBER (0xB030)
Contiene un intero da 2 byte che memorizza il numero del nodo, utile per identificarlo
come padre nei suoi nodi figli.

B.1 Introduzione
APPENDICE B
Le estensioni OpenGL
Le estensioni OpenGL sono funzioni non definite all’interno del nocciolo standard
OpenGL di Silicon Graphics. Esse sono invece fornite dai singoli produttori di hard-
ware all’interno dei driver delle schede grafiche, e potenziano l’insieme di funzionalità
base OpenGL.
Ogni estensione è identificata da un nome. Una estensione il cui nome inizia per
GL ARB è una estensione che è stata approvata dall’ARB (cfr. 3.1.4) e in quanto
tale deve obbligatoriamente essere fornita all’interno di ogni driver di scheda grafica
che supporti OpenGL. Le estensioni aventi come prefisso GL EXT sono estensioni
molto diffuse ma non ancora approvate formalmente dall’ARB; si consiglia comunque
ai produttori di schede grafiche di includerle all’interno dei driver. Esistono infine
una moltitudine di estensioni realizzate dalle singole case produttrici di hardware, ad
esempio nVidia (GL NV ) e Silicon Graphics (GL SGIS). La provenienza di ciascuna
estensione è quindi ricavabile semplicemente osservando il prefisso del suo nome.
B.2 Elenco delle estensioni presenti
È possibile ottenere l’elenco delle estensioni presenti nel proprio driver interrogando
OpenGL per mezzo della procedura glGetString. Una chiamata a
glGetString(GL_EXTENSIONS);
restituisce un puntatore ad una stringa contenente i nomi di tutte le estensioni
fornite all’interno del driver, separate fra loro da spazi.
100

APPENDICE B. LE ESTENSIONI OPENGL 101
B.3 Utilizzare le estensioni OpenGL
Per utilizzare le estensioni OpenGL è necessario includere la libreria glext.h che defi-
nisce tutte le macro C necessarie. All’interno della stessa libreria sono anche definite
le funzioni aggiuntive introdotte dalle varie estensioni, sotto forma di puntatori.
Le modalità di utilizzo di questi puntatori variano dipendentemente dal sistema ope-
rativo utilizzato. In ambiente Linux/Unix è possibile utilizzare tali puntatori senza
istanziarli. In ambiente Windows è invece necessario istanziarli con la locazione di
memoria corretta; per fare ciò è possibile utilizzare wglGetProcAddress che riceve
come input il nome della procedura di cui si vuole ottenere il puntatore e restitui-
sce tale puntatore.
illustrato nel seguente esempio:
È necessario effettuare un cast sul puntatore restituito, come
glActiveTextureARB = (PFNGLACTIVETEXTUREARBPROC)
wglGetProcAddress("glActiveTextureARB");
I tipi da utilizzare per il cast sono definiti nel file glext.h.
È sufficiente osservare
all’interno di tale file il tipo della procedura per la quale si vuole ottenere il puntatore
e utilizzare tale tipo per il cast.
Se non è presente una funzione per la quale si vuole ottenere un puntatore wglGet-
ProcAddress restituisce un puntatore nullo; analogamente anche sotto Linux/Unix
il puntatore è istanziato dal sistema a NULL. Questo implica che sia sempre neces-
sario controllare la presenza di una estensione con glGetString(GL EXTENSIONS)
prima di cercare di utilizzare una funzione ad essa collegata.
Il file glext.h è scaricabile dai siti dei vari produttori di schede grafiche, ad esempio
http://oss.sgi.com/projects/ogl-sample/registry/
oppure facilmente reperibile con una ricerca sui principali motori di ricerca.
B.4 Le estensioni utilizzate nella presente libreria
Il presente lavoro fa uso, se sono disponibili, di tre estensioni OpenGL:
• GL ARB multitexture;
• GL ARB texture env add;

APPENDICE B. LE ESTENSIONI OPENGL 102
• GL ARB texture env combine.
Se una di esse non è disponibile vengono disabilitate tutte le funzionalità della
presente libreria che fanno uso di tale estensione.
GL ARB multitexture
Questa estensione aggiunge al nocciolo OpenGL funzionalità per il multitexturing,
ovvero la possibilità di utilizzare contemporaneamente più di una texture sullo stesso
poligono. Fra le procedure introdotte da questa estensione quelle utilizzate all’inter-
no della presente libreria sono due: glActiveTextureARB e glMultiTexCoord2fARB.
OpenGL è una macchina a stati, perciò è possibile impostare le modalità di utilizzo
della texture semplicemente modificando gli stati OpenGL. Quando si utilizzano più
texture allo stesso momento risulta però difficile configurare per mezzo delle funzioni
base ciascuna texture indipendentemente dalle altre. La procedura glActiveTextu-
reARB serve a selezionare la texture attiva, ovvero quella per la quale avvengono le
modifiche degli stati. Tale texture può essere selezionata con le costanti introdotte
da glext.h, ovvero GL TEXTURE0 ARB, GL TEXTURE1 ARB, e così via.
Se non si utilizza il multitexturing è possibile definire per ogni vertice la relati-
va coordinata di texture utilizzando la procedura glTexCoord2f del nocciolo base
OpenGL. Quando si utilizza il multitexturing è possibile utilizzare la procedura
glMultiTexCoord2fARB per associare a ciascun vertice una coordinata di texture
separata per ognuna delle texture utilizzate. glMultiTexCoord2fARB funziona in
maniera analoga a glTexCoord2f ma riceve come parametro aggiuntivo una fra le
costanti GL TEXTUREn ARB sopracitate. [GF98]
GL ARB texture env add
In fase di rendering viene effettuata una modulazione fra il colore del materiale di
un poligono e i colori delle varie texture definite sul medesimo poligono. Il nocciolo
OpenGL consente di definire la modalità in base alla quale avviene tale modulazione
tramite le costanti
• GL DECAL e GL REPLACE, che permettono di sostituire il colore già presen-
te sul frammento (dato dal colore del materiale oppure dal colore della texture
precedente) con quello della texture corrente;

APPENDICE B. LE ESTENSIONI OPENGL 103
• GL MODULATE e GL BLEND, che permettono di eseguire una moltiplica-
zione fra il colore presente sul frammento e quello della texture corrente;
Questa estensione aggiunge la possibilità di utilizzare una quinta costante, GL ADD,
che consente di sommare fra loro pixel per pixel il colore presente sul frammento e
quello della texture corrente. [GF99]
GL ARB texture env combine
Questa estensione consente un maggiore controllo sulle equazioni che definiscono la
modulazione pixel per pixel che avviene fra il colore del materiale di un poligono e
il colore delle texture del poligono stesso.
Vengono fornite nuove costanti per poter definire con precisione gli operandi e gli
operatori da utilizzare per ottenere il colore RGBA finale partendo da quello del
materiale e quello della texture (oppure delle texture se si utilizza anche l’esten-
sione per il multitexturing).
È possibile definire sia le operazioni che intervengono
sul colore (COMBINE RGB) sia quelle che influiscono solamente sul canale alpha
(COMBINE ALPHA).
Gli operandi possono essere selezionati fra:
• GL TEXTURE, ovvero il colore della texture corrente;
• GL CONSTANT ARB, ovvero un colore costante definibile tramite le proce-
dure OpenGL;
• GL PRIMARY COLOR ARB, ovvero il colore del materiale;
• GL PREVIOUS ARB, ovvero il colore già presente sul frammento;
Per tutti questi operandi è possibile decidere se selezionare il colore, il suo com-
plementare, il valore del canale alpha oppure il complementare di tale valore. Gli
operatori che si possono utilizzare sono i già citati REPLACE, MODULATE e ADD;
in aggiunta si può usare ADD SIGNED (come ADD ma al risultato viene sottratta
la metà del valore massimo), INTERPOLATE (una somma pesata per la quale sono
necessari tre operandi: il terzo viene utilizzato come peso) e SUBTRACT (il valore
del primo operando meno quello del secondo).
Le specifiche per questa estensione sono reperibili in [PGFH01].

C.1 Introduzione
APPENDICE C
Il frustum culling
Il frustum culling è un processo volto a decidere se dei punti siano all’interno oppure
all’esterno del frustum di vista (cfr. 6.4). Nella presente libreria il frustum culling è
stato utilizzato assieme alle bounding box (cfr. 6.3) per alleggerire le computazioni
che avvengono in fase di rendering: è possibile applicare il frustum culling sulle
bounding box di tutti gli oggetti della scena per scoprire quali siano gli oggetti
visibili e quali siano quelli sui quali non è necessario eseguire il rendering, in quanto
non visibili.
L’algoritmo implementato opera in due fasi: la prima è necessaria per ottenere i sei
piani che formano il frustum di vista a partire dalla matrice di trasformazione del
modello e della vista e dalla matrice di trasformazione della proiezione (cfr. 6.4),
la seconda consiste nella vera e propria operazione di culling e si basa sul frustum
calcolato nella prima fase.
C.2 Il calcolo del frustum
Per il calcolo del frustum si utilizzano la matrice di trasformazione del modello e
della vista M (in OpenGL le due trasformazioni sono unite in un’unica matrice) e
la matrice di trasformazione della proiezione P (cfr. 6.4). Esse sono facilmente ot-
tenibili interrogando OpenGL con l’apposita funzione glGetFloatv utilizzando come
parametri GL MODELVIEW MATRIX e GL PROJECTION MATRIX. [NDW94]
Da queste due matrici è possibile ottenere
104

APPENDICE C. IL FRUSTUM CULLING 105
⎛
⎜
C = P M = ⎜
⎝
m11 m12 m13 m14
m21 m22 m23 m24
m31 m32 m33 m34
m41 m42 m43 m44
che corrisponde alla matrice per trasformare ciascun vertice dal suo sistema di ri-
ferimento locale al Clipping Coordinate System (cfr. 6.4). Il vertice in coordinate
omogenee (x, y, z, w) T viene trasformato da questa matrice in
⎛
⎜
⎝
x ′
y ′
z ′
w ′
⎞
⎟
⎠
⎞
⎟
⎠ =
⎛
⎞
⎜
⎝
m11
m21
m31
m12
m22
m32
m13
m23
m33
m14
m24
m34
⎟
⎠
m41 m42 m43 m44
×
⎛ ⎞
⎜
⎝
x
y
z
⎟
⎠
⎛
w
⎞
=
⎜
⎝
x · m11 + y · m12 + z · m13 + w · m14
x · m21 + y · m22 + z · m23 + w · m24
x · m31 + y · m32 + z · m33 + w · m34
x · m41 + y · m42 + z · m43 + w · m44
⎟
⎠
In OpenGL il frustum della vista viene trasformato nel Clipping Coordinate System
in un cubo di lato 2 centrato sull’origine, i cui vertici sono perciò tutte le triplette
di coordinate ottenibili utilizzando i valori 1 e −1.
(x ′ , y ′ , z ′ , w ′ ) T = (x ′ /w ′ , y ′ /w ′ , z ′ /w ′ , 1) T
sia all’interno di questo cubo solamente se vale
⎧
⎪⎨ −1 < x
⎪⎩
′ /w ′ < 1
−1 < y ′ /w ′ < 1
−1 < z ′ /w ′ < 1
ovvero ⎧ ⎪⎨
−w ′ < x ′ < w ′
−w
⎪⎩
′ < y ′ < w ′
−w ′ < z ′ < w ′
È quindi evidente che un vertice

APPENDICE C. IL FRUSTUM CULLING 106
Ponendo queste disequazioni in funzione di (x, y, z, w) T anziché (x ′ , y ′ , z ′ , w ′ ) T per
mezzo di una sostituzione si ottiene ad esempio per −w ′ < x ′ :
−(x · m41 + y · m42 + z · m43 + w · m44) < x · m11 + y · m12 + z · m13 + w · m14
ovvero
0 < x · (m41 + m11) + y · (m42 + m12) + z · (m43 + m13) + w · (m44 + m14)
che è la disequazione di uno semispazio. Siccome nella presente libreria tutti i vertici
sono nel formato (x, y, z, 1) T si giunge a
0 < x · (m41 + m11) + y · (m42 + m12) + z · (m43 + m13) + (m44 + m14)
dove si possono identificare
a = (m41 + m11), b = (m42 + m12), c = (m43 + m13), d = (m44 + m14)
come i coefficienti di un piano
ax + by + cz + d = 0
In maniera analoga si possono ottenere i coefficienti di tutti i sei piani che definiscono
il volume di spazio del frustum di vista, che risultano essere quelli indicati nella
Tabella C.1 (per i piani di clipping si veda 6.4).
Tutti i piani vengono quindi normalizzati; i loro coefficienti vengono cioè tutti divisi
per la norma del vettore (a, b, c) T ottenendo
(a ′ , b ′ , c ′ , d ′ ) T �
a
= √
a2 + b2 + c2 ,
b
√
a2 + b2 + c2 ,
c
√
a2 + b2 + c2 ,
�T d
√
a2 + b2 + c2 C.3 Il frustum culling
Un vertice (x0, y0, z0, 1) T è nel semispazio positivo rispetto ad un piano ax+by+cz+d
se si ha che
a · x0 + b · y0 + c · z0 + d > 0
In maniera analoga una bounding box è nel semispazio positivo rispetto ad un piano
se tutti i suoi otto vertici sono nel semispazio positivo rispetto a tale piano.

APPENDICE C. IL FRUSTUM CULLING 107
Piano di clipping Diseguaglianza Coefficienti
left −w ′ < x ′ a = m41 + m11
b = m42 + m12
c = m43 + m13
d = m44 + m14
right x ′ < w ′ a = m41 − m11
b = m42 − m12
c = m43 − m13
d = m44 − m14
bottom −w ′ < y ′ a = m41 + m21
b = m42 + m22
c = m43 + m23
d = m44 + m24
top y ′ < w ′ a = m41 − m21
b = m42 − m22
c = m43 − m23
d = m44 − m24
21ck −w ′ < z ′ a = m41 + m31
b = m42 + m32
c = m43 + m33
d = m44 + m34
front z ′ < w ′ a = m41 − m31
b = m42 − m32
c = m43 − m33
d = m44 − m34
Tabella C.1: I coefficienti dei sei piani che formano il frustum di vista (cfr. Figura
C.1), espressi in funzione del Clipping Coordinate System

APPENDICE C. IL FRUSTUM CULLING 108
Figura C.1: I sei piani che definiscono il volume del frustum di vista
Come si può notare dalle equazioni della sezione C.2 un punto è all’interno del
frustum di vista solamente se si trova all’interno dell’intersezione fra i semispazi
positivi di tutti i sei piani che formano il frustum. Una bounding box è all’interno
del frustum di vista (parzialmente o totalmente) solamente se almeno uno dei suoi
vertici è all’interno del frustum.
L’algoritmo implementato per il frustum culling scarta tutte le bounding box che si
trovano nel semispazio negativo rispetto ad uno qualsiasi dei sei piani che formano
il frustum. Questo algoritmo non esclude perciò le bounding box esterne al frustum
ma non completamente all’interno di uno dei sei semispazi negativi, come illustrato
nella Figura C.2.
In questo ultimo caso sarebbe infatti necessario impiegare anche un algoritmo di
collision detection fra la bounding box ed il frustum. Un algoritmo di questo tipo
non consiste nell’individuazione della posizione di un punto rispetto ad un piano,
calcolabile tramite la risoluzione di un’equazione per mezzo dell’algoritmo di fru-
stum culling sopra presentato; un algoritmo di collision detection comporta invece
la risoluzione di sistemi di equazioni per individuare l’esistenza di uno o più punti di
intersezione fra la bounding box dell’oggetto ed il frustum di vista, e risolvere questi
sistemi è evidentemente più costoso computazionalmente rispetto alla risoluzione di
una sola disequazione.

APPENDICE C. IL FRUSTUM CULLING 109
Figura C.2: Solamente i poligoni completamente all’interno di uno semispazio negativo
vengono eliminati. Per questo motivo la bounding box B0 viene scartata dal frustum
culling, mentre B1 viene mantenuta

D.1 Introduzione
APPENDICE D
Il bump mapping
Le superfici da modellare possono talvolta non essere perfettamente liscie, ed ai fini
di un rendering realistico può essere utile rappresentare rugosità e scanalature. È
possibile farlo in maniera precalcolata utilizzando texture diffusive ad alto contra-
sto (cfr. 7.2.1). Quando però le luci che influiscono sulla superficie si muovono è
necessario che le ombre causate dai particolari in rilievo si spostino in tempo reale
in funzione della posizione della luce. In questi casi è possibile fare uso del bump
mapping (cfr. 7.2.6).
Il bump mapping, traducibile in italiano come mappatura dei rilievi, è una tecnica
utilizzata in computer graphics per simulare dei dislivelli oppure delle asperità su
una superficie. Esistono vari algoritmi per il bump mapping, ma lo scopo comune
di tutti è quello di modificare la riflessione della superficie come se su di essa fossero
realmente presenti i dislivelli e le scabrosità.
Ci sono vari modi per modificare la riflessione di una superficie:
• modificare i vettori normali alla superficie pixel per pixel. Questo implica
impiegare algoritmi di shading per pixel anziché per vertice non ancora com-
putazionalmente affrontabili all’interno di programmi di grafica in tempo reale
(cfr. 7.2);
• modificare i vettori normali alla superficie vertice per vertice. Il realismo di
questa soluzione è legato al numero di poligoni che compongono il model-
lo. Non bisogna comunque dimenticare che aumentare il numero di poligoni
significa anche aumentare la pesantezza computazionale del rendering;
110

APPENDICE D. IL BUMP MAPPING 111
• sfruttare operazioni fra le texture come avviene nell’embossing, l’algoritmo im-
plementato all’interno della presente libreria; l’embossing verrà spiegato nella
sezione D.3.
D.2 La texture di bump mapping
La texture di bump mapping consiste in una immagine in scala di grigi (i cui valori
per ogni pixel variano nell’intervallo [0, 1], ovvero fra il nero ed il bianco) che viene
interpretata come una mappa di altitudine: il bianco indica l’altitudine più elevata,
il nero quella meno elevata ed i valori intermedi sono rappresentati dai vari valori di
grigio.
I dislivelli fra due zone sono tanto più grandi quanto maggiore è la distanza fra i
due valori cromatici dei pixel che le rappresentano. Una texture di bump mapping
per il pianeta Terra è fornita come esempio nella Figura D.1.
Figura D.1: Una texture di bump mapping per il pianeta Terra

APPENDICE D. IL BUMP MAPPING 112
D.3 L’embossing
L’embossing è un algoritmo di bump mapping che funziona tramite una semplice
operazione di somma fra texture, come chiarito poco avanti. Ha il difetto di modifi-
care solamente la riflessione diffusiva della superficie su cui è applicato, senza poter
modificare la riflessione speculare (per quest’ultima è necessario un algoritmo per
pixel); d’altra parte ha il grosso vantaggio di essere comunque parecchio realistico
(cfr. 7.2.6) ed al tempo stesso molto veloce: questo è ciò che conta in particolar
modo nelle applicazioni di grafica in tempo reale, e per questo motivo all’interno
della presente libreria è stato adottato l’embossing.
Il punto di partenza per effettuare l’embossing è ovviamente la texture di bump
mapping. Viene creata una copia di questa texture con i colori invertiti; per inverso
di un colore c definito sull’intervallo [0, 1] si intende il valore 1 − c. I valori di
entrambe le texture vengono poi dimezzati, in maniera tale da portare tutti i pixel
dall’intervallo [0, 1] all’intervallo [0, 0.5].
Se a questo punto si esamina una sezione delle due texture rappresentando con
diversi livelli di altitudine i colori delle due texture, è evidente che sommandole si
ottiene una texture di colore grigio (0.5) uniforme (cfr. Figura D.2).
Figura D.2: La somma fra la texture di bump mapping e la sua inversa genera una texture
uniforme grigia
L’effetto cromatico che si nota su una superficie con dislivelli che viene influenzata

APPENDICE D. IL BUMP MAPPING 113
da una luce è lo schiarimento delle zone di dislivello orientate verso la luce stessa
e lo oscuramento delle zone opposte. Se nella Figura D.2 spostiamo la texture di
bump mapping mantenendo immutata la posizione della sua inversa, otteniamo che
la somma non è più un valore costante, bensì la sezione di una texture sulla quale è
presente l’effetto che desideriamo ottenere sulla superficie soggetta a bump mapping.
Figura D.3: Se la texture di bump mapping viene scostata rispetto alla sua inversa la
loro somma genera due dislivelli di colore, uno più scuro ed uno più chiaro
È quindi evidente come sia sufficiente utilizzare questa somma fra la texture di bump
mapping invertita e la texture di bump mapping originale per simulare la ruvidità
di una superficie, modificando su ogni vertice in tempo reale le coordinate della
texture di bump mapping originale in maniera da scostarla di poco verso il punto
di luce. I coefficienti di scostamento della texture di bump mapping sono calcolabili
in funzione di tre versori:
• il versore inverso rispetto alla direzione della luce. Si possono avere luci di
posizione, collocate in un punto preciso del mondo virtuale, ed in tal caso
bisogna calcolare per ciascun vertice di ogni faccia il vettore che va dal vertice
al punto dove è collocata la luce, quindi normalizzarlo.
È possibile utilizzare
anche luci direzionali, ed in tal caso è sufficiente invertire il vettore di direzione
della luce, avendo sempre cura di normalizzarlo;
• i due versori di avanzamento della texture. Le texture sono bidimensionali, e su

APPENDICE D. IL BUMP MAPPING 114
di esse è definito un sistema di riferimento a due assi. I versori di avanzamento
servono a stimare la direzione nel mondo tridimensionale nella quale sono
orientati i due assi del sistema di riferimento della texture. Questa stima deve
essere calcolata per ogni vertice, e la metodologia impiegata nella presente
libreria è presentata in seguito.
Versori di avanzamento della texture
I versori di avanzamento di texture vengono calcolati sui tre vertici di ciascuna fac-
cia. I software dimostrativi che fanno uso dell’embossing utilizzano solitamente dei
modelli predefiniti per i quali i versori di avanzamento delle texture sono precalco-
lati. Questo non è ovviamente possibile all’interno della presente libreria, in quanto
non si conoscono a priori i modelli per i quali verrà utilizzato il bump mapping. È
stato perciò necessario ideare un algoritmo per calcolare una stima attendibile della
direzione di avanzamento delle coordinate di texture.
Figura D.4: Un triangolo con le coordinate di texture dei vari vertici
Utilizzando come esempio il triangolo della Figura D.4, ed in particolar modo il lato

APPENDICE D. IL BUMP MAPPING 115
che va da P 0 a P 1, è necessario individuare una valida stima della direzione spaziale
verso la quale avanzano le due coordinate della texture.
È evidente come all’interno delle equazioni da utilizzare dovranno trovare posto i
due coefficienti
∆u = u1 − u0
∆v = v1 − v0
che rappresentano la differenza fra le coordinate di texture sui due vertici.
Dovrà anche trovare posto il vettore
p = P 1 − P 0 = (p1x − p0x, p1y − p0y, p1z − p0z)
che è invece il vettore che va da P 0 = (p0x, p0y, p0z) T a P 1 = (p1x, p1y, p1z) T , ed
indica la direzione verso la quale le coordinate di texture avanzano di (∆u, ∆v).
Questo non è però sufficiente, in quanto sono necessari anche due coefficienti che
rappresentino l’attendibilità della stima. Per ottenere questi coefficienti è stato
sufficiente osservare i casi limite:
• quando ∆u = 0 si ha che la stima per l’avanzamento della coordinata v è al
massimo dell’attendibilità, a meno che non si abbia anche ∆v = 0. Lo stesso
vale per il caso ∆v = 0 e la coordinata u;
• quando |∆u| = |∆v| la stima è al minimo dell’attendibilità, in quanto il vettore
di direzione spaziale indica un avanzamento diagonale sulla texture, dal quale
è impossibile estrarre i due versori paralleli agli assi u e v del sistema di
riferimento della texture.
Si è perciò scelto di utilizzare come valore di attendibilità
a = |(|∆u| − |∆v|)|
che rispetta i casi limite analizzati e varia linearmente nei casi intermedi, in funzione
della differenza fra |∆u| e |∆v|.
I due vettori calcolati come stima dell’avanzamento nello spazio delle coordinate di
texture sono perciò
u = ∆ua · p

APPENDICE D. IL BUMP MAPPING 116
v = ∆va · p
Questi vettori sono calcolati per tutti i tre vertici di ciascuna faccia.
Questi vettori non sono però quelli finali. Per ogni smoothing group (cfr. A.2)
viene infatti calcolata una media dei vettori relativi a ciascun vertice del modello
appartenente a tale smoothing group (ogni vertice può difatti appartenere a più di
una faccia); questo vettore medio viene normalizzato per ottenere un versore, ed è
infine assegnato al relativo vertice come versore di avanzamento della coordinata di
texture.
Il coefficienti di scostamento della texture di bump mapping
Una volta calcolati i versori di avanzamento delle coordinate di texture ci ritroviamo
dalla situazione presentata in Figura D.4 a quella in Figura D.5. A questo punto è
possibile calcolare lo scostamento da applicare alla texture di bump mapping, che
dipenderà dalla posizione della luce.
Figura D.5: Sono stati i calcolati i versori di avanzamento delle coordinate di texture per
il triangolo di Figura D.4 (sono mostrati solo quelli per P 0)
Riferendoci all’immagine D.5 possiamo osservare la modalità utilizzata per il calcolo

APPENDICE D. IL BUMP MAPPING 117
dello scostamento della texture sulla coordinata u. La metodologia per il calcolo
dello scostamento sulla coordinata v è la stessa.
Come si nota è necessario calcolare il versore con direzione uguale a quella del-
la luce e verso opposto.
È innanzitutto necessario ricavare il vettore (x, y, z, w)T
rappresentante la luce utilizzando la funzione OpenGL
glGetLightfv(GL_LIGHT_n, GL_POSITION, light)
dove n corrisponde al numero della luce per cui si vuole ottenere il vettore 1 , mentre
light è un array di 4 floating point che conterrà tale vettore come output.
Figura D.6: È necessario calcolare il versore con direzione uguale a quella della luce e
verso opposto. Calcolando la norma della sua proiezione sul versore di avanzamento della
coordinata di texture si ottiene lo scostamento da applicare
1 In OpenGL è possibile utilizzare più di una luce contemporaneamente. Il limite degli hardware
attuali è solitamente posto ad otto luci, per cui n solitamente può assumere i valori fra 0 e 7
compresi.

APPENDICE D. IL BUMP MAPPING 118
Il vettore della luce restituito da glGetLightfv è espresso in funzione del sistema di
riferimento della vista, mentre i vettori di avanzamento delle coordinate di texture
sono espressi in coordinate locali dell’oggetto (cfr. 6.4).
È quindi necessario mol-
tiplicare il vettore della luce appena ottenuto per l’inversa della matrice relativa
alla trasformazione del modello e della vista. Tale matrice inversa è calcolata con il
metodo del determinante, già chiarito nella sezione 5.6.1. Così facendo si ottiene il
vettore (x ′ , y ′ , z ′ , w ′ ) T rappresentante la luce in funzione del sistema di riferimento
locale dell’oggetto.
Sempre riferendoci alla Figura D.6, dipendentemente dal valore di w ′ si possono
avere due casi:
• se w ′ = 0 la luce è di tipo direzionale (ovvero i raggi luminosi sono tutti paralleli
come provenienti da una sorgente posta a distanza infinita).
È sufficiente
normalizzare (−x ′ , −y ′ , −z ′ ) T per ottenere il versore con direzione uguale a
quella della luce e verso opposto;
• se w ′ �= 0 la luce è di tipo posizionale (ovvero i raggi luminosi sono tutti
provenienti da una sorgente puntiforme).
È necessario normalizzare il vettore
(x ′ − p0x, y ′ − p0y, z ′ − p0z) T per ottenere il versore con direzione uguale a
quella della luce e verso opposto (si rammenta che P 0 = (p0x, p0y, p0z) T ).
A questo punto, indipendentemente dalla tipologia di luce che stiamo considerando, è
stato ottenuto il versore indicato nella Figura D.6 con la lettera ˆ l. Come scostamento
da applicare alla texture di bump mapping sulla coordinata u è sufficiente utilizzare
la norma della proiezione di ˆ l sul versore û. Il calcolo di questo valore consiste in un
semplice prodotto scalare fra i due versori, ovvero ˆ l · û. Per ottenere lo scostamento
sulla coordinata v si devono eseguire tutti i passi appena presentati sostituendo
semplicemente il versore û con il versore ˆv.
È infine possibile utilizzare un coefficiente di attenuazione dello scostamento. Non
esiste un valore univoco per tale coefficiente ma è necessario decidere empiricamen-
te il valore da impiegare dipendentemente da quanto si vuole che sia evidente e
marcata l’ombreggiatura generata dal bump mapping. Nel presente lavoro si utiliz-
za come coefficiente 0.01, ma esso è dichiarato con una direttiva del preprocessore
C (#define BUMP_LEVEL 0.01) ed è quindi facilmente modificabile da parte degli
utenti della libreria intervenendo sul file che contiene tale direttiva.

APPENDICE D. IL BUMP MAPPING 119
Si ha quindi che i coefficienti di scostamento su e sv per ciascun vertice P sul quale
sono stati calcolati come versori di avanzamento delle coordinate di texture ûp e ˆvp
e per il quale il versore avente come direzione quella della luce ma verso opposto è
ˆ lp sono
[GOL99]
su = BUMP LEVEL · ûp · ˆ lp
sv = BUMP LEVEL · ˆvp · ˆ lp

APPENDICE E
L’algoritmo di ordinamento
E.1 Introduzione
All’interno del presente lavoro di tesi è stato necessario implementare un algorit-
mo di ordinamento per motivi legati alla trasparenza e chiariti nelle sezioni 6.6 e
7.4. L’algoritmo implementato nella presente libreria è utilizzabile per ordinare in
funzione della distanza dal punto di vista
• i triangoli che compongono un singolo modello tridimensionale;
• i figli di un nodo della gerarchia.
L’algoritmo funziona in due passi successivi: innanzitutto è necessario calcolare la
distanza che intercorre fra ciascun poligono oppure ciascun figlio di un nodo della
gerarchia ed il punto di vista, quindi si può applicare un ordinamento dal più lontano
di essi al più vicino. Di seguito sono presentate le due modalità per il calcolo della
distanza rispettivamente fra il punto di vista ed un poligono e fra il punto di vista
ed un nodo della gerarchia. Viene quindi presentato l’algoritmo di ordinamento, che
è un merge sort.
E.2 Distanza fra un poligono ed il punto di vista
Come spiegato nella sezione 6.4 le due trasformazioni del modello e della vista ser-
vono a portare il punto di vista nell’origine degli assi e ad orientare la direzione della
vista su un’asse. Nel caso di OpenGL queste due trasformazioni sono unite nella
120

APPENDICE E. L’ALGORITMO DI ORDINAMENTO 121
Figura E.1: Sistema di riferimento globale (A) e sistema di riferimento della vista (B).
La trasformazione della vista porta il punto di vista nell’origine degli assi ed orienta la
direzione della vista lungo l’asse z
matrice denominata ModelView, e orientano la vista sull’asse z nel verso dei valori
crescenti, come si può notare nella Figura E.1. [NDW94]
Questo significa che trasformando un poligono con la matrice ModelView è poi
elementare calcolare la sua distanza dal punto di vista, in quanto il punto di vista
sarà collocato nell’origine.
Il metodo per il calcolo della distanza di una faccia triangolare dal punto di vista
implementato nella presente libreria utilizza per misurare tale distanza il punto
ottenuto dalla media dei tre vertici della faccia. Se i tre vertici sono P0, P1 e P2 il
punto medio utilizzato è
Pm = P0 + P1 + P2
3
Per diminuire il numero di calcoli eseguiti, la matrice ModelView viene applicata
solo in seguito a questa media, e solamente al punto medio Pm. La distanza della
faccia che si sta considerando è quindi calcolata come
dove Pm = (mx, my, mz) T .
d =
�
m 2 x + m 2 y + m 2 z

APPENDICE E. L’ALGORITMO DI ORDINAMENTO 122
E.3 Distanza fra un nodo della gerarchia ed il punto di vista
Come spiegato nella sezione 6.3 ad ogni nodo della gerarchia è assegnata una boun-
ding box, con un relativo centro. Si può quindi applicare quanto detto nella sezione
E.2 a tale centro.
Se il centro del nodo di cui si vuole calcolare la distanza dal punto di vista è C =
(xc, yc, zc) T ad esso viene innanzitutto applicata la matrice delle trasformazioni del
modello e della vista M ottenendo
C ′ = MC = (x ′ c, y ′ c, z ′ c) T
ed infine si computa la distanza del nodo come
d = � (x ′ c) 2 + (y ′ c) 2 + (z ′ c) 2
E.4 L’algoritmo di ordinamento
L’algoritmo di ordinamento implementato all’interno della presente libreria è un
merge sort, e ordina array di floating point (rappresentanti le distanze dal punto di
vista dei vari poligoni oppure dei figli di un nodo) dal maggiore al minore. Ai fini
della libreria è difatti necessario avere poligoni e nodi ordinati dal più lontano al più
vicino, per motivi legati alla trasparenza e spiegati in 6.6.
MergeSort(Array, from, to):
1: if from < to then
2: m = from+to
2
3: MergeSort(Array, from, m)
4: MergeSort(Array, m+1, to)
5: Merge(Array, from, m, to)
6: endif
Tabella E.1: Merge Sort
L’algoritmo implementato si basa su un approccio divide et impera, cioè una metodo-
logia che suddivide ricorsivamente il problema in più sottoproblemi di meno difficile

APPENDICE E. L’ALGORITMO DI ORDINAMENTO 123
risoluzione, sino ad un caso base risolvibile elementarmente. [SED93] L’algoritmo è
presentato in pseudocodice nella tabella E.1.
Come si nota dallo pseudocodice MergeSort si appoggia su un’altra procedura de-
nominata Merge. Lo pseudocodice di Merge è presentato nella tabella E.2. Ci sono
dei requisiti per l’input inviato a Merge: i due sottoarray Array[from..middle]
e Array[middle+1..to] devono essere già ordinati. Se queste specifiche sull’input
sono rispettate l’output di Merge sarà l’intero array Array[from..to] ordinato.
Merge(Array, from, middle, to):
1: k = from
2: i = from
3: j = middle+1
4: while (i ≤ middle) ∨ (j ≤ to) do
5: if (i > middle) then
6: Temp[k] = Array[j]
7: j = j+1
8: else if (j > to) then
9: Temp[k] = Array[i]
10: i = i+1
11: else
12: if Array[i] > Array[j] then
13: Temp[k] = Array[i]
14: i = i+1
15: else
16: Temp[k] = Array[j]
17: j = j+1
18: endif
19: endif
20: k = k+1
21: endwhile
22: for i from from to to do
23: Array[i] = Temp[i]
24: endfor
Tabella E.2: Merge
Come si può notare dallo pseudocodice Merge non opera in place, ovvero necessita
di un array di supporto sul quale salvare temporaneamente i dati che vengono ordi-

APPENDICE E. L’ALGORITMO DI ORDINAMENTO 124
nati. Questo sovrapprezzo di memoria è però ampiamente ricompensato dalla bassa
complessità dell’algoritmo che è O(n log n), a fronte di un utilizzo della memoria che
è comunque O(n), dove n è il numero degli elementi presenti nell’array da ordinare.
[CLR98, SED93]

APPENDICE F
I quaternioni e la rotazione
F.1 Introduzione
I quaternioni furono inventati da Sir William Rowan Hamilton (*1809 – †1865)
nel 1843. L’obiettivo di Hamilton era generalizzare i numeri complessi alle tre di-
mensioni, ovvero numeri nella forma a + ib + jc dove a, b, c ∈ R e i 2 = j 2 = −1.
Una delle motivazioni di Hamilton per la ricerca di numeri complessi tridimensio-
nali era trovare una rappresentazione delle rotazioni nello spazio tramite numeri
complessi, dove una moltiplicazione potesse corrispondere ad una rotazione ed un
ridimensionamento.
Nell’Ottobre del 1843, mentre passeggiava sul Royal Canal a Dublino, Hamilton si
rese conto che sono necessari quattro numeri per descrivere una rotazione seguita
da un ridimensionamento: un numero per il coefficiente di ridimensionamento, un
numero per i gradi di rotazione ed i rimanenti due per descrivere il piano nel quale
il vettore deve essere ruotato 1 . Hamilton nominò quindi quaternioni i numeri com-
plessi quadridimensionali da lui ideati, esprimendoli nella forma ix + jy + kz, dove
i 2 = j 2 = k 2 = ijk = −1, ij = k e ji = −k. [KDL98]
La modalità spesso utilizzata per definire una rotazione fa uso dei tre angoli di
Eulero, scomponendo ciascuna rotazione in una combinazione di tre rotazioni sui
tre assi del sistema di riferimento. La rotazione per mezzo dei quaternioni è invece
definita con un angolo di rotazione ed un asse generico. La differenza fra le due
modalità è visibile in Figura F.1.
1 Il piano xy può essere ruotato in un piano qualsiasi dello spazio xyz tramite i due angoli di rotazione
sugli assi x e y.
125

APPENDICE F. I QUATERNIONI E LA ROTAZIONE 126
Figura F.1: Rotazione con i tre angoli di Eulero (A) e con un angolo ed un asse generico
(B)
Figura F.2: Una doppia rotazione di 90 ◦ eseguita su (A) causa la sovrapposizione di due
assi (B) con la perdita di un grado di libertà

APPENDICE F. I QUATERNIONI E LA ROTAZIONE 127
Il metodo degli angoli di Eulero soffre del problema del Gimbal Lock, ovvero una
perdita di uno dei tre gradi di libertà rotazionale. La perdita di un grado di libertà
avviene quando una rotazione di 90 ◦ va a sovrapporre fra loro due assi del sistema
di riferimento, come illustrato in Figura F.2. In questo caso si viene a ricreare una
situazione per la quale eseguire una rotazione su uno dei due assi coincidenti sia
equivalente ad eseguirla sull’altro, per cui i due assi identificano lo stesso grado di
libertà. La rotazione con i quaternioni non soffre di Gimbal Lock. [BOB98]
F.2 Matematica base dei quaternioni
I quaternioni sono rappresentati solitamente come [s, v] con s ∈ R, v ∈ R 3 . Sono
perciò composti da una parte scalare s ed una parte vettoriale v. L’insieme dei
quaternioni è denominato H.
Moltiplicazione fra quaternioni
Dati due quaternioni q, q ′ ∈ H con q = [s, v] e q ′ = [s ′ , v ′ ], il loro prodotto è definito
come
qq ′ = [ss ′ − v · v ′ , v × v ′ + sv ′ + s ′ v]
dove · e × sono rispettivamente i prodotti scalare e vettoriale in R 3 .
Moltiplicazione fra un quaternione ed uno scalare
La moltiplicazione fra uno scalare s ed un quaternione q è definita come [s, 0]q.
Quaternione coniugato
Dato un quaternione q = [s, v] è detto suo coniugato, e denominato q ∗ , il quaternione
q ∗ = [s, v] ∗ = [s, −v].
Norma di un quaternione
La funzione || · || : H ↦→ R è definita come ||q|| = √ qq ∗ . Questa funzione è chiamata
norma, perciò ||q|| è la norma di q.
Viene denominato ˚ H l’insieme di tutti i quaternioni aventi norma non nulla.

APPENDICE F. I QUATERNIONI E LA ROTAZIONE 128
Inverso di un quaternione
Dato un quaternione q ∈ ˚ H è definito come suo inverso, e denotato q −1 , il quater-
nione
q −1 = q∗
||q|| 2
Ogni quaternione in ˚ H ha un inverso, come dimostrato in [KDL98].
F.3 Rotazione con i quaternioni
Con i presupposti matematici esposti in F.2, è possibile utilizzare i quaternioni per
ruotare un vettore.
Rappresentiamo un vettore v con un quaternione nella forma p = [0, v]. Dato un
asse di rotazione normalizzato n ed un angolo θ, definiamo
Si ha allora che
q = [cos θ, sin θn]
p ′ = qpq −1
equivale a p ruotato sull’asse n di un angolo 2θ. Per una prova formale di questo si
rimanda a [KDL98].
È possibile dimostrare che dato un quaternione p = [0, v], il quaternione p ′ = qpq −1
sarà nella forma p ′ = [0, v ′ ] (si veda [KDL98]).
Per ruotare il vettore v di un angolo θ sull’asse n è perciò sufficiente inserirlo
all’interno di un quaternione p = [0, v], calcolare
p ′ = [cos θ θ
, sin
2 2
ed estrarre dal quaternione p ′ il vettore v ′ .
θ θ
· n]p[cos , sin
2 2 · n]−1 = [0, v ′ ]

APPENDICE G
Screenshot della demo realizzata
G.1 Demo 1: la gerarchia e le trasformazioni geometriche
in tempo reale
Figura G.1: Un modello rappresentante una vasta area rurale. Esso è composto da 23519
facce triangolari memorizzate in una gerarchia formata da 2902 nodi (cfr. Capitolo 6)
129

APPENDICE G. SCREENSHOT DELLA DEMO REALIZZATA 130
Figura G.2: Un nodo della gerarchia viene aggiunto e modificato senza influenzare il resto
del modello (cfr. Capitolo 6)
Figura G.3: I due mezzi appaiono in movimento sulla strada grazie all’applicazione in
tempo reale di una traslazione variabile nel tempo (cfr. 6.5)

APPENDICE G. SCREENSHOT DELLA DEMO REALIZZATA 131
G.2 Demo 2: bump mapping
Figura G.4: Quando la luce si sposta le ombre su un pavimento con bump mapping
abilitato variano (cfr. 7.2.6)

APPENDICE G. SCREENSHOT DELLA DEMO REALIZZATA 132
Figura G.5: Quando la luce si sposta le ombre su un muro di mattoni con bump mapping
abilitato variano (cfr. 7.2.6)

APPENDICE G. SCREENSHOT DELLA DEMO REALIZZATA 133
G.3 Demo 3: trasparenza e modifica delle texture in tempo
reale
Figura G.6: Un pannello semitrasparente posto al centro di una stanza rivestita di
piastrelle (cfr. 6.6)
Figura G.7: La texture del pannello trasparente viene modificata in tempo reale in
maniera da simulare la proiezione di una animazione su di esso (cfr. 7.2)

APPENDICE G. SCREENSHOT DELLA DEMO REALIZZATA 134
Figura G.8: La trasparenza del pannello è uniforme nell’immagine a sinistra, modulata
in maniera non uniforme per mezzo di una mappa di opacità nel pannello di destra (cfr.
7.2 e 7.2.8)
G.4 Demo 4: mappe di luminosità ed integrazione fra modelli
importati da formati differenti
Figura G.9: Nella scena di sinistra l’illuminazione è calcolata in tempo reale, nella scena
di destra sono sfruttate le mappe di luminosità (cfr. 7.2.7)

APPENDICE G. SCREENSHOT DELLA DEMO REALIZZATA 135
Figura G.10: L’ambiente è stato importato da un file BSP (cfr. 9.2) mentre la teiera è
stata importata da un file 3DS (cfr. 3.4). Come si può notare l’indipendenza dal formato di
provenienza delle classi Group e Object (cfr. Capitolo 4) consente una totale integrazione
fra modelli provenienti da tipi di file differenti

Bibliografia
[ABA96] Marco Abate. Geometria. McGraw-Hill, 1996.
[BAC00] Anders Backman. Virtual reality, 2000.
(http://www.cs.umu.se/kurser/TDBD12/HT00/lectures/introduction.pdf, 21 Novembre 2003).
[BEI03] Klaus-Peter Beier. Virtual reality: A short introduction, 2003.
(http://www-vrl.umich.edu/intro/, 10 Novembre 2003).
[BOB98] Nick Bobick. Rotating objects using quaternions, 1998.
(http://www.gamasutra.com/features/19980703/quaternions 01.htm, 23 Novembre 2003).
[CLR98] Thomas H. Cormen, Charles E. Leiserson e Ronald L. Rivest. Intro-
duction to Algorithms. McGraw-Hill, 1998.
[COH00] Jonathan Cohen. History of virtual reality, 2000.
(http://www.cs.jhu.edu/˜cohen/VW2000/Lectures/History.color.pdf, 06 Novembre 2003).
[ECK98] Bruce Eckel. Thinking in C++, 2nd Edition. Prentice Hall, 1998.
[EG01] Wolfgang F. Engel e Amir Geva. Beginning Direct3D Game Program-
ming. Prima Tech, 2001.
[FAR00] Paul A. Farrell. OpenGL rendering pipeline, 2000.
(http://www.cs.kent.edu/ farrell/graphics/opengl/openglprog1.2/opengl/render.html, 26 Dicembre 2003).
[GF98] Michael Gold e Tom Frisinger. GL ARB multitexture, 1998.
(http://oss.sgi.com/projects/ogl-sample/registry/ARB/multitexture.txt, 27 Gennaio 2004).
[GF99] Michael Gold e Tom Frisinger. GL ARB texture env add, 1999.
(http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture env add.txt, 27 Gennaio 2004).
136

BIBLIOGRAFIA 137
[GOL99] Michael I. Gold. Emboss bump mapping, 1999.
(http://developer.nvidia.com/object/emboss bump mapping, 12 Novembre 2003).
[HR94] David Halliday e Robert Resnick. Fisica 2. Ambrosiana, 1994.
[ISO85] ISO. The graphical kernel system (GKS), 1985. Technical Report ISO
7942.
[ISO88A] ISO. The graphical kernel system for three dimensions (GKS-3D), 1988.
Technical Report ISO 8805.
[ISO88B] ISO. The graphical kernel system (GKS) language bindings, 1988.
Technical Report ISO 8651.
[ISO89] ISO. Programmer’s hierarchical interactive graphics system (PHIGS),
1989. Technical Report ISO 9592.
[JÄH93] Bernd Jähne. Digital Image Processing. Springer-Verlag, 1993.
[KDL98] Martin Koch, Erik B. Dam e Martin Lillholm. Quaternions, interpolation
and animation, 1998.
[LAF99] Susan Laflin. History of computer graphics, 1999.
(http://www.cs.bham.ac.uk/˜slb/sem307/g11.html, 04 Dicembre 2003).
[MOR89] Michael E. Mortenson. Computer Graphics: An introduction to the
Mathematics and Geometry. Industrial Press Inc, 1989.
[NDW94] Jackie Neider, Tom Davis e Mason Woo. OpenGL Programming Guide.
Addison-Wesley, 1994.
[OPE03] OpenGL.org. OpenGL overview, 2003.
(http://www.opengl.org/about/overview.html, 05 Dicembre 2003).
[PGFH01] Bimal Poddar, Michael Gold, Tom Frisinger e Rick Hammerstone.
GL ARB texture env combine, 2001.
(http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture env combine.txt, 27 Gennaio 2004).

BIBLIOGRAFIA 138
[PVVF97] Jim Pitts, Martin van Velsen e Robin Fercoq. 3D-Studio File Format
(.3ds), 1997.
(http://thorkildsen.no/faqsys/docs/3ds2.txt, 13 Settembre 2003).
[SAA95] Janne Saarela. What is GKS (the Graphical Kernel System), 1995.
(http://wwwasdoc.web.cern.ch/wwwasdoc/gks html3/node6.html, 05 Dicembre 2003).
[SED93] Robert Sedgewick. Algoritmi in C++. Addison-Wesley, 1993.
[SIC58] Francesco Sicardi. Enciclopedia U.T.E.T., voce Luce, 1958.
[SMI95] Terry Smith. An introduction to PHIGS, 1995.
(http://terrysmith.net/archives/collegehomepage/research/phigs/phigs.html, 05 Dicembre 2003).
[STE01] Karl Steiner. History of ve, 2001.
(http://www.cs.unt.edu/ steiner/4330-VR/lecture1.html, 03 Novembre 2003).
[STE02] James Stewart. The OpenGL pipeline, 2002.
(http://www.cs.queensu.ca/home/jstewart/454/notes/pipeline/, 26 Dicembre 2003).