Dentro de Immortals of Aveum la entrevista técnica de Digital Foundry

Inside Immortals of Aveum Digital Foundry's technical interview

Desde una perspectiva tecnológica, Immortals of Aveum de Ascendant Studios es un juego altamente importante. Excluyendo Fortnite, creado por Epic Games en sí mismo, es el primer juego triple A que se lanza con todas las características de vanguardia de Unreal Engine 5 en su lugar. Eso incluye Nanite basado en microgeometría, capaz de niveles asombrosos de detalle, junto con Lumen, una solución de iluminación global basada en trazado de rayos y mapas de sombras virtuales. Antes de Fortnite, The Matrix Awakens fue el único lanzamiento de UE5 basado en consola que vimos con esas características, se veía increíble pero con problemas de rendimiento obvios.

No solo Ascendant está utilizando todas las características de UE5, también apunta a 60 fps en consolas. Es un juego altamente ambicioso, pero como reveló la reseña de DF de ayer, el cálculo de la GPU solo puede llegar hasta cierto punto, por lo que la calidad de la imagen necesariamente tiene que sufrir, con FSR 2.2.1 utilizado para aumentar la resolución base de 720p en Xbox Series X y PlayStation 5.

Al entrar en el proceso de revisión, estábamos muy motivados para descubrir más sobre lo que hace que el juego funcione, por lo que cuando EA nos ofreció la oportunidad de hablar con el equipo de desarrollo, aprovechamos la oportunidad. Alex Battaglia y Tom Morgan hablaron con Mark Maratea, Julia Lichtblau y Joe Hall de Ascendant Studios, y aquí está esa conversación.

¿Cuánto tiempo ha estado en desarrollo Immortals, y la idea siempre fue producir algo similar a un shooter en primera persona mágico o evolucionó durante el proyecto?

Mark Maratea: La compañía se formó para hacer este juego, y llevó una parte significativa de tiempo para prepararse… luego llegó el Covid, por lo que el reclutamiento se convirtió en un período muy interesante. Este juego tiene cinco años, en todos los sentidos.

• El papel de Pedro Pascal en Law & Order, explicado
• Los Mejores Juegos de Xbox Series X Que Pueden Ejecutarse a 4K y 60...
• Star Wars ¿Cómo volvió Palpatine en El Ascenso de Skywalker?

Julia Lichtblau: Un par de meses después de que Brett [Robbins] fundó el estudio en realidad, le entregó a Dave Bogan, el director de arte principal, y a mí este documento de presentación de 60 páginas, que supuestamente era un shooter mágico. Tenía la premisa básica de [el protagonista] Jack y esta gran historia. Obviamente, las cosas cambiaron un poco, como los detalles del combate, pero él sabía que Brett sabía que quería hacer este juego de shooter mágico porque era algo que no existía antes y era un juego que realmente quería jugar y hacer.

Basándonos en el momento, imagino que el juego no comenzó en Unreal Engine 5 ya que no existía, ¿así que comenzó en Unreal Engine 4 y migró a UE5? ¿Cómo fue eso?

Mark Maratea: El proyecto comenzó usando UE 4.20, que salió en julio, y la compañía se formó en agosto [2018]. Cuando la compañía comenzó, todo se hizo en blueprints sin cambios en el código del motor, como si fuera un proyecto indie más pequeño para prototiparlo… Esto podría haber cambiado; la realidad de las decisiones comerciales en torno a esto es que si alguien hubiera entrado como editor tres meses después y dijera: “te aceptamos, pero estás usando Frostbite o lo que sea”, eso hubiera requerido un cambio. Somos lo suficientemente afortunados de tener una fuente de financiación muy generosa… un socio increíble, por lo que nos ha dado autonomía para tomar estas decisiones. Comenzamos con 4.20 normal, 4.21 normal, motor personalizado 4.23, 4.25, 4.26, vista previa de UE5, UE5 real, UE5.1 y ahora estamos lanzando como UE 5.1.1.

