XNA Demos (IV): reduciendo la carga del Pixel Shader con un Z-Prepass

descargar_codigo

Si el ejemplo anterior trataba sobre la complejidad geométrica de una escena, en éste se va a explicar un método para reducir el trabajo que tiene que realizar el raster a la hora de aplicar los Pixel Shaders.

Normalmente, el bucle de dibujado de una escena consiste en recorrer todos los objetos (si son completamente opacos no hace falta ordenarlos de más lejano a más cercano) y ejecutar las instrucciones de dibujado de cada uno. La GPU recibe todos los datos, descompone las formas complejas (rectángulos, triangle strips, triangle fans) en triángulos sencillos y ejecuta los siguientes pasos por cada uno:

diagrama_rasterProceso de raster, simplificado.

Por lo tanto, en el mismo momento en que se determina que un triángulo o vértice es visible (pasar el Z-Test), se procede a actualizar su profundidad en el Z-Buffer (sobrescribiendo los valores antiguos) y se rasterizan todos los píxeles afectados por la nueva geometría.

depthZ-Buffer (también llamado Depth Buffer) con la profundidad de la escena.

Pero esta implementación, aunque es completamente correcta y lógica, tiene un punto débil: en una escena ordenada de más lejano a más cercano (o, si no lo está, también pueden darse las condiciones necesarias desde determinada posición y ángulo), cada objeto dibujado superpone al anterior; de esta manera, todos los objetos pasarán el Z-Test y serán enviados al raster. Si los Pixel Shader de los objetos tienen un número elevado de instrucciones, se estará desaprovechando una buena parte del trabajo de la GPU en dibujar píxeles que más tarde serán ocluidos; para evitar esta pérdida de rendimiento, vamos a implementar una técnica llamada Z-Prepass.

El Z-Prepass es un algoritmo muy sencillo, en el que se dibuja toda la escena dos veces; aún teniendo el doble de coste geométrico, el ahorro de trabajo en los Pixel Shader suele compensar ésta desventaja. Los pasos a seguir son los siguientes:

  1. Paso previo:
    1. Activar el Z-Test (RenderState.DepthBufferEnable = true).
  2. Z-Prepass:
    1. Activar escritura en Depth Buffer (RenderState.DepthBufferWriteEnable = true).
    2. Desactivar escritura en canales de color (RenderState.ColorWriteChannels = ColorWriteChannels.None).
    3. Dibujar escena con el shader de Z-Prepass.
  3. Escena final:
    1. Reactivar escritura en canales de color (RenderState.ColorWriteChannels = ColorWriteChannels.All).
    2. Desactivar escritura en Depth Buffer (RenderState.DepthBufferWriteEnable = false).
    3. Dibujar escena con los shaders correspondientes.

Los cambios de estado de ColorWriteChannels no son explícitamente obligatorios, pero ayudan a ganar algo de rendimiento; debido a que la única funcionalidad que nos interesa del shader especial de Z-Prepass es la transformación de los vértices y que la GPU rellene el Depth Buffer, no nos importa descartar la información de color pues no le vamos a dar utilidad ninguna.

Así pues, contando con un Z-Buffer pregenerado, en el segundo pase de geometría, y al estar desactivada la escritura (sólo se comprueban los valores), sólo se rasterizan los píxeles estrictamente visibles, evitando el redibujado de partes ocultas. Además, existe hardware (como la XBOX 360 y algunos modelos de tarjetas gráficas) optimizado para ejecutar un Z-Prepass con la mayor eficiencia posible.

Por último, queda aclarar que el Z-Prepass no es la panacea ni una solución universal; su mayor ventaja es aplicarlo a escenas en las que el trabajo de los Pixel Shaders puede ralentizar el proceso de render en general, debido a que ejecutan un gran número de instrucciones (normal mapping, übershader, sombras con PCF). En los peores casos se puede llegar incluso a perder rendimiento, debido a que el coste de dibujar la geometría dos veces es mayor que el de rasterizar toda la escena.

XNA Demos (III): Simulación de geometría con impostores

descargar_codigo

Aunque hoy en día las GPUs ganan rendimiento a pasos agigantados, la evolución de los gráficos por computador (no olvidemos que muchos de los efectos y técnicas que ahora se usan en tiempo real estaban limitados a un uso precalculado hasta no hace mucho) se adapta a estos cambios y los explota al máximo, y más aún desde el abandono de la FFP y el advenimiento de los shaders.

