OpenGL cambia de look

Jodo, sigo leyendo las noticias de opengl.og y me encuentro con una burrada de cambios que se van a producir en opengl en el próximo verano:

- Dos nuevas releases para el verano. En resumen, si usas una implementación serás compatible con las viejas y nuevas tarjetas y con la otra solo podrás usar el nuevo hardware con la ventaja de poder usar todo su pontencia

- un SDK, que ya era hora. Hasta ahora yo me habia guiado con el redbook, la espec de opengl y la de GLSL, pero está claro que es necesario unificar y centralizar ,sacando algo similar al SDK de DX.

- cambios en el modelo de opengl. Al parecer el modelo usado para algunas cosas, como explica en la web, era una chapuza y estaban optimizadas para la creación y no para el render.

Estas son las más importantes según mi punto de vista y parece que todas cara a poder hacer frente a lo que está por venir en D3D. Todo orientado a facilitar las cosas y a poder optimizar para el hardware moderno.

Geometry Shaders con OpenGL

Hace bien poco salía la nvidia 8800 que promete que será capaz de tirar dx10. Entre tantas cosas, añade a su funcionalidad el tema de geometry shaders, esto es, shaders que permiten añadir vértices. Hasta ahora nos habíamos conformado con transformar los vértices que teníamos pero ahora es posible generarlos.

Y para qué leches quiere alguien generar vértices? Por ejemplo, imaginemos el caso de querer usar billboards. Tenemos la opción de usar fixed pipeline, transformando uno por uno los vértices de los quads para orientarlos a la cámara. Otra opción es usar un vertex shader, de forma que le pasamos un “quad” con los 4 vértices centrados en el centro del quad, luego en una coordenada de textura se le pasas el número de esquina y por último dos uniforms con los ángulos de cámara. Con simple trigonometría y un vector de vec3 en el que se haga lookup con el número de esquina se puede transformar el vértice. Con geometry shaders se puede, indicar que la entrada es un punto, la salida es un triangle strip y en el shader generar los 4 vértices a partir del primero, con el consecuente ahorro de cálculo en el VS y de transferencia de datos.

Este es un ejemplo, pero seguro que hay cosas mucho más útiles que eso :). Un buen tutorial lo he visto hoy en una noticia de hace 4 días en la web de opengl. Bien explicado, con sus gráficos de rigor. A ver que hace ATI (aka, quisquillosa con GLSL) ahora.

perrito

El otro día un compañero de trabajo apareció en la oficina con un perrito que estaba abandonado y que le estaba siguiendo. Como tenemos (aún) un poco de corazón le hemos acogido en nuestro seno, dándole cobijo, alimento y cuidado. Es un perrito la mar de juguetón, como viene siendo habitual cuando son cachorros, no parece que sea de raza definida, se le ve que está a falta de cariño y me imagino que nos lo quedaremos hasta que alguien lo adopte. Parece ser que en la protectora de animales únicamente se comprometen a meterlo con otros perritos y darlo de comer (que no es poco), pero preferimos mantenerlo unos días a ver si le podemos encontrar familia. De momento, y a a falta de un nombre mejor, le he bautizado como “jeta”.

STL: sí o no

Es muy común entre los que programamos en C++ el reinventar a menudo la rueda (incluso varias veces) y reprogramarse los contenedores básicos él mismo. Se suelen escudar en cuestiones de legibilidad de código, sobrecarga de llamadas, rapidez de ejecución. Es cierto que muchas veces es necesario tener muy claro como funciona algo, sobretodo con algortimos críticos sin embargo hay una serie de pros que me hacen decantarme por el uso de STL:

- efectividad: ganas tiempo en no tener que programar y hacer debug de tus contenedores. Además sabes que hay muchas más personas usándola y tienes cierta seguridad cuando las usas.

- rapidez de ejecución: es posible que tus contenedores sean más rápidos, pero en el tiempo que has usado para programarlos es posible que invitiéndolo en otros algortimos hubieras ganado más ciclos de cpu (o gpu :P).

- trabajos en equipo: cuando se trabaja en equipo es muy ventajoso que todo el grupo conozca muy bien las cosas básicas del código sobre el que se trabaja. Además casi nunca se suele estar de acuerdo en como deben funcionar los contenedores.

- Los iterators: te dan una versatilidad para cambiar de contenedor y trabajar con los mismos algortimos sobre cada uno bastante alta y que da aporta mucha efectividad a la hora de programar

pero también hay contras:

- No te evitas bugs… pero tampoco te libras de ellos si los programas tú. Por ejemplo hacer std::vector< std::vector > en algunas versiones de gcc (con la STL de GNU) tiene un bug.

- Código muchas veces ilegible, con lo cual hace difícil saber qué hacen exactamente.

- Múltiples implementaciones. Por un lado tienes la que traen por defecto los compiladores, STL de SGI, STL port. No es que sea un gran problema, pero hay contenedores y algortimos diferentes, ciertos detalles internos, etc.

- Los iterators: a algunos programadores les resulta engorroso tener que usar, por ejemplo, un iterator para eliminar un elemento de un std::vector

En resumen, para mi, STL sí, porque prefiero usar mi tiempo en crear algortimos diferentes a los de toda la vida, aunque creo que todo programador debería saber como implementar una lista enlazada o un vector. Tú que opinas?

La fiesta empieza en Gameloft

Leo en khronos que gameloft anuncia en una nota de prensa que va a usar OpenGL ES en uno de sus juegos y que además lo va a endosar en un móvil con aceleracion.

Me hace gracia como vende la moto el presidente de Gameloft, más que nada porque existen juegos 3D hace siglos, no creo que porque veamos juegos 3D en dispositivos móviles vaya a ser la revolución aunque si funciona bien gameloft, entre tantas, se puede forrar a base de bien. El problema es que un juego 3D requiere mucho más trabajo que uno 2D (y por tanto mayor coste de producción) y no sé si saldrá tan rentable.

Por suerte OpenGLES es muy similar a OpenGL y los programadores de PC no creo que tengan problemas en reconvertirse, con lo cual la experiencia acumulada para PC siempre se puede aprovechar. A ver que va saliendo.