Entonces mencionaste que comenzaste con blueprints y cambios mínimos en el código, pero con 4.23 pasaste a un motor personalizado, ¿cuáles fueron esos cambios más grandes que lo hicieron divergir?

Mark Maratea: Ya sabes, el comienzo de todos estos cambios solía ser “… y luego un diseñador o un artista pidió esta cosa imposible, y tuvimos que hacer un cambio en el motor”. Para el nivel de las ruinas en particular, tuvimos que hacer algo de magia en la versión de UE4 debido a la forma en que se diseñó el nivel; en realidad tuvimos que mover el sol en el cielo. Esto no parece gran cosa hasta que recuerdas que UE4 se basa en iluminación precalculada, así que eso se convirtió en un gran problema y requirió mucho trabajo.

Este juego siempre ha sido 10 libras de juego en una bolsa de cinco libras. Nuestro sistema de combate ha evolucionado y se ha convertido en el génesis de muchos de nuestros cambios en el motor, ya que construimos nuestro sistema de combate en el Unreal Gameplay Ability System, que fue diseñado para un MOBA. Es un buen marco de trabajo para un sistema de habilidades replicado en red y lo usamos para todas las armas del juego: armas de fuego de disparo rápido, armas apuntadas y controladas, así que realmente nos salimos de los límites de ese sistema. Así que el primer conjunto enorme de cambios fue tomar el sistema de jugabilidad del juego y hacer que funcione de la manera en que queremos que funcione el combate.

Lo siguiente fue la composición del mundo: ¿cómo se transmite [datos] el juego, dónde vive todo? Hicimos cambios enormes en ese sistema para poder adaptarnos a estos mundos extra grandes y transitar a través de ellos y mantenerlos dentro de nuestro presupuesto de memoria… y luego sucede la magia de UE5 y la composición del mundo deja de existir porque la han dejado de usar. Como puedes imaginar, fue una transición para todos nosotros: ingenieros, todos nuestros equipos de contenido, artistas de niveles y diseñadores de niveles en particular. Fue como decir “aquí está la nueva biblia de cómo construir un juego” y ellos respondieron “en primer lugar, ustedes necesitan aprender a escribir… y en segundo lugar, eso es una locura”. Fue un proyecto de innovación a nivel de estudio enorme, tuvimos que prototipar cuál era la forma correcta, establecer las reglas, averiguar en qué se equivocó Epic, cambiar la forma en que funcionaba nuestro juego, reescribir las reglas nuevamente y eso fue un proceso continuo hasta incluso los últimos seis meses.

Tomamos la versión 5.1 durante las vacaciones de Navidad y pasé mis vacaciones integrando [esa versión]… cuando pasamos a la 5.1, no podíamos cargar ningún activo en el juego, así que tuve que básicamente reescribir todo el cargador de activos en dos días para que eso no ocurriera y no perdiéramos todo nuestro progreso.

Ese es el costo de mantenerse actualizado, ¿no es así?

Mark Maratea: Sí, pero definitivamente valió la pena.

¿Seleccionaste alguna función de precarga de sombreadores de la versión 5.11 o 5.2?

En realidad, estoy en medio de una discusión en Slack sobre si necesitamos incluir algo de la versión 5.2 para ayudar con esto. Así que la precarga de PSO en la versión 5.1 funciona, pero si miras el código, la primera línea es un comentario que dice “esto no funciona, no uses esto”, y tiene salidas tempranas hacia otras secciones de código. Estaban tratando de hacer una precarga adaptativa, lo cual causaba fugas de memoria y eventualmente bloqueos al liberar activos, lo cual es malo, pero en la versión 5.2 todo eso está arreglado. Desafortunadamente, estamos justo en el límite entre la versión 5.1.0 y la versión 5.2, que funcionan de cierta manera, y la versión 5.1.1 que intentaron que funcionara pero no lo logra del todo.

