En su conferencia, prestó atención al principio básico de construir muchos efectos en el juego, o el principio de granularidad. Cómo implementó el estudio un sistema a gran escala de destructibilidad realista, qué limitaciones de sus propios recursos y rendimiento de la plataforma enfrentó, qué optimizaciones hizo y qué lecciones aprendió de todo esto, más adelante en el material.
Entonces, primero sobre los desafíos a los que se ha enfrentado el estudio.
El juego tiene lugar dentro de un edificio de una agencia gubernamental de estilo brutalista que tiene algunas características sobrenaturales como paredes móviles.
La estructura de la sede debería haber parecido creíble, porque se trata de una agencia gubernamental que emplea a miles de personal de servicio que realiza tareas de rutina. Mesas, teléfonos, tazas, MFP: todos estos son los atributos habituales de un oficinista que espera ver en el lugar de trabajo y, con su presencia, ayudan a contar cualitativamente la historia de este mismo lugar. Brutalismo significa toneladas de hormigón, pero no solo: aquí tenemos madera y vidrio, que crean el aspecto más adecuado para un edificio de servicios especiales.
Cuando se trata de destrucción, lo primero en lo que pensar es en la capacidad táctil. El equipo de desarrollo tuvo la tarea de organizar un rico entorno interactivo que crea inmediatamente la sensación de poder interactuar con casi cualquier cosa dentro de él.
Obviamente, el estudio enfrentó ciertas restricciones durante su trabajo. Las interacciones con los objetos tenían que verse y sentirse realistas. El jugador debe tener cierta libertad de acción con respecto a la destrucción, pero no ilimitada, ya que las posibilidades del juego descansan en el rendimiento final de las plataformas, la memoria y los requisitos de inteligencia artificial. Al mismo tiempo, el equipo encargado de la tarea de implementar el entorno destructible resultó ser bastante pequeño, lo que también había que tener en cuenta en el trabajo.
Entonces, la destructibilidad en el juego se basa en el principio de granularidad. También es la base de muchos efectos especiales en cinematografía. Su significado es que la naturaleza no está cuantificada. Es un lienzo continuo creado a partir de una amplia gama de objetos, desde grandes a pequeños, desde sólidos a gran escala hasta polvo y humo. Si algo no se refleja en la pantalla, la imagen completa no funcionará.
En un motor de juego, este principio se puede implementar en tres niveles diferentes de detalle. Los objetos sobre ellos se presentan en forma de cuerpos rígidos (Cuerpos rígidos), sus partes, partes de utilería, utilería propiamente dicha y el entorno. Este último en este caso es una especie de cuadrícula estática con la que los objetos interactivos pueden colisionar. Las partículas de malla, las jerarquías sólidas y las calcomanías de materiales brindan a los objetos más detalles en capas específicas. Entonces, de los objetos sólidos pasamos a sus fragmentos y luego a los fragmentos. La última capa son las propias partículas. Los sprites de partículas, las partículas de brasas, la arena y más juegan un papel importante en el relleno de estos gradientes.
La captura de pantalla anterior muestra un entorno estático. Parece bastante vacío, aunque aquí hay algún detalle: por ejemplo, al fondo se puede ver la barandilla de las escaleras.
Es sorprendente cómo cambia la percepción cuando comenzamos a llenar el espacio con objetos con los que podemos interactuar directamente.
En cuanto al flujo de trabajo en Remedy, en realidad es bastante trivial. Los artistas del entorno proporcionan módulos de geometría de nivel y accesorios para el montaje, después de lo cual el departamento de efectos visuales personaliza los equipos y las animaciones de destrucción cinematográfica. Finalmente, el resultado se envía al motor de Remedy, Northlight.
Era necesario decidir un enfoque sobre cómo funcionaría todo, y el equipo se decidió por uno de procedimiento.
Qué significa eso?
El enfoque de procedimiento es el procesamiento y la interpretación de datos basados en reglas.
La información sobre el mundo del juego está representada por modelos que contienen metadatos sobre los materiales. Entonces, puede configurar, por ejemplo, que los asientos del banco estén hechos de tela, la base esté hecha de hormigón, las plantas sean en realidad plantas. Una vez definidos los materiales, puedes formular un conjunto finito de reglas para cada uno de ellos, determinando las reacciones a todas las acciones que se pueden realizar en el juego. Por ejemplo, para que al disparar desde las plantas, salgan trozos de hojas, el hormigón se rompa en fragmentos, la tubería de metal se deforme y salga agua. Luego, todos los datos se redirigen al motor y este ya reacciona a cada interacción según corresponda.
Entonces, ¿por qué la destrucción procesal?
Porque era necesario un giro de acciones rápido y consistente, un comportamiento predecible dentro de condiciones claramente definidas. Hay cientos de activos involucrados en el juego. En la imagen de arriba, puede ver todo tipo de bloques que forman habitaciones, paredes, columnas, escaleras, barandas y más. Debajo hay varios accesorios: mesas, sillas, jarrones, plantas, computadoras, teléfonos. Para implementar la destrucción de tal variedad de objetos, se seleccionó un equipo de solo 1-3 personas. Por lo tanto, era necesario predeterminar los patrones según los cuales funciona el mundo: si un objeto está influenciado de cierta manera, es necesario que se rompa exactamente como está prescrito para el método elegido de destrucción de un material dado.
Entonces, era necesario establecer un cierto comportamiento en función del material. De modo que cuando dispararas al árbol, volaría en pedazos. O, si dispara al vidrio, se romperá en pedazos. Al mismo tiempo, las partículas y las calcomanías también deben comportarse de cierta manera de acuerdo con la composición del objeto.
Cada material tiene su propia geometría de fractura, definida por diferentes niveles. En el ejemplo, vemos un trozo de barandilla, en la base de la cual es de hormigón, luego un soporte metálico y, finalmente, madera. De izquierda a derecha, las etapas se muestran a medida que se rompen:
- El nivel A muestra una rotura en el hormigón. Aquí no hay calcas, ya que todavía quedan pocas grietas. Se puede ver que el soporte está ligeramente doblado.
- Nivel B. El metal se ha ido, pero quedan más hormigón y madera rotos.
- C : , .
Ahora imaginemos que golpeamos una esquina determinada de un objeto; entonces no debería romperse por completo, solo una parte.
Entonces, en Control hay cuerpos sólidos que son un solo objeto. Pero también hay detalles conectados por enlaces. Estos son los mismos cuerpos rígidos que puede separar una llamada colisión compuesta.
Las piezas se crean durante la inicialización, comparten un colisionador común y se mueven como una sola pieza hasta que se rompen. Están conectados entre sí por aquellas superficies que se tocan entre sí.
Hablemos de conexiones. Se crean en una jerarquía geométrica basada en metadatos. Los sólidos están conectados entre sí mediante una especie de bisagra, por ejemplo, en el caso de una puerta o un cajón. Pueden ser destruidos dinámicamente, nuevamente por la fuerza del impulso.
Existe una física especial de destrucción de compuestos. No se rompen con el objeto; es decir, si perfora un agujero en la puerta, la puerta seguirá siendo un objeto completo, unido por conexiones internas. Por lo tanto, si rompe el bloque principal RB1, la puerta no se caerá de sus bisagras: una parte seguirá unida a la abertura, no afectada por el impacto. Y una puerta con un agujero en el medio todavía se puede cerrar y abrir como se esperaba. Así, los desarrolladores querían evitar situaciones en las que los objetos se rompieran por completo, independientemente de dónde y con qué fuerza cayera el golpe, como es el caso de algunos juegos.
La simulación patentada de Northlight ejecuta la lógica de destrucción y determina qué eventos y partículas reaccionan a ella. El motor de física de NVIDIA luego modela los cuerpos rígidos e intenta ajustarlos a las limitaciones del juego.
La destrucción en sí se realiza de la siguiente manera. Tenemos algo de geometría de entrada. A veces es necesario preparar el modelo de antemano, establecer la geometría de pegado y determinar en qué casos qué partes pueden romperse. Luego, los modelos se envían a Houdini y se procesan allí. La destrucción en Houdini es una configuración de HDA a bastante gran escala que realiza reacciones basadas en materiales y escribe datos en la memoria. A veces tuve que arreglar y configurar manualmente algunos metadatos físicos para asegurarme de que la configuración fuera correcta, especialmente cuando se trataba de conexiones. Luego, todos los datos se transfieren al motor, donde se utilizan para crear el mundo del juego.
La herramienta de destrucción en Houdini se parece a esto. Digamos que tenemos un bloque de hormigón como entrada. Es necesario determinar qué áreas pueden romperse y fraguar el material. En este caso, el bloque realizará la destrucción de acuerdo con las reglas establecidas para el hormigón, lo gestionará y creará diferentes jerarquías en términos de geometría de renderizado y colisiones. Luego, debe asegurarse de que el modelado se realice dentro del presupuesto y el estilo que haya establecido. Después de eso, puede exportar el modelo al motor.
Se ve así en el motor. Tiene una especie de jerarquía que lleva información sobre las capas A, B, C, etc. Esto incluye el nombre del material, si el objeto es estático o no, datos sobre conexiones, sus tipos, etc. La jerarquía está representada por niveles y las propiedades físicas difieren según el nombre del material. Si el nombre se especifica correctamente, el motor procesa la física. Hablaremos del problema de los nombres más adelante.
Arriba hay un escenario de simulación sólido. Jesse dispara objetos a su alrededor y explotan, dándose cuenta de la física de la destrucción.
Dado que un entorno destructible requiere muchos recursos, y las consolas y las PC tienen sus propios límites de rendimiento, el equipo se enfrentó a la tarea de optimizar el sistema para que no sobrecargara los dispositivos.
Dado que era necesario ajustarse a un determinado presupuesto de rendimiento, se estableció un límite de 200 sólidos activos en la pantalla, por lo que los objetos fuera de ella desaparecieron por completo.
En el caso de eventos que involucran muchos objetos en movimiento rápido, hay un retraso en las colisiones para que el sistema tenga tiempo para hacer todos los cálculos.
También se implementó el modo de suspensión para los elementos no utilizados. Por ejemplo, si un bloque de hormigón cae al suelo, nadie espera que empiece a saltar como una pelota, por lo que puede "quedarse dormido" con bastante rapidez. Esto se aplica a muchos elementos del juego. Por la misma razón, se pueden apilar una encima de la otra y también permanecerán inmóviles de la misma manera.
Además, los espacios entre los elementos se llenaron de partículas. Por lo tanto, cuando un objeto se destruye, se forma polvo o astillas a su alrededor.
Todo en el juego es sistemático y está basado en eventos. Existen los siguientes eventos de partículas:
- impacto de bala, que tiene un resultado diferente según el material;
- romper la conexión entre dos partes; en este caso, se produce el desguace, liberando partículas;
- destrucción completa de un objeto, lo que lleva a su desintegración en partículas.
Lo anterior muestra el proceso de edición de partículas. Justo en el juego, puedes colocar un determinado sistema de partículas y luego cambiarlo. En este caso, la frecuencia de formación de chispas simplemente cambia. Curiosamente, puede cambiarlo literalmente en tiempo real y obtener comentarios instantáneos de inmediato, y luego reproducirlo nuevamente y ver cómo funciona el efecto. Implementado de esta manera, un ciclo de iteración rápido le permite pulir cosas como esta hasta que se muestren correctamente.
Otra característica de las partículas es el modelado estándar. De vez en cuando, el equipo tenía que utilizar campos de distancia firmados (SDF). Gracias a esto, fue posible asegurar que los objetos no cayeran por el piso, lo que se vería extremadamente extraño.
En el ejemplo anterior, un objeto destructible es una simbiosis de partículas y un sólido. Esto es lo que vemos. La explosión crea polvo en el aire debido a capas adicionales de partículas que llenan los huecos faltantes en el gradiente de granularidad.
Y el último - calcas de materiales, de las cuales hay muchas en el juego y se generan de forma dinámica. Básicamente, son solo texturas que se aplican sobre objetos para crear la apariencia de destrucción.
Si algo se rompe, aparecerá una calcomanía con una imagen de grietas en el artículo. Suelen crearse en Houdini o similar. En Control, la elección de la calcomanía deseada se realiza de forma dinámica en función del material. También ayudó a hacer uso de una parte bastante grande de la geometría estática. Como se demostró al principio, siempre hay muchos objetos estáticos a nuestro alrededor, que también pueden estar sujetos a algún tipo de influencia que hay que tener en cuenta.
Esto es lo que parece. Si rompe el piso, el polígono en sí seguirá siendo el mismo, pero con la apariencia de las calcas, su apariencia puede cambiar mucho. Vale la pena señalar que su uso es bastante económico y eficaz.
Entonces tenemos partículas, sólidos y calcas. En este ejemplo, tuve que recurrir a algunos trucos, porque una simple herramienta de explosión no generaría tantas calcomanías. Ahora Jesse "lanza" un objeto que puede dejar una abolladura en el suelo. Al mismo tiempo, el suelo sigue siendo un polígono estático, pero gracias a las calcas quedan marcas de impacto en él.
También tocaremos el tema de los accesorios personalizados. Hay muchos elementos del juego que se pueden esparcir (extintores de incendios, computadoras, lámparas y similares) que no se pueden generar por procedimientos. Los artistas ambientales todavía tenían que configurar los efectos para cada uno de ellos manualmente. Sin embargo, por su presencia, el mundo del juego parece más rico y diverso.
Entonces, ¿qué lecciones aprendió el estudio de Control?
Vale la pena tocar aquí las siguientes cosas:
- ;
- ;
- ;
- .
El primero es la calidad de la geometría. La geometría de entrada incoherente puede deberse a una escala y orientación incorrectas, pero también a asignaciones de material incorrectas. A veces, la calidad de la malla puede ser demasiado baja y esto también tendrá un efecto perjudicial en el resultado. También sucede que cuando rompes un objeto, te das cuenta de que no hay nada en su interior, y eso está mal. Para evitar tales problemas, es necesario mejorar los datos de entrada, estandarizar toda la tubería de geometría para que durante la exportación el sistema advierta si algo no cumple con los criterios y debe corregirse. Esto ayudaría a evitar ciclos de retroalimentación constante entre diferentes departamentos que buscan exactamente cuándo surgieron los problemas.
Además, sería bueno tener herramientas integradas para que pueda modelar un objeto y ver inmediatamente cómo se verá cuando se destruya. Obviamente, esto plantea el desafío de hacer más herramientas con mejores interfaces, pero vale la pena.
Estamos acostumbrados a poner nombre a cosas distintas. Pero el problema es que estos nombres pueden ser incorrectos. Por ejemplo, Control tiene 17 designaciones diferentes para el material "hormigón", y no se puede culpar a nadie por eso, porque siempre existe un factor humano. El consejo de Richter es eliminar por completo el estándar de nombres. Es mejor tener una única API de metadatos. De esta manera, sin importar qué herramienta usen los artistas para crear los accesorios, es posible exportar los datos al motor directamente desde allí sin ningún paso intermedio.
El siguiente tutorial es principalmente específico de Houdini. La conclusión es que a menudo, al comenzar a trabajar en algo, lo rehace muchas veces en el proceso, crea algunos complementos y debe asegurarse de que, incluso después de dos años de trabajo, pueda abrir el archivo fuente aunque que la herramienta de trabajo ya se podría cambiar 20 veces. Esto significa que necesita algún tipo de estandarización para trabajar con HDA. Esto es en lo que Remedy está trabajando ahora mismo: para asegurarse de que todo esté correctamente distribuido, para que nunca pierda ninguna versión de la herramienta y siempre tenga la oportunidad de repetir lo que hizo en el pasado.
Es importante tener en cuenta aquí que cuando crea herramientas automatizadas, de hecho está utilizando el mismo software que si estuviera haciendo todo manualmente. Y siempre que tengan el mismo backend, todo debería ser completamente consistente.
El rendimiento y las pruebas son algunos de los aspectos más esenciales del desarrollo.
Inicialmente, las pruebas no se automatizaron en Remedy. Después de agregar nuevos objetos al nivel, era necesario revisarlo manualmente para verificar que todo funcionaba correctamente. Pero luego algo cambió en el motor, el backend cambió, algo se optimizó y después de eso se requirió una nueva prueba. Esto es bastante peligroso, porque seguramente se olvidará de verificar algo. En resumen, no es la mejor manera, lo que lleva a una posible acumulación de errores.
El segundo aspecto son las pruebas de rendimiento. Durante mucho tiempo, Remedy no midió ninguna métrica significativa como la velocidad de fotogramas o el tiempo de cálculo. Por tanto, los problemas de rendimiento a menudo se descubren demasiado tarde.
Lo que se puede hacer aquí es, en primer lugar, mejorar los indicadores de desempeño. Es necesario determinar qué aumento de parámetros afectará mejor o peor al juego, para poder contar con esto a la hora de optimizar y determinar un presupuesto que no se puede superar.
Además, las pruebas automatizadas pueden ayudarlo, donde también puede variar la salida para demostrar mejor el impacto de los cambios en el motor.
También puede identificar y tomar medidas contra la degradación del rendimiento. Por ejemplo, para asegurarse de que durante eventos a gran escala, algunos objetos eviten niveles intermedios de destrucción, por ejemplo, de sólidos que van directamente a partículas.
Otra medida es la zonificación del área en función de la carga esperada. Esta idea se basa en el hecho de que nosotros mismos podemos determinar en qué ámbito aplicar determinadas contramedidas para no aplicarlas a todos los activos en el nivel cuando no sea necesario. Por ejemplo, si pronto los enemigos con granadas llegan a tiempo para Jesse, obviamente habrá demasiada destrucción en la ubicación, y durante su ataque, el proceso de generación de destrucción puede acelerarse.
Como resultado, me gustaría señalar que el equipo de Remedy ha realizado un trabajo monumental, del cual se pueden obtener muchas ideas sobre la implementación y optimización del sistema de destrucción procedimental del entorno.