Algo que me tenía bastante confundido era cómo dibujar los polígonos que tenían mapeada una textura de cielo de la forma en que se veían en el juego. Finalmente, lo que decidí hacer fue simplemente eliminar todos estos polígonos y dibujar una Skybox acorde a las dimensiones de la bounding box del mapa.

Rendering del cielo en base2.bsp.

Para renderizar el cielo desarrollé un nuevo Shader que elimina la porción de traslación de la matriz ModelView, haciendo que el cielo se encuentre “infinitamente” lejano. A nivel de mapeo de texturas, utilicé CLAMP_TO_EDGE para ocultar las aristas de la Skybox. El efecto es bastante sorprendente: incluso sabiendo dónde se ubican las aristas, resulta difícil notar las caras interiores de la Skybox.

Cuarto de exteriores en base1.bsp, renderizado con su cielo.

Cuarto final en base1.bsp. Notar el cielo a través de las ventanas y el techo.

Primer mapa del Juego, renderizado desde la posición de inicio del jugador con mapeo de texturas.

La ventaja de soportar los archivos PAK originales del juego es que ahora puedo cargar los recursos del juego directamente desde ahí (incluso los mapas BSP), sin necesidad de previamente extraerlos.

Comenzemos estudiando la paleta de colores. La paleta se encuentra dentro del PAK bajo el nombre “pics/colormap.pcx”. Para poder acceder a su contenido es necesario cargarla en memoria desde el PAK como un BLOB. Este BLOB es una imagen codificada en PCX, y es necesario descomprimirla para poder utilizarla como una matriz de colores.

Luego, cada WAL correspondiente a un polígono es referenciado mediante su nombre y ruta dentro del PAK. Los WAL consisten principalmente en un header que determina, entre otras cosas, las dimensiones de la imagen y el offset donde comienzan los datos. Los datos a leer son exactamente w*h bytes a partir de offset[0]. Estos datos son una matriz de índices a la paleta de colores. Afortunadamente, estos datos no se encuentran codificados de ninguna forma y pueden utilizarse directamente para indexar la paleta de colores.

A modo de comentario, cada índice leído es exactamente un byte de tamaño, por lo cual los WAL en teoría no pueden referenciar más de 256 colores distintos en la paleta. Consecuentemente, uno esperaría que la paleta sea exactamente de 256*3 bytes, sin embargo, esto no es así. Quizás otros aspectos del motor utilizan la misma paleta y por eso existen colores que en principio no podrán ser referenciados.

Una vez que tenemos el WAL y la paleta, la textura se crea fusionándolos en una matriz de colores RGB. Esto se puede hacer de dos formas: se puede suministrar la paleta a OpenGL y luego crear una textura compuesta por índices, o bien, se puede fusionar la paleta con el WAL manualmente por Software y suministrar texturas 2D ya preparadas a OpenGL.

El primer enfoque tiene la ventaja de que se ahorra mucha memoria de video, ya que por cada textura, necesitamos almacenar solamente 1/3 de los datos que necesitaríamos para almacenar colores RGB (más la paleta una única vez). Por otro lado, este enfoque es más difícil de configurar a nivel de OpenGL (yo no logré hacerlo andar), requiere que la implementación de OpenGL soporte la extensión ARB_imaging y es más lento en tiempo de ejecución, ya que OpenGL deberá fusionar la paleta con los índices por cada cuadro. A su vez, OpenGL no soporta paletas del tamaño de la del Quake 2 e, incluso si lo hiciera, deberíamos convertir todas nuestras matrices de índices a dimensiones potencias de 2.

El segundo enfoque resuelve todos estos problemas al costo de consumir más memoria de video. Personalmente elegí este segundo enfoque, al costo de saber que probablemente mi renderer tenga problemas de performance en placas de video con poca RAM (64 MB?).

Si w,h son las dimensiones del archivo WAL, “textura” es una matriz de w*h*3 bytes, “indx” el i-ésimo índice del archivo WAL y “paleta” la paleta de colores, la forma de fusionar manualmente la paleta con los índices en un array es mediante la siguiente operación:

textura[i*3+0] = paleta[indx*3+0];
textura[i*3+1] = paleta[indx*3+1];
textura[i*3+2] = paleta[indx*3+2];

Donde i es un contador en el intervalo [0, w*h), y teniendo cuidado de no leer fuera del espacio de memoria de la paleta. Es válido referenciar colores fuera de la paleta, si bien los WAL de Quake 2 no parecen hacerlo. Si esto llegase a pasar, se deberá forzar el valor a negro (0x0).

