Blog Personal.

Conceptos Básicos, Feedback, Futuro

Unreal Engine 5 (I) (Feedback)

Bueno, vamos a hacer el Feedback ya que no me esperaba unos 18 comentarios de repente.

Comentario#1:

¿Entonces cuando dice que la demo tecnica es totalmente jugable mienten?

hacia el minuto 16, cuando Geoff Keighley les pregunta.
https://www.youtube.com/watch?v=I9vhEm0rjJk

Mas tarde también indican que aunque sea una demo, no es un juego en desarrollo y que la demo habían realizado para mostrarla en el GDC
En twitter creo que fue, o en otra de las entrevistas tengo que revisarlo, comentaron que si no hubiera sido por el covid, la demo hubera sido disfrutable para que los visitantes gdc la probaran en su stand, pero que no podian lanzarla para su testeo publico, como hicieron con las de star wars y tal, ya que nadie tiene sdk de ps5 salvo algunos desarrolladores en estos momentos.

No, no mienten sino que el problema es el contexto y como la gente confunde una demo técnica en tiempo real con una demo jugable. El hecho de que hablen de la GDC que es una feria de desarrolladores y no de promoción de juegos como era el E3 y la comparen con la demo de Star Wars del año pasado es sintomático sobre que tipo de demo se trata.

En realidad lo que buscan es vender un motor a futuro.

Comentario#2:

Entonces todo movimiento de cámara está predeterminado en la demo? Incluso cuando al principio activan el modo drone para mover la cámara por la escena y esta sigue activa? No logro entenderlo, una vez calculada la luz y rebotes sobre la geometría de escena debería dar igual desde donde mires (cámara), los cambios que se produzcan de los objetos sería cuando habría que recalcular incidencias lumínicas, no? O me he perdido algo o me he perdido del todo 🤔🙃

No, no es predeterminado pero hay que tener en cuenta el problema que supone la voxelización para crear una estructura de datos espacial basada en estos. Precisamente la ventaja de los SSD de la que nadie habla y que NO es exclusiva de PS5 sino una ventaja general de todos ellos es el hecho de que los tiempos de búsqueda no tienen milisegundos extras por la naturaleza del medio.

¿Que tiene que ver? Bueno, cada vez que se genera una estructura de datos espacial según la posición de la cámara esta se almacena en memoria por si luego la vista de cámara pasa bajo las mismas circunstancias. Obviamente la primera vez que ejecutas la demo la construcción de dicha información es lenta pero una vez ya has generado la información pasa a estar disponible para no tenerla que calcular de nuevo. Eso si, a cambio de tener un alto coste en el almacenamiento del SSD.

Comentario#3:

La demo es completamente jugable y está en los devkits de ps5.

También han contestado en Twitter diciendo que no es un pasillo de carga de nivel sino que es para ver muchos detalles cerca.

Con ssd y streaming de polígonos no veo por qué necesitarían un pasillo de carga, y menos cuando al volar no se ve popping ni LOD

Pasillos van a continuar existiendo pero ya no serán de carga sino de transición de una parte a la otra al escenario. Por otro lado si en el diseño de niveles es necesario colocar un pasillo o porque la parte arquitectonica del nivel lo requiere por el diseño del mismo… ¿Acaso van a prescindir de ello? Lo de decir que vamos a dejar de ver pasillos es cuanto menos sumamente atrevido, otra cosa es que desaparezcan los pasillos de carga que lo van a hacer u otros trucos similares.

Comentario#4:

Urian para entender Lumen, debes buscar las tecnicas SSGI(SSRTGI) y Voxel Cone Tracing. Aqui te dejo una de SSRTGI:

https://80.lv/articles/ssrtgi-toughest-challenge-in-real-time-3d/

La razon porque no se usa BVH y hardware dedicado, es porque no es una tecnica basada en Ray Tracing puro o geometria, si no combina tecnicas de screen Space y voxel.

La SSGI es una tecnica parecida al Ray Tracing, se disparan rayos por pixel desde la camara(patch tracing) pero en ves de utilizar la geometria, se utiliza los datos de profundidad y color de buffer del espacio en pantalla, con ello se puede calcular la oclusión ambiental y la luz indirecta(GI), es parecido al SSAO y a los reflejos SSR, solo bastante mejor, el Benchmark de ungine Superposition esta basado en ello y debido a su naturaleza de funcionar en buffer hay shader bastante famoso que se puede aplicar con reshade en muchos juegos.

Pero no es una tecnica que se pueda aplicar individualmente por su naturaleza de screen space, epic con lumen la combinado con otra de voxelizacion.

Los desarrolladores no se tendran quebrar la cabeza lumen es una tecnica que funciona con shaders tradicionales y es barata comparado al Ray Tracing GI, no tiene nada de complicado su implementacion.

Tienes una obsesíón de buscarle los cinco pies al gato con lo que escribo que a veces da mucho asco.

