Animación de dos robots

Modelos en Sketchfab:

• Big robot: https://skfb.ly/pBTNv
• Little Robot: https://skfb.ly/pBTJD

En esta actividad he creado las animaciones principales para los dos robots desarrollados en los retos anteriores con el uso de Blender. El objetivo ha sido dotarles de un conjunto de acciones básicas que se puedan reutilizar después en Unity: reposo, movimiento, ataque, defensa, recibir daño y muerte.

Aunque el enunciado pedía cinco animaciones por personaje, finalmente he preparado siete animaciones para cada robot, reutilizando la misma lógica pero adaptando el movimiento y el peso a la personalidad de cada uno.
A lo largo de la entrada adjunto capturas del proceso, los enlaces a sketchfab y un video por cada robot con todas las animaciones desde distintos puntos de vista.

Modelos y enfoque general

He trabajado toda la animación en Blender, reutilizando los rigs que preparé en el reto de rigging. Desde el principio he querido que cada robot tuviera una personalidad clara a nivel de movimiento. En Little Robot he priorizado la sensación de agilidad, apoyando gran parte del peso en el único brazo disponible y marcando bien los cambios de apoyo en las piernas. Para reforzar esta idea he exagerado la asimetría del cuerpo: el brazo activo ha tomado más protagonismo en las poses de ataque y defensa y he desplazado ligeramente el centro de masas hacia ese lado, de forma que el personaje parece desequilibrado por el peso de su único brazo “útil”. En Big Robot he buscado justo lo contrario: un personaje más lento y estable, con movimientos más contenidos y robustos. Sus reacciones han sido más lentas y los gestos algo más torpes, lo que ayuda a transmitir esa sensación de peso y de máquina pesada que no se mueve con tanta soltura como el robot pequeño.

Proceso de animación

Poses base

Para construir cada animación he seguido siempre el mismo flujo de trabajo. Primero he definido las poses clave sin preocuparme todavía por las transiciones; por ejemplo, en la animación de ataque he partido de la pose relajada, he fijado la pose de impacto y finalmente la vuelta a la calma. Una vez claras las posiciones extremas, he añadido las poses intermedias necesarias para evitar deslizamientos y conseguir que el movimiento se sintiera creíble. En la animación de caminar, por ejemplo, he reforzado la pose en la que la pierna se levanta entre paso y paso, porque sin esa clave el pie tendería a arrastrarse sobre el suelo. En estas poses intermedias también he aprovechado para separar ligeramente los brazos, introducir pequeños rebotes en la cabeza y el torso y compensar el peso del cuerpo.

Con el esqueleto de poses montado, he ajustado los tiempos y los espaciados para que el movimiento resultara más natural. He desfasado levemente los brazos respecto a las piernas, he introducido ligeros retrasos entre el gesto del pecho, la cadera y los brazos, y he añadido pequeños rebotes que ayudan a vender el peso y la inercia de cada personaje. Todo este ajuste ha sido clave para intentar que las animaciones no se vean mecánicas.

Gestión del pelo del Big Robot

El pelo del Big Robot ha sido la parte más complicada. Para automatizar su comportamiento he usado dos constraints principales por mechón:

• Damped Track, para que el esqueleto del mechón siguiera una referencia y reaccionara al movimiento de la cabeza.

• Limit Rotation, para restringir los ángulos y evitar que el pelo atravesara en exceso el modelo.

Por ello, de cara a la exportación he tenido que hacer un paso extra. Primero he bakeado la animación de estos huesos para transformar el resultado de los constraints en keyframes normales. Después he limpiado los keys redundantes y he ajustado los bucles para minimizar los cambios bruscos de rotación entre el final y el inicio de cada ciclo. De esta manera Unity recibe animaciones cerradas en bucle y no depende del cálculo en tiempo real de los constraints, lo que evita saltos extraños al reiniciar las animaciones.

Herramientas de Blender usadas

Para agilizar el trabajo me he apoyado en varias herramientas de Blender:

• Pose Library:
  Durante el proceso he utilizado la Pose Library de Blender para agilizar el trabajo con los dos personajes. He ido guardando poses predefinidas tanto de toda la armadura como de grupos de huesos concretos. Entre estas poses he registrado, por ejemplo, una pose de relax general, un puño cerrado o las poses base de ataque y defensa. Esta biblioteca me ha permitido reutilizar y adaptar rápidamente las mismas poses en distintas animaciones y en ambos robots, modificando solo los matices necesarios para cada situación en lugar de construir cada pose desde cero.

  

• Bloqueo de transformaciones:
  Para mantener las animaciones más limpias y evitar keyframes en canales que no debían cambiar, he configurado el bloqueo de transformaciones en varios huesos del rig. En el torso he bloqueado la localización, dejando solo la rotación activa, ya que por la propia jerarquía del esqueleto no tenía sentido que ese hueso se desplazara de forma independiente. En los huesos de tipo pole IK he bloqueado la rotación porque su función es únicamente de dirección y no de giro directo. Con estos bloqueos he evitado generar keyframes vacíos o ruido innecesario en el editor de curvas, lo que ha facilitado tanto la edición como la limpieza final de las animaciones.

• Colecciones de huesos:
  También he aprovechado el sistema de colecciones de huesos que preparé en el reto de rigging para organizar mejor el trabajo de animación. He aprovechado las colecciones específicas para los huesos móviles del cuerpo y otra para los huesos del pelo, de modo que podía aislar rápidamente el grupo que necesitaba en cada fase del proceso. Esto me ha ayudado a evitar bakear por error huesos que no debían recibir animación directa, como la cadena de IK de los brazos o la punta del pelo utilizada solo como soporte de constraints, y a centrarme en los huesos realmente relevantes en cada momento sin saturar el timeline.

Animaciones creadas

Para cada robot he generado el mismo set de animaciones, adaptando timings y actitudes a su personalidad:

• Idle
  Bucle en posición de reposo. El objetivo ha sido que se pueda reproducir indefinidamente sin saltos visibles.

• Hit
  El personaje recibe un impacto desde la pose de reposo. He intentado usar el mínimo número posible de keyframes para que en un futuro se pueda combinar con otras animaciones (por ejemplo, con un desplazamiento), aunque esto habría que testearlo en un contexto real de juego.

• Defense_Idle
  Bucle en posición de defensa, con un peso más bajo y tenso que en Idle.

• Defense_Hit
  El personaje recibe un golpe mientras está en defensa. Cambian los vectores de reacción respecto a Hit normal para que se note la diferencia.

• Attack
  Animación de ataque desde la posición de reposo hasta la acción y retorno a la calma.
  He enfatizado el anticipo y el follow-through para que se lea bien el gesto.

• Walk
  Bucle de caminar. He incluido un avance del root para poder gestionar la velocidad desde el Animator de Unity ajustando el parámetro de velocidad del clip.

• Dead
  Animación de derrota/muerte. No es cíclica; el personaje termina en el suelo y se queda inmóvil.

Pruebas en Unity

Para asegurarme de que las animaciones estaban correctamente preparadas para el motor he realizado una prueba rápida en Unity. He exportado los modelos en formato FBX con todas las animaciones incluidas y he creado un Animator Controller básico para cada robot, conectando los estados Idle, Walk, Attack, Defense, Hit y Dead. A partir de ahí he configurado parámetros booleanos y triggers para cambiar entre estados y he comprobado que los bucles de Idle, Defense_Idle y Walk se reproducían sin saltos visibles, que las transiciones entre Attack, Hit y Dead no generaban poses intermedias extrañas y que el avance del root en la animación de caminar se podía reutilizar para controlar la velocidad desde el parámetro de speed del propio clip. Mi intención es utilizar este controller como punto de partida para la siguiente actividad, donde los robots empezarán a “pelear” dentro del juego y podré refinar este sistema.

Dificultades

