Implementación en Unity

En este proyecto he desarrollado un videojuego de lucha entre dos robots, utilizando como base los modelos, texturas, rigs y animaciones creados a lo largo de las prácticas anteriores de la asignatura. El objetivo principal de esta última entrega ha sido la implementación de esos personajes mediante un sistema de animación y control en Unity, integrando las animaciones dentro de una máquina de estados funcional y conectándolas a una lógica de juego básica.
El resultado es un prototipo de robots fighter inspirado conceptualmente en los juegos clásicos de lucha en dos dimensiones, como Street Fighter, pero implementado con personajes y entornos tridimensionales. El juego se desarrolla en una única escena, denominada Space Level, donde ambos robots se enfrentan hasta que uno de ellos se queda sin vida.

Actualmente cada robot dispone de movimiento lateral, ataque, defensa, reacción al daño y animación de derrota. Aunque el sistema es deliberadamente sencillo, está planteado como una base sólida sobre la que se podrían añadir mecánicas más complejas en el futuro, como ataques especiales, habilidades diferenciadas o gestión de energía.

El proyecto ha sido exportado a formato HTML y publicado en Unity Play e Itch.io, permitiendo su ejecución directamente desde navegador sin necesidad de instalación local.

• • Robots Fight (UnityPlay): https://play.unity.com/en/games/4a0fc901-9b75-45ac-834e-f62dfd62f825/robots-fight
  • Robots Fight (Itch.io): https://raquel-lopez-barcelo.itch.io/robots-fight
  • Repositorio: https://gitlab.com/RaquelLB/robots

Diseño del sistema de animación

Para el proyecto se han creado dos Animator Controllers independientes, uno para cada robot, tal y como indicaba el enunciado. Aunque ambos controllers comparten exactamente la misma estructura y lógica, se mantienen separados para evitar problemas de retargeting y permitir ajustes específicos en el futuro si cada personaje requiere animaciones o comportamientos distintos.

Estructura de la máquina de estados:

La máquina de estados está planteada de forma clara y deliberadamente contenida. Mientras el personaje está vivo y no recibe ningún input, el estado por defecto es Idle. Desde este estado se puede pasar a Walk cuando se recibe entrada de movimiento, o a Defend cuando el jugador mantiene pulsada la tecla de defensa.

La animación de caminar utiliza un parámetro de tipo float denominado SpeedMultiplier, que permite controlar tanto la dirección del movimiento sin necesidad de duplicar animaciones. Este parámetro se ajusta desde el script de control y se multiplica por un factor de dirección para cada personaje, permitiendo reutilizar el la misma lógica aunque los robots estén enfrentados.

El ataque se gestiona mediante un trigger que lanza la animación correspondiente. Durante la animación de ataque, el personaje no puede moverse ni iniciar nuevas acciones, evitando estados inconsistentes. De forma similar, cuando el personaje recibe daño se activa el trigger Hit, que lleva a la animación de reacción al impacto.

Si el personaje se encuentra defendiendo en el momento de recibir daño, se reproduce una animación específica de Defense_Hit. Desde esta animación se retorna automáticamente al estado de defensa si el jugador mantiene el input activo, o a Idle en caso contrario. Desde Idle no es posible llegar directamente a Defense_Hit, ya que este estado está pensado únicamente como reacción contextual durante la defensa.

El estado Dead se encuentra conectado desde Any State y no tiene transiciones de salida. Una vez se entra en este estado, la máquina de animación queda bloqueada, reflejando que el personaje ha sido derrotado y no debe responder a más inputs.

Las únicas animaciones que funcionan en bucle son Idle, Walk y Defense_Idle. El resto están pensadas para reproducirse una sola vez. Las transiciones se han ajustado manualmente para evitar saltos o solapamientos extraños, permitiendo interrupciones inmediatas únicamente en los casos de Hit, Defense_Hit y Dead, ya que estas situaciones deben reaccionar de forma instantánea a lo que ocurre en el combate.

Control y lógica del juego

La lógica general del juego está centralizada en el script GameManager, que actúa como coordinador de los estados globales de la partida. Este script gestiona el menú inicial, el inicio del combate, el estado de lucha, la finalización de la partida y la recarga de la escena. También se encarga de actualizar el HUD, mostrando la vida de cada robot mediante barras, y de mostrar los textos de victoria y derrota al finalizar el combate.
Al comenzar la partida, el GameManager ejecuta una pequeña secuencia cinemática en la que ambos robots se desplazan hasta su posición inicial de combate. Durante este proceso los controles están desactivados y se reproducen las animaciones de caminar de forma controlada desde código. Una vez los personajes alcanzan su posición, se habilitan las colisiones del escenario y se activa el control de los jugadores.