Vamos a ver, el Voxel Cone Tracing no tiene nada que ver con Lumen ni tampoco el SSGI por un motivo, En el caso del SSGI Epic ya implemento el SSGI en el Unreal Engine 4 por lo que no es novedad. Lumen es simplemente trazado de rayos pero utilizando voxelización para crear la estructura de datos y esto no es compatible con las unidades de intersección que utilizan Turing y RDNA 2 en estos momentos por lo que la intersección se tiene que realizar via shaders por el hecho de que no han seguido el estándar.

El problema es que la implementación del Trazado de Rayos ahora mismo de cara a los juegos es una implementación incompleta donde:

  • Los desarrolladores han de decir explicitamente que superficies emiten un rayo y como.
  • Todavía se utilizan técnicas propias de la rasterización.

De cara a la iluminación directa el hecho de utilizar trazado de rayos no aporta ninguna ventaja respecto a la rasterización, es por ello que se renderiza primero la escena con iluminación directa y la iluminación indirecta luego es invocada durante el post-procesado dependiendo de los recursos del sistema pero hay que tener en cuenta que habra situaciones en la que no se tirara del trazado de rayos para solventar ciertos problemas por falta de velocidad y rendimiento.

Y si, se que suena muy…

Cada tipo de efecto de iluminación indirecta necesita su propio tipo de rayo definido. Las sombras necesitan un tipo de rayo, los reflejos. En realidad cuando se habla de iluminación global dinámica se habla la mayoría de veces de hacer rebotar un rayo de luz varias veces pero si quieres que genere sombras, reflejos… Tienes que generar los rayos de ese tipo en paralelo a la trayectoria del rayo.

Es decir, puedes hacer que el rayo de luz rebote por la escena y que no genere ni rayos de sombras ni reflejos, los cuales los has de invocar explicitamente. Es decir, cuando en el pipeline tenemos que invocar un nuevo rayo explicitamente a través del «Ray Generation Shader» si queremos que el objeto refleje o genere sombra hemos de invocar los rayos correspondientes a ese fenómeno.

Vamos a ver muchos motores y juegos que para lo que es la iluminación la hagan rebotar tres veces e incluso cuatro pero no la vamos a ver generando sombras o reflejos por el hecho que los programadores no querran y aquí tengo que pedir disculpas por no explicar una parte en la entrada.

Una cosa que me salte a la hora de analizar es lo de los mapas de sombras virtualizados, Epic ha decidido no tirar del sombreado via trazado de rayos y ha tirado de los mapas de sombras pero aprovechando la velocidad del SSD para crear varios Mip Maps de un mapa de sombras, es decir, versiones a menos resolución de los mismos.

Los mapas de sombras se generan renderizando la escena pero colocando el emisor de la sombra como cámara de la escena y almacenando solo los valores del Z-Buffer (no hay texturizado) como el mapa de sombras a utilizar en la escena. El planteamiento es el mismo en el mapa de entornos (reflejos) y de luces utilizado de manera tradicional y en muchos casos este tipo de mapas son pre-generados durante el desarrollo y una cosa que vamos a ver a medida que el trazado de rayos avance es el hecho que estas técnicas se van a extinguir pero como estamos en un periodo de transición pues las vamos a continuar viendo un tiempo como es el caso.

Si los mapas de sombras son de 16K x 16K pixeles contando incluso la compresión de texturas para ello esto es una cantidad ingente de memoria necesaria, de ahí a la importancia del SSD para ir moviendo rapidamente los datos y sin esperas. El hecho de que la demo del UE5 no utilice el trazado de rayos para sombras es sorprendente, pero es una consecuencia indirecta de tomar un camino diferente al del estandar que han decidido seguir los fabricantes de hardware.

¿El motivo de ello por parte de Epic?

No, en serio, no lo se y no digo que sea bueno o malo. El problema es que la demo funciona en resolución dinámica por lo que utiliza todos los recursos del hardware y si resulta que tirar del trazado de rayos que han optado como estándar es más rápido pues van a optar por ello. Precisamente si hay algo que me parece interesante de los efectos derivados del trazado de rayos es que una vez solventada la intersección estos son más rápidos de ejecutar.

Bueno, en realidad si que lo se, el motivo de ello es que el trazado de rayos via BVH pese a que es mucho más fácil de implementar via función fija que el voxelizado en hardware sin esa función fija es extremadamente lento. Es decir, es una solución de Epic de buscar un tipo de trazado de rayos reducido para hardware más modesto y sin ese tipo de unidades pero esta claro hacía donde irán las cosas.

Comentario#5:

Muchas gracias Urian. Tenía dudas sobre si Lumen podría de algún modo usar las unidades de intersección para acelerar su rendimiento. Veo que no.