El pelo de Big Robot ha sido una de las partes más conflictivas del proceso. Al calcularse automáticamente mediante constraints, el reinicio de los bucles forzaba un recálculo brusco de la rotación del pelo y aparecían posiciones extrañas justo al volver al primer frame. La solución, como explico en el resto del documento, ha pasado por bakear la animación de estos huesos antes de exportar, limpiar las curvas y cerrar cuidadosamente los bucles para evitar esos saltos. Sin embargo, me hubiera gustado implementar un sistema de colisiones, dado que me enfrenté a este problema al final del proceso, en la exportación, no tenia tiempo para gestionar este cambio de cálculo.

Otra dificultad importante ha sido la pérdida de varias animaciones durante el trabajo en Blender. El programa elimina automáticamente los datos que se quedan con “0 users” al cerrar el archivo, y aunque existe la opción de marcar un “fake user” para conservarlos, no suelo tener problemas con ello y en este caso me he confiado. En la práctica lo que hacía era generar una acción, pulirla y dejarla a 0 users al asignar al rig la siguiente animación. Entre distintas sesiones de trabajo me he encontrado con que había perdido casi todas las animaciones generadas hasta ese momento en cada modelo, a excepción de la que estaba usando en la última sesión, lo que se ha traducido en unas cuatro animaciones perdidas. Gracias al sistema de autosave he podido recuperar dos animaciones y una pose de referencia; la otra animación he tenido que reconstruirla desde cero y la pose de posado he tenido que terminarla de nuevo. Para evitar que volviera a suceder he gestionado correctamente las acciones añadiendo el “fake user” y poniéndola en “stash” en NLA. Aunque ha sido frustrante, también me ha servido como recordatorio para gestionar mejor las acciones y los “fake users” en futuros proyectos.

En general, el proceso de animación me ha resultado más exigente de lo que esperaba, sobre todo por la cantidad de iteraciones necesarias para que los movimientos dejaran de verse mecánicos y por los problemas añadidos del pelo y la gestión de acciones en Blender. Aun así, siento que he aprendido bastante sobre cómo planificar mejor las animaciones, proteger el trabajo (fake users, NLA) y preparar los clips pensando desde el principio en su uso real dentro del motor.

Vídeos de las animaciones, en Blender y en Unity:

Este primer vídeo fui montándolo según iba terminando animaciones:

Vídeo de cómo se ven las animaciones finales en Unity (sin input, simplemente en bucle):

Distintas perspectivas:

A continuación adjunto varios vídeos del proceso. La mayoría corresponden a autoguardados de diferentes momentos, ya que durante la producción estuve muy centrada en el trabajo y no siempre grabé manualmente:

Animación idle en proceso, se puede ver que todavía no había ajustado bien las curvas y daba un “salto” del último al primer frame.

Animaciones de andar en proceso.

Captura del proceso de animación de Death de Player1. Si no colocaba manualmente los huesos en el frame 19, autogeneraba un giro extraño al dar la vuelta del modelo, haciendo que quedase todo el personaje revuelto.

En el caso de las animaciones de ataque y defensa, no dispongo de capturas de proceso porque fueron relativamente rápidas de producir (aprox. 30 minutos por animación) y no se generaron autoguardados en esos intervalos.

Respecto a las animaciones de muerte, al ser las últimas que realicé, los autoguardados se sobrescribieron a medida que iba ajustando detalles, y solo he podido recuperar la captura de pantalla anterior.

Software empleado

• Blender para todo el proceso de animación. Las animaciones se han planteado para ser vistas de lado; de frente puede parecer que los personajes están algo “desbalanceados”, ya que se han exagerado posturas para mejorar la lectura y la estética de las animaciones

Animaciones de Reposo (Idle)

Las animaciones de tipo Idle fueron las más sencillas de realizar, creando en primer lugar un primer frame que sirva de “pose base” también para las demás animaciones.

La principal manera de crear las animaciones de idle fue crear la pose inicial, duplicarla en el último frame (48 frames en total) y entre medias añadir pequeñas oscilaciones, sobre todo en los huesos del torso y la cadera para crear un pequeño movimiento. En Player 2 se ha elegido hacer un movimiento más marcado y a un ritmo ligeramente distinto que en Player 1, que es algo más suave o sutil. Además, a Player2 he añadido la particularidad de tener un pie de puntillas en la mayoría de animaciones.

