Desenvolupament de videojocs Cas pràctic de l'ús d'un motor de ...

Desenvolupament de videojocs
Cas pràctic de l’ús d’un motor de
videojocs pel desenvolupament de
les Obscurances en temps real
Desenvolupament del Projecte
per Jordi Catà Castillo
Enginyeria Informàtica
Escola Politècnica Superior
Universitat de Girona
Tutor : Mateu Sbert Casasayas
Departament : Departament d’Informàtica i
Matemàtica Aplicada

Versió del 01/09/2004 16:51:19
3

Minino de Cheshire,
¿podrías decirme, por favor, qué camino debo seguir para salir de aquí?
Esto depende en gran parte del sitio al que quieras llegar --dijo el Gato.
No me importa mucho el sitio... --dijo Alicia.
Entonces tampoco importa mucho el camino que tomes --dijo el Gato.
... siempre que llegue a alguna parte --añadió Alicia.
¡Oh, siempre llegarás a alguna parte --aseguró el Gato--, si caminas lo suficiente!
Alícia en el país de las meravelles
4

TAULA DE CONTINGUTS GENERAL
Taula de continguts
1. INTRODUCCIÓ ................................................................................................... 10
1.1. SITUACIÓ DEL PROBLEMA .............................................................................. 10
1.2. OBJECTIUS DEL PROJECTE............................................................................. 12
1.3. ESCTRUCTURACIÓ DELS CONTINGUTS........................................................... 13
2. DESENVOLUPAMENT DE VIDEOJOCS ....................................................... 14
2.1. L’EQUIP DE DESENVOLUPAMENT................................................................... 14
2.2 FASES EN EL DESENVOLUPAMENT D'UN VIDEOJOC, CICLE DE VIDA DEL
PROJECTE I DOCUMENTS ........................................................................................... 24
2.3 INTRODUCCIÓ A LA GESTIÓ I PLANIFICACIÓ DEL DESENVOLUPAMENT ....... 30
2.4 PARTS D’UN VIDEOJOCS................................................................................. 36
2.5 DESENVOLUPAMENT DE VIDEOJOCS.............................................................. 40
3. CAS PRÀCTIC: DESENVOLUPAMENT DE LES OBSCURANCES EN
TEMPS REAL .............................................................................................................. 57
3.1. ANÀLISIS: MODEL D’IL·LUMINACIÓ GLOBAL MITJANÇANT OBSCURANCES . 57
3.2. DISSENY.......................................................................................................... 65
3.3. IMPLEMENTACIÓ ............................................................................................ 80
3.4 RESULTATS I CONCLUSIONS........................................................................... 90
3.5 TREBALLS FUTURS ......................................................................................... 92
ANNEXES ..................................................................................................................... 94
ANNEX 1: HISTÒRIA DELS VIDEOJOCS/CONSOLES .................................................... 94
ANNEX 2: GENERES DE VIDEOJOCS ......................................................................... 102
ANNEX 3: M ERCAT DELS VIDEOJOCS ...................................................................... 106
ANNEX 4: FORMAT D’ESCENES DE CS ..................................................................... 107
ANNEX 5: CLASSES FUNCIONS PRIN CIPALS ............................................................. 111
ANNEX 5: CRECIÓ D’UNA APLICACIÓ EN CRYSTAL SPACE..................................... 121
BIBLIOGRAFIA ........................................................................................................ 128
REFERÈNCIES ...................................................................................................... 128
WEB ......................................................................................................................... 130
AGRAÏMENTS ........................................................................................................... 131
6

TAULA DE CONTINGUTS
Taula de continguts
1. INTRODUCCIÓ ................................................................................................... 10
1.1. SITUACIÓ DEL PROBLEMA .............................................................................. 10
1.1.1. Trasfons.................................................................................................. 10
1.1.2. Projecte previ.......................................................................................... 11
1.2. OBJECTIUS DEL PROJECTE............................................................................. 12
1.3. ESCTRUCTURACIÓ DELS CONTINGUTS........................................................... 13
2. DESENVOLUPAMENT DE VIDEOJOCS ....................................................... 14
2.1. L’EQUIP DE DESENVOLUPAMENT................................................................... 14
2.1.1 Producció............................................................................................... 14
Productor extern.................................................................................................. 15
Productor intern.................................................................................................. 15
Assistents i Productors associats ........................................................................ 15
2.1.2 Disseny ................................................................................................... 16
Dissenyador del joc............................................................................................. 17
Dissenyador de nivells........................................................................................ 17
L’escriptor........................................................................................................... 17
2.1.3 Programació........................................................................................... 17
Cap de programació............................................................................................ 18
Programadors...................................................................................................... 18
2.1.4 Art........................................................................................................... 20
Cap d’artistes ...................................................................................................... 20
Artistes................................................................................................................ 21
2.1.5 Testeig..................................................................................................... 22
Cap de testeig...................................................................................................... 22
Testejadors.......................................................................................................... 22
2.1.6 Recursos Externs ................................................................................... 22
2.2 FASES EN EL DESENVOLUPAMENT D'UN VIDEOJOC, CICLE DE VIDA DEL
PROJECTE I DOCUMENTS ........................................................................................... 24
Desenvolupar el Concepte .................................................................................. 24
Proposta de projecte............................................................................................ 25
Preproducció ....................................................................................................... 26
Desenvolupament ............................................................................................... 28
2.3 INTRODUCCIÓ A LA GESTIÓ I PLANIFICACIÓ DEL DESENVOLUPAMENT ....... 30
2.3.1 Planificació i calendaris........................................................................ 30
Abast ................................................................................................................... 31
Pressions externes............................................................................................... 31
Modificació de requeriments .............................................................................. 31
Optimisme dels desenvolupadors ....................................................................... 31
El problema irresoluble....................................................................................... 32
2.3.2 Escollint el millor model de cicle de vida per al desenvolupament d’un
videojoc 32
Cascada............................................................................................................... 32
Cascada modificada ............................................................................................ 33
Prototipatge iteratiu ............................................................................................ 33
2.3.3 Recuperació............................................................................................ 34
Estratègies innefectives ...................................................................................... 34
Estratègies efectives............................................................................................ 35
7

Taula de continguts
2.4 PARTS D’UN VIDEOJOCS................................................................................. 36
2.4.1 Sistema d’Entrada.................................................................................. 36
2.4.2 Sistema de Visualització........................................................................ 37
2.4.3 Sistema de So ........................................................................................ 37
2.4.4 Sistema de Xarxa ................................................................................... 38
2.4.5 Sistema d’Actualització.......................................................................... 38
2.4.6 Bucle principal....................................................................................... 38
2.5 DESENVOLUPAMENT DE VIDEOJOCS.............................................................. 40
2.5.1 Llibreries, motors gràfics i motors de videojocs ................................... 40
2.5.2 Llibreries ................................................................................................ 41
OpenGL .............................................................................................................. 41
OpenAL .............................................................................................................. 41
HawkLib ............................................................................................................. 41
Raknet ................................................................................................................. 42
Devil, Corona...................................................................................................... 42
Cal3D.................................................................................................................. 42
lib3DS ................................................................................................................. 42
SDL (Simple Direct Layer) ................................................................................ 42
Clanlib................................................................................................................. 42
2.5.3 Motor de videojocs ................................................................................. 42
Crystal Space ...................................................................................................... 44
Ogre .................................................................................................................... 51
Nebula Device 2 ................................................................................................. 52
Open Scene Graph.............................................................................................. 53
Irrlitch ................................................................................................................. 55
3. CAS PRÀCTIC: DESENVOLUPAMENT DE LES OBSCURANCES EN
TEMPS REAL .............................................................................................................. 57
3.1. ANÀLISIS: MODEL D’IL·LUMINACIÓ GLOBAL MITJANÇANT OBSCURANCES . 57
3.1.1. Model d’ il·luminació Obscurances sense fonts de llum...................... 58
3.1.2. Model d’ il·luminació Obscurances amb fonts de llum........................ 60
3.1.3. Model millorat de les obscurances (Color Bleeding) ........................... 61
3.1.4. Calculant les obscurances ..................................................................... 62
3.2. DISSENY.......................................................................................................... 65
3.2.1. Fases en la implementació de les Obscurances en temps real ............. 65
3.2.2. Lightmaps............................................................................................... 65
3.2.3. Càrrega i Estructuració de l’escena: Voxels........................................ 70
3.2.4. Algorisme per calcular les Obscurances............................................... 71
Voxel origen del raig .......................................................................................... 72
Llançament de raigs............................................................................................ 73
Calculant i aplicant les Obscurances al patch origen del raig ............................ 76
Inicialització de les estructures per a les Obscurances en temps real................. 77
3.2.5. Exemple pas a pas.................................................................................. 78
3.3. IMPLEMENTACIÓ ............................................................................................ 80
3.3.1 Relació entre classes .............................................................................. 80
3.3.2 Seqüència d’execució bàsica................................................................. 81
3.3.3 Aplicació walktest .................................................................................. 82
3.3.4 Classe csEngine ..................................................................................... 84
3.3.5 Diagrama de seqüències: inicialització estructures ............................. 85
Càrrega de les dades ........................................................................................... 86
Estructuració de l’escena en Voxels ................................................................... 87
3.3.6 Diagrama de seqüències: càlcul obscurances ...................................... 88
8

Taula de continguts
Aplicar les Obscurances al patch........................................................................ 89
3.4 RESULTATS I CONCLUSIONS........................................................................... 90
3.4.1 Captures de pantalla.............................................................................. 90
3.4.2 Resultats................................................................................................. 92
3.4.3 Conclusions............................................................................................ 92
3.5 TREBALLS FUTURS ......................................................................................... 92
ANNEXES ..................................................................................................................... 94
ANNEX 1: HISTÒRIA DELS VIDEOJOCS/CONSOLES .................................................... 94
Els principis ........................................................................................................ 94
Evolució de les videoconsoles (1972-2001)....................................................... 95
La dècada dels clàssics (1978-1988) .................................................................. 99
ANNEX 2: GENERES DE VIDEOJOCS ......................................................................... 102
Aventures.......................................................................................................... 102
Acció ................................................................................................................. 102
RPGs (Role-playing games)............................................................................. 102
Estratègia .......................................................................................................... 103
Simulació .......................................................................................................... 103
Esports .............................................................................................................. 104
Lluita................................................................................................................. 104
Jugar a ser Deu.................................................................................................. 104
Jocs online ........................................................................................................ 105
Educatius........................................................................................................... 105
Puzzles .............................................................................................................. 105
Jocs de casualitat............................................................................................... 105
ANNEX 3: M ERCAT DELS VIDEOJOCS ...................................................................... 106
ANNEX 4: FORMAT D’ESCENES DE CS ..................................................................... 107
Definició textures.............................................................................................. 107
Definició materials............................................................................................ 107
Definició Malles ............................................................................................... 108
Definició sectors ............................................................................................... 108
Definició inicial de l’escena ............................................................................. 109
Exemple de fitxer en format CS ....................................................................... 109
ANNEX 5: CLASSES FUNCIONS PRIN CIPALS ............................................................. 111
Classe raig......................................................................................................... 111
Classe Patch...................................................................................................... 112
Classe PatchList................................................................................................ 113
Classe ObsPoly................................................................................................. 113
Classe ObsPolyList........................................................................................... 115
Classe Voxel..................................................................................................... 116
Classe VoxeList ................................................................................................ 117
Classe Obscurance ............................................................................................ 118
Classe ObsCube ................................................................................................ 119
Classe csEngine ................................................................................................ 120
Classe Walktest................................................................................................. 120
ANNEX 5: CRECIÓ D’UNA APLICACIÓ EN CRYSTAL SPACE..................................... 121
BIBLIOGRAFIA ........................................................................................................ 128
REFERÈNCIES ...................................................................................................... 128
WEB ......................................................................................................................... 130
AGRAÏMENTS ........................................................................................................... 131
9

1. Introducció
Introducció
El present document és la memòria del projecte anomenat “Desenvolupament de
videojocs cas pràctic de l’us d’un motor de videojocs per desenvolupament de Real-
Time Obscurances”. En aquesta memòria es recull la presa de decicions de totes les
fases d’anàlisis, disseny i implementació, així com tot el que implica desenvolupar un
videojoc. En el manual d’usuari s’explica com compilar, instal·lar i executar el
projecte.
1.1. Situació del problema
1.1.1.Trasfons
Els gràfics per computador han estat una àrea popular en les ciències de la computació
en les últimes dècades. Gran part de la recerca en aquest camp s’ha destinat a obtenir
imatges el més realistes possibles [8][9], però generar aquestes imatges tant realistes té
un preu. Ens els seus inicis els algorismes tendeixen a ser computacionalment costosos i
solen ser implementats en hardware gràfic específic que normalment tenen uns elevats
preus, per tant únicament les universitat i empreses que es dediquem a temes de gràfics
per computador poden assolir. Però tot i haver aquesta limitació inicial de que els
ordinadors personals (de gamma baixa) assolibles per el públic en general no han tingut
molta potència per a produir imatges realístiques, els videojocs han tingut molta
popularitat durant dècades, com podem veure en l’annex 1.
Els dissenyadors i programadors de videojocs han hagut de ser creatius per a poder
produir entorns immersius amb una alta jugabilitat de tal manera que els jugadors no
tinguessin en compte les imatges de baixa qualitat produïdes pels ordinadors de gamma
baixa.
A mesura que ha passat el temps la tecnologia ha anat millorant, la demanda per
videojocs més realistes i amb interacció en temps reals està en augment. Juntament amb
la millora de la tecnologia, la millora dels gràfics, els grups de jugadors han evolucionat
d’un nombre petit d’individus a grans segments de la població. Un dels videojocs més
populars, de més èxit, i més venut va ser Myst, creat i produït per Cyan Productions i
publicat per Broderbund. Aquest joc i d’altres similars van mostrar que era possible
accedir a un nou mercat a través dels videojocs. Un mercat que incloïa als consumidors
generals, no únicament els “adictes” als computadors. L’increment de la demanda de
videojocs i el potencial del mercat ha creat un nou impuls per incrementar la velocitat,
capacitat i potència de la tecnologia.
Un resultat del increment de la demana ha estat l’evolució de les targes gràfiques que
han passat a accelerar per hardware gran quantitat de càlculs que anteriorment es feien
per software (CPU). Les targes gràfiques inicials només estaven preparades per treballar
o bé en 3D (funcionaven únicament a pantalla complerta) o bé 2D (utilitzades
únicament per interfícies estàndards). Les generacions posteriors van ser dissenyades
per treballar tant en 3D com en 2D i podien treballar en mode finestra (no
necessàriament a pantalla complerta). Des de que la rasteritzation dels triangles ha estat
10

Introducció
el major coll d’ampolla en els software de rendering, les targes gràfiques van actuar
com a ràpides rasteritzation de triangles. La següent evolució de targes gràfiques va ser
dissenyat per poder fer més càlculs per segon, en particular fer transformacions de
vèrtexs i càlculs d’il·luminació per hardware. En aquest punt es on es comença a parlar
de GPU (Graphic Procesing Unit) per tant els ordinadors passen a tenir dos
processadors molt potents, un per als càlculs generals (CPU) i l’altre per les operacions
gràfiques específiques (GPU).
Un altre resultat de l’ increment de la demanda dels videojocs ha estat l’evolució de les
CPUs per incloure suport a operacions que típicament existeixen en aplicacions 3D:
divisions ràpides, arrels quadrades inverses (per normalitzar vectors) i paral·lelismes
que ajuden a transformar vèrtexs i calcular productes vectorials. Moltes empreses estan
actualment explotant noves vies per utilitzar la tecnologia 3D en aplicacions que no son
videojocs com per exemple en Comerç electrònic i plugins per aplicacions empresarials.
Actualment l’imparable avanç tecnològic ens ha portat a les noves generacions de targes
gràfiques amb la capacitat de poder ser programades on the fly via vertex i pixel shaders
establint un gran paral·lelisme entre la CPU i la GPU. Per tant sobre un nou horitzó en
el camp dels gràfics per computador.
Actualment les targes gràfiques suporten de l’ordre de 100 milions de triangles per
segon.
Degut al gran paral·lelisme entre CPU i GPU, la CPU es pot encarregar de tasques
específiques com la detecció de col·lisions, física, intel·ligència artificial, etc, mentre
que de la part gràfica s’encarrega la GPU. No hem d’oblidar que la CPU s’encarrega d’
enviar les dades a la GPU.
A part de la gran evolució en el mon dels gràfics/videojocs, el seu mon mou més diners
que la indústria del cinema, tal i com comentem en l’annex 3.
1.1.2.Projecte previ
No obstant la gran potència que van adquirint les noves tecnologies, hi ha càlculs que
segueixen sent costosos de realitzar. Dins d’aquests càlculs costosos podem trobar els
algoritmes de radiositat que simulen la il·luminació difusa d’una escena. El càlcul de la
radiositat per un quadre d’una animació pot portar hores i hores de preprocesament ja
que molts dels esforços realitzats en el càlcul es destinen a la resolució de grans
sistemes d’equacions, consumint molts recursos tant de CPU com de memòria al haver
de calcular les aportacions de tots el patchs contra tots els patchs determinats per
obtenir imatges molt realistes on es poden apreciar les reflexions difuses, el color
bleeding entre superfícies, les penombres que apareixen en els límits de les ombres,
ombres molt realistes, etc..
El desenvolupament de les Obscurances sorgeix com a alternativa a la radiositat, ja que
simplifica els càlculs d’aquesta però els resultats finals son pràcticament idèntics.
Podem veure una primera implementació en el projecte fi de carrera de Margarita
Garcia i Teixidor: “Implementació i millora del mètode d’il·luminació global mitjançant
obscurances” [14]. En el que es proposa una implementació de les obscurances dins el
11

Introducció
paquet RenderPark. En aquest anterior projecte podem veure una comparativa entre el
mètode de la radiositat i el nou mètode, aquí exposat, de les Obscurances.
1.2. Objectius del projecte
Com hem comentat en els apartats anteriors, els videojocs han evolucionat molt des de
que van sorgir els primers. En les primeres èpoques els videojocs eren molt ràpids de
desenvolupar degut a la seva simplicitat (bastava una persona durant unes setmanes per
finalitzar-ne un), mentre que en l’època actual crear un videojoc és un projecte ambicios
portat a terme per uns equips pluridisciplinars durant un llarg període de temps (de 6
mesos a 2 anys de mitja). A més la indústria dels videojocs mou més diners que la
indústria del cinema, tal i com podem veure en l’annex 3.
Podriem resumir un videojoc com:
? Software innovador.
? Software creatiu.
? De gran complexitat (penseu en jocs del tipus Shenmue, Doom 3 o Quake 3)
? Intervenen multitud d’àrees de coneixement.
? És un Mercat en expansio.
L’objectiu del projecte està en conèixer a fons tot el que implica un desenvolupament
d’un videojoc, des de les persones implicades, el cicle de vida, llibreries per ajudar al
desenvolupament, i per últim està en la implementació de la tècnica d’il·luminació
anomenada Obscurances en temps real en un motor de videojocs.
La implementació de les Obscurances ens servirà per realitzar una aproximació pràctica
del funcionament d’un motor de videojocs.
Fent un resum dels objectius trobem:
• Desenvolupament de videojocs
o Equip de treball.
o Cicle de vida del desenvolupament d’un videojoc.
o Parts de les que és composa un videojoc.
o Llibreries i motors gràfics per ajudar al desenvolupament.
• Cas pràctic d’utilització d’un motor gràfics
o Estudi de les Obscurances
o Estudi del motor Crystal Space
o Implementació de les Obscurances en temps real en el Crystal Space.
12

1.3. Esctructuració dels continguts
Els diferents capítols de que consta aquest dossier son els següents:
Tema 1: Introducció (aquest capítol).
Introducció
Tema 2: Desenvolupament de videojocs. Expliquem quines son les fases en el
desenvolupament d’un videojoc així com les persones implicades, les parts que formen
un videojoc a més d’explicar diferents llibreries i motors gràfics que s’utilitzen pel
desenvolupament.
Tema 3: Desenvolupament del projecte, on realitzarem un desenvolupament pràctic,
el mètode d’il·luminació anomenat Obscurances, utilitzan un motor gràfic, s’analitzen
des del punt de vista d’anàlisis, disseny i implementació, valoració dels resultats
obtinguts i els treballs futurs.
Annexes: Els annexes recullen tota la informació que hem trobat interessant respecte el
projecte però que no te una importància molt rellevant per al desenvolupament del
mateix.
Bibliografia: s’enumeren les fonts de referència que hem utilitzat per la realització del
projecte.
13

2. Desenvolupament de videojocs
Projecte
Un videojoc és un programari molt complex [4], en el que intervenen gran quantitat de
recursos, tant materials com humans. El desenvolupament d’un videojoc mínimament
comercial (amb una certa qualitat d’innovació, jugabilitat, impacte visual i complexitat)
és un procés llarg, habitualment solen tardar d’un a dos anys en finalitzar-se, en el que
cal una bona planificació i gestió de tots els recursos disponibles. Podríem dir que un
videojoc equival a la producció d’una pel·lícula, però tenint en compte que en la
pel·lícula del videojoc el personatge principal serà el jugador.
En aquest apartat analitzarem les persones involucrades en la realització d’un videojoc,
com hem comentat anteriorment estem en la categoria d’un videojoc mínimament
complex on no hi tenen cabuda videojocs del tipus web (flash) o videojocs simples que
poden ser realitzats per una persona en poc temps (mesos), parlem dons de projectes de
videojocs que serien comparables a grans projectes d’enginyeria del programari. També
parlarem del cicle de vida de la producció d’un videojoc, d’una petita introducció a la
planificació i gestió, i per últim entrarem en detall en l’estructura interna d’un videojoc
(els subsistemes que en formen part) i de les eines/llibreries/motors per tal de
desenvolupar cada subsistema, passant per una comparativa dels motors de videojocs
que és poden utilitzar en el desenvolupament.
2.1. L’equip de desenvolupament
Com en qualsevol altre projecte de desenvolupament, ja sigui projectes de construcció,
ja sigui projectes de desenvolupament de software, hi ha diferents persones amb
diferents perfils especialitzats que s’encarreguen de petites parts del projecte [3][4][5].
Les diferents persones/equips en les que és divideix el projecte d’un videojoc son:
1. Producció
2. Disseny
3. Programació
4. Artistes
5. Testeig
2.1.1 Producció
El productor és la persona encarregada d’explicar les parts fortes del nostre videojoc,
tant al departament de vendes, com a marketing. Entén com el joc participa en els
objectius de la companyia i pot explicar el per que és bo mantenir la producció en
desenvolupament. Algunes empreses l’anomenen director de projectes, cap de projectes
o director.
14

Projecte
S’encarrega també de controlar que les diferents tasques s’acabin en els terminis
previstos, controla els riscos que poden sorgir durant el desenvolupament, etc.
Alguns dels riscos que poden sorgir son:
• Què passa si l’entorn de desenvolupament no arribà en el temps previst ?.
• Què passa si la programació de la “intel·ligència artificial” té un cost de temps
superior al temps que es va planificar ?
• Què passa si un programador del motor gràfic es retarda amb una característica
especial ?.
Les diferents persones en el grup de Producció són:
• Productor extern
• Productor intern
• Productor associat o assistent
Productor extern
Treballa per a un publicador i es responsabilitza per a que l’empresa que desenvolupa
el joc compleixi els terminis previstos amb les característiques esperades. Una altra
funció del productor extern està en aprovar pagaments, encarregar-se de la compra de
hardware necessari pel desenvolupament, en general d’aportar a l’equip de
desenvolupament tot el necessari per que pugin generar el desenvolupament.
Productor intern
Gestiona tot l’equip de desenvolupament directament i notifica de l’estat actual a
l’empresa (normalment per a la que treballa l’equip de desenvolupament) o un
publicador extern.
Gestiona l’equip de desenvolupament i el representa al mon exterior (incloen els
publicadors, marketing i departament de compres). Algunes empreses l’anomenen
director de projectes, cap de projectes o director.
Assistents i Productors associats
Els objectius d’aquest paper dins la tasca de producció varia d’un equip a un altre. Però
les missions que principalment desenvolupa son:
• Gestió d’actius. Gestiona les diferents versions de documents / fitxers que
apareixen durant el desenvolupament. Controla les versions que hi ha en els
diferents servidors de l’empresa, etc.
15