Así que hemos tenido que hacer algunos cambios, estamos utilizando la precarga de PSO combinada con la caché normal de DX12. Hay una línea desechable en la documentación [de Epic] que dice “cuando haces la precarga de PSO, por defecto cacheará todos los PSO que pueda encontrar y luego los cargará todos de una vez”. Y esa parte de “cargarlos todos de una vez” [es problemática]. Tenemos muchos sombreadores en nuestro juego, hicimos un sistema increíble y diferente que utiliza ramificaciones dinámicas, y en realidad reescribimos parte del pipeline de sombreadores, lo que nos da 3-4ms menos en nuestros tiempos de renderizado, realmente algo importante. El inconveniente es que aumenta las permutaciones de sombreadores, así que tenemos 5,7 millones de sombreadores con permutaciones completas… eso genera 563 mil objetos PSO, así que cuando inicias el juego intenta cargar medio millón de PSOs.

¿Explica eso lo que vi cuando cargué el juego sin el archivo .ini? [nota: el código de revisión para PC se envió sin un archivo .ini crucial, lo que causó problemas iniciales rápidamente resueltos] Estoy acostumbrado a ver que la CPU se pone al máximo [al hacer la precompilación de sombreadores], pero aquí parecía que la CPU tenía problemas incluso para alcanzar la plena utilización.

Mark Maratea: Sí, todo tiene que ver con la E/S. Es un poco la peor versión de la E/S porque estás cargando los PSOs desde la caché a la memoria, procesándolos y guardándolos de vuelta en tu unidad C:. Y así estás evitando todas las optimizaciones porque tiene que ir a una unidad diferente; la mayoría de las personas ya no tienen su biblioteca de Steam en la unidad C:, y estás evitando cosas como DMA y DirectStorage que no funcionan, así que tienes una penalización.

¿Mencionaste DirectStorage, lo estás usando en las consolas Xbox Series o en PC?

Mark Maratea: Sí, si [DirectStorage] está presente, Unreal automáticamente intentará aprovecharlo. También aprovechamos el cómputo asíncrono, lo cual es un impulso de velocidad maravilloso cuando se combina con DirectStorage, ya que nos permite cargar los sombreadores de cómputo directamente en la GPU y luego hacer cálculos mágicos para que el juego se vea mejor y sea más impresionante. Nos permite ejecutar partículas de la GPU sin causar una carga asíncrona en la CPU y no afecta el hilo del juego.

Jugué los primeros 25 minutos del juego y no tuve problemas de compilación de sombreadores, lo cual es raro en un juego de Unreal Engine.

Mark Maratea: No habrá interrupciones de optimización de estado de pipeline en todo el juego. Lo digo en voz alta en este momento, públicamente, está registrado.

¿Cómo fue implementar Nanite en el juego y cómo se comparó con la creación habitual de LOD?

Julia Lichtblau: En el lado artístico, en realidad comenzamos a construir este juego en Unreal 4, por lo que muchos de nuestros kits iniciales se basaron en ese flujo de trabajo tradicional. Cuando cambiamos a Nanite y UE5, hubo mucha emoción porque pudimos incluir mucho más detalle en los propios activos… Originalmente se creaba un modelo de alta poligonización en ZBrush, que se reducía a la textura y material clásicos para obtener su forma, manteniendo un bajo recuento de polígonos. Pero cuando cambiamos a Nanite, de repente pudimos volver a los activos de alta poligonización. Descubrir cómo desplegar algo de esa densidad definitivamente implicó repensar el flujo de trabajo, porque ahora estás tratando con muchos más GameTopics, en los millones… Una vez que estuvo en el motor, fue increíble comenzar a agregar millones y millones y millones de polígonos al motor sin que se bloqueara por completo.

Hubo algunas veces en las que, al importar, a veces la marca de Nanite no se mantendría, y estaríamos volviendo a importar un estante de libros de varios millones de polígonos, preguntándonos por qué el motor se entrecortaba cuando mirábamos en esa dirección. Se podía ver que Unreal no sabía cómo manejar eso, pero tan pronto como marcabas esa casilla, lo manejaba todo. Realizaba los ajustes dinámicos de LOD y los clústeres justo hasta el punto en que nuestra fluidez de trabajo se aceleró significativamente, y fue increíble saltar a la vista de Nanite y ver cómo los clústeres se ajustaban en tiempo real y cómo se optimizaban. Nos permitió construir este juego mucho más rápido con un equipo tan pequeño.