Por último, se ajustaron las curvas de animación para facilitar el loop.

Animaciones de Ataque

Para las animaciones de ataque, planifiqué que Player1 diera dos puñetazos, al ser de menor tamaño que Player2, y Player2 una patada. Para ello, tuve como referencia fotos y vídeos que tomé de mí misma, y también grabé la pantalla mientras jugaba Tekken 7 con distintos personajes, editando luego el vídeo y ajustándolo a velocidad 0.2x, pudiendo así estudiar detenidamente cómo se planteaban ciertas animaciones dentro del juego, y cómo varían de personaje a personaje. Sin embargo, no he seguido una técnica tradicional de motion capture, ya que en vez de situar el vídeo dentro del propio software y fijarme en la posición de cada frame, simplemente lo he empleado de referencia y como material de estudio.

En Player1 al tener un ataque doble, la animación dura 48 frames. Player2, que es más rápida, tiene una animación de 30 frames.

En ambas animaciones, se añadieron los frames 1 y 48, que son iguales, y posteriormente se añadió un frame central con la pose de ataque  (es decir, la pierna levantada en caso de la patada, y el primer puño sacado en el caso de los puñetazos). A partir de ahí, fui añadiendo keyframes intermedios y más detalles, finalmente editando las curvas para ajustar el ritmo. En estas animaciones lo que me resultó más complicado fue afinar el efecto de impacto, que mejoró bastante con pequeños movimientos y giros en zonas cercanas (ej.: El muslo en el caso de la patada, el pecho en el caso del puñetazo), además de hacer que el keyframe de impacto dure dos frames. Al estar sostenido un frame más, da la sensación de que es un golpe y no solo un movimiento del brazo o la pierna.

Animaciones de Defensa (Crouch)

Puesto que ambas tienen ataques altos, he planteado que la postura de defensa sea agacharse para esquivar los ataques. En estas animaciones no he añadido una transición para pasar de Idle a Crouch, sino que añadiré dentro de Unity una transición entre ambas animaciones para suavizar el cambio de una animación a otra. De esta manera, se puede repetir en bucle la animación de defensa si el jugador decide mantenerse más de 48 frames en este estado. Al igual que en la animación Idle, he añadido un pequeño balanceo en ambos personajes, siendo el movimiento de Player 2 más notorio.

Animaciones Desplazamiento  (Step)

Para el desplazamiento de los personajes he querido plantearlo similar a como lo plantean sagas como Street Fighter o Tekken, en el que el movimiento es un solo paso cada vez que se pulsa el botón de input (una Arrow Key del gamepad, como herencia de cuando se planteaban estos juegos de lucha en máquinas de arcade). No es un movimiento sostenido o constante, sino un solo paso cada vez que se pulsa el botón.

Por esto, mi idea es plantear el propio desplazamiento del personaje en el eje X a través de programar el comportamiento en Unity, permitiendo que la animación de Desplazamiento comience y termine como el primer frame de Idle, permitiendo oscilar fácilmente entre movimiento y reposo. La animación se ha hecho manteniendo el eje central del personaje fijo, y simulando movimiento con el cuerpo, sin llegar a desplazar el propio personaje.

Además, se ha planteado para poder invertir la velocidad del movimiento y que la animación funcione como un paso hacia atrás también.

Animación Derrota (Death)

Las animaciones de derrota, junto a las animaciones de ataque, fueron las más complejas. Especialmente la de Player1, que quise hacer que diera un giro en el aire como consecuencia de recibir una patada final de Player 2. Hacer que diera la vuelta fue especialmente complicado, y es la animación con más keyframes con diferencia. Gran parte del trabajo fue, no solo moviendo los huesos del personaje, sino ajustando las curvas para que el ritmo fuera adecuado.

A continuación se pueden ver dos capturas de pantalla de los keyframes (mostrando solo los de los huesos parent) y el gráfico de curvas (teniendo en cuenta todos los huesos):

