No están todos, cada semana tres capítulos nuevos, así nadie se atraganta

Relacionadas: gpu gems online

A mi me han gustado especialmente, sin ningún orden específico:

Multi-threading made easier through Open-Source Threading Building Blocks

Task stealing: cuando un core real se queda sin tareas “roba” a otro una tarea para maximizar el throughput

Después de hacer una extensa introducción sobre paralelismo, paralelismo sobre datos, paralelismo funcional, etc… muy orientado a videojuegos (bien!) nos presenta Threading Building Blocks(TBB), una librería brutal, open-source y multiplataforma, de la mano de intel.

La parte novedosa de usar TBB es que está orientado a tareas (task patterns), no a programar threads (hilos) como tal. Programar tareas hace que, teóricamente, el diseño escale automáticamente según el número de cores que tenga nuestro procesador. TBB es para C++, y está hecho para C++, por lo que usa plantillas para definir concurrent-containers (hash, queue, vector, ..), algoritmos paralelos (sort, for, while, reduce, …), tiene también un patrón “pipeline” para poder encadenar tareas, scalable-memory-allocators (para evitar sincronizaciones entre tareas al reservar memoria), etc.

Otra razón para usar tareas es que es fácil debuggear, ya que por diseño, puedes limitar todo a un single thread y depurar, una vez todo funciona puedes lanzarlo en multithread con casi todas las garantías de que va a funcionar.

En general TBB está muy bien montado. No se si se nota las ganas que tengo de usarlo

To hardcode or not – considerations about an ultimate demotool

Motor de render picoEngine, integrado dentro de Maya como plugin. Escena de la última demo de plastic: Linger in Shadows

¿ hardcodear demos ó demotools ? Evolución de plastic desde sus primeras demos hardcodeadas a los plugins y editores que ahora usan para diseñar demos. Por lo visto tienen su motor de render (picoEngine) integrado como un plugin del editor que usen (Maya en este caso), y un editor de escenas para ajustar timelines, velocidad, etc.

Definitivamente para plastic el enfoque está muy cerca del artista, aunque reconocen que cierta funcionalidad es más cómoda de implementar en código que diseñarla con un editor.

Tonite let’s all make demo in Bingen

La demo cuenta una historia, tiene un flujo y los efectos de transición, no son tales, si no que se integran en ese flujo conectando una escena con la siguiente, suavemente.

Vemos la otra cara de la moneda, para ASD lo principal es el código como herramienta y defienden que muchos de los efectos y transiciones no se podrían hacer con comodidad en un demoeditor. Por otro lado, como con plastic, no todo es blanco o negro.

Empieza con las razones por las que no hacemos demos ( me ha gustado eso de : “19% estamos intimidados por Farbrausch” ) y cómo las hacen en ASD. Básicamente: librería sencillita en C++, soporte básico para manejo de shaders y texturas, sin engine para animaciones, sistemas de partículas adecuados, scripting para los eventos y funciones de cámara imaginativas.

Desmitifican el “hacer una hardcoded demo es más difícil” y explican paso a paso como organizan sus demos. Detallan cómo organizan las escenas, efectos y las transiciones (aunque las transiciones de ASD son para dar de comer aparte).

Del motor de partículas destacan que es una pérdida de tiempo el típico bucle de actualización de partícula por frame, ya que en el 95% de los casos, las partículas se comportan de forma determinista por lo que se puede calcular su path previamente.

También es interesante cómo ajustan los detalles de las escenas, utilizando rands, y semillas asociadas a eventos de teclado y ratón para encontrar algún estado que quede bien en la demo (mola!!!).

Las cámaras tienen solo un par de movimientos, elípticos y lineales, interpolados con s-curves, simple y controlable.

El resto es filosofía de diseño, muy, muy interesante.

When there’s smoke there’s fire

¡¡ Ruido, y más ruido !!

Una presentación de nvidia muy asequible para el público en general sobre generación procedural y cálculo en la GPU. Explica con muchísimo detalle perlin noise para modelado de partículas, al margen del uso que hagan la explicación por si sola ya merece la pena.