La lógica específica de cada robot se encuentra en el script Robot_Ctrl, que se aplica al objeto padre de cada personaje. Este script se encarga de leer los inputs desde el Input Action Asset, gestionar el estado actual del robot (reposo, movimiento, defensa, ataque, impacto o muerte) y traducir ese estado en movimiento físico y cambios de animación. Para evitar comportamientos erráticos, el script comprueba constantemente las etiquetas del estado actual del Animator, bloqueando el movimiento o el ataque cuando el personaje se encuentra en animaciones críticas como ataque, impacto o muerte.

La gestión de la vida se realiza en el componente Robot_Statics, que mantiene el valor de salud del personaje y marca su estado como muerto cuando esta llega a cero. La aplicación del daño se realiza de forma distribuida mediante los scripts MakeDamage y TakeDamage, asociados a los colliders ofensivos y defensivos respectivamente. Cuando un collider de ataque entra en contacto con una zona vulnerable del oponente, se registra el impacto y el Robot_Ctrl decide si el daño es válido, comprobando que no se trate de un autogolpe y que el oponente esté realmente en un estado de ataque. Si el personaje se encontraba defendiendo, el daño se anula y solo se reproduce la reacción visual correspondiente.
Este sistema, aunque sencillo, permite separar claramente la detección física del impacto de la lógica de juego, facilitando futuras ampliaciones como distintos tipos de daño, zonas críticas o ataques especiales.

Estética, cámara y sonido

La cámara está planteada siguiendo la lógica clásica de los juegos de lucha en dos dimensiones, con una vista lateral fija, pero aprovechando la profundidad del espacio tridimensional. Se ha elevado y rotado ligeramente para mejorar la lectura de los personajes y dar sensación de volumen sin perder claridad en la acción.
El escenario representa el interior de una nave espacial. Actualmente funciona como un blocking visual cuidado, más orientado a definir el espacio de juego que a ser un entorno final. La estética del escenario es deliberadamente más simple, con geometría low poly y texturas planas, lo que genera cierto contraste con los robots, que presentan un mayor nivel de detalle, suciedad y variación de materiales. Esta diferencia es consciente y se asume como una base provisional sobre la que se podría trabajar en futuras iteraciones.

En cuanto al sonido, el proyecto incluye actualmente música de fondo durante el combate y efectos sonoros básicos para la interacción con el menú. En un desarrollo futuro sería deseable añadir sonidos específicos para los robots, como ruidos metálicos al moverse, impactos al atacar o variaciones sonoras según el estado del personaje.

Interfaz y flujo de juego

Al iniciar el juego se muestra un menú principal desde el que se puede comenzar la partida o salir del juego. Durante el combate, el jugador puede pausar la partida mediante un botón situado en la esquina superior derecha, lo que muestra nuevamente el menú con opciones adicionales para reiniciar la escena o continuar la partida. Al finalizar el combate, el GameManager muestra los textos de vencedor y perdedor mediante una pequeña animación de entrada y, tras unos segundos, recarga automáticamente la escena, devolviendo al jugador al menú inicial.

Evolución y continuidad del proyecto

Este proyecto está planteado como una base sobre la que se podrían desarrollar mecánicas mucho más complejas. A nivel jugable, sería interesante introducir ataques especiales y habilidades únicas para cada robot, sustentadas por una barra de energía. Por ejemplo, el Big Robot podría disponer de ataques a distancia o golpes de área, mientras que el Little Robot podría incorporar saltos, dash o movimientos más rápidos.
También sería interesante ampliar el espacio de combate, pasando de un escenario estático a uno dinámico, manteniendo la lógica 2D pero con desplazamientos horizontales o verticales. Escenarios móviles, como una pelea sobre un tren en movimiento o una zona que se va inundando progresivamente, añadirían presión y variedad al combate, incluso incorporando peligros ajenos a los personajes.
Desde el punto de vista estético, el proyecto ganaría mucho con escenarios tematizados, efectos visuales asociados a las habilidades y un uso más activo de la cámara para reforzar impactos y momentos clave del combate. A nivel de control, una adaptación a mandos sería prácticamente imprescindible para mejorar la ergonomía y permitir una experiencia multijugador más cómoda.

Conclusiones de las entregas anteriores

Este proyecto es el resultado de un proceso progresivo en el que cada una de las entregas anteriores ha condicionado directamente las decisiones tomadas en la siguiente, hasta converger en un único sistema coherente. Desde el inicio, el planteamiento no ha sido el de generar piezas aisladas, sino el de construir un pipeline completo de creación de personajes pensado para su uso final en un motor de videojuegos.

El modelado inicial de los robots sentó las bases visuales y conceptuales del proyecto, definiendo desde el principio dos personalidades claramente diferenciadas que han guiado todas las decisiones posteriores. El contraste entre un personaje ligero y ágil frente a otro más pesado y estable no solo se reflejó en las proporciones y volúmenes, sino que condicionó la forma de entender su movimiento, su comportamiento y, más adelante, su rol dentro del juego. La decisión de mantener un diseño relativamente simple y modular no fue únicamente estética, sino estratégica, ya que permitió afrontar con mayor control las fases posteriores de rigging y animación.
Este planteamiento se reforzó durante la fase de texturizado, donde se buscó alejarse de un acabado excesivamente limpio para apostar por superficies con desgaste, suciedad y variación de materiales. Estas decisiones no solo aportaron mayor riqueza visual a los personajes, sino que ayudaron a consolidar su identidad como máquinas usadas, algo que posteriormente ha resultado clave para que los robots mantengan presencia y credibilidad dentro de Unity incluso en un entorno escénico sencillo.

El rigging me supuso reto en el proceso, ya que obligó a traducir todas las decisiones previas en una estructura funcional capaz de sostener la animación. Al tratarse de personajes que no responden a una anatomía humana estándar, fue necesario diseñar un rig manual adaptado a sus necesidades reales, diferenciando claramente entre piezas rígidas y zonas deformables. Este trabajo no solo facilitó la animación posterior, sino que permitió introducir elementos más complejos, como el control específico del “pelo” del Big Robot, que acabarían influyendo directamente en la planificación y limpieza de las animaciones.

La fase de animación terminó de unificar todo el proceso. Las animaciones no se plantearon como clips aislados, sino como partes de un sistema pensado para convivir dentro de una máquina de estados en Unity. El peso, los tiempos y la exageración de las poses se ajustaron para reforzar la personalidad definida desde el modelado inicial, asegurando que cada robot se moviera y reaccionara de acuerdo con su carácter. El hecho de preparar los bucles, los impactos y las transiciones pensando desde el inicio en su uso en tiempo real ha facilitado la integración posterior en el motor.

Todo este trabajo previo a ayudado a generar un pequeño proyecto de videojuego con la comprensión del pipeline de medios 3D desde su diseño hasta su integración en motor, permitiendo que los recursos generados sean a favor del videojuego y su individualidad.

Recursos

• Kenney. (s. f.). UI Pack [Imagenes]. https://kenney.nl/assets/ui-pack
• Kenney. (s. f.). Space Station Kit [Modelos 3D]. https://kenney.nl/assets/space-station-kit
• dafont.com. (s. f.). TT Octosquares [Fuente tipográfica]. https://www.dafont.com/es/tt-octosquares.font
• OpenGameArt.org. (s. f.). Mouse click [Efecto de sonido]. https://opengameart.org/content/mouse-click
• OpenGameArt.org. (s. f.). Cynic Battle Loop [Archivo de audio]. https://opengameart.org/content/cynic-battle-loop

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.

Texturización de dos robots

He texturizado los dos modelos (“Little Robot” y “Big Robot”) usando Blender y Substance Painter.
El objetivo visual ha sido darles un acabado realista: metal pintado, zonas con desgaste, suciedad acumulada y sensación de uso/daño.

A nivel de color partí de los concepts iniciales de cada robot. No buscaba un acabado limpio tipo “juguete nuevo”, sino algo más vivido. En el caso del Little Robot, por ejemplo, le falta un brazo, así que le di un look más castigado. El Big Robot en teoría debía parecer más “entero”, pero al final, por cómo responde el material, casi da la impresión contraria cuando los ves juntos.

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

Desplegado de UVs

El unwrap de UVs lo he hecho en Blender manualmente, marcando los cortes en zonas coherentes con la geometría y colocándolos donde menos se noten al bakear. He intentado que:

• La malla se pueda abrir sin provocar estiramientos grandes.

• Los seams queden en cantos duros (sharp edges) o en zonas que normalmente no se ven en cámara.

• Las islas importantes mantengan orientación consistente cuando voy a pintar detalles gráficos (por ejemplo, piezas donde quiero meter símbolos, franjas o letras). En esas piezas he respetado orientación horizontal/vertical en UV para que luego sea más fácil pintar algo legible (Ej: Pelo de “BigRobot”).

• En el resto de piezas, donde solo me importa aprovechar espacio, he permitido rotar las islas para empaquetarlas mejor y aprovechar al máximo el espacio útil de los mapas.

Las islas de UV mantienen escala proporcional al tamaño real de cada parte del modelo. No he hecho “texel density trampa” (no hay manos a 4x resolución y torso a 1/4, por ejemplo). Para comprobar que las UVs estaban bien apliqué un UV checker para ver si había estiramientos raros o giros locos del patrón.

Antes de exportar a Substance, unifiqué materiales en Blender. Dejé cada robot con un solo material asignado a todas sus piezas físicas, y preparé un vertex paint de IDs. Ese vertex color me sirve como máscara de materiales en Substance Painter.

Ejemplo: todas las partes verdes del Big Robot comparten el mismo ID de color en el vertex paint, porque sé que van a usar el mismo material base. Eso me facilita separar capas luego.

Bake inicial en Substance Painter

Exporté cada robot desde Blender a .fbx.
En Substance Painter creé un proyecto nuevo con plantilla “Unity Standard” y resolución de trabajo a 4K.

El primer paso fue bakear los mapas base (normales, AO, curvature, etc.) usando la pestaña de Bake Mesh Maps. Ajusté las opciones del bake para que realmente trabajase a 4K, aunque sé que el resultado final que tengo que entregar está limitado a 2K, pero de esta manera se abren posibilidades de exportación a otras dimensiones en caso de que en un futuro se requirieran.

En el primer bake tuve un problema con el Little Robot: aparecían sombras raras en una zona. Volví a Blender, revisé las normales (estaban bien) y al final vi que lo que pasaba era tensión de vértices en esa zona. Relajé esa parte de la malla, reexporté y volví a bakear. Con eso se corrigió.

Texturizado y materiales

Organicé el trabajo en Substance por carpetas, basándome en el ID de color que había pintado en Blender.

Ejemplo del Little Robot:

• Blanco

• Gris claro

• Gris oscuro

• Rojo

• Emisivo

A cada bloque le apliqué un material base (por ejemplo, un steel damaged de los Smart Materials de Substance) y luego le hice ajustes finos encima con capas de relleno para controlar roughness, metallic y color sin destrozar el tono que quería.

Caso concreto: las zonas blancas. No quería que parecieran metal desnudo gris brillante. Prefería que parecieran metal pintado o incluso plástico pintado, con un roughness algo más alto y menos metalness. Así que subí el color a blanco y limité el valor metálico y el roughness.

Después añadí suciedad, óxido fino y desgaste en cantos usando mascaras inteligentes. Esto lo usé sobre todo en el blanco y el rojo del Little Robot para remarcar que ese robot está más castigado físicamente.

El Big Robot sigue el mismo flujo general, pero con dos diferencias:

No necesitaba definir un canal emisivo previo para exportarlo y el “pelo” del Big Robot lo resolví con normales. Aproveché una máscara tipo alpha en blanco y negro (forma rectangular con bordes suavizados) procedente de la base de datos de Substance Painter. Esa máscara se usa para generar los huecos entre las piezas de los mechones. Luegoen esa zona bajé un poco la altura y cambié color, de forma que parece que son segmentos separados en vez de un bloque único rígido. La idea es que visualmente parezca algo compuesto por pequeñas piezas flexibles en vez de un tubo macizo.

Optimización y exportación

Siguiendo las instrucciones de optimización del enunciado cree un solo set de UV por robot, un material por robot, texturas cuadradas con tamaño potencia de dos y la exportancion final en 2k (2048 x 2048).

Para exportar desde Substance Painter hice dos salidas distintas:

1. Plantilla Unity Standard
   Esto genera:

   • Albedo/BaseColor

   • Normal map

   • Emissive (si aplica)

   • Un mapa combinado (Metallic/Roughness/AO empaquetados en canales)

   Esta versión la quiero para llevar directamente a Unity en las actividades futuras.

2. Plantilla Blender
   Esta me deja las texturas en el formato que Blender espera sin tener que montar los nodos manualmente a mano.
   Gracias a esto puedo volver a Blender, asignar el material rápido y exportar un .obj con materiales “limpios” que Sketchfab entiende mejor que .fbx en mi caso (los .fbx a veces no enlazan bien las texturas en Sketchfab).

Cada robot se entrega con su propio set de mapas. Como maximo hay 4 imagenes preparadas para Unity, lo cual es una cifra razonable para el motor. Esto está pensado justo para lo que avisa el enunciado: “cuantos más archivos distintos haya, más esfuerzo tendrá que hacer la tarjeta gráfica”, por ello se usa un mapa “Combined” en la exportación de Unity reduciendo en 2 la salida total de imágenes.

Origen de las texturas y derechos de uso

• Los materiales base (smart materials tipo “steel damaged”, suciedad, etc.) son recursos incluidos en Substance Painter.
  Dado que el acceso a esta aplicación ha sido a traves de una licencia de estudiante estos materiales se pueden usar para fines educativos y para prototipado, que es el contexto de esta práctica.

• El alpha que uso para el “pelo” del Big Robot está creado dentro de Substance Painter a partir de una forma simple (rectángulo con bordes suavizados) y luego ajustado por mí (escala, repetición y máscara). No es una textura descargada de internet.

• No he usado texturas fotográficas externas de terceros.

Sketchfab

Los modelos finales se pueden visualizar y descargar desde Sketchfab:

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

En cada modelo he subido:

• El .obj + .mtl

• Carpeta con las texturas exportadas desde Blender

• Carpeta con las texturas exportadas con la plantilla de Unity

En Sketchfab se están viendo las texturas pensadas para Blender (no la versión Unity empaquetada).

Modelado 3d de dos robots

He realizado el modelado 3D de dos robots utilizando Blender.

El diseño conceptual de ambos robots está inspirado en el videojuego Hollow Knight.

• El robot rojo, nombrado Little Robot, toma como referencia al personaje Hornet.

• El robot verde, nombrado Big Robot, está basado en el Falso Caballero, el primer jefe del juego.

En los concepts iniciales añadí algunos elementos como telas y armas, pero estos los he omitido en el modelado 3D final siguiendo las recomendaciones del foro, con el fin de mantener el diseño más sencillo para una futura animación.

En la sección técnica se incluyen comparativas con un humano de 1,75 m de altura:

• Little Robot: aproximadamente 1,50 m.

• Big Robot: aproximadamente 1,85 m.

El modelado se ha realizado respetando la topología en quads y tris. He utilizado distintos modificadores (principalmente Mirror y Solidify) para agilizar el trabajo y facilitar el futuro desplegado de UVs. (Aunque en un principio los he aplicado en la entrega)
Cada robot está dividido en distintos objetos por el momento emparentados en un orden funcional (cabeza, antebrazo, codo, brazo, etc.) para facilitar el proceso de rigging y animación en futuras actividades.

Una de las partes que más me costó fue la cabeza del robot pequeño, sobre todo al decidir la distribución de los cortes y la forma de los ojos. Primero realicé un Inset y después, con la herramienta Loop Tools, generé un círculo tomando como referencia la sección cercana al ojo. A partir de ahí fui ajustando los vértices manualmente hasta conseguir el contorno. Eliminé las caras sobrantes y apliqué el modificador Solidify para dar grosor a la cabeza respetando la inclinación de la zona del ojo.
El mayor problema fue adaptar el resultado a la curvatura general de la cara, ya que tuve que ir rotando y ajustando los vértices para evitar tensiones y conseguir que encajara correctamente con el resto de la geometría.

En el segundo robot aproveché parte del modelado del primero (Little Robot), lo que me permitió reducir el tiempo de trabajo (aproximadamente un tercio menos).

Los materiales 3D de los renders de la ultima sección se han aplicado únicamente como referencia visual, ya que los definitivos se desarrollarán en la siguiente actividad.

Los modelos pueden visualizarse y descargarse (.fbx) desde Sketchfab a través de los siguientes enlaces:

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

Concept

Ataque Little Robot

Ataque Big Robot

Defensa Little Robot

Defensa Big Robot

Detalles técnicos

Modelos 3D:

Little Robot Sketchfab: https://skfb.ly/pBTJD

Big Robot Sketchfab: https://skfb.ly/pBTNv