Como se puede observar en las curvas, en los frames 18 y 19  es cuando el personaje termina de dar el giro en el aire, y cambian de orientación y posición numerosos huesos del cuerpo. En las curvas se traduce como una zona saturada de pequeños puntos (ajustes en huesos), con mayores curvas en el gráfico.

En esta animación, al igual que en las anteriores, se añadieron en primer lugar el keyframe 1, luego el central (dando la vuelta en Player1, y cayendo en el caso de Player2), y la postura final. Una vez tengo estos tres keyframes clave, voy añadiendo keyframes, moviendo el keyframe central y corrigiendo detalles.

En Player2 hice una animación de derrota en la que el personaje se ve brevemente impulsado en el aire y finalmente cae, tras recibir un puñetazo. En el caso de Player 2 la posición de caída es de lado, mientras que en Player 1 se ve perpendicular a la cámara. Quise hacer esta distinción para generar más diferencia entre ambos personajes, tras haber estudiado y visto que en juegos de lucha también hay numerosas posiciones y animaciones de derrota según el ataque que reciban.

Para estas animaciones, tuve como referencias grabaciones que tomé de Tekken 7, a cámara lenta:

Exportación de FBX y conclusiones

Se pueden observar los modelos animados en sketchfab:

Player1

Player2

Finalmente, comprobé que los modelos con sus animaciones se animasen y exportaran correctamente a Unity, que no me dio problemas. Creé un loop igual que en sketchfab, reproduciendo todas las animaciones una después de otra.

Como conclusión, era la primera vez que animaba en 3D y he notado una curva de aprendizaje importante. El primer día la mayor cantidad de tiempo se fue en comprender cómo configurar correctamente las acciones en Blender para que se guarden las animaciones.

Tuve algún susto de animaciones que de golpe dejan de funcionar o verse, y agradezco haber hecho copias de seguridad según iba trabajando ya que algunos de los errores eran por configurar mal la animación nueva que creaba, sobreescribiendo otra acción o no guardándose correctamente. Para el último día de trabajo ya sentía que había agilizado bastante el proceso, y me lancé a hacer las animaciones de derrota más complejas que las anteriores para poner a prueba lo aprendido.

Para el futuro, me gustaría probar a hacer el proceso de animación recreando el método de Motion Capture, con vídeos propios o de licencia gratuita, para comprobar si hay mucha diferencia entre hacerlo a mano, de manera libre, y con un vídeo en el fondo pudiendo adaptar cada keyframe para que sea exactamente igual que el vídeo.

Siento que he aprendido bastante, pero ha habido momentos en los que no conseguía que el movimiento se viera del todo natural y no conseguía descifrar qué en concreto era lo que fallaba. La mayoría de veces se arreglaba añadiendo movimientos sutiles en huesos como la cabeza o la cadera, pero ha habido otros keyframes que por muchas vueltas que le diese no terminaba de sentirlo natural.

Animaciones de los Robots

Animaciones del Robot A:

• Idle_Robot_A
• Movimiento_Robot_A
• Ataque_Robot_A
• Defensa_Robot_A
• Muerte_Robot_A

Animaciones del Robot B:

• Idle_Robot_B
• Movimiento_Robot_B
• Ataque_Robot_B
• Defensa_Robot_B
• Muerte_Robot_B

Resumen

Se tomo como base algunas animaciones de mixamo para crear las propias para cada robot. Como el movimiento asemejando a movimientos de boxeo, para el ataque del Robot A usa sus puños para su ataque en cambio el Robot B lanza unos martillazos. Sus movimientos de movilidad son similares para ambos robot diferenciándose en que el Robot B arrastra sus pies debido a que usa ruedas. Para su movimiento de reposo parten de la misma base pero con sutiles diferencias, siendo el Robot A un tipo de lucha de Box mientras que el Robot B se considera un tipo de lucha más salvaje al usar martillos.

Videos

Robot A

Robot B

En versión Drive.

Reflexión

Aunque al principio parecía fácil de animar, en realidad es un trabajo laborioso. Ya que debes de ser minucioso para que las animaciones resulten lo más fluidas posibles. Fue bastante divertido generar animaciones desde cero, aprender el proceso y lograr ver los resultados que uno desea.