Cómo se desarrolla un cuento de peste: el marco de la inocencia

Prólogo

Como en mis otros estudios, comencemos con la introducción. Hoy nos fijamos en el último juego del desarrollador francés Asobo Studio. La primera vez que vi un video de este juego el año pasado, cuando un colega compartió un avance del juego de 16 minutos conmigo. La mecánica de "rata contra la luz" me llamó la atención, pero realmente no quería jugar este juego. Sin embargo, después de su lanzamiento, muchos comenzaron a decir que parece que se hizo en el motor Unreal, pero esto no es así. Tenía curiosidad por ver cómo funciona el renderizado y cuánto los desarrolladores se inspiraron en Unreal en general. También estaba interesado en el proceso de renderizar una bandada de ratas, porque en el juego parecía muy convincente y también es uno de los elementos clave del juego.

Cuando comencé a intentar capturar el juego, pensé que tendría que rendirme, porque nada funcionaba. Aunque el juego usa DX11, que ahora es compatible con casi todas las herramientas de análisis, no pude hacer que ninguna de ellas funcione. Cuando intenté usar RenderDoc, el juego se bloqueó al inicio, y lo mismo sucedió con PIX. Todavía no sé por qué sucede esto, pero afortunadamente, pude completar varias capturas con NSight Graphics. Como de costumbre, elevé todos los parámetros al máximo y comencé a buscar marcos adecuados para el análisis.

Romper marco

Después de hacer un par de capturas, decidí usar uno de los primeros comienzos del juego para el análisis de cuadros. No hay mucha diferencia entre los agarres, y además, puedo evitar los spoilers.

Como de costumbre, comencemos con el cuadro final:


Lo primero que noté fue un equilibrio completamente diferente en este juego de renderizar eventos en comparación con lo que vi en otros juegos anteriores. Aquí hay muchas llamadas de extracción, lo cual es normal, pero sorprendentemente solo unas pocas se utilizan para el procesamiento posterior. En otros juegos, después de renderizar colores para obtener el resultado final, el marco pasa por muchas más etapas, pero en A Plague Tale: Innocence la pila de postprocesamiento es muy pequeña y está optimizada para solo unos pocos eventos de renderizado / computación.

El juego comienza a construir un marco al representar GBuffer con seis objetivos de renderizado. Curiosamente, todos estos objetivos de renderizado tienen un formato entero sin signo de 32 bits (con la excepción de uno) en lugar de colores RGBA8 u otros formatos específicos de dichos datos. Esto fue difícil porque tuve que decodificar cada canal manualmente usando la función Custom Shader de NSight. Pasé mucho tiempo descubriendo qué valores están codificados en objetivos de 32 bits, pero es posible que me haya perdido algo de todos modos.


GBuffer 0

El primer objetivo contiene algunos valores de sombreado en 24 bits, y algunos otros valores para el cabello en 8 bits.


GBuffer 1

El segundo objetivo se parece a un objetivo RGBA8 tradicional con diferentes valores de control de material en cada canal. Según tengo entendido, el canal rojo es metalidad (no está del todo claro por qué algunas hojas están marcadas con él), el canal verde parece un valor de rugosidad y el canal azul es la máscara del personaje principal. Ninguna de las capturas que hice utilizó el canal alfa.


GBuffer 2

El tercer objetivo también se parece a RGBA8 con albedo en los canales RGB, y el canal alfa en cada captura que hice fue completamente blanco, por lo que no entiendo muy bien qué deberían hacer estos datos.


GBuffer3

El cuarto objetivo es curioso porque en todas mis capturas es casi completamente negro. Los valores se parecen a una máscara de parte de la vegetación y todo el pelo / pelaje. Quizás esto tiene algo que ver con la translucidez.


GBuffer 4

El quinto objetivo es probablemente algún tipo de codificación normal, porque no los he visto en ningún otro lado, y el sombreador parece muestrear mapas normales y luego salir a ese objetivo. Con esto en mente, no he descubierto cómo visualizarlos correctamente.


Profundidad de GBuffer 5


Máscara de GBuffer 5

