Introducción

En esta última práctica de la asignatura de Media para Videojuegos debemos hacer un pseudo-juego de lucha con los personajes que hemos realizado durante el curso.

Desarrollo

Mi intención es hacer una simulación muy simple del videojuego Pacific Rim: The Game en 2.5D (es decir, con los personajes moviéndose únicamente en el eje Y y X aunque sea en un entorno 3D).

He recreado un entorno importando diferentes assets gratuitos de la Store (enlances en el apartado de referencias), recreando un mundo post-apocalíptico con ciudades hundidas en el océano como fondo. También he incluido un skybox de cielo nocturno para dar más realismo y un ambiente oscuro.

He incluido los paquetes “Animation Rigging” y “Cinemachine” para controlar mejor los movimientos de los personajes y el seguimiento de la cámara.

Pare empezar con la programación y las animaciones, he añadido componentes de física a todos los elementos. El robot tiene un RigidBody con un Capsule Collider y, por otro lado, el suelo tiene un Box Collider. Importante bloquear la rotación y el movimiento del eje Z del rigid body con constraints.

El script de robot jugador lo he ido escribiendo y mejorando con ChatGPT. Básicamente, consiste en una máquina de estados que transiciona según el input de las teclas y que llama a las animaciones adecuadas según cada estado. Este acercamiento me permitirá añadir la lógica de juego sencillamente después.

He creado este animator controller donde la animación por defecto es la de Idle. Ésta puede transicionar bidireccionalmente con la de Walking dependiendo del parámetro de velocidad. Después las demás animaciones pueden partir desde cualquier estado y al acabar vuelven a Idle (excepto Defeat, que termina la máquina de estados). CORRECCIÓN: hay que eliminar la transición a exit, ya que si no la animación de Defeat se queda en Loop al ser derrotado.

El primer “problema” que me he encontrado es que las animaciones no transicionaban a no ser que hubiera acabado el clip. Por suerte esto tiene fácil arreglo: solo hace falta desmarcar la casilla “Has Exit Time” en la transición de las animaciones correspondientes.

Algo similar sucedía cuando se mantenía presionada una tecla, ya que la animación se reiniciaba constantemente. Esto lo he podido solucionar por código haciendo que no se pueda transicionar entre estados hasta que las animaciones de ataque o defensa hayan finalizado.

He escrito por código que cuando el personaje camine hacia el lado opuesto al que empieza se invierta la animación ( de speed 1 a speed -1) para que haga el efecto de caminar hacia atrás con el parámetro WalkingSpeed.

Al aplicar lo realizado en el V1 al V2 me he encontrado algún que otro inconveniente. Primero, la animación de Walking por alguna razón se exportó con 40 frames congelados así que la he tenido que recortar. Por suerte, desde el inspector de Unity esto se puede hacer fácilmente. Con este robot no se siente tan bien el invertir la animación para hacer que camina hacia atrás, pero todos los parámetros son correctos, así que debe ser un problema artístico de la práctica anterior. CORRECCIÓN: resulta que el problema es que al girar el robot la pierna que comienza a caminar se debía invertir. Es decir, haciendo un flip del personaje se ha solucionado.

He añadido dos barreras invisibles a los laterales para que los personajes no puedan salirse de cámara. Finalmente no he utilizado Cinemachine para hacer seguimiento de los personajes.

En este punto he añadido dos BoxCollider as Trigger delante de los robots para activar la zona de puño cuando se ejecuta la animación. También he hecho que tengan un indicador de vida (100 puntos) y que si se están defendiendo que no puedan sufrir daño. Como extra, he añadido un sistema de partículas que lance chispas cuando impactan para dar más feedback. Para que quede en escrito, este juego no pretende estar balanceado ni dar una experiencia de combate justa.

Para los SFX he utilizado diversos audios de PixaBay y los he reproducido en momentos concretos del script. Los SFX que se reproducen son: Attack, Defeat, Impact y Walking.

Para la lógica del menú he creado un GameManager con una FSM para los diferentes estados del juego: GameStart, GameRunning, GamePaused, GameWinnerV1, GameWinnerV2. Los menús son gameObjects con botones, ya que me parecía mucho más sencillo hacerlo así que crear una nueva escena para el menú principal, etc. También he hecho que reproduzca música en loop y algunos efectos de comenzar y terminar partida.