La paleta se asume es un array unidimensional de la forma R,G,B, R,G,B, ... Es por esto que la forma en que se indexa la paleta es tal que el índice 0 corresponde a los primeros 3 bytes (0,1,2), el índice 1 corresponde a los siguientes 3 (3,4,5) y así sucesivamente.

Una vez creada nuestra textura RGB, la cargamos a OpenGL y ésta queda pronta para ser utilizada.

El último detalle a tener en cuenta es la diferencia entre los sistema de coordenadas de textura de Quake 2 y de OpenGL. Quake 2 utiliza un sistema de coordenadas en píxels, mientras que OpenGL utiliza un sistema normalizado. Para solucionar esta diferencia es necesario (tras calcular las coordenadas u,v de textura), dividir u y v entre el ancho y largo de la textura respectivamente. Esto no necesariamente producirá coordenadas en el intervalo [0,1], lo cual es esperable, ya que muchas de las texturas en Quake 2 deben dibujarse con Tiling.

Sin más detalles, les dejo a continuación un par de screenshots nuevos, esta vez con la iluminación deshabilitada pero con texturas mapeadas con filtrado bilineal.

Cuarto de Ambiente Exterior en Base 1, con mapeo de texturas. Notar los Triggers puestos en el cuarto para disparar eventos en el Juego y como el cielo se ve "raro" al dibujarlo como cualquier otro polígono.

Cuarto escondido en Base 1.

Primer mapa del Juego, renderizado desde la posición de inicio del jugador.

El formato es relativamente simple de leer ya que básicamente se trata de un conjunto de blobs con un directorio. Esto hace que sea extremadamente sencillo de levantarlo desde C o C++.

La mayor dificultad con la que me encontré consistió en dar un formato a estos datos que sea razonable para enviarlos a OpenGL en forma eficiente (recordemos que es un formato del ’97). Particularmente, a mi gusto, existe demasiada “distancia” entre las hojas del Árbol BSP que contienen geometría y los detalles de la misma, debiendo atravesar varias tablas para llegar desde una hoja que se sabe visible hasta las coordenadas de los vértices que componen todos sus polígonos.

Finalmente se me ocurrió una forma de transformar todos los polígonos para evitar el tener que estar saltando entre 6 tablas cada cuadro a dibujar : )

El renderer dispone de un sistema de iluminación muy básico, con luces direccionales y brillo especular.

Los próximos pasos que me gustaría realizar serían implementar el mapeo de texturas (idealmente leyendo los archivos .wal originales del juego desde el paquete .pak) y el descartado de geometría mediante el cálculo del PVS.

Les dejo algunos screenshots.

Cuarto de "Exteriores" en base1.bsp

Cuarto de inicio del segundo mapa (base2.bsp).

El video es parte del curso de Desarrollo de Aplicaciones para iPhone de la Universidad de Stanford.

Dejo el video a continuación.

No solo nos permiten programar dentro del pipeline de la Tarjeta de Video para desarrollar efectos visuales sorprendentes, sino que además nuestros programas se ejecutan automáticamente en paralelo sobre cada uno de los vértices o fragmentos (dependiendo del tipo de Shader), permitiendo acelerar muchísimo algunas operaciones que, de ser realizadas en la CPU, frenarían toda la aplicación.

Los Shaders se desarrollan en lenguajes de programación especiales y deben ser compilados en tiempo de ejecución sobre la plataforma en la cual nuestra aplicación está ejecutando. El lenguaje de Shading compañero de OpenGL es GLSL (GL Shading Language) y su desarrollo también se encuentra a cargo del Grupo Khronos.

En Lighthouse 3D se presenta un tutorial muy claro (si bien un poquito desactualizado) que explica cómo cargar Shaders GLSL, compilarlos y adjuntarlos a un programa. Lo que me llamó la atención particularmente en el sitio fue el siguiente esquema, el cual resume visualmente todo proceso.

Carga de Shaders escritos en GLSL desde OpenGL. Fuente: Lighthouse 3D.

Algo a notar es que esta figura deja por fuera todo el proceso de interacción de la aplicación con los programas GLSL compilados, así como el proceso de limpieza de recursos posterior. Pueden revisar el resto del tutorial para obtener un pantallazo de cómo se realizan estas otras tareas.