Para la iluminación directa no es necesario ninguna técnica más allá de la rasterización tradicional ya que las ventajas de los algoritmos basados en trazado de rayos empiezan a partir de la iluminación indirecta.

Si quisiéramos iluminación global sólo para la iluminación directa ¿se podría usar Lumen? Entiendo que sería sólo la voxelización.

Por definición eso es imposible:

  • Iluminación Directa: 0 rebotes, el objeto afectado no emite luz.
  • Iluminación Indirecta: 1 rebote (el objeto afectado emite luz)

Se le llama iluminación global cuando la luz hace 2 rebotes o más…

El trazado de rayos se basa en simular el recorrido de la luz en un espacio tridimensional, la cantidad de rebotes van a depender si el objeto esta programado para emitir luz o no y de como la transmita. Cada tipo de material tiene un coeficiente de emisión que va de 0 a 1, dicho coeficiente de emisión se multiplica con la energía del rayo, si el coeficiente es cercano a 0 entonces la energía se atenuará y si llega a 0 el objeto no emite luz.

Black hole in space. Abstract background.

Si el objeto llega a 1 entonces emite la energía tal cual, es el caso de los espejos.

En el caso de los juegos cada rebote ha de ser explicito para no gastar recursos con rebotes más allá de lo que se puede procesar. Los rayos van a desaparecer cuando se llegue a una energia minima que no tiene porque ser 0, se puede marcar un coeficiente de por ejemplo 0.3 y que todo objeto que tenga ese coeficiente o menor no genere luz. Otra forma de hacer desaparecer los rayos es cuando estos salen de escena.

La gran ventaja del trazado de rayos no es solo que representa la luz indirecta de manera mucho más precisa que la rasterización sino también la naturaleza de los materiales.

Esto no lo veremos de la noche a la mañana sino progresivamente en los años siguientes. Estamos en un periodo de transición que va a durar una generación entera. No vamos a estar en la generación del trazado de rayos como norma general sino en la que es el camino hacia al trazado de rayos.

Más sencillo, que me hago un lío, ¿cómo crees que Lumen podría combinarse con raytracing? ¿Ofrecería ventajas al desarrollador o al rendimiento?

Lumen se basa en un tipo de trazado de rayos, el cual no es un algoritmo general del que se han derivado una cantidad ingente de algoritmos. Obviamente no es el de las películas por no hay la potencia suficiente sino una aproximación.

Esto es todo, tenéis el Discord y los comentarios de esta entrada para comentarla.

0 0 vote
Article Rating
7 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Nitupensis

Entonces el lio lo esta montando los chicos de Epic, ya que dicen que la demo es jugable y la gente lo entiende como tal, ahora revisando de nuevo el video veo que han hecho una edición si bien no del video, si de la transcripción de los subtitulos cuando Geoff Keighley pregunta hacia el minito 16:50… «just want to confirm like what we’re seeing there that’s all like you can actually play that with a controller like that’s not kind of frame dumped or anything?» Kim Librari responde, al inicio incluso asintiendo con la cabeza… «Is fully playable demo…»… Read more »

jose diaz

A mi me ha parecido entender que «la demo» se ejecuto cuando anteriormente habia sido jugada o cargada en el ssd y memoria y que eso le proporciono una mejora en rendimiento.

Lalilulelo

No, habla de la voxelizacion precalculada.
comment image?version=1&modificationDate=1562912994000&api=v2

Pero yo creo que no le afecta para nada el recorrido de la cámara.

Se almacena igual que un escenario .bsp pero con mayor subdivisión, 8x8x8 en vez de 2x2x2 de un árbol binario.

Quake 1 usaba una herramienta que descartaba los polígonos que no serían visibles desde dentro del escenario, como las caras exteriores el escenario o el interior de los objetos macizos. Pero no tenía nada que ver con el recorrido que hicieras. Y estoy seguro de que con lumen tampoco.

comment image

Set

Lo siento si te doy asco, pero si hay cajas de comentarios es para opinar y si veo fallos es par comentarlos y aprender, si no te gusta las opiniones correctivas tan facil como ignorarlas. Y es que fallos como que la Iluminación Global solo es con 2 rebotes, es un error que no se puede obviar, dentro del mundo de programacion y si buscas su definición, iluminación Global se le llama a luz indirecta, y la luz indirecta comienza desde el primer bounce, la luz directa impacta en una superficie y esta rebota, a este rebote se le llama… Read more »

Lalilulelo

¿Dices que Lumen es sparse voxel octree cone tracing + screen space reflections?

¿La oclusión ambiental sería parte de ese cone tracing además del color reflejado como esto?
comment image

Ger

Gracias por la respuesta. Estaba releyendo tu entrada del upstreaming de amd y me vino a la cabeza algo que me llamó mucho la atención con la ya famosa demo que dijo alguien de epic y es que «PS5 dispone de una ingente cantidad de memoria flash muy muy cerca del procesador». Hay relación?