Finalmente, para exportar con WebGL he instalado el paquete WebGL publisher y he creado una build en local para debuggear. Al principio el asset de la store de Vrbn Studios me ha dado algunos problemas, pero he eliminado del proyecto todos los scripts relacionados (ya que aportaban funcionalidades que no necesitaba para los edificios). De esta manera ya compilaba (con varias advertencias en la consola, pero son ingorables).

Ahora llega el momento que más me temía, que es que el proyecto parece ser demasiado grande para ser exportado en WebGL. Tras una tarde de prueba y error, conseguí exportarlo correctamente importando todas las partes del proyecto de una en una a una versión anterior de Unity y comprimiendo los archivos. Aun así, los edificios seguían dando problemas, así que opté por la vía rápida: hacer un pre-renderizado y ponerlo como textura plana en el fondo. Este método es muy efectivo en cuanto a rendimiento, y más para una versión web. Además, con los efectos de desenfoque y demás no se nota tanto. Debería haber pensado en utilizarlo antes, la verdad.

Edificios con canal Alpha aplicado.

Resultado final exportado con WebGL Publisher.

Juego en WebGL

Mecha Battle! – Unity Play

Apunte: he intentado incrustar el proyecto con un iframe tanto de Itch.io como de Unity Play, pero el WordPress de este servicio no lo permite.

El repositorio de todo el proyecto se puede encontrar públicamente en GitLab: https://gitlab.com/jongompal/r5-mecha-battle.git

Visión de futuro

Lo cierto es que el resultado es sencillo, pero estoy muy contento con el empaque final y cómo se integran los modelos con el entorno. Evidentemente, se podría expandir muchísimo más con más animaciones, personajes, entornos, más tipos de ataque y hacer un sistema de combate más atractivo.

Lo cierto es que me ha atraído mucho la idea de hacer un combate más estratégico y lento en lugar de uno en el que cada milisegundo cuenta y los reflejos rápidos son la joya de la corona. Creo que es una perspectiva del género inexplorada y que empaca muy bien con la estética de Mechas que he querido transmitir.

En el hipotético caso de que siguiera en un futuro apostando por este concepto, claramente haría un rediseño total, pensando muchísimo más en las mecánicas y recreando el apartado artístico en consecuencia (aunque no ha estado mal investigar el camino inverso por una vez).

Para terminar, decir que el punto que me falla siguen siendo las animaciones. Son el apartado que claramente requieren más trabajo y que se nota más antinatural. Por ello, en un futuro proyecto de este estilo buscaría cómo integrar aún más las herramientas del motor con las externas e incluso investigar si sería posible crear animaciones procedurales que se adaptaran al entorno.

Referencias

Introducción

Trabajo de animación para la asignatura Media para Videojuegos. En mi caso he utilizado el software Cascadeur y Blender.

Desarrollo

El primer paso al importar un modelo con rig en Cascadeur es asignar los diferentes esqueletos a un esquema humanoide con el “Quick Rigging Tool”. Si tuviéramos un modelo estandarizado lo detectaría automáticamente, pero difícilmente vamos a cumplir esos requisitos con un modelo hecho a mano.

La propia guía de YouTube de Cascadeur ha sido muy útil para conocer los procesos de importación.

Aquí llega un momento gracioso, pues me doy cuenta de que en la actividad anterior no apliqué la escala de los objetos del modelo y al generar el rig todo sale disparado. Así que tuve que iterar y cambiar algunos valores del ejercicio anterior para que aquí todo funcionara correctamente.

Llega el momento de animar. Cuesta un poco acostumbrarse a los controles viniendo de Blender pero los resultados valen la pena. Primero seleccionamos los puntos que vamos a manejar en nuestro esqueleto y los colocamos en la posición que queramos comenzar. Automáticamente, se marcarán en azul (se pueden desactivar con Shift + Z).

Seguidamente, nos movemos en la timeline a la siguiente keypose que queramos hacer y así progresivamente (se pueden mover los keyframes utilizando el botón central del ratón y duplicarlos manteniendo Shift).

Por último, al seleccionarlos todos podemos crear una interpolación asistida por IA que nos dará el resultado final de la animación apretando el botón correspondiente y seleccionando el tipo de curva de animación (en mi caso bezier clamped).

