Si eres una persona a la que le gustan los videojuegos o simplemente te interesan los gráficos por ordenador en alguna ocasión te habrás encontrado con estas palabrejas en inglés que ni yo mismo entiendo muy bien aún. Es mi intención pues y hasta donde llegan mis limitaciones, explicar un poco qué significa esto y a ver si algunos se dan cuenta que esto de hacer aparecer cosas por pantalla no es sólo cosa de hacer click en un simple botón.

Pero, ¿qué es el deferred shading? Vamos al grano: a la hora de hacer aparecer nuestras “cosas” por pantalla existen un sinfín de técnicas y aproximaciones de otras técnicas. Una de ellas es el deferred shading, que a su vez puede ser interpretada de otras tantas maneras. Ahí está la diferencia entre juegos o aplicaciones 3d con gráficos malos, buenos e increíbles. No se me mal interprete con que el deferred shading excluya otras técnicas.

Sin meterme en historias de quién fue el inventor del concepto (para eso tenéis la Wikipedia), sí voy a comentar que su empleo llega de la evolución del hardware (tarjetas gráficas más modernas) que permitió su implementación de manera óptima gracias al MRT (multiple render target).

El deferred shading consiste en hacer un dibujado previo por separado de la información que necesitamos para la obtención final de la imagen. A diferencia del forward rendering (dibujamos directamente, uno a uno los objetos por pantalla). Es decir, en lugar de dibujar en pantalla lo que queremos, primero vamos a ir guardando en texturas (imágenes) la información de los objetos por separado y al final de todo el proceso lo combinamos.

Así pues, en un primer paso, se crea el G-Buffer que no es más que un grupo de texturas en donde se guarda la información que vamos a necesitar. Como el color, la posición de cada pixel en el espacio, la capacidad de reflejar la luz del material, etc.

En la siguiente foto muestro un ejemplo de un G-Buffer con composición final de una oclusión realizada aquí en BITTIA:

Como se puede ver tenemos 3 primeras texturas (imágenes pequeñas de la parte superior) con diferente información, color, dirección de las normales (dirección a la que mira el pixel) y distancia a la cámara representado en escala de grises. Esto último es como decir la posición x, y, z del pixel en el espacio obtenido mediante cálculos matemáticos que no me voy a poner a explicar. Pues bien, con ellas (en realidad sólo con las dos últimas) podemos generar una especie de sombreado (SSAO) que combinado con el color nos daría más realismo a la escena.

Esto es un simple ejemplo de uso del G-Buffer, será cosa de la imaginación de cada uno o del equipo de desarrollo del juego o aplicación lograr las impresionantes escenas cinematográficas que obtienen en sus costosos y multimillonarios proyectos.

Un punto muy a favor que tiene el deferred shading es a la hora de calcular las luces de la escena, permitiendo tener en un mismo momento cientos (esto tengo que testearlo, aún no me lo creo a excepción de que poseas un super-ordenador, yo lo dejaría en muchas más) de luces dinámicas funcionando mientras que en el forward rendering no es posible.

Como se puede observar el proceso que hemos de realizar a la hora de enseñarte algo por pantalla es muy grande, largo y costoso. Pasa por un montón de manos y NO ES NADA hasta que el último pintor da la última capa. De ahí la importancia en conocer la labor de cada uno de los miembros que intervienen en el proceso.

Documentación empleada:

http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf

http://cmpmedia.vo.llnwd.net/o1/vault/gdc09/slides/gdc09_insomniac_prelighting.pdf

http://developer.amd.com/gpu_assets/S2008-Filion-McNaughton-StarCraftII.pdf

La técnica de realidad aumentada nos permite incorporar objetos tridimensionales en un entorno real, uniendo la realidad con la ficción en la pantalla de nuestro monitor. Pero no es todo tan bonito.

A simple vista, cuando vemos un objeto sobre nuestra mano en un entorno de realidad aumentada da la impresión de que está sobre nuestra mano y es un efecto que, según el caso, puede resultar impresionante, pero el problema aparece cuando, por ejemplo, tenemos una “vaka” que vuela de un lado a otro de lo que nuestra webcam está “observando”.

Hagamos un stop para explicar, muy por encima, el proceso de dibujado en una aplicación de realidad aumentada:

Por un lado tenemos la imagen de la webcam que es lo que se dibuja en primer lugar, es decir, si fuera Photoshop, sería la primera capa de nuestro psd o foto.

Después, tenemos los objetos 3D que hemos de dibujar también y que corresponden a la segunda capa de nuestra foto. ¿Qué significa esto? Pues que siempre, siempre, tendremos los objetos 3D por encima de la imagen de la webcam.