¿Cómo decidieron qué se haría con Nanite?

Julia Lichtblau: Cuando cambiamos a Unreal [5], activamos Nanite en todo lo que pudimos. Creo que en la versión 5.0 no era compatible con la vegetación, eso vino un poco más tarde, pero tan pronto como pudimos tener vegetación con Nanite, lo activamos. Luego comenzamos a retroceder y preguntarnos “¿realmente esto necesita ser Nanite?” Nos encontramos con algunos activos que presentaban problemas debido a su construcción y la forma en que se configuraron las conchas UV, por lo que tuvimos que rehacer algunos de esos activos para que funcionaran con Nanite o cambiarlos por completo y volver al método tradicional. No pudimos usar [Nanite] para cosas que se mueven, como las banderas. Realmente lanzamos todo al cubo de Nanite para aprender de ello. Ahora hemos podido construir una enorme página Confluence [wiki corporativo] sobre cómo se debe manejar Nanite en el futuro.

¿Cómo se traduce Nanite y los mapas de sombras virtuales en consolas como PS5 y Series X/S?

Julia Lichtblau: En el lado artístico, no hemos tenido que ajustar nada, ¡pero tal vez Mark haya estado haciendo cosas en el backend para que eso funcione y nosotros los artistas no tengamos que preocuparnos tanto!

Mark Maratea: Diría que de alguna manera funciona mejor en consolas, curiosamente. La geometría virtualizada de Nanite es muy intensiva en la transmisión de datos, todo se trata de la E/S del disco. Por lo tanto, UE5 está reescribiendo el pipeline de E/S y las optimizaciones que hicieron para las SSD NVMe. Está diseñado para funcionar en consolas. En PC, no tengo idea de cuál es el ancho de banda de E/S de nadie… El único inconveniente en las consolas es que cuando estás usando Nanite, realmente necesitas usar texturas virtuales en streaming, realmente necesitas una gran reserva de texturas virtuales. Las consolas tienen memoria fija, pero [una sola tarjeta gráfica] puede tener más memoria que la PS5. Por lo tanto, optimizar para ambas es realmente difícil.

Nanite hace un buen trabajo utilizando la memoria disponible, pero la excepción a eso es que las piscinas de texturas virtuales en UE no se pueden cambiar de tamaño: tienen que inicializarse al inicio del motor y no se pueden modificar nuevamente, [lo que proporciona] una memoria contigua completamente asignada que es maravillosa desde el punto de vista del rendimiento, pero [pueden surgir problemas donde, por ejemplo] hay una copa lejana, a dos píxeles de distancia, y necesita una parte de una textura [de una asignación de piscina de 500MB], y no tienes nada de eso hasta que la textura desaparezca. A la PC no le importa [quedarse sin memoria]; en el peor de los casos, se va a la memoria virtual. La consola dice “no tengo memoria virtual, estoy acabada”. Y no se bloqueará, pero causará problemas sustanciales. Esto causó lo que se conocía internamente como el infame error del paisaje, donde simplemente caminabas por ciertas partes del juego y parecía que alguien había pintado un paisaje de anime en el suelo, porque no se podía asignar para la piscina de texturas virtuales.

Nanite parece haber facilitado la vida en el aspecto artístico; ¿hay algún momento del juego del que estés especialmente orgulloso, un momento destacado de lo que puedes hacer con Nanite que no hubieras podido hacer sin UE 5.1?

Julia Lichtblau: En cada nivel realmente tenemos que esforzarnos en eso. Hay un nivel con un coloso gigante, este mecha gigante, y tiene geometría curva con mucha detalle; en su interior, cada remache está ahí y las aberturas en el suelo están modeladas para que puedas ver todos estos activos cilíndricos en movimiento y de alta poligonalidad que pudimos seguir agregando más y más detalle… Nanite ha abierto el mundo para hacer los niveles mucho más hermosos, porque ahora ya no tenemos que depender de mapas normales y ese tipo de trucos que se desmoronan [en un cierto ángulo de visión]. Ese problema ya no existe, porque la geometría está realmente ahí… puedes acercarte mucho y seguirá teniendo toda esa curvatura y detalle. Así que ha sido realmente genial experimentar con una variedad de texturas, superficies, formas y estilos arquitectónicos diferentes. Fue realmente divertido en el aspecto artístico empujar eso en todo el juego.

