Llevo mucho tiempo sin escribir en el blog. Bueno, sin hacer muchas otras cosas, porque no sólo he dejado de escribir en el blog. He dejado de hacer muchas cosas porque desde el 4 de mayo he estado muy ocupado y he podido hacer pocas otras cosas.
Supongo que no lo habrá echado de menos mucha gente. No hago estadísticas (ni consulto páginas de terceros que las hagan) sobre las visitas que puedo tener. Es más, me da igual quien sea el que lee esto, si pienso que lo leerá mucha gente lo mismo me corto y me censuro por el qué dirán.
Bueno el caso es que venía a contar qué he estado haciendo todos este tiempo y es que he dedicado la mayor parte del tiempo a un proyecto que se me planteó como un reto. Me invitaron a hacer una animación para un vídeo musical: aquí está.
En mediagoblin y en Youtube:
El proceso ha sido largo y tortuoso. Nos hemos encontrado con múltiples problemas que hemos tenido que ir sorteando como hemos podido con el presupuesto que teníamos (0 euros):
- El equipo
- La inexperiencia
- La falta de conocimientos
El equipo
Esto ha sido la principal limitación de todo el proyecto. Nos ha limitado para hacer las cosas más mejor (que diría alguien).
Tampoco queríamos un acabado hiperrealista, pero sí algo mejor hecho, pero el problema eran los tiempos de render. Nos enfrentamos al proyecto contando tan sólo con dos ordenadores de andar por casa. Mientras me dedicaba a hacer las cosas simples: modelando con pocos polígonos, texturas sencillas (planas en su mayoría) usando las luces justas, había escenas que nos darían un quebradero de cabeza con el render.
La mayor parte del vídeo transcurre en el espacio (luces las justas, pocos polígonos porque todo es vacío, fácil de animar, etc). Es la única forma que se me ocurre para poder hacer algún minuto de animación de forma rápida. Esta parte la realizamos dos personas: yo iba modelando y Pablo Busto los iba renderizando, aunque a veces teníamos las dos máquinas calculando fotogramas como si no hubiera un mañana.
Cuando el ordenador se pone a calcular el procesador comienza a funcionar al 100%, la temperatura del ordenador se dispara y es un estrés para la máquina (y para el usuario) importante. ¿Aguantará o se quemará? El problema se incrementó cuando llegamos a la parte en que había algunos materiales más complejos. Las transparencias y los espejos ray-trace le sientan muy mal a los cálculos, igual que las luces de área.
En la escena del bar hay unos elementos que se llevan la palma: la botella, el vaso, el tequila. Tienen en común que utilizan materiales transparentes y eso se paga con ciclos de cálculo. Quizá, a los que no saben cómo funciona un raytracer, tendría que explicar por qué se multiplican los cálculos en el caso de las texturas complejas, --no sólo trasparentes, también las especulares que reflejan su entorno--. Pero nos quedaremos en que hay partes en las que un fotograma tardaba en renderizarse en mi ordenador al rededor de 15 minutos. Lo que hacía que una hora de intensos cálculos proporcionara tan sólo cuatro fotogramas. O dicho de otra forma: renderizar un segundo de animación (24 fotogramas) eran seis horas del ordenador echando fuego por la rejilla de ventilación (y de tener los dedos cruzados del propietario por que no fallara el ventilador del ordenador, que hay que recordar que todos esos productos son chinos).
Mi costumbre era dejar los render para la noche, cuando no utilizaba el ordenador. Además lanzaba el render desde una consola de texto sin cargar ningún entorno gráfico ni ninguna aplicación para dejar cuanta más memoria RAM disponible mejor. El comando es algo como esto:
blender -b fichero.blend --frame-start XX --frame-end XX --render-anim
Todo estaba compartido a través de la nube. En principio en la que tengo montada yo para mi uso particular. Pero cuando se disparó el uso (ficheros grandes, grandes caudales de datos subiendo y bajando, muchos usuarios, etc) mi nubecilla empezó a dar problemas de sincronización. Tuvimos que cambiar a algo mayor y dejamos owncloud por una nube más grande: «Mega».
La verdad es que hemos tenido problemas con todas las nubes. Problemas de sincronización básicamente. Había renders en los que desaparecían texturas o partes de modelos. En ese aspecto owncloud funcionó de una forma mucho más fiable: si había algún error lo decía, pero cuando decía estar sincronizado lo estaba de verdad. Mega no nos tiró errores de sincronización, pero por los resultados estaba claro que no había funcionado algo. Lo triste es que te das cuenta que has tirado 8 o 10 horas de proceso porque el resultado no te sirve.
El equipo humano
Todo empezó con una conversación a través de la red entre Pablo Busto y yo. Él estaba haciendo una nueva canción y quería un vídeo musical. Todavía no me explico cómo se enredó la conversación para concretar en que haríamos un vídeo después de dos o tres conversaciones más.
Así me añadí al equipo musical. Pablo terminó de dar los últimos toques al fichero musical mientras yo tenía esbozada la idea del vídeo.
Como en todos los procesos complejos el resultado no se parece en nada a lo que se proyectó. Todo resultaba mejor en la imaginación del guionista. Supongo que influido por los acabados de vídeos profesionales me imaginaba unos acabados que no podríamos obtener con nuestras limitaciones de material.
Posteriormente y dado que los tiempos de render se dispararon, tuvimos que buscar ayuda. Pablo se encargó de reclutar a algunos voluntarios que nos echaron una mano renderizando mientras yo podía seguir modelando y animando.
La inexperiencia
Este problema se cura haciendo cosas como ésta.
No es la primera vez que animo un personaje o que hago texturas o que hago un modelo. Si fuera así no se podría haber hecho el vídeo. Ni siquiera es el primer proyecto compartido que hago a través de internet con otras personas. El problema es que es la primera vez que hago todas esas cosas a la vez, y siempre se escapa algo. Es imposible estar pensando en cómo hacer una determinada textura para un pichorro mientras estás modelando otro o intentando iluminar otra escena.
La inexperiencia pesó en los tiempos de render. Al final, descubrí el uso de las diferentes herramientas bake que proporcionaban un ahorro importantísimo de los tiempos de render. Se calculaba la iluminación utilizando luces de área, se hacía algún render «prohibitivo» en tiempos para ver el resultado de cómo quedaría. Lo siguiente era ir calculando las «texturas» de todos los objetos visibles con la herramienta bake. Para no liarme mucho en el despliegue UV y puesto que eran «texturas» circunstaciales se le dejaba a blender desplegar como quisiera él, sin costuras y sin comerme mucho la cabeza. Luego se aplicaban esas texturas, se eliminaban las luces de área y se iluminaba la escena con dos o tres luces puntuales, hasta conseguir una apariencia «lo más similar posible» a como quedaba la escena original. El resultado era que fotogramas que tardaban en renderizarse más de medio minuto reducían el tiempo de render a pocos segundos sin una pérdida escesiva de calidad.