Projecte
• Supervisió de les compilacions diàries i les copies de seguretat. Els assistents
tenen l’objectiu de supervisar que cada dia és realitzin copies de seguretat de tots
els documents / fitxers que s’originen.
• Manteniment del disseny de la web. Una manera pràctica i ràpida de disposar
de tota la informació referents als diferents equips de treball, les seves tasques,
els punts on estan dintre d’aquestes tasques, etc, és via una Intranet. En la
intranet els diferents components de treball poden veure en quins punts/tasques
estan els altres equips de treball d’una manera ràpida. La persona encarregada de
mantenir aquesta informació “actualitzada” sol ser habitualment el productor
associat.
• Generació de “pantalles” del joc i donar suport al productor. Quan un joc és
anunciat al públic, moltes vegades hi ha una forta demanda de “pantalles” del
joc. És tracta doncs de generar “pantalles” interessants, mostrar els “bocetos” del
joc, etc. Intentant sempre mostrar les millors “pantalles” per tal de que el públic
consideri el joc un dels millors jocs desenvolupats. Una altra funció dels
productors associats/assistents està en preparar les demos que és posaran a
disposició del públic, de les revistes especialitzades, etc.
• Revisió de les etapes importants en el desenvolupament. Quan una etapa és
considera tancada, és feina del productor associat controlar que els diferents
materials superen els requeriments establerts, per tal d’assegurar que la qualitat
final és bona.
• Altres tasques no contemplades. Hi ha infinitat de petites tasques que no es
contemplen durant el desevnolupament. Habitualment recau sobre el productor
associat la responsabilitat de dur-les a terme. Un exemple seria demanar pizzes
per a l’equip de desenvolupament per a sessions nocturnes de treball, preparar
les màquines per a enviar-les a fires de videojocs, etc.
2.1.2 Disseny
El dissenyador del joc (que a vegades actua com escriptor) s’encarrega de crear el
document de disseny i l’actualitza a mesura que avança el desenvolupament.
Documenta els mecanismes de jugabilitat del joc i també avalua noves idees per
determinar si enriqueixen o no al joc.
El dissenyador treballa amb els artistes del storyboard per dissenyar la introducció, les
pel·lícules i curts intermedis. Si actua també com a escriptor, crearà tots els diàlegs del
joc i probablement realitzarà els primers esquemes del manual. Si no actua com
escriptor, llavors dirigirà a un escriptor professional que farà la feina d’escriure els
dialegs, guió, etc.
El dissenyador habitualment dirigeix a l’equip de disseny de nivells. Crea el flux del joc
i dirigeix l’equip de disseny de nivells per a que creï les petites unitats que s’afegiran al
flux.
Al mateix temps l’equip de disseny col·labora amb el departament de programació per
construir la web del videjoc i amb el departament de marketing per crear la publicitat,
els fulls informatius del joc, les caixes del joc, etc.
16

Està compost per els següents rols:
• Dissenyador del joc
• Dissenyador de nivells
• L’escriptor
Dissenyador del joc
Projecte
El dissenyador del joc és la persona responsable de dissenyar un videojoc que
entretingui als jugadors. Habitualment, però no sempre, el dissenyador del joc és la
persona que té la idea inicial del que serà el videojoc (té la pel·lícula en el seu cap). És la
persona encarregada de filtrar les noves idees aportades per els diferents elements de
l’equip i ha de ser capaç de decidir si les noves idees aporten millores o no al joc.
Molts videojocs solen incorporar llenguatges de script per tal permetre que els
dissenyadors puguin provar les seves idees directament contra el joc i no requereixin de
coneixement tècnics de programació.
Dissenyador de nivells
És la persona encarrega de dissenyar els diferents nivells del joc, de generar els diferents
elements interconnectats del flux del joc.
L’escriptor
Desenvolupa els diferents diàlegs que apareixen durant el joc, ja sigui quan el
personatge principal interactua amb altres personatges o bé quan realitza determinades
accions.
2.1.3 Programació
Els programadors són les persones encarregades de transformar els diferents models,
textures, nivells, guions en la realitat que serà el programa informàtic que entetindrà als
diferents jugadors.
En aquest equip destaquem els diferents rols:
• Cap de programació
• Programadors
17

Cap de programació
Projecte
El cap de programació té un paper important en el desenvolupament del videojoc. Està
present en les primeres etapes del desenvolupament juntament amb el productor,
dissenyador i el cap d’artistes.
La primera tasca del cap de programació és en inspirar a l'equip de programadors de que
el videojoc és tecnicament factible i mostrant les àrees d'innovació/reptes per l'equip. La
següent tasca està en la plataforma per la que es desenvoluparà (pc, xbox, playstation
2,...), d'aquesta manera es crearà un programari que aprofitarà les avantatges de cada
plataforma i compensarà les mancances.
Durant la fase de preproducció, el cap de projectes crea el pla tècnic on s’enumera les
diferents tasques a desenvolupar i estima la planificació/terminis, treballadors, etc, que
calen per completar el projecte.
Durant la fase de producció gestiona les diferents tasques dels programadors i la seva
planificació i explica l'estat actual de les fases de desenvolupament al productor, si té
temps també programarà algunes parts de l'aplicació.
Programadors
Els programadors son les persones encarregades de donar vida als diferents models,
textures, nivells del videojoc. Solen treballar conjuntament amb els dissenyadors per tal
d'evitar confusions a la hora d'entendre l’esència del joc.
Hi ha diferents àrees dintre de l'equip de desenvolupament, habitualment els
programadors solen tocar diferents àrees al mateix temps. A continuació mostrem
algunes dels diferents apartats:
• Motor de rendering
• Intel·ligència artificial
• Física
• Eines
• Base de dades
• Xarxa i multijugador
• Efectes gràfics
• Efectes de só
• Llenguatges d'script
• Lògica del joc
• La interfície d'entrada/sortida
Motor de rendering
Consisteix en tot el motor que permet mostrar/visualitzar els diferents elements del joc
(personatges, edificis, ...). Es a dir és la part que “dibuixa” en la pantalla els escenaris,
personatges, etc, i permet que els jugadors pugin veure per la pantalla aquests elements.
18

Intel·ligència artificial
Projecte
El comportament dels personatges que no controla cap jugador estarà guiat per diferents
algorismes de IA. La planificació de rutes del personatge (per exempe, per on passarà
per anar del punt A al punt B dins el mapa el personatge) per tal de que no passi per
zones “prohibides” com parets, cotxes, etc.
Física
S'encarregarà de tot els càlculs matemàtics destinats per exemple a trobar la velocitat del
vehicle, trobar les forces que fan que el vehicle derrapi, a la detecció de colisions del
personatge amb l'entorn, etc.
Eines
Per tal de facilitar la feina a les persones no programadores, es desenvolupen un seguit
d'eines que ajuden per exemple a crear les textures dels personatges, els nivells del joc,
per modificar els scripts que controlen el comportament dels personatges, etc.
Base de dades
S'encarrega de totes les tasques relacionades a guardar la informació dels estats dels
diferents personatges en un moment determinat. Són comuns en tots els jocs les opcions
de guardar la partida per posteriorment recuperar-la.
Xarxa i multijugador
La seva funció és la de donar suport al joc simultani entre diferents jugadors a través de
la xarxa o bé a diferents jugadors jugant al mateix temps en la mateix màquina (cas típic
del joc amb pantalla partida, una part per cada jugador). Tot i que cada cop més s’exten
més la opció del multijagador en xarxa encara a dia d’avui les noves videoconsoles
permeten l’opció de multijugador en la mateixa màquina (cas de la GameCub que
permet 4 jugadors i la Xbox que en permet 2).
Efectes gràfics
Durant el joc hi han efectes gràfics que simulen per exemple el foc, els llamps, la pluja,
els reflexes, etc. Tots aquets efectes especials es desenvolupen en aquesta part.
19

Efectes de só
Projecte
Al igual que en els efectes gràfics, els efectes de só simulen efectes, en aquest cas
sonors resultat d'algun event del jugador, alguna acció dels personatges no jugadors,
dels trets d'armes de focs, etc.
Llenguatges de script
Amb el mateix objectiu que l'apartat d'eines, els llenguatges de script són una manera
comoda de que persones sense coneixement de programació puguin modificar el
comportament per exemple dels enemics del joc, canviar l'aspecte dels personatges, etc.
Lògica del joc
És on es connecta els diferents mòduls (física, so, gràfics, scripts, rendering, etc) d'una
manera seqüencial per tal de donar vida al videojoc.
Interfície d'entrada/sortida
Aquesta part té com objectiu comunicar al jugador amb el joc, ja sigui mitjançant el
teclat, el ratolí, el joystick, el pad, etc, en resum té com objectiu desenvolupar els
mecanismes per al control per part del jugador del videojoc.
2.1.4 Art
L'equip dedicats a l'art té com objectiu donar al videojoc l'aspecte contemplat en el
disseny del joc. Aquest aspecte pot anar des del disseny de les interfícies de les pantalles
fins a la representació del mon en la pantalla, passant pels efectes especials, el
modelatge dels personatges, etc.
En aquest equip destaquem els diferents rols:
• Cap d'artistes
• Artistes
Cap d’artistes
Aquesta persona dins l'equip de desenvolupament del joc és el responsable de l'aspecte
del joc, hi està a mig camí entre l'equip de disseny, l'equip de programació, i l'equip de
gestió. La seva funció està en analitzar el que dessitja el dissenyador, treballar amb el
cap de programació per establir el camí de producció i determinar l'abast de les tasques
20

Projecte
artístiques, com pot ser determinar el nombre de treballadors necessaris d'un tipus
concret, el temps per realitzar les diferents fases, etc.
Quan treballa amb el dissenyador el seu objectiu està en establir l'aparença/estil del
videojoc que s'utilitzarà per les interfices, els menus, els personatges, els entorns, etc.
Tot aquest estil s'afegirà a un document anomentat la guia d'estils, on es recolliran els
recursos visuals que tots els artístess consultaràn quan vulguin crear nous materials /
conceptes del joc.
Quan treballa amb el cap de programació, tots dos creen el camí de producció intentant
que les eines per generar continguts dels artistes permetin veure els resultats el més
ràpidament possible dintre del joc (ja sigui a partir de scripts, eines fetes a mida, etc).
Artistes
Els artístes son les persones encarregades de desenvolupar els nous materials,
personatges, interfícies, etc, seguint la guia d'estils.
Dintre d'aquest grup trobem tres tipus de dedicacions:
• Concepte
• Modeladors de personatges
• Animadors
• Modeladors de fons
• Textures
Conceptes
Els artistes de conceptes treballen amb el dissenyador per crear l'aparença del joc via
“esbos” dels personatges, de les pantalles, etc.
Modeladors de personatges
Els modeladors dissenyen i creen els personatges, criatures i objectes utilitzant paquets
3D com poden ser el 3D Studio Max o Maya.
Animadors
Els animadors fan possible que els personatges dissenyats pels modeladors cobrin vida.
S’encarregen de crear els moviments que faran els personatges, criatures, objectes, etc.
Modeladors de fons
Construeixen el mon per el que els personatges es mouran, combinant objectes, textures,
il·luminació, etc.
21

Textures
Projecte
Son els creadors de les textures dels diferents personatges que es colocaran sobre els
models, a les imatges de fons, etc.
2.1.5 Testeig
Els testers son una part fonamental en tot desenvolupament degut a la seva tasca
continua de trobar els diferents errors/problemes que poden sorgir en la programació, en
conseqüència de descuits de l'equip de programadors.
Cap de testeig
La funció del cap de testers està en coordinar l'equip de treball que provarà totes les
característiques del videjoc, intentant trobar errors fruit d'un descuit per part dels
programadors.
Al començament del projecte, el seu paper es bassa en aportar un feedback cap als
programadors, per tal de que arreglin els erros, millorin la jugabilitat, etc.
Quan el videojocs es va aproximant a la versió alpha (fase on el videojoc és poc jugable
de començament a fi), es dedica a preparar el pla de testeig (pren com a partida el
document de disseny), a partir del qual es buscarà fallades en el joc. El cap de testers ha
d'estar en sincronia amb el dissenyador i els programadors ja que ha de saber en tot
moment l'estat actual del joc.
Testejadors
Els testers són les persones que proven el videojoc, i troben les possibles mancances en
jugabilitat, usabilitat, divertiment, requeriments, etc. Els testers proven el joc de moltes
maneres diferents, sempre intentant emular la infinitat de tipus de persones que jugaran
al joc.
2.1.6 Recursos Externs
Hi ha una serie de recursos que es solen subcontractar a empreses especialitzades o a
professionals independent per tal de dotar al joc d'un ambient “cinematogràfic” en el só,
la música, etc.
Alguns recursos externs solen ser:
• Veu dels personatges
• Música
22

• Efectes de só
• Vídeo
• Manual
• Normativa legal
Projecte
23

Projecte
2.2 Fases en el desenvolupament d'un videojoc,
Cicle de Vida del projecte i Documents
Alguns jocs són desenvolupats ens sis mesos, d’altres en molts anys [4][5][6]. Però cada
videojoc desenvolupat passa per una sèrie de fases ben definides que han esdevingut
estàndards en la indústria.
A l’igual que en qualsevol projecte de enginyeria del programari, el desenvolupament
d’un videojoc té una sèrie de fases. A continuació expliquem el cicle de vida.
Desenvolupar el Concepte
Figura 2.2.1: Cicle de vida desenvolupament videojocs
L’objectiu principal d’aquesta fase es la decidir com serà el nostre videojoc, es a dir,
determinarem els diferents elements de jugabilitat del joc, crearem el concepte artístic
per mostrar com serà el joc i quin aspecte gràfic tindrà, a més de determinar la història
que l’envolta, tot es realitza a partir de la idea original del joc. El resultat d’aquesta fase
serà un document que servirà per la següent fase de proposta de projecte que
correspondria a la fase d’estudi de requeriment en l’enginyeria del programari.
El grup de persones que desenvolupen aquesta fase sol ser petit. Està format bàsicament
per un dissenyador, el cap de projectes tecnològic, un artista creatiu i un productor.
24

Proposta de projecte
Projecte
La proposta de projecte és el document que s’utilitza per desenvolupar el nostre
videojoc. Conté en poques pàgines informació sobre el joc, el per què serà un èxit de
mercat i com farà diners. El document es dividit en diferents seccions:
• High Concept
• Característiques
• Història
• Mecanismes de jugabilitat
El High Concept
El concepte general del joc o High Concept és la idea que defineix el nostre videojoc.
Podríem definir-lo com el “ganxo” que fa al nostre joc més excitant i el diferencia de la
competència.
Un High Concept fort ens ajuda durant la fase de desenvolupament perquè és útil per
decidir quines característiques incloure o quines deixar fora del nostre videojoc.
Característiques
És la llista de característiques del que faran al nostre joc excepcional, és a dir, des de
quina tecnologia gràfica utilitzarem, per exemple si utilitza els últims algorismes de
il·luminació realista, l’estil dels gràfics, si utilitza so envolvent dobly per exemple, etc.
Normalment aquesta llista de característiques es la que apareixerà en la part posterior de
la caixa del joc.
La Història
Aquesta part és un resum dels diferents personatges del joc (tant els principals siguin
bonx o dolents, com els secundaris), com guanyaran els bons als dolents. A més inclou
la història que envolta el videojoc.
Mecanismes de jugabilitat
Descriu el que fan els personatges, com interactiuen i com s’utilitzen dins el joc.
Aquesta part depen del gènere del videojoc.
25

Preproducció
Projecte
L’objectiu d’aquesta fase és la de completar el disseny del joc, crear els conceptes
artístics, establir la planificació, el pla de projecte, i fer prototipus tècnics que demostrin
la factibilitat d’utilitzar les noves tecnologies que nosaltres desitgem fer servir en el
desenvolupament del nostre videojoc.
Si som uns desenvolupadors independents, els nostres publicadors poden utilitzar
aquesta fase com una presa de contacte per tal de determinar si ens ajustem a les seves
expectatives, per exemple als temps d’entrega.
Els resultats d’aquesta fase són diferents documents i diferents prototipus del producte
final.
Les diferents fases que composen la preproducció són:
• Disseny del videojoc
• Compendi artístic
• Camí de producció
• Disseny tècnic
• Pla de projecte
• Prototipus
Document de disseny del videojoc
Al final de l’etapa de preproducció obtindrem un document anomenat document de
disseny que explica d’una manera detallada com serà, en que consistirà el videojoc, es a
dir contindrà les diferents especificacions de requeriments a partir de les quals
elaborarem el pla tècnic. La combinació d’aquest dos documents ens servirà per crear el
pla de projecte.
Durant la fase de desenvolupament, aquest document de disseny ens servirà per
determinar les diferents experiències del jugador dins el joc. Incorporarà diferent
informació de la jugabilitat, la interfície d’usuari, la història, els personatges, els
monstres, la intel·ligència artificial, etc, és a dir incorporarà tots els detalls que ens
ajudin a entendre el que s’espera del joc.
Compendi artístic
Els artistes durant el cicle de preproducció estableixen la imatge de com serà visualment
el joc. La idea d’aquesta fase està en establir un estil unificat per a tots els artistes
involucrats a partir d’un compendi d’imatges que ens reflecteixin quin és l’estil visual
del joc, com són els personatges, les escenes, etc.
26

El camí de producció
Projecte
S’entén per camí de producció els passos necessaris per passar de la idea (la persona
que te la idea brillant de com serà el videjoc) a la realitat (el programa d’ordinador).
Necessitem trobar la manera més eficient de passar de les especificacions de disseny,
als sketchs de conceptes, als models 3D, a les textures pel model 3D, a l’animació del
model, a aplicar Intel·ligència Artificial al personatge, fins a que tenim el personatge 3D
dins el joc i podem moure’l.
Tots aquest seguit de passos requereixen d’una sèrie d’eines, des d’editors de textures,
fins a modeladors 3D. Però tots han de compartir una característica entre ells:
compatibilitat. Tots han de ser compatibles entre la fase anterior i posterior, d’aquesta
manera facilitem els passos d’importar / exportar entre una eina i la següent.
En la fase de preproducció es treballen tots aquest aspectes. Els costos de comprar les
eines necessàries o bé construir-les han de ser inclosos dins el pla de projecte.
Document de disseny tècnic
L’objectiu d’aquest document està en transformar el document de disseny de paraules a
software. Estableix el camí de producció, mostra les diferents tasques de totes les
persones implicades en el desenvolupament i estima els temps per completar cada una
de les tasques. Descriu també les eines que s’utilitzaran per construir el videojoc,
especificant en detall quines eines són internes, quines es desenvoluparan
específicament per aquest joc i quines es compraran. S’inclou també la llista del
hardware necessari a comprar així com els canvis necessaris en la infrastructura de
l’empresa (velocitat de la xarxa, copies de seguretat, etc) per tal de donar suport al
desenvolupament.
Pla del projecte
Ens descriu com construirem el nostre videojoc. Consisteix en la planificació de totes
les tasques, estableix les dependències entre totes elles, té en compte les hores extres, en
definitiva transforma tots els aspectes implicats en una planificació real. El projecte
final està dividit en el pla de recursos, el pressupost i la planificació.
El pla de recursos és una fulla de càlcul que inclou una llista de tot el personal que
participa en el projecte, quan començaran, i com s’aplicaran els seus salaris al projecte.
Pren com a partida el document tècnic, el temps d’adquisició del hardware i estima els
costos externs (veu, musica, vídeo) que influiran en el pressupost.
El pla de projecte ha de ser actualitzat a mesura que avança el projecte. Existeixen
programes per gestionar projectes que ens poden ajudar a la planificació. Alguns
d’aquest programes son el Mr.Projecte, KProject, KPlanner, etc.
27

Projecte
El pla de projecte també especifica les dates en les s’han d’acabar les tasques. Hem
d’anar en compte amb dates molt estrictes, ja que una mala planificació pot portar al
incompliment d’aquestes; a més d’aquestes dates depenen altres departaments, per
exemple el de Marketing que pot començar a fer campanyes de publicitat, pot començar
a negociar amb revistes per a cobrir la història. Un altre departament afectat pot ser el de
vendes que pot haver negociat amb les distribuïdores les dates en les que el producte
estarà disponible. Per tant una errada en el compliment de les dates pot ocasionar moltes
pèrdues en les ventes, a part de perdre temps i diners en les tasques que realitzen tots els
departament implicats.
Prototipus
El resultat de tota la fase de preproducció és el prototipus. Normalment és un petit
programa que captura en una pantalla l’essència que fa que el videojoc sigui especial i
es diferencií de la competència. Podem trobar també com a prototipus material
prerenderitzat que serà renderitzat en temps real durant el joc, com també podem trobar
petites demostracions de que la tecnologia que volem desenvolupar és factible en temps
real. Aquestes petites demostracions no solen ser des del punt de vista artístic cap gran
èxit, però des del punt de vista tecnològic ens podem mostrar el que comentàvem
anteriorment, és a dir, que la tecnologia que volem incloure dins el joc és possible.
La idea principal del prototipus, a part de mostrar la visió del joc, de la tecnologia, etc,
també ens serveix per demostrar que el nostre camí de producció està en funcionament
i estem passant del mon de les idees al mon de la realitat d’una manera raonable i
efectiva.
Desenvolupament
El desenvolupament és el punt mestre, la fase crítica en tot el procés de creació d’un
videojoc. Aquesta fase pot portar de 6 mesos fins a 2 anys. L’inconvenient de
desenvolupaments excessivament llargs està en el risc de que les noves idees
incorporades al joc poden aparèixer en altres jocs (ja no tenim innovació) o bé que la
tecnologia utilitzada quedi desfasada degut als avenços en el hardware.
La dificultat d’aquesta tasca està en la correcta planificació de les diferents subfases que
s’han de realitzar. Les subfases grans s’han de dividir en noves sub-subtasques per
acotar molt més les hores de desenvolupament, els terminis, etc.
En l’apartat posterior es donaran unes pinzellades de diferents tècniques de gestió , però
podem anomenar una sèrie de consells per realitzar una bona planificació:
• Mantenir una bona comunicació en l’equip. Un component crític és el mantenir
el document de disseny actualitzat i fàcilment accessible. Tot l’equip a de tenir
molt clar que és el que s’ha de fer en tot moment, quines son les característiques
del joc, quina qualitat s’espera, etc.
28

Alfa
Projecte
• Fer un seguiment de les tasques actuals contra la planificació real. Hem de saber
en tot moment la situació de cada una de les subtasques respecte la planificació
per tal de poder aplicar mesures correctores, o de recuperació.
• Mantenir la identitat i esperit de l’equip, s’ha de treballar en equip, cada
component de l’equip ha de confiar en els altres. Una bona manera d’obtenir
confiança, identitat, etc, és la d’organitzar sopars, sortides, partits de futbol, etc,
amb el que aconseguirem que els components de l’equip es sentin units,confiïn
uns amb els altres i es coneguin.
L’estat d’alfa en qualsevol programa representa que aquest é funcional, però que encara
s’han de polir certs aspectes en la interfície, hi ha petites característiques que encara
s’han de desenvolupar i la jugabilitat / usabilitat s’han de millorar.
En aquesta fase és quan el videojoc o programa és vist i evaluat per gent externa al
equip de desenvolupament per primera vegada.
Beta
Al arribar a aquesta fase, totes les característiques del joc han estat finalitzades, la
usabilitat i jugabilitat han estat polides, el desenvolupament s’acaba, es fan proves en
altres configuracions de hardware (targetes gràfiques, processadors, ...). La única cosa
pendent està en arreglar els errors de programació (bugs) el més aviat possible.
Aquesta fase representa habitualment un “viure pel treball” constant, on tots els
components de l’equip realitzen proves, arreglen errors, ...
En els últims dies de la fase beta es realitzen els preparatius de començar a realitzar el
cd “mestre”. El cd es prova i les úniques modificacions al codi font que es permetran
serà per corregir errors que no possibilitin el testeig, i s’entra en un bucle fins que no
s’aconsegueixi un “release to manufacture”.
Producció final
Un cop un cd de la fase beta s’ha testeijat i s’ha trobat acceptable, es procedeix a
produir tots els cd que es vendran al mercat.
Parches i Actualitzacions
Un cop el videojoc s’ha realitzat, l’equip de desenvolupament anirà realitzant parches,
que solucionaran problemes detectats amb hardware específic (per exemple amb un
determinat tipus de tarjeta gràfica el joc no ha funcionat).
Les actualitzacions aportaran noves millores al joc, com la millora en la jugabilitat, nous
escenaris, nous personatges, etc.
29

Projecte
2.3 Introducció a la Gestió i planificació del
desenvolupament
En aquest apartat introduirem breument el concepte de gestió i planificació del
desenvolupament d’un joc.
No hem d’oblidar que desenvolupar un videojoc no deixa de ser desenvolupar un
projecte de software, per tant, per afrontar la realitat de construir un videojoc hem de
partir de les tècniques d’enginyeria del software.
Les principals característiques per gestionar correctament un projecte de software [4]
[16][18][19][20][21] son:
• Començar per un disseny complert.
• Desenvolupar un raonable pla tecnològic i una bona planificació.
• Entendre el problema que ens ocupa, i treballar per resoldre’l.
• Conèixer com recuperar-nos quan el nostre projecte es un desastre.
Segons la metodologia que seguim per desenvolupar el joc, podria ser que fos important
abans de començar la fase de desenvolupament tenir enllestit el document de disseny
del joc. El document de disseny, com s’ha comentat en apartats anteriors, equival a la
fase d’anàlisis de requeriments en el mon de l’enginyeria del software. Aquest
document correspon a les característiques que tindrà el joc, l’estil gràfic de la interfície,
de les pantalles, etc.
Començar la fase de desenvolupament sense tenir les idees clares de com serà el joc,
com seran les pantalles, etc, portarà la fase de desenvolupament a un caos continu. Hi ha
estudis que demostren que la millor solució està en perdre temps en planificar,
dissenyar, establir l’abast del projecte, i un cop aquestes tasques estan ben lligades
procedir a la fase de desenvolupament.
2.3.1 Planificació i calendaris
Els passos per crear un bon calendari per a projectes de software son els següents:
• Estimar la mida/abast del projecte
• Estimar l’esforç d’una persona/mes per desenvolupar un sistema de la grandària
indicada.
• Aplicar l’estimació persona/mes al nombre de persones en l’equip de treball i
aplicar-la al calendari per poder establir els terminis, costos, dies de vacances,
etc.
Hi ha una sèrie de problemes en les planificacions:
• Abast
• Pressións externes
30

