Comentario#1:

Lo que me gusta del RAYTRACING en particular es que es una de las tecnologías más antiguas, nació junto con el 3D, hace ma´s de 15 años veíamos revisiones plausibles , así que la pregunta es ..Qué tanto están dispuestas estas casas como Sony o EA en abrazar estas opciones y dejar atrás las opciones cómodas basadas en cinemáticas? …bastante remoto..

A eso se le llama mear fuera de tiesto, en serio.

image003-e1521466338634.png

En el blog de Microsoft afirman que motores gráficos como Unreal Engine, Frostbite y Unity lo van a soportar. El Renderizado híbrido donde la iluminación directa es calculada via rasterización y la indirecta dinámica via raytracing es una de las soluciones para lo que se le llama iluminación indirecta dinámica en las escenas a tiempo real de los juegos, la otra solución es el uso del Sparse Voxel Octree Cone Tracing que aunque el Cone Tracing es muy rápido dado que las GPUs recorren fátal las estructuras de datos pues en rendimiento:

thumbsdown

Y esto es por la naturaleza de sus ALUs que solo tienen acceso a sus registros y no tienen un mecanismo para recorrer la memoria. Esta limitación la comente hace unos días y semanas y… Paradojicamente me esta sirviendo enormemente para que la gente pueda entender ciertos conceptos.

Pero claro, se ha de entender que el Raytracing Híbrido y el Raytracing Puro son distintos y DXR permite realizar motores de los dos tipos. ¿La diferencia entre ambos? El híbrido es un método derivado del renderizado por diferido donde primero se calcula el G-Buffer de la escena normalmente compuesto por 4 búfers de imagen distintos.

deferred_g_buffer

Si hablamos de iluminación directa (y por tanto los objetos no tienen la capacidad de reflejar la luz de ninguna manera) entonces la rasterización tiene una ventaja enorme sobre el raytracing en rendimiento y las ventajas en calidad de imagen de este último no existen. Lo que se hace en el Raytracing híbrido es que a partir de la información del G-Buffer se trazán los rayos que recorren la escena… Ahora os preguntaréis seguramente lo de… ¿Si la escena ha sido rasterizada y se ha perdido la información de posición como sabe el trazado recursivo de los rayos?

DeferredRays

Pues es simple, lo sabe utilizando la información el G-Buffer. La diferencia con la solución híbrida de Imagination Technologies es que Microsoft esta diciendo que por ahora los desarrolladores de juegos y motores gráficos hagán la étapa de iluminación via Compute Shaders y sin unidad especializada pero pronto va a existir la unidad especializada cuyo trabajo no es más que realizar de manera recursiva el famoso algoritmo que ya he puesto muchas veces.

Por cada pixel
{
 Por cada objeto dentro del pixel 
 {
 Sí el rayo a través del pixel intersecciona con el objeto y si dicha
 intersección es más cercana que la profundidad almacenada
 {
 Ejecuta el shader sobre el pixel y actualiza el color.
 }
 }
}

ms_rasterization_575px.png

En este caso el shader que se ejecutaría sería el de iluminación, pero el proceso de evaluación al ser recursivo en todos los fotogramas al igual que el proceso clásico de rasterización se haría a través de una unidad especializada que nos debería servir tanto para el Raytracing híbrido como el renderizado via Raytracing puro y duro que es a donde voy a entrar ahora.

El pipeline de la rasterización y el raytracing es exactamente el mismo en la primera etapa que es la geometría. Lo que ocurre es que mientras la rasterización lo que hace es rasterizar la geometría…

Graphics3D_Rasterization

… lo que hace el Raytracing es trazar los rayos por cada uno de los pixeles en pantalla para comprobar si hay un objeto

rayrecursion_575px

Si el objeto se detecta tiene la capacidad de funcionar como fuente de luz este mismo servirá como fuente de luz y se hará una sub-evaluación tomando como punto de referencia ese pixel y no la cámara. Si no se realiza dicha sub-evaluación entonces el Raytracing no tiene utilidad alguna en comparación con lo que tenemos ahora en la rasterización en lo que a calidad de imagen se refiere. En todo caso tanto para el sistema híbrido como el puro se necesita un emisor y evaluador que funcione de manera recursiva para ahorrar potencia en los shaders para algo que se va a tener que realizar en cada fotograma y quitarle a los desarrolladores el mareo de tener que implementar por software esa etapa de manera recursiva.