Después continúa con la evolución del perlin noise hacia el Simplex noise y cómo usarlo, acabando con notas sobre el sampleado del ruido para conseguir los mejores resultados.

La segunda parte de la charla trata sobre cómo renderizar humo. Empieza por la composición del humo en la escena (esta es la parte fácil y similar con la primera parte de la charla). Después comenta cómo calcular la simulación de fluidos en la GPU y añade cómo detectar las colisiones con geometría de la escena (pasándola a un volumen).

La serie GPU gems se compone de artículos independientes que analizan problemas muy particulares. Son amenos de leer y no se centran únicamente en los gráficos, también exploran otros usos de la GPU o cuestiones de diseño muy prácticas para los programadores que estén trasteando con motores de render .

En esta entrega encontraremos:

• Efectos naturales
• Iluminación y sombras
• Materiales
• Procesado de Imágenes
• Rendimiento y Diseño
• Cálculo general en la GPU

Aunque aun faltarán tres documentos que wget no descubre que hace falta bajar

cd opengl2/xhtml
wget http://www.opengl.org/sdk/docs/man/xhtml/pmathml.xsl
wget http://www.opengl.org/sdk/docs/man/xhtml/ctop.xsl
wget http://www.opengl.org/sdk/docs/man/xhtml/mathml.xsl


PD: También podría dejar colgado un tgz con todo, pero no estoy seguro de si es legal o no, de esta forma cada uno se lo hace por su cuenta y riesgo. Realmente lo interesante es que quien no haya usado wget para hacer un mirror de una página por lo menos ya sabe que se puede.

Típicamente en el mundillo de los gráficos desde tiempos inmemoriales se ha venido usando un set de librerías conocido por DevIL ( que inicialmente se llamaba OpenIL aunque por problemas con SGI cambiaron el nombre). Esta librería es además de práctica muy sencilla de utilizar y entona muy bien con openGL por estar basada en una máquina de estados y estar separada en varios niveles de abstracción IL, ILU, ILUT (como GL, GLU, y GLUT).

