Forward+ para torpes.

Esta entrada es como fundamento teórico para una entrada que haré más adelante.

¿Que es el Forward +? para ello tenemos que especificar lo que es el Renderizado hacía adelante (Forward Rendering) y el Renderizado por diferido (Deferred Rendering).

Lo que habitualmente llamamos Forward Rendering es la forma clásica de dibujar una escena:

forward-v2

 Aquí se encuentra una buena explicación a como funciona:

Los caros cálculos para la iluminación se tienen que ejecutar por cada fragmento visible de cada polígono en pantalla, independientemente si este esta por encima de otro o escondido por el fragmento de otro polígono. Sí tu pantalla tiene una resolución de 1024*768 (la cual no es una resolución muy alta) entonces tienes casi 800.000 pixeles que necesitan ser renderizados/dibujados. Tu puedes alcanzar rápidamente un millón de operaciones de fragmentos por fotograma. También, muchos de los fragmentos no aparecerán en pantalla por el hecho que serán eliminados con un test de profundidad, por lo que el cálculo de la iluminación se ha gastado inútilmente en ese caso.

Sí tienes un millón de eso fragmentos y de repente tienes que renderizar esa escena otra ves por cada luz, ¡entonces darás el salto a [num of lights] x 1,000,000  de operaciones de fragmento por fotograma! Imagina si tienes que renderizar una ciudad llena de luces donde cada una de ellas es una fuente de luz…

La formula para estimar la complejidad en Notación Big O.notation , es: O(num_fragmentos_geometricos * num_luces).  Puedes ver aquí como la complejidad esta directamente relacionada con el número de geometrías y el número de luces.

Los Fragmentos son potenciales pixeles que terminarán en la pantalla si no son recortados por un test de profundidad. Ahora, algunos motores optimizan esto eliminando las luces que están muy lejos, combinando luces o usando mapeados de iluminación (muy populares, pero estáticos). Pero si tu quieres iluminación dinámica y montones de ellas, entonces necesitamos una mejor solución.

La solución a ello es retirar el cálculo de la iluminación de lo que es el cálculo de la geometría de la escena por lo que el número de polígonos en pantalla no se relacione con el número de fragmentos geométricos en pantalla, esta solución es el Deferred Rendering:
deferred-v2
Se le llama renderizado por diferido por el hecho que en vez de utilizar un solo búfer de imagen se utilizan varios, uno por cada componente de información del pixel y luego se le aplica la iluminación de la escena como último paso.
Captura de pantalla 2014-10-26 a la(s) 13.14.28
Estas se combinan en un búfer final:
Captura de pantalla 2014-10-26 a la(s) 13.15.58
El articulo que estoy citando dice así:
Conociendo lo alejado que esta el pixel y la normal de su vector, podemos combinar el color de ese pixel con la luz para producir nuestro render final.
¿Pero que dice exactamente el artículo que estoy citando para la explicación?

El Deferred Rendering es un planteamiento interesante que reduce la cuenta de los objetos, en particular la cuenta del total de fragmentos, y realiza los cálculos de la iluminación en los pixeles en pantalla, de este modo se utiliza el tamaño de la resolución en vez del número total de fragmentos.

La complejidad del Deferred Rendering en notación Big O es: O(resolución_pantalla * num_luces).

Como puedes ver no importa cuantos objetos tengas en pantalla para determinar cuantas luces utilizaras, así que puedes aumentar felizmente el número de estas.

Buscando información sobre lo que es el Forward+ me he encontrado con la siguiente presentación, en ella se puede ver de forma más clara la diferencia entre el computo matemático entre el Deferred y el Forward:

Captura de pantalla 2014-10-26 a la(s) 13.31.35

La ecuación del Forward+ es la siguiente:

Captura de pantalla 2014-10-26 a la(s) 13.33.41

Y su explicación simplificada esta:

Captura de pantalla 2014-10-26 a la(s) 13.37.06

Traducción:

Extensión del pipeline del Forward Rendering:

  • No se ve limitado por la cantidad de material (objetos en pantalla).

Extensión del pipeline del Deferred Rendering:

  • Mantiene la capacidad de utilizar múltiples luces.

Simplificando las cosas, el Forward+ es el hecho de aplicar la ecuación del Forward Rendering pero no por cada objeto en pantalla sino por cada pixel en pantalla por lo que el nivel de precisión visual aumenta. No obstante al contrario de lo que pueda parecer el tiempo de renderizado disminuye:

Captura de pantalla 2014-10-26 a la(s) 13.46.02

¿Como es que es más rápido? El motivo es que pese a que la ecuación es mucho más compleja lo que hace el Forward+ es disminuir la cantidad de veces que se escribe en memoria el resultado de algún búfer, ¿como? Reduciendo la cantidad de estos:

Captura de pantalla 2014-10-26 a la(s) 13.49.11

Y es aquí donde entra la otra parte de la explicación, hay una relación directa entre la tasa de relleno de un procesador gráfico (número de pixeles que puede dibujar) y el ancho de banda para la escritura y si tenemos en cuenta que en el renderizado por diferido cada vez que se escribe en un búfer entonces tenemos que la contrapartida del Deferred Rendering es la necesidad de un alto ancho de banda, cosa que el Forward+ soluciona disminuyendo la cantidad de veces que se escribe en memoria y por tanto se disminuye el ancho de banda necesario, aumentando así el rendimiento en un mismo sistema y con ello la velocidad de renderizado.

Eso es todo, hasta la siguiente entrada.

Anuncios