Hacer herramientas de Nuke para producción

Soy Eva Mateo Fábregas, artista de “lighting y compositing” para proyectos de animación 3D. En este artículo vas a poder leer diferentes puntos respecto a cómo crear herramientas y aspectos fundamentales a tener en cuenta, principalmente en Nuke, basados en mi experiencia. También algunas anécdotas del proyecto y de los compañeros con los que ha trabajado en “The Twits”. ¡Si estás trabajando en otra disciplina o usas otro software, espero que este artículo también te pueda ayudar!

Las herramientas, ante todo, deben ser fáciles de entender y de utilizar por los artistas. De nada sirve tener la mejor herramienta del mundo si luego los artistas no saben usarla o es difícil de entender.

También deben estar bien optimizadas para el software, es decir, que no ralentice el ordenador o que tome mucho tiempo ejecutarlas. Por ejemplo, si se hace un script para resolver un proceso, no debería llevar mucho tiempo de espera. A veces será inevitable, pero siempre hay que tener en cuenta optimizar o mejorar los tiempos. Como ya he mencionado anteriormente, las herramientas deben resolver problemas, una necesidad de la producción.

Una herramienta también debe ser robusta. Un código robusto es un código capaz de manejar errores y condiciones inesperadas de manera efectiva durante su ejecución. Sobre todo cuando programamos “callbacks”, estos deben ser robustos también. A mí personalmente, a veces se me olvida este punto, pero trato de trabajar en ello.

Los callbacks los añadimos a las herramientas para que hagan funciones específicas. Por ejemplo, si queremos que al activar una casilla se cambie el color del texto, eso se programaría con un “callback”. En este caso, el “callback” de la casilla nos sirve para que se vea más fácilmente qué funciones se han activado, y así hacer que la herramienta sea más artist friendly, es decir, más fácil de usar para el artista. Estas funciones a veces no son necesarias en funcionalidad, pero sí en usabilidad y experiencia del usuario (UX).

La herramienta también debe estar documentada en la wiki de tu empresa. Aunque diseñemos una herramienta que sea fácil de usar, siempre es importante documentarla. Sobre todo es útil cuando hagamos una herramienta compleja.

Si estás trabajando como Junior o Mid en un entorno de producción y tienes alguna idea de cómo resolver un problema, ¡Nunca tengas miedo de compartirla con tu lead! Al principio compartí las herramientas con mi “lead” y luego las fueron supervisando otros compañeros del equipo que tenían más experiencia haciendo herramientas. Y las compartieron con el resto del equipo. Siempre que se permita compartir, las herramientas ayudan siempre, sobre todo si resuelven necesidades del proyecto.

Recuerdo que, en la herramienta de “eyes specs” para el proyecto, que la inició mi ex supervisor, Javier González, y continué trabajando y mejorando durante la producción; hice un error de Python que cuando cargaban la herramienta en Nuke, éste se cerraba de golpe. Era simplemente una línea de código que daba error. ¡Desde entonces entendí por qué Nuke se llamaba nuclear! Incluso a mi excompañero Patrice «Pat» Gracia, al propagar una secuencia con otra herramienta de pipeline incluyendo el “eye spec gizmo”, le explotó/corrompió toda la secuencia entera. En vez de entrar en pánico, me reí y resolví el problema cuando me dieron el reporte de la consola. Era algo fácil de arreglar, por suerte. Hasta que no vi usar la herramienta, no fui consciente de que existía ese error y no pasaba nada. ¡Por suerte no operamos a corazón abierto!

Es normal equivocarse y cometer errores, sobre todo cuando las herramientas son complicadas como esa misma. Y siempre me recordaré la conversación con Patrice «Pat» Gracia, cuando me contó lo de la secuencia. Me comentó que se rompió toda la secuencia y le respondí a eso con que «me gusta romper cosas», bromeando. Entonces él me envió un “gif” en nuestro “chat” de Teams de la serie de «Como conocí a vuestra madre» de Marshall pidiendo matrimonio a Lily, como si me lo estuviera pidiéndome a mí. Cabe decir que era una broma recurrente de él, había «pedido de matrimonio» a medio equipo, y tenía otra versión de todos los planos de la secuencia.

Aun así, me hizo mucha gracia en ese contexto. Pat es un divertido y gran compañero, que tuvo la paciencia de supervisar gran parte de mis herramientas mientras estaba liderando un equipo de “lighting y comp” y haciendo herramientas para Solaris también.

También recuerdo que, cuando hice un código para actualizar los “reads” en Nuke, aparecía una ventana informando los renders que se habían actualizado y los que no con un color en el texto: los renders actualizados, de color verde y los que no lo estaban, de color rojo. Geoffrey Duch, por mi ex CG supervisor, me dijo como “feedback” que le daba ansiedad ver el no actualizado de color rojo, bromeando. ¡Hay que tener cuidado incluso con las pequeñas cosas como los colores también!

Voy a contar una anécdota que me hizo bastante gracia. Me llamó mucho la atención y me gustaría compartirla. Es el mejor “feedback” que he recibido al respecto y es bastante divertido. En mi “sandbox”, una carpeta personal que tienen los artistas en el proyecto, yo tenía una carpeta concreta denominada «Nuke Tools». Solía guardar mis versiones de las herramientas en desarrollo o las finales que compartía con el resto del equipo. Pero también tenía pequeñas herramientas que usaba en mis planos y no las compartía porque eran muy simples o creía que no tenían mucha utilidad.

No fue hasta que me asignaron un plano de un compañero, que ya había terminado su contrato, y vi que en su archivo de Nuke, tenía esas herramientas que yo creía que no eran útiles para compartir. ¡Me quedé muy sorprendida! Sorprendida porque las había encontrado, porque había sabido usarlas sin documentación y las estaba usando bien.

Fui corriendo a contárselo a mi ex lead, Alissa Soukhanova, y ella me respondió con que no es la única persona que hacía eso, que prácticamente casi todos lo hacían. Creo que fue uno de los mejores halagos que he recibido, aunque al mismo tiempo me reí de la situación. Así que si alguna vez te encuentras en una situación similar. ¡A tus compañeros les gustan tus herramientas!

Mi excompañero Carlos Lucas, ex lighting lead del equipo de “The Twits”, fue la primera persona que me pidió ayuda en el proyecto para resolver unos problemas con el desenfoque: teníamos sobre todo artefactos en los bordes de las “layers”, y tuvimos que ver cómo hacer funcionar bien el “Bokeh”, que por aquel entonces lo acababan de implementar en Nuke como nodo nativo y no lo sabíamos usar. Fue a la primera persona a la que le pasé alguna de mis herramientas en Nuke, le pasé mi primera versión del gizmo de arreglar los edges en el desenfoque. Él las llamaba herramientas «piratillas», por el simple hecho de que no estaban vinculadas o en el pipeline, imagino. Me parecía divertido que se refiriera a las herramientas así. Cuando alguien del equipo te pide ayuda por algo específico, es buena señal de que lo estás haciendo bien también.

Realmente hay muchos recursos en internet hoy en día y siempre puedes mirar cómo han hecho otros artistas gizmos o scripts de Python. Eso ayuda mucho, tanto si están bien hechos como si no. Los gizmos de Adrián Pueyo son muy buena referencia para estudiar cómo hacerlos, por ejemplo. Personalmente me gusta mucho cómo resuelve los gizmos y cómo los estructura.

También te sugiero mirar los pequeños tutoriales de The Foundry y en YouTube, si haces una búsqueda rápida, seguro que los encuentras. Empieza con cosas sencillas al principio creando “knobs” y emparentando “knobs” de dentro a fuera del grupo. Y a medida que te vayas familiarizando con eso, ves haciendo herramientas más complejas. Si tienes interés en aprender programación, yo te aconsejo que empieces con Python 3.

Si te gustara aprender BlinkScript que está basado en C++ para hacer herramientas con BlinkScript, te aconsejo primero empezar con entender cómo funciona la programación y un lenguaje de alto nivel. Un lenguaje de alto nivel es aquel lenguaje que es más comprensible para los humanos. Por ejemplo, Pythones un lenguaje de alto nivel. Por el contrario, C++ es un lenguaje de un nivel más bajo y menos comprensible para los humanos no entrenados. Eso sí, cuando entiendas las bases de programación y estés familiarizado con eso, programar C++ con BlinkScriptno te va a resultar complicado.

Sobre todo, haz herramientas cuando necesites resolver una necesidad. No siempre tienen que ser gizmos, también pueden ser ToolSets. Los ToolSets son conjuntos de nodos que hacen una función específica. Por ejemplo, en un plano de “The Twits”, hice un efecto 2D en “compo” y eso podría considerarse un ToolSet, porque ese árbol de nodos podría usarse en más planos, que fue el caso. A veces es mejor tener visible lo que estás haciendo en tu “setup” y no «esconderlo» en un grupo o gizmo.  

Más allá de querer explicar la parte técnica de hacer herramientas, he querido animarte a que empieces a hacer tus herramientas. En “The Twits” he tenido el placer de trabajar con un equipo muy profesional y abierto a que pueda compartir estas herramientas. Fue una experiencia muy enriquecedora para mí. Mejoré y aprendí mucho en la parte técnica de Nuke. La mejor forma de mejorar una habilidad es siempre practicar. Y si lo puedes hacer con un equipo encantador y divertido, ¡mejor!

Espero que te haya resultado interesante este artículo. Si te han surgido dudas o te gustaría saber más sobre mi experiencia y “background”, no dudes en escribirme por LinkedIn. Puedes encontrarme por el nombre Eva Mateo Fábregas.

También quiero agradecer a Marco Delgado por su tiempo y dedicación a esta revista, y brindarme la oportunidad de poder escribir este artículo. Que los artistas podamos escribir artículos o “breakdowns” de nuestros trabajos y leer artículos y entrevistas de personas referentes de la industria es una maravilla. Siempre es un gusto colaborar con él. Hace unos años escribí otros dos artículos que puedes encontrar en sus números #39 y #41 con el título de la “Pintura de la Luz”. ¡Hasta pronto!