Pero si queremos usar algo más potente de DevIL podemos usar ImageMagick. Con ImageMagick ganaremos no sólo un cargador, además ganamos un editor, compositor y conversor de imágenes con la ventaja de que ImageMagick probablemente ya viene instalada en las ubuntu/debian/*nix normales ( y si no viene, sólo hay que enseñar a usar convert o cualquiera de las command-line-tools de ImageMagick ).

Veamos un breve, rapidísimo tutorial de cómo cargar una imagen con Imagemagick. Vamos a usar la interfaz “C” de magick-wand, también existe una para C++ (así como para python, perl, php,…) pero implicaría tener que añadir una dependencia extra… y la verdad es que Magick-Wand es suficientemente fácil de usar por sí misma.


#include <wand/magick_wand.h>
int main(...) {
MagickWandGenesis();
MagickWand *wand = NewMagickWand();
// ...
wand = DestroyMagickWand(wand);
MagickWandTerminus();
}


Las llamadas MagickWandGenesis y MagickWandTerminus inicializan y finalizan la librería, una vez hecho con NewMagickWand y DestroyMagickWand podemos crear y liberar varitas (mágicas) para trabajar con imágenes, transformalas, etc… Lo siguiente consiste en cargar la imagen de un fichero o un BLOB de memoria:


// opcion 1: leer de fichero dado un path
MagickBooleanType status = MagickReadImage ( wand, path );
// opcion 2: leer de un puntero a memoria (data) de tamaño conocido (size)
MagickBooleanType status = MagickReadImageBlob( wand, data, size );
if ( status != MagickFalse )
{
}


Las dos llamadas de MagickReadImage[Blob] hacen lo mismo, leen una imagen y además lo hacen identificando el tipo de imagen que es. Esto lo digo concretamente por la versión “blob”, no hay que decirle si es un png, jpg, ppm, svg… Imagemagick lo identificará por la cabecera del fichero, si usáis vuestro propio cargador de ficheros no tenéis más que leer el fichero entero sin preocuparos del tipo de fichero y MagickReadImageBlob intentará leerlo.
También existe la versión MagickReadImageFile que recibe un descriptor de fichero tipo FILE*
nota: en vuestro caso particular sólo hay que usar una de las dos opciones, claro está

El resultado es un booleano, si todo a ido bien sólo queda recuperar esa información y subirlo a la textura. En este caso vamos a tener en cuenta si la imagen tiene alfa o no (para ImageMagick es ver si tiene opacidad):


unsigned long width = MagickGetImageWidth( wand );
unsigned long height = MagickGetImageHeight( wand );
unsigned char *data = 0;
MagickFlipImage( wand );
// reservamos para una textura y la activamos
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
if ( MagickGetImageChannelDepth(wand, OpacityChannel) > 1 )
{
// con alfa
data = new unsigned char[width*height*4];
MagickGetImagePixels(wand, 0,0, width, height, "RGBA", CharPixel, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
}
else
{
// sin alfa
data = new unsigned char[width*height*3];
MagickGetImagePixels(wand, 0,0, width, height, "RGB", CharPixel, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, data);
}
delete[] data;


Este ya es un buen cacho, primero obtenemos ancho y alto de la imagen, hacemos un flip de la imagen (ya que en OpenGL las imágenes empiezan abajo a la izquierda – pitfall 12) y reservamos una textura de OpenGL. Después preguntamos a la varita si la imagen tiene alfa, en realidad le preguntamos si la profundidad del canal de opacidad es mayor que 1, si es así reservamos espacio para guardarnos la información de la imagen en formato RGBA y lo subimos a la textura. Si no tiene alfa pues lo mismo pero en formato RGB. Y como somos muy limpios, al final un delete[] para liberar la memoria temporal donde guardamos la imagen.

Y finalmente el ejemplo más o menos completo del tema… Para compilarlo en linux no hay que olvidar que tenemos un mágico `Wand-config --cppflags --cflags --ldflags --libs` para ayudarnos.


#include <GL/gl.h>
#include<wand/magick_wand.h>
int main(...) {
// inicializamos openGL o lo que haga falta...
GLuint texture = 0; // nuestra textura
MagickWandGenesis();
MagickWand *wand = NewMagickWand();
// opcion 1: leer de fichero dado un path
MagickBooleanType status = MagickReadImage ( wand, path );
// opcion 2: leer de un puntero a memoria (data) de tamaño conocido (size)
MagickBooleanType status = MagickReadImageBlob( wand, data, size );
if ( status != MagickFalse )
{
unsigned long width = MagickGetImageWidth( wand );
unsigned long height = MagickGetImageHeight( wand );
unsigned char *data = 0;
MagickFlipImage( wand );
// reservamos para una textura y la activamos
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
if ( MagickGetImageChannelDepth(wand, OpacityChannel) > 1 )
{
// con alfa
data = new unsigned char[width*height*4];
MagickGetImagePixels(wand, 0,0, width, height, "RGBA", CharPixel, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
}
else
{
// sin alfa
data = new unsigned char[width*height*3];
MagickGetImagePixels(wand, 0,0, width, height, "RGB", CharPixel, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, data);
}
delete[] data;
}
wand = DestroyMagickWand(wand);
MagickWandTerminus();
}


Glee cargará por ti dinámicamente aquellas extensiones que soporte tu tarjeta, sólo hay que tener en cuenta que aunque estés progrmando contra el API de OpenGL 2.1, es posible que tu tarjeta NO soporte ciertas llamadas, o ciertos formatos… las comprobaciones de las capabilities de la tarjeta se tienen que seguir haciendo ( en tiempo de ejecución ).

En resumen, el que prueba esta librería no vuelve a complicarse la vida con las extesiones de OpenGL.

Desde: OpenGL.org

La respuesta es: tiene consecuencias (y graves). ¿Cómo hacer que OpenGL vaya mucho más deprisa? para averiguarlo podéis ver este video de la última Blender Conference. Este video nos viene a contar desde qué punto de vista hemos de enfocar el uso de OpenGL hoy día, ya que el hecho de poder programar como hace 10 años no justifica el hacerlo teniendo en cuenta la penalización que eso supone.

Me ha gustado tanto que intentaré desglosar su contenido en pequeños posts, por si alguien tiene dificultades con el inglés.
Noticia original OpenGL performance programming.