Y e aquí la clave del asunto, nosotros no podemos conocer verdaderamente el entorno tridimensional que rodea a “LaVaka”, pero, dado un objeto conocido y su posición, podemos hacer una máscara de él (en este caso el brick de Central Lechera Asturiana) para simular que un objeto real de la vida misma está por delante de nuestro objeto ireal de la realidad aumentada.

Para muestra un botón:

Como se puede ver, no podemos conocer que hay una mesa que “choca” con nuestra compuerta, pero si conocemos la existencia de nuestro brick y que hemos modelado previamente. De este modo podemos hacer nuestra máscara para que “LaVaka” quede oculta en caso de volar por detrás del brick.

Seguro que hay un montón de métodos para hacer esta máscara, pero yo voy a comentar el empleado en este caso, por su facilidad de aplicación y su “escasa” necesidad de emplear líneas de código, además de la aportación que nos da la aceleración gráfica.

Como muchos sabrán, las gráficas nos permiten hacer “miniprogramitas” que van a ser ejecutados cuando dibujamos un pixel por pantalla. Es decir, si yo tengo un brick modelado en 3D con un color o una textura, etc. puedo decirle a la gráfica que cuando dibuje ese pixel concreto del brick antes de ponerlo por pantalla ejecute mi pequeño programita que va a modificar el color de ese pixel.

A ese programa se le llama Shader y es el encargado de modificar el color de ese pixel para sutituirlo por el color que yo le diga. De este modo le digo a la gráfica que cuando dibuje el pixel blanco del brick lo sustituya por el color del pixel de la webcam.

Así pues y con Shader Modelo 3 que tiene una estructura que nos facilita muchísimo la vida, podemos hacer esta máscara sin despeinarnos.

Esta estructura es la VPOS y nos da las coordenadas x e y del pixel que se está dibujando en ese preciso momento, con esa información y un pequeño cáculo de proporciones podemos sustituir la textura original del brick por la imagen de la webcam, de este modo, ya conseguimos el efecto deseado. La definimos de la siguiente manera:

struct PS_INPUT
{
float2 coord : VPOS;
};

Básicamente el pixel shader es tan simple como esto:

Realizamos el cálculo de proporciones para obtener el pixel que queremos dibujar :

IN.coord.x = IN.coord.x * webcam.x / screen.x;
IN.coord.y = IN.coord.y * webcam.y / screen.y;

Donde coord. es el pixel que se está dibujando y webcam/screen es la proporción entre la resolución de la webcam y el del monitor.

Esta coordenada obtenida tenemos que transformarla a un número entre 0 y 1 que será la que la gráfica entienda, y “cogerlo” de la textura de la webcam.

tex.x = IN.coord.x / 1024;
tex.y = IN.coord.y / 512;

En este caso mi textura es de 1.024×512.

Y sólo queda pedir el color del pixel de la textura que este caso es la imagen de la webcam:

float3 Color = tex2D(baseMap,tex);

y, finalmente, le decimos a la gráfica que dibuje el pixel con el color obtenido.

return float4(Color,1);

Para explicar qué es exactamente hay que entender que el monitor de nuestro ordenador no dibuja al instante una imagen en pantalla sino que hace un recorrido trocito a trocito hasta que completa la imagen que tiene que mostrar. Es por ello que si estamos dibujando un círculo y el ordenador aún no ha terminado de rellenar la pantalla, éste ha de ser redibujado otra vez sin terminar el ciclo correctamente provocando un pantalleo indeseable en la imagen.

¿Cómo solucionarlo?

Hace unos cuantos años, en la época en que se accedía directamente a la memoria gráfica, la época de esos maravillosos juegos de 256 colores, este tema se solucionaba de varias maneras:

Desde MS-DOS, donde se tenía acceso a todo, registros del ordenador, secciones de memoria… lo que se solía hacer era un bucle que comprobaba cuando el monitor terminaba de dibujar y, una vez terminado, se continuaba dibujando. Qué tiempos…

Más tarde se usó el concepto de doblebuffer, que consistía en dibujar todo en una “segunda” capa y, después, se copiaba o sustituía por la que usa el monitor para dibujar en pantalla. Actualmente, este concepto es el mismo, con la diferencia de que ya es totalmente abstracto para nosotros y cuando utilizamos algún motor gráfico no nos damos cuenta de lo que en verdad está haciendo para ver la imagen correctamente.

Como tenemos potencia de raster suficiente pues nada, que más da…

Mi opinión sobre la v-sync es clara, siempre activada a menos que lo que estemos viendo sea lento (donde si se podrá desactivar), como una postal o unas diapositivas etc., pero, en juegos, la única ganacia que podemos obtener es cierta mejora en la fluidez, que no en la imagen, y esa fluidez está relacionada con esos indeseables pantalleos por lo que a mí, personalmente, no me gusta.