Como es de esperarse, el tutorial asume que estamos trabajando en C, no obstante, trabajando desde Python con PyOpenGL, el proceso de carga de archivos de texto con código fuente GLSL, así como su carga a OpenGL es extremadamente sencillo. Esto es principalmente debido a que las construcciones de Python para E/S son extremadamente sencillas y, aparentemente, los desarrolladores de PyOpenGL se tomaron el trabajo de “Pythonizar” esta porción de la API, simplificando mucho todo el proceso.

Les recomiendo revisar el tutorial en Lighthouse 3D o bien dirigirse a opengl.org para encontrar la referencia completa de cada una de estas funciones y de GLSL.

Este es el sexto update a la especificación realizado en tan solo dos años. Entre las nuevas características anunciadas se encuentra soporte para la API de OpenGL ES 2.0 (ahora OpenGL es un superconjunto de OpenGL ES 2.0), soporte para trabajar con Shaders en formato binario y soporte para punto flotante de 64 bits para Vertex Shaders, entre otras.

De acuerdo con algunos sitios, las nuevas características estarían poniendo a OpenGL por delante de DirectX 11 en términos de funcionalidades, principalmente debido al hecho de poder desarrollar programas para dispositivos móviles y de escritorio utilizando la misma API, algo que de momento no se puede realizar con ninguna versión de DirectX.

Vía opengl.org

En el evento desarrollamos una aplicación para iPad que utiliza la tarjeta de video del dispositivo para calcular y desplegar los conjuntos de Julia-Fatou y Mandelbrot. La siguiente imagen muestra la Demo ejecutando sobre el Simulador de iPad:

iFractals, ejecutando sobre el Simulador de iPad

La implementación fue realizada utilizando Fragment Shaders de OpenGL ES, con el fin de utilizar la GPU del iPad como un coprocesador en paralelo, capaz de evaluar los Fractales virtualmente al mismo tiempo para cada pixel visible en la pantalla del dispositivo.

Después de desarrollar la Demo, el expositor de Globant nos invitó a explicar el concepto y tecnologías utilizadas a la Audiencia utilizando un iPad real.

Les dejo unas fotos del evento debajo.

El conjunto de Mandelbrot, renderizado en un iPad.

El conjunto de Julia para c=-0.012+0.74i, renderizado en un iPad.

Hasta el momento, el rendering de la animación era realizado sin interpolar entre keyframes, lo cual causaba que la animación se viera un poco tosca. Ayer estuve trabajando en agregar interpolación entre keyframes; El resultado fue un gran suavizado del proceso de animación.

Dejo un nuevo video a continuación. En él podrás notar que, incluso animando a tan solo 2 frames por segundo, pero interpolando, la animación se ve mucho más continua, a pesar de que el video anterior se había generado a 10 frames por segundo.

¿Notas la diferencia? El costo que tenemos que pagar por la interpolación ciertamente es un aumento en el overhead de CPU que tenemos para dibujar cada cuadro.

En el caso particular de éste modelo, cada keyframe se compone de 610 triángulos, cada triángulo de 3 vértices y cada vértice de 5 floats. Así (solo para dibujar éste modelo), entre cada cuadro, tendremos que interpolar ni más ni menos que ¡9150 floats! un proceso relativamente costoso que además aumenta con cada modelo adicional que queremos dibujar.

Como suele suceder en todo lo que tiene que ver con Computación Gráfica, la mejora en el realismo visual se financia a razón de performance. En este caso, no queda duda que el costo en términos de CPU es bien compensado por la mejora visual.

La idea consistía en cargar un modelo de popular juego de 1996 1997 de Id Software “Quake 2″ y dibujarlo en la pantalla.

El Quake 2 consistió en uno de mis juegos favoritos en la saga (que actualmente se compone de 4 juegos) y cargar sus modelos 3D y verlos animados fué como un viaje instantáneo a un pasado nostálgico.

El formato que utiliza el Quake 2 para sus modelos consiste en un archivo binario muy fácil de leer desde código C o C++.

En este archivo se definen una serie de vértices y triángulos del modelo organizados en “keyframes”: una serie de poses que permiten dibujar el modelo con animación. El archivo también referencia cero o más texturas en formato PCX a utilizarse como “piel” del modelo, en terminología del Quake 2.

Una vez que el modelo y su textura se encuentran cargados en memoria, utilizo OpenGL y GLUT para dibujarlo.

Les dejo un video que subí a YouTube con el renderer en acción. El video fue generado dibujando 10 frames por segundo y sin interpolar entre keyframes, lo cual hace que la animación sea un poco tosca y no tan suave como se podría haber hecho.

Esperen más información en los próximos días