Joe Hall: Con los efectos visuales en UE5.1, introdujeron la transparencia con Nanite, que definitivamente necesitábamos. Hay un nivel de biblioteca donde este metal necesita erosionarse según la progresión del jugador, por lo que esos son activos de Nanite que realmente se erosionan con efectos de emisivos y partículas y utilizando la malla de respaldo dentro de ellos. Es realmente impresionante.

Tendremos que capturar estos momentos para nuestra cobertura…

Mark Maratea: Para ser honesto, los primeros 10 minutos del juego después de la cinemática del teatro, hacemos el paneo de Seren Underbridge – eso es todo en tiempo real, en el juego, totalmente iluminado, una zona del mundo de geometría Nanite. Eso es enorme, creo que muchos de nosotros olvidamos lo impresionante que es; cualquier otro juego lo habría pre-renderizado. Iluminación en tiempo real, molinos de viento en los edificios girando en tiempo real, mallas animadas… cada vez que lo miro, descubro un nuevo detalle. Nuestro equipo de arte es simplemente fenomenal, con lo que han hecho con UE5. Se salta el valle inquietante, entra directamente en “sí, esa es una ciudad normal”.

Con Nanite, puedes usar la replicación, rotación y escala del mismo objeto exacto para construir áreas, ¿cómo introduces variación en los entornos? ¿Hay un sistema de desgaste? ¿Hay detalle mezclable para agregar variación a ciertos activos?

Julia Lichtblau: No tenemos un sistema de desgaste; hemos utilizado diferentes instancias de material para agregar, por ejemplo, diferentes colores de pintura a los edificios, y una serie de calcomanías que permiten tener, por ejemplo, ciertas áreas con estuco desmoronado, o marcas de suciedad, o graffiti o ese tipo de cosas. Gran parte de ello fue agregar geometría [hecha a mano]: tomar un edificio y agregar un montón de accesorios a su alrededor. Construimos estos planos de barrios marginales que tenían muchos accesorios intercambiables, por lo que no comenzamos colocándolos a mano, sino que pudimos agregar ese detalle artístico, esa sensación de vivido, para contar una historia ambiental, así que siento que eso nos permitió agregar variedad a la mayoría de estos activos.

¿Con 60fps en consolas, ¿estás utilizando el software Lumen? Y con PC, ¿obtienes automáticamente el software Lumen, o elige entre el hardware y el software Lumen según tu configuración?

Mark Maratea: Sí [para el software Lumen en consolas]. [En PC] actualmente es software, tenemos opciones para ambos. Esto vuelve a los problemas de almacenamiento en caché de PSO; resulta que tan pronto como activas el hardware [Lumen], se duplican las permutaciones de sombreado porque se construyen las versiones de hardware y software, y decidí que no deberíamos hacer eso a las personas de inmediato.

Una de las cosas que puedes hacer con el almacenamiento en caché de PSO para evitar algunos de estos problemas es utilizar un sistema de enmascaramiento. Así que necesito volver atrás y volver a capturar todos los [10 millones] de PSOs en el juego. Y necesito instrumentar el juego con un uint64 bitflag que diga, esta es la etapa uno, esta es la etapa dos, esta es la etapa tres, en todo el juego, y luego hacer la precarga, en orden, en diferentes momentos, en diferentes niveles. Así que necesito construir ese pequeño sistema e incorporarlo, luego podremos poner el hardware [Lumen] sin que cause una reconstrucción de sombreadores de cinco minutos al comienzo del juego.

Con el hardware Lumen, con todos sus detalles lejanos, ¿te encontrarás con problemas de CPU?