IMPORTANTE: durante el proceso de exportación me he encontrado que las últimas versiones de Cascadeur no permiten exportar en .FBX con el plan gratuïto. Por lo tanto, si queremos trabajar gratis habrá que descargar una versión anterior (en mi caso la v2023.2.1)

La primera animación que he decidido hacer ha sido la de caminar (walking). Recomiendo especialmente seguir el tutorial de Cascadeur dedicado a este tema para empezar a acostumbrarse a las herramientas de este programa. Además, da algunos consejos para generar un loop más natural.

En mi caso busco unas animaciones que representen el peso y tamaño de mis robots, ya que la idea es que en la vida real serían unos modelos de unos 20 metros de altura. Por ello me he inspirado en el fantástico trabajo de animación que realizó ILM en la película Pacific Rim.

El resto de animaciones ha sido pura creatividad espontánea y jugar con las herramientas del programa. Un shortcut muy recomendable para hacer keyframes es F, y Alt+F para intervalos. La pantalla dividida es útil para tener en un lado el modelo limpio y en el otro los controles del rig (en esta versión se activa con la barra espaciadora y con la “X” le das play a la animación).

Respecto a las dos versiones de robots distintas, he dado prioridad a que tengan la misma cantidad de frames para que así al combatir no se generen delays entre los combates.

Para acabar, he juntado todas las animaciones exportadas como .fbx de Cascadeur en un único documento de Blender. Para que todas se muestren en el mismo modelo, he convertido todas las animaciones en acciones en la pantalla de “Nonlinear Animation”. De esta manera también se pueden visualizar y seleccionar en SketchFAB.

Entregables

Video resumen

Robot V1 en Sketchfab: https://sketchfab.com/3d-models/v1-robot-animations-cb11a3bf072a46b7bc69b1518d2b04b3

Robot V2 en Sketchfab: https://sketchfab.com/3d-models/v2-robot-animations-7cfddf43d3624f28be4772a1d0a4b51b

Conclusiones

Lo cierto es que estoy muy orgulloso del resultado; traer a la vida modelos 3D siguiendo todo el proceso es una gran experiencia. Considero que hay muchísimas herramientas que nos facilitan la vida (como Mixamo o Acurrig), pero hacer las cosas por uno mismo da muchísima más precisión en los detalles.

Cascadeur es una herramienta superpoderosa para tener control sobre la animación pero automatizar muchísimos aspectos que le dan más realismo. La realidad es que las animaciones han quedado poco pulidas para mi gusto, especialmente debido a que no les he podido aplicar simulación de físicas debido a un problema de escala con Cascadeur que no he podido solucionar en el margen tan estrecho de tiempo que teníamos para tantas animaciones.

La animación es un arte en sí misma y no he ni rascado la superficie, pero he disfrutado mucho del proceso y todo lo aprendido para futuros proyectos.

Introducción

En esta entrada hago el rigging de los modelos texturizados de los dos robots de las actividades anteriores. Se nos propone utilizar Mixamo (aunque finalmente yo he utilizado accuRIG) y realizar el esqueleto manualmente en nuestro sofware, en mi caso Blender.

Flujo de trabajo

Mixamo

En el enunciado de la actividad se nos propone Mixamo como herramienta para riggear nuestro modelo automáticamente. No obstante, la web de este servicio no me deja subir los archivos .fbx de mis modelos texturizados (muy probablemente debido al tamaño de las texturas). Por ese motivo únicamente he podido hacer la prueba con el modelo sin texturizar:

AccuRIG

AccuRIG funciona de manera similar a Mixamo pero en local y dejándonos más control, ya que podemos movernos entre las distintas fases del rigging libremente. De esta manera podemos trabajar con modelos más detallados.

Por algún motivo el software no muestra correctamente las texturas en este modelo (en el V1 sí), pero no es preocupante porque la exportación es correcta. En esta fase ponemos indicadores en los puntos de flexión.

Recomiendo también ubicarlos correctamente en la vista lateral (barra lateral izquierda) y desactivar la casilla “Midpoint Placement” (panel derecho) porque si no se nos centran los puntos y perdemos el trabajo de la vista frontal.

En Hand Rig he seleccionado 0 dedos porque mi robot no los tiene modelados individualmente, ya que los tiene en forma de puño.

Finalmente, podemos visualizar con animaciones de ejemplo el modelo riggeado con ejemplos y retroceder en el flujo de trabajo si no nos convence cualquier ajuste.

UPDATE: Resulta que el error sucedía porque en Blender exporté sin querer el modelo con más de un mapa de UVs y accuRIG se hacía un lío. Por suerte podemos cargar el .fbx con los mapas corregidos y cargar los datos del rigging anterior con la opción de “Load AutoRIG Data”.

UPDATE: Y por algún motivo más las texturas exportadas con AutoRIG no son correctas, pero importando el .fbx en Blender y copiando el material que creé en la actividad anterior se resuelve el problema.

Rigging a  mano en Blender

Como en la última actividad para exportar los modelos junté todas las mayas, el primer paso para hacer rigging va a ser seleccionar el objeto en modo edición y separar “By Loose Parts” para tener todos los objetos individualmente en el editor. Me he descargado un armature de Mixamo para tener el mismo número de bones y así facilitar el retargeting.

En las zonas de flexión selecciono las caras que marcan el centro de unión y ubico el centro del objeto en esa zona.

Posteriormente, muevo el cursor a ese punto y por último traigo la cabeza del bone a donde está el cursor.

Ahora borro la mitad del esqueleto y utilizo la función symetrize de Blender para duplicarlos y no tener que hacer el doble de trabajo. Importante incluir .L (o R) al final del nombre de cada bone para que la función haga efecto.

Ahora, para tener los huesos bien numerados, le he pedido a ChatGPT que escriba un script para renombrar todos los bones que se han creado con la simetria, de manera que cambia el nombre de, por ejemplo, “mixamorig:LeftHand.L” a “mixamorig:RightHand.R”

Ahora utilizio el Addon Parent to nearest bone para parentar los objetos a la armature. Menos la parte del torso que la hago con Automatic Weights para que tenga flexibilidad respecto a la spine.

Finalmente aquí tenemos los modelos importados en Unity con los huesos mostrados gracias al package Animation Rigging “Bone Renderer Setup”.

Resultados

Time-lapse workflow: https://youtu.be/3PXBWwFq4Xo

Podéis ver los archivos si sois miembros de la UOC en la siguiente carpeta de Google Drive: https://drive.google.com/drive/folders/1WeB18sHIAXxtb-lJtBhdWBLydxLz7d9s?usp=sharing

Valoraciones finales

Por un lado, opino que los resultados con herramientas de automatización son muchísimo mejores de lo que esperaba sobre todo teniendo en cuenta que mis modelos son hard surface. Creo que son una herramienta muy útil porque deja un esqueleto listo para usar en cualquier motor eliminando incompatibilidades (siempre y cuando, claro está, sea una figura humanoide).

Por otro lado, hacer rigging “a mano” en Blender a mí me resulta cómodo y eficiente. Sobre todo deja muchísimo más control sobre los movimientos, ya que se pueden aplicar constraints a los huesos para que se muevan de una manera determinada. Por contrapartida, la compatibilidad del esqueleto que diseñemos en Blender puede no ser la mejor para softwares estandarizados como animaciones de Mixamo o Unity, de modo que hará falta investigar cuál método es más práctico de cara a animar en la siguiente fase del desarrollo.

Introducción

En esta actividad texturizo los dos modelos del trabajo anterior con el addon Material Works de Blender Bros y hago un bake de los materiales para que sean game ready.

Flujo de trabajo

Primero de todo agrupé los distintos elementos del modelo y les asigné vertex groups para mantener la distinción de materiales en un mismo objeto.

Tras crear los nuevos materiales con el plugin Material Works utilicé la función “Remap Users” en los materiales de blender para vincular todas las instancias del material de ejemplo que utilicé al nuevo material:

Seleccionando todas las partes del robot en modo edición “faces”, hago una smart UV project para conseguir el mapa de UVs

Para crear los materiales utilizo Material Works, de Blender Bros. La gracia de este plugin es que permite generar metales con diferentes capas de desgaste configurables a voluntad. He prestado especial atención en el desgaste de los bordes (edges) para resaltar más la silueta de las figuras hard surface.

Y una vez hecho todo esto, llega el momento de hacer el bake de las texturas. Este paso costó mucho más de lo esperado, ya que todas las herramientas de las que disponía para hacer el bake daban herror o no creaban un mapa de UVs coherente. Siguiendo el tutorial “Blender Baking Textures in less that 1 Minute using Omniverse“, decidí utilizar la implementación de Envidia Omniverse en Blender.

Por desgracia, con este método por alguna razón aparecía el error Circular dependency for image “Basic_Metal_basecolor.png” from object “Cube.029_baked” (ejemplo). Tras prueba y error descubrí que se producía debido al uso compartido de las instancias de las texturas del plugin Material Works, de modo que para arreglarlo fui uno por uno en los nodos de las texturas haciendo únicas las instancias (single-user copy):

Este proceso convierte en tedioso lo que en un principio pensaba que iba a ser sencillo (eso sin contar las diversas otras pruebas que realicé haciendo bake con la herramienta nativa de Blender, usando el blugin Bystedts Blender Baker…). Aun así, creo que Omniverse es una herramienta muy potente y si creas las texturas por tí mismo adecuadamente puede ser un gran aliado (eso sí, su coste computacional es elevado).

Aquí tenemos el resultado con las texturas procedurales:

Y aquí con las texturas de Omniverse:

No obstante, precisamente antes de comenzar a texturizar el robot V2 me encontré con este tutorial: Blender to Unreal and Unity – Export and Bake Anything, que mencionaba un addon que todavía no había probado: Principled Baker.

Y tras probarlo, llegué a la conclusión de que era una mucho mejor opción, ya que era más eficiente, no daba error con mis texturas y el mapa de UVs era más fiel al de las texturas procedurales. Aquí un ejemplo:

En este caso pude añadirle los decals que quise siguiendo este tutorial, y utilizando los recursos de Chuck_CG en Gumroad: https://chuckcg.gumroad.com/l/SXxhW?layout=profile

En el caso de los logos, pertenecientes a cada modelo, le pedí a ChatGPT que creara unas ilustraciones con la sinopsis del trabajo anterior como input y las retoqué con Photoshop:

Para el texturizado podéis ver un time-lapse con el flujo de trabajo ya optimizado:

Mapa de UVs finales:

Robot V1:

Robot V2:

Sketchfab links

Robot V1: https://skfb.ly/p8sCw

Robot V2: https://skfb.ly/p8sCD

Final thoughts

Echando la vista atrás, el proceso ha sido más intenso y tedioso de lo que esperaba. Y siendo sinceros ni siquiera he invertido apenas tiempo en el mapa de UVs (también porque creo que las texturas procedurales hacen que no se noten apenas los cortes de sección). Aun así, debería haber dado más margen al desplegar, ya que algunas caras se solapan.

Estoy bastante satisfecho con el trabajo final, aunque para facilitar el proceso he tenido que juntar todos los objetos en uno solo. Ya veremos cómo afecta eso en las siguientes fases del proyecto.

Referencias

Recursos

Robots de combate V1 & V2

En un futuro no muy lejano, una facción de poder se dividió en dos después de una guerra devastadora. La Resistencia conservó sus robots de combate originales, la versión V1, mientras que el Imperio Asiático desarrolló la versión avanzada, la V2. Ahora ambos bandos se preparan para una batalla épica con estas máquinas titánicas como protagonistas.

Esbozos iniciales

Robot V1 – La resistencia

Robot V2 – Imperio Asiático

Referencias

Bocetos técnicos

Boceto técnico en perspectiva

Boceto técnico front and left

Modelos 3D

Capturas del V1 – Viewport, wireframe, render – Sketchfab (.fbx)

Capturas del V2 – Viewport, wireframe, render – Sketchfab (.fbx)

Proceso creativo

Los esbozos (hechos con Procreate) fueron algo rápido para poder empezar con el modelado lo antes posible. Me desarrollo mejor creativamente creando los detalles in situ en Blender. Problemas que me encontré: incoherencias de perspectiva e imposibilidades articulares, por lo que, especialmente en los hombros de los robots, existen diferencias respecto a los esbozos.

Mi “workflow” en Blender pasa por utilizar dos plugins muy conocidos en el hard modeling, que son BoxCutter y HardOps, creando las figuras a partir de booleanos. También me gusta aplicar beveling a todas las prendas para conseguir una estética más realista; el problema de esto es que la densidad de polígonos aumenta considerablemente. En esta primera actividad, al no mover el modelo a Unity, no me he preocupado, pero es muy posible que en iteraciones futuras tenga que simplificar la topología.

Aquí tiene dos vídeos del proceso de modelado como extra ;)