Una de las limitaciones que más rápidamente se alcanza es la complejidad poligonal de la escena. Teniendo en cuenta que la GPU tiene que transformar la posición de cada vértice a coordenadas de pantalla, interpolar los valores (posición, normal, coordenadas de textura) al resto del triángulo, y por último rasterizar los fragmentos visibles (aplicando los efectos de shader correspondientes), tener una escena de un millón de polígonos y querer moverla con un refresco decente (60+ Hz) sigue siendo un suicidio. Por ello, hay que recurrir a técnicas de simplificación, como puede ser el frustrum culling, para eliminar objetos fuera del campo de visión de la cámara, o, como se muestra en el ejemplo, simplificar el dibujado de los mismos.

Uno de los métodos más empleados es el Level-Of-Detail, o LOD. Ésta técnica consiste en disponer de varias copias de un mismo modelo, en las que se ha ido reduciendo el nivel de polígonos (mediante un programa de modelado) progresivamente. Dependiendo de la distancia del objeto a la cámara, se dibuja una versión con mayor o menor detalle, procurando que el tamaño final del objeto en pantalla compense los posibles errores del modelo (partes deformadas, texturas mal alineadas, etc.).

comparacion_lod

Izquierda: ~10000 polígonos. Derecha: ~4000 polígonos.

Pero cuando el LOD no es suficiente (cientos o miles de instancias de objetos al mismo tiempo) y el mesh instancing tampoco da buenos resultados, se recurre a un “truco”: los impostores. Un impostor es un sprite orientado siempre hacia la cámara (algunas veces con un eje de rotación restringido, para evitar resultados poco realistas debido a deformaciones), y que contiene una imagen del modelo visto desde un ángulo determinado.

tira
Los sprites usados para los impostores del ejemplo.

Dependiendo de la forma y uso de los impostores, podremos generar más o menos proyecciones del model, dependiendo del grado de realismo que queramos alcanzar. En el ejemplo se han generado 8 vistas de 128×128 píxeles, con una diferencia de 45º de rotación entre ellas; dependiendo de la orientación de la cámara, se dibujará una u otra para simular la existencia de un objeto tridimensional en la escena, como muestra el esquema siguiente:

diagrama
Sprite empleado dependiendo de la orientación de la cámara y el objeto.

Por último, queda aclarar que los impostores no siempre son la solución; si la diferencia de altura entre el objeto y la cámara es muy grande, se puede producir (debido a la restricción de ejes en el impostor) una distorsión que arruinaría todo el realismo de la escena:

image
Distorsión de los impostores al verlos desde un ángulo muy inclinado.

XNA Demos (II): Reflexiones en tiempo real con cubemaps

descargar_codigoUno de los efectos más buscados en los videojuegos desde la transición del género a las 3D ha sido la posibilidad de generar reflexiones (como espejos o superficies metálicas) de una manera realista y convincente. Debido a la poca flexibilidad del renderizado por raster (sólo se dibujan los píxeles visibles por el volumen generado a partir de las matrices de vista y proyección), siempre se ha recurrido a “trucos” para simular el efecto. Por ejemplo, los motores con geometría basada en CSG aprovechan el uso de los portales para, creando una máscara mediante el uso del stencil buffer, redibujar los objetos visibles tal y como se verían reflejados.

Con el aumento de la potencia de las GPUs y el abaratamiento de la VRAM, se ha optado por utilizar un tipo especial de textura llamado “cubemap”, que como el nombre indica, almacena las 6 caras de un cubo. De esta manera, se puede representar todo el entorno que rodea a un punto determinado, y se pueden crear offline (con un editor gráfico, para dibujar por ejemplo un skybox que dé profundidad a la escena) o en tiempo de ejecución.

cubemapCubemap estático de la demo, reescalado

Uno de los motores que más emplean el uso de cubemaps es Source, si bien los utiliza sólo en su versión estática; al compilar un mapa, y mediante un comando especial, se ordena que se generen los cubemaps en determinados puntos designados por el diseñador. El problema de este método es que las reflexiones sólo mostrarán los objetos estáticos del mapa, así que si creamos una superficie totalmente reflectante y situamos al jugador delante suyo, no habrá cambio alguno.

Un método más realista es actualizar los cubemaps dinámicamente, para que reflejen todos los cambios de la escena. Sin embargo, éste método también tiene sus desventajas: hay que dibujar la escena 7 veces (una por cada cara del cubemap y otra para el resultado final), así que hay que pensar en métodos para rebajar la carga: usar sólo un cubemap dinámico al tiempo, actualizar únicamente 2 caras a cada frame…

Por último, la demo también incluye un efecto de refracción, con una constante de transmisión del medio de 0.66, para simular vidrio. La única diferencia entre los dos shaders es la instrucción usada para calcular el vector que se empleará para obtener el téxel del cubemap, que en un caso es reflect y en el otro refract.

reflex_refract Vectores de reflexión y refracción.

01/01/2010: actualizado el código para mejorar el rendimiento del Cubemap dinámico.