Sí. El hilo de dibujo se carga mucho. El cambio más grande de software a hardware Lumen es que pasa de 200m a 1000m. Hay un problema secundario sorprendente cuando comienzas a agregar fuentes de luz desde cinco veces la distancia, que es que ahora estás obteniendo reflejos de luces desde cinco veces la distancia. A Lumen realmente le gusta manejar los reflejos en todo, y tenemos muchas luces, así que ahora comienzas a jugar con otros parámetros para evitar tener demasiados reflejos en todos tus materiales brillantes. El equipo de Julia ama los materiales brillantes, tenemos muchos, así que es un equilibrio constante entre tener muy pocos y tener demasiados reflejos. Si optimizas en la dirección equivocada, se vuelve confuso o se convierte en un festival de destellos brillantes, ninguno de los cuales es genial. Así que estamos enhebrando la aguja muy estrechamente para [equilibrar la velocidad de fotogramas y la fidelidad visual]. Eso requiere muchas pruebas y no puedes romper otras cosas mientras lo haces.

Nuestra especificación mínima actual es un RX 5700 XT y RTX 2080. Supongo que las especificaciones actualizadas están en manos de la gente; de hecho, hemos podido bajar un poco los requisitos mínimos. Hemos estado trabajando arduamente para reducir eso mucho más allá de cualquier cosa que admita RTX. El efecto secundario de eso, obviamente, es asegurarnos de que el software [Lumen] en PC no se deteriore a medida que comenzamos a optimizar para el hardware [Lumen].

Volviendo a Lumen, ¿llega a la configuración ultra para la iluminación global y los reflejos? ¿Dónde se encuentran las consolas dentro de estas configuraciones?

Mark Maratea: Básicamente están en medio, apuntando a 1080p 60fps con escalado.

Es increíble ver que el juego soporta Nanite y Lumen desde el principio en consolas a 60fps. ¿Siempre fue parte del plan? ¿Hubo un momento en el que consideraron ir por 30fps?

Mark Maratea: Pasamos los primeros dos años persiguiendo nuestro objetivo visual [en lugar de un objetivo de fps], con el equipo de arte liderando esa carga. Al mismo tiempo, teníamos al equipo de combate y a Brett [director del juego] trabajando, y el equipo de Joe asegurándose de que los visuales del combate cumplieran con los objetivos de diseño. Una vez que esas dos cosas se consolidaron, teníamos una máquina que se ejecutaba de manera constante a 45-50fps en modo de desarrollo, y Brett estaba jugando eso y dijo: “OK, no, ya no me gusta 30. Este juego necesita ser a 60, el combate no se siente bien a 30”. Y así, como equipo, pivotamos.

Desde entonces, hemos eliminado muchas de esas interrupciones, lo que nos ha permitido bajar un poco los requisitos mínimos. No recomiendo que nadie haga esto, pero si alguien lanzara [una GTX] 1060 a este juego, en realidad funcionaría. No está optimizado para eso; tampoco es una tarjeta de 8GB, así que tendrías que tener mucho cuidado. Unreal se enoja mucho si no tienes suficiente memoria de sombra virtual para la resolución en la que estás jugando. Si estás jugando a 1080p, no es tan grave, pero como jugador de élite de PC exclusivamente en 4K, te puedo decir que es un gran problema cuando me quedo sin memoria de sombra. Ese es el lado técnico de esto, pero esta es realmente una pregunta de arte. Una vez que decidimos los 60, ambos equipos de Julia y Joe siguieron caminos increíbles para hacer que RT se ejecutara en ese punto.

¿Qué hay de otras configuraciones equivalentes a consolas? ¿La PS5 y la Series X están en medio para la mayoría de las configuraciones, o pueden ir a ultra en algo?

