Deferred Rendering, Crytek 3D pixel reconstruction

[Prompt]

Bueno, hoy por fin he conseguido terminar mi deferred rendering. Lo doy por finalizado al poder reconstruir la posición del pixel en world position para compararlo con la posición de cada luz.

Finalmente despues de estudiar decenas de implementaciones y solventar los agujeros negros que hay en ciertas partes... he implementado la manera que se utiliza en el nuevo motor de Crytek, ciertamente casi igual al paper original de Fabio Policarpo y Francisco Fonseca de CheckMate Games.

Parece que la gente hace a posta las implementaciones mal ! y de una manera extrañisima! pero bueno pronto lo documentaré y lo subiré a la wiki de stratos, un wiki-paper.

Es una tecnica que con la memoria y el BUS que tienen hoy en dia las tarjetas gráficas es básico. Recordad que también el nuevo UE 3.5 se han pasado de Forward Rendering a Deferred, Starcraft y KillZone. Subiré pronto una demo con 2 tipos de variantes de comparacion (en World y View) y la comparación en World reconstruyendo la posición 3D del pixel ahorrandonos por tanto 1 textura (que es mucho).

Os dejo una imagen de hace minutos, no es gran cosa y tampoco es que sea impresionante pero os podreis imaginar por donde van los tiros del deferred rendering / lighting:


Como se puede ver en la imagen una vez obtenido el render en diferido almacenado en texturas por cada luz aplicamos un shader en el que si el punto en World Space coincide con el de la luz, utilizamos su radio de "potencia" de luz para iluminar la escena. En mi caso y ahí no se puede observar muy bien, la distancia o potencia de la luz es mayor contra más blanco sea o más alto sea RGB. No debería ser así ya que no todos los colores saturan o iluminan igual, pero bueno esto ya es complicar el asunto :)

Un saludo a todos.

[[EX3]]

No ando muy metido en materia de las 3D pero parece que va teniendo buena pinta el motor que te andas montando :) Si no he entendido mal estas implementado una tecnica igual o similar de iluminacion por pixel tal como hace Crysis o Gears of Wars 2, no?

Salu2...

[Prompt]

Real-time Atmospheric Effects in Games Revisited: http://ati.amd.com/developer/gdc/2007/D3DTutorial_Crytek.pdf

Es el slide 12. Lo copio:
Recovering World Space Position
from Depth
· Many deferred shading implementations
transform a pixel's homogenous clip space
coordinate back into world space
· 3 dp4 or mul/mad instructions
· There's often a simpler / cheaper way
· For full screen effects have the distance from the
camera's position to its four corner points at the far
clipping plane interpolated
· Scale the pixel's normalized linear eye space depth by
the interpolated distance and add the camera position
(one mad instruction)

En resumen te ahorras almacenar en 1 textura la posicion en World del pixel. Almacenas en 8Bits la distancia normalizada, y le pasas por las coordenadas de textura el Far Plane con la rotación de la camara, por cada pixel "trazas un rayo" y mutiplicas por la distancia almacenada, y te da la posición en 3D del pixel. Luego comparas con la posicion de la luz e iluminas.

Como dije es lo que hace en el tutorial "Deferred Shading Tutorial" Fabio Policarpo y Francisco Fonseca, pero a mi modo de ver el tutorial deja muchos agujeros negros. Nadie explica en detalle como ha de hacerse. Como en todas estas cuestiones con fuerza de voluntad e internet he podido entender la tecnica en detalle e implementarla. No le deseo a nadie el stress que me ha provocado  >:(

Era ya un tema personal, conseguirlo si o si "por mis santos cojones". Despues de semanas dandole al tema en mi tiempo libre ya estaba agotado y decidí tirar un poco del foro de Game Dev para lo ultimo que me quedaba. La solución ya la habia probado pero hace tiempo tenia un fallo en el código del que me di cuenta hace poco. El post en cuestión es este:

http://www.gamedev.net/community/forums/topic.asp?topic_id=541980

Lo que se consigue con esta solucion "de crytek" aunque no es suya la idea solo comentan como lo han hecho (antes ya se hizo), es saturar menos el BUS de datos de la tarjeta grafica. Recordemos que cada frame se crea un G-Buffer de n texturas iguales al tamaño de la pantalla y se procesan, es mucha tela. Esto es una optimización muy importante ya que para calculos de todo tipo necesitamos la posición en World del pixel, y en otras variantes en View (pero ya es multiplicar la posición o cambiar un poco la implementación). Para hacer SSAO por ejemplo.

Me voy a la piscina que me tengo que des-estressar! :D

[Prompt]

Se me olvidó decir que la tecnica o el estudio original es de los años 90, el 91 creo... mmm... ahora que miro... [Ellsworth91]

Así que debemos ir preparandonos para olvidarnos de una vez de calculos en 3D e ir pensando en calcular cosas en 2D con información 3D :)

Si os dais cuenta y habeis usado el programa perf HUD o "pix" con el cual "pinchando" con el ratón en un pixel podemos saber cuantas llamadas a la API "de marras" se han hecho para generar ese pixel. Es lo que se soluciona con el Deferred Shading. El no calcular y calcular mil veces cosas para 1 pixel.

[tamat]

o sea, el compromiso de siempre, memoria o cpu

[Prompt]

Pues si, manda webos la de triquiñuelas que tenemos que hacer para programar 3D... dentro de 20 o 30 años se reiran de nosotros usando photon mapping a cascoporro sin optimizar xD

[Shaitan]

Hola,
No acabo de entender para que necesitas pasarle por coordenada de textura el far de la cámara y su rotación. No es esto constante? O es que cuesta menos crear la variable en el vs y pasarsela por parámetro al fs que directamente dársela al fs (con un par de uniforms)??

Un saludo,

[Prompt]

Hola,
No acabo de entender para que necesitas pasarle por coordenada de textura el far de la cámara y su rotación. No es esto constante? O es que cuesta menos crear la variable en el vs y pasarsela por parámetro al fs que directamente dársela al fs (con un par de uniforms)??

Un saludo,

Tienes que tener en cuenta, que en el único momento donde necesitas "una camara" y la estas usando es en el Geometry Stage, despues pasas a pintar solo en 2D y a hacer calculos en 2D.

Ciertamente se podria hacer "la warreria" o no! quien sabe. De pintar un quad a full screen justo en la posición del Near Plane +1, como si nos pusieran un papel delante de los ojos :P. Lo que se tendría que hacer por tanto es meter en modelViewProjection ese quad. Ahora bien.

Realmente no merece la pena ya que estás guardando la información de Z linearizada y con ella y el far plane puedes tener la posición 3D del pixel en world. Que es mucho más que tener un depth buffer :)

Es más pensandolo así por encima se me antoja mucho más interesante para hacer sombras, cuanto tienes muchas luces has de estar "pintando" el Z buffer que es, normalmente de 24 bits. Te cargas la GPU vamos. Con esta técnica solo necesitas hacer por cada luz, un buffer de 8 bits, que es 3 veces menos que la tecnica normal e incluso tienes más información que solo Z.

¿Para qué utilizar esta información?
Pues por ejemplo para no hacer bordes duros, hacer penumbra del tirón... nose alguna triquiñuela para darle más realismo a la sombra si está cerca de un borde, generarle rugosidad a la sombra, modificarla para que tenga la misma forma de un Bump Mapping. etc... etc...

Bienvenidos todos a ver más allá de Z :)