Leo en opengl.org que el Grupo Khronos, anunció recientemente la disponibilidad de la especificación para OpenGL 4.1. Khronos realizó el anuncio durante la conferencia SIGGRAPH 2010 que se está llevando a cabo esta semana en Los Angeles.

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

Durante esta semana estuvimos orgullosamente presentes en el iOS Hackathon, parte del OpenDay organizado por Globant LLC. Globant es una de las mayores compañías de Outsourcing en el Cono Sur.

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.

En un artículo anterior les comentaba que había estado desarrollando un programa para cargar y dibujar modelos del juego “Quake 2″ de Id Software. En dicho artículo les mencionaba, a grandes rasgos, el contenido del archivo y cómo éste representa las animaciones mediante el uso de keyframes.

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.

Durante la semana pasada aproveché un par de días de ocio para trabajar en un proyecto personal.

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

Ayer me encontré con este dibujo:

Dibujando con OpenGL 3.3

Este dibujo muestra visualmente las llamadas a OpenGL versión 3.3 para dibujar geometría en la pantalla. Puede resultar una buena referencia para recordar las diferencias entre las distintas invocaciones para dibujar mediante Vertex Arrays.

En el dibujo se encuentran ausentes todas las llamadas correspondientes al rendering mediante Modo Inmediato y Dispay Lists, las cuales fueron marcadas como obsoletas a partir de OpenGL 3.2.

Visto en: http://tartley.com/?p=1045

Esta mañana leía un artículo en un blog llamado “Insight VR” muy interesante. El artículo cuenta la historia de una aplicación estilo “Asteroids” desarrollada hace 12 años por un -en aquel momento- estudiante de Computer Science.

Según cuenta, la aplicación se desarrolló utilizando Mesa, una implementación libre de OpenGL, como un trabajo obligatorio.

En un principio, la aplicación se desarrolló sobre un Mac, al poco tiempo se portó a una Workstation SGI (debiendo reescribir únicamente las rutinas de entrada del usuario). A los años, ésta se portó a Windows y, más recientemente, al iPhone.

La historia es muy interesante y termina con una conclusión bastante importante. El autor destaca como el hecho de haber trabajado con un estándar abierto (OpenGL) permitió que su programa pudiera mantenerse vigente y sobreviviera la prueba del tiempo.

“Imagina si en vez de OpenGL (ok, Mesa3D) hubiesemos usado alguna versión temprana de Direct3D para mi clase de gráficos. No solo todo lo que escribí se hubiese vuelto obsoleto cinco veces a esta altura, sino que ¿en qué plataformas funcionaría? “

El autor concluye,

“Realmente hay algo para decir a favor de los estándares abiertos y las bibliotecas construídas sobre dichos estándares. [...] Si estás escribiendo algo que va a tener una vida útil más allá de un par de años, deberías considerar cuidadosamente las tecnologías de base que utilizarás para construirlo. No te distraigas con los términos marketineros o lo que esté de moda. Incluso si lo que estás escribiendo es código para descartar, escribirlo portable puede brindar oportunidades que de otra forma no existirían.”

Realmente algo para considerar.

Les dejo el link al artículo (en inglés).

En estos últimos días he estado trabajando sobre un renderer para un artículo que estoy produciendo para una importante revista de Linux. El renderer debía dibujar un campo de vectores discretizado, con dimensiones variables de 16×16, 32×32, 64×64 y hasta 96×96 (o más, dependiendo de la cantidad de memoria de video disponible).

Cada elemento en el campo de vectores es representado visualmente por un cuadrado (piensa en una baldoza) y una flecha (que representa la dirección). Cada cuadrado se forma con dos triángulos y cada flecha con tres, por lo cual para un campo de vectores de tan solo 16×16 estaríamos dibujando 1.280 triángulos, mientras que para un campo más grande de 64×64 estaríamos trabajando con un total de 20.480 triángulos.

Logo de PyOpenGL

La diferencia en desempeño fue increible. Con un mediano trabajo de refactoring logré obtener una aceleración que permitía redibujar la escena mucho más rápido, tanto más que no me alcanza el refresh rate del monitor para dibujar todos los cuadros que son generados por segundo.

Convertir el código de rendering de Modo Inmediato de OpenGL a VBO’s no fue tarea sencilla sin embargo. El problema fundamental consistió en que para trabajar con VBO’s se deben realizar transferencias de porciones de memoria RAM a buffers en memoria de video, por lo cual es necesario realizar un manejo bastante importante de punteros. Manejar punteros no es problema desde un lenguaje como C o C++, pero se puede llegar a complicar cuando se está trabajando en Python.

El primer problema consistía en convertir las listas de vertices y colores de listas Python a arrays contínuos en memoria. Para esto (y mucho a mi pesar) debí utilizar NumPy.array, lo cual solucionó el problema, pero al costo de agregar una nueva dependencia al código: numpy. Lo bueno es que teniendo un NumPy array, resulta sencillo generar los tipos adecuados para que los datos lleguen correctamente a la memoria de video. El siguiente snippet muestra la llamada a la función de copia de memoria:

from OpenGL.GL import *
from OpenGL.arrays import ArrayDatatype as ADT
import numpy
...
array = numpy.array(vertices_and_colors, dtype=numpy.float32)
glBufferData(GL_ARRAY_BUFFER, ADT.arrayByteCount(array), ADT.voidDataPointer(array), GL_STATIC_DRAW)

El segundo problema que tuve consitió en cómo indicarle a PyOpenGL los offsets dentro del buffer. El buffer de memoria que estoy utilizando está cargado tanto con datos de vértices como de colores, por lo cual debía poder especificar dónde empiezan los vértices y dónde empiezan los colores (en offset de bytes) a la API. Si bien esto parecía sencillo utilizando ctypes, se complicó bastante debido a un bug en PyOpenGL 3.0. La solución fué descargar el código de la Beta de PyOpenGL 3.0.1, compilarlo y hacer uso de ésta biblioteca en vez de la versión disponible en los repositorios de Ubuntu y Macports (actualmente ambas presentan este bug).

Una vez actualizada la biblioteca, crear un puntero genérico (void *) resultó trivial, como se muestra a continuación.

from ctypes import c_void_p
...
glColorPointer(3, GL_FLOAT, 0, c_void_p(colors_offset))

Quiero mencionar que cuando escribí en la lista de usuarios de PyOpenGL preguntando por este último problema, quien me respondió que en realidad se trataba de un bug en la biblioteca no fué ni más ni menos que el autor de la misma (!)