Mark Maratea: A pesar de tener [un rendimiento] similar, la Series X y la PS5 manejan las cosas de manera diferente. La computación asíncrona funciona muy bien en una pero no tan bien en la otra, lo que cambia la carga de la GPU. Parte del proceso de ajuste de la consola nos llevó a construir la herramienta de rendimiento que tenemos en PC. Hicimos un gráfico de todas las variables de renderización que existen en el sistema de ajuste de Unreal, todos los rangos posibles, y ejecutamos el juego [con cada combinación de configuraciones], 17,000 veces. Y entendimos el compromiso entre rendimiento y visualización de todas estas cosas. Luego nos sentamos con el departamento de arte y llegamos a un punto intermedio donde tenemos lo que considero uno de los juegos de consola con mejor aspecto jamás creado que se ejecuta a una velocidad de fotogramas muy, muy buena.

El menú de gráficos de PC calcula una puntuación para tu CPU y GPU. ¿En qué se basa esto?

Mark Maratea: Epic construyó un programa de referencia sintética [que usamos] y obtiene números reales [que los usuarios ven], así es de donde viene. La CPU es esencialmente el rendimiento de un solo núcleo, la GPU es el rendimiento de la GPU en todos los aspectos. Una CPU de especificación mínima está alrededor de 180 o 200, ultra está alrededor de 300; una GPU de especificación mínima está alrededor de 500, ultra comienza desde alrededor de 1200, que es donde aparece una 7900 XT o una 4080.

La confesión es que esto surgió de nuestro ajuste para las consolas, lo que significa que hace un par de semanas mientras me duchaba pensé “sería realmente genial” construir esta herramienta de rendimiento. Ahora, todos estos datos están llegando debido a eso, [lo que nos permite] exponer datos [sobre los costos de diferentes configuraciones gráficas] a los usuarios… [Si] alguien tiene un nuevo procesador o tarjeta de video, eso nos proporciona nuevos puntos de datos y eso puede cambiar los números. Básicamente, estamos recopilando una gran cantidad de datos sobre una amplia variedad de hardware y luego haciendo muy buenas suposiciones.

¿Está preparado para el futuro en términos de hardware futuro, o todavía implica mucho ajuste manual?

Mark Maratea: La versión actual es muy manual, pero la versión que verás será sustancialmente mejor. Si este juego vende como espero que venda en el día 60, realmente contará con varios algoritmos de mejora de la resolución, diferentes resoluciones, RT activado y desactivado, y realizará esencialmente predicciones de aprendizaje automático sobre hacia dónde se dirigirán las velocidades de fotogramas.

Eso me recuerda al Índice de experiencia de Windows [introducido con Windows Vista]. Siempre me dio mucha pena que los juegos no terminaran usándolo porque me pareció una idea realmente buena. Tu blog menciona el uso de FSR 2 en la consola, ¿qué te hizo elegir FSR 2 en lugar de TSR?

Mark Maratea: Rendimiento. Estamos utilizando FSR 2.2.1, estamos en la vanguardia con la versión de AMD. Tiene un rendimiento sustancialmente mejor en la mejora de la resolución y la mejora de la resolución de TSR tiene mucho más efecto fantasma que DLSS o FSR. Estamos constantemente en contacto con AMD, Intel y Nvidia para minimizar los problemas, y cada uno de ellos tiene sus laboratorios de compatibilidad que ejecutan todo esto, y hemos dedicado mucho esfuerzo a trabajar con ellos. Es un poco más difícil que Epic lance un cambio de motor para solucionar los problemas de TSR.

¿Qué hay de los objetivos de resolución específicos en las consolas? ¿FSR 2 en ultra apunta a 4K, o es una configuración más alta?

Mark Maratea: Solo en las consolas, se realiza un aumento adaptativo, por lo que observamos a qué te conectaste desde el punto de vista del monitor/TV… y hay una ranura en la lógica que dice que si sale una PS5 Pro, aumentará la calidad a diferentes niveles, será calidad FSR 2 en lugar del rendimiento estándar de FSR 2.

Entonces, si juegas el juego en una pantalla de 1080p, ¿podrías tener un rendimiento potencialmente diferente al jugar en una pantalla 4K?

Mark Maratea: Sí.

En cuanto a los sombreadores de ramificación dinámica que mencionaste, ¿puedes explicar las diferencias entre la base de UE5 y lo que están haciendo?

