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.