← Volver al devlog

Arte

El desenvaine, en ocho direcciones

Hace dos semanas escribí que lo correcto era repartir los trabajos: el 3D mueve, el 2D dibuja. Estaba equivocado. La respuesta era dejar de parchear.

Leo desenvainando, visto desde las ocho direcciones a la vez en una rejilla de cuatro por dos
Leo desenvainando, visto desde las ocho direcciones a la vez en una rejilla de cuatro por dos

Esta es la animación más difícil del personaje, terminada y en las ocho direcciones:

Leo desenvainando, visto desde las ocho direcciones a la vez

Cincuenta cuadros, dos segundos, ocho cámaras. Saca la espada, se coloca el escudo y se asienta en guardia. De frente:

Leo desenvainando de frente, animado: saca la hoja de la funda, la levanta y la baja a guardia mientras se coloca el escudo

Y de espaldas, que es donde esto se pone difícil: la espada sale por detrás del cuerpo, el escudo cruza el torso y nada se puede resolver «tapándolo» porque no hay cara que mirar.

Leo desenvainando visto de espaldas, animado

Y para llegar aquí tuve que admitir que lo que escribí en la entrada anterior estaba mal.

Lo que decía hace dos semanas

Que la solución era repartir los trabajos: el 3D pone el movimiento y el acabado se repinta en 2D, cuadro a cuadro. Lo conté con detalle, con sus razones, y me parecía sólido.

No lo era. Esa vía se cayó revisión tras revisión, siempre por lo mismo: el dibujo se mantenía en un cuadro y se iba en el siguiente. Un color que partía el faldón. El brazo del escudo parpadeando. Un hueco claro junto al contorno de la manga. Las botas que recuperaban el acabado y lo perdían dos revisiones después.

Cada arreglo era un parche sobre un parche: congelar una pieza, anclar una mano, bloquear la cara, traer un trozo del render para tapar un cruce. Y cada parche tapaba un problema y abría dos.

El giro

En vez de pintar mejor encima del 3D, hacer el 3D lo bastante bueno como para que no haya que pintar nada encima.

Todo se resuelve ahora dentro de Blender: la pose, los agarres, qué tapa a qué. La espada va ligada al puño, el escudo a su sujeción, la funda al cinturón. Y las dos correas interiores del escudo, que llevaban meses dando guerra, dejaron de ser un dibujo y pasaron a ser geometría de verdad, anclada al escudo.

La regla quedó escrita, con estas palabras, para que no se vuelva a colar:

La oclusión sale de la geometría: no añadir cabezas externas, retoques por fotograma ni manchas de color para ocultar cruces.

Lo que sale del render se cuantiza a una paleta común, sin tramado, con alfa binario y contorno de píxel. No se retoca un solo cuadro a mano. Y el resultado aguanta el cien por cien:

Primer plano del desenvaine a tamaño nativo: se ven la rejilla de píxel, el pelo en mechones, el aro del escudo y la hoja saliendo de la funda

La baja

Hubo que cortar algo para llegar aquí, y es justo quien más guerra había dado: el modelo ya no lleva bufanda.

Si has seguido estas entradas, la bufanda es un viejo conocido. En junio desapareció la capa del primer concepto por ser tela suelta junto a los brazos. En septiembre se rechazó un turnaround entero porque la cola de la bufanda ocupaba el 35 % de la figura. Se quedó la punta remetida en la nuca, y aun así siguió apareciendo en cada lista de defectos durante cuatro meses.

Ya no está. Y el personaje no ha perdido nada: se reconoce igual.

Las cifras

El diseño aprobado es la revisión 227, del 6 de octubre. Las revisiones van numeradas desde el principio, así que el número dice bastante por sí solo sobre lo que costó.

Ocho cámaras —sur, sureste, este, noreste, norte, noroeste, oeste, suroeste—, render en GPU a 32 muestras, lienzo de 450 × 540, fondo transparente y 24 imágenes por segundo. Cada dirección se exporta como PNG sueltos, APNG y GIF, y se revisan las ocho: agarres, oclusiones, límites del lienzo y continuidad.

Lo que falta

El desenvaine está aprobado; el resto de animaciones no. La siguiente es el caminar con espada y escudo equipados, y hay una prueba de marcha con un rig distinto que todavía no he dado por buena. Que el pipeline funcione para una acción no significa que funcione para todas, y no pienso darlo por hecho otra vez.

Lo que me llevo

Que escribí una conclusión en firme con dos semanas de evidencia detrás, y era la equivocada.

No porque el razonamiento fuera tonto —repartir el trabajo entre lo que cada herramienta hace bien es una idea razonable—, sino porque había una opción que no estaba mirando: que el problema no se repartiera, sino que desapareciera. Me pasé semanas puliendo la forma de tapar los cruces en vez de preguntarme por qué había cruces.

Y hay un detalle que no se me escapa: la entrada anterior cerraba diciendo que la herramienta no puede acabar siendo el diseño. Tenía razón en el titular y me equivoqué en el diagnóstico, que es la forma más incómoda de acertar.

← Volver al devlog