Un Bounding Volume no es más que una caja o más bien un espacio contenedor donde esta colocado un objeto o parte de un objeto de la escena.

teapotbbox

El proceso para crear un Bounding Volume ya lo hemos visto con anterioridad, es el mismo empleado en la Voxelización de la escena, empleado en escenas como el Cone Tracing en todas sus variantes (una versión light del Raytracing) pero en este caso no hablamos de voxelizar la escena sino de organizar la geometría de la escena por «cajas» que esten compuestas por otras subcajas, el concepto es simple, a la hora de realizar la intersección del rayo con el objeto no lo haríamos pixel por pixel sino que comprobariamos si la caja contiene un objeto o no, si la caja no contiene nada se cuenta como un miss, si contiene algo se desciende un nivel y se hace de nuevo la comprobación hasta que no hayan más niveles por debajo. Esto hace que los Bounding Volume se organicen en una jerarquía.

534px-Example_of_bounding_volume_hierarchy.svg

Estas jerarquías tipo arbol pueden tener varias configuraciones distintas según la cantidad de nodos que tenga cada sub-rama del arbol. Los más habituales son el KD-Tree, el Quadtree y el Octree. Basicamente son formas de ir subdiviendo la escena en subdivisiones de 2, 4 y 8 respectivamente, si realizamos la intersección utilizando las unidades programables (shaders) nos interesa poder ocupar las ALUs con la mayor cantidad de nodos a comprobar y es aquí donde AMD tiene un gran problema en este aspecto respecto a Nvidia, por eso pese a que Volta carecía de RT Cores como los AMD Vega de AMD la configuración de 16 ALUs por SIMD de AMD era contraproducente frente a los 8 ALU por SIMD de las Volta donde se puede utilizar un Octree y ocupar todas las ALUs. Recordar que AMD funciona con olas de 64 elementos  y Nvidia con olas de 32 elementos.

Pero como tambien os explique el hecho de atravesar una estructura de datos espacial es horrible para los shaders de una GPU donde su rendimiento es muy pobre, es ahí donde entran los RT Cores en Turing que de manera completamente opaca dicen si la luz impacta con un objeto o no impacta y el shader correspondiente aplica los efectos de manipulación de los pixeles determinados y lo hace de manera mucho más eficiente que a través de los shaders.

PicaPicaTuringvsVolta

La intersección forma parte del pipeline para el Raytracing y es una función esencial del mismo, como podéis ver los resultados entre Turing y Volta ante la misma demo saltan a la vista, los RT Cores aceleran enormemente el tiempo de renderizado descargando a las unidades programables de dicho trabajo y reduciendo el trabajo de estas a aplicar el shader correspondiente.

RaytracingDXR

Ahora bien, el pipeline que vamos a ver es híbrido y no puramente Raytracing por lo que la escena es inicialmente renderizada teniendo en cuenta la luz directa, es decir, la que se genera a partir de las fuentes de luz primarias pero no la que se genera como resultado del impacto de la luz con los objetos y no se renderiza utilizando el Raytracing sino el pipeline convencional de rasterización.

RasterizacionDXR

Por lo que el Raytracing es aplicado por un lado como post-procesado y por el otro añade etapas adicionales al renderizado por lo que si queremos renderizar una escena a la misma velocidad con este deberemos acelerar el resto de las etapas y esto se consigue aumentando la potencia de cada una de ellas y su eficiencia, lo cual es de perogrullo. Hay que tener en cuenta que cada vez que el pipeline se ha hecho más complejo ha supuesto una nueva versión de DirectX/OpenGL por lo que es muy posible que DXR se convierta en DX13 pero… ¿Quien sabe?

Ahora bien… ¿como viaja la luz? Basicamente por el plano (ZX)

300px-3D_coordinate_system.svg

El rayo no sale de las fuente de luz y atraviesa desde esa posición la escena, cuando impacta con una estructura se resuelve pero hemos de tener en cuenta que ese rayo puede no transportar consigo información de color y cuando impacta con el objeto es el shader que se ejecuta el que va a definir el nivel de refracción de luz que tiene y cuanta de ella deja pasar. Si es un objeto completamente opaco no dejara pasar la luz al objeto que exista en el nivel inferior del arbol si lo es en mayor o menor grado entonces dejará pasar la luz hacía adelante y se puede convertir en una fuente de luz o no. El rayo continuara atravesando la escena hasta que se quede sin energia o hasta que no hayan más nodos. Obviamente la cantidad de energia inicial del rayo así comoel número de nodos de la estructura son valores que pueden ser asignados por el desarrollador.

Ahora si sois perspicaces habréis visto que este segundo arbol no es el del BVH pese a que utiliza el BVH para construirse y al mismo tiempo es una versión más avanzada del concepto de los mapas de sombras en la rasterización, el cual se basa en renderizar la escena tomando como punto de cámara (origen) la propia fuente de luz y renderizando solo el Z-Buffer+Stencil con tal de crear un mapa de sombras de la escena. En el caso que nos ocupa lo que creamos es una estructura de datos espacial que resulta mucho más eficiente que el Z-Buffer para solventar por ejemplo el problema de las sombras indirectas generadas dinamicamente. Es por ello que lo primero que han hecho los desarrolladores no es solventar el problema de los reflejos sino la generación de sombras, permitiendo la inclusión del Raytracing el uso de las llamadas Soft Shadows.

0041_04_10

El segundo arbol puede ser generado por los shaders programables o por la unidad de función fija (RT Core) aunque el segundo caso es mucho más eficiente porque permite realizar el trabajo en menos tiempo y luego hemos de tener en cuenta que se va a lanzar un rayo o varios por tipo de efecto por fuente de luz ya sea secundaria o primaria dado que podemos definir un objeto también como fuente de luz donde esta refracte siendo la iluminación especular indirecta…

diffuse-vs-specular

… la más utilizada el desglosarse por completo en un solo rayo y no en varios como la difusa (lo que significaría una cantidad enorme de rayos a procesar) por lo que podríamos pensar que lo que vamos a ver en los juegos a corto-medio plazo es el Whitted Raytracing más que ser via Path Tracing, en realidad esto no es del todo cierto sino que todos los tipos de Raytracing van a ser adoptados y hemos de tener en cuenta que el concepto «energia» se utiliza más bien en el Path Tracing pero este tiene un problema enorme y es la enorme cantidad de ruido que genera… ¿Y que empresa esta promocionando el uso del Path Tracing? Nvidia por el hecho que limpiar la imagen requiere el uso de sus Tensor Cores, pero el proceso de limpieza del ruido no forma parte del pipeline de DXR ni formara parte del de Vulkan.

Y aquí entramos en un tema realmente curioso, mirando el articulo de Digital Foundry acerca del uso del Ray Tracing en el Battlefield V…

Mientras que DICE está obteniendo una gran calidad de los rayos que dispara, los resultados sin filtrar del ray tracing s son aún bastante ruidosos e imperfectos. Para limpiar ese ruido, se usa un filtro temporal personalizado, junto con un filtro espacial separado después de eso, para asegurarse de que los reflejos nunca se rompan y se conviertan en sus resultados granulosos y sin filtro. Curiosamente, esto significa que DICE no está utilizando actualmente los núcleos tensoriales de Nvidia o los filtros de descongelación entrenados por AI para limpiar sus reflejos de trazado de rayos.

¿Y por qué DICE prescinde los Tensor Cores? Pues porque tienen que hacer que Frostbite evolucione a un minimo común multiple y la gente de EA DICE tiene que tener información que el resto no tenemos. El RT Core si que parece ser una parte esencial que encaja en el pipeline del DXR pero los Tensor Core no… ¿Es la no inclusión en Frostbite una pista de lo que nos podemos encontrar a futuro? ¿Vamos a ver a AMD sin el uso de los Tensor Core solo pq Microsoft no los ha implementado como parte del estandar DXR?

Pe… pero Urian… Si AMD hizo una demostración el marzo pasado de un «Denoiser»… ¿No es eso la demostración de que van a utilizar algo como los Tensor Cores?

Denoising

Es cierto, pero el Denoiser puede ser aplicado sin problemas también en los shaders con la diferencia de que la velocidad es obviamente mucho más lenta, este es uno de los motivos por los cuales en la comparación Pascal vs Turing que hizo Nvidia para hablar del «enorme» salto de potencia en cuanto al Raytracing era moviendo el «Denoiser» a la unidades CUDA en Pascal por falta de Tensor Cores en estos, de ahí la enorme diferencia en la comparativa de rendimiento que hizo Nvidia.

NVIDIA-RTX-Turing-GPU_13-1030x579

Otra de las demos es del juego Control de Remedy Entertainment en su versión para Nvidia RTX, el cual utiliza el Northlight Engine utilizado previamente en Quantum Break.

Pues bien, hemos podido saber los tiempos en una GeForce RTX 1080 Ti, ni más ni menos que unos 9.2 ms por fotograma son utilizados por el Raytracing, desglosados de la siguiente manera:

  • 2.3 ms para la generación de sombras (utilizando 2 rayos)
  • 4.4 ms para el calculo de los reflejos (utilizando 1 solo rayo)
  • 2.5 ms para lo que el denoising (realizado en los Tensor Cores)

Esos 2.5 ms sin la existencia de los Tensor Core aumentarían enormemente hasta niveles de 10ms como mínimo solo para dicha parte sin ellos, pero la inclusión del denoising desde los mismos hace que  por lo que tenemos que hacer que el resto del pipeline sea unos 2.5ms más rápido. Hemos de tener en cuenta que esos 9.2 ms no es el fotograma entero sino que es solo la parte de raytracing, el postprocesado por lo que el resto del renderizado se tiene que realizar en solo 6.8ms si hablamos de una escena a 60fps con la misma GPU o 24.1 ms en la misma escena a 30fps, lo cual dada la naturaleza del juego tiene mucho más sentido pero eso no quita que necesitemos incluso unos 2.5 ms por fotograma y con ello una GPU algo más potente que sin la aplicación de la limpieza de la escena.

Pero el problema del Denoiser es un problema de resolución, no en vano las declaraciones de en twitter de uno de los cientificos jefe de Nvidia acerca del Raytracing en altas resoluciones da que pensar que de cara al futuro a no ser que se le encuentren otras utilidades esenciales a los Tensor Cores vamos a ver como estos desaparecen con el tiempo.

Noise

Y si, están hablando de una resolución de 8K (32 Mpixeles) pero tiene miga si miramos la respuesta de Sebastian, simplemente renderizar a 1080P y luego escalar temporalmente a 8K pero… ¡Si para ello es recomendable tener los Tensor Cores! ¿Entonces nos vamos a ver con un Raytracing con ruido e inexactitudes? No realmente y aquí entramos en algo que se esta barajando de estandarizar en la siguiente generación y que va ayudar a estandarizar el Ray Tracing, algo que es una versión reducida del mismo y que se beneficia enormemente también de la aceleración de las estructuras BVH, me estoy refieriendo al Cone Tracing del que ya había hablado anteriormente.

El Cone Tracing es un derivado del algoritmo de trazado de rayo que reemplaza los rayos, que no tienen grosor, con rayos gruesos.

TC 12

Es decir, en vez de lanzar un rayo por pixel lanzamos un cono de luz a cada noda nodo del BVH, no siendo tan preciso como el Raytracing pero si mucho más rápido de renderizar y por tanto mucho más viable, pero para funcionar bien necesita la implementación de unidades de función fija que hagan el trabajo del RT Core. La otra ventaja del Cone Tracing es el hecho de que el Raytracing genera ruido en la imagen final que se ha de corregir, con el Cone Tracing no porque no genera ese ruido.

La implementación del Cone Tracing durante la actual generación de consolas  fue desastrosa por la eliminación del BVH que es el Octree ya que las GPUs de hace un lustro no erán lo suficientemente rápidas, esto hizo que se propusieran soluciones aún más simples que no utilizan una BVH.

Axxtgrx.jpg

La idea es que si volvemos al mínimo común múltiple que nos marca la versión de Frostbite para Battlefield V (la cual tiene que estar optimizada para el lanzamiento de Battlefront 3 el año que viene) nos encontramos que algo como los RT Core si que van a ser un elemento común en todo hardware y esto no solo puede beneficiar la adopción del Raytracing a largo plazo sino de su versión menos avanzada que es el Core Tracing a tiempo real, la cual es menos precisa pero al mismo tiempo mucho más precisa que la actual iluminación.

Y para terminar me gustaría que os fijaseis en la última diapositiva que he puesto, el último punto porque es clave y voy a terminar explicando con un gráfico la diferencia de rendimiento respecto a la geometria de la escena a la hora de tener un BVH.

logvslin.jpg

Dudo mucho que el DXR sea algo solo para Nvidia y estoy seguro que AMD tiene algo preparado y sin Tensor Cores ya que no son necesarios en el estandar DXR que propuso Microsoft hace unos meses, no me extrañaria una demo de Battlefield V en modo hibrido funcionando en cierta GPU en el CES de este año y para ciertas futuras consolas. 😉

Esto es todo, ya sabéis que para cualquier duda tenéis el Discord para comentar y los propios comentarios de esta misma entrada.