El último objetivo es una excepción porque utiliza un formato de coma flotante de 32 bits. La razón de esto es que contiene la profundidad lineal de la imagen, y el bit de signo codifica alguna otra máscara, enmascarando nuevamente el cabello y parte de la vegetación.

Una vez completada la creación de GBuffer, la resolución del mapa de profundidad se reduce en el sombreador computacional, y luego se representan mapas de sombras (mapas de sombras en cascada direccionales del sol y mapas de profundidad cúbica de fuentes de luz puntuales).


Rayos crepusculares

Después de completar los mapas de sombras, puede calcular la iluminación, pero antes de eso, los rayos de dios se representan en un objetivo separado.


SSAO

En la etapa de cálculo de iluminación, se realiza un sombreador computacional para calcular el SSAO.


Geometría opaca iluminada

La iluminación se agrega desde mapas cúbicos y fuentes de luz locales. Como resultado, todas estas fuentes de luz diferentes, combinadas con los objetivos representados anteriormente, forman una imagen HDR iluminada.


Elementos de representación proactiva

Los elementos renderizados en renderizado proactivo se agregan encima de la geometría opaca iluminada, pero no son particularmente notables en esta escena.

Después de la acumulación de todo el color, casi hemos terminado, solo hay unas pocas operaciones de procesamiento posterior y la interfaz de usuario.


La resolución del color se reduce en el sombreador computacional y luego se aumenta para crear un efecto de floración muy hermoso y suave.


Después de componer todos los resultados anteriores, agregar la suciedad de la cámara, la gradación del color y finalmente la corrección de la imagen tonal, obtenemos los colores de la escena. La superposición de IU nos da una imagen desde el comienzo del artículo.

Vale la pena mencionar un par de cosas interesantes sobre el renderizado:

• La creación de instancias (duplicación de la geometría) se usa solo para mallas individuales (parece que solo para la vegetación). Todos los demás objetos se representan en llamadas de sorteo separadas.
• Parece que los objetos se ordenan aproximadamente de adelante hacia atrás, con algunas excepciones.
• Parece que los desarrolladores no hicieron ningún esfuerzo para agrupar las llamadas de sorteo en términos de parámetros materiales.

Ratas

Como dije al comienzo del artículo, una de las razones por las que quería explorar este juego era por la forma de renderizar el paquete de ratas. La decisión me decepcionó de alguna manera: parece que fue tomada por la fuerza bruta. Aquí uso capturas de pantalla de otra escena del juego, pero espero que no haya spoilers en él.


Al igual que con otros objetos, las ratas no parecen tener ninguna duplicación de la geometría, a menos que alcancemos la distancia a la que cambiamos al último nivel de detalle de malla (LOD). Veamos como funciona.


LOD0


LOD1


LOD2


LOD3

Las ratas tienen 4 niveles de LOD. Curiosamente, en el tercer nivel, la cola se dobla hacia el cuerpo, mientras que la cuarta cola no. Esto probablemente significa que las animaciones solo están activas para los primeros dos niveles. Desafortunadamente, NSight Graphics no parece tener suficientes herramientas para probar esto.


Sin duplicación (instancing) de ratas.

Con duplicación.


En la escena que se muestra arriba, se renderizó el siguiente número de ratas:

• LOD0 - 200
• LOD1 - 200
• LOD2 - 1258
• LOD3 - 3500 (con duplicación de geometría)

Esto nos hace comprender que hay un límite estricto en el número de ratas que se pueden representar en los dos primeros LOD.

En la captura que hice, no pude identificar ninguna rata lógica que vincule a LOD individuales. A veces, las ratas más cercanas a la cámara no son muy detalladas, y a veces las ratas que apenas son visibles tienen muchos detalles.

En conclusión

Plague Tale: Inocencia es muy interesante en términos de representación. Sus resultados sin duda me impresionaron, sirven muy bien al juego. Al igual que con cualquier motor patentado, sería genial escuchar un análisis más detallado de los labios de los propios desarrolladores, especialmente porque no pude confirmar algunas de mis teorías. Espero que mi artículo llegue algún día a alguien de Asobo Studio y vean que la gente está interesada en esto.