desarrollo videojuegos 2 programacion grafica

ABCADEFFCEFCA

CFCAECCAABCA

D

C!C"F!C#C$EFB%FEABABCADEF&FCEFCA&

CFCAE&CCAABCA&D

CDEF '()*)+*,),*-./)*.0!CABCBDBEFBFFA1CDEF'()*)+*,),*-./,*,FDBDF 230AB1F"F0FDFB1 F!"C#4CB!CA5ABCADEFBA ABCADEF

6CF%CECE7C8F!CF!CABCADEF5CFE9D!5!5C!F%C!FC:!E;D&2C!C&;3EC5

A ABACD A EDCFBBACB A B C DFDBABACDD!DCBA"DDE#CAACAA$C%CBD &'() *! BACAA $CBB$A D+,-B!. CAA D BAD !AD / CAB!FA)

BCDE FADA 0 (DDC %!CD$AD AEDCFB BACB A B A1CDEADC2B!CABACBABF$CADABA%!AA EDCFBAB!&A AB!C CABD D EDCFB +CEB*3AB A FA &AB / *BAF 4$ACBDAA ) 5!FAA ! BB BABDCBC A DCD D *BAF !B5AA A&AACB(BCB!BD/&AB5!FA)

CDEC6(DDC%!CD$ADAEDCFBBACB A B A 1CDEADC5/!A(DDCABF$CADABA%!AAABAC3BACA !CB A5F7 %5AB!CAEDCFB4EBFB5$BABAC3 / *BAF A DF!BB8 A %BEBBDAA 0) 5!FAA ! BB BABDCBCADCD9BBBABAA&D8B8B/5$CAB: A5!DFBD)