Abast
• Modificació dels requeriment
Projecte
Molts dels projectes de software fracassen degut a que cap persona de l’equip de treball
s’ha pres la molèstia d’estudiar les dimensions del projecte, a part d’aquest gran
problema ens trobem amb planificacions i pressupostos fets per executius que no tenen
coneixements de l’esforç necessari per entregar el projecte.
L’abast consisteix en analitzar la grandària del projecte en si. Per estudiar la mida hi ha
moltes tècniques:
• Acudir a expert externs.
• Comparar les característiques del videojoc a desenvolupar amb altres jocs que
s’han realitzat anteriorment i estimar l’abast a partir de l’experiència de qui fa
l’estudi. Per tal de portar a terme aquest estudi històric, és una bona pràctica que
les persones que planifiquen i gestionen un projecte guardi els resultats de les
planificacions i els resultats reals un cop acabat el projecte, per tal de comparar
dades i fer una aproximació més acurada.
• Llegir pàgines web amb postmortem del desenvolupament de videojocs que han
sortit al mercat, per tal d’estudiar els problemes que han tingut altres equips de
treball i poder aprendre com els han solucionat.
Pressions externes
Solen ser unes bones polítiques de vendes el produir uns determinats productes en unes
dates concretes. Pot ser el cas dels videojocs per exemple de futbol, no té cap sentit
treure el videojoc de la lliga del 2004 a l’any 2005.
És molt important que abans d’acceptar els terminis, calendari, alguna persona de
l’equip de desenvolupament comprovi que es basen en dades lògiques i reals, no te cap
sentit que els calendaris i terminis no s’adjuntin a la realitat o bé siguin molt estrictes.
L’equip de desenvolupament ha de ser capaç de realitzar el projecte, però no ha de tenir
que fer esforços sobrehumans per dur-lo a terme.
Modificació de requeriments
Un altre error important està en la modificació dels requeriments inicials sense
replanificar ni canviar els calendaris. Depèn de la metodologia emprada aquest pot ser
un gran problema.
Optimisme dels desenvolupadors
31

Projecte
Per realitzar la planificació, els desenvolupadors solen ser molt optimistes en quan els
costos de temps representa fer una determinada tasca. Hi ha estudis que mostren que els
desevnolupadors generalment desestimen les seves pròpies tasques en un 20-30%.
El problema irresoluble
L’últim problema està en que és difícil fer-se una idea de com serà el videojoc a partir
del document de disseny. Per tant sol ser habitualment comú realitzar prototipus del que
serà el joc i adequar els requeriments a mesura que el prototipus va creixent.
Tenim una realimentació constant entre les diferents fases, per exemple si el videojoc no
és entretingut, el disseny canviarà. Si el disseny canvia, els requeriments canvien , i si
els requeriments canvien la planificació canvia també.
Aquest és un problema comú en tots els projectes de software. En l’apartat següent es
comenten diferents cicles de vida que intenten arreglar el problema anterior.
2.3.2 Escollint el millor model de cicle de vida per al
desenvolupament d’un videojoc
L’enginyeria del software reconeix diferents maneres d’aproximació al disseny i
desenvolupament de projectes de software. Algunes aproximacions són idonies per a
projectes en les que intervé un únic programador amb uns milers de línies de codi,
mentre que altres son aptes per a equips de programació de quinze programadors i
milions de línies de codi. En el cas del desenvolupament de videojocs els projectes
tenen la categoria mitja, que correspon a equips entre quatre i vuit programadors i
centenars de milers de línies de codi.
Degut a la grandaria d’aquest tipus de projectes, els cicles de vida més apropiats son els
següents:
• Cascada
• Cascada modificada
• Prototipatge iteratiu.
Cascada
Aquest model és el tradicional model en enginyeria del programari. Consisteix en
realitzar una sèrie de fases d’una manera ordenada.
L’inconvenient d’aquesta metodologia està en l’estudi dels requeriments. S’han de tenir
ben definits els requeriments des del principi, tasca molt difícil en segons quin tipus de
projectes on els clients no saben el que volen.
32

Projecte
Aquesta metodologia s’utilitza en projectes de videojocs en els quals els mecanismes de
jugabilitat son molt coneguts, com poden ser jocs que composen una saga (per exemple
FIFAs, King quest, etc), on es coneixen molt bé les característiques del joc. Es pot
utilitzar també aquest model per subsistemes grans dins del joc, com poden ser el motor
gràfic i la interfície, o bé quan s’estan afegint noves funcionalitats o nous nivells al joc.
Cascada modificada
Figura 2.3.2.1: Cicle de vida en cascada
La idea del cicle de vida tradicional modificat està en poder sobreposar les diferents
fases, per exemple podem començar a implementar alguns subsistemes abans de que
estigui acabat tot el disseny.
Un exemple de jocs que poden utilitzar aquesta metodologia son els jocs aventures, ja
que el més important per la jugabilitat del joc està en la interacció amb l’entorn, però el
dissenyador habitualment no coneix com serà aquest entorn visualment fins que els
artistes el creen.
Prototipatge iteratiu
Aquesta metodologia és molt utilitzada quan és molt costos establir els requeriments
inicials d’una manera acurada.
La idea principal d’aquest mètode està en desenvolupar el més ràpid possible un
prototipus funcional, i sobre aquest prototipus determinar quines coses agraden i quines
no, refent contínuament el disseny.
El tipus de videojocs en els que es sol utilitzar aquesta metodologia son els d’estratègia.
Un cop es creen les unitats i s’han afegit les característiques, els mecanismes de
jugabilitat i estratègia s’han de realitzar, i poden haver-hi estratègies bones i de
33

Projecte
dolentes. Les bones estratègies es mantindran per a futurs prototipus, mentre que les
dolentes es descartaran, al igual passa amb els escenaris.
El software es fa per increments i cada increment afegeix una nova funcionalitat al
sistema, a més de fer les extensions del disseny necessàries. Cada increment es prova
(això suposa un avantatge ja que el sistema rep una prova més exhaustiva).
2.3.3 Recuperació
Tot i que és pot realitzar una bona planificacions en un projecte, segurament aquest
haurà de fer front a una sèrie de problemes d’entre molts d’altres destaquem:
• Si es subcontracten parts del desenvolupament, l’empresa subcontractada pot
lliurar fora de termini la seva part.
• Mecanismes de planificació insuficients. S’ha de fer un seguiment de les tasques
que es van o s’han realitzat, per tal de saber l’estat de cada part del projecte.
• Equips de desenvolupament distribuïts. Si el nostre equip de treball està dispers
en la geografia serà convenient establir reunions “cara a cara” periòdicament per
tal de que els components de l’equip no es sentin sols davant el projecte.
Estratègies innefectives
Quan un projecte començar a fer fallida en certes parts, les reaccions típiques per tal de
rectificar-lo son:
• Imposar que els treballadors realitzin hores extres. És millor preguntar qui
estaria disposat a fer hores extres que imposar-les, ja que si es sotmet als
treballadors a la realització per força de més hores per a avançar tasques que
s’estan endarrerint, això desemboca amb el temps a una pèrdua de motivació, es
cometen més errors per el que implica haver de realitzar més proves. Hi ha
estudis que demostren que una gran motivació és igual a una gran productivitat,
per tant és millor preguntar als treballadors com creuen que han de planificar el
seu horari laboral per tal de ser el més efectius i productius possibles.
• Afegir gent al projecte. Afegir més personal a un projecte que acaba de
començar pot ser una bona idea per tal de incrementar la productivitat de l’equip
de treball. Afegir més personal quan el projecte fa mesos que ha començat no és
una solució, ja que les persones noves necessiten un temps de rodatge per tal de
familiaritzar-se amb els altres components de l’equip, a més les persones
originals del projecte han de dedicar temps a instruir als nous, la comunicació és
fa més difícil ja que hi ha més gent que s’ha de posar d’acord, les reunions
s’allarguen, etc.
• Demanar més reunions per control l’estat de les coses. Un exemple típic en
les empreses és que els responsables demanin un resum del que han fet els
treballadors durant el dia, també que és realitzin reunions a unes determinades
hores, etc. El problema radica en que el treball intel·lectual necessita d’un estat
34

Projecte
de “flux d’idees” en el que la ment s’endinsa plenament en el problema. Els
estudis determinen que aquest procés d’establir el flux està en uns 15 minuts.
Cada cop que s’interromp el treballador, ha de tornar a establir aquest flux. Per
tant crear un dia de treball que estigui ple de reunions, resums de treball, etc
garanteix que el treball creatiu/intel·lectual es retardi.
Estratègies efectives
Com hem vist anteriorment el principal problema que pot afectar a la planificació d’un
projecte és el seu abast. La manera més efectiva de dividir la planificació d’un projecte
està en decrementar el seu abast via disminuir les característiques/funcionalitats finals
que tindrà el projecte .Cada característica/funcionalitat que s’elimina redueix el temps
de disseny, creació, desenvolupament, integració i proves. L’inconvenient de reduir
funcionalitats en fases molt avançades del desenvolupament pot comportar llacunes,
crear errors, i per últim desmoralitzar a l’equip.
La solució a aquesta fet està en prioritzar les diferents característiques/funcionalitats que
tindrà el videojoc identificant les que son importants, les que serien interessants i les
que podria tenir. Les avantatges de donar prioritat a les característiques/funcionalitats
són:
• Si el desenvolupament s’encara a finalitzar les entrades més prioritaries, l’equip
tindrà més ganes d’acabar-les el més ràpid possible per tal de tenir temps per
implementar les característiques/funcionalitats no tant prioritaries.
• Si tothom coneix el temps que es requereix per desenvolupar una característica,
es sentiran menys “afectats” emocionalment si s’ha d’eliminar per falta de
temps.
• No es crearan llacunes en el joc al eliminar una característica/funcionalitat, ja
que es coneix tot el que repercuteix a aquesta (prioritat) i es coneix que el joc
funcionarà bé sense ella.
35

2.4 Parts d’un Videojocs
Projecte
En aquest subcapítol explicarem les diferents parts d’un videojoc a nivell més tècnic.
Molts dels videjocs tenen en comú moltes parts. El motor intern està composat de
diferents parts lògiques [6][17] amb una sèrie de funcions. Podem trobar els
subsistemes:
• Entrada
• Visualització
• So
• Xarxa
• Actualització
• Bucle principal
Figura 2.4.1: Parts d’un videojoc
És dificil detectar en el codi font d’un videojoc on comença i on acaba un determinat
subsistema per que els jocs estan molt optimitzats per a la velocitat de procés, no
obstant teòricament suposem independents per tal d’estudiar les característiques de cada
un d’ells.
En els capítols posteriors s’analitzaran algunes llibreries per ajudar al desenvolupament
de cada un dels subsistemes que formen part d’un videojoc.
2.4.1 Sistema d’Entrada
36

Projecte
Aquest sistema rep les comandes d’entrada de l’usuari via dispositius com el teclar, la
rata, etc. I guarda aquestes comandes per al posterior processament. Aquest sistema és
una part important en el motor d’un joc, ja que tot i que programar un dispositiu
d’entrada no és complicat, s’ha de fer amb compte per que una mala entrada pot arruïnar
la jugabilitat dels millors jocs. Habitualment aquest sistema soporta la possibilitat de
tenir diferents elements d’entrada (ratolí, teclat, joysticks, etc), a més un bon sistema
hauria de permetre integrar d’altres amb un mínim esforç.
2.4.2 Sistema de Visualització
El sistema de visualització té com a objectiu mostrar l’estat del joc, els elements gràfics,
etc al jugador. Aquest sistema ha de ser capaç d’utilitzar la potència de les targetes
gràfiques d’última generació aprofitant totes les capacitats 3D per tal de tenir una gran
eficiència i qualitat en els videojocs 3D. Normalment, per explotar aquesta potència és
necessari utilitzar una Aplication programming intergace (API) com poden ser
OpenGL, DirectX, etc, o bé partir d’un motor/llibreria que suporti aquestes APIs.
2.4.3 Sistema de So
Desenvolupar un sistema de so no és tant complicat i no necessita tant potència com pot
necessitar desenvolupar el sistema de visualització. Al igual que el sistema anterior, el
sistema de so ha de ser capaç d’aprofitar el hardware de la targeta de so, per exemple
hauria de ser capaç de produir efectes de so surround en les targetes actuals.
Similarment passa amb l’us d’un API per tal d’explotar la potència del só. Aquestes
APIs poden ser la OpenAL, DirectSound o bé aprofitar motors/llibreries que suportin
aquestes APIs.
37

2.4.4 Sistema de Xarxa
Projecte
Actualment afegir la funcionalitat de multijugador a través de la xarxa permet que els
jugadors “aprofitin” molts més els videojocs, és a dir, ja no parlem d’un joc
monojugador amb l’objectiu de passar-se totes les fases, estem parlant d’un videojoc
que permet competir entre diferents jugadors distribuïts amb l’objectiu de guanyar la
partida.
L’objectiu d’aquest sistema és el d’informar als altres ordinadors distribuïts de l’estat
del joc per tal de que és pugin sincronitzar entre ells. Al igual que els casos anteriors
normalment és treballar per sobre d’una API com poden ser Hawknl, Rakknet,
directplay, o motor que soporti el joc en xarxa.
2.4.5 Sistema d’Actualització
El sistema d’actualització és el “cervell” del joc. És el sistema que controla l’estat de
totes les entitats en el joc, com poden ser el jugador, enemics (mitjançant Intel·ligència
Artificial), etc, en definitiva, controla la informació que s’ha d’actualitzar quadre a
quadre.
2.4.6 Bucle principal
El bucle principal del joc és el sistema que s’encarrega d’ajuntar els diferents
subsistemes. Bàsicament és un bucle while que s’executa de 30 a 60 vegades per segon.
El bucle principal s’encarrega de cridar les funcions correctes per tal d’obtenir les
entrades (per exemple del teclat) que fa el jugador o bé de la xarxa provenint d’altres
jugadors, actualitzant l’estat de tots els objectes en el joc, visualitzant el pròxim quadre
dels gràfics i produint el so.
38

Projecte
La organització en el bucle principal és important ja que l’ordre afecta al producte. Per
exemple, les dades que es reben de la xarxa que indica l’estat dels altres jugadors dins el
joc, influència els altres sistemes com per exemple l’actualització o la xarxa. I
normalment el sistema de gràfics és el darrer sistema que s’executa per tal de reflectir
les dades generades pels altres anteriors sistemes.
39

2.5 Desenvolupament de videojocs
Projecte
En el capítol anterior hem comentat les diferents parts que formaven un videojoc, en
aquest capítol es comentaran algunes de les APIs/llibreries/motors gràfics per tal de
desenvolupar els diferents sistemes que formen un videojoc, tot i que ens centrarem
molt més en la part dels motors gràfics.
Primer de tot explicarem les diferències entre les llibreries i els motors gràfics.
2.5.1 Llibreries, motors gràfics i motors de videojocs
Entenem per llibreria un conjunt de funcions/utilitats/eines que ens ajuden a realitzar
tasques concretes, com poden ser el desenvolupament de tot el sistema de xarxa del joc,
o el sistema de visualització. Exemples d’aquest tipus són:
• Xarxa: HawkLib, Raknet, DirectPlay.
• Visualització: OpenGL, DirectX.
Podríem desenvolupar un videojoc a partir de diferents llibreries especialitzades en cada
subsistema d’un videojoc, per exemple podríem utilitzar pel sistema d’entrada la
llibreria DirectInput, pel sistema de xarxa la llibreria Raknet, per el sistema de
visualització OpenGL i pel só la llibreria OpenAL.
Entenem per motor gràfic un conjunt de funcions/utilitats/eines que ens ajuden al
desenvolupament del sistema de visualització a més alt nivell del que ens permetria per
exemple la llibreria de visualització OpenGL. En OpenGL no tenim contemplat la
càrrega de objectes 3D, l’estructuració de les dades per a fer més eficient la
visualització, entre d’altres característiques, mentre que en un motor gràfic aquestes
funcions estarien incloses.
I per últim tenim els motos de videojocs que van un pas més enllà. Un motor de
videojocs incorpora totes les funcionalitats d’un motor gràfics però afegint-hi per
exemple funcionalitats de llenguatges d’script per tal de que la gent no programadora
pugi modificar el comportament de certes part del motor.
Resumint podem dir que un motor de videojocs dona totes les funcionalitats per poder
desenvolupar videojocs d’una manera ràpida, un motor gràfic incorpora totes les
funcionalitats per fer aplicacions de visualització 3D, sense tenir en compte el tipus
d’aplicació ni si necessita llenguatges d’script, per exemple, i les llibreries incorporen
totes les funcionalitats d’un subsistema dintre d’un joc o aplicació.
A la pràctica la diferenciació entre motors gràfics i motors de videojocs és molt difícil
d’establir ja que col·loquialment anomenen indistintament a tots els motors gràfics i
motors de videojocs simplement motors gràfics o motors 3D, encara que en teoria tenen
diferències conceptuals.
40

2.5.2 Llibreries
Projecte
Existeixen un gran nombre de llibreries per tal de desenvolupar els subsistemes que
formen part d’un videojoc, d’entre elles podem destacar:
• Sistema d’entrada: OpenGL, SDL, Clanlib.
• Sistema de visualització: OpenGL.
• Sistema de So: OpenAL.
• Sistema de xarxa: HawkLib, Raknet.
• Formats de fitxers d’imatges: Devil, Corona.
• Formats de fitxers de dades: Cal3D, lib3ds.
• Middleware: SDL, Clanlib
Les seves característiques principals son:
• Portabilitat: Suport multiplataforma (Windows, Linux, etc).
• Programari lliure: tenim accés al codi font.
OpenGL
figura 2.5.2.1: Llibreries i els subsistemes que tracten.
OpenGL s’ha convertit en l’estandar per desenvolupar aplicacions interactives en 2D i
3D. Està desenvolupat en C++ i suport multiplataforma.
OpenAL
És una llibreria multiplataforma (PC, XBox, GameCube, Playstation 2) per
desenvolupar solucions en só 3D. Incorpora efectes Doppler, atenuació relativa a la
distància, efectes d’entorn (reflexions, obstruccions, transmissions, reverberació, …)
HawkLib
Entorn de desenvolupament multiplataforma orientat a xarxa. Suporta multitud de
protocols, estadistíques de treansmisió, etc.
41

Raknet
Llibreria multiplataforma que incorpora característiques avançades de xarxa.
Devil, Corona
Son dues llibreries per treballar amb fitxers d’imatges contra OpenGL.
Cal3D
Projecte
Llibreria escrita en C++ multiplataforma. La seva funció està en aportar animacions 3D
basades en esquelet.
lib3DS
Aporta suport per treballart amb el format 3DS. Està escrita en C++ I és
multiplataforma.
SDL (Simple Direct Layer)
És una llibreria multiplataforma amb suport per Linux, Windows, etc. Està escrit en C,
però funciona nativament en C++ i com a llenguatge d’scripts te enllaços a Lua, Perl,
Php, Python, Ruby, etc.
Engloba accés de baix nivell a funcions d’audio, teclat, ratolí, acceleració 3D via
OpenGL, etc.
Clanlib
Llibreria multiplataforma escrita en C++ per desenvolupar jocs. Integra accés a baix
nivell per controlar recursos, replicació d’objecte en la zarza, só, teclat, etc.
Per veure exemples d’utilització de les llibreries i les seves finalitats consulteu les
respectives pàgines web.
2.5.3 Motor de videojocs
42

Projecte
Un motor de videojocs no es res més que una API (aplication programming interface)
que ens permet desenvolupar d'una manera còmoda i ràpida videojocs, i aplicacions 3D
(tot i que pel que estan realment optimitzades son pels videojocs).
D'una manera planera definim un motor de videojocs com una caixa d'eines. Per
exemple si necessitem fer una taula, obrirem la caixa d'eines i agafarem una serra, un
destornillador, cargols, un taladre , etc., a part necessitarem també els taulons de fusta.
A continuació per fabricar la nostra taula, serrarem els taulons amb les formes de les
potes i la base de la taula. Farem un forat a les potes amb el taladre, i també farem un
forat a la base de la taula. Tot seguit unirem les potes a la base fent passar els cargols
pels forats que hem fet i amb el destornillador els collarem el més fort possible per que
la taula sigui solida i no trontolli.
Prenent com a partida el símil de la taula, si el que volem és fer un videojocs del tipus
tetris, únicament haurem d'agafar les eines que ens proporciona el motor per tal de
desenvolupar el nostre joc.
En internet podem trobar gran quantitat de motors gràfics [WEB1] destinats a ajudar al
desenvolupament de videojocs.
Les característiques mínimes que requerim d’un motor gràfic són:
• Portabilitat: Suport multiplataforma (Windows, Linux, etc).
• Modularitat: Claredat en l’estructuració, la implementació, en el disseny, etc.
• Extensibilitat: Facilitat de ampliar les característiques (plugins).
• Interoperativilitat: Incorpori importadors / exportadors de diferents paquets 3D
com per exemple 3D, Maya, Milkshape, etc.
• Tecnologia: Incorpori les noves tendències actuals, com per exemple el
llenguatge CG (vertex shaders, pixel shaders).
• Programari lliure: necessitem llibertat d’acció.
Entre la infinitat de motors disponibles [11][WEB1], enumerarem les característiques
principals dels que considerem més importants dins les pautes anteriors, que podríem
resumir en:
• Crystal Space
• Ogre
• Nebula Device
• Open Scene Graph
• Irrlicht
A més d’enumerar les característiques principals entrarem més a fons en el motor
Crystal Space que és en el que hem desenvolupat les Obscurances.
43

Crystal Space
Projecte
[WEB2] CS és un Kit de desenvolupament de jocs 3D escrit en C++ sota llicència GPL,
actualment hi ha una gran comunitat de col·laboradors participant i un gran nombre de
projectes desenvolupats amb aquest motor, d’entre ells:
• PlanetShift: joc de rol multijugador a través d’internet.
Algunes imatges del joc:
Les característiques principals del motor son:
Arquitectura general:
• Sistema de plugins, com so, tipus de lletres, etc., i llenguatges de script
flexibles, com Python i LUA.
Textures i mapes de textures:
Portabilitat:
• Suport per diferents formats de textures: GIF, TGA, PNG, BMP, JPG i
altres.
• Les plataformes actuals suportades son DOS (DJGPP), Unix (X Widnows,
OpenGL), GNU/Linux (X Windows, SVGALIB, SDL i OpenGL),
Macintosh (OpenGL), Widows 32-bit (DirectDraw Direct3D, DirectX,
OpenGL), BeOS (OpenGL), NextStep, OpenStep, Rhapsody i OS/2
(OpenGL).
Formats de fitxers suportats:
44

Projecte
• Càrrega directa dels formats 3DS, MDL, MD2, ASE, OBJ o POV.
• Format de fitxers XML, el que permet redefinir l’escena de manera ràpida.
• Les escenes poden ser guardades en fitxers comprimits per a permetre
empaquetar els diferents fitxers que en formen part.
• Possibilitat de fer llibreries d’objectes, textures, i altres utilitats.
Altres característiques:
• Suport de so en Windows, GNU/Linux i Macintosh i a més suport per so 3D
com EAX, D3D, etc. i suport per diferents formats de so com WAV, MP3,
Ogg/Vorbis, AIFF, IFF, MOD
• Comunicació simple per Windows, GNU/Linux and Unix basada en Sockets.
L’estructura del motor
Aquest motor implementa la idea de Interfícies per tal d’independitzar la implementació
de les classes dels objectes que les utilitzen i evitar d’aquesta manera problemes de
compatibilitat.
Un plugin implemetna una o més Interfaces. És el mateix concepte que en Java. A més
en CS esta solventat per el sistema SCF (shared Class facility), com veurem més
endavant).
El motor està format d’entre d’altres per:
• Llibreries
• Plugins
• Sectors i Portals
• Dades geomètriques (Meshes) dels Objectes
Per una informació detallada consultar la informació del motor gràfic.
Llibreries
Aquest motor gràfic està dividit en diverses llibreries, algunes de les més importants son
Llibreria geomètrica ( llibreria: csgeom)
Inclou una llibreria matemàtica 3D, 2D, vectors, matrius i polígons. Pot ser utilitzada
independentment de la resta del motor gràfic.
Llibreria d’utilitats ( llibreria: csutil)
45

Projecte
Aquesta llibreria inclou la possibilitat de llegir fitxer comprimits directament, fitxers de
configuracions per a opcions del programa, carrega dinàmica de llibreries (.so i .dll),
entre d’altres.
Llibreria SCF (Shared Class Facility)
La funció d’aquesta llibreria està en separar la implementació de les classes dels
programes que les utilitzen. És realitza separant la implementació de les classes en
mòduls separats en forma de llibreries compartides, anomenades mòduls de plugins. El
motiu de separar la implementació dels programes que utilitzen les classes és el de
solventar problemes d’incompatibilitat entre plataformes. D’aquesta manera podem
crear els nostres plugins de manera independent.
Crystal Space Windowing System (CSWS)
Aquest sistema s’encarrega d’aportar un sistema de finestres simple, efectiu i
multiplataforma al CS.
Plugins
Un plugin és un subsistema que es carrega en temps d’execució i que ens representa
alguna funcionalitat.
Virtual File System (VFS)
S’encarrega de gestionar el sistema de fitxers de cada una de les plataformes suportades
i de gestionar els diferents fitxers (fitxers comprimits) del motor d’una manera
transparent per l’usuari.
Graphics Drivers
Controlador 2d
S’encarrega de gestionar l’accés de baix nivell a la pantalla. Suporta funcions
primitives de pintar píxels, línies, texte, accés directe a la memòria, etc. Totes
son específiques de rasteritzadors 3D com l’OpenGL 3D o bé en Unix de la
llibreria/controlador OpenGL 2D XLib.
Rasteritzador 3D
Aquest sistema es necessari pel motor 3D però pot funcionar sol. Aquest
controlador s’utilitza per dibuixar gràfics 3D i també textures 2D en pantalla.
Actualment hi ha varies implementacions d’aquest component: Software,
OpenGL, directX, etc.
Sistema de Shaders
46

Projecte
Alguns renderitzadors (com per exemple l’OpenGL) necessiten sistema de
shaders adicionals per tal d’activar diferents característiques avançades de les
targetes gràfiques.
3D Engine (csEngine)
És el cor de Crystal Space. Necessita el component de rasteritzador 3D per a visualitzar
les escenes i necessita també altres llibreries com (csutil, csgeom,).
Aquesta classe implementa la interfície pública “iEngine” i a més conté una sèrie
d’objectes d’entre d’altres que son interessants:
• Sectors: la classe csSector amb interfície “iSector” correspon a una regió de
l’espai i conté la llista de meshes del sector, les llums, portals, etc.
• Meshes: Dades geomètriques dels objectes que hi ha en l’escena, així com de si
es pot moure, la informació de les llums, ombres, etc que l’afecten.
• Camera_position: Guarda la posició de la càmera inicial.
• Textures: Guarda les textures que s’aplicaran als diferents objectes de l’escena.
Map File Parser (csParser)
Aquesta classe s’encarrega de llegir la informació dels fitxers que defineixen les
escenes.
Sistema Mesh Object Plug-In
Aquest sistema s’encarrega de definir i d’utilitzar els objectes 3D dins el motor CS. Hi
ha una sèrie d’objectes predefinits com poden ser sistemes de partícules, fonts, boles,
etc.
Llenguatges d’Scripting
S’encarrega de relacionar el CS amb llenguatges d’script com poden ser el python, perl,
lua, etc.
Animació
Aquest plugins s’encarrega d’animar els sprites que hi ha dins l’escena. Existeixen dos
sistemes d’animació, el basat en quadres o per animació de l’esquelet (s’utilitza la
llibreria externa Cal3D).
Important models de dades
CS permet llegir altres formats que no siguin el format natiu. Amb aquest plugin és
permet importar dades independents de l’estructura i carregar-les dins el motor.
Alternate Windowing System (AWS)
El AWS és una alternativa millorada al Sistema de finestres que incorpora el CS.
47

Arquitectura principal
Projecte
L’arquitectura principal del motor el qual demostra una elevada modularitat, estret de la
seva pàgina web és el seqüent:
Sectors i Portals
El concepte bàsic de CS és el sectors [12][17]. Un sector és
• Àrea infinita de l’espai
• Conté llums i objectes
• Un portal connecta diferents sectors.
Una escena està constituïda per sectors que no son res més que un conjunt tancat i
convex de polígons. Convex significa que si dibuixem una línia entre dos punts
arbitraris en el sector, llavors mai interceptarà un polígon en el sector. Tancat indica
que no existeix possibilitat de sortir del sector sense traspassar un polígon.
48

Projecte
Dos sectors adjacents poden ser connectats usant un portal. Un portal és un tipus de
polígon especial, ja que un polígon normal és renderitzat utilitzant mapes de textura o
altres tècniques, però quan el render troba un portal, aquest salta a un altre sector, que
és el sector destí del portal.
Un portal és un polígon que connecta dos sectors (pot ser el mateix sector). És poden
crear efectes especials utilitzant portals com per exemple miralls i tenen grans
repercusions en el disseny de nivells ja que es pot separar àrees interiors de les àrees
exteriors.
Meshes
Una mesh no és res més que una graella de dades d’un objecte (ja sigui dades
geomètriques, textures, ...).
Existeien diferents tipus de Meshes d’objectes dins el CS, d’entre les que destaquem:
• Objecte format per triangles
• Objectes animats
• Objecte format de polígons
• Sistemes de partícules
• Motor de terrenys
Les meshes poden ser afegides en jerarquies i a més és poden moure, rotar i desplaçar
entre sectors.
Fabrica de meshes
Com hem comentat les meshes representen la geometria d’una escena. Una fabrica de
meshes no és res més que una plantilla per una mesh d’un objecte. Es a dir, podem tenir
una fabrica de mesh que ens representa per exemple una taula, i tenir diferents meshes
de la taula que s’han creat a partir d’aquesta plantilla a diferents punts de l’escena.
D’aquesta manera aprofitem millor la memòria, ja que només és guarda un cop la
informació de la taula, i és fa referència en les diferents meshes que instancien la taula.
Estructura d’una escena
49

Projecte
Com s’ha comentat anteriorment en l’apartat de Sectors i Portals, una escena està
formada per sectors. Un sector manté una llista de les llums i una llista amb les meshes
dels objectes, una llista dels portals d’entre d’altres. Una mesh com hem comentat en la
part de les Meshes pot estar entre dos sectors.
Per a un resum de totes les característiques visitar la pàgina web de Crystal Space.
50

Ogre
Projecte
[WEB3] OGRE (Object-Oriented Graphics Rendering Engine) és un motor 3D orientat
a escena i molt flexible, dissenyat per fer més fàcil i més intuïtiu el desenvolupament de
videojoc utilitzant el hardware 3D. Està desenvolupat en C++ i sota llicència LGPL.
Aquest motor tot i no tenir una tant gran comunitat com el cas del Crystal Space, té
també molts projectes, i a més comercials:
• Granite2004: Simulador de “autos de xoc”
• VTrike: Simulador ”d’ala delta”.
Granite 2004 Vstrike
Entre d’altres característiques destaquem:
Característiques de productivitat:
• Interfície orientada a objectes simple i fàcil d’utilitzar, dissenyada per reduir
l’esforç al renderitzar escenes 3D.
• Sistema de plugins, com so, tipus de lletres, etc., i llenguatges de script
flexibles, com Python.
Portabilitat:
• Windows (DirectX i OpenGL), Linux (OpenGL) i MacOSX (OpenGL).
• Utilització de les llibreries STL.
Materials:
• Potent llenguatge de declaració de materials.
• Permet shaders (CG i DirectX9 HLSL).
• Suport per textures en format PNG, JPEG, TGA, BMP i DDS .
51

Formats de fitxers suportats:
Projecte
• Càrrega directa dels formats 3DS, MDL, MD2, ASE, OBJ o POV.
• Format de fitxers XML, el que permet redefinir l’escena de manera ràpida.
• Les escenes poden ser guardades en fitxers comprimits per a permetre
empaquetar els diferents fitxers que en formen part.
• Possibilitat de fer llibreries d’objectes, textures, i altres utilitats.
Característiques de les escenes :
• Gestió de l’escena altament configurable, permet estructuració en BSP, octress ,
scene graphs, etc.
Com s’ha comentat a l’inici d’aquest apartat, l’únic motor gràfic que s’explica en
detall és el Crystal Space, ja que és el motor amb el que s’ha desenvolupat les
Obscurances.
Per a un resum de totes les característiques visitar la pàgina web de Ogre.
Nebula Device 2
[WEB5] Aquest motor és un motor de videojocs /visualització escrit en c++ i sota
llicència Tcl-style license. Hi ha una gran comunitat al darrera de Nebula Device, a més
la gran majoria de projectes son comercials:
• Project Nomads: arcada fantàstic.
• Urban assault: estratègia futurista.
• Schwarzenberg: thriller històric.
Nomads Schwarzenberg Urban assault
Les característiques més importants son:
52

Portabilitat:
• Windows (DirectX i OpenGL), Linux (OpenGL) i MacOSX (OpenGL).
Característiques de productivitat:
Projecte
• Sistema de plugins, com so, tipus de lletres, etc., i llenguatges de script
flexibles, com Python, Lua, Tcl/Tk, java
Materials:
• Potent llenguatge de declaració de materials.
• Permet shaders (CG i DirectX9 HLSL).
• Suport per textures en format PNG, JPEG, TGA, BMP i DDS .
Formats de fitxers suportats:
• Càrrega directa dels formats 3DS, MDL, MD2, ASE, OBJ o POV.
• Format de fitxers XML, el que permet redefinir l’escena de manera ràpida.
• Les escenes poden ser guardades en fitxers comprimits per a permetre
empaquetar els diferents fitxers que en formen part.
• Possibilitat de fer llibreries d’objectes, textures, i altres utilitats.
Aquest motor està pensat per poder accedir a tota la estructura interna a partir de
llenguatge script.
Com s’ha comentat a l’inici d’aquest apartat, l’únic motor gràfic que s’explica en
detall és el Crystal Space, ja que és el motor amb el que s’ha desenvolupat les
Obscurances.
Per a un resum de totes les característiques visitar la pàgina web de Nebula.
Open Scene Graph
53

Projecte
[WEB4] L’OSG és un motor 3D d’altres prestacions utilitzat en els camps de la
simulació, videojocs, realitat virtual, visualització científica i modelat. Està
desenvolupat en c++ i sota llicència.
D’entre els projectes que s’han realitzat en aquest motor destaquem:
• Barc: sistema de realitat virtual capaç de visualitzar qualsevol tipus de carreres
marítimes. Va ser desenvolupat per la copa de les nacions 2003 en Itàlia.
• VideaLab: aquest laboratoria va modelar la catedral de Tiu (Espanya) en vrml i
la visualitzava a partir de l’OSG.
• CSP: simulador de combat aeri.
Barc VideaLab CSP
D’entre les característiques destaquem:
Portabilitat:
• Windows, Linux, MacOSX, IRIX, Solaris i FreeBSD, tots amb OpenGL.
Característiques de productivitat:
• Sistema de plugins, com so, tipus de lletres, etc., i llenguatges de script
flexibles, com Python.
Característiques de les escenes :
• Sistemes de portals, Impostors, View Frustum cullung, etc.
Materials:
• Permet shaders (CG).
• Suport per textures en format PNG, JPEG, TGA, BMP, DirectX .x, AC3D .
Formats de fitxers suportats:
• Càrrega directa dels formats 3DS, MDL, MD2, ASE, OBJ o POV.
Característiques avançades:
54

• Paginació nativa de Bases de dades multi-threaded
Projecte
Com s’ha comentat a l’inici d’aquest apartat, l’únic motor gràfic que s’explica en
detall és el Crystal Space, ja que és el motor amb el que s’ha desenvolupat les
Obscurances.
Per a un resum de totes les característiques visitar la pàgina web de OSG.
Irrlitch
[WEB6] El motor Irrlicht està escrit en C++ sota llicència zlib/libpng. Té una gran
comunitat al darrera però no té t’han d’èxit en aplicacions comercials com poden ser el
Nebula o l’OSG o inclòs l’Ogre.
Algunes pantalles del motor:
D’entre les característiques destaquem:
Portabilitat:
• Windows (DirectX i OpenGL), Linux (OpenGL).
Característiques de productivitat:
• Sistema de plugins, com so, tipus de lletres, etc., i llenguatges de script
flexibles, com Python, perl, java, ruby.
Materials:
• Suport per textures en format: BMP, PSD, JPG, TGA.
Formats de fitxers suportats:
• Càrrega directa dels formats: DirecX .x, 3DS, Milkshape, Maya, Quake 3,
Quake 2Format de fitxers XML, el que permet redefinir l’escena de manera
ràpida.
55

Projecte
• Les escenes poden ser guardades en fitxers comprimits per a permetre
empaquetar els diferents fitxers que en formen part.
• Possibilitat de fer llibreries d’objectes, textures, i altres utilitats.
Com s’ha comentat a l’inici d’aquest apartat, l’únic motor gràfic que s’explica en
detall és el Crystal Space, ja que és el motor amb el que s’ha desenvolupat les
Obscurances.
Per a un resum de totes les característiques visitar la pàgina web de Irrlitch
56

Projecte
3. Cas pràctic: Desenvolupament de les
Obscurances en temps real
3.1. Anàlisis: model d’il·luminació global
mitjançant Obscurances
El primer pas per entendre bé el que hem de desenvolupar està en estudiar amb detall el
concepte d’Obscurances [1][14].
Les Obscurances són una tècnica d’il·luminació molt poten que simula la il·luminació
difusa, obtenint resultats similars a la radiositat però a un menor cost. Aquesta avantatge
es basa en considerar únicament les interaccions veïnes en lloc de considerar les
interaccions globals. Podríem definir la tècnica com la propietat geomètrica purament
local d’un punt en l’escena que consisteix en la integració dels factors de forma dels
punts veïns al punt donat. La tecnologia que es proposa té molts beneficis, entre ells la
simplicitat i l’acceleració de la representació d’escenes realistes.
La tècnica de la radiositat es comunment emprada per simular la il·luminació difusa en
entorns 3D tancats. Aquesta tècnica es molt potent i ha incrementat la seva velocitat
d’una manera considerable, però no és suficient per als requeriments d’editar d’una
manera ràpida i eficient una escena o bé l’actualizació en temps real d’aquesta. Les
interaccions de cada superfície en l’escena amb les altres ha de considerar-se (almenys
potencialment). Les Obscurances han estat dissenyades per oferir una alternativa a la
radiositat, mentre es mantenen les propietats visuals que fan que l’escena tingui un
aspecte realista. D’aquesta forma aquestes poden aplicar-se sense cap canvi als entorns
3D. Aquesta tècnica ha estat utilitzada en videojocs 3D i animacions (intros i cutscenes)
per a Heretic-II, Civilization-III, etc. En aquest capítol es comenta la implementació en
el motor gràfic Crystal Space [10], permeten l’actualització en temps real de les
Obscurances per a objectes en moviment.
La majoria de models de il·luminació local expliquen las interreflexions difuses
utilitzant la llum ambient, la que es considera normalment constant per tota l’escena. En
realitat, l’il·luminació no és constant. Per exemple, en una habitació amb parets difuses
o Lambertianess, la il·luminació canvia sobre les superfícies de la paret, de tal manera
que en les cantonades el color és més fosc (Obscurances), comparat amb el reste de l’
habitació. Cada efecte de llum en àrees ombrejades pot ser modelat sense necessitat
d’utilitzar mètodes tan costosos com la Radiositat. El nostre modelo d’il·luminació està
basat en el concepte de Obscurances, que destaca per la generació de les ombres en les
cantonades o zones on hi ha més quantitat de patchs per àrea, per exemple sota d’una
pota de la taula o als voltants d’aquesta taula.
57

Projecte
3.1.1.Model d’ il·luminació Obscurances sense fonts de
llum
Suposem que la llum difusa pot venir de qualsevol direcció il·luminant tota l’escena.
Definició: Escollim un punt P d’una superfície de l’escena, ω un punt de la hemiesfera
unitaria Ω centrada en P.
La funció L (P, ω) es defineix com:
Figura 3.1.1.1: Obscurances Hemiesfera
⎧dist(
P,
C),
on Cés
el primer punt d' intersecci ó del raig Pω
L(P, ω ) = ⎨
⎩+
∞,
cas _ contrari (si el raig no intersecta )
Considerem que un patch estè completament obert, es a dir, que estè completament
il·luminat. D’aquesta manera l’intensitat d’un patch donat pot ser aproximat de la
següent format:
? ( L ( P, ?)) : Funció que determina l’energia que arriba al punt P des de la primera
superfície interceptada amb una distancia menor que L en direcció ?
? : Àngle entre la direcció ? i la normal en P.
IA : Intensitat de la Llum Ambient.
R (P): Reflectivitat de P.
π
1 : és el factor de normalització tal que si ?() = 1 contra el reste de la semiesfera O,
llavors I (P) es R * IA.
(1)
58

Projecte
La funció ρ() és una funció monòtona creixent que depèn de L. Sabent que normalment
la il·luminació ambient d’un cert punt afectarà primerament als patchs veïns. Llavors,
podem concluïr que la funció ρ() haurà de seguir la forma que indica la següent figura:
Figura 3.1.1.2: Funció monòtonaa creixent
Es a dir, que la funció ρ(L) serà igual a 1 quan L ≥Lmax. Això significa que no tindrem
en consideració totes aquelles interseccions que es trobin més enllà de la distancia
màxima. D’aquesta manera, únicament escollirem aquelles interseccions “veïnes” al
punt fitxat.
Definició: Triarem un punt P d’una superfície de la escena. La Obscurance del punt P
la definirem com:
Llavors la Obscurance del punt P és la mitjana de les proporcions de l’energia donada
per els punts d’intersecció veïns al punt P. Clarament, per qualsevol punt P de la
superfície és cumpleix que 0 ≤ W ( P)
≤ 1 . La funció W(P) reflexa les propietats
geomètriques del punt P.
En els casos més extrems, el valor 1 de la Obscurance significa que el patch està
completament obert, mentre que el valor 0 vol dir que el patch està totalment tancat. La
Obscurance d’un patche és la mitjana dels factors de forma del patch ponderat per la
funció ρ . D’aquesta forma, utilizant les equacions anteriors sabem que la intensitat del
patch P és:
I( P)
R ( P)
I A W ( P)
∗ ∗ =
Aquesta expressió ens determina el nostre model d’il·luminació sense fonts de llum.
Aquest model pot anomenar-se localment global; ja que el càlcul de las Obscurances
inclou l’anàlisi de la geometria local de l’escena, però amb els efectes de la il·luminació
semblant globals.
La tècnica exposada és una propietat geomètrica que no depèn de les fonts de llum, això
suposa que únicament seran calculades un sol cop, implicant que per escenes animades
59

Projecte
on es poden moure les fonts de llum, simplement calcularem un cop les Obscurances
associades a l’escena i reutilizarem els càlculs a cada pas d’animació. És evident que
això representa una reducció considerable del cost computacional.
3.1.2.Model d’ il·luminació Obscurances amb fonts de
llum
L’objectiu del nostre model d’il·luminació es justificar la il·luminació indirecta causada
per les interreflexions difuses d’una manera senzilla i ràpida. Per calcular la il·luminació
d’un determinat patch causada per una determinada font de llum, distingirem dos parts
dins d’aquesta il·luminació: una directa i una altra indirecta. Per calcular la primera,
utilitzarem els models estàndards d’il·luminació local difusos. Per a la segona,
aplicarem el concepte de Obscurance en un punt.
La fórmula que defineix la il·luminació:
On
( P)
= ( I A + I ′ ( P))
∗ R(
P)
* W ( P)
+ RD
( P)
∗ I ( P)
1 4 4 4 4 2 4 4 4 4 3 1 4 2 4 43
I s
iluminacióindirecta
iluminaciódirecta
IA: constant de l’intensitat de la llum ambient. Aquest valor és pot calcular.
R, RD : coeficients de reflexió i difusa del patch.
IS : ens indicarà la intensitat de la llum directa que es desprèn per totes les fonts de llum
visibles.
= ∑ 2 cos
) ( I j
I P
α j
r
by allvisible
light sources
I ’ S : intensitat de la llum indirecta que ve de totes les fonts de llum,
on
'
I S ( P)
= β ∗
j
∑
light sources
all by
Ij : intensitat de la llum j-essima.
Rj : distancia de la llum al patch P.
α j : angle que forma la normal del patch amb la direcció de la font j.
β : constant que compleix 0 < β < 1.
La il·luminació indirecta procedent de les fonts de llum la calcularem a partir del terme
I’S. El factor β ens escalarà la component indirecta contra la directa. El terme I’S no
conté el factor cosinus perquè considerem que els raigs secundaris, que arriben a un
patch, venen de totes direccions.
I
r
j
2
j
60

Projecte
El principal paràmetre que controla l’ il·luminació és la distancia màxima (Lmax).
D’aquest terme dependrà la quantitat d’ombra que generen els objectes, es a dir, la
distancia màxima seleccionada haurà d’estar en concordança amb la grandària dels
objectes; ja que en realitat, objectes grans presenten ombres més grans que els objectes
més petits. Tal com indica la següent figura:
Figura 3.1.2.1: Efecte de la distància Lmax en el càlcul de les Obscurances
La distancia màxima dependrà també de la grandària de l’escena, ja que ens interessa
que les Obscurances siguin una propietat local. Per tant, Lmax tindrà un valor
proporcional a la grandària de l’escena de manera que sigui el més local possible. Un
dels objectius futurs que proposem és el càlcul automàtic de la distancia màxima més o
menys acceptable per a una escena determinada.
3.1.3.Model millorat de les obscurances (Color Bleeding)
El model exposat anteriorment ens proporciona d’una manera simple i ràpida escenes
3D molt reals. Les característiques que ens genera la tècnica presentada son ombres
molt realistes (en els contorns, en els objectes, suavitat d’ombres, etc).
En el mon real no solament es té en compte que tot objecte genera una certa “ombra”,
sinó que existeix una interacció entre els colors de les diferents superfícies del objecte i
les superfícies pròximes. Per exemple, suposem que tenim una habitació amb totes les
parets de color blanc exceptuant una que és de color vermell; és evident, que les parets
veïnes a la vermella adquireixen una tonalitat vermellosa degut a les reflexions tal i com
es pot veure en el dibuix:
Figura 3.1.3.1: Color Bleeding
És obvio que l’efecte entre les diferents superfícies de l’escena dependrà de les
característiques d’aquestes com poden ser el color i la seva reflectancia.
61

Projecte
La millora anterior rep el nom de color bleeding, és a dir, la transferència del color
mitjançant reflexió amb la superfície, de manera que les escenes tenen un major
realisme.
Per obtenir la finalitat o efecte que produeixen les diferents superfícies dels patch veïns
sobre un determinat patch, utilitzarem el concepte de reflectancia (capacitat de reflexar
la llum) dels patch veïns a aquest. Resumint, depenent de la reflectància que presentin
els patchs de l’entorn, l’efecte sobre el patch serà major o menor. Aquesta característica
serà la que ens transmetrà el color de les superfícies veïnes al nostre patch. L’esquema
que seguirem per calcular l’efecte del color bleeding sobre un cert patch és el següent.
Figura 3.1.3.2: Càlcul color bleeding
Obtenim la reflectancia del patch que ha interceptat cada raig llançat des de el patch
seleccionat, de manera que aquest obté els colors de les superfícies interceptades. Si es
donés el cas que el raig llançat no interceptes cap patch, utilitzarem com a reflectancia
del patch seleccionat la reflectancia mitjana de l’escena que anteriorment hauríem
calculat.
3.1.4.Calculant les obscurances
Abans d’aplicar les Obscurances hem d’especificar la distància màxima i el nomre de
raigos que s’hauran de llançar per calcular la part indirecta (Obscurances). El següent
pas és calcular la constant de llum ambient. Per això calcularem la reflectància mitjana
total Rave:
R
n
∑
i=
ave = 1
A ∗ R
on:
Ai : és l’àrea del patch i
Ri: és la reflectància del patch i
Atotal: és l’àrea de tota l’escena. Quan s’hagi calculat la reflectància mitjana passarem al
càlcul de la intensitat de la llum ambient.
A
i
total
i
62

I
A
=
n
∑
i=
1
Ai
∗Ei
+ R
A
total
ave
∗
n
∑
i=
1
Ai
∗Ei
+ R
A
total
2
ave
∗
n
∑
i=
1
Ai
∗Ei
1
+ ... =
A ( 1−
R
total
ave
∗
)
n
∑
i=
1
A
Projecte
A ∗E
on:
Ei: és la emitància del patch i;
1 ( 1−
Rave
) és el número mitjà de rebots o camins de la llum. Aquesta expressió té en
consideració la llum directa (1ª expresió de la sèrie). Tan sols ens interessa la llum
ambient indirecta, per tan hi haurà un factor de reflectivitat Rave per el que tindrem que
multiplicar IA. Aquest factor estarà implícit en el càlcul de les Obscurances millorades.
Una cop calculada la intensitat de la llum ambient, podrem passar al càlcul de les
Obscurances. Primer, calcularem els raigs que corresponen a cada patch amb la
següent expressió: i total A A raigs
patch
Lines ) ( _ = ∗ , és a dir, número de raigs per
unitat d’àrea del patch. Tot i que, es podria distribuir de diferent forma, per exemple
número constant de raigs per patch (aquesta és la solució utilitzada en la implementació
amb el motor Crystal Space).
A continuació llançarem tants raigs com indica el terme Lines_patch. Els raigos es
llancen d’una manera aleatòria, amb la distribució corresponent als factors de forma. Per
cada raig es busca la intersecció més pròxima dins de la distància màxima prenent com
origen el patch actual. Si es produeix la intersecció, aplicarem la funció monòtona
creixent i que segueix la corba especificada en els apartats anterior; en el nostre cas
i max L D f = , on Di és la distància entre l’origen del raig i el punt d’intersecció. En el
cas de que la intersecció no es produís , f serà igual a 1. Tenint en compte aquest fet, la
Obscurance del patch serà:
1
Obscurance =
num.
rayos
on
fi: és el valor de la funció per al raig j.
Rint:: és la reflectància del patch interceptat.
num rayos
∑ j
j=
R f
.
int
1
Aquesta operació es reprodueix per a tots els raigs que es llancen des d’aquest patch.
Després es multiplica el valor de la funció, que és el que ens determina la Obscurance
del patch, per la reflectància de cada patch interceptat. La reflectància de cada patch
interceptat s’ha de tenir en compte per a que cada patch origen dels raigs adquireixi
l’efecte de color bleeding (seguint el procediment explicat en l’apartat anterior).
A continuació es calcula la il·luminació de l’escena amb les Obscurances seguint la
fórmula:
I( P)
= ( I A + I ′ ( P))
∗ R(
P)
* W ( P)
+ RD
( P)
∗ I s(
P)
on
I A (llum ambient): calculada a partir del procediment exposat anteriorment.
I′ s (P)
: no es té en consideració.
i
total
i
63

Projecte
R, RD
: R correspon a la reflectància del patch i RD es troba implícit en el càlcul de la
llum directa que fa el mateix programa.
W (P)
: correspon a Obscurance mitjana del patch.
I s (P)
: correspon a la llum directa.
Obtenint l’expressió:
I A
( P)
= I ∗ R ( P)
* W ( P)
+ ( llum
on la llum directa es calculada per el Crystal Space.
directe)
64

3.2. Disseny
Projecte
Tenint clar els càlculs necessaris que s’han de realitzar per calcular les Obscurances
procedirem al disseny de les Obscurances en temps real.
3.2.1.Fases en la implementació de les Obscurances en
temps real
El procés de calcular les Obscurances té un seguit de pasos:
En detall:
Figura 3.2.2.1: Pasos a realitzar
• Càrrega de les dades (preparació dels Lightmaps) i estructuració de l’escena.
• Algorisme per Calcular les Obscurances
o Voxel Origen del raig
o Llançament de raigs
o Intersecció dels raigs
o Modificació dels Lightmaps dels polígons afectats
o Inicialització de les estructures per a les Obscurances en temps real
• Navegació de l’escena
o Recàlcul dels polígons afectats pels moviments d’objectes en moviment.
Per tal de treballar amb les Obscurances dins el Crystal Space explicarem a continuació
el concepte de Lightmap.
3.2.2.Lightmaps
Per tal de realitzar la implementació de les Obscurances ens basarem en el concepte de
Lightmaps (mapes de llums). Cada superfície de l’escena en el motor gràfic Crystal
Space, té una sèrie d’atributs: color, vèrtexs, Lightmaps, etc. Un Lightmap no és res més
que una o més textures que guarden informació de la il·luminació d’un polígon [22] que
son aplicades a la textura original del polígon abans de renderitzar-se per pantalla.
Podem veure uns exemples a continuació:
65

Textura Lightmap Textura +
Original Lightmap
Figura 3.2.2.2: Lightmaps
Projecte
Podem definir un Lightmap com a una matriu de valors, on cada element s’anomena
Lumel (Luminosity element), podem trobar l’element homònim en les textures: Texel
(Texture element). Un Lightmap no té per que tenir la mateixa resolució que una textura,
habitualment tenen dimensions inferiors però per aplicar correctament la superposició
de Lightmap i textura, el Lightmap s’escala al tamany de la Textura (emprant
interpolacions).
Per tal de simplificar càlculs, considerarem que cada Lumel correspon a un Patch, de tal
manera que podem establir una relació directa entre Patchs i Lumels. La utilització del
Crystal Space ens facilita tot el procés de generació dels Lightmaps de cada una de les
superfícies de l’escena, per tant quan carreguem l’escena, ja tenim calculats els
Lightmaps de cada superfície.
L’algorisme per calcular els Lightmaps te dues parts: Trobar les coordenades u,v
correctes per cada vèrtex en el Lightmap i calcular el contingut del Lightmap, aquests
càlculs son realitzats automàticament pel Crystal Space, però trobem adients comentarlos
per tal de tenir clars els passos que realitza, per tal d’afegir la implementació de les
Obscurances dins el motor gràfic.
Primer pas, generació de les coordenades u,v correctes del Lightmap
1. Projectem el polígon contra un pla primari (XZ, XY o YZ), ja que hem de tenir en
compte que un Lightmap té dues dimensions. Normalment aquesta decisió és basa en la
Normal. Per exemple, si els components de la normal té que la coordenada Y és més
dominant (la més gran) que XZ, llavors el pla XZ serà en el que farem la projecció.
66

Projecte
2. Trobem la caixa englobant del polígon. Una textura té sempre la forma d’un
rectangle. El proposit d’aquest pas està en definir aquest rectangle i trobar les seves
dimensions. Això es realitza trobant la caixa englobant que conté aquest polígon.
Figura 3.2.2.3: Càlcul del Bounding box
Per realitzar això, el mínim i el màxim de les coordenades u,v son determinades, el
següent algorisme calcula aquests valors:
Assignem a les coordenades Max i min u i v les coordenades UV (x i z en aquest cas)
del primer vèrtex.
Per cada vèrtex del polígon
Si max u < vèrtex u llavors max u = vèrtex u
Si min u > vèrtex u llavors min u = vèrtex u
Si max v < vèrtex v llavors max v = vèrtex u
Si min v > vèrtex v llavors min v = vèrtex v
Fper
Algorisme 1
Després d’aquest pas, la caixa englobant representa l’àrea del Lightmap.
3. Fem que totes les coordenades u, v siguin relatives a l’origen de la textura. L’origen
de la textura és el Min u i Min V (punt A) en l’anterior figura. Per tal de fer totes les
coordenades u,v relatives a aquest punt, simplement restem les Min u, Min V de les
coordenades u,v del Lightmap de cada vèrtex del polígon
4. Escalem totes les coordenades u,v del Lightmap en el rang 0.0 a 1.0. Per fer això
hem de conèixer les dimensions de la textura (normalment son conegudes). Per
determinar l’amplada: max u – min u, similar per trobar l’alçada: max v – min v.Ara
dividim la coordenada u de cada vèrtex per l’amplada de la textura i dividim la
coordenada v de cada vèrtex per l’alçada de la textura.
En aquest moments tenim les correctes coordenades del Lightmap per cada vèrtex del
polígon. Les dimensions d’aquest Lightmap son també conegudes. El pròxim pas està
67

Projecte
en generar el Lightmap. És molt important dir que les textures son definides en un
espai de textures en dues dimensions. El polígon al que se l’hi aplicarà té un espai de
mon (coordenades de mon) en tres dimensions. Quan la textura es generada, és recorre
lumel a lumel utilitzant dos bucles anidats. Quan el valor d’un determinat lumel s’ha de
determinar, el lumel s’ha de projectar de dues dimensions a unes coordenades de mon
en tres dimensions. Aquest pas és necessari per assegurar que la orientació de la font de
llum és correcte així que el càlcul de la il·luminació serà correcte.
Segon pas, generació del Lightmap
Figura 3.2.2.4: Generació Lightmaps
La figura anterior és la mateix figura vista en el primer pas per crear un Lightmap però
amb informació afegida. Quan el contingut del Lightmap es generat, la generació
començarà en el punt A. El punt A està en coordenades de textura en dues dimensions,
per tant s’hauran de calcular les coordenades del punt A en coordenades de mon (tres
dimensions). En l’exemple el polígon ha estat projectat contra el pla ZX. Les
coordenades z i z del punt A es poden calcular d’una manera simple ja que son les
coordenades min u i min v respectivament. La coordenada Y no es coneix, per tal de
trobar-la necessitem trobar l’equació del pla del polígon en el que resideix el Lighmap.
Un cop trobada l’equació del plà trobar la component Y és trivial.
L’equació del pla és:
Ax + By + Cz + D = 0
La component X i Z son conegudes, així que l’equació ens donarà el valor de Y:
y = - ( Ax + Cz + D ) / B
El pròxim pas està en trobar els dos vectors que comencen en el punt A (un vector
apuntant cap a la direcció d’un extrem de la textura, l’altre cap a l’altre) que serien els
vectors marcats en la figura anterior com a B i C. Podem definir el vector B = D – A,
però no és correcta ja que el punt D està en coordenades de textura (dues dimensions),
en comptes d’això s’empra l’equació del plà del polígon per tal de determinar la
coordenada Y dels punts D i E.
68

Els dos vectors son definits com:
B = D3D - A
C = E3D – A
Projecte
On D3D i E3D fan referència als punts D i E projectats en les tres dimensions en les
coordenades de mon.
Un cop realitzats els passos anteriors, es realitza una interpolació entre els vectors B i C
al llarg de la superfície del Ligthmap, per tal de determinar tota la informació necessària
per generar el Lightmap. L’algorisme següent mostra com generar el Lightmap:
Per ly = 0 a l’alçada del Lightmap
Per lx = 0 a l’amplada del Lightmap
Fiper
Fiper
LL = posició del lumel L(lx, ly) en coordenades de mon (es
troba a partir de la interpolació i el vector A).
Il·luminació = calculem la il·luminació en LL.
Guardem la il·luminació en el Lightmap[lx][ly].
Algorisme 2
Figura 3.2.2.5: Calculant el Lightmap
La figura anterior mostra els passos de l’algorisme anterior. Suposem que el bucle de
l’algorisme a arribat al lumel L. En la figura b es mostra el pla de projecció La figura c
mostra el pla de projecció i la “transformació” en coordenades de mon (tres
dimensions) on es pot veure la font de llum. Podem també observar que tenim tota la
informació necessària per calcular la il·luminació en el punt LL.
Nr és el vector normal al polígon.
D és el vector apuntat cap a la font de llum. G és la longitud d’aquest vector D.
P és el polígon actual al que aplicarem el Lightmap. Qualsevol model d’il·luminació pot
ser aplicat per tal de determinar la correcta il·luminació en LL. Cal remarcar que tots els
càlculs son realitzats abans de renderitzar, per tal el model d’il·luminació podria tenir un
cost elevat, ja que és realitzar abans de que l’escena sigui visualitzada per pantalla.
69

Projecte
Aquest és el cas de les obscurances, que son calculades quan l’escena és carregada i
preparada per visualitzar-se. El mètode per calcular la i·luminació en el Crystal Space
és:
Intesitat × Terme_
difus×
( Nr×
D)
Il·luminació =
γ
Emprant aquesta equació la intensitat de la llum és inversament proporcional a la
distància del punt a la font de llum ja que γ serà més gran quan més lluny estigui el
lumel projectet de la font de llum.
Com hem comentat anteriorment aquest pas és realitzat automàticament pel Crystal
Space, però necessitàvem saber com realitza el procés de generació de Lightmaps de
cada superfície per tal d’afegir el càlcul de les obscurances.
3.2.3.Càrrega i Estructuració de l’escena: Voxels
Per augmentar la velocitat, l’eficiència del càlcul de les interseccions dels raigs amb els
plans que representen els Patchs / polígons, la’escena s’estructura mitjançant Voxels.
Un Voxel és un element de volum (Volumen element) que habitualment es representa
mitjançant un cub. Donada una escena, si es divideix tot l’espai en subespais en forma
de cubs, obtenim una escena voxelitzada.
Figura 3.2.3.1: Pasos a realitzar
Figura 3.2.3.2: Voxels
Quan és llegeixen les dades d’un objecte, per cada un dels patchs d’aquest (pels vèrtexs)
és fa un petit càlcul per determinar en quin voxel està el patch afegint-lo a la llista de
patchs del voxel, després sí el polígon al que pertany el patch no està en la llista de
polígons del voxel, s’afegueix a aquesta llista. L’algorisme per realitzar aquest petit
càlcul per saber en quin voxel està un vèrtex és:
Caixa: és la caixa englobant de tota l’escena
Num_voxels_x: nombre de voxels de l’escena en l’eix X ( el mateix per
Y i Z)
70

vèrtex.
x − caixa.
MinX
X = PartEntera ( × num _ voxels _ x)
caixa.
MaxX − caixa.
MinX
vèrtex.
y − caixa.
MinY
× num _ voxels _
caixa.
MaxY − caixa.
MinY
vèrtex.
z − caixa.
MinZ
× num _ voxels _
caixa.
MaxZ − caixa.
MinZ
Y = PartEntera ( y )
Z = PartEntera ( z)
Voxel_al_que_va = X + Y * num_voxels_x + Z * num_voxels_x *
num_voxels_y;
Algorisme 3
Projecte
Resumint, dins de cada Voxel guardem dues llistes, la primera llista amb els polígons
que hi ha dins de cada Voxel, o bé el “traspassen”, i la segona llista amb els patchs que
hi ha dins o traspassen el Voxel. Es guarden dues llistes pel fet de que donat un polígon
dins el voxel necessitem saber d’una manera ràpida els patchs del polígons que hi ha
dins el voxel determinat, i sinó tinguéssim la segona llista no hi hauria una manera
ràpida de saber quins son els patchs d’un polígon que queden dins d’un voxel i quins
queden fora. A més la llista de polígons ens servirà per quan s’hagi de buscar la
intersecció d’un raig amb l’escena (primer es comprova el raig contra cada polígon del
voxel actual) i després es calcula el patch interceptat.
Un esquema de l’estructura de les llistes dels voxels és:
Figura 3.2.3.3: Estructura de llista dels voxels de l’escena
S’ha triat aquesta estructuració de l’escena per la simplicitat a la hora d’implementar
aquesta jerarquia contraposada al grau de dificultat que comporta una jerarquia del tipus
octree.
3.2.4.Algorisme per calcular les Obscurances
Tenint en compte l’estructura jeràrquica de l’escena en Voxels [2][10] l’esquema del
càlcul de les Obscurances és el següent:
71

Figura 3.2.3.1: Pasos a realitzar
I l’algorisme per calcular les Obscurances serà:
Per Cada Voxel (v) en l’escena
FPer
Per Cada Patch (p) de la lista de Patch del Voxel (v)
FPer
Per Cada Raig (r) aleatori que es llença del Patch (p)
Fper
Calcular el patch d’intersecció
Calcular i Acumular el valor de la obscurance
Aplicar Obscurance al Patch (p)
Algorisme 4
Projecte
Amb aquest algorisme el nombre d’objectes que s’han de comprovar és petit, ja que
només comprovem el raig contra tots els objectes del voxel actual, podem estar segurs
que si intercepta algun objecte del voxel actual, aquest estarà molt pròxim, per tant no
haurem de comprovar els altres voxels.
Per cada patch que tractem es llancen n raigs. De cada raig calculem les Obscurances i
les acumulem per quan acabem de llençar tots el raigs del patch actual, poder a partir
del valor de les Obscurances modificar el Lightmap del polígon al que pertany el patch
(en concret el Lumel corresponent al patch amb el valor de la Obscurance d’aquest)
Voxel origen del raig
Quan un raig és generat des d’un patch podria donar-se el cas que el patch estigués
entre dos voxels. Per aquest motiu necessitem calcular quin és el voxel des d’on
72

Projecte
s’origina ja que primer és tracta tots els objectes del voxel originari. Per calcular el voxel
des d’on s’origina aplicarem el mateix procediment que per calcular el patch interceptat,
però amb unes petites modificacions:
Caixa: indica la caixa englobant de tota l’escena
Num_voxels_x: indica el nombre de voxels en l’eix X (igualment per Y i
Z).
Punt_origen: indica el punt des del que s’origina el raig.
X = PartEntera (
Y = PartEntera (
Z = PartEntera (
( punt.
x − caixa.
MinX ) × num _ voxels _ x
caixa.
MaxX − caixa.
MinX
( punt.
y − caixa.
MinY ) × num _ voxels _ y
caixa.
MaxY − caixa.
MinY
( punt.
z − caixa.
MinZ)
× num _ voxels _ Z
caixa.
MaxZ − caixa.
MinZ
voxel origen = X + Y * num_voxels_x + Z * num_voxels_x * num_voxels_y
Llançament de raigs
algorisme 5
Per calcular les Obscurances necessitem llençar n raigs per cada un dels patchs en que
és subdivideix l’escena. Quan un raig intercepta un altre patch llavors apliquem la
fòrmula de les obscurances per obtenir el valor final del patch origen del raig.
Generació del raig aleatori
Cada raig que és genera segueix una distribució aleatòria del tipus drand48 que retornar
valors de 48 bits de doble precisió positius de coma flotant i uniformement distribuïts
sobre l’interval [0.0, 1.0]. A partir d’aquests valors generem el punt on s’inicia el raig
sobre del patch i la direcció cap on es dirigeix.
El raig aleatori segueix l’equació de la recta:
On P0 és la posició on començar el raig.
Direcció es el vector direcció del raig.
T és el temps.
P0 + Direcció * t = 0
)
)
)
73

Projecte
Per trobar la distància màxima fins la que el raig arribarà prenem t = Lmax per tant
obtindrem:
Po + Direcció * Lmax = 0
Aquesta equació ens servirà per calcular la intersecció d’una recta amb un polígon, com
veurem més endavant.
Calcular el patch interceptat
L’algorisme per calcular les intercepcions dels raigs amb els objectes de l’escena per tal
de calcular les Obscurances és simple. A continuació mostrem l’algorisme per trobar la
intercepció del raig amb l’escena:
Calculem el Voxel on s’origina el raig
Per cada Polígon (i) en la lista de Polígons del Voxel actual
fper
Comprovem intersecció
Si la intersecció està més aprop que l’anterior, guardem
l’actual.
Si hi ha intersecció
Calculamem el patch on es produeix la intersecció
altrament
Calculem el Voxel cap el que va el raig.
S’apliquen els mateixos passos per el nou Voxel, exceptuant el
pas 1 (càlcul del Voxel origen, ja es coneix)
fsi
Algorisme 6
Per comprovar si un raig intercepta amb un polígon, primer es comprova si el raig
intercepta el pla que conté el polígon, si és així es comprova si el punt interceptat està
dins el polígon que estem comprovant. L’algorisme per testeijar si el raig intercepta el
pla del polígon és:
vu = raig.punt_final – raig.punt_inici;
denom = pla.normal * vu;
Si denom = 0 llavors //el raig i el pla son paral·lels
Retornar fals
distància =
pla . normal * inici + pla.
DD
−
denom
punt_interceptat = inici + distància * vu;
Algorisme 7
74

Projecte
Si és passa el test (si el raig intercepta el pla) llavors fem un test per detectar si el punt
interceptat està dins el polígon, per fer això seguim l’algorisme:
Projectem el polígon a 2D ( en el pla dominant, tal i com fèiem en el
pas 1 dels Lightmaps)
Per i = 1 fins nombre_vertex fer
i2 = i + 1;
Si i = nombre_vertex llavors i2 = 0
Si Determinant (vertex(i), vertex(i2)) < 0 llavors retornem fals
Fper
Retornem cert
Algorisme 8
Un cop detectat si el raig intercepta un polígon en concret, hem de calcular el patch en
el que intercepta, aquesta càlcul és resumeix a:
Projectem el polígon sobre el pla dominant (2D), fem el mateix pel
punt d’intersecció.
X = PartEntera (
Y = PartEntera (
( punt _ int
( punt _ int
erceptat.
x − poligon2d.
MinX ) × Amplada _ lightmap
poligon2d.
MaxX − poligon2d.
MinX
erceptat.
y − poligon2d.
MinY ) × Alçada _lightmap
poligon2d.
MaxY − poligon2d.
MinY
Patch_interceptat = X + Y * amplada_Lightmap;
Algorisme 9
Per exemple, suposem que hem trobat que el raig originat en un patch ha interceptat el
punt (2.5, 2.5, 0.0) i ens interessa trobar el patch al que pertany aquest punt.
Figura 3.2.4.1: Exemple càlcul patch interceptat
)
)
75

Projecte
Suposem que el polígon interceptat de vèrtex inferior (0.0, 0.0, 0.0) i superior (4.0, 4.0,
0.0), sabem també que la grandària del Lightmap és de 4x4.
Primer pas: Projectem el polígon a dos dimensions que en aquest cas és : (0.0, 0.0), (4.0,
0.0), (4.0, 4.0) i (0.0, 4.0)
Segon pas:
( 2.
5 − 0.
0)
× 4
X = ≅ 2
4.
0 − 0.
0
( 2.
5 − 0.
0)
× 4
Y = ≅ 2
4.
0 − 0.
0
Patch interceptat = 2 + 2 x 4 = 10 com que la numeració comença en 1 (en comptes de
0) sumem un + 1. Per tant el patch final és el 11.
Un cop és coneix el Patch amb el que intercepta el raig i coneixem el valor de la
Obscurance podem modificarel valor del Lightmap a la posició corresponent.
Calculant i aplicant les Obscurances al patch origen del raig
Un cop tenim les obscurances acumulades per un patch en concret simplement
apliquem aquest valor de la Obscurance al Lightmap del polígon al que pertany el patch
(modifiquem el Lumel del Lightmap amb el valor de la Obscurance calculada que
correspon al patch actual que estem tractant). L’algorisme que hem vist en l’apartat
3.2.4 reflectia tot el procés de calcular les obscurances per tota l’escena, anem a centrarnos
en la part de llançar els raigs d’un patch i calcular les Obscurances:
Per num_raig = 0 fins a raigs_per_patch fer
Raig = GenerarRaigAleatori();
Voxel_origen = CalcularVoxelOrigen(Raig);
Patch_desti = LlençarRaig ( voxel_origen, raig);
Si Patch_desti llavors
funcio =
patch_
desti.
dis tan cia
L max
Color_patch_desti = patch_desti->ObtenirColor();
Color_patch_origen = patch_origen->ObtenirColor();
Altrament
funcio = 1;
fsi
oscur_origen = oscur_origen + funcio * color_patch_desti;
76

Fper
oscur_origen =
oscur _ origen
raigs _ per _ patch
Patch_origen->PosaObscuranceAlLumel (obscur_origen);
;
Algorisme 10
Projecte
Depenent del tipus d’Obscurance calculem la Obscurance a partir de la llum ambient,
la part directa, la obscurance mitjana, etc. En aquest cas hem triat el cas simple.
Inicialització de les estructures per a les Obscurances en temps real
Per poder treballar amb les Obscurances en temps real, hem d’afegir dues llistes més,
llista de patchs dinàmics i llista de polígons dinàmics. Ens serviran per guardar els
patchs i polígons respectivament dels objectes que estan en moviment.
L’objetiu d’aquestes dos noves llistes és poder controlar a cada quadre els patchs o
polígons dinàmics que existeixen en l’escena en un instant determinat. D’aquesta
manera, quan es processi el següent quadre, podem eliminar sense problemes aquestes
dues llistas, per a posteriorment tornar o omplenar-les amb els nous patchs o polígons
que es troben en aquest moment dins d’un voxel.
L’algorisme per tractar les llistes de patchs i polígons inicial és:
Per cada Patch (p) de l’escena
Calculem Obscurances
fper
Si un raig intercepta un objecte en moviment
Guardem el patch (p) interceptat en la llista de patchs
dinàmics.
Altrament
Si el raig s’origina en un patch d’un objecte en moviment
Guardem el patch interceptat en la llista de patchs
dinàmics
fsi
Algorisme 11
Un cop hem inicial les llistes de patchs dinàmics i polígons dinàmics, a cada quadre de
la navegació dins l’escena l’algorisme per processar aquestes llistes és el següent:
Per cada Patch (p) dels objectes en moviment fer
Recalculem Obscurances
Guardem els patchs interceptats en una nova llista (2)
Fper
Per cada patch en la llista de patchs dinàmics fer
Recalculem Obscurances
77

Fper
Si un raig intercepta un objecte en moviment
Guardem el patch en la nova llista(2)
Fsi
Esborrem la llista de patchs dinàmics
Llista de patchs dinàmics = nova llista(2)
3.2.5.Exemple pas a pas
Algorisme 12
Projecte
Suposem que l’escena ja estat carregada a les estructures de voxels. Per tant cada voxel
té una llista de patchs i una llista de polígons que els travessen.
Per cada patch:
Per cada raig del patch:
• Pas 1: es genera un raig aleatori en el patch actual (hem de generar n raigs
per patch).
Figura 3.2.5.1: pas 1 càlcul obscurances, generació del raig
• Pas 2: Calculem el Voxel origen del raig.
Figura 3.2.5.2: pas 2 càlcul obscurances, càlcul voxel origen del raig
78

Projecte
• Pas 3: Comprovem el raig contra els polígons del voxel on s’origina
(calculem la intersecció)
Figura 3.2.5.3: pas 3 càlcul obscurances, testeig raig contra els polígons del voxel
• Pas 4: suposem que el raig no intersecta avancem al següent voxel i
comprovem el raig contra la llista de polígons del nou voxel.
Figura 3.2.5.4: pas 4 càlcul obscurances, avançar al següent voxel
• Pas 5: Suposem que hi ha intersecció. Tenim el polígon interceptat i el punt
interceptat, amb el que calcularem el patch del polígon que ha rebut
l’impacte.
• Pas 6: Acumulem el valor de la Obscurance calculada per tots el raigos que
és llancen des del patch actual, per tal de calcular la Obscurance final del
patch i poder aplicar-la al Lightmap del polígon.
Per una escena amb objectes en moviment (dinàmics) és segueix els mateixos passos,
que amb una escena estàtica, però s’afegeixen dues llistes noves, la llista de patchs i
polígons dels objectes en moviment. Per inicialitzar aquestes dues llistes és segueix
l’algorisme 11 i per els successius recàlculs (successius quadres) es segueix l’algorisme
12 que hem vist anteriorment.
79

3.3. Implementació
Per a una explicació detallada de les classes consultar el manual tècnic.
3.3.1 Relació entre classes
Projecte
Tal i com ja s’ha comentat, el programa està dividit en un conjunt de classes (per
l’estructura de dades), a més s'utilitzen classes propies del Crystal Space versió 0.95.
En l’esquema següent es veu clarament quina relació existeix entre cada classe i cada
mòdul. Cal remarcar que només mostra les relacions principals entre les classes més
importants. Per a més informació consultar el codi font.
Figura 3.3.1.1: esquema de classes
Raig: ens representa un raig en 3D. Aquesta classe utilitza les classes csIntersect3D i
csPolygon3D per tal de comprovar i calcules les interseccion.
Patch: ens representa una petita part d'un polígon, per simplificar hem considerat que
un Patch correspont a un Lumel (element del Lightmap d'un polígon).
PatchList: Llista dinàmica on guardarem els Patchs.
80

Projecte
ObsPoly: Ens representa un polígon 3D de la escena, aquesta classe conté un objecte
del tipus csPolygon3D i csLightmap (per modificar el Lightmap amb les Obscurances)
i la llista de patchs del polígon PatchList.
ObsPolyList: Llista que contè objectes del tipus ObsPoly, ens servirà per
emmagatzemar els polígons de l'escena.
Voxel: Classe que representa una divisió de l'espai en forma de cub, dins d'aquest
objecte tenim la llista de patchs que hi ha dins del voxel (ObsPatchList) i la llista de
polígons que hi ha dins el voxel (ObsPolyList).
VoxelList: Llista de voxels de l'escena, contè cada uns dels voxels en que es subdivideix
l'escena.
Obscurance: Aquesta és la classe principal de la jerarquia. Aquesta classe conté la
llista de Voxels (VoxelList) i la llista de polígons de l'escena (ObsPolyList).
ObsCube: Ens representa els cubs en moviment de l’escena, guarda les dades d’un
objecte en moviment, en el nostre cas els objectes en moviment tenen una ruta de
moviment determinat.
csEngine: És la classe mare del CS, sempre s’executa la primera, aquesta classe
controla la creació de les Obscurances, com veurem en el següent apartat.
iCommandLineParser: Interfície del CS que s’encarrega de lleguir els paràmetres
d’entrada de l’aplicació.
iConfigManager: Ens ajudarà a lleguir els paràmetres dels fitxers de configuració per
tal de configurar els valors que s’utilitzen en les Obscurances (com en nombre de
voxels, nombre de raigs per patch, etc).
csMapToLoad: La funció d’aquesta classe està en carregar l’escena.
iMeshWrapper: Interfície encarregada de controlar els accessos a la geometria d’un
objecte. A partir d’aquesta podem accedir als polígons, vèrtexs, etc.
csPath: Classe que s’encarrega de calcular a cada quadre “d’animació” la nova posició
on es troben els objectes en moviment.
Walktest: Classe encarregada d’inicialitzar l’aplicació walktest, la seva funció està en
controlar la activació/desactivació de les Obscurances per l’usuari i a més de controlar
que és realitzi el càlcul de les Obscurances en temps real a cada quadre de l’animació.
3.3.2 Seqüència d’execució bàsica
L’esquema de la seqüència d’execució bàsica per el nostre projecte és:
81

Figura 3.3.1.2: seqüència d’execució bàsica
Projecte
Primer de tot instanciem l’objecte walktest, que ens inicialitzarà tot el necessari per
l’execució de l’aplicació. Aquest objecte ens llegeix els fitxers de configuració
necessàris, com per exemple “autoexec.cfg” que ens indica l’associació de les tecles
amb accions, tal i com veurem en el següent apartat. A continuació el control de
l’aplicació passa a la classe csEngine que llegirà el fitxer de configuració “engine.cfg”
que conté en el nostre valors de configuració de les Obscurances (per exemple: nombre
de voxels, nombre de raigs per patch, etc), acte seguit calcularà les Obscurances i
modificarà els valors dels Lightmaps dels polígons i permetrà navegar l’escena. En el
cas de les Obscurances en temps real la classe csEngine crida a cada quadre d’animació
la funció setupframe de la classe walktest i és aquí on és realitzaran les accions
necessàries.
Anem a veure amb més detall el que fa l’aplicació walktest.
3.3.3 Aplicació walktest
Per tal de desenvolupar el projecte, necessitem estudiar dues parts del CS. Aquestes
parts son l’aplicació walktest i la classe csEngine.
L’aplicació walktest ens permet navegar per una escena, per tant podem aprofitar-la
com a punt de partida del desenvolupament del projecte.
Anem llavors, a estudiar com funciona l’aplicació walktest.
Aquesta aplicació com hem comentat anteriorment, ens permetrà navegar per una
escena d’una manera còmode, a més és molt configurable per a l’usuari (consultar el
manual d’usuari). Aquesta aplicació és troba en el directori “apps/walktest/” del CS.
Les Obscurances és poden activar o desactivar, es a dir podem veure com quedarien els
Lightmap sense el càlcul de les Obscurances o amb el càlcul. Al igual que les
Obscurances en temps real per objectes en moviment. Per realitzar això existeix un
82

Projecte
fitxer de configuració “data/config/autoexec.cfg” on s’associa a una combinació de
tecles la generació d’una comanda/event. Aquestes comandes s’intercepten per
l’aplicació walktest En el nostre cas el fitxer de configuració “autoexec.cfg” quedarà de
la següent manera:
bind o obscurances toggle
bind i rt_obscurances toggle
Amb aquestes sentències indiquem que quan es premi la “o” es genera una comanda de
canvi del valor de les Obscurances a true o false segons el cas, aquesta comanda
s’intercepta per la funció commandhandler (dins el fitxer walkcmd.h de l’aplicació
walktest) on és controlarà l’acció a realitzar:
else if (!strcasecmp (cmd, "obscurances"))
{
csEngine *engine = (csEngine*)(Sys->Engine);
csCommandProcessor::change_boolean (arg,
&engine->use_obscurance, "obscurances");
if (engine->use_obscurance) obs->ActivarObscurances();
else obs->DesactivarObscurances();
}
else if (!strcasecmp (cmd, "rt_obscurances"))
{
csEngine *engine = (csEngine*)(Sys->Engine);
if (engine->use_obscurance)
{
csCommandProcessor::change_boolean (arg,
&engine->GetObscurance()->Realtime, "real time obscurances");
}
}
Podem observar com segons el cas (“o” o “i”) la acció a realitzar serà o bé s’activarà o
és desactivarà les Obscurances o bé s’activarà les Obscurances en temps real (objectes
en moviment).
En el cas de les Obscurances en temps real també cal afegir una sèrie de línies al fitxer
“walktest.h” per tal de que a cada quadre de “l’animació” és calculin les Obscurances
dels patchs implicats.
void WalkTest::SetupFrame ()
{
…
csEngine *engine = (csEngine*)(Sys->Engine);
}
//the next step for the animate cube
if (engine->GetObscurance())
engine->GetObscurance()->Animate (elapsed_time);
És a dir quan la classe csEngine prepari el següent quadre de l’animació per a ser
mostrat en el següent quadre, el que farà serà cridar a la funció Walktest::SetupFrame
i aquesta cridarà la funció Animate de la classe Obscurances.
83

3.3.4 Classe csEngine
Projecte
La classe csEngine és el punt de partida de CS i la que s’encarrega de calcular la
il·luminació de l’escena, per el que ens pot ser útil entendre el que fa.
El principal pas a realitzar per el motor Crystal Space està en comprovar que el flag
use_obscurance està actiu en el fitxer de configuració engine.cfg (en el directori
“data/config/”). La classe csEngine llegeix aquest fitxer de configuració, consultar el
manual d’usuari per a més informació.
Aquest fitxer de configuració és llegeix des de la classe csEngine, concretament en la
funció ReadConfig i és on podrem inicialitzar els flags de les Obscurance:
csEngine::use_obscurance = Config->GetBool
("Engine.Lighting.Obscurance.Enable",
csEngine::use_obscurance);
if (csEngine::use_obscurance)
{
csObscurance::maxim = Config->GetFloat (
"Obscurances.Maxim", csObscurance::maxim);
}
csObscurance::rays4patch = Config->GetInt (
"Obscurances.Rays4patch", csObscurance::rays4patch);
csObscurance::DimensionXBoxel = Config->GetInt (
"Obscurances.XBoxels", csObscurance::DimensionXBoxel);
csObscurance::DimensionYBoxel = Config->GetInt (
"Obscurances.YBoxels", csObscurance::DimensionYBoxel);
csObscurance::DimensionZBoxel = Config->GetInt (
"Obscurances.ZBoxels", csObscurance::DimensionZBoxel);
csObscurance::Sectors = Config->GetInt (
"Obscurances.Sectors", csObscurance::Sectors);
A partir d'aquí quan Crystal Space calculi la il·luminació en l'escena, es a dir, quan és
cridi la funció ShineLight es farà:
if (csEngine::use_obscurance)
{
obs_debug = new csObscurance(this, meter);
obs_debug->DoObscurance();
}
El primer que fa aquest codi és comprovar si el flag de les Obscurances està actiu, si és
el cas, instanciarà on objecte del tipus Obscurance (prepara l'esctructuració en voxels de
l'escena, prepara els lightmaps, etc). El segon pas està en procedir a calcular les
Obscurance.
84

Projecte
Un cop el càlcul de les Obscurances s'ha realitzat, tots els polígons de l'escena tenen en
els seus Lightmaps els valors de les Obscurances calculades, per el que l'usuari podrà
navegar sense cap problema per l'escena.
3.3.5 Diagrama de seqüències: inicialització estructures
Anem a veure d'una manera simplificada el diagrama de seqüències:
Figura 3.3.5.1: diagrama seqüències inicial
La classe csEngine llegueix la configuració del fitxer data/config/engine.cfg, a
continuació i després de carregar les dades de l'escena crida, d'entre d'altres a la funció
ShineLight que ens càlcula la llum de l'escena i l'aplica a cada un dels Lightmaps dels
polígons que composen l'escena. En aquest punt, si el flag use_obscurance està activat
llavors instancia un objecte del tipus Obscurance.
La classe Obscurance crea una llista de polígons de l'escena (del tipus ObsPoly) i a
continuació estructura l'escena en voxels, és a dir, inicialitza les estructures de dades
dels Voxels (les llistes de patchs i les llistes de polígons de cada voxel).
A continuació mostrem un diagrama de seqüència més detallat del càlcul de les
Obscurances, no cal dir que és un esquema general.
85

Càrrega de les dades
Projecte
La implementació de la càrrega de les dades amb el motor gràfic Crystal Space és la
següent:
bool csObscurance::LoadScene()
{
iSectorList * sec;
iSector * s1;
csSector * sec1;
iMeshList * imeshes;
iMeshWrapper * imesh;
iThingState * thing;
iPolygon3D * poly;
csPolygon3D * p;
csVector3 * vec;
ObsPoly *op;
register int i = 0, j = 0, k = 0, aux = 0, nv = 0;
boundbox.StartBoundingBox(); //init the boundbox
sec = engine->GetSectors (); //access to all the engine's sectors
//l’objecte cube s’ha inicialitzat abans amb la mesh corresponent
if (Cube)
{
//test the cube’s thing interface for return the id
thing_cube = SCF_QUERY_INTERFACE(Cube->Mesh->GetMeshObject(), iThingState);
}
if (thing_cube)
{
poly = thing_cube->GetPolygon(k);
pol_cube = poly->GetPrivateObject();
ID_CUBE = pol_cube->GetParent()->GetID();
}
//for all the sectors in engine
for (; i < sec->GetCount(); i++)
{
s1 = sec->Get(i); //acces to interface sector(i)
sec1 = s1->GetPrivateObject(); //access to sector
imeshes = sec1->GetMeshes(); //access to all sector's meshes
for (j = 0; j < imeshes->GetCount(); j++)
{
imesh = imeshes->Get(j); //access to interface meshes(j)
//access to thing interface of the mesh
thing = SCF_QUERY_INTERFACE(imesh->GetMeshObject(), iThingState);
if (thing)
{
//move trought all the thing's polygon
for (k = 0; k < thing->GetPolygonCount(); k++)
{
poly = thing->GetPolygon(k); //access to polygon's interface(k)
p = poly->GetPrivateObject(); //acces to polygon object
if ((p->GetUnsplitPolygon() == NULL ) && //chech if polygons is not split
p->GetLightMapInfo() && //and if it has a lightmap
p->GetLightMapInfo()->GetPolyTex()->GetCSLightMap())
{
nv = p->GetVertices ().GetVertexCount();
vec = new csVector3[nv];
for ( aux = 0; aux < nv; aux++)
{
86

}
}
vec[aux] = p->Vwor(aux);
//actualizen la caixa englobant de l’escena
boundbox.AddBoundingVertex(vec[aux].x, vec[aux].y, vec[aux].z);
delete []vec;
//creem un nou obspoly a partir del polígon actual
op = new ObsPoly(p);
//afegim el cub a l’estructura de cubs dinàmnics
if (((int)p->GetParent()->GetID() == ID_CUBE))
Cube->InsertPolyCube(op);
else
//afegim el polygon a la llista de polygons de l'escena
ObsPolyList->Insert (op);
}//end if
}//end for polygons
thing->DecRef();
}//end if thing
}//end for meshes count
}//end count sectors count
return(true);
Estructuració de l’escena en Voxels
Projecte
Per tal de crear la estructuració de l’escena en voxels tenim la següent implementació:
bool VoxelList::CreateVoxels()
{
if (csObscurance::Config::voxelsx

voxel.SetBoundBox (&bound);
list.push_back(voxel);
} //end i loop
} //end j loop
} //end k loop
3.3.6 Diagrama de seqüències: càlcul obscurances
Figura 3.3.6.1: diagrama seqüències càlcul de les Obscurances
Projecte
Com hem comentat en l’esquema anterior, la classe obscurances crea una llista de
polígons de l'escena (del tipus ObsPoly) i a continuació estructura l'escena en voxels, és
a dir, inicialitza les estructures de dades dels Voxels (les llistes de patchs i les llistes de
polígons de cada voxel).
Anem al cas mostrar en la figura anterior. Suposem que les dades ja estan carregades i
l’escena ja està “voxelitzada” i anem a calcular les Obscurances per un patch
determinat:
1. La classe obscurances es situa en el primer voxel de l’escena.
2. S’agafa el primer patch de la llista de patchs del primer voxel.
3. Es genera un raig.
4. Es comprova el raig contra la llista de polígons del voxel des del que s’origina el
raig.
5. Ens quedem amb la intersecció més pròxima.
88

Projecte
6. A partir del polígon interceptat i el punt interceptat calculem el patch interceptat.
7. Apliquem les fórmules de les Obscurances a partir del color del patch
interceptat, la seva emitància, reflectància, etc.
8. Apliquem les Obscurances al patch origen del raig, hem de tenir en compte que
normalment es llancen n raigs, per tant s’acumularia el valor de les Obscurances
i al final s’aplica al Lightmap..
Aplicar les Obscurances al patch
Per tal d’aplicar les obscurances al patch corresponent tenim la funció
ObsPoly::CopyColor2Lumel (int lumel, const csColor & value). Aquesta funció
accedeix a la posició (lumel representat pel patch) del lightmap del polígon i guarda el
valor de la Obscurance en ell.
void ObsPoly::CopyColor2Lumel(int lumel, const csColor & value)
{
int res;
//the original value are in lm_c
//agafem els valors del lightmap original i li afegim
//el color de la obscurance calculada i maxaquem
//el resultat al lightmap
csRGBpixel *lm_c = copy_lightmap->GetArray ();
csRGBpixel *lm = lightmap->GetArray ();
// Red
res = QRound(lm_c[lumel].red * value.red);
if (res > 255) res = 255;
else if (res < 0) res = 0;
lm[lumel].red = res;
// Green
res = QRound(lm_c[lumel].green * value.green);
if (res > 255) res = 255;
else if (res < 0) res = 0;
lm[lumel].green = res;
// Blue
res = QRound(lm_c[lumel].blue * value.blue);
if (res > 255) res = 255;
else if (res < 0) res = 0;
lm[lumel].blue = res;
}
89

3.4 Resultats i conclusions
3.4.1 Captures de pantalla
Projecte
Room amb Obscurances i llum directe Room sense Obscurances i llum directe
Infinite amb Obscurances i llum directe Infinite sense Obscurances i llum directe
B4 planta, Obscurances i llum ambient B4 planta, sense Obscurances i llum ambiente
90

Projecte
B4 interior, Obscurances, llum ambient B4 interior, sense Obscurances, llum ambient
P4, passadís, Obscurances i llum directe P4, passadís, sense Obscurances i llum directe
P4, passadís, Obscurances i llum directe P4, passadís, sense Obscurances i llum directe
91

3.4.2 Resultats
Escena Poligons Patch Raigs Temps C. FPS FPS/TR
Room 73 1423
60 1,7 56 17
80 2,2 56 14
100 2,8 56 11,5
4016
Infinite 180 5508
13824
60 4,6 56 10,5
80 5,9 56 8
100 7,3 56 6,5
60 6,4 40 -
80 8,3 40 -
100 10,3 40 -
60 19,8 40 -
80 20,7 40 -
100 26,1 40 -
Projecte
Escenes Característiques: Room i Infinite, per a diferent número de patchs. La segona
columna mostra el número de polígons, la tercera el número de patchs, la quarta el
número de raigs llançats per patch per al càlcul de les obscurances, la cinquena és el
temps de computació, la sexta el número de quadres per segon (FPS), y la última el FPS
recalculant les Obscurances amb objectes en moviment dins de la escena.
El sistema utilitzat per a la prova ha estat un AMD athlon 900 MHz, 768 MB RAM.
Aquest ordinador és un PC de gamma baixa, i la implementació podria ser més eficient,
tot i així els resultats han estat molt satisfactoris.
3.4.3 Conclusions
Els resultats demostren l’assoliment dels objectius. Volem remarcar que la màquina
empreada és de gama baixa, però tot i així els resultats son satisfactoris. Si tenint en
compte que la programació no ha estat del tot eficient, podem concluir que la velocitat
del càlcul de les Obscurances en temps real és excelent.
3.5 Treballs futurs
• Adaptar les Obscurances en temps real a les noves versions del Crystal
Space (actualment 0.98r003).
92

Projecte
• Adaptar la implementació al sistema de plugins, per tal d’independitzar al
màxim les obscurances del motor i poder carregar-les/descarregar-les en
temps d’execució.
• Millorar l’eficiència i permetre escenes/objectes més complexes.
• Permetre més objectes en moviment.
93

Annexes
Annex 1: Història dels Videojocs/consoles
Annexes
La història del videojocs està molt lligada al sorgiment de la ciència dels gràfics per
computador.
Anem a fer un petit d’historia sobre els videojocs:
Els principis
1958 – Bill Nighinbottham creà (menys d’una setmana) el videojoc tennis for two per a
una fira cientìfica, però no el va registrar per que pensava que no el portaria enlloc.
1972 – Nolan Bushnell fundà la companyia Atari publicant el joc de Bill Nighinbottham
però sota el nom de pong.
El primer videojoc creat va se per Nolan Bushenll abans de crear Atari. S’anomenava
Computer Space.
1975 – Apareix el primer joc en color Indi 800 que permetia jugar fins a 8 jugadors
simultaneament. Creat per Atari.
1976 – Steve Jobs i Steve Wozniak, desenvolupen en Atari en joc Breakout. En 1978 els
dos Steve van fundar Apple Computer.
Però podem retornar molt més endarrera d’aquesta època, l’any 1889.
1889 – Un empresa japonesa fabricava cartes per el joc japonès Hanafunda (cartes fetes
a ma molt detallades). Aquesta empresa era Nintendo fundada per Fusajiro Yamauchi.

Annexes
1929 - Les cartes ja es distribueixen en terres americanes. Aviat van firmar acords amb
Disney i altres companyies per poder afegir nous dissenys.
1975 – Nintendo s’associa amb Mitsubisi i comencen a crear videojocs.
1978 – Primers consoles de videojocs anomenades TV Game 15 i TV game 16 amb jocs
típics de tennis, cotxes, etc.
1980 – Es distribueixen les Game y Watch que eren les primeres consoles portàtils del
mon, precursores de Game Boy.
Shigeru Miyamoto en Nintendo crea el clàssic Donkey konk. On apareix la
mascota de Nintendo Mario.
Evolució de les videoconsoles (1972-2001)
1972 – La primera videoconsola de caràcter comercial veu la llum. El nom era
Magnavox Odyssey i tenia 8 bits.
1975 – Atari crea la seva consola Atari Pong, només era possible jugar al pong. Va tenir
molt d’impacte cultural i va donar origen al impuls dels videojocs.
1977 – Atari llança una nova consola: Atari 2600. Els jocs eren intercanviables i tenia
un ampli catàleg.
95

Annexes
Al poc temps de sortir la consola va treure una nova versió la junior, que va permetre
que la consola estigués en el mercat fins als anys 90. Per tant és la consola que més
temps a estat en el mercat.
1978 - Surt al mercat Magnavox-Odyssey2, però no va arribar a la popularitat de l’Atari
2600. Era la primera en incorporar un teclat.
1980 – Surt al mercat la consola Mattel Intellvision amb un motor gràfic de 16 bits, però
al igual que els altres competidors de l’Atari no va tenir gaire èxit tot i tenir millors
capacitats gràfiques. Fou la primera consola que va substituir els joysticks per mandos
amb botons.
1983 – La consola Nintendo Entertainment System, llançada al Japó en 1983 com la
Famicom (Computadora familiar), marcà la segona era dels videojocs i el començament
de la hegemonia de Nintendo en aquest mercat. La NES era un sistema de 8 bits amb 52
colors i solament 2K de RAM. Fou un éxit total i es convertí en el sistema de videojocs
més venut des de la Atari 2600. El jocs Súper Mario Bros. 3, llançat en 1988, va vendre
més de set millons de copies. La popularitat de la NES convertí a Nintendo en la
companyia japonesa més exitosa per 1990.
96

Annexes
1989 - La Turbografx-16 fou llançada en Japó en 1988. Tenia una CPU de 8 bits camb
un chip per gràfics de 16 bits. Fou el primer sistema amb lector de CD incorporat. Però
va sucumbir davant la Sega Genesis, degut en part a la seva menor quantitat de jocs i a a
la seva CPU menys potent.
1991 – L’entrada de Nintendo en el mon dels 16 bits va arribà de la mà del jocs “Súper
Mario World”. En un principi la seva popularitat fou inferior a la de la Sega Genesis,
però va aconseguir remuntar el vol i va representar una forta competència amb el model
rival en una competència molt tancada. La Súper NES i Sega van compartir el lidertage
en el mercat dels videjocs durant els cinc anys següents, fins l’arrivada dels jocs de 32
bits. Aquesta època de competència va tenir l’efecte d’augmentar la selecció de jocs
disponibles, inclús amb productes de terces parts.
1995 – Fou introduïda en el mercat en la primavera (boreal) de 1995 la consola Sega
Saturn. Era un sistema de 32 bits amb molta més memòria RAM i un lector de CD.
Amb els seus gràfics tridimensionals i so digital, la Saturn va tenir una gran arrancada i
va arribar a vendre 100,000 unitats en els seus tres primers dies, segons Sega. Amb el
temps no va tenir la demanda esperada i la PlayStation de Sony la va desbancar un any
més tard en Estats units.
1995 – La PlayStation de Sony va començar la seva vida com un lector de CD que
s’incorporava a la Súper NES. Nintendo i Sony no van conseguir posar-se d’acord sobre
la comercialització del nou aparell, per el que aquesta última decidí desenvolupar més el
seu producte fins convertir-lo en una consola. La PlayStation sorgí al mercat
97

Annexes
estadounidens en setembre de 1995, inaugurant l’era dels 32 bits en aquesta àrea. Cap al
maig del 2000 un de cada quatre cases en Estats Units tenia una PlayStation.
1996 - Nintendo va passar l’era dels 32 bits, fent front a les amenaces de les consoles de
Sega i Sony mentre treballava en un aparell de nova generació. La N64, llençada en
Estats Units en 1996, trasllada els èxits de la companyia a los 64 bits, enfatizant la
sensació d’una tercera dimensió. La targeta gràfica de la N64 fou produïda per Silicon
Graphics, la companyia de computadors que portar a les pantalles èxits cinematogràfics
com “Jurassic Park”.
1999 - La Dreamcast fou la primera consola de videojocs amb arquitectura de 128 bits.
Tenia un hardware que solament podia trobar-se en una poderosa computadora personal.
Disposava d’un processador a 200 MGhz, un chip de so de 64 canals i 26 MB de
RAM... i tot per jugar. Tot aquesta potència de hardware va desembocar en gràfics més
ràpids, més detallats i amb major qualitat. També incorporava un modem de 56K per
aprofitar la creixen popularitat dels jocs en xarxa.
2000 – Sony va llançar la consola PlayStation 2 amb un motor de 128 bits a 300 MGhz,
lector de DVD, so Dolby surrond (AC-3) i memòria de 32 MB de RAM, un xip de so de
48 canals. Disponia també d’una expansió per afegir un disc dur i un adaptador de xarxa
per accedir a internet. Té una arquitectura amb quatre processadors (Emotion engine
que seria la CPU, graphic syntetizer que seria la GPU, sound processor, i/o processor),
va ser quan es comença a parlar entre el paral·lelisme entre GPU i CPU.
98

Annexes
2001 – Microsoft treu al mercat la consola XBOX la primera consola amb una potència
igual a un potent ordinador. Les seves característiques eren un processador a 700 MHz,
amb 64 MB de RAM, port ethernet, disc dur de 8 GB, targeta gràfica de Nvidia ,suport
per conectar 4 comandaments, 256 canals de so. Té tres processadors (CPU, la GPU de
nvidia, processador de so.)
2001 – Nintendo produeix la Gamecube una altra consola de 128 bits. Amb un
processador de 405 MGhz, 24 MB de ram, incorpora un nou format de Cd el mini-dvd
per tal d’evitar la pirateria. Té tres processadors (CPU, la GPU “Gekko”, processador de
so.).
Actualment estan en desenvolupament la Playstation 3, la Game Cube 2 i la Xbox 2,
que aportaran una extraordinària potència gràfica als jocs, aportant experiències mai
vistes.
La dècada dels clàssics (1978-1988)
1978 – Sorgeix el videojocs Space Invaders creat per Taito que permetia guardar la
puntuació més alta.
99

Annexes
1979 – Atari creà Asteroids, va suposar una revolució ja que va donar forma a un nou
entreteniment. Va aparèixer en la revista Newsweek.
1980 – Namco realitza el joc Pacman, el joc més original dels que havia sortit fins al
moment.
1981 – Aparaix Donkey kong per Atari, i de la ma de Namco: Miss Pacman (pacman 2)
i Galaga.
1982 – Els jocs que van sorgir foren: Super pacman, Moon Patrol, Donkey kong jr, Star
Trek, Q’Bert, etc.
1983 – Es el primer cop que s’utilitza un argument de pel·lícula en un videojoc
anomenat Tron. El van seguir els jocs de Star wars per atari, Dragon’s Lair (el primer
en utilitzar la tecnologia Laser Disc).
Nintendo creà Mario Bros, que era el primer cop que el protagonista de Donkey
kong tenia el seu videojoc. Aquest va tenir molt d’èxit per el que va passar a ser la
mascota de Nintendo.
Nintendo també creà primera consola independent (abans ho feia amb empreses
associades). La consola fou anomenada Nintendo.
1984 – Apareix l’empresa Capsule Company (Capcom). Els jocs que apareixen aquest
any son: Star Force, Pac-Land (on pacman debuta en jocs de plataformes), Kung fu
Master, Paperboy, etc.
1985 – Yamauchi (directori de Nintendo) encarrega a Miyamoto el joc Super Mario
Bros que era el primer videojoc llarg, ple de colors que va trencar esquemes.
Al arribar la consola de Nintendo a Espanya va ser la consola que va desbancar
la consola Atari 2600. Els jocs més importants de la època foren: Pitfall 2, Indiana Josen
and the Temple of Doom, Empire Strikes Back, Ghosts’N’Goblins.
1986 – Surten els jocs com Outrun, Wonderboy, Arkanoid, Bubble Booble, Rygar)
100

Annexes
1987 – Destaquen tres companyies: Sega, Capcom i Taito amb jocs com: After Burner,
Alien Syndrome, Shinobi, Heavyweight Champ y Wonder Boy In Monster Land. Però
el joc amb més exit va ser Stree Fighter.
1988 – Els jocs més importants del període son la segona part del Ghost and Ghost
(Ghost and Goblins), Ninja gaiden. I el mític Tetris del que a dia d’avui encara es fan
diferents versions en 3D.
101

Annex 2: Generes de videojocs
Aventures
Annexes
Els jocs d’aquest tipus son jocs basats en una història on habitualment s’han de resoldre
diferents tipus de puzzles. Poden ser basades en texte (com les primeres aventures de
Zork i PlanetFall) o gràfiques (la sèrie de King Quest, Grabiel Knight o Monkey Island)
i és basen en seleccionar una acció i objecte de l’acció, es a dir, l’usuari selecciona una
acció i després l’objecte de l’acció. No solen ser jocs en temps real, és a dir mentre
l’usuari fa una acció en el mon virtual no succeeix res.
Acció
King quest Monkey Island
Son jocs en temps real en els que el jugador ha de reaccionar molt ràpidament al que
passa en el mon virtual. Els jocs d’aquesta categoria el solen dominar jocs en primera
persona, anomenats shooters (FPS: first person shooters), com el Quake i Unreal .
També en aquesta categoria tenen cabuda jocs en tercera persona com per exemple
Tomb Raider que son una mescla entre joc d’aventures i joc d’acció. Els enemigs del
jugador poden ser o bé personatges controlats per Intel·ligència Artificial o altres
jugadors a través de la xarxa.
RPGs (Role-playing games)
Unreal Tournament Quake 3
En els jocs de rol el jugador dirigeix un grup de personatges en una sèrie d’aventures. El
joc consisteix en gradualment incrementar les habilitats i força dels personatges. Jocs
d’aquest gènere son l’Ultima, Might and Magic, Final Fantasy i Baldur’s Gate. Aquest
gènere sol tenir complexes sistemes de màgia i diferents races de personatges, a més
d’una trama molt elavorada.
102

Estratègia
Baldur’s Gate Final Fantasy VIII
Annexes
Els jocs d’estratègia consisteixen en gestionar un conjunt limitat de recursos per tal
d’obtenir èxits en les missions. El conjunt de recursos habitualment consisteix en
decidir quins tipus d’unitats s’han de crear i quan s’han de crear. D’aquest tipus de jocs
n’hi ha de dos tipus, basats en torns i de temps real. Els primers consisteix en que el
jugador decideix quina és l’acció que realitzarà, i quan aquest acaba, li toca el torn al
següent jugador/ordinador. En el segon cas, els jugadors/ordinadors poden fer les
accions encara que un jugador no estigui preparat. Els jocs d’estratègia de temps real
substitueixen els oponents humans per la intel·ligència artificial. Jocs d’aquest tipus son
Command & conquer, Age of empires, Praetorians i Cossacks.
Simulació
Comand & conquer Praetorians
Emulen les condicions del mon real i la maquinaria complexe, és el cas dels simuladors
de vols, en els que el jugador abans de començar han d’estudiar el manual
d’instruccions per saber com funciona l’avió, tank, tren, etc. Podem trobar en aquest
gènere jocs del tipus Flight Simulator.
Flight Simulator 2002
103

Esports
Annexes
Son jocs que fan participar al jugador en un esport concret, com poden ser el futbol,
bàsquet, golf, tennis, etc. Reprodueixen les regles i estratègies de l’esport d’una manera
acurada. Sovint, sobretot en els jocs de futbol hi ha diferents rols: Entrenador d’un
equip (ha de gestionar l’alineació, contractar nous jugadors, etc) o jugador d’un equip
(simplement juga els partits). Uns exemples clàssics son les sèries Fifa o Nba Live.
Lluita
Fifa 2004 Nba Live 2003
Els jocs de lluita son jocs de dos jugadors en els que el jugador controla un personatge
en la pantalla i utilitza combinacions de moviments per atacar al oponet i defensar-se
dels seus atacs. Generalment es veuen des de la vista d’alçat (del costat), tot i que cada
cop més s’han introduït jocs en 3D. Els jocs que trobem en aquest gènere son el
Soulcalibur 2, Street fighter
Jugar a ser Deu
SoulCalibur 2 Street Fighter Alpha 3
Son jocs en els que l’usuari representa el deu del univers del joc i en el que pot crear
objectes, moure muntanyes, etc. Son jocs d’aquest estil per exemple RollerCoaster
Tycoon, Black’n’white, etc.
Black’n’white Roller Coaster Tycoon
104

Jocs online
Annexes
Podem incloure en aquesta categoria els altres gèneres que disposin de la possibilitat de
multijugador a través de la xarxa. Al voltant d’aquest gènere neixen grans comunitats de
jugadors com és el cas dels jocs Ultima Online o Everquest.
Educatius
Ultima Online
Son pensats per a que el jugador aprengui mentre s’entretén. Son jocs pensats per a nens
petits per tal de que aprenguin. El disseny d’aquests jocs necessita de gent experta en el
camp educatiu per tal de saber si els continguts son apropiats per als nens.
Puzzles
Aquest tipus de gènere està pensat per a que els jugadors resolguin problemes utilitzant
la intel·ligència. Trobem jocs com The Increible Machine i The Castle of Dr. Brain.
Jocs de casualitat
S’inclouen en aquest gènere els jocs que son adaptacions de jocs tradicionals com els
escacs, el solitari, etc. També s’inclouen jocs a través de web del tipus Poker,
Concentracio, o bé adaptacions de programes de televisió de l’estil de la roda de la
fortuna o Qui vol ser milionari ?. En general son jocs molt fàcils de jugar on les partides
duren poc.
105

Annex 3: Mercat dels videojocs
Annexes
Actualment el mercat dels videojocs és una indústria que mou molts diners degut al seu
gran grau d’innovació i creativitat tecnològica. Però per què tenen tant d’èxit els
videojocs ?. la resposta està clara: les persones necessitem divertir-se, passar el temps
lliure, fugir de la realitat, conèixer gent, per el que busquen la sortida en els videojocs
que aporten una manera ràpida de fer-ho.
A continuació mostrem una gràfica del creixem dels videojocs.
%
80
70
60
50
40
30
20
10
0
A continuació mostrem una taula (Regne unit) del nombre de pc, i consoles.
Platform
PC
% Households with children who have
video games/PCs/online access
1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000
Sony PS2
Nintendo Gamecube
Microsoft Xbox
2002
11,000,000
2,415,000
139,000
157,500
2003
12,870,000
3,067,050
176,530
200,025
2004
15,057,900
3,895,154
224,193
254,031
Video Games
PC
Online Access
106

Annex 4: Format d’escenes de CS
Annexes
El format estàndard comprensible directament per Crystal Space 0.95 és un format
ASCII pur, dividit en diferents bloc:
• Bloc de definició del mon o escena.
• Bloc de definició de textures.
• Bloc de definició de materials.
• Bloc de definició de malles.
• Bloc de definició de sectors.
• Bloc de definició de sector inicial.
Amb aquests blocs en fem prou per a definir la nostra escena. Passem a explicar d’una
manera detallada els components que formen cada part.
Definició textures
La primer part dins el fitxer és el bloc de definició de textures, que relaciona una nom
lògic amb el fitxer físic que conté la imatge. Aquest fitxer d’imatge o bé ha d’estar dins
el fitxer comprimit en format ZIP del nostre projecte o dins el fitxer de textures de
Crystal Space, per a més informació consultar l’annex sobre Crystal Space i el manual
d’usuari.
Les textures s’apliquen als diferents objectes dins els sectors, com és comenta en el bloc
de definició de sectors.
Un exemple de codificació seria:
TEXTURES (
TEXTURE 'andrew_wood' (FILE (/lib/stdtex/andrew_wood.jpg))
)
On la part definida per FILE identifica el nom del fitxer dins el fitxer comprimit en ZIP
en el primer cas, i en el segon especifica que la imatge és trobar en el fitxer de textures
de CS. Es a dir dins el fitxer comprimit haurem de tenir també les textures, o bé afegirles
al fitxer de textures de Crystal Space.
Definició materials
La definició dels materials és una manera de poder renombrar els noms de les textures.
La sintaxis és la següent:
MATERIALS (
107

)
MATERIAL 'wood' (TEXTURE ('andrew_wood'))
…
Definició Malles
Annexes
En la part de definició de malles simplement s’especifica els objectes, en aquest cas per
exemple és crea una caixa (una pota d’una taula) amb la textura de fusta
(“andrew_wood”).
MESHFACT 'tableP' (
PLUGIN ('thingFact')
PARAMS (
VERTEX (-.05,.85,.05) VERTEX (.05,.85,.05)
VERTEX (-.05,.85,-.05) VERTEX (.05,.85,-.05)
VERTEX (-.05,0,.05) VERTEX (.05,0,.05)
VERTEX (-.05,0,-.05) VERTEX (.05,0,-.05)
)
)
MATERIAL ('andrew_wood') TEXLEN (1)
POLYGON 'n' (VERTICES (1,0,4,5))
POLYGON 'e' (VERTICES (3,1,5,7))
POLYGON 's' (VERTICES (2,3,7,6))
POLYGON 'w' (VERTICES (0,2,6,4))
D’aquesta manera podem definir una malla i afegir-la a posteriori en un sector tans cops
com ens interessi de la següent manera:
MESHOBJ 'tableP1' (
PLUGIN ('thing')
PARAMS (FACTORY ('tableP'))
HARDMOVE (V (-2.4,-1,2.9))
)
on hardmove ens determina la nova posició de l’objecte.
També és possible definir una malla directament en dins un sector, tal i com veurem a
continuació.
Definició sectors
La segona part, i la / les part / parts més important / importants dins el fitxer és el bloc
on s’especifica cada un dels sectors que formen part de l’escena. Ve precedit del terme
SECTOR i el seu interior engloba tots els polígons, objectes, portals, textures, etc., que
formen part del sector. El seu ús és pot apreciar en l’exemple:
SECTOR 'nom_sector1’
(
;especifiquem un cub que serà possible moure’l
108

)
MESHOBJ 'cubterra'
(
PLUGIN ('thing')
PARAMS (
MOVEABLE (TRUE) ; aquest cub podrà
; estar en moviment
)
VERTEX (-.5,-.5,.5) VERTEX (.5,-.5,.5)
VERTEX (-.5,-.5,-.5) VERTEX (.5,-.5,-.5)
VERTEX (-.5,.5,.5) VERTEX (.5,.5,.5)
VERTEX (-.5,.5,-.5) VERTEX (.5,.5,-.5)
MATERIAL ('red') TEXLEN (1)
POLYGON 'up' ( VERTICES (4,5,7,6) )
POLYGON 'down' ( VERTICES (2,3,1,0) )
POLYGON 'front' ( VERTICES (6,7,3,2) )
POLYGON 'back' ( VERTICES (5,4,0,1) )
POLYGON 'left' ( VERTICES (4,6,2,0) )
POLYGON 'right' ( VERTICES (7,5,1,3) )
)
HARDMOVE (V (0.9,0,-3)); posició on estarà el cub
Annexes
Dins d’aquests blocs s’especifiquen les malles de vèrtexs i polígons que en formen part,
així com els polígons que representen portals que comuniquen amb altres sectors,
textures que s’apliquen a cada polígon, les llums, etc.
Definició inicial de l’escena
Aquest mon engloba tots els blocs anteriors, ja que determina tota l’escena, i és
necessària per a que el Motor Gràfic identifiqui correctament tots els sectors que en
formen part.
La seva definició en format CS és:
WORLD(
)
Exemple de fitxer en format CS
WORLD( Definim l’inici de l’escena.
TEXTURES ( Definim l’inici del bloc de definció de textures
Textura de les parets, terra i sostre.
TEXTURE 'paret.gif' (FILE(/lib/stdtex/floors_1_d1n__128.jpg))
...
) Fi del bloc de definició de textures
MATERIALS ( Definim l’inici del bloc de definció de materials
MATERIAL 'marble_08_ao___128' (TEXTURE (paret.gif')
109

)
MESHFACT 'tableP' ( Definim un bloc que serà una malla
PLUGIN ('thingFact')
PARAMS (
VERTEX (-.05,.85,.05) VERTEX (.05,.85,.05)
VERTEX (-.05,.85,-.05) VERTEX (.05,.85,-.05)
VERTEX (-.05,0,.05) VERTEX (.05,0,.05)
VERTEX (-.05,0,-.05) VERTEX (.05,0,-.05)
)
)
MATERIAL ('andrew_wood') TEXLEN (1)
POLYGON 'n' (VERTICES (1,0,4,5))
POLYGON 'e' (VERTICES (3,1,5,7))
POLYGON 's' (VERTICES (2,3,7,6))
POLYGON 'w' (VERTICES (0,2,6,4))
Annexes
Definició del sector inicial, la camera començarà al sector 19 a la posició X, Y i Z.
START (sector19, -7.6, 3.8, 0.0)
Inici del bloc de definició dels sectors que formen l’escena.
SECTOR 'sector19' Definició d’un sector
(
MESHOBJ 'cubterra' Definició d’una malla dins el sector
(
PLUGIN ('thing')
PARAMS (
MOVEABLE (TRUE) ; aquest cub podrà
; estar en moviment
)
)
)
VERTEX (-.5,-.5,.5) VERTEX (.5,-.5,.5)
VERTEX (-.5,-.5,-.5) VERTEX (.5,-.5,-.5)
VERTEX (-.5,.5,.5) VERTEX (.5,.5,.5)
VERTEX (-.5,.5,-.5) VERTEX (.5,.5,-.5)
MATERIAL ('red') TEXLEN (1)
POLYGON 'up' ( VERTICES (4,5,7,6) )
POLYGON 'down' ( VERTICES (2,3,1,0) )
POLYGON 'front' ( VERTICES (6,7,3,2) )
POLYGON 'back' ( VERTICES (5,4,0,1) )
POLYGON 'left' ( VERTICES (4,6,2,0) )
POLYGON 'right' ( VERTICES (7,5,1,3) )
)
HARDMOVE (V (0.9,0,-3)); posició on estarà el cub
MESHOBJ 'tableP1' ( Definició d’una malla que serà copia de la que hem
definit previament.
PLUGIN ('thing')
PARAMS (FACTORY ('tableP'))
HARDMOVE (V (-2.4,-1,2.9))
)
110

Annex 5: Classes funcions principals
Annexes
Cal dir que les especificacions de les funcions, amb les seves explicacions, estàn
pensades per complimentar-se amb els comentaris adjunts amb el codi font del
programa.
Segons hem vist en la memòria en la part d’implementació la relació entre classes és la
següent:
Per tal de implementar les llistes de patchs, voxels i polígons hem utilitzat les STL per
tal de no haver d’implementar-les nosaltres, a més les STL son unes llibreries molt
eficients i estables.
Per tant a continuació anem a explicar cada una de les classes.
Classe raig
Ens representa un raig en 3D. Aquesta classe utilitza les classes csIntersect3D i
csPolygon3D per tal de comprovar i calcules les interseccion.
La definició de la classe és la següent:
111

class Ray
{
public:
};
Ray();
~Ray();
void Print();
Annexes
csVector3 start, end, dir; //the start/end and direction of the ray
Patch *patch; //origin patch
long int voxel_origin; //ray's origin voxel
float distance2point; //distance from origin to intersect point
bool IntersectRay (csPolygon3D *, csVector3 &point, float &dist);
//return true if the ray intersect with the plane
bool IntersectRayPlane (csPlane3, csVector3 &point, float &dist);
//return true if the ray will intersect the polygon
bool IntersectPolygon3D (csPolygon3D *);
Les funcions més importants de la classe son:
Bool IntersectRay (csPolygon3D *, csVector3 &point, float &dist);
La seva tasca consisteix en passat un polígon determinar si hi ha intersecció entre el raig
i el polígon, si és el cas retornar true i en els paràmetres point i dist retornar el punt
d’intersecció i la distància d’intersecció.
Classe Patch
Representa una petita part d'un polígon, per simplificar hem considerat que un Patch
correspont a un Lumel (element del Lightmap d'un polígon).
class Patch
{
public:
Patch();
~Patch();
unsigned int GetId() const { return id; }
//set the id lumel relative to polygon's lightmap
void SetIdLumel(unsigned int i);
//return the id lumel of patch relative to polygon's lightmap
unsigned int GetIdLumel () const { return idlumel;}
//return the specified vector (one patch have 2 vertors)
//set/get the coords of the lumel in x and y
112

void SetCoord (unsigned int xx,unsigned int yy);
void GetCoord (unsigned int &xx, unsigned int &yy);
void SetObsPoly (ObsPoly *poly);
ObsPoly * GetObsPoly() { return obspoly; }
csVector3 *GetVertex (int ); //return the vertex i of patch
void Print(); //print
Annexes
Ray *McrGenerateLocalLine(double *xi); //generate a random ray
};
Les funcions més importants son:
Ray *McrGenerateLocalLine(double *xi);
Retornar un raig aleatori generat en el patch que crida la funció.
unsigned int GetIdLumel () const { return idlumel;}
retornar el identificador del lumel dins el lightmap del polígon al que pertany el match.
Classe PatchList
Llista dinàmica on guardarem els Patchs. Té les funcions per recórrer la llista de patchs.
class PatchList
{
public:
PatchList();
PatchList(unsigned int);
~PatchList();
};
//return the pointer to the list of patches
std::vector * GetList() { return &list;}
//return the path(i)
Patch * GetPatch (int);
bool InsertPatch (Patch *);
int GetSize() { return list.size(); }
Patch *GetNext(); //return the next patch in the list
Classe ObsPoly
113

Annexes
Ens representa un polígon 3D de la escena, aquesta classe conté un objecte del tipus
csPolygon3D i csLightmap (per modificar el Lightmap amb les Obscurances) i la llista
de patchs del polígon PatchList.
class ObsPoly
{
public:
ObsPoly();
ObsPoly(csPolygon3D *poly);
~ObsPoly();
ObsPoly(const ObsPoly&);
unsigned int GetId() const { return id; }
//return the id
csPolygon3D * GetPolygon3D () const { return polygon; }
//return the original polygon in engine
csVector3 GetLumelOrigin() { return lumel_origin; }
csVector3 GetLumelX() { return lumel_x_axis; }
csVector3 GetLumelY() { return lumel_y_axis; }
PatchList * GetPatchList() { return &patchlist; }
//return the patchlist
std::bit_vector * GetTreaty() { return &treaty; }
//return the treaty list
std::vector *GetRayList(): //return the ray list
unsigned int GetRays (unsigned int i) const;
bool SetRays(unsigned int lumel, unsigned int rays);
bool GetTreaty (unsigned int i ) const; //get if the patch(i)
//is treaty
bool SetTreaty (unsigned int i, bool s = true); //set the patch
//(i) treaty
int GetSizePatchList(); //return the patch number
bool SaveLightMap(); //save the lightmap into copy_lightmap
bool RestoreObsLightMap(); //restore the original lightmap
(copy_lightmap into
//lightmap), and store the lightmap into
copy_lightmap
bool RestoreOriginLightMap();
void Setup(); //Calcule the lumel_origen, lumel_x_axis and
//lumel_y_axis from the obspoly and create all the
//patches
void ResetTreaty(); //reset/set the treaty vector
void SetTreaty();
void ResetRays(); //reset/set the raylist to 0 in all the patches
Patch * GetNextPatch(); //return pointer to next patch
void ResetIndex(); //reset the index (previus to GetNextPatch()
Patch * CalculateIntersectedPatch(csVector3 *); //return the
//patch intersected in csVector3
114

void Print();
Annexes
void CopyColor2Lumel(int lumel, const csColor & color); //set the
//lumel with the color
csColor GetObscuranceLumel (int lumel); //return the obscurance of
//the lumel/patch
};
void TestPatchs(const csColor &); //set all the patchs in polygon
//with one color, for testing
//purpose only
bool PointonPolygon(csVector3 *); //return true if vertex is in
//polygon
csColor GetFlatColor() ; // return the flat color value
Les funcions principals son:
void Setup();
Calcula on comença l’origen dels lumels I els increments respecte x i respecte y.
Patch * CalculateIntersectedPatch(csVector3 *);
Donat un punt d’intersecció dins el polígon retorna el patch interceptat .
void CopyColor2Lumel(int lumel, const csColor & color);
Donat un identificador del lumel/patch li assigna al Lightmap el color correspondent.
Classe ObsPolyList
Llista que contè objectes del tipus ObsPoly, ens servirà per emmagatzemar els polígons
de l'escena.
class ObsPolyList
{
public:
ObsPolyList();
ObsPolyList(unsigned int); //set the maximum capacity of the vector
~ObsPolyList();
//return the pointer to the list of obspoly
std::vector * GetList() { return &list; }
int GetSizeObsPolyList() const { return list.size(); }
//return the obspoly
ObsPoly * GetObsPoly (int);
115

insert te obspoly into the list
bool InsertObsPoly (ObsPoly *);
//return the next obspoly in the list
ObsPoly * GetNext();
};
Classe Voxel
Annexes
Classe que representa una divisió de l'espai en forma de cub, dins d'aquest objecte tenim
la llista de patchs que hi ha dins del voxel (ObsPatchList) i la llista de polígons que hi
ha dins el voxel (ObsPolyList).
class Voxel: public csObject,csBox3
{
public:
Voxel(csBox3 &box);
Voxel();
Voxel(const Voxel &);
~Voxel();
//the unique ID from CS
CS_ID GetID() const { return csid; }
//the real voxel's id from scene, for indexing purpose
unsigned long int GetIdVoxel() const { return idvoxel; }
//return the number of polygons in the voxel
int GetSizePolygonList() const { return list_id_obspoly.size(); }
//return pointer to list_id_obspoly;
std::vector * GetIdObsPolyList()
{ return &list_id_obspoly; }
//set the boundbox of the voxel
void SetBoundBox(csBox3 *);
void Print(); //print patch's data
Patch * GetNextPatch(); //return the pointer to next patch in the
//voxel
long int GetNextObsPoly(); //return the id to next obspoly in the
//voxel
bool AddPatch (Patch *); //add one patch (only the id) to
//list_id_patch
bool AddObsPoly (ObsPoly *); //add one obspoly (only the if ) to
//list_id_obspoly
int RaysGoTo (Ray *); //return the face that the ray trought to
};
Destaquem les següents funcions:
int RaysGoTo (Ray *);
116

Annexes
Donat un raig (del que sabem el voxel origen del raig) retorna la cara cap a la que va, els
valors possibles son:
#define VOXEL_FACE_LEFT 0
#define VOXEL_FACE_RIGHT 1
#define VOXEL_FACE_BEHIND 2
#define VOXEL_FACE_FRONT 3
#define VOXEL_FACE_UNDER 4
#define VOXEL_FACE_OVER 5
#define VOXEL_NO_FACE -1
Classe VoxeList
Llista de voxels de l'escena, contè cada uns dels voxels en que es subdivideix l'escena.
class VoxelList
{
public:
VoxelList();
VoxelList(csBox3 *);
std::vector * GetList() { return &list;} //return the pointer
//to the list of voxels
bool SetBoundBox (csBox3 *); //set the boundbox
csBox3 * GetBoundBox() { return &boundbox; } //return pointer
//to boundbox of scene
int GetSize() const { return list.size(); } //return the
//number of elements of list
Voxel * GetVoxel (unsigned int ); //return pointer to voxel(i)
void Print() ; //print stats
bool AddPatch2Voxel(Patch *); //add patch to voxels
//this function also add the obspoly to voxels
int CalculateVoxel(csVector3 *); //calculate the voxel that vertex
//go into, called by AddPatch2Voxel
int RaysGoTo(Ray *); //return the next voxel that rays go to
};
bool SetBoundBox (csBox3 *);
Assigna a l’estructura de voxels la caixa englobant passada per paràmetre, d’aquesta
manera dividirà l’espai en voxels.
int CalculateVoxel(csVector3 *);
117

Retorna el voxel on està un vèrtex determinat.
bool AddPatch2Voxel(Patch *);
Donat un patch l’afegueix al voxel corresponent a partir de la funció anterior.
int RaysGoTo(Ray *);
Retornar donat un raig el voxel cap el que va.
Classe Obscurance
Annexes
Aquesta és la classe principal de la jerarquia. Aquesta classe conté la llista de Voxels
(VoxelList) i la llista de polígons de l'escena (ObsPolyList) i s’encarrega de calcular les
Obscurances de l’escena, tant la inicial com la dels objectes en moviment (obscurances
en temps real).
class csObscurance
{
bool LoadScene(); //load the scene into the ObsPolyList, and set
//boundbox called by constructor csObscurance
bool PrepareVoxels(); //create all the voxels from scene
//called by DoObscurance
bool CalculateObscurances(); //calculate the obscurances
bool CalculateObs4Voxel( unsigned int i); //calculate the
//obscurances for one voxel
Patch * ShootRay (Ray *ray); //shoot one ray from one patch,
//return the patch intersected (null if no)
bool CalculateObs4Patch(Patch *); //calculate the obscurances for one
//patch
/// Does the whole obscurance thing. This is the one to call.
void DoObscurance();
void RecalculateObscuranceCube();
//calculate one frame of the "animation"
void Animate (csTicks elapsedTime);
Destaquem les següents funcions:
void LoadScene();
Carrega l’escena dins les estructures internes de les obscurances preparant tots els
polígons, lightmaps, patchs, etc.
118

ool CalculateObscurances();
Annexes
Funció principal que s’encarrega de calcular totes les Obscurances de cada uns dels
voxels i patchs de l’escena.
bool CalculateObs4Voxel( unsigned int i);
Calcula les Obscurances per un voxel determinat.
Patch * ShootRay (Ray *ray);
Retornar el patch interceptat per un raig, null si no intercepta cap.
bool CalculateObs4Patch(Patch *);
Calcula les Obscurances per un patch determinat.
void RecalculateObscuranceCube();
Modifica les llistes dels patchs i polígons dinàmics de l’escena a les noves posicions a
la que es mouen els objectes dinàmics i recalcula les obscurances.
void Animate (csTicks elapsedTime);
Aquesta funció és crida a cada quadre de “l’animació” i és la responsable de el recalcul
de les obscurances en temps real. Dins d’aquesta funció és calculen les noves posicions
dels objectes en moviment.
Classe ObsCube
Ens representa els cubs en moviment de l’escena, guarda les dades d’un objecte en
moviment, en el nostre cas els objectes en moviment tenen una ruta de moviment
determinat.
class csObsCube
{
//Pointer to the Path that the cube along to
csPath *Path;
csObsCube();
~csObsCube();
void InitPath();
void InitPath2();
};
void InitPath();
119

Inicialitza els paràmetres del moviment del cub 1 quan es mogui.
void InitPath2();
Inicialitza els paràmetres del moviment del cub 2 quan es mogui.
Classe csEngine
Annexes
És la classe mare del CS, sempre s’executa la primera, aquesta classe controla la creació
de les Obscurances, com veurem en el següent apartat.
Veure la documentació del Crystal Space.
Classe Walktest
Classe encarregada d’inicialitzar l’aplicació walktest, la seva funció està en controlar la
activació/desactivació de les Obscurances per l’usuari i a més de controlar que és
realitzi el càlcul de les Obscurances en temps real a cada quadre de l’animació.
Veure la documentació del Crystal Space.
120

Annex 5: Creció d’una aplicació en Crystal Space
Per crear una aplicació en CS s’han de tenir en compte una sèrie de coses:
La utilitat SCF (Shared class facility)
Annexes
Aquest sistema és el cor del framework que controla la memòria de Crystal Space.
L’hem d’inicialitzar abans que qualsevol altre subsistema declarant en l’aplicació:
csInitializer::InitializeSCF()
Contador de referències
És un sistema que controla les referències que es creen en CS d’un objecte. Quan un
objecte és vol destruir es crida a la funció DecRef() i si no hi ha cap punter que tingui la
seva referència, la memòria és alliberada.
Registre d’objectes
Aquest registre és el repositori central d’objectes d’aquest motor. Qualsevol element
dins CS l’utilitzarà per obtenir punters als objectes que l’interessin en tot moment. Per
tal de crear aquest registre s’ha de incloure en el codi la comanda
csInitializer::CreateObjectRegistry() o bé csInitializer::CreateEnviorement().
Gestor de Plugin
Aquest sistema s’encarrega de carregar o descarregar els plugins. Un plugin és una
llibreria compartida que es carrega dinàmicament en temps d’execució. En entorns Unix
tenen l’extensió “.so” mentre que en Windows tenen extensions “.dll”. Gairebé tot en
Crystal Space és un plugin. Aquest sistema es crea a partir de
csInitializer::CreatePluginManager() o bé csInitializer::CreateEnviorement().
Cua d’events
CS és un framework orientat a events, per el que aquest sistema s’encarrega de controlar
la cua de missatges i enviar cada missatge al receptor corresponent. Cada mòdul o
plugin pot implementar la interfície iEventHandler i d’aquesta manera pot registrar-se
en la cua d’events i així obtenir notificació de quan succeeix un determinat event. La
cua d’events es crea a partir de csInitializer::CreateEventQueue() o bé
csInitializer::CreateEnvironment().
Una aplicació que es desenvolupi en CS haurà de crear un subsistema que s’encarregi
de gestionar els events per tal de poder processar els events que sorgeixin, com poden
ser per exemple el renderitzat de la pantalla o bé guardar les pulsacions del teclat o
ratolí. Per tal de posar a punt el sistema que gestiona els events es crida a la funció
csInitializer::SetupEventHandler()
121

Commandline Parser
Annexes
És el responsable de comprovar les opcions que es passen per la línia de comandes. Si
s’han inicialitzat correctament els arguments “argc” i “argv” llavors es poden consultar
les opcions que hem passat per paràmetre. Molts plugins i mòduls de CS comproven els
paràmetres així que és important iniciar aquest sistema correctament. Per crear-lo farem
csInitializer::CreateCommandLineParser() o bé
csInitializer::CreateEnviorement().
Gestor de Configuracions
S’encarrega de llegir les opcions dels fitxers de configuració. Molts dels plugins i
mòduls del CS poden llegir les opcions que s’especifiquen en els fitxers de
configuració.
Per crear un gestor de configuració farem: csInitialitzer::CreateConfigManager() o
bé csInitializer::CreateEnviorement. Si volem especificar un gestor de configuració
ho farem amb csInitializer::SetupConfigManager()
Input Drivers
S’encarrega de controlar els dispositius d’entrada com el teclat, ratolí o joystick. Per tal
de crear aquest sistema es fa via csInitializer::CreateInputDrivers() o bé
csInitializer::CreateEnviorement(). Cada event que es generi per un controlador serà
encuat a la cua d’events per a que sigui atès.
Classe csInitializer
Aquesta classe ens ajuda a iniciar els diferents elements per a que les aplicacions
funcionin correctament.
Anem a veure un exemple de creació d’una petita aplicació utilitzant Crystal Space:
Fitxer: simple.h
#ifndef __SIMPLE_H__
#define __SIMPLE_H__
#include
struct iEngine;
struct iLoader;
struct iGraphics3D;
struct iKeyboardDriver;
struct iSector;
struct iView;
struct iVirtualClock;
struct iObjectRegistry;
struct iEvent;
class Simple
122

{
private:
iObjectRegistry* object_reg;
csRef engine;
csRef loader;
csRef g3d;
csRef kbd;
csRef vc;
float rotX, rotY;
public:
Simple (iObjectRegistry* object_reg);
~Simple ();
};
bool Initialize ();
void Start ();
static bool SimpleEventHandler (iEvent& ev);
bool HandleEvent (iEvent& ev);
#endif // __SIMPLE_H__
Annexes
Aquesta class anomenada “simple” conté una sèrie de referències a objectes importants.
Els mètodes a destacar son Initialize() que ens inicialitza tots els plugins necessaris per
l’aplicació i el mètode Start() que inicia el gestor d’events.
Fitxer: simple.cpp
#include "cssysdef.h" //necessari en tot els fitxers
#include "csutil/sysfunc.h"
#include "iutil/vfs.h"
#include "csutil/cscolor.h"
#include "cstool/csview.h"
#include "cstool/initapp.h"
#include "simple.h"
#include "iutil/eventq.h"
#include "iutil/event.h"
#include "iutil/objreg.h"
#include "iutil/csinput.h"
#include "iutil/virtclk.h"
#include "iengine/sector.h"
#include "iengine/engine.h"
#include "iengine/camera.h"
#include "iengine/light.h"
#include "iengine/texture.h"
#include "iengine/mesh.h"
#include "iengine/movable.h"
#include "iengine/material.h"
#include "imesh/thing.h"
#include "imesh/object.h"
#include "ivideo/graph3d.h"
#include "ivideo/graph2d.h"
#include "ivideo/texture.h"
#include "ivideo/material.h"
#include "ivideo/fontserv.h"
#include "igraphic/imageio.h"
#include "imap/parser.h"
123

#include "ivaria/reporter.h"
#include "ivaria/stdrep.h"
#include "csutil/cmdhelp.h"
#include "csutil/event.h"
CS_IMPLEMENT_APPLICATION
// The global pointer to simple
Simple* simple = 0;
Simple::Simple (iObjectRegistry* object_reg)
{
Simple::object_reg = object_reg;
}
Simple::~Simple ()
{
}
bool Simple::Initialize ()
{
//fem una petició dels plugins que volem carregar
if (!csInitializer::RequestPlugins (object_reg,
CS_REQUEST_VFS,
CS_REQUEST_OPENGL3D,
CS_REQUEST_ENGINE,
CS_REQUEST_FONTSERVER,
CS_REQUEST_IMAGELOADER,
CS_REQUEST_LEVELLOADER,
CS_REQUEST_REPORTER,
CS_REQUEST_REPORTERLISTENER,
CS_REQUEST_END))
{
csReport (object_reg, CS_REPORTER_SEVERITY_ERROR,
"crystalspace.application.simple",
"Can't initialize plugins!");
return false;
}
Annexes
// Check for commandline help.
//comprava si s’ha especificat per línia de comandes l’opció “—help”
if (csCommandLineHelper::CheckHelp (object_reg))
{
csCommandLineHelper::Help (object_reg);
return false;
}
// The virtual clock.
vc = CS_QUERY_REGISTRY (object_reg, iVirtualClock);
if (!vc)
{
csReport (object_reg, CS_REPORTER_SEVERITY_ERROR,
"crystalspace.application.simple",
"Can't find the virtual clock!");
return false;
}
// Find the pointer to engine plugin
engine = CS_QUERY_REGISTRY (object_reg, iEngine);
if (!engine)
124

{
}
csReport (object_reg, CS_REPORTER_SEVERITY_ERROR,
"crystalspace.application.simple",
"No iEngine plugin!");
return false;
loader = CS_QUERY_REGISTRY (object_reg, iLoader);
if (!loader)
{
csReport (object_reg, CS_REPORTER_SEVERITY_ERROR,
"crystalspace.application.simple",
"No iLoader plugin!");
return false;
}
g3d = CS_QUERY_REGISTRY (object_reg, iGraphics3D);
if (!g3d)
{
csReport (object_reg, CS_REPORTER_SEVERITY_ERROR,
"crystalspace.application.simple",
"No iGraphics3D plugin!");
return false;
}
kbd = CS_QUERY_REGISTRY (object_reg, iKeyboardDriver);
if (!kbd)
{
csReport (object_reg, CS_REPORTER_SEVERITY_ERROR,
"crystalspace.application.simple",
"No iKeyboardDriver plugin!");
return false;
}
//indiquem quina es la funció que tractarà els events
if (!csInitializer::SetupEventHandler(
object_reg, SimpleEventHandler))
{
csReport (object_reg, CS_REPORTER_SEVERITY_ERROR,
"crystalspace.application.simple",
"Can't initialize event handler!");
return false;
}
// Open the main system. This will open all the previously
// loaded plug-ins.
if (!csInitializer::OpenApplication (object_reg))
{
csReport (object_reg, CS_REPORTER_SEVERITY_ERROR,
"crystalspace.application.simple",
"Error opening system!");
return false;
}
csReport (object_reg, CS_REPORTER_SEVERITY_NOTIFY,
"crystalspace.application.simple",
"Simple Crystal Space Application version 0.1.");
return true;
Annexes
125

}
bool Simple::HandleEvent (iEvent& ev)
{
if (ev.Type == csevKeyboard &&
csKeyEventHelper::GetEventType (&ev) == csKeyEventTypeDown &&
csKeyEventHelper::GetCookedCode (&ev) == CSKEY_ESC)
{
csRef q (CS_QUERY_REGISTRY (object_reg,
iEventQueue));
if (q)
q->GetEventOutlet()->Broadcast (cscmdQuit);
return true;
}
return false;
}
//aquesta és la funció que tracta els events
bool Simple::SimpleEventHandler (iEvent& ev)
{
return simple ? simple->HandleEvent (ev) : false;
}
void Simple::Start ()
{
csDefaultRunLoop (object_reg);
}
/*---------------*
* Main function
*---------------*/
int main (int argc, char* argv[])
{
//creem el register d’objectes
iObjectRegistry* object_reg =
csInitializer::CreateEnvironment (argc, argv);
if (!object_reg) return -1;
}
//creem un objecte de la clase que hem creat
simple = new Simple (object_reg);
if (simple->Initialize ())
simple->Start ();
delete simple;
simple = 0;
csInitializer::DestroyApplication (object_reg);
return 0;
Annexes
Aquesta aplicació és la més sencilla que es pot crear amb el CS. El que fa l’aplicació és
el següent:
• Obre una finestra.
• Controla el tamany de la finestra a partir dels paràmetres d’entrada per la línia
de commandes (-mode).
126

Annexes
• Carrega els següents plugins: engine, 3D renderer, canvas, reporter, reporter
listener, font server, image loader, level loader, and VFS.
Podem observar en el codi la inclusió de la macro CS_IMPLEMENT_APPLICATION.
Aquesta és necessària per tal de comprovar que la funció main() està correctament
linkada i que és crida correctament en cada plataforma
La rutina principal (main), primer crida a csInitializer::CreateEnviornment() per tal
d’assegurar que el SCF, el registre d’objectes, la lectura de la línia de comandes i
multitud d’utilitats (gestor de plugins, cua d’events, ...) s’inicien correctament. A
continuació la rutina principal crea una instància de la classe “simple”. Aquesta
instància està emmagatzemada en una variable global per tal de facilitar l’accés. El
següent pas està en iniciar l’aplicació (mètode Initialization).
Cal remarcar que s’utilitza la funció csReport per tal d’enviar missatge al plugin de
notificació (d’error). Aquesta té un funcionament semblant a la funció printf()
exceptuant que s’han d’indicar el nivell de l’error i un identificador per tal de que sigui
fàcil detectar des d’on es produeix la notificació.
La funció csInitializer::RequestPlugin() utilitza un fitxer de configuració per tal de
saber quins son els plugins disponibles.
Per acabar és crida la funció csInitializer::OpenApplication() que s’encarrega d’enviar
l’event ‘cscmdSystemOpen’ a tots els objectes en la cua d’events. D’aquesta manera per
exemple el renderitzador 3D obrirà una finestra on és mostrarà l’escena. I l’últim pas
està en cridar Simple::Start() on no és finalitzarà fins que s’enviï un event de fi
d’aplicació.
127

BIBLIOGRAFIA
Bibliografia
La bibliografia ha estat citada segons la notació MLA (Modern Language Association
of America.: www.mla.org
REFERÈNCIES
[1] A.Iones, A. Krupkin, M. Sbert, S. Zhukov
Fast realistic lighting for video games
Article de recerca, 2003.
[2] Alex Méndez, Mateu Sbert, Jordi Catà
Real Time Obscurances
Graphics Group of Girona (GGG), Article de recerca, Abril 2003.
[3] Andrew Rollings and Ernest Adams
Andrew Rollings and Ernest Adams on Game Design
New Riders Publishing, maig 2003
[4] Bob Bates
Game Design: The art & business of creating games
Prima Tech’s Game Developement series, Abril 2001
[5] Chris Crawford
Chris Crawford on Game Design
New Riders Publishing, juny 2003
[6] Daniel Sánchez-Crespo Dalmau
Core Techniques and Algorithms in Game Programming
New Riders Publishing, Setembre 2003
[7] David H. Eberly
3D Game Engine Design, A practical aproach to Real-Time computer
Morgan Kaufmann Publishers ,2001
[8] Donato Piccinno
E-Opportunity in the Computer Game Industry
MBA 2002 Dissertation
[9] Isma Garcia, Francisco Gonzalez
Comparativa Técnica: PS2, GameCube, Xbox
Graphics Group of Girona (GGG), Report intern, 2003.
[10] Jordi Catà Castillo, Alex Méndez, Mateu Sbert
Implementació del mètode de les obscurances en temps real
Graphics Group of Girona (GGG), Article de recerca, Abril 2003.
[11] Jordi Catà Castillo, Alex Méndez
128

Comparativa de motores gràficos para videojuegos
Graphics Group of Girona (GGG), report intern, Abril 2002.
Bibliografia
[12] Jordi Catà Castillo
Recorregut interactiu d’escenes arquitectòniques.
Projecte Fi de Carrera, Enginyeria Tècnica en Informàtica de Gestió,
Escola Politècnica Superior, Universitat de Girona, abril 2002.
[13] Jorrit Tyberghein
The portal technique for Real-time 3D Engines
[14] Margarita García i Teixidor
Implementació i millora del mètode d’il·luminació global mitjançant
obscurances.
Projecte Fi de Carrera, Enginyeria Tècnica en Informàtica de sistemes,
Escola Politècnica Superior, Universitat de Girona, juliol 2001.
[15] Tomas Möller, Eric Haines
Real Time rendering
A. K. Peters, Natick, Massachusetts, 1999
[16] Rudy Rucker
Software Engineering and Computer Games
Addison Wesley, Desembre 2002
[17] John R. Hall
Programming Linux Games
Loki software, Inc, 2001
[18] Roger S. Pressman
Ingenieria del Software, un enfoque pràctico, quarta edició
McGraw-hill, 1999
[19] Steve McConnell
Rapid Development
Microsoft press, 1996
[20] Steve McConnell
Software Project survival guide
Microsoft press, 1998
[21] Steve McConnell
Professional software development
Addison Wesley, 2003
[22] Tomasz Zaniewski
Using Texture Mapping Techniques to Simulate Lights and Shadows in
Real Time Computer Graphics
Tesis Doctoral, Rhodes University, 2000
129

WEB
• Motors gràfics i llibreries:
[WEB1] http://www.3dengines.net/
[WEB2] http://crystal.sourceforge.net
[WEB3] http://www.ogre3d.org/
[WEB4] http://openscenegraph.sourceforge.net
[WEB5] http://www.nebuladevice.org/
[WEB6] http://irrlicht.sourceforge.net/
[WEB7] http://www.hawksoft.com/hawknl/
[WEB8] http://www.rakkarsoft.com/
[WEB9] http://www.libsdl.org/
[WEB10] http://www.clanlib.org/
[WEB11] http://www.openal.org/
[WEB12] http://cal3d.sourceforge.net/
[WEB13] http://openil.sourceforge.net/
• Pàgines sobre gràfics per computador i videojocs:
http://realtimerendering.com
www.gamasutra.com
www.flipcode.com
http://www.gamespp.com
http://www.programmersheaven.com
http://www.masda.vxu.se/~npamasda/GameLinkCollection.htm
http://www.game-culture.com/newssites.html
http://www.mcvuk.com
Bibliografia
130

AGRAÏMENTS
Agraïments
Voldria agrair i dedicar el projecte a un conjunt de persones que m’han ajudat d’una
manera o una altra a la realització d’aquest projecte que és l’últim pas per assolir la
titulació d’Enginyer Informàtic. Entre aquestes persones vull destacar:
• Mònica Izquierdo. La meva dona, per donar-me un suport moral, de comprensió,
revisió i resums durant el desenvolupament.
• Josep Catà. El meu germà per donar-me un altre punt de vista sobre temes
d’implementació i presionar-me per que entregues el projecte a temps.
• Concepció Castillo i Pere Catà. Els meus pares, sense ells no estaria en aquest
mon i no hagués arribat fins aquí. I a més, per ensenyar-me el sentit de la vida i
a lluitar per el que és vol.
• Mateu Sbert. Per permetrem presentar com a projecte part de la meva feina en el
Grup de Gràfics de la Universitat de Girona i sofrir les meves absències.
131