El problema que le veo al Raytracing puro es que este para evaluar la iluminacion de la escena suele utilizar una estructura de datos espacial y eso en las GPUs va como el culo, es por ello que dudo que veamos Raytracing puro y duro a tiempo real y me decanto más en videojuegos por la unidad de función fija realizando la evaluación como ocurre en el PowerVR Wizard. Más que nada porque en este tipo de situaciones no colocar o eliminar este tipo de unidades es contraproducente en rendimiento y es un tema de costes ya que la evaluación via shaders necesita una GPU sumamente potente, no en vano Nvidia esta utilizando las Titan V para ello.

Por otro lado…

Recordemos tanto monta-monta tanto y que todo lo que sea posible ejecutar con una API será posible ejecutar con la otra, toda tecnología que se añada en las GPUs acaba siendo aprovechada por todas las APIs y es una señal de que esto se va a estandarizar pero no me veo el Raytracing  a tiempo real hasta que las GPUs no tengan las unidades de función fija necesarias para ello y con la información de ayer dudo por completo que sea el uso de Tensor Cores dado que se utiliza una GPU convencional de momento como experimentación antes de que el hardware definitivo este disponible con las unidades de función fija necesarias y si Microsoft lo estandariza en una versión 12.2 de Direct3D entonces tendrán la obligación todos de colocar dicha unidad de función fija.

Comentario#2:

Por cierto, otra cosa buena de estas entradas es que te dan una idea de si actualizar la placa de video o aguantar con una fucking gtx 970.

Igual con mi gtx 670 a 1366mhz puedo jugar Battlefield 1 en alto a 1080p 60 frames, que se jodan los que piensan que se necesita una 1060 minimo.

Yo en mi portátil tengo una 960M y me va de puta madre en muchos juegos, me pongo a jugar cuando la tele del comedor esta siendo utilizada y quiero jugar tranquilamente pero…

20180127_213505

Esto es lo que hay conectado en la tele 4K del comedor. No es necesario realmente y tampoco es una condicion minima para poder jugar, pero… xD.

PD: Los comentarios están desactivados en esta entrada, comentad en la anterior que ire ampliando esta a medida que vayáis comentando. 

(EDIT: Añado para responder los comentarios de Xarman sobre el tema)

Comentario#3:

Esto me recuerda que epic tras cancelar el conetracing en ue4 llegó a un acuerdo con nvidia para demos técnicas o algo así con esa tecnología… así que como mínimo vamos a ver una demo con la última versión de ue4…

la proxima es ue4.20, que como minimo va a incluir resolución dinámica e input lag bajo también en pc (la 4.19 solo en consolas) y aprovechando el número redondo preveo soporte de esa tecnología

Y así ha sido, es más, lo han anunciado el soporte de esto que estamos hablando en el Unreal Engine 4.

Comentario#4: 

Te recuerdo que la propia sony propuso para ps4 hacer conetracing por gpu, sin usar un octree por cpu, sino la funcionalidad de acelerar megatexturas por hardware

Aun asi eso no impide usar megatexturas ya que rage lo hacía por software y el plugin granite para ue y unity tiene 2 modos, uno de ellos mas optimizado que supongo que aprovecha eso, pero el otro tambien permite mantener bajo el uso de vram y aumentar el rendimiento igualmente, sin importar cuantas texturas formen la biblioteca que conforma la megatextura.

Asi que preveo que acaben usando conetracing sin hardware dedicado, multiplataforma, aunque suponga bajar en ps4 la resolución a 900p/30 fps o menos tanto por menos voxels como por liberar potencia para conetracing

Sobre granite han colgado un video reciente con la demo del niño y su cometa del ue4 exportando la biblioteca de texturas a una megatextura de granite de forma automática

https://www.youtube.com/watch?v=_-73omcouAw&app=desktop

1 gb vram, doble de gigatexels, doble de framerrate

En el video de las minas con unity mencionan que no usa mas de 233 mb para la megatextura y que permanecerá constante por mucho que crezca la cantidad de texturas

Al parecer dejan sueltas unos 500 mb de texturas que corresponden a cosas como vegetación, skybox, skin del protagonista… Dice que es mas eficiente en esos casos dejarlo fuera.

El Cone Tracing es una versión simplificada del Ray Tracing en realidad donde en vez de trazar un rayo de luz por pixel lo que hacemos es trazar un cono y se evaluan varios pixeles al mismo tiempo que afectan varios pixeles y por tanto no tenemos que evaluar tantos pixeles.

ao_cones

Da una iluminación mucho mejor que la de la rasterización pero peor incluso que el Raytracing híbrido al no tener tanta precisión, pero al no tener que hacer la evaluación objeto por objeto y pixel por pixel pues…

TC 12.jpg

¿El handicap? En su versión original depende del Octree y recorrerlo para una GPU es cuanto menos un cuello de botella enorme. Por eso se acabo optando por una solución diferente que es la de generar la estructura de datos voxelizando primero la escena.

voxelization

Para generar una matriz de Tiles en 3D que pueden ser recuperados uno por uno y procesados gracias a la funcionalidad de las texturas parcialmente residentes.

volume-tiled-resources

Recorrer una estructura de datos en forma de árbol es mortal para una GPU en cambio recorrer algo como es un búfer de imagen en 3D no lo es.

directx-11-3-volume-tiled-resources

Simplemente cargas cada Tile a la memoria interna de la GPU y lo procesas, Sony ya comento que era posible hacerlo en una PS4 y tenemos el ejemplo del Tomorrow Children pero ni por asomo llega a la precisión de la solución que están mostrando estos días aunque pienso que el Cone Tracing va a quedar como la versión pobre para sistemas no tan potentes o que no tengan el hardware especializado para trazar rayos, simplemente se podrá ajustar si hacer la evaluación utilizando conos (menos precisión pero más velocidad) o rayos (más precisión pero menos velocidad). Es más, el mecanismo para la evaluacion de la intersección de los rayos en el Raytracing se puede utilizar en el Cone Tracing.

¿Que utilizarán los desarrolladores? Pues dependera de las necesidades de cada juego.

Asi que preveo que acaben usando conetracing sin hardware dedicado, multiplataforma, aunque suponga bajar en ps4 la resolución a 900p/30 fps o menos tanto por menos voxels como por liberar potencia para conetracing

Pero no van a utilizar Raytracing híbrido, eso ha de quedar claro. En cuanto al tema que comentas… Me huelo a que vamos a ver algun juego futuro de PS4 funcionando a 720P en la PS4 estándar con Cone Tracing, 1080P sin él. En la PS4 Pro a 1080P con Cone Tracing y a 4K Checkerboard sin él… ¿A que juego me refiero?

Luego una versión en PS5 capaz de ir a 4K nativos y con una iluminación más precisa por el uso de Raytracing híbrido y el hardware dedicado.

Sobre granite han colgado un video reciente con la demo del niño y su cometa del ue4 exportando la biblioteca de texturas a una megatextura de granite de forma automática.

1 gb vram, doble de gigatexels, doble de framerrate

En el video de las minas con unity mencionan que no usa mas de 233 mb para la megatextura y que permanecerá constante por mucho que crezca la cantidad de texturas

Al parecer dejan sueltas unos 500 mb de texturas que corresponden a cosas como vegetación, skybox, skin del protagonista… Dice que es mas eficiente en esos casos dejarlo fuera.

¿Sabés cual es el problema? Que esto en PC lo vamos a ver bien pero a los fabricantes de consolas no les gusta el hecho de tener varios niveles de memoria diferenciados, en realidad el concepto del HBCC que AMD ha colocado en Vega va sobre eso, en tener una cantidad de memoria muy pequeña en una memoria muy cercana al procesador y dejar el resto en un nivel de memoria inferior en vez de tener una memoria de un solo nivel muy extensa.

VegaHBCCVegaHBCC2VegaHBCC3

La idea de utilizar la memoria HBM2 como una especie de cache es interesante y más si la cantidad de memoria necesaria es muy baja realmente. El gran problema que tiene la HBM2 es alto coste, llevo tiempo hablando de ello y de ahí a que estén buscando recortar el coste de dicha memoria para hacer una versión barata.

lowcosthbm

La version barata en desarrollo busca unos 192GB/s de ancho de banda por pila… Pero necesita un controlador de memoria diferente al del HBM2 por el hecho que hay ciertas funciones que cambiarían. A los fabricantes de consolas no les gusta este tipo de memoria porque es cara y no esta estandarizada y prefieren un solo nivel nivel de memoria donde colocarlo todo y además que la HBM de consumo no sería lo suficientemente rápida con un solo chip. Tiene una desventaja menor que la GDDR6 pero sigue existiendo la desventaja desde el momento en que necesitas ancho de banda para cierto efectos… ¿Y el colmo? Que además tendrías que colocar un segundo nivel de memoria DDRn en la consola que la encarecería aún más.

Posiblemente me equivoque pero no me veo algo así, me veo más bien el uso de memoria GDDR6 en un solo nivel y punto. Lo que si que veo es el proceso de voxelización de la escena que he comentado antes para tener una estructura de datos o lo más parecido para que el trazador de rayos la pueda recorrer con más precisión que un G-Buffer, eso si que lo veo posible.

Comentario#5:

¿Se podría combinar la técnica de los decoupled shaders para aprovechar la potencia de los shaders y así usar la potencia sobrante para la voxelización mediante el pipeline de computación?

Si, si que se podría hacer.

Pero no veo que esten estandarizando los Decoupled Shaders por ningún lado pese a ser una de las propuestas más firmes de mejora en los últimos años, aunque quien sabe si se guardan el as bajo la manga. Yo pienso que deberían porque el aumento en rendimiento que obtienen con ello es enorme a base de eliminar la recursivad en los Pixel/Fragment Shaders. Por si andáis perdidos, esto lo comente en una entrada reciente.

Comentario#6:

Por dios bendito…

Quad sli tope de gama volta, y supongo con tensor cores… Para ps6 o 7 en juegos a esa calidad xD

Lo acabo de ver y… Me parece una exageración por el hecho que veo mucha supuesta iluminación «caústica» en la escena pero podría ser un engaño de mi cerebro y estar yo metiendo la pata como conclusión a todo ello.

¿Que es una caústica?

En óptica, una cáustica es la envolvente de los rayos de luz reflejados o refractados por una superficie curva u objeto.

Es decir, técnicamente lo siguiente:

f117

¿Cual seria el problema? Pues el hecho de que esto va un nivel más allá de complejidad visual que la iluminación indirecta dinámica por un motivo muy simple. El sistema utilizado tradicionalmente para la representación del transporte de la luz esta pensado para su refracción en superficies no curvas. Ahora bien, la pregunta clave es: ¿Realmente la demo técnica utiliza dicho nivl de complejidad en la iluminación a tiempo real o es nuestro cerebro que lo considera suficientemente bueno como para dar el pego?

En fin, lo mejor es ir a los detalles en cuanto a la demo porque el diablo se encuentra en estos mismos.

Consegur unos 24 fps «cinemáticos» a tiempo real aún necesita algún hardware sumamente serio: Este esta ejecutandose en un DXG Station de Nvidia.

Dado que la transformación es en una GPU del tipo Volta.. Han necesitado la siguiente burrada de sistema para conseguir renderizar la escena a tiempo real:

DGXStation

Nos encontramos que la escena para funcionar a unos 24fps necesita un total de 4 Nvidia Volta por un lado y por el otro 20 CPUs Xeon de Intel. El único representante es el chip GV100 con una potencia de 15 TFLOPS en FP32 y por tanto estamos hablando de una escena renderizada a tiempo real con una potencia de 60 TFLOPS en FP32 a nivel gráfico y eso son contar la potencia de los Tensor Cores, a nivel de potencia de gráfica estamos hablando de un 5X respecto a lo que esperamos en PS5 y la sucesora de Xbox One si acaba existiendo una porque Microsoft no sabe ni que quiere hacer.

¿Sabéis lo que me huelo? Que en un tiempo vamos a ver la misma demostración ejecutandose en una GeForce RTX 2080 Ti/2080 o como las quieran llamar, funcionan en una sola GPU pero eliminando las cáusticas de la iluminación para acelerar el proceso. ¿Desapareciendo los reflejos? No, haciendo que estos no sean matematicamente exactos, pero oye… A la gente le parecerá mucho mejor que lo que tenemos ahora y dira… ¡Guau! Ya nuestro propio cerebro se encargará de rellenar los huecos.

En todo caso parece que tenemos un futuro híbrido que es lo que he estado hablando estos últimos días y tiene toda la lógica del mundo si se quiere hacer una transicion suave al ray-tracing.

«Estaremos en un lugar híbrido en unos años donde una parte estara rasterizada y otra parte estará trazada por rayos.»

En el mismo artículo hacen referencia de que algunas partes están «rasterizadas» en realidad es una forma de decir que desde el momento en que no refractan y/o reflejan la luz solo son afectados por la iluminación directa.

Ahora bien, la demostración tiene cierta trampa porque en ningún momento Epic y Nvidia y Epic no nos han dicho a que resolución esta se esta renderizando la escena en ningún momento, en todo caso no creo que las aspiraciones de Nvidia sean para videojuegos a corto/medio plazo con esta tecnología porque el hardware es demasiado caro. ¿Entonces para que es? Para el contenido audiovisual narrativo o mejor dicho, para vender GPUs de gama muy alta… Teslas… Al mercado de la creación del contenido audiovisual.

Lo que es realmente tedioso en hacer un actor virtual es ni más ni menos que la animación, el Deep Learning recorta enormemente el tiempo de animación y aprendizaje por lo que disminuye enormemente el coste. Lo que antes eran horas y horas de tiempo delante de un ordenador animando vertice por vertice… Ahora en cambio es algo que… ¡Y alto que esto no es de esta GDC, esto lo vimos en el SIGGRAPH del Agosto Pasado!

Han vuelto a presentar la misma tecnología de nuevo pero de manera más avanzada utilizando al actor Andy Serkis.

El Andy Serkis del primer video por cierto no es el real, aquí podéis ver un corto Making Off.

Dicho de otra manera, parece ser que Nvidia a corto plazo quiere entrar en el mercado que hace dos décadas tenía ocupado Silicon Graphics, y Epic quiere entrar como parte de los proveedores del software. ¿Para que? Las herramientas y habilidades para crear un videojuego pueden utilizarse para una producción audiovisual de este tipo, el hardware es lo suficientemente barato como para generar algo completamente creible a nivel de animación a una velocidad sumamente rápida y los directores no tendrán que esperar semanas a tener una escena renderizada.

Ahora bien… ¿Como llevamos esto a los videojuegos? Pues lo primero que nos deberíamos plantear es como piensa Nvidia llevar esto a nivel doméstico con una futura GeForce RTX dado que cada uno de los chips V100 son mastodontes con un tamaño de 815mm^2 en el proceso de 12/16FF. La trampa inicialmente estará en paso de los 16FF a los 7FF de TSMC, salto que va a permitir que el chip en area y sin cambios acabe ocupando 1/3 de lo que ocupa, esto son unos 280mm^2 en total aproximadamente, pero de lo que es la unidad SM de cara a nivel doméstico se pueden realizar algunas simplificaciones a la unidad SM.

SMVolta

Obviamente no necesitamos las ALUs en FP64 para lo que es el mercado doméstico por lo que eso se puede eliminar, pero en el caso que nos ocupa Nvidia en Volta ha hecho un cambio que… Bueno, si os fijáis hemos dejado de tener lo que son «Cores» en el diagrama para tener las ALUs en FP32 y en enteros completamente desacopladas. Un núcleo CUDA se componía por ambos tipos de ALUs pero solo podía utilizar un tipo al mismo tiempo, ahora parece que Nvidia las ha desacoplado. La pregunta sería si a nivel doméstico aplicaría el desacople o simplemente mantendría la configuracion como hasta ahora pero añadiendo los Tensor Cores.

PascalSM

La lógica me dicta que lo que harán será eliminar las unidades FP64 para tener un procesador más ligero por SM que sera la GV102, con una configuracion de 6 GPC también y reemplazando la memoria HBM2 por memoria GDDR6, siendo esta la GeForce 2080 Ti, la GeForce 2080 estándar vendra a tener solo unos 4 GPC y por tanto solo «unos» 3584 núcleos CUDA y se tratará del chip GV104, luego tendremos la GeForce 2060 Ti con unos 1792 núcleos CUDA siendo el chip GV106. Estos chips se lanzarán durante este año al mercado doméstico por el hecho que el proceso de 7nm no estará lo suficientemente maduro antes de dar el salto que se realizará el año que viene definitivamente con Volta a 7nm que serán llamados Ampere con una configuración similar, más baratos y con una velocidad de reloj mayor, pero obviamente esto son especulaciones.

Comentario#7:

Ambient oclussion por raytracing. joder no hacen falta ni texturas si se usan objetos coloreados a lo super hot r.v.

Se necesita el coeficiente BDRF de cada material, este puede ser calculado matemáticamente pero me da que lo que vamos a ver en los juegos es que dicho coeficiente será dado de antemano como un mapa de texturas adicional. Lo que si que es cierto es que al contrario de la rasterización pura donde necesitamos varios mapas de texturas para simular ciertos resultados de la luz ahora al pasar a estar generados dinámicamente pues… no son necesarios dado que los datos se obtienen al vuelo.

path tracing filtrando la IA permite ilustraciones 3d en pocos segundos en vez de minutos

Lo del Path Tracing que sale al final del video me toca bastante los cojones porque es bastante engañoso al ser un método Monte Carlo que suelen necesitar una potencia enorme por el hecho que con pocas muestras por pixel no consiguen la precisión necesaria. Hace unos meses en el SIGGRAPH presentaron una demostracion basada en reducir el número de muestras en el renderizado via Path Tracing y luego dejar que los Tensor Cores adivinen estas, pero es engañoso colocarlo en la demo porque no vais a ver eso ni en pintura a tiempo real o mejor dicho a tiempo real viable para un videojuego.

La demo del SIGGRAPH ya la he puesto con anterioridad:

Veamos:

Nvidia esta buscando reescribir las reglas del trazado de rayos utilizando la Inteligente Artificial para acelerar masivamente el proceso que tanto tiempo consume en vez de utilizar procesamiento via fuerza bruta.

El fabricante de GPUs esta utilizando la IA para disminuir significativamente la cantidad de rebotes de luz que se necesitan para obtener «una imagen correcta».

Más adelante se puede leer:

Nvidia dice que la aceleracion esta en la region de 8X más rápidas en el mismo hardware.

Nvidia-A-3.gif

La idea es muy simple, renderizar la escena con una menor cantidad de muestras y luego utilizar los Tensor Cores para… adivinar como se vería la escena con una mayor cantidad de muestras porque precisamente el problema del Path Tracing es el «ruido» en la imagen cuando hay pocas muestras y la potencia que requiere es enorme.

spp-compare-1

La diferencia entre el Ray Tracing y la Rasterizacion es que en el caso de la Rasterización por cada cambio de valor en el color del pixel tenemos que volver a escribir el valor en el búfer de imagen, en el caso del Ray Tracing y derivados el valor de color se va acumulando matemáticamente mientras el rayo atraviese la escena y no olvidemos que para almacenar la trayectoria de luz se utilizan en estos casos estructuras de datos espaciales como KD-Trees…

kdtree

De ahí a necesitar una estación DGX con unos cuantos Xeones porque sinceramente las GPUs no son muy buenas atravesando estructuras de datos. ¿A donde quiero ir a parar? Olvidaos de un método de renderizado del tipo Monte Carlo a tiempo real, es una fumada increible proponerlo y en engaño enorme por parte de Nvidia y Epic a no ser claro esta que como he comentado antes que piensen utilizarlo para el mundo del cine.

Pe… pero Urian… Han dicho Path Tracing y no Ray Tracing.

Uno es la evolución del otro… El algoritmo es una version mejorada del Ray Tracing y por tanto más complejo y con la necesidad de una potencia mucho más alta. Es que no tiene sentido hablar del mismo para videojuegos. Pero es que a la gente los arboles no le deján ver el bosque, no se trata de pasar de la rasterización al raytracing sino de utilizar el raytracing en combinación con la rasterización para solventar algunos problemas de esta última, pero no al nivel de dar el salto al Path Tracing a tiempo real para videojuegos… Por Dios, es que pensarlo es de:

obelix

¿A donde me veo esto? Como he dicho antes en el mundo del cine y la television por el momento, ya he comentado antes lo que pienso en esta misma entrada. La gente se esta haciendo pajas mentales muy grandes pero no es su culpa, son Nvidia y Epic haciendo de las suyas con tal de generar un hype que en un tiempo se habrá olvidado.

iluminacion precalculada pero que funciona con el ciclo dia-noche…
ademas como se almacena en lightmaps son tileables para streaming en megatexturas permitiendo muy alta resolución.

Precalculada no puede ser desde el momento en que esta es dinámica, pero he estado pensando sobre ello en los últimos minutos dado que esta es la madre del cordero.

the-thinker-auguste-rodin-png-A95vde-clipart

El tema esta en que la propuesta de Microsoft es que en vez de utilizar un KD Tree o un Octree se utilice una simple matriz tridimensional que es mucho más fácil de recorrer para la GPU que no esas estructuras de datos y como bien dices se pueden trasladar los Tiles 3D a la memoria para procesarlos uno por uno. Pero el tema esta en la precision… ¿Como almacenamos en una matriz 3D la información de una imagen de aproximadamente 4K pixeles por 2K pixeles como son los 4K?

directx-11-3-volume-tiled-resources

Parece ser que la propuesta es que la Z de la matriz sea la misma que la Y por lo que acabaríamos teniendo una matriz de:

3840*2160*2160= 17.915.904.000 voxeles

Teniendo en cuenta que cada tile es de unos 32 bits/4 bytes

17.915.904.000 *4= 71.663.616.000 bytes = 67 GB

Simple y llanamente no es viable por el tema de la memoria y la aplicacion de los rayos pixel por pixel va a necesitar una enorme cantidad de memoria… Ahora bien… ¿Vamos a ver los rayos calculados por pixel/voxel en la escena o por grupo de pixeles/voxeles? Es que tecnicamente no es lo mismo y a lo que me refiero es que en vez de aplicar el algoritmo de iluminacion por pixel se aplique por Tile… Se necesita menos potencia, es mucho menos preciso pero es mas viable a tiempo real.

(3840/32)*(2160/32)*(2160/16)= 1.093.500 voxeles

1.093.500*4= 4.374.000 bytes

Pero eso sería la precision más baja posible donde se calcularía la iluminacion conjunta de un Tile 3D entero y por tanto la que daría peor calidad de imagen. Habrían varios niveles de precision aunque el más bajo que veo que vamos a ver mientras el filtrado de texturas sea de 2×2 va a ser una precisión de:

(3840/2)*(2160/2)*(2160/2)= 2.239.488.000 voxeles

2.239.488.000 *4 = 8.4 GB

La idea sería que cada Tile 3D de 32x32x16 voxeles estuviese compuesto por una serie de Micro-Tiles de 2x2x2 voxeles cada uno de ellos. Pero que la precisión de en cuentos voxeles de la escena se proyecta el rayo dependerá del desarrollador, pensad en ello como en la precisión de ciertos efectos especiales que es variable según las necesidades de cada hardware gráfico. En los más potentes será posible aplicar la comprobación por voxel unitario, a medida que vayamos bajando la comprobacion de la iluminación será por grupos de voxeles cada vez más grandes, pasando del Ray Tracing a su hermano pequeño que es el Cone Tracing.

TC 12

El problema es que esto es solo la mitad de la historia, obviamente la cantidad de información por Voxel al tener un G-Buffer sería mucho más alta… ¿Como la evitamos? Mi hipotesis es que lo que van a hacer va a ser renderizar el transporte de la luz en la escena sin tener en cuenta el texturizado/color pero si el BDRF que se va a generar en una matriz 3D que será un mapa de luces complejo de los cuales se descartarán los pixeles no visibles en la escena para tener el mapa de texturas correspondiente. ¿Como? No se si la gente ha observado que en las demos que han presentado no hay ni una sola superficie transparente.

Esto nos debería permitir descartar por completo el G-Buffer de esta manera y centrarnos en el Tile Forward Rendering o Forward+ pero de manera mucho más precisa al combinarlo con el Raytracing en modo híbrido.

forward-eurographics-2012-10-638