Mark Maratea: Sí, quiero darle crédito a [esto] a Joe Weyland, esto es su creación. Esto es como un documento técnico de nivel Siggraph. Hemos estado trabajando en esto durante aproximadamente 3.5 años. Tenemos un sistema jerárquico de creciente complejidad a medida que construyes tus sombreadores, puedes imaginar que el parámetro básico es “es brillante”, y luego hay un subelemento que es “es brillante o rugoso” o lo que sea. Entonces, con este tipo de sistema, hay muchas instrucciones que no necesitas; se evaluarán como “no usar”… pero la forma en que funciona el pipelining, la GPU todavía tiene que evaluarlas, lo que parece un desperdicio de recursos de la GPU.

Así que construimos un sistema inteligente de ramificación dinámica que nos permite podar de antemano las rutas de nodos que no se van a utilizar para un material en particular. Es una decisión en tiempo de ejecución, lo que nos permite hacer muchas cosas en el editor donde la gente puede ajustar algo de inmediato y ver los cambios de rendimiento y visualización en tiempo real. Pero esas decisiones se ejecutan finalmente en tiempo de ejecución. Esto nos permite tener diferentes ramas con extensiones específicas del fabricante de hardware, como extensiones de sombreado exclusivas de Nvidia donde ni siquiera verificamos en una tarjeta AMD. Así que eso nos da, dependiendo de la complejidad de la escena, alrededor de 2-5ms. Esto es un grupo de personas muy inteligentes que pasaron mucho tiempo construyendo su trabajo de toda la vida y, francamente, es asombroso.

¿Es siquiera posible considerar una versión para PS4 o Xbox One del juego, a la luz de que se anunció Jedi: Survivor para consolas de la generación anterior?

Definitivamente no. No hay una versión de Lumen que funcione en la generación anterior, ni siquiera en software. A menos que alguien llegara con un camión de basura lleno de dinero y dijera: “Queremos que desmontes todos tus niveles y los hagas funcionar con iluminación precalculada, y reduzcas todas tus texturas para que encajen en la memoria de la consola de la generación anterior”. Eso tendría que ser un gran camión de basura. Y esto es después de que Joe, Julie y yo nos fuéramos de vacaciones tropicales durante seis meses, luego regresaríamos y haría tu versión para la generación anterior. Quiero decir, básicamente estás preguntando si podemos reconstruir todo el juego desactivando una serie de características clave y reduciendo nuestro presupuesto de arte a una cuarta parte.

Definitivamente. Diría que en Digital Foundry… no hemos visto suficientes lanzamientos de nueva generación, especialmente después de tres o cuatro años en la generación. Somos grandes defensores del juego a 60fps, pero para las versiones de consola, ¿hay un modo de calidad o resolución más alta a 30fps en el horizonte?

Mark Maratea: Básicamente hacemos eso para el usuario; tenemos espacios no combativos donde hemos intercambiado la velocidad de cuadros por la fidelidad visual… vas a encontrar áreas que bajan un poco, sin combate allí y se verán excepcionalmente hermosas. Ya están en modo de calidad. Luego, a medida que te adentras en áreas que son espacios de combate, comenzamos a hacer intercambios: hay menos luces dinámicas, hay menos cosas únicas, comenzamos a eliminar personajes accesorios que podrían aparecer en una RTX 4090 para mantener la velocidad de cuadros.

Joe [Hall], ¿hay algo que te gustaría decir sobre los efectos visuales de los que estás realmente orgulloso, o algo que lograste incluir en el juego y no creías que fuera posible?

Joe Hall: Devolver el color. Devolver el color al combate, de una manera realista pero también mágica. Esto es definitivamente algo. Mantener [el juego] a 60fps, buscando momentos de alta fidelidad y alta calidad es algo de lo que estar orgulloso. Estoy orgulloso del equipo y de todo el esfuerzo que han puesto, de lo lejos que hemos llevado el listón. Definitivamente estoy agradecido de que exista UE 5.1. ¡Es emocionante para los jugadores unirse a esto!