A ABACD A EDCFB $DC /ACA(BA"D/(ACCDDABAD !AD$DC)%$ABB:DAACCDD;(D

Prefacio

Este libro forma parte de una coleccin de cuatro volmenes dedi-cados al Desarrollo de Videojuegos. Con un perfil principalmente tcni-co, estos cuatro libros cubren los aspectos esenciales en programacinde videojuegos:

1. Arquitectura del Motor. En este primer libro se estudian losaspectos esenciales del diseo de un motor de videojuegos, ascomo las tcnicas bsicas de programacin y patrones de diseo.

2. Programacin Grfica. El segundo libro de la coleccin se centraen los algoritmos y tcnicas de representacin grfica y optimiza-ciones en sistemas de despliegue interactivo.

3. Tcnicas Avanzadas. En este tercer volumen se recogen ciertosaspectos avanzados, como estructuras de datos especficas, tc-nicas de validacin y pruebas o simulacin fsica.

4. Desarrollo de Componentes. El ltimo libro est dedicado aciertos componentes especficos del motor, como la InteligenciaArtificial, Networking, Sonido y Multimedia o tcnicas avanzadasde Interaccin.

Sobre este libro...

Este libro que tienes en tus manos es una ampliacin y revisinde los apuntes del Curso de Experto en Desarrollo de Videojuegos, im-partido en la Escuela Superior de Informtica de Ciudad Real de laUniversidad de Castilla-La Mancha. Puedes obtener ms informacinsobre el curso, as como los resultados de los trabajos creados por losalumnos en la web del mismo: http://www.esi.uclm.es/videojuegos.

La versin electrnica de este manual (y del resto de libros de lacoleccin) puede descargarse desde la web anterior. El libro fsicopuede adquirirse desde la pgina web de la editorial online Bubok enhttp://www.bubok.es.

Requisitos previos

Este libro tiene un pblico objetivo con un perfil principalmentetcnico. Al igual que el curso del que surgi, est orientado a la capac-itacin de profesionales de la programacin de videojuegos. De estaforma, este libro no est orientado para un pblico de perfil artstico(modeladores, animadores, msicos, etc) en el mbito de los videojue-gos.

Se asume que el lector es capaz de desarrollar programas de nivelmedio en C y C++. Aunque se describen algunos aspectos clave de C++a modo de resumen, es recomendable refrescar los conceptos bsicoscon alguno de los libros recogidos en la bibliografa del curso. De igualmodo, se asume que el lector tiene conocimientos de estructuras dedatos y algoritmia. El libro est orientado principalmente para titula-dos o estudiantes de ltimos cursos de Ingeniera en Informtica.

Programas y cdigo fuente

El cdigo de los ejemplos del libro pueden descargarse en la si-guiente pgina web: http://www.esi.uclm.es/videojuegos. Salvo quese especifique explcitamente otra licencia, todos los ejemplos del librose distribuyen bajo GPLv3.

Agradecimientos

Los autores del libro quieren agradecer en primer lugar a los alum-nos de la primera edicin del Curso de Experto en Desarrollo de Video-juegos por su participacin en el mismo y el excelente ambiente en lasclases, las cuestiones planteadas y la pasin demostrada en el desa-rrollo de todos los trabajos.

De igual modo, se quiere reflejar el agradecimiento especial al per-sonal de administracin y servicios de la Escuela Superior de Infor-mtica, por su soporte, predisposicin y ayuda en todos los capri-chosos requisitos que plantebamos a lo largo del curso.

Por otra parte, este agradecimiento tambin se hace extensivo ala Escuela de Informatica de Ciudad Real y al Departamento de Tec-nologas y Sistema de Informacin de la Universidad de Castilla-LaMancha.

Finalmente, los autores desean agradecer su participacin a loscolaboradores de esta primera edicin: Indra Software Labs, la aso-ciacin de desarrolladores de videojuegos Stratos y a Libro Virtual.

Resumen

El objetivo de este mdulo titulado Programacin Grfica del Cur-so de Experto en Desarrollo de Videojuegos es cubrir los aspectos esen-ciales relativos al desarrollo de un motor grfico interactivo.

En este contexto, el presente mdulo cubre aspectos esenciales ybsicos relativos a los fundamentos del desarrollo de la parte grfica,como por ejemplo el pipeline grfico, como elemento fundamental de laarquitectura de un motor de juegos, las bases matemticas, las APIs deprogramacin grfica, el uso de materiales y texturas, la iluminacino los sistemas de partculas.

As mismo, el presente mdulo tambin discute aspectos relativosa la exportacin e importacin de datos, haciendo especial hincapi enlos formatos existentes para tratar con informacin multimedia.

Finalmente, se pone de manifiesto la importancia de elementos co-mo los shaders, con el objetivo de dotar de ms realismo grfico a losvideojuegos, y la necesidad de llevar a cabo optimizaciones tanto enescenarios interiores como exteriores.

I

ndice general

1. Fundamentos de Grficos Tridimensionales 1

1.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. El Pipeline Grfico . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1. Etapa de Aplicacin . . . . . . . . . . . . . . . . . . 5

1.2.2. Etapa de Geometra . . . . . . . . . . . . . . . . . . 5

1.2.3. Etapa Rasterizacin . . . . . . . . . . . . . . . . . . 8

1.2.4. Proyeccin en Perspectiva . . . . . . . . . . . . . . . 9

1.3. Implementacin del Pipeline en GPU . . . . . . . . . . . . 10

1.3.1. Vertex Shader . . . . . . . . . . . . . . . . . . . . . . 12

1.3.2. Geometry Shader . . . . . . . . . . . . . . . . . . . . 12

1.3.3. Pixel Shader . . . . . . . . . . . . . . . . . . . . . . . 12

1.4. Arquitectura del motor grfico . . . . . . . . . . . . . . . . 13

1.5. Casos de Estudio . . . . . . . . . . . . . . . . . . . . . . . . 14

1.6. Introduccin a OGRE . . . . . . . . . . . . . . . . . . . . . 15

1.6.1. Arquitectura General . . . . . . . . . . . . . . . . . 18

1.6.2. Instalacin . . . . . . . . . . . . . . . . . . . . . . . 23

1.7. Hola Mundo en OGRE . . . . . . . . . . . . . . . . . . . . . 24

2. Matemticas para Videojuegos 29

2.1. Puntos, Vectores y Coordenadas . . . . . . . . . . . . . . . 29

2.1.1. Puntos . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.1.2. Vectores . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2. Transformaciones Geomtricas . . . . . . . . . . . . . . . 34

III

2.2.1. Representacin Matricial . . . . . . . . . . . . . . . 35

2.2.2. Transformaciones Inversas . . . . . . . . . . . . . . 37

2.2.3. Composicin . . . . . . . . . . . . . . . . . . . . . . 38

2.3. Perspectiva: Representacin Matricial . . . . . . . . . . . 39

2.4. Cuaternios . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4.1. Suma y Multiplicacin . . . . . . . . . . . . . . . . . 43

2.4.2. Inversa . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.4.3. Rotacin empleando Cuaternios . . . . . . . . . . . 44

2.5. Interpolacin Lineal y Esfrica . . . . . . . . . . . . . . . . 44

2.6. El Mdulo Math en OGRE . . . . . . . . . . . . . . . . . . 45

3. Grafos de Escena 49

3.1. Justificacin . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1.1. Operaciones a Nivel de Nodo . . . . . . . . . . . . . 50

3.2. El Gestor de Escenas de OGRE . . . . . . . . . . . . . . . 52

3.2.1. Creacin de Objetos . . . . . . . . . . . . . . . . . . 52

3.2.2. Transformaciones 3D . . . . . . . . . . . . . . . . . 54

3.2.3. Espacios de transformacin . . . . . . . . . . . . . 56

4. Recursos Grficos y Sistema de Archivos 59

4.1. Formatos de Especificacin . . . . . . . . . . . . . . . . . . 59

4.1.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . 59

4.1.2. Recursos de grficos 3D: formatos y requerimien-tos de almacenamiento . . . . . . . . . . . . . . . . 60

4.1.3. Casos de Estudio . . . . . . . . . . . . . . . . . . . . 66

4.2. Exportacin y Adaptacin de Contenidos . . . . . . . . . . 79

4.2.1. Instalacin del exportador de Ogre en Blender . . . 81

4.2.2. Creacin de un modelo en Blender . . . . . . . . . 81

4.2.3. Aplicacin de texturas mediante UV Mapping . . . 81

4.2.4. Exportacin del objeto en formato Ogre XML . . . 85

4.2.5. Carga del objeto en una aplicacin Ogre . . . . . . 87

4.3. Procesamiento de Recursos Grficos . . . . . . . . . . . . 89

4.3.1. Ejemplo de uso . . . . . . . . . . . . . . . . . . . . . 92

4.4. Gestin de Recursos y Escena . . . . . . . . . . . . . . . . 94

4.4.1. Recursos empaquetados . . . . . . . . . . . . . . . 95

4.4.2. Gestin del ratn . . . . . . . . . . . . . . . . . . . . 96

4.4.3. Geometra Esttica . . . . . . . . . . . . . . . . . . . 97

4.4.4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.4.5. Mscaras . . . . . . . . . . . . . . . . . . . . . . . . 101

5. APIS de Grficos 3D 103

5.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.2. Modelo Conceptual . . . . . . . . . . . . . . . . . . . . . . 105

5.2.1. Cambio de Estado . . . . . . . . . . . . . . . . . . . 105

5.2.2. Dibujar Primitivas . . . . . . . . . . . . . . . . . . . 106

5.3. Pipeline de OpenGL . . . . . . . . . . . . . . . . . . . . . . 107

5.3.1. Transformacin de Visualizacin . . . . . . . . . . 107

5.3.2. Transformacin de Modelado . . . . . . . . . . . . . 108

5.3.3. Transformacin de Proyeccin . . . . . . . . . . . . 109

5.3.4. Matrices . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.3.5. Dos ejemplos de transformaciones jerrquicas . . 111

5.4. Ejercicios Propuestos . . . . . . . . . . . . . . . . . . . . . 114

6. Gestin Manual OGRE 3D 115

6.1. Inicializacin Manual . . . . . . . . . . . . . . . . . . . . . 115

6.1.1. Inicializacin . . . . . . . . . . . . . . . . . . . . . . 116

6.1.2. Carga de Recursos . . . . . . . . . . . . . . . . . . . 119

6.1.3. FrameListener . . . . . . . . . . . . . . . . . . . . . 119

6.2. Uso de OIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

6.2.1. Uso de Teclado y Ratn . . . . . . . . . . . . . . . . 122

6.3. Creacin manual de Entidades . . . . . . . . . . . . . . . 125

6.4. Uso de Overlays . . . . . . . . . . . . . . . . . . . . . . . . 126

7. Materiales y Texturas 131

7.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.2. Modelos de Sombreado . . . . . . . . . . . . . . . . . . . . 133

7.3. Mapeado de Texturas . . . . . . . . . . . . . . . . . . . . . 134

7.4. Materiales en Ogre . . . . . . . . . . . . . . . . . . . . . . . 136

7.4.1. Composicin . . . . . . . . . . . . . . . . . . . . . . 137

7.4.2. Ejemplo de Materiales . . . . . . . . . . . . . . . . . 137

7.5. Mapeado UV en Blender . . . . . . . . . . . . . . . . . . . 140

7.5.1. Costuras . . . . . . . . . . . . . . . . . . . . . . . . . 144

7.6. Ejemplos de Materiales en Ogre . . . . . . . . . . . . . . . 145

7.7. Render a Textura . . . . . . . . . . . . . . . . . . . . . . . . 148

7.7.1. Texture Listener . . . . . . . . . . . . . . . . . . . . 151

7.7.2. Espejo (Mirror) . . . . . . . . . . . . . . . . . . . . . 152

8. Partculas y Billboards 155

8.1. Fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . 155

8.1.1. Billboards . . . . . . . . . . . . . . . . . . . . . . . . 155

8.1.2. Sistemas de partculas . . . . . . . . . . . . . . . . 159

8.2. Uso de Billboards . . . . . . . . . . . . . . . . . . . . . . . 160

8.2.1. Tipos de Billboard . . . . . . . . . . . . . . . . . . . 162

8.2.2. Aplicando texturas . . . . . . . . . . . . . . . . . . . 163

8.3. Uso de Sistemas de Partculas . . . . . . . . . . . . . . . . 164

8.3.1. Emisores . . . . . . . . . . . . . . . . . . . . . . . . 165

8.3.2. Efectores . . . . . . . . . . . . . . . . . . . . . . . . 165

8.3.3. Ejemplos de Sistemas de Partculas . . . . . . . . . 166

9. Iluminacin 169

9.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 169

9.2. Tipos de Fuentes de Luz . . . . . . . . . . . . . . . . . . . 170

9.3. Sombras Estticas Vs Dinmicas . . . . . . . . . . . . . . 171

9.3.1. Sombras basadas en Stencil Buffer . . . . . . . . . 172

9.3.2. Sombras basadas en Texturas . . . . . . . . . . . . 174

9.4. Ejemplo de uso . . . . . . . . . . . . . . . . . . . . . . . . . 176

9.5. Mapas de Iluminacin . . . . . . . . . . . . . . . . . . . . . 178

9.6. Ambient Occlusion . . . . . . . . . . . . . . . . . . . . . . . 180

9.7. Radiosidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

10.Animacin 187

10.1.Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 187

10.1.1.Animacin Bsica . . . . . . . . . . . . . . . . . . . 188

10.1.2.Animacin de Alto Nivel . . . . . . . . . . . . . . . . 189

10.2.Animacin en Ogre . . . . . . . . . . . . . . . . . . . . . . 191

10.2.1.Animacin Keyframe . . . . . . . . . . . . . . . . . . 191

10.2.2.Controladores . . . . . . . . . . . . . . . . . . . . . . 192

10.3.Exportacin desde Blender . . . . . . . . . . . . . . . . . . 192

10.4.Mezclado de animaciones . . . . . . . . . . . . . . . . . . . 197

11.Exportacin y Uso de Datos de Intercambio 203

11.1.Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 203

12.Shaders 211

12.1.Un poco de historia . . . . . . . . . . . . . . . . . . . . . . 211

12.1.1.Y qu es un Shader? . . . . . . . . . . . . . . . . . 213

12.2.Pipelines Grficos . . . . . . . . . . . . . . . . . . . . . . . 214

12.2.1.Por qu un pipeline grfico? . . . . . . . . . . . . . 214

12.2.2.Fixed-Function Pipeline . . . . . . . . . . . . . . . . 215

12.2.3.Programmable-Function Pipeline . . . . . . . . . . 218

12.3.Tipos de Shader . . . . . . . . . . . . . . . . . . . . . . . . 218

12.4.Aplicaciones de los Shader . . . . . . . . . . . . . . . . . . 221

12.4.1.Vertex Skinning . . . . . . . . . . . . . . . . . . . . 221

12.4.2.Vertex Displacement Mapping . . . . . . . . . . . . 221

12.4.3.Screen Effects . . . . . . . . . . . . . . . . . . . . . 221

12.4.4.Light and Surface Models . . . . . . . . . . . . . . . 222

12.4.5.Non-Photorealistic Rendering . . . . . . . . . . . . . 222

12.5.Lenguajes de Shader . . . . . . . . . . . . . . . . . . . . . 223

12.6.Desarrollo de shaders en Ogre . . . . . . . . . . . . . . . . 224

12.6.1.Poniendo a punto el entorno . . . . . . . . . . . . . 224

12.6.2.Primer Shader . . . . . . . . . . . . . . . . . . . . . 225

12.6.3.Comprobando la interpolacin del color . . . . . . 229

12.6.4.Usando una textura . . . . . . . . . . . . . . . . . . 231

12.6.5.Jugando con la textura . . . . . . . . . . . . . . . . 233

12.6.6.Jugando con los vrtices . . . . . . . . . . . . . . . 236

12.6.7.Iluminacin mediante shaders . . . . . . . . . . . . 239

13.Optimizacin de interiores 241

13.1.Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 241

13.2.Tcnicas y Algoritmos . . . . . . . . . . . . . . . . . . . . . 242

13.2.1.Algoritmos basados en Oclusores . . . . . . . . . . 242

13.2.2.Algoritmo BSP . . . . . . . . . . . . . . . . . . . . . 243

13.2.3.Portal Rendering . . . . . . . . . . . . . . . . . . . . 250

13.2.4.Mapas de Oclusin Jerrquicos (HOM) . . . . . . . 252

13.2.5.Enfoques hbridos . . . . . . . . . . . . . . . . . . . 254

13.2.6.Tests asistidos por hardware . . . . . . . . . . . . . 255

13.3.Manejo de escenas en OGRE . . . . . . . . . . . . . . . . . 256

13.3.1.Interiores en OGRE . . . . . . . . . . . . . . . . . . 257

14.Optimizacin de exteriores 259

14.1.Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . 259

14.2.Estructuras de datos . . . . . . . . . . . . . . . . . . . . . 260

14.3.Determinacin de la resolucin . . . . . . . . . . . . . . . 262

14.3.1.Polticas Discretas de LOD . . . . . . . . . . . . . . 262

14.3.2.Polticas Continuas de LOD . . . . . . . . . . . . . . 263

14.4.Tcnicas y Algoritmos . . . . . . . . . . . . . . . . . . . . . 263

14.4.1.GeoMipmapping . . . . . . . . . . . . . . . . . . . . 264

14.4.2.ROAM . . . . . . . . . . . . . . . . . . . . . . . . . . 266

14.4.3.Chunked LODs . . . . . . . . . . . . . . . . . . . . . 268

14.4.4.Terrenos y GPU . . . . . . . . . . . . . . . . . . . . . 269

14.4.5.Scenegraphs de Exteriores . . . . . . . . . . . . . . 269

14.5.Exteriores y LOD en OGRE . . . . . . . . . . . . . . . . . . 270

14.5.1.Terrenos . . . . . . . . . . . . . . . . . . . . . . . . . 270

14.5.2.Skyboxes, skydomes y skyplanes . . . . . . . . . . 274

14.5.3.LOD : Materiales y Modelos . . . . . . . . . . . . . . 277

14.6.Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Captulo1Fundamentos de Grficos

Tridimensionales

Carlos Gonzlez Morcillo

U no de los aspectos que ms llaman la atencin en los videojue-gos actuales son sus impactantes grficos 3D. En este primercaptulo introduciremos los conceptos bsicos asociados al pi-peline en grficos 3D. Se estudiarn las diferentes etapas de trans-formacin de la geometra hasta su despliegue final en coordenadasde pantalla. En la segunda parte del captulo estudiaremos algunasde las capacidades bsicas del motor grfico de videojuegos y veremoslos primeros ejemplos bsicos de uso de Ogre.

1.1. Introduccin

An ms rpido!!

Si cada frame tarda en des-plegarse ms de 40ms, noconseguiremos el mnimo de25 fps (frames per second) es-tablecido como estndar encine. En videojuegos, la fre-cuencia recomendable mni-ma es de unos 50 fps.

Desde el punto de vista del usuario, un videojuego puede definirsecomo una aplicacin software que responde a una serie de eventos,redibujando la escena y generando una serie de respuestas adicionales(sonido en los altavoces, vibraciones en dispositivos de control, etc...).

El redibujado de esta escena debe realizarse lo ms rpidamenteposible. La capa de aplicacin en el despliegue grfico es una de lasactividades que ms ciclos de CPU consumen (incluso, como veremosen la seccin 1.3, con el apoyo de las modernas GPUs Graphics Pro-cessing Unit existentes en el mercado).

Habitualmente el motor grfico trabaja con geometra descrita me-diante mallas triangulares. Las tcnicas empleadas para optimizar eldespliegue de esta geometra, junto con las propiedades de materia-

1

[2] CAPTULO 1. FUNDAMENTOS DE GRFICOS TRIDIMENSIONALES

les, texturas e iluminacin, varan dependiendo del tipo de videojuegoque se est desarrollando. Por ejemplo, en un simulador de vuelo, eltratamiento que debe darse de la geometra distante (respecto de laposicin de la cmara virtual) debe ser diferente que la empleada paraoptimizar la visualizacin de interiores en un videojuego de primerapersona.

Uno de los errores habituales en videojuegos amateur es la fal-ta de comunicacin clara entre programadores y diseadores.El desarrollador debe especificar claramente las capacidadessoportadas por el motor grfico al equipo de modeladores, ani-madores y equipo artstico en general. Esta informacin debecomprender tanto las tcnicas de despliegue soportadas, comoel nmero de polgonos disponibles para el personaje principal,enemigos, fondos, etc...

A un alto nivel de abstraccin podemos ver el proceso de rendercomo el encargado de convertir la descripcin de una escena tridimen-sional en una imagen bidimensional. En los primeros aos de estudiode esta disciplina, la investigacin se centr en cmo resolver proble-mas relacionados con la deteccin de superficies visibles, sombreadobsico, etc. Segn se encontraban soluciones a estos problemas, secontinu el estudio de algoritmos ms precisos que simularan el com-portamiento de la luz de una forma ms precisa.

Figura 1.1: Descripcin ge-neral del proceso de rende-ring.

En esencia, el proceso de rendering de una escena 3D requiere lossiguientes elementos:

Superficies. La geometra de los objetos que forman la escenadebe ser definida empleando alguna representacin matemtica,para su posterior procesamiento por parte del ordenador.

Cmara. La situacin del visor debe ser definida mediante unpar (posicin, rotacin) en el espacio 3D. El plano de imagen deesta cmara virtual definir el resultado del proceso de rende-ring. Como se muestra en la Figura 1.1, para imgenes generadasen perspectiva, el volumen de visualizacin define una pirmidetruncada que selecciona los objetos que sern representados enla escena. Esta pirmide se denomina Frustum.

Tiempo de cmputo

En sntesis de imagen realis-ta (como por ejemplo, las tc-nicas de rendering emplea-das en pelculas de anima-cin) el clculo de un so-lo fotograma de la animacinpuede requerir desde variashoras hasta das, empleandocomputadores de altas pres-taciones.

Fuentes de luz. Las fuentes de luz emiten rayos que interactancon las superficies e impactarn en el plano de imagen. Depen-diendo del modo de simulacin de estos impactos de luz (de laresolucin de la denominada ecuacin de render), tendremos di-ferentes mtodos de rendering.

Propiedades de las superficies. En este apartado se incluyen laspropiedades de materiales y texturas que describen el modelo derebote de los fotones sobre las superficies.

Uno de los principales objetivos en sntesis de imagen es el rea-lismo. En general, segn el mtodo empleado para la resolucin de la

1.1. Introduccin [3]

AB

AB

ABC

DAEABCDCEFCEC

AB

CDEFEDB

FDEF

FDEF

Figura 1.2: Diferencias entre las tcnicas de despliegue interactivas (mtodos basados en ScanLine) y realistas (mtodosbasados en RayCasting). En el Pipeline Hardware, la seleccin del pxel ms cercano relativo a cada tringulo se realizadirectamente en Hardware, empleando informacin de los fragmentos (ver Seccin 1.2).

ecuacin de render tendremos diferentes niveles de realismo (y diferen-tes tiempos de cmputo asociados). El principal problema en grficosen tiempo real es que las imgenes deben ser generadas muy rpida-mente. Eso significa, como hemos visto anteriormente, que el motorgrfico dispone de menos de 40 ms para generar cada imagen. Habi-tualmente este tiempo es incluso menor, ya que es necesario reservartiempo de CPU para otras tareas como el clculo de la InteligenciaArtificial, simulacin fsica, sonido...

Los primeros mtodos de sombreado de superficies propuestos porGouraud y Phong no realizaban ninguna simulacin fsica de la refle-xin de la luz, calculando nicamente las contribuciones locales deiluminacin. Estos modelos tienen en cuenta la posicin de la luz, elobservador y el vector normal de la superficie. Pese a su falta de rea-lismo, la facilidad de su cmputo hace que estas aproximaciones sigansiendo ampliamente utilizadas en el desarrollo de videojuegos.

RayTracing

El algoritmo original del Ray-Casting de Appel, fue el pre-cursor del mtodo de RayTra-cing (Trazado de Rayos) deWhitted de 1980. El mtodode RayTracing sirvi de ba-se para los principales mto-dos de sntesis de imagen hi-perrealistas que se empleanen la actualidad (Metrpolis,Path Tracing, etc...).

En 1968 Arthur Appel describi el primer mtodo para generar im-genes por computador lanzando rayos desde el punto de vista del ob-servador. En este trabajo, generaba la imagen resultado en un plotterdonde dibujaba punto a punto el resultado del proceso de render. Laidea general del mtodo de RayCasting es lanzar rayos desde el planode imagen, uno por cada pxel, y encontrar el punto de interseccinms cercano con los objetos de la escena. La principal ventaja de estemtodo frente a los mtodos de tipo scanline que emplean zbuffer esque es posible generar de forma consistente la imagen que representeel mundo 3D, ya que cualquier objeto que pueda ser descrito median-te una ecuacin puede ser representado de forma correcta medianteRayCasting.

Como puede verse en la Figura 1.2, existen diferencias importantesentre el mtodo de despliegue que implementan las tarjetas acelerado-ras 3D (y en general los motores de visualizacin para aplicaciones in-teractivas) y el mtodo de RayCasting. El pipeline grfico de aplicacio-


nes interactivas (como veremos en la seccin 1.2) puede describirse deforma general como el que, a partir de una lista de objetos geomtricosa representar y, tras aplicar la serie de transformaciones geomtricassobre los objetos, la vista y la perspectiva, obtienen una imagen rasterdependiente del dispositivo de visualizacin. En este enfoque, las pri-mitivas se ordenan segn la posicin de la cmara y slo las visiblessern dibujadas. Por el contrario, en mtodos de sntesis de imagenrealista (como la aproximacin inicial de RayCasting) calcula los rayosque pasan por cada pxel de la imagen y recorre la lista de objetos,calculando la interseccin (si hay alguna) con el objeto ms cercano.Una vez obtenido el punto de interseccin, se evala (empleando unmodelo de iluminacin) el valor de sombreado correspondiente a esepxel.

1.2. El Pipeline Grfico

Para obtener una imagen de una escena 3D definida en el Sistemade Referencia Universal, necesitamos definir un sistema de referen-cia de coordenadas para los parmetros de visualizacin (tambindenominados parmetros de cmara). Este sistema de referencia nosdefinir el plano de proyeccin, que sera el equivalente de la zonade la cmara sobre la que se registrar la imagen1. De este modo setransfieren los objetos al sistema de coordenadas de visualizacin y fi-nalmente se proyectan sobre el plano de visualizacin (ver Figura 1.4).

El proceso de visualizar una escena en 3D mediante grficos porcomputador es similar al que se realiza cuando se toma una fotografareal. En primer lugar hay que situar el trpode con la cmara en unlugar del espacio, eligiendo as una posicin de visualizacin. A conti-nuacin, rotamos la cmara eligiendo si la fotografa la tomaremos envertical o en apaisado, y apuntando al motivo que queremos fotogra-fiar. Finalmente, cuando disparamos la fotografa, slo una pequeaparte del mundo queda representado en la imagen 2D final (el resto deelementos son recortados y no aparecen en la imagen).

La Figura 1.3 muestra los pasos generales del Pipeline asociadoa la transformacin de una escena 3D hasta su representacin finalen el dispositivo de visualizacin (tpicamente una pantalla con unadeterminada resolucin).

El Pipeline est dividido en etapas funcionales. Al igual que ocurreen los pipeline de fabricacin industrial, algunas de estas etapas serealizan en paralelo y otras secuencialmente. Idealmente, si dividimosun proceso en n etapas se incrementar la velocidad del proceso enese factor n. As, la velocidad de la cadena viene determinada por eltiempo requerido por la etapa ms lenta.

ABBCDEFBDBB

C

ABBCDEC

CABCDE

ABBCDE

FF

CCCDE

CC

ABBCDEBCD

ABBCDEBCD

CE

ABBCDE

EEC!"B

CC!"E

FF

ADEFC""

ABC

DEBFF

Figura 1.3: Pipeline generalen grficos 3D.

1En el mundo fsico, la pelcula en antiguas cmaras analgicas, o el sensor de ima-gen de las cmaras digitales.

1.2. El Pipeline Grfico [5]

ABCBDEEFCACABFAB

ABCBDEEFCACABEABE

ABCBDEEFCACABCBAA

AEBCBAA

Figura 1.4: Sistema de coordenadas de visualizacin y su relacin con otros sistemas de coordenadas de la escena.

Como seala Akenine-Mler [AMHH08], el pipeline interactivo sedivide en tres etapas conceptuales de Aplicacin, Geometra y Rasteri-zacin (ver Figura 1.3). A continuacin estudiaremos estas etapas.

1.2.1. Etapa de Aplicacin

La etapa de aplicacin se ejecuta en la CPU. Actualmente la mayo-ra de las CPUs son multincleo, por lo que el diseo de esta apli-cacin se realiza mediante diferentes hilos de ejecucin en paralelo.Habitualmente en esta etapa se ejecutan tareas asociadas al clculode la posicin de los modelos 3D mediante simulaciones fsicas, de-teccin de colisiones, gestin de la entrada del usuario (teclado, ratn,joystick...). De igual modo, el uso de estructuras de datos de alto nivelpara la aceleracin del despliegue (reduciendo el nmero de polgonosque se envan a la GPU) se implementan en la etapa de aplicacin.

1.2.2. Etapa de Geometra

En su tortuoso viaje hasta la pantalla, cada objeto 3D se trans-forma en diferentes sistemas de coordenadas. Originalmente, como semuestra en la Figura 1.4, un objeto tiene su propio Sistema de Coorde-nadas Local que nos definen las Coordenadas de Modelo, por lo quedesde su punto de vista no est transformado.

A los vrtices de cada modelo se le aplican la denominada Trans-formacin de Modelado para posicionarlo y orientarlo respecto delSistema de Coordenadas Universal, obteniendo as las denominadasCoordenadas Universales o Coordenadas del Mundo.


ABCDBEABCCADCEFCFBCDBECACCCCCCC

ABCDEFFDDCDE

ABCDEFFDDCDE

Figura 1.5: El usuario especifica la posicin de la cmara (izquierda) que se transforma, junto con los objetos de la escena,para posicionarlos a partir del origen del SRU y mirando en la direccin negativa del eje Z. El rea sombreada de la cmarase corresponde con el volumen de visualizacin de la misma (slo los objetos que estn contenidos en esa pirmide sernfinalmente representados).


Instancias

Gracias a la separacin en-tre Coordenadas de Mode-lo y Transformacin de Mo-delado podemos tener dife-rentes instancias de un mis-mo modelo para construiruna escena a las que apli-camos diferentes transfor-maciones. Por ejemplo, paraconstruir un templo romanotendramos un nico obje-to de columna y varias ins-tancias de la columna a lasque hemos aplicado diferen-tes traslaciones.

Como este sistema de coordenadas es nico, tras aplicar la trans-formacin de modelado a cada objeto, ahora todas las coordenadasestarn expresadas en el mismo espacio.

La posicin y orientacin de la cmara nos determinar qu objetosaparecern en la imagen final. Esta cmara tendr igualmente unascoordenadas universales. El propsito de la Transformacin de Vi-sualizacin es posicionar la cmara en el origen del SRU, apuntandoen la direccin negativa del eje Z y el eje Y hacia arriba. Obtenemosde este modo las Coordenadas de Visualizacin o Coordenadas enEspacio Cmara (ver Figura 1.5).

Habitualmente el pipeline contiene una etapa adicional intermediaque se denomina Vertex Shader Sombreado de Vrtice que consiste enobtener la representacin del material del objeto modelando las trans-formaciones en las fuentes de luz, utilizando los vectores normales alos puntos de la superficie, informacin de color, etc. Es convenienteen muchas ocasiones transformar las posiciones de estos elementos(fuentes de luz, cmara, ...) a otro espacio (como Coordenadas de Mo-delo) para realizar los clculos.

La Transformacin de Proyeccin convierte el volumen de visua-lizacin en un cubo unitario (ver Seccin 1.2.4). Este volumen de vi-sualizacin se define mediante planos de recorte 3D y define todoslos elementos que sern visualizados. En la figura 1.5 se representamediante el volumen sombreado. Existen multitud de mtodos de pro-yeccin, aunque como veremos ms adelante, los ms empleados sonla ortogrfica (o paralela) y la perspectiva.

En la seccin 1.2.4 estudiaremos cmo se realiza la proyeccin enperspectiva de un modo simplificado. Cuando veamos en el captulo 2,determinaremos la expresin mediante la que los objetos de la escenase proyectan en un volumen simple (el cubo unitario) antes de procederal recorte y su posterior rasterizacin.

Tras la proyeccin, el volumen de visualizacin se transforma enCoordenadas Normalizadas (obteniendo el cubo unitario), donde losmodelos son proyectados de 3D a 2D. La coordenada Z se guardahabitualmente en un buffer de profundidad llamado Z-Buffer.

ABCDEFA

Figura 1.6: Los objetos queintersecan con los lmites delcubo unitario (arriba) son re-cortados, aadiendo nuevosvrtices. Los objetos que es-tn totalmente dentro del cu-bo unitario se pasan directa-mente a la siguiente etapa.Los objetos que estn total-mente fuera del cubo unitarioson descartados.

nicamente los objetos que estn dentro del volumen de visua-lizacin deben ser generados en la imagen final. Los objetos que es-tn totalmente dentro del volumen de visualizacin sern copiados n-tegramente a la siguiente etapa del pipeline. Sin embargo, aquellosque estn parcialmente incluidas necesitan ser recortadas, generandonuevos vrtices en el lmite del recorte. Esta operacin de Transfor-macin de Recorte se realiza automticamente por el hardware de latarjeta grfica. En la Figura 1.6 se muestra un ejemplo simplificado derecorte.

Finalmente la Transformacin de Pantalla toma como entrada lascoordenadas de la etapa anterior y produce las denominadas Coorde-nadas de Pantalla, que ajustan las coordenadas x e y del cubo unitarioa las dimensiones de ventana finales.


1.2.3. Etapa Rasterizacin

A partir de los vrtices proyectados (en Coordenadas de Pantalla) yla informacin asociada a su sombreado obtenidas de la etapa ante-rior, la etapa de rasterizacin se encarga de calcular los colores finalesque se asignarn a los pxeles de los objetos. Esta etapa de rasteri-zacin se divide normalmente en las siguientes etapas funciones paralograr mayor paralelismo.

En la primera etapa del pipeline llamada Configuracin de Trin-gulos (Triangle Setup), se calculan las coordenadas 2D que definenel contorno de cada tringulo (el primer y ltimo punto de cada vr-tice). Esta informacin es utilizada en la siguiente etapa (y en la in-terpolacin), y normalmente se implementa directamente en hardwarededicado.

A continuacin, en la etapa del Recorrido de Tringulo (TriangleTraversal) se generan fragmentos para la parte de cada pxel que per-tenece al tringulo. El recorrido del tringulo se basa por tanto enencontrar los pxeles que forman parte del tringulo, y se denominaTriangle Traversal (o Scan Conversion). El fragmento se calcula inter-polando la informacin de los tres vrtices denifidos en la etapa deConfiguracin de Tringulos y contiene informacin calculada sobre laprofundidad desde la cmara y el sombreado (obtenida en la etapa degeometra a nivel de todo el tringulo).

La informacin interpolada de la etapa anterior se utiliza en el Pi-xel Shader (Sombreado de Pxel) para aplicar el sombreado a nivel depxel. Esta etapa habitualmente se ejecuta en ncleos de la GPU pro-gramables, y permite implementaciones propias por parte del usuario.En esta etapa se aplican las texturas empleando diversos mtodos deproyeccin (ver Figura 1.7).

ABCDEFB

ABCDEF

FC

EF

Figura 1.7: Representacindel resultado de las princi-pales etapas del Pipeline deRasterizacin.

Finalmente en la etapa de Fusin (Merging) se almacena la infor-macin del color de cada pxel en un array de colores denominadoColor Buffer. Para ello, se combina el resultado de los fragmentos queson visibles de la etapa de Sombreado de Pxel. La visibilidad se sueleresolver en la mayora de los casos mediante un buffer de profundidadZ-Buffer, empleando la informacin que almacenan los fragmentos.

El Z-Buffer es un buffer ampliamente empleado en grficos porcomputador. Tiene el mismo tamao en pxeles que el buffer decolor, pero almacena la menor distancia para cada pxel a todoslos fragmentos de la escena. Habitualmente se representa comouna imagen en escala de grises, y asocia valores ms cercanosa blanco a distancias menores.


1.2.4. Proyeccin en Perspectiva

En grficos por computador es posible elegir entre diferentes mode-los de proyeccin de los objetos sobre el plano de visualizacin. Un mo-do muy utilizado en aplicaciones de CAD es la proyeccin de los obje-tos empleando lneas paralelas sobre el plano de proyeccin, mediantela denominada proyeccin paralela. En este modo de proyeccin seconservan las proporciones relativas entre objetos, independientemen-te de su distancia.

Mediante la proyeccin en perspectiva se proyectan los puntoshasta el plano de visualizacin empleando trayectorias convergentesen un punto. Esto hace que los objetos situados ms distantes delplano de visualizacin aparezcan ms pequeos en la imagen. Las es-cenas generadas utilizando este modelo de proyeccin son ms rea-listas, ya que sta es la manera en que el ojo humano y las cmarasfsicas forman imgenes.

Perspectiva

La mayora de los juegos 3Dse basan en el uso de c-maras de proyeccin en pers-pectiva. Estudiaremos conms detalle este tipo de mo-delos de proyeccin en el ca-ptulo 2.

En la proyeccin en perspectiva, las lneas paralelas convergen enun punto, de forma que los objetos ms cercanos se muestran de untamao mayor que los lejanos. Desde el 500aC, los griegos estudiaronel fenmeno que ocurra cuando la luz pasaba a travs de pequeasaberturas. La primera descripcin de una cmara estenopeica se atri-buye al atrnomo y matemtico holands Gemma Frisius que en 1545public la primera descripcin de una cmara oscura en la observa-cin de un eclipse solar (ver Figura 1.8). En las cmaras esteneopeicasla luz pasa a travs de un pequeo agujero para formar la imagen enla pelcula fotosensible, que aparece invertida. Para que la imagen seantida, la abertura debe ser muy pequea.

Siguiendo la misma idea y desplazando el plano de proyeccin de-lante del origen, tenemos el modelo general proyeccin en perspectiva.

Consideraremos en el resto de la seccin que ya se ha realizado latransformacin de visualizacin alineando la cmara y los objetos de laescena mirando en direccin al eje negativo Z, que el eje Y est apun-tando hacia arriba y el eje X positivo a la derecha (como se muestraen la Figura 1.5).

Figura 1.8: Descripcin dela primera cmara esteno-peica (pinhole camera o ca-mera obscura) por GemmaFrisius.

En la Figura 1.9 se muestra un ejemplo de proyeccin simple, en laque los vrtices de los objetos del mundo se proyectan sobre un planoinfinito situado en z = d (con d > 0). Suponiendo que la transforma-cin de visualizacin se ha realizado, proyectamos un punto p sobre elplano de proyeccin, obteniendo un punto p = (px, p

y,d).

Empleando tringulos semejantes (ver Figura 1.9 derecha), obtene-mos las siguientes coordenadas:

pxpx

=dpz

px =d pxpz

(1.1)


ABAC

Figura 1.9: Modelo de proyeccin en perspectiva simple. El plano de proyeccin infinitoest definido en z = d, de forma que el punto p se proyecta sobre p.

De igual forma obtenemos la coordenada py = d py/pz, y pz = d.Como veremos en el Captulo 2, estas ecuaciones se pueden expresarfcilmente de forma matricial (que es la forma habitual de trabajar in-ternamente en el pipeline). Estudiaremos ms detalles sobre el modelode proyeccin en perspectiva en el Captulo 2, as como la transforma-cin que se realiza de la pirmide de visualizacin (Frustum) al cubounitario.

1.3. Implementacin del Pipeline en GPU

El trmino GPU

Desde el 1999, se utiliza eltrmino GPU (Grpahics Pro-cessing Unit) acuado porNVIDIA para diferenciar laprimera tarjeta grfica quepermita al programador im-plementar sus propios algo-ritmos (GeForce 256).

El hardware de aceleracin grfica ha sufrido una importante trans-formacin en la ltima dcada. Como se muestra en la Figura 1.10, enlos ltimos aos el potencial de las GPUs ha superado con creces alde la CPU.

Resulta de especial inters conocer aquellas partes del Pipeline dela GPU que puede ser programable por el usuario mediante el desa-rrollo de shaders. Este cdigo se ejecuta directamente en la GPU, ypermite realizar operaciones a diferentes niveles con alta eficiencia.

En GPU, las etapas del Pipeline grfico (estudiadas en la seccin1.2) se implementan en un conjunto de etapas diferente, que ademspueden o no ser programables por parte del usuario (ver Figura 1.11).Por cuestiones de eficiencia, algunas partes del Pipeline en GPU noson programables, aunque se prevee que la tendencia en los prximosaos sea permitir su modificacin.

La etapa asociada al Vertex Shader es totalmente programable, yencapsula las cuatro primeras etapas del pipeline grfico que estudia-mos en la seccin 1.2: Transformacin de Modelado, Transformacinde Visualizacin, Sombreado de Vrtices (Vertex Shader) y Transforma-cin de Proyeccin.

1.3. Implementacin del Pipeline en GPU [11]

ABCDEFCDEDCC FCEC

ABCDEF

F

BEA

BEAAEF

DCBFD

!D

Figura 1.10: Evolucin del nmero de transistores en GPU y CPU (1999-2010)

La etapa referente al Geometry Shader es otra etapa programableque permite realizar operaciones sobre las primitivas geomtricas.

ABCABD

AB

EAFBBBC

CBC

CDEFBAB

BFAB

BEAFBA

B

Figura 1.11: Implementa-cin tpica del pipeline enGPU. La letra asociada acada etapa indica el nivelde modificacin permitida alusuario; P indica totalmenteprogramable, F indica fijo (noprogramable), y C indica con-figurable pero no programa-ble.

Las etapas de Transformacin de Recorte, Transformacin de Panta-lla, Configuracin de Tringulo, Recorrido de Tringulo y Fusin tienenun comportamiento funcional similar al estudiado en la seccin 1.2,por lo que no sern descritas de nuevo.

Finalmente, el Pixel Shader es la ltima etapa totalmente progra-mable del pipeline en GPU y permite al programador desarrollar ope-raciones especficas a nivel de pxel.

El desarrollo de shaders actualmente se realiza en lenguajes de al-to nivel con una sintaxis similar a C, como HLSL, GLSL y Cg. Estoslenguajes de alto nivel son compilados a un lenguaje ensamblador in-termedio independiente de la tarjeta grfica. Son los drivers de cadatarjeta grfica los que transforman este lenguaje intermedio en ins-trucciones especficas para cada tarjeta.

Los tres lenguajes de desarrollo de shading ms empleados ac-tualmente son HLSL (High Level Shader Language), desarro-llado por Microsoft en colaboracin con NVIDIA para Direct3D,GLSL (OpenGL Shading Language), que forma parte del estn-dar multiplataforma OpenGL, y Cg (C for Graphics) lenguajeabierto propuesto por NVidia.


Ensamblador?

En realidad este cdigo en-samblador intermedio pue-de verse como una especiede cdigo de mquina virtualque garantiza la compatibili-dad entre diferentes disposi-tivos hardware.

Veremos a continuacin brevemente algunas caractersticas de es-tas etapas programables de la GPU.

1.3.1. Vertex Shader

Los vertex shaders permiten aplicar transformaciones y deforma-ciones a nivel de vrtice. Este shader se aplica en la primera etapa delpipeline de la GPU. En esta etapa, los flujos de datos que la CPU envaa la tarjeta son procesados y se aplican las matrices de transformacinespecificadas por el usuario.

En esta etapa se aplican las instancias sobre los datos enviados a laGPU (evitando enviar varias veces las mismas primitivas geomtricas).A este nivel, el vertex shader nicamente trabaja con la informacinrelativa a los vrtices (posicin, vector normal, color y coordenadas detextura). El vertex shader no conoce nada sobre la conexin de estosvrtices entre s para formar tringulos.

Algunas operaciones clsicas que se implementan empleando ver-tex shader son efectos de lente (como por ejemplo, de ojo de pez odistorsiones como las causadas en escenas submarinas), deformacio-nes de objetos, animaciones de textura, etc.

Figura 1.12: Resultado deaplicar un Vertex Shader pa-ra deformar un modelo.

1.3.2. Geometry Shader

Los geometry shaders facilitan la creacin y destruccin de primi-tivas geomtricas en la GPU en tiempo de ejecucin (vrtices, lneas ytringulos).

La entrada de este mdulo lo forman la especificacin de los ob-jetos con sus vrtices asociados. Para cada primitiva de entrada, elgeometry shader devolver cero o ms primitivas de salida. Las pri-mitivas de entrada y salida no tienen por qu ser del mismo tipo. Porejemplo, es posible indicar un tringulo como entrada (tres vrtices3d) y devolver el centroide (un punto 3D) como salida. Las primitivasdel flujo de salida del geometry shader se obtienen en el mismo ordenque se especificaron las primitivas de entrada.

Este tipo de shaders se emplean para la simulacin de pelo, pa-ra encontrar los bordes de los objetos, o para implementar algunastcnicas de visualizacin avanzadas como metabolas o simulacin detelas.

1.3.3. Pixel Shader

A nivel de pixel shader se pueden aplicar operaciones a nivel de p-xel, permitiendo definir complejas ecuaciones de sombreado que sernevaluadas para cada pxel de la imagen.

1.4. Arquitectura del motor grfico [13]

Notacin...

En OpenGL al Pixel Sha-der se le denomina FragmentShader. En realidad es unmejor nombre, porque se tra-baja a nivel de fragmento.

El Pixel Shader tiene influencia nicamente sobre el fragmento queest manejando. Esto implica que no puede aplicar ninguna transfor-macin sobre fragmentos vecinos.

El uso principal que se da a este tipo de shaders es el estableci-miento mediante cdigo del color y la profundidad asociada al frag-mento. Actualmente se emplea para aplicar multitud de efectos de re-presentacin no realista, reflexiones, etc.

1.4. Arquitectura del motor grfico

El objetivo de esta seccin es proporcionar una primera visin gene-ral sobre los conceptos generales subyacentes en cualquier motor gr-fico 3D interactivo. Estos conceptos sern estudiados en profundidada lo largo de este documento, mostrando su uso prctico medianteejemplos desarrollados en C++ empleando el motor grfico OGRE.

Como se ha visto en la introduccin del captulo, los videojuegosrequieren hacer un uso eficiente de los recursos grficos. Hace dosdcadas, los videojuegos se diseaban especficamente para una pla-taforma hardware especfica, y las optimizaciones podan realizarse amuy bajo nivel. Actualmente, el desarrollo de un videojuego tiende arealizarse para varias plataformas, por lo que el uso de un motor gr-fico que nos abstraiga de las particularidades de cada plataforma noes una opcin, sino una necesidad.

Compatiblidad

En algunos casos, como enel desarrollo de videojuegospara PC, el programador nopuede hacer casi ningunasuposicin sobre el hardwa-re subyacente en la mqui-na donde se ejecutar final-mente el programa. En el ca-so de desarrollo para conso-las, los entornos de ejecucinconcretos estn mucho mscontrolados.

En estos desarrollos multiplataforma es necesario abordar aproxi-maciones de diseo que permitan emplear diferentes perfiles de eje-cucin. Por ejemplo, en mquinas con grandes prestaciones se em-plearn efectos y tcnicas de despliegue ms realistas, mientras queen mquinas con recursos limitados se utilizarn algoritmos con me-nores requisitos computacionales y versiones de los recursos grficosadaptadas (con diferente nivel de detalle asociado).

Las limitaciones asociadas a los recursos computacionales son unaconstante en el rea del desarrollo de videojuegos. Cada plataformaconlleva sus propias limitaciones y restricciones, que pueden asociar-se en las categoras de:

Tiempo de Procesamiento. El desarrollo de videojuegos en prc-ticamente cualquier plataforma actual require el manejo de mlti-ples ncleos de procesamiento (tanto de CPU como GPU). El ma-nejo explcito de la concurrencia (habitualmente a nivel de hilos)es necesario para mantener una alta tasa de Frames por Segundo.

Almacenamiento. En el caso de ciertos dispositivos como conso-las, la variedad de unidades de almacenamiento de los recursosdel juego (con velocidades de acceso y transferencia heterog-neas), dificultan el desarrollo del videojuego. En ciertas platafor-mas, no se dispone de aproximaciones de memoria virtual, por loque el programador debe utilizar explcitamente superposiciones


Figura 1.13: Capturas de algunos videojuegos desarrollados con motores libres. La imagen de la izquierda se correspondecon Planeshift, realizado con Crystal Space. La captura de la derecha es del videojuego H-Craft Championship, desarrolladocon Irrlicht.

(overlays) para cargar las zonas del juego que van a emplearse encada momento.

Dada la gran cantidad de restricciones que deben manejarse, ascomo el manejo de la heterogeneidad en trminos software y hardwa-re, es necesario el uso de un motor de despliegue grfico para desa-rrollar videojuegos. A continuacin enunciaremos algunos de los msempleados.

1.5. Casos de Estudio

En esta seccin se estudiarn algunos de los motores grficos 3D li-bres, comentando brevemente algunas de sus caractersticas ms des-tacables.

Crystal Space. Crystal Space (http://www.crystalspace3d.org/)es un framework completo para el desarrollo de videojuegos escri-to en C++, desarrollado inicialmente en 1997. Se distribuye bajolicencia libre LGPL, y es multiplataforma (GNU/Linux, Windowsy Mac).

Panda 3D. Panda 3D (http://www.panda3d.org/) es un motor pa-ra el desarrollo de videojuegos multiplataforma. Inicialmente fuedesarrollado por Disney para la construccin del software aso-ciado a las atracciones en parques temticos, y posteriormenteliberado en 2002 bajo licencia BSD. Este motor multiplataforma(para GNU/Linux, Windows y Mac) incluye interfaces para C++ yPython. Su corta curva de aprendizaje hace que haya sido utiliza-do en varios cursos universitarios, pero no ofrece caractersticas

1.6. Introduccin a OGRE [15]

de representacin avanzadas y el interfaz de alto nivel de Pythonconlleva una prdida de rendimiento.

Irrlicht. Este motor grfico de renderizado 3D, con primera ver-sin publicada en el 2003 (http://irrlicht.sourceforge.net/),ofrece interfaces para C++ y .NET. Existen gran cantidad dewrap-pers a diferentes lenguajes como Java, Perl, Python o Lua. Irrlichttiene una licencia Open Source basada en la licencia de ZLib.Irrlicht es igualmente multiplataforma (GNU/Linux, Windows yMac).

OGRE. OGRE (http://www.ogre3d.org/) es un motor para grfi-cos 3D libre multiplataforma. Sus caractersticas sern estudia-das en detalle en la seccin 1.6.

De entre los motores estudiados, OGRE 3D ofrece una calidad dediseo superior, con caractersticas tcnicas avanzadas que han per-mitido el desarrollo de varios videojuegos comerciales. Adems, el he-cho de que se centre exclusivamente en el capa grfica permite uti-lizar gran variedad de bibliotecas externas (habitualmente accedidasmediante plugins) para proporcionar funcionalidad adicional. En la si-guiente seccin daremos una primera introduccin y toma de contactoal motor libre OGRE.

Figura 1.14: El logotipo deOGRE 3D es un... OGRO!

1.6. Introduccin a OGRE

OGRE es un motor orientado a objetos libre para aplicaciones gr-ficas 3D interactivas. El nombre del motor OGRE es un acrnimo deObject-oriented Graphics Rendering Engine. Como su propio nombreindica, OGRE no es un motor para el desarrollo de videojuegos; secentra exclusivamente en la definicin de un middleware para el ren-derizado de grficos 3D en tiempo real.

Slo Rendering!

El desarrollo de OGRE secentra exclusivamente en laparte de despliegue grfico.El motor no proporciona me-canismos para capturar lainteraccin del usuario, nipara reproduccin audio ogestin del estado interno delvideojuego.

El proyecto de OGRE comenz en el 2000 con el propsito de crearun motor grfico bien diseado. El lder del proyecto Steve Streetingdefine el desarrollo de OGRE como un proyecto basado en la calidadms que en la cantidad de caractersticas que soporta, porque la canti-dad viene con el tiempo, y la calidad nunca puede aadirse a posterio-ri. La popularidad de OGRE se basa en los principios de meritocraciade los proyectos de software libre. As, el sitio web de OGRE 2 recibems de 500.000 visitas diarias, con ms de 40.000 descargas men-suales.

El ncleo principal de desarrolladores en OGRE se mantiene deli-beradamente pequeo y est formado por profesionales con dilatadaexperiencia en proyectos de ingeniera reales.

OGRE tiene una licencia LGPL Lesser GNU Public License. Esta li-cencia se utiliza con frecuencia en bibliotecas que ofrecen funciona-lidad que es similar a la de otras bibliotecas privativas. Por cuestinde estrategia, se publican bajo licencia LGPL (o GPL Reducida) para

2http://www.ogre3d.org


permitir que se enlacen tanto por programas libres como no libres. Lanica restriccin que se aplica es que si el enlazado de las bibliotecases esttico, la aplicacin resultado debe ser igualmente LGPL (porqueel enlazado esttico tambin enlaza la licencia).

La versin oficial de OGRE est desarrollada en C++ (el lenguajeestndar en el mbito del desarrollo de videojuegos). La rama oficialde OGRE nicamente se centra en este lenguaje sobre los sistemasoperativos GNU/Linux, Mac OS X y Microsoft Windows. No obstante,existen wrappers de la API a otros lenguajes (como Java, Python oC#) que son mantenidos por la comunidad de usuarios (presentandodiferentes niveles de estabilidad y completitud), que no forman partedel ncleo oficial de la biblioteca.

Algunas caractersticas destacables de OGRE son:

Motor Multiplataforma. Aunque el desarrollo original de OGREse realiz bajo plataformas Microsoft Windows, la distribucinoficial ofrece versiones binarias para GNU/Linux y Mac OS X.Adems, gracias al soporte nativo de OpenGL, es posible compi-lar la biblioteca en multitud de plataformas (como diversas ver-siones de Unix, adems de algunos ports no oficiales para Xboxy dispositivos porttiles). OGRE soporta la utilizacin de las APIsde despliegue grfico de bajo nivel OpenGL y Direct3D.

Portabilidad

Uno de los objetivos de di-seo de OGRE es utilizarotras bibliotecas multiplata-forma estables en su desa-rrollo, como FreeType pa-ra el despliegue de fuen-tes TrueType, OpenIL parala carga y manipulacin deimgenes y ZLib para la ges-tin de archivos comprimidosZIP.

Diseo de Alto Nivel. OGRE encapsula la complejidad de acce-der directamente a las APIs de bajo nivel (como OpenGL y Di-rect3D) proporcionando mtodos intuitivos para la manipulacinde objetos y sus propiedades relacionadas. De este modo no esnecesario gestionar manualmente la geometra o las matrices detransformacin. Todos los objetos representables de la escena seabstraen en un interfaz que encapsula las operaciones necesa-rias para su despliegue (tcnicas empleadas y pasadas de com-posicin).OGRE hace un uso de varios patrones de diseo para mejorarla usabilidad y la flexibilidad de la bibloteca. Por ejemplo, parainformar a la aplicacin sobre eventos y cambios de estado utili-za el patrn Observador. El patrn Singleton se emplea en grannmero de Gestores para forzar que nicamente exista una ins-tancia de una clase. El patrn Visitor se emplea para permitiroperaciones sobre un objeto sin necesidad de modificarlo (comoen el caso de los nodos del grafo de escena), el patrn Facade pa-ra unificar el acceso a operaciones, Factora para la creacin deinstancias concretas de interfaces abstractos, etc. La definicinde estos patrones sern estudiadas en detalle en el Mdulo 1 delcurso.

Grafos de Escena. Prcticamente cualquier biblioteca de des-pliegue de grficos 3D utiliza un Grafo de Escena para organizarlos elementos que sern representados en la misma. Un objetivofundamental en el diseo de esta estructura de datos es permitirbsquedas eficientes. Una de las caractersticas ms potentes deOGRE es el desacople del grafo de escena del contenido de la es-cena, definiendo una arquitectura de plugins. En pocas palabras,


a diferencia de otros motores grficos como Irrlicht3D, Blitz3D oTrueVision3D (o motores de videojuegos como Torque, CryEngi-ne o Unreal), OGRE no se basa en la Herencia como principio dediseo del Grafo de Escena, sino en la Composicin. Esto permi-te expandir el diseo cmodamente para soportar otros tipos dedatos (como audio o elementos de simulacin fsica).

ABCD

EACCFB

EACCC EACCC

CCA CCA

EC E

CCC CCC

AB

AB

ABCD

Figura 1.15: Esquema gene-ral de la gestin del grafo deescena en OGRE.

La Figura 1.15 muestra el esquema general de gestin del grafode escena en OGRE. Los Renderables manejan la geometra de laescena. Todas las propiedades para el despliegue de estos Rende-rables (como por ejemplo los materiales) se gestionan en objetosde tipo Entidad (Entity) que pueden estar formados por variosobjetos SubEntidad (SubEntity). Como se ha comentado anterior-mente, la escena se Compone de nodos de escena. Estos Scene-Nodes se adjuntan a la escena. Las propiedades de esos nodosde escena (geometra, materiales, etc...) se ofrecen al SceneGraphmediante unMovableObject. De forma similar, losMovableObjectsno son subclases de SceneNode, sino que se adjuntan. Esto per-mite realizar modificaciones en la implementacin del grafo deescena sin necesidad de tocar ninguna lnea de cdigo en la im-plementacin de los objetos que contiene. Veremos ms detallessobre el trabajo con el grafo de escena a lo largo de este mdulo.

Aceleracin Hardware. OGRE necesita una tarjeta aceleradoragrfica para poder ejecutarse (con soporte de direct rendering mo-de). OGRE permite definir el comportamiento de la parte progra-mable de la GPU mediante la definicin de Shaders, estando almismo nivel de otros motores como Unreal o CryEngine.

Materiales. Otro aspecto realmente potente en OGRE es la ges-tin de materiales. Es posible crear materiales sin modificar niuna lnea de cdigo a compilar. El sistema de scripts para ladefinicin de materiales de OGRE es uno de los ms potentesexistentes en motores de rendering interactivo. Los materiales deOGRE se definen mediante una o ms Tcnicas, que se compo-nen a su vez de una o ms Pasadas de rendering (el ejemplo dela Figura 1.16 utiliza una nica pasada para simular el sombrea-do a lpiz mediante hatching). OGRE busca automticamente lamejor tcnica disponible en un material que est soportada porel hardware de la mquina de forma transparente al programa-dor. Adems, es posible definir diferentes Esquemas asociados amodos de calidad en el despliegue.

Figura 1.16: Ejemplo deShader desarrollado por As-saf Raman para simular tra-zos a Lpiz empleando el sis-tema de materiales de OGRE.

Animacin. OGRE soporta tres tipos de animacin ampliamenteutilizados en la construccin de videojuegos: basada en esque-letos (skeletal), basada en vrtices (morph y pose). En la anima-cin mediante esqueletos, OGRE permite el uso de esqueletos conanimacin basada en cinemtica directa. Existen multitud de ex-portadores para los principales paquetes de edicin 3D. En estemdulo utilizaremos el exportador de Blender.

El sistema de animacin de OGRE se basa en el uso de contro-ladores, que modifican el valor de una propiedad en funcin deotro valor. En el caso de animaciones se utiliza el tiempo como


valor para modificar otras propiedades (como por ejemplo la po-sicin del objeto). El motor de OGRE soporta dos modelos bsicosde interpolacin: lineal y basada en splines cbicas.

Optimizacin offline

El proceso de optimizacin deal formato binario de OGREcalcula el orden adecuado delos vrtices de la malla, cal-cula las normales de las ca-ras poligonales, as como ver-siones de diferentes nivelesde detalle de la malla. Esteproceso evita el clculo de es-tos parmetros en tiempo deejecucin.

La animacin y la geometra asociada a los modelos se almacenaen un nico formato binario optimizado. El proceso ms emplea-do se basa en la exportacin desde la aplicacin de modeladoy animacin 3D a un formato XML (Ogre XML) para convertirloposteriormente al formato binario optimizado mediante la herra-mienta de lnea de rdenes OgreXMLConverter.

Composicin y Postprocesado. El framework de composicin fa-cilita al programador incluir efectos de postprocesado en tiempode ejecucin (siendo una extensin del pixel shader del pipelineestudiado en la seccin 1.3.3). La aproximacin basada en pasa-das y diferentes tcnicas es similar a la explicada para el gestorde materiales.

Plugins. El diseo de OGRE facilita el diseo de Plugins comocomponentes que cooperan y se comunican mediante un interfazconocido. La gestin de archivos, sistemas de rendering y el sis-tema de partculas estn implementados basados en el diseo dePlugins.

Gestin de Recursos. Para OGRE los recursos son los elementosnecesarios para representar un objetivo. Estos elementos son lageometra, materiales, esqueletos, fuentes, scripts, texturas, etc.Cada uno de estos elementos tienen asociado un gestor de recur-so especfico. Este gestor se encarga de controlar la cantidad dememoria empleada por el recurso, y facilitar la carga, descarga,creacin e inicializacin del recurso. OGRE organiza los recursosen niveles de gestin superiores denominados grupos. Veremosen la seccin 1.6.1 los recursos gestionados por OGRE.

Caractersticas especficas avanzadas. El motor soporta grancantidad de caractersticas de visualizacin avanzadas, que estu-diaremos a lo largo del mdulo, tales como sombras dinmicas(basadas en diversas tcnicas de clculo), sistemas de partcu-las, animacin basada en esqueletos y de vrtices, y un largoetctera. OGRE soporta adems el uso de otras bibliotecas au-xiliares mediante plugins y conectores. Entre los ms utilizadoscabe destacar las bibliotecas de simulacin fsica ODE, el soportedel metaformato Collada, o la reproduccin de streaming de v-deo con Theora. Algunos de estos mdulos los utilizaremos en elmdulo 3 del presente curso.

1.6.1. Arquitectura General

El diagrama de la Figura 1.17 resume algunos de los objetos prin-cipales del motor OGRE. No es un diagrama exhaustivo, pero facilitala comprensin de los principales mdulos que utilizaremos a lo largodel curso.


A

BCDECF

EAC FE

FE

FE FE

DDBCCD

EAD ADE

B

DBCCD

DDC

DBCCDADCF

AD EA

B!CF"#

E$ %CDC &E

BCCD "DBCCD

%B!CF

%'DE!(CD$ &)*D

'DE!(CD$ )*D

&AD$

AD$

Figura 1.17: Diagrama general de algunos de los objetos principales de OGRE

Objeto Root

El objeto Root es el eje prici-pal sobre el que se define unaaplicacin que utiliza OGRE.La creacin de una instan-cia de esta clase har que seinicie Ogre, y su destruccinhar que se libere la memoriaasociada a todos los objetosque dependen de l.

Uno de los objetos principales del sistema es el denominado Root.Root proporciona mecanismos para la creacin de los objetos de altonivel que nos permitirn gestionar las escenas, ventanas, carga deplugins, etc. Gran parte de la funcionalidad de Ogre se proporciona atravs del objeto Root. Como se muestra en el diagrama 1.17, existenotros tres grupos de clases principales en OGRE:

Gestin de Escena: Los objetos de este grupo de clases se en-cargan de definir el contenido de la escena virtual, su estructura,as como otras propiedades de alto nivel de abstraccin (posicinde la cmara, posicin de los objetos, materiales, etc...). Comose estudi en la Figura 1.15, el grafo de escena es un elementoprincipal en la arquitectura de cualquier motor 3D. En el casode OGRE, el Gestor de Escena (clase SceneManager) es el que seencarga de implementar el grafo de escena. Los nodos de esce-na SceneNode son elementos relacionados jerrquicamente, quepueden adjuntarse o desligarse de una escena en tiempo de eje-cucin. El contenido de estos SceneNode se adjunta en la formade instancias de Entidades (Entity), que son implementaciones dela clase MovableObject.

Gestin de Recursos: Este grupo de objetos se encarga de ges-tionar los recursos necesarios para la representacin de la escena(geometra, texturas, tipografas, etc...). Esta gestin permite su


carga, descarga y reutilizacin (mediante cachs de recursos). Enla siguiente subseccin veremos en detalle los principales gesto-res de recursos definidos en OGRE.

Entidades Procedurales

La mayor parte de las en-tidades que incluyas en elSceneNode sern cargadasde disco (como por ejemplo,una malla binaria en formato.mesh). Sin embargo, OGREpermite la defincin en cdi-go de otras entidades, comouna textura procedural, o unplano.

Rendering: Este grupo de objetos sirve de intermediario entre losobjetos de Gestin de Escena y el pipeline grfico de bajo nivel(con llamadas especficas a APIs grficas, trabajo con buffers, es-tados internos de despliegue, etc.). La clase RenderSystem es uninterfaz general entre OGRE y las APIs de bajo nivel (OpenGL oDirect3D). La forma ms habitual de crear la RenderWindow esa travs del objeto Root o mediante el RenderSystem (ver Figura1.18). La creacin manual permite el establecimiento de mayorcantidad de parmetros, aunque para la mayora de las aplica-ciones la creacin automtica es ms que suficiente.

Por ser la gestin de recursos uno de los ejes principales en lacreacin de una aplicacin grfica interactiva, estudiaremos a con-tinuacin los grupos de gestin de recursos y las principales clasesrelacionadas en OGRE.

Gestin de Recursos

Como hemos comentado anteriormente, cualquier elemento nece-sario para represesntar una escena se denomina recurso. Todos losrecursos son gestionados por un nico objeto llamado ResourceGroup-Manager, que se encarga de buscar los recursos definidos en la apli-cacin e inicializarlos. Cada tipo de recurso tiene asociado un gestorde recurso particular. Veamos a continuacin los tipos de recursossoportados en OGRE:

Mallas. La geometra de los elementos de la escena se especificaen un formato de malla binario (.mesh). Este formato almacena lageometra y la animacin asociada a los objetos.

Materiales. Como se ha descrito anteriormente, el material se es-pecifica habitualmente mediante scripts (en ficheros de extensin.material). Estos scripts pueden estar referenciados en el propioarchivo .mesh o pueden ser enlazados a la malla mediante cdigocompilado.

Texturas. OGRE soporta todos los formatos de texturas 2D ad-mitidos por la biblioteca OpenIL. El formato se reconoce por laextensin asociada al mismo.

Esqueletos. Habitualmente el esqueleto est referenciado en elfichero .mesh. El fichero de definicin de esqueleto contiene lajerarqua de huesos asociada al mismo y tiene una extensin.skeleton.

Fuentes. Las fuentes empleadas en la etapa de despliegue deOverlays se definen en un archivo .fontdef.

Composicin. El framework de composicin de OGRE carga susscripts con extensin .compositor.


ABC

AB

DEF

ACDEF

DF

F

BF

F

F F!

"C#F $B

FF

DC

%F

D

Figura 1.18: Diagrama de clases simplificado de los Gestores de alto nivel que dan acceso a los diferentes subsistemasdefinidos en OGRE

GPU. El cdigo de shaders definidos para la GPU (de HLSL, GLSLy Cg) se describe en archivos con extensin .program. De igualmodo se pueden definir cdigo en ensamblador mediante archi-vos .asm. Los programas de GPU son cargados antes que se pro-cese cualquier archivo de material .material, de forma que estosshaders puedan ser referenciados en los archivos de definicinde material.

Un gestor (Manager) en OGRE es una clase que gestiona el accesoa otros tipos de objetos (ver Figura 1.18). Los Managers de OGRE seimplementan mediante el patrn Singleton que garantiza que nica-mente hay una istancia de esa clase en toda la aplicacin. Este patrnpermite el acceso a la instancia nica de la clase Manager desde cual-quier lugar del cdigo de la aplicacin.

Como puede verse en la Figura 1.18, el ResourceManager es unaclase abstracta de la que heredan un gran nmero de Managers, talescomo el encargado de las Fuentes, las Texturas o las Mallas. A conti-nuacin se ofrece una descripcin general de los Managers (por ordenalfabtico) definidos en OGRE. A lo largo del documento se describirn(y se utilizarn ampliamente) muchos de estos gestores.

Archive Manager. Se encarga de abstraer del uso de ficheroscon diferentes extensiones, directorios y archivos empaquetados.zip.


CompositorManager. Esta clase proporciona acceso al frame-work de composicin y postprocesado de OGRE.

ControllerManager. Es el gestor de los controladores que, comohemos indicado anteriormente, se encargan de producir cambiosen el estado de otras clases dependiendo del valor de ciertas en-tradas.

DynLibManager. Esta clase es una de las principales en el di-seo del sistema de Plugins de OGRE. Se encarga de gestionarlas bibliotecas de enlace dinmico (DLLs en Windows y objetoscompartidos en GNU/Linux).

ExternalTextureSourceManager. Gestiona las fuentes de textu-ra externas (como por ejemplo, en el uso de video streaming).

FontManager. Gestiona las fuentes disponibles para su repre-sentacin en superposiciones 2D (ver OverlayManager).

GpuProgramManager. Carga los programas de alto nivel de laGPU, definidos en ensamblador. Se encarga igualmente de cargarlos programas compilados por el HighLevelGpuProgramManager.

HighLevelGpuProgramManager. Gestiona la carga y compila-cin de los programas de alto nivel en la GPU (shaders) utilizadosen la aplicacin en HLSL, GLSL o Cg.

LogManager. Se encarga de enviar mensajes de Log a la salidadefinida por OGRE. Puede ser utilizado igualmente por cualquiercdigo de usuario que quiera enviar eventos de Log.

MaterialManager. Esta clase mantiene las instancias de Materialcargadas en la aplicacin, permitiendo reutilizar los objetos deeste tipo en diferentes objetos.

MeshManager. De forma anloga al MaterialManager, esta cla-se mantiene las instancias de Mesh permitiendo su reutilizacinentre diferentes objetos.

OverlayManager. Esta clase gestiona la carga y creacin de ins-tancias de superposiciones 2D, que permiten dibujar el interfazde usuario (botones, iconos, nmeros, radar...). En general, loselementos definidos como HUDs (Head Up Display).

ParticleSystemManager. Gestiona los sistemas de partculas,permitiendo aadir gran cantidad de efectos especiales en aplica-ciones 3D. Esta clase gestiona los emisores, los lmites de simu-lacin, etc.

PlatformManager. Esta clase abstrae de las particularidades delsistema operativo y del hardware subyacente de ejecucin, pro-porcionando rutinas independientes del sistema de ventanas, tem-porizadores, etc.

ResourceGroupManager. Esta clase gestiona la lista de gruposde recursos y se encarga de notificar a los Managers de la nece-sidad de cargar o liberar recursos en cada grupo.


SceneManager. Como se ha explicado anteriormente, esta cla-se se encarga de la gestin, organizacin y rendering de la esce-na. Esta clase permite definir subclases que organicen la escenade una forma ms eficiente, dependiendo del tipo de aplicacin.Por defecto, el SceneManager utiliza una jerarqua de cajas lmite(bounding boxes) para optimizar el despliegue de los objetos.

SceneManager

Los SceneManagers de OGREson implementados comoPlugins, de forma que elusuario puede cargar variosgestores de escena en suaplicacin. Si el videojuegorequiere escenas de interio-res con mucha geometra, ascomo escenas de exteriores,puede ser interesante cargardos gestores de escenadiferentes optimizados paracada parte del juego.

SkeletonManager. Al igual que el MaterialManager y el MeshMa-nager, esta clase mantiene las instancias de Skeleton cargadasen la aplicacin, permitiendo su reutilizacin entre diferentes ob-jetos.

TextureManager. Gestiona la carga y uso de las texturas de laaplicacin.

1.6.2. Instalacin

En esta seccin se detallar el proceso de instalacin de la bibliote-ca OGRE 1.7 en sistemas GNU/Linux yMicrosoft Windows. Nos centra-remos en la instalacin en distribuciones Debian, que servirn comobase para el desarrollo del presente curso. No obstante, se proporcio-narn igualmente las herramientas necesarias y makefiles adaptadospara Microsoft Windows empleando MinGW.

GNU/Linux (Debian)

Para comenzar, instalaremos las herramientas de compilacin b-sicas necesarias para compilar: gcc, g++ y make se encuentran dispo-nibles en el metapaquete build-essential:

apt-get install build-essential

A continuacin instalaremos los paquetes especficos de OGRE:

apt-get install libogre-1.7.3 libogre-dev ogre-doc ogre-tools

El paquete libogre-1.7.3 contiene las bibliotecas necesarias parala ejecucin de las aplicaciones desarrolladas con OGRE. El paquetelibogre-dev contiene los ficheros de cabecera instalados en /usr/in-clude/OGRE necesarios para compilar nuestros propios ejemplos. El pa-quete de documentacin ogre-doc instala en /usr/share/doc/ogre-docla documentacin (manual de usuario y API). Finalmente el paque-te ogre-tools contiene las herramientas para convertir al formato demalla binario optimizado de OGRE.

Como se coment en la introduccin, OGRE se centra en propor-cionar exclusivamente un motor de despliegue grfico 3D interactivo.OGRE no proporciona mecanismos para gestionr la entrada del usua-rio. En este mdulo utilizaremos OIS (Object Oriented Input System),una biblioteca desarrollada en C++ multiplataforma que permite tra-bajar con teclado, ratn, joysticks y otros dispositivos de juego. Insta-laremos igualmente el paquete binario y las cabeceras.


apt-get install libois-1.3.0 libois-dev

Tanto OGRE como OIS puede ser igualmente instalado en cual-quier distribucin compilando directamente los fuentes. En el caso deOGRE, es necesario CMake para generar el makefile especfico parael sistema donde va a ser instalado. En el caso de OIS, es necesarioautotools.

Microsoft Windows

Aunque no utilizaremos ningn entorno de desarrollo en esta plata-forma, dada su amplia comunidad de usuarios, puede ser convenientegenerar los ejecutables para esta plataforma. A continuacin se de-tallarn los pasos necesarios para instalar y compilar los desarrollosrealizados con OGRE en plataformas Windows.

Como entorno de compilacin utilizaremos MinGW (Minimalist GNUfor Windows), que contiene las herramientas bsicas de compilacinde GNU para Windows.

El instalador de MinGW mingw-get-inst puede obtenerse de la p-gina web http://www.mingw.org/. Puedes instalar las herramientas enC:\MinGW\. Una vez instaladas, debers aadir al path el directorioC:\MinGW\bin. Para ello, podrs usar la siguiente orden en un termi-nal del sistema.

path = %PATH%;C:\MinGW\bin

De igual modo, hay que descargar el SDK de DirectX3. Este paso esopcional siempre que no queramos ejecutar ningn ejemplo de OGREque utilice Direct3D.

Sobre Boost...

Boost es un conjunto de bi-bliotecas libres que aadenmultitud de funcionalidad ala biblioteca de C++ (estnen proceso de aceptacin porel comit de estandarizacindel lenguaje).

A continuacin instalaremos la biblioteca OGRE3D para MinGW4.Cuando acabe, al igual que hicimos con el directorio bin de MinGW,hay que aadir los directorios boost_1_44\lib\ y bin\Release al path.

path = %PATH%;C:\Ogre3D\boost_1_44\lib\; C:\Ogre3D\bin\

1.7. Hola Mundo en OGRE

A continuacin examinaremos un ejemplo bsico de funcionamien-to de OGRE. Utilizaremos la estructura de directorios mostrada en laFigura 1.19 en los ejemplos desarrollados a lo largo de este mdulo.

En el directorio include se incluirn los archivos de cabecera. Eneste primer ejemplo, no es necesario ningn archivo de cabeceraadicional, por lo que este directorio estar vaco.

3Puede descargarse de: http://www.microsoft.com/download/en/details.aspx?-displaylang=en&id=6812

4Puede descargarse de: http://www.ogre3d.org/download/sdk

1.7. Hola Mundo en OGRE [25]

El directorio media contendr los archivos de geometra, anima-ciones y texturas necesarios para ejecutar el ejemplo. Todos estosarchivos sern cargados por el ResourceManager.

En obj se generarn automticamente los ficheros objeto compi-lados a partir de los fuentes existentes en src.

El diretorio plugins contendr los plugins de Ogre. En GNU/Li-nux, podemos crear un enlace simblico de este directorio al lu-gar donde se encuentran los plugins (archivos .so) en disco. EnWindows deberemos copiar los .dll a este directorio. La ruta deeste directorio, como veremos ms adelante, se debe indicar en elarchivo plugins.cfg.

El directorio src contiene los ficheros fuente de la aplicacin.Gracias al makefile que veremos a continuacin, la compilacinde todos los ficheros fuente en objetos binarios se realiza auto-mticamente.

AB

CB

DE

F

A

CBB

CBB

BA

FA

BABA

Figura 1.19: Descripcin dedirectorios del ejemplo HolaMundo.

Para compilar el ejemplo, definiremos un makefile para ambos sis-temas operativos. En el siguiente listado se muestra el listado paraGNU/Linux.

En la lnea 0 se define el nombre del ejecutable que queremos

obtener. A continuacin en las lneas 1-3 se definen los directorios

para los archivos fuente, objetos y cabeceras. Las lneas 7 y 9 definen

los flags para la compilacin y enlazado respectivamente.

El makefile construido permite indicar el modo de compilacin, uti-lizando unos flags de compilacin en modo Debug y otros en modo Re-lease. Si llamamos a make con mode=release, se utilizarn los flags decompilacin optimizada. En otro caso, utilizaremos la compilacin consmbolos para el depurado posterior con GDB.

En las lneas 20-21 se utilizan las funciones de make para generar

la lista de objetos a partir de los fuentes .cpp existentes en el directorioapuntado por DIRSRC. De este modo, se obtienen los objetos con elmismo nombre que los fuentes, pero situados en el directorio indicadopor DIROBJ.

Finalmente, en las lneas 32-37 se emplean las reglas de compila-

cin implcitas de make para generar el ejecutable. Se incluye al finalla tpica regla de clean para limpiar los temporales obtenidos.

De este modo, para compilar el ejemplo en modo release ejecutare-mos en un terminal

make mode=release

Si no indicamos modo, o indicamos explcitamente mode=debug, seutilizarn los flags de compilacin en modo debug.


Listado 1.1: Makefile genrico para GNU/Linux

0 EXEC := helloWorld1 DIRSRC := src/2 DIROBJ := obj/3 DIRHEA := include/4 CXX := g++56 # Flags de compilacion --------------------------------------------7 CXXFLAGS := -I $(DIRHEA) -Wall pkg-config --cflags OGRE8 # Flags del linker ------------------------------------------------9 LDFLAGS := pkg-config --libs OGRE -lGL -lOIS -lstdc++

1011 # Modo de compilacion (-mode=release -mode=debug) -----------------12 ifeq ($(mode), release)13 CXXFLAGS += -O2 -D_RELEASE14 else15 CXXFLAGS += -g -D_DEBUG16 mode := debug17 endif1819 # Obtencion automatica de la lista de objetos a compilar ----------20 OBJS := $(subst $(DIRSRC), $(DIROBJ), \21 $(patsubst %.cpp, %.o, $(wildcard $(DIRSRC)*.cpp)))2223 .PHONY: all clean2425 all: info $(EXEC)2627 info:28 @echo ---------------------------------------------------29 @echo >>> Using mode $(mode)30 @echo (Please, call "make" with [mode=debug|release])31 @echo ---------------------------------------------------32 # Enlazado --------------------------------------------------------33 $(EXEC): $(OBJS)34 $(CXX) $(LDFLAGS) -o $@ $^35 # Compilacion -----------------------------------------------------36 $(DIROBJ)%.o: $(DIRSRC)%.cpp37 $(CXX) $(CXXFLAGS) -c $< -o $@38 # Limpieza de temporales ------------------------------------------39 clean:40 rm -f *.log $(EXEC) *~ $(DIROBJ)* $(DIRSRC)*~ $(DIRHEA)*~

El makefile en su versin para plataformas windows se ha nom-brado como makefile.win. Bsicamente es similar al estudiado paraGNU/Linux, pero cambian los flags de compilacin. Para compilar,tendremos que ejecutar el make de MinGW que se denomina mingw32-make. De este modo, para compilar ejecutaremos desde una consola:

mingw32-make -f makefile-windows mode=release

Como se muestra en la Figura 1.19, adems de los archivos paramake, en el directorio raiz se encuentran tres archivos de configura-cin. Estudiaremos a continuacin su contenido:

Figura 1.20: Ventana deconfiguracin de las propie-dades de Rendering.

ogre.cfg. Este archivo, si existe, intentar ser cargado por el ob-jeto Root. Si el archivo no existe, o est creado de forma inco-rrecta, se le mostrar al usuario una ventana para configurarlos parmetros (resolucin, mtodo de anti-aliasing, profundidadde color, etc...). En el ejemplo que vamos a realizar, se fuerza a

1.7. Hola Mundo en OGRE [27]

que siempre se abra el dilogo (ver Figura 1.20), recuperando losparmetros que el usuario especific en la ltima ejecucin.

plugins.cfg. Como hemos comentado anteriormente, un plugines cualquier mdulo que implementa alguno de los interfaces deplugins de Ogre (como SceneManager o RenderSystem). En estearchivo se indican los plugins que debe cargar OGRE, as comosu localizacin. En el ejemplo del holaMundo, el contenido delarchivo indica la ruta al lugar donde se encuentran los plugins(PluginFolder), as como el Plugin que emplearemos (pueden es-pecificarse varios en una lista) para el rendering con OpenGL.

Plugins.cfg en Windows

En sistemas Windows, comono es posible crear enlacessimblicos, se deberan co-piar los archivos .dll al di-rectorio plugins del proyec-to e indicar la ruta relativaa ese directorio en el archivoplugins.cfg. Esta aproxi-macin tambin puede reali-zarse en GNU/Linux copian-do los archivos .so a dichodirectorio.

resources.cfg. En esta primera versin del archivo de recursos,se especifica el directorio general desde donde OGRE deber car-gar los recursos asociados a los nodos de la escena. A lo largo delcurso veremos cmo especificar manualmente ms propiedadesa este archivo.

Una vez definida la estructura de directorios y los archivos queforman el ejemplo, estudiaremos la docena de lneas de cdigo quetiene nuestro Hola Mundo.

Listado 1.2: El main.cpp del Hola Mundo en OGRE

0 #include 12 class SimpleExample : public ExampleApplication {3 public : void createScene() {4 Ogre::Entity *ent = mSceneMgr->createEntity("Sinbad", "Sinbad.

mesh");5 mSceneMgr->getRootSceneNode()->attachObject(ent);6 }7 };89 int main(void) {10 SimpleExample example;11 example.go();1213 return 0;14 }

Como vemos, en el main se crea una instancia de la clase SimpleE-xample (definida en las lneas

2-7 ). Esta clase es derivada de la clasebase ExampleApplication, que se proporciona en el SDK de OGRE parafacilitar el aprendizaje de la biblioteca.

Nombres en entidades

Si no indicamos ningn nom-bre, OGRE elegir automti-camente un nombre para lamisma. El nombre debe sernico. Si el nombre existe,OGRE devolver una excep-cin.

En esta clase definimos el mtodo pblico CreateScene. En la lnea 4 llamamos al SceneManager (creado automticamente por la clasebase ExampleApplication) a travs de su puntero, solicitando la crea-cin de una entidad con nombre nico Sinbad, asociado a Sinbad.mesh(que se encontrar en el directorio especificado en resources.cfg). Es-ta llamada nos crear la entidad, y nos devolver un puntero a unobjeto de ese tipo.

A continuacin, adjuntamos la entidad creada a la escena. Paraello, accedemos al mtodo attachObject() del nodo raz devuelto porgetRootSceneNode().


Si compilamos y ejecutamos el holaMundo, primero nos aparece-r una ventana para configurar las opciones de rendering (como semuestra en la Figura 1.20). Cuando pulsemos

Accept , se abrir unaventana con el modelo cargado (muy pequeito). Si pulsamos la flechadel cursor

, el modelo se acercar. Podemos variar la posicin de lacmara y la rotacin del modelo (as como su modo de rendering) conlos otros tres cursores

leftarrow downarrow rightarrow , y las teclas A , S , D , W y R . La salida del modelo se muestra en la Figura1.21.

Figura 1.21: Resultado, trasajustar el modelo, del HelloWorld.

La clase ExampleApplication nos abstrae de la complejidad de crearuna aplicacin desde cero con OGRE. Utilizaremos esta clase base enalgunos ejemplos ms del siguiente captulo, pero la abandonaremosrpidamente para controlar todos los aspectos relativos a la inicia-lizacin (carga de Plugins, definicin del RenderSystem, gestin de lacmara virtual, control de eventos, etc).

Captulo2Matemticas para

Videojuegos

Carlos Gonzlez Morcillo

E n este captulo comenzaremos a estudiar las transformacionesafines bsicas que sern necesarias para en el desarrollo de Vi-deojuegos. Las transformaciones son herramientas imprescin-dibles para cualquier aplicacin que manipule geometra o, en general,objetos descritos en el espacio 3D. La mayora de APIs y motores gr-ficos que trabajan con grficos 3D (como OGRE) implementan clasesauxiliares para facilitar el trabajo con estos tipos de datos.

2.1. Puntos, Vectores y Coordenadas

Figura 2.1: Aunque en desa-rrollo de videojuegos se haceuso de prcticamente todaslas reas de las matemti-cas (desde trigonometra, l-grebra, estadstica o clcu-lo), en este captulo nos cen-traremos en los fundamentosms bsicos del lgebra li-neal.

Los videojuegos necesitan posicionar objetos en el espacio 3D. Elmotor grfico debe gestionar por tanto la posicin, orientacin y esca-la de estos objetos (y sus cambios a lo largo del tiempo). Como vimosen el captulo 1, en grficos interactivos suelen emplearse represen-taciones poligionales basadas en tringulos para mejorar la eficiencia.Los vrtices de estos tringulos se representan mediante puntos, y lasnormales mediante vectores. Veamos a continuacin algunos concep-tos bsicos relacionados con los puntos y los vectores.

29

[30] CAPTULO 2. MATEMTICAS PARA VIDEOJUEGOS

2.1.1. Puntos

Un punto puede definirse como una localizacin en un espacio n-dimensional. En el caso de los videojuegos, este espacio suele ser bidi-mensional o tridimensional. El tratamiento discreto de los valores aso-ciados a la posicin de los puntos en el espacio exige elegir el tamaomnimo y mximo que tendrn los objetos en nuestro videojuego. Escrtico definir el convenio empleado relativo al sistema de coordena-das y las unidades entre programadores y artistas. Existen diferentessistemas de coordenadas en los que pueden especificarse estas posi-ciones, como se puede ver en la Figura 2.2:

AB

BCDBE

FBE

Figura 2.2: Representacin de un punto empleando diferentes sistemas de coordena-das.

Coordenadas Cartesianas. Es sin duda el sistema de coordena-das ms habitual. Este sistema de coordenadas define ejes per-pediculares para especificar la posicin del punto en el espacio.Como se muestra en la figura 2.3, existen dos convenios para ladefinicin de los ejes de coordenadas cartesianas; segn la reglade la mano derecha o de la mano izquierda. Es muy sencillo con-vertir entre ambos convenios; basta con invertir el valor del ejeque cambia.

Coordenadas Cilndricas. En este sistema se utiliza un eje ver-tical para definir la altura h, un eje radial r que mide la distanciacon ese eje h, y un ngulo de rotacin definido en la circunfe-rencia sobre ese radio.

ABC

DEFA

Figura 2.3: Convenios pa-ra establecer los sistemas decoordenadas cartesianas.

Coordenadas Esfricas. Este sistema emplea dos ngulos y ,y una distancia radial r.

2.1. Puntos,

desarrollo videojuegos 2 programacion grafica

Documents