Durante el pasado més de Septiembre Polyphony Digital, los desarrolladores de Gran Turismo, presentaron una tecnología para aplicar Raytracing a tiempo real a GT Sports a la que han decidido llamar Iris.
Dado que GT Sports es un juego renderizado utilizado la rasterización podemos suponer de entrada y sin coger información que Iris es un motor de renderizado híbrido que se basa en rasterizar primero la escena y luego utilizar el raytracing para solventar algunos «problemas» visuales que la rasterización no puede «solucionar».

Este es el camino que esta tomando la industria en general de cara a hacer evolucionar el pipeline 3D más allá de lo que existe en estos momentos y es normal que en Polyphony Digital estén experimentando con ello. El caso es que la gente anda completamente confundida, al nivel de cuando se vio el juego a 8K y 120fps, que tuve que realizar una entrada para aclarar las cosas y demostrar como con la tecnología actual esto no es posible.
Pero veamos lo que es «Iris» realmente:
Un tema importante que se ha discutido en la presentación es el sistema de renderización «Iris» desarrollado recientemente por Polyphony Digital. Se tratade un «sistema de trazado de rayos de Monte Carlo», pero no te emociones mucho: se refiere a una clase de algoritmos, no a la famosa pista de carreras.
Polyphony Digital ha desarrollado a Iris completamente in-house y se utilizo por primera vez en Gran Turismo Sports. Iris utiliza un método de «baking» que pre-renderiza la iluminación en el ambiente. Esto genera luces y sombras realistas, pero es casi con certeza la razón por la cual no tenemos no tenemos iluminación dinámica segun el momento del día o condiciones climáticas dinámicas en el GT Sports
![]()
Para el «baking» de un circuito como Nürburgring, el cual según el aper son 42GB de datos comprimidos, el trabajo se distribuyo entre 8 servidores de renderizado con 40 CPUs cada uno. Un total de 320 núcleos para renderizar los datos de iluminación en 30 minutos.
Olvidemos un momento de la iluminación… ¿Como se renderiza la iluminación en la rasterización? Pues simple y llanamente tanto los mapas de luces como los mapas de sombras cuando son dinámicas se realizan renderizando la escena de nuevo desde el punto de vista de la fuenta de luz o de sombras pero no se texturiza sino que el resultado que es un búfer de imagen se almacena en forma de mapa de luces o de sombras según el caso, mapa que se combinará con el resto de texturas para dar la sensación de luz. El problema es que este método es impreciso a más no poder, pero durante años ha sido el utilizado porque era el más veloz y además que era lo suficientemente bueno.
¿Pero que ocurre con la iluminación indirecta dinámica? En la rasterización es imposible y es por ello que se suele «hornear» y un método es el que utiliza Polyphony. Imaginaos una escena con sol fijo y no dinámico del circuito de Nürburgring pero no un fotograma del juego sino el modeloado completo del circuito como si fuese una maqueta iluminada por un foco.

Lo que han hecho es tener esa maqueta de manera digital, la han renderizado completamete off-line para tener los mapas de luces de una posición concreta del día de cara a conseguir un mayor realismo en GT Sports, pero no es Ray Tracing a tiempo real en dicho juego, aunque esto es solo la mitad de la historia. La parte que nos interesa es la que viene a continuación:
Tenemos la demostración del Raytracing en el el modelado de dos coches, no estamos hablando del presentador mostrando un gameplay de Gran Turismo Sports funcionando con Raytracing a tiempo real sino algo que no es muy diferente a la demostración de hace unos meses de Nvidia con el Porsche.
Pero se que hay gente que se cree que PlayStation 5 va a poder mostrar Raytracing a tiempo real con una muy alta calidad, lo cual es completamente imposible. Es un concepto teórico que equivale a decir que cualquier cuerpo con masa puede superar la velocidad de la luz y quedarse tan anchos después de eso. Pero como se que la gente va a querer una demostración de porque es imposible que el Raytracing a ese nivel a tiempo real pues se la voy a dar.
En primer lugar hemos de entender que el problema del pipeline híbrido es que crea resultados que son visualmente y matemáticamente imprecisos por un motivo bien simple, los algoritmos tipo Montecarlo necesitan una enorme cantidad de muestras por pixel dado que generan una enorme cantidad de ruido por lo que necesitan una cantidad de muestras por pixel brutal. Olvidemos por un momento que estamos renderizando utilizando un pipeline híbrido, imaginemos que queremos renderizar una escena utilizando Raytracing puro y duro, necesitamos un hardware para hacerlo… ¿Que tal la potente RTX Titan? No vamos a ser exigentes en cuanto a resolución pero tampoco vamos a dar un paso atrás, 1080p60 es algo obligatorio.
Volviendo al artículo podemos leer:
Otro tema de discusión son las múltiples fuentes de iluminación, la luz desde la cual se superpone e interactúa consigo misma de muchas formas complejas. El mayor desafío lo presentó el curso nocturno de Northern Isle Speedway, que cuenta con más de 208 fuentes de iluminación únicas.
El circuito de Nurburgring tiene 2308 fuentes de luz. Aunque se extienden sobre un área mucho más grande, las tribunas presentan un desafío único, con una alta densidad de luces en un área pequeña.
Utilizando el Raytracing puro lo utilizamos tambien para generar lo que es la escena con iluminación directa… tened en cuenta que esto es por el momento imposible pero lo voy a utilizar como ejemplo para explicaros como funciona el Raytracing y porque se utiliza por el momento el Raytracing híbrido. Pero para ello tenemos que tener en cuenta el concepto de fotón de la realidad.
Partícula mínima de energía luminosa o de otra energía electromagnética que se produce, se transmite y se absorbe.
Nuestro fotón no va a a transmitir electromagnetismo pero si la energia luminosa que en nuestro caso es el color que vamos transmitiendo en la escena, la fuente de luz tiene un color y cada vez que el fotón rebota con un objeto se refracta de una u otra manera según la naturaleza de la superficie, pero sobre el tipo de rebote ya entraremos.Pensad en los «fotones» como pelotas que son como pequeña pelotas que vamos rebotando en la maqueta, dichas pelotas son como pelotitas de tenis que van rebotando en las diferentes superficie de la maqueta. Con la pelotita pueden pasar tres cosas:
- La pelotita se pierde en el horizonte (después de rebotar con un objeto se sale fuera de la maqueta.
- La pelotita es rebotada al impactar con un objeto.
- La pelotita es absorbida por un obj…
… este… no porque entonces estaríamos hablamos de un agujero negro que es el único objeto en el que la luz no puede escapar.

Por lo que los fotones de luz van a estar rebotando continuamente, en el Raytracing lo que hacemos es enviar un rayo/fotón por cada pixel y lo hacemos rebotar por la escena. Lo normal es enviar una rayo/fotón/pelotita (esto es para que visualmente lo podáis visualizar) por cada pixel y este va rebotando, la información que lleva de entrada la vamos a llamar E y es la emisión luminica que en nuestro caso es el color y sus carácteristicas como la Luminosidad. Para entender el color imaginad que el escenario donde lanzamos las pelotas de tenis esta lleno de superficies recien pintadas y cada impacto la pelota va arratrando los diferentes colores de pintura y se van a ir mezclando.
¿Os acordáis de una vieja formula que puse sobre el Raytracing que derivaba de la ecuación de renderizado?

La formula es exagerada porque supone una escena cerrada donde la luz no puede escapar, y donde tenemos superficies reflectantes, cuando el fotón/rayo/pelotita haga el impacto con una superficie tendrá que calcular el rebote de luz con dicha superficie (KE) pero cada rebote de luz en nuestra escena ira rebotando de manera recursiva hasta el infinito. Es decir, si enviamos un fotón a un pixel y no hay nada entonces L=E, si enviamos un fotón a un pixel, rebota pero no hay un segundo rebote entonces L=E+KE y esto se puede hacer con el rasterizado pero si queremos iluminación indirecta entonces L=E+KE+K^2E.
Pensad que en cada rebote se ha de calcular la interacción del rayo sobre el pixel o el objeto y los procesos de computación (shader) correspondientes. La maqueta de Nurburgring tiene 2308 fuentes de luz,esto son 2308 muestras y significa tener que calcular solo con la iluminación directa unas 2308 veces por pixel la iluminación. Esto solo para la iluminación directa son 2308 muestras por pixel… ¿Sería posible algo así en una RTX Titan? Pensad que estoy descartando por completo la iluminación indirecta. Veamos como resultaría…
(10.000.000.000)/(1920*1080*60)= 80 Rayos por pixel.
Que decepción, ya no podemos, necesitamos calcular 2308 intersecciones por pixel y no tenemos la suficiente potencia para las interesecciones siquiera. El downgrade de 2308 muestras/fuentes de luz es realmente impactante, no solo eso sino que además nos encontramos que la cantidad de operaciones por pixel tampoco es lo suficientemente alta… ¿pero 80 muestras? Incluso con el hardware actual es una barbaridad… La mayoría de juego que utilizan el Raytracing híbrido para funcionar bien con el hardware más potente actuamente no llegan ni a las 10 muestras por pixel, si fuese via Raytracing puro y duro no tendriamos nada bueno a nivel de calidad e imagen y a velocidades injugables.
El resultado no sería aceptable y tampoco tendríamos representadas todas las muestras/fuentes de luz de la escena. Pero es que además hay un elemento adicional en que mucha gente no ha reparado… ¿Como vamos a hacer rebotar nuestra pelota contra un escenario aún no construido? El punto en común entre el Raytracing y la Rasterización es que en ambos a priori tenemos que generar la geometria de la escena, pero en el Raytracing no se Rasteriza y es que el problema de rasterizar es que al eliminar la estructura tridimensional de la escena no tenemos una representación tridimensional en el que podamos representar la trayectoria de los fotones.
Si no sabemos como es el escenario porque lo ha de trazar… ¿Como sabe donde va a rebotar cada pelota de tennis? Pues es muy simple, el escenario ya lo hemos trazado y hemos almacenado la posición de la geometria en una estructura de datos espacial llamada KD-Tree (otras estructuras de datos como el Octree también se pueden utilizar pero el estandar es el KD-Tree) que nos permite almacenar la información de los objetos de la escena a través de una subdivisión de la misma.


En el Raytracing calculamos la geoemetria de la escena y una vez calculada una vez realizada es ordenada en una estructura de datos espacial que es el KD-Tree (o el Octree dependiendo del caso) que nos va a servir para tener la escena ordenada de cara a la comprobación de si una pelota de tenis va a rebotar con un objeto o no. Obviamente es dificil entenderlo de entrada el concepto pero la idea es que solo necesitamos almacenar la posición de cada uno de los objetos en el KD-Tree. este se convierte en lo que llamamos un BVH.

Es decir, tenemos la geometria de la escena almacenada en una estructura de datos. Esto era imposible hacerlo en el hardware de rasterizado clásico porque el ordenamiento de los elementos de la escena se hacía casi al final de la fase de renderizado, es decir después del texturizado.

Pero con la aparición de la rasterización por Tiles ahora la escena ya puede ser ordenada antes de la rasterización y lo que tenemos de ella es la geometría de la escena, es decir lo que tenemos previamente a la rasterización…

Por lo que la primera etapa es igual en el rasterizado que en el Raytracing y desde el momento en que en el rasterizado podemos representar de manera fidedigna las fuentes de luz podemos hacer que la iluminación directa vaya a través del rasterizado pero con ello nos viene otro problema.Y es el hecho que por cada fuente de luz tenemos que re-calcular cada uno de los pixeles… En el rasterizado utilizar 2308 fuentes de luz por pixel supone y sin contar otro efectos calcular unas 2308 veces cada pixel haciendo que la tasa de texturizado se reduce a 1/2308. es decir, se necesitaría una tasa de texturizado de…
1920*1080*60*2308= 287.152.128.000 texeles por segundo.
287 Gtexeles/seg aprox
Y tendriamos que calcular el shader por cada pixel calculado y esto solo para la iluminación directa. ¿Que es lo que se hace? Pues se utiliza como trampa el rasterizado en diferido. Dicha trampa es que se utiliza para eliminar el problema que tiene la rasterización con multiples fuentes de luz. En el renderizado convencional cada vez que hay un cambio en el pixel este se re-dibuja provocando que se divida la tasa de texturizado y a posteriori la de relleno, el Deferred Rendering nos permite simular varias fuentes de luz pero dichas fuentes realmente no emiten fotones realmente pero para una escena bajo rasterización son lo suficientemente buenas…

¿Pero que ocurre si no emiten fotones o los hacen rebotar? Pues basicamente que nos encontramos ante una imprecisión visual y matemática y como comente en la entrada del Fake Tracing en una paradoja. El hecho de rasterizar a priori y/o aplicar otros efectos es para que haya una información en la escena que aunque matemáticamente y visualmente no sea exacta sea una aproximación lo suficientemente cercana para convencer al espectador.

Es decir, empezamos rasterizando utilizando el método diferido y generando la estructura de datos en el proceso.

Y lo que hacemos a continuación es aplicar sobre esa escena el Raytracing, como la parte E+KE de la ecuación esta resuelta lo que hacemos es aplicar K^2E pero lo hacemos enviando un fotón desde cada fuente de luz a cámara o hacemos que haga el camino inverso (de cámara a la fuente de luz), en este caso la formula L=E+KE+K^E dado que ya tenemos E+KE como una constante en cada pixel ha pasado a ser E a nivel computacional, pero seguimos necesitando una estructura de datos espacial para el recorrido de la luz.
El siguiente paso es la parte del Raytracing, no tenemos una luz de rebote de inicio en el diferido. ¿Que se hace entonces? Pues la asignamos a cada objeto la capacidad de comportarse como una fuente de luz primera (directa) aunque realmente sea una indirecta, es por ello que en el raytracing hibrido no es igual renderizar por diferido.

El pipeline va a ser el mismo que el del DXR en todos los sistemas, esto es indiscutible. En el diagrama donde se utilizan los shaders esta marcado en amarillo. En este caso tenemos que cada material de la escena tiene una capacidad de emisión, pero aqui no estamos haciendo rebotar un fotón de luz para luz indirecta, aqui le asignamos a cada material de la escena una capacidad de emisión y de rebote de la luz, de tal manera que a nivel computacional la ecuación L=E+KE+K^2E la hemos convertido en L=E+KE. De esta manera reducimos enormemente la carga computacional con el handicap de que no es matematicamente ni visualmente preciso y si, se que a estas alturas muchos estaréis…

Pero cuando veais el resultado pese a no ser fiel a la realidad, vais a decir…

Lo que vais a tener es una aproximación más fiel a la realidad de lo que ya tenéis en estos momentos en las consolas actuales. No vais a tener la realidad tal cual simulado y olvidaos de un raytracing de alta precisión que han utilizado para generar la iluminación pre-cocinada. El concepto de aproximación no me lo he inventado yo, realmente existe.
Aproximación es una representación inexacta que, sin embargo, es suficientemente fiel como para ser útil. Esta aproximación nunca es utilizada en ciencias exactas a grado profesional debido a la pérdida de información.
Aunque en matemáticas la aproximación típicamente se aplica a números, también puede aplicarse a objetos tales como las funciones matemáticas, figuras geométricas o leyes físicas.…
En casos de información incompleta, que impide el uso de representaciones exactas, pueden usarse aproximaciones. Por otra parte existen problemas que son demasiado complejos para resolverse analíticamente, o bien imposibles de resolver con las herramientas disponibles. En estos casos, una aproximación puede arrojar una solución suficientemente exacta, reduciendo significativamente la complejidad del problema y el costo de su solución.
¿Pero que nos podemos esperar realmente? Lo mejor es buscar un ejemplo cercano como es el Asetto Corsa Competizione funcionando con raytracing híbrido para hacernos una idea de como sería GT Sports con Raytracing en un hardware muy cercano a lo que será PS5.
El Asetto Corsa con Raytracing aun no ha salido pero si GT Sports en PS5 soporta raytracing no diferira mucho. Pero no dejara de ser lo que yo llamo Fake Tracing que es lo que es el raytacing hibrido pero al mismo tiempo pese a ser una aproximación lejana será algo lo suficientemente bueno.
¿Veremos esto alguna vez en una consola de Nintendo, si es que llega a existis para esa época?
Me gustaMe gusta
¿Tú eres de los que creen que la vida se acaba a los 30?
Me gustaMe gusta
Gracias buena entrada volveré a leer las que escribiste de Raytracing par entender mejor
Me gustaMe gusta
«un agujero negro que es el único objeto en el que la luz no puede escapar»
error ya se sabe que si hay luz que sale, sale luz, sale energia, sale masa, y sale materia, pero claro para entender esto que se esta descubrinedo del agujero negro actualmente… hay que OLVIDARSE de todo lo que te han enseñado en al escuela de lo que es un agujero negro… un agujero negro no tiene nada que ver con lo que te han enseñado y lo demuestra los descubrimientos de los que te digo
Me gustaMe gusta
En el ejemplo que pones(el de los 80 rayos por pixel), entiendo que es porque la iluminación se calcula por entero, o lo he entendido mal. ¿Pero no se podría ir cargando tira a tira?
Entiendo que en un juego de coches deba cargarse el circuito entero, al fin y al cabo no son ‘demasiado’ grandes, pero por ejemplo en un juego de rol, o uno de aventura, no entiendo porque no se podría ir cargando trozo de mapa a trozo de mapa.
Me gustaMe gusta
La ñapa, en mi opinion maravillosa, que han sacado en Nvidia esta bien, optimiza recursos y permite un Ray Tracing que da el pego, ademas no pierden la compatibilidad en los desarrollos actuales y futuros para el parque de hardware actual, Ps4, Xbox One y pc pre-Rtx ,ya tienen los Rt que hace hace el calculo de los rayos y sus rebotes, con poquitos rayos y los Tc que salvan el problema de la imprecision y el ruido, es asi con trucos y aproximaciones donde consiguen unos resultados bastante buenos y con un coste computacional enorme que en Pc donde «todo vale» y «mucho dinero es poco» cuela pero que resulta lejano para el entorno de consolas, donde el calor, el tamaño y el precio son claves.
Un poco dificil hoy en un chip para consola aunarlo todo, poco consumo, poco calor, precio contenido, buena tasa de cuadros, buena calidad grafica, buena resolucion y un precio en torno a los no mucho mas de 500 euros-dolares, a no ser que encuentren otra arquitectura u otro metodo por software que saque mas con menos, no se, igual nos sorprenden.
Me gustaMe gusta
Tras ver lo de gran turismo y ver dientes de sierra haciendo zoom en una captura estoy seguro de que lo van a dar como opción en ps5, elegir entre resolución o raytracing siempre que este aguante 60 fps
Lo interesante es el upres por IA también usado como antialiasing parecido a supersampling
Si dos pasadas equivalen a ssaa x64 es que una equivale a x8. Y sin ghosting a diferencia del TAA.
Asumo que necesita hacer x4 para eliminar sus propios artefactos de reescalado, por lo que una pasada vale para upres x2 y ya estaría filtrado con ssaa x4
Por lo que da un buen resultado de partida para la segunda pasada, y mas resolución de partida, por lo que quizá la segunda pasada pueda hacer upres x4 y ssaa x2 para eliminar los artefactos.
Tal vez con dlss x2 puedan subir de 1/2 full hd hasta 4k sin los artefactos del checkerboard, que creo que es lo que causa el escalón en la siguiente:
Creo que en esta captura nvidia parte en ambas de mitad de 4k, en una con checkerboard y en otra con upres x4
El ctaa tx16 decian sus desarrolladores que eleva el prefiltrado de msaa x2 hasta msaa x8 al reciclar frames, por lo que debe ser equivalente pero con ghosting a hacer checkerboard y filtrar el resultado con una pasada de ctaa.
Lo interesante es que se puede hacer otra como he dicho antes…
Pues bien, el raytracing, svogi, svoti, voxelizacion, vxao, etc tienen un consumo directamente relacionado con la resolución de partida antes del DLSS…
Seguro que es un despilfarro hscer dlss con fp32 en ps4, en pro puede ahorrar con fp16 pero las rtx lo hacen con fp8 si no me equivoco. Solo hace falta que la next gen pueda trabjar en fp8 sin desperdiciar.
Me gustaMe gusta
Con dlss hacen upres porque bajan la resolución lo que es demostrado por la subida de rendimiento
Así que va a haber resolución fake (checkerboard + TAA actual, bajada de resolución y upres + ssaa con upres por IA tipo DLSS) Y TAMBIÉN FPS FAKES que ya se hace en realidad virtual tanto en oculus como en vive como en mixed reality como en psvr, interpolando y usando vectores de movimiento.
Me gustaMe gusta
6ms de tiempo tarda el DLSS de Nvidia para escalar de 1440P a 2160p/4K… 6ms que no es poco.
Me gustaMe gusta
¿Pero reescalar de 1140×810 que es mitad de full hd? ¿1,5 ms?
Y ten en cuenta que sustituye a otro AA.
¿Y si le damos una segunda pasada de 1080p a 1/2 4k suma 3 ms de deficit? Suponiendo que otro AA convencional solo gaste 1,5 ms
Mitad de 4k con raytracing lo veo de cojones.
En el pdf de detroit desglosan el tiempo y gasta más de la mitad del disponible por frame en iluminación. Puestos a gastar así bien podrian hacer raytracing a 1/2 de 1080p, pero claro, sigue siendo mucho para ps4 estándar.
Me gustaMe gusta
Y no olvides las comparativas de frames, con dlss rinde más y ademas saliendo el AA gratis, porque bajan la resolución nativa y no se nota.
Me gustaMe gusta
1440×810 quería decir
Me gustaMe gusta
https://hardwaresfera.com/noticias/hardware/battlefield-v-podria-recibir-la-tecnologia-dlss-en-breve-que-es-exclusiva-de-las-nvidia-geforce-rtx/
Recientes filtraciones indican que una RTX 2060 puede llegar a los 90FPS en FullHD con el Battlefield V. Si se activa Raytracing el rendimiento cae hasta los 65FPS pero si se activa el DLSS el rendimiento sube hasta los 88FPS.
Me gustaMe gusta