Tanto en el blog de elephant vfx como en los cursos online o talleres presenciales, hemos hablado en un sin fin de ocasiones sobre diferentes estrategias para separar renders de cara a facilitar la labor de composición, de modo que podamos dotar de mayor control al equipo de compositores que se encargará de recoger los planos de lighting y de finalizar el plano antes de pasar a DI.

Hemos hablado de render passes, render layers, AOVs, LPEs, light groups, etc. Por ello, a menudo me preguntan cual es la forma correcta de renderizar un plano, o cual es el método que yo utilizo.

La respuesta, como casi todo lo que realizamos en VFX es la misma, depende. Depende del show, depende de la secuencia, depende del plano, depende de los assets de los que se compone el plano, de los FX, de las preferencias del supervisor 2D, del visual effects supervisor, etc.

En el caso de que sea yo quien decide, la respuesta es clara, el setup más sencillo, el más rápido de montar y el que ofrezca lo mínimo que requieren los compositores. Como norma general no me gusta facilitar un control absoluto por el mero echo de tener la posibilidad de hacerlo. Si no hay una justificación clara, no necesito generar unos setups enormes que lleven mucho tiempo tanto de montar en 3D como de reconstruir en 2D. Además mi ideal de trabajo en VFX es que el 3D sea lo mejor posible, que el trabajo de composición sea para mejorar el 3D, no para arreglarlo.

Aunque raramente sea yo quien va a decidirlo, aunque actúe como supervisor de lighting. La razón de ello, es que siempre consulto al supervisor de 2D, o al sequence supervisor, o al compositor encargado del plano en última instancia. No siempre, pero en general me gusta que quien vaya a recoger el trabajo que sale de lighting, pueda opinar sobre el material que le gustaría recibir, y en la medida de lo posible y dentro de los estándares de ambos departamentos, hacer todo lo posible para facilitarle todo aquello que considere necesario.

Lo que procuro siempre es, tras analizar considerablemente la secuencia y el plano, sugerir el material a proporcionar por lighting al departamento de composición. Cuando se trata de look-development, siempre trabajo con AOVs tanto directos como indirectos. Me lo llevo todo a Nuke y ahí realizo el offline look-dev. De estar forma puedo trabajar muy rápido y crear diferentes versiones en un tiempo relativamente reducido.

Cuando se trata de un plano de lighting, si es posible y si consigo convencer al compositor, y sobretodo, si el 3D tiene una calidad excelente, no me gusta proporcionar AOVs. En estas ocasiones me gusta proporcionar light groups. Considero que los light groups son mucho más sencillos de utilizar que los LPEs y aunque no ofrezcan un control total, opino que ofrecen un control más que suficiente para poder satisfacer tanto a lighting como a compositing.

De nuevo, si puedo permitirme no dividir en componentes los light groups, prefiero no hacerlo. Como decía, si el 3D es bueno, prefiero que los compositores no lo toquen. De ser este el caso, los light groups que renderizo son los beauty de cada una de las luces que utilice en el plano. Aquí abajo muestro un ejemplo muy sencillo de como realizar el setup de light groups en Maya y Arnold. En elephant vfx procuramos siempre hablar de técnicas, de sistemas de trabajo, no de software. Así que recuerdo a los lectores, que los light groups son una técnica agnóstica de software, puedes extrapolar todo lo que estoy comentando en este post a cualquier renderer.

Esta es la escena que estoy utilizando para esta demo. No es un plano de lighting, no hay tiempo para preparar algo tan complejo. Pero hagamos un ejercicio de imaginación y supongamos que esta escena es un plano de lighting. En el plano tenemos un personaje, un fondo, y varias luces. Suficiente para ilustrar este texto.

En las opciones de AOV light group de cada luz, tenemos que nombrar al grupo donde queremos incorporar una luz determinada. Podemos agrupar varias luces si así lo creemos oportuno, de hecho es una práctica muy habitual. Por ejemplo, en el caso de que estemos iluminando un estadio de fútbol, quizás podríamos querer agrupar todos los focos que colocados en la parte superior. En otras ocasiones, especialmente cuando tenemos setups más sencillos, lo más común es individualizar cada una de las luces. Para ello necesitamos crear un AOV light group para cada luz. En las imágenes de más abajo vemos como voy nombrando light groups para las diferentes luces.

Una vez nombrados todos los AOV light groups, el siguiente paso es crear esos AOVs en el render. Como decía, de momento estamos mostrando como crear los beauties. Para ello, basta con añadir custom AOVs con el prefijo RGBA seguido del nombre de cada uno de los AOV light groups.

Como nota adicional. En este ejemplo concreto, he tenido que añadir dos AOVs extras para emission y transmission. La razón es que una de las luces utilizadas en la escena y que contribuyen a esos componentes, no es una luz propia de Arnold, y el sistema de AOVs no funciona correctamente del todo. Si fuese una luz Arnold, no hubiese hecho falta añadir estos dos AOVs, la información estaría incluida en los beauties. Procurad no utilizar luces de Maya.

Con este setup de RGBA por luz, los compositores deberían tener un amplio control sobre el look final de plano sin necesidad de cambiar el look particular de los assets.

En el caso de necesitar aun más control, y siempre que esté justificado, podemos mediante un setup sencillo separar los componentes que creamos oportunos para cada uno de los light groups.

En este ejemplo estoy separando los componentes diffuse, specular, sss, transmission y emission de cada una de las luces del plano. Si los assets del plano utilizasen otros componentes de shading, bastaría con añadir estos. Sinceramente, a menos que el look final del plano no esté para nada claro, o estemos realizando look-dev del plano, no veo razón justificada para separar los componentes de shading en direct, indirect y albedo. Si quisiéramos hacerlo, por supuesto que podríamos. Pero hay que tener en cuenta la cantidad de AOVs por luz que acabaríamos generando, y por supuesto, las probabilidades de cometer errores tanto en el setup de lighting como en la reconstrucción en 2D también aumentarían. Como digo, muy perdidos tenemos que estar en el look-development del plano para necesitar un setup más complejo que componentes de shading per light group.

El setup básico en Nuke siempre es aditivo, y el control que se otorga a los compositores es suficiente como para reinterpretar el plano con mucha facilidad.

Pues ya está, poco más que añadir a este post. Este es el setup de light groups separados por componente de shading que más utilizo en las secuencias que superviso. Son muchos los planos que he iluminado sin ni siquiera separar los componentes de shading, sólo separando las luces y los beauties de las mismas. Siempre tratando de mantener los setups lo más sencillos posibles, justificando todo el material creado y dándole mucha importancia a la calidad del render 3D, para que el trabajo de 2D sea siempre para mejorar, no para arreglar lo que ha salido mal del 3D.

Los suscriptores de elephant vfx pro podéis descargaros las escenas de Maya y Nuke para analizarlas.

Desde hace unos años, utilizamos Cryptomatte para crear todo tipo de IDs, mattes, etc. Sin duda, la mejor y más eficaz forma de realizar este tipo de máscaras. Pero en ocasiones, debido a ciertas limitaciones que nos podemos encontrar en nuestra producción, no nos queda otra que recurrir a IDs de "toda la vida".

En este video te muestro como realizar un setup de IDs basado en custom AOVs.

En este post vamos a ver como crear variaciones de color y texturas de diferentes formas utilizando Arnold render. La idea principal, es dotar a varios assets, ya bien sean geometría, aiStandins, partículas, scatterers o cualquier otro tipo de multitudes, de variaciones de look, utilizando solamente un shader.

Vamos a mostrar cuatro formas diferentes de realizar esta tarea, cada una de ellas puede aplicarse en función de las necesidades particulares que cada uno pueda tener en su pipeline de producción.

Diferentes colores definidos para diferentes objetos

  • Esta es la escena que vamos a utilizar para todos los ejercicios. Ocho cabezas de una figura de Lego. El objetivo, es utilizar un solo shader y que cada cabeza tenga un color o una textura diferente.
  • Si lanzamos un render, este es el aspecto actual. Un shader sencillo con un color amarillo en el base color y en el sss color.
  • Crea un aiUserDataColor y conectalo tanto al base color como al sss color.
  • En sus parámetros escribe color en el campo attribute.
  • Selecciona el shape de cada objeto, y añade un attribute.
    • nombre: mota_constant_color
    • data type: vector
  • Si ahora vas a los extra attributes, puedes utilizar el color que quieras mediante valores RGB.
  • En este render sólamente he definido un color rojo para uno de los objetos.
  • En este render he definido colores RGB para cada uno de los objetos de la escena.
 

Colores completamente aleatorios y/o texturas definidas de forma aleatoria

  • Al igual que en el ejemplo anterior, tengo el mismo shader, con sss. Además, tengo un mapa de displacement conectado.
  • Lo que pretendemos es utilizar un color aleatorio para cada uno de los objetos, o en lugar de un color, una serie de texturas definidas asignadas de forma aleatoria.
  • En estos momentos este es el aspecto del render. Mismo shader con mismos parámetros para todos los objetos.
  • Crea un aiUtility y conéctalo al base color y al sss color.
  • Pon en shade mode como flat y el color mode como object id.
  • Estos settings nos proporcionarán un color aleatorio para cada objeto.
  • Si lanzamos un render este es el resultado.
  • Conecta un aiRandom después del aiUtility.
  • Pon el type como color.
  • Introduciendo diferentes valores en el seed, obtendremos diferentes colores.
  • Render utilizando un seed con valor 2
  • Conecta un aiColorToFloat después del aiRandom y pon el mode como sum.
  • Con este nodo convertiremos los valores de albedo en datos, de donde podremos extraer máscaras.
  • Crea un aiSwitch y conecta tantos inputs como texturas necesites.
  • Conecta el aiColorToFloat al index input del aiSwitch.
  • Este es el resultado del render.
  • Para obtener diferentes variaciones podemos conectar un aiColorCorrect después del aiRandom y tocando por ejemplo su exposición, alteraremos los valores de albedo y por lo tanto de las máscaras.
  • Tambien podemos utilizar un seed distinto para obtener mayor variación.
  • Otro render diferente aumentando la exposición del aiColorCorrect.
 

Una textura diferente definida para cada objeto utilizando un solo shader

  • Renombre todas las texturas utilizando el siguiente template.
  • Añade el siguiente attribute al texture file node
    • /Users/xuanprada/Desktop/arnold_variance/textures/<attr:head default:COL1_head_a>.tx
    • Añade un attribute al shape de cada objeto
      • nombre: mtoa_constant_head
      • data type: string
    • Si ahora vas a los extra attributes, puedes llamar a una textura diferente basándote en naming convention.
    • Render final.
     

    Lo mismo que en el caso anterior, pero basándonos en naming convention de shape

    • Renombra las texturas basandote en el siguiente template
      • COL1_head_a.tx
    • Añade el siguiente tag al nombre del file texture node
      • /Users/xuanprada/Desktop/arnold_variance/textures/COL1_<shapeName>.tx
    • Los shapes de cada objeto han de ser renombrados utilizando la siguiente nomenclatura.
    • Render final

    Si eres usuario de elephant vfx pro, puedes descargarte las escenas utilizadas en este tutorial.

    Aquí os dejo un video de alrededor de 1 hora, donde explico de forma breve y a modo de introducción como utilizar el node graph de Mari 4.
    Los texture artists generalmente combinan Mari y Nuke para trabajar sus texturas, gracias a la introducción del node graph dese Mari 3, cada vez dependemos menos de Nuke. Por otro lado, las líneas que separan a los texture artists de los look-dev TD's cada vez está más difuminada, y es cada día más común que un mismo profesional se pueda ocupar de ambas tareas, al menos, en assets no demasiado complejos.

    Además, estamos trabajando en un nuevo curso "Estrategias de texturizado y look-development para entornos" donde utilizaremos exclusivamente el node graph de Mari 4 combinado con Substance Painter y Maya, así que esta breve introducción pretende poneros en contexto para lo que vendrá en un futuro.

    Lo dicho, aquí os dejo con casi 1 hora de introducción al node graph de Mari.

    Imágenes pertenecientes al curso "Estrategias de texturizado y look-dev para entornos",

    En alguna ocasión anterior ya hemos hablado sobre el uso de Ricoh Theta para tareas de image acquisition en efectos visuales. En ese video ya comentaba algunos de los puntos fuertes y débiles de utilizar un setup convencional vs un setup basado en Ricoh Theta. Te recomiendo echarle un vistazo.

    En esta ocasión, he realizado un ejercicio de image acquisition, donde la fuente lumínica principal es muy potente, el sol, y por lo tanto, es muy importante capturar el mayor rango dinámico posible, para así poder representar de forma efectiva la situación lumínica capturada de forma virtual.

    Los setups a comparar son

    • Canon 5D Mark III + 8mm fish eye + panoramic head
    • Ricoh Theta S + Manfrotto mini tripo
    • Los dos anteriores se complementan con lighting checkers y macbeth chart.

    Las imágenes capturadas con el setup tradicional. 6 ángulos (aunque podrían haber sido solamente 3). 7 exposiciones por cada ángulo con 2 stops de diferencia. En total 42 imágenes.

    Settings de cámara

    • ISO: 100
    • Apperture: f22
    • Mid exposure: 1/100
    • 2EV apart
    • Min exposure: 1/6400
    • Max exposure: 0''6
    • White balance, focus, etc = manual

    Todos mis brackets están perfectamente alineados, ya que las fotografias se realizaron con un pano head. De esta forma no es necesario perder ni 2 minutos en Ptgui para hacer el stitching.

    0005.png

    Las fotografías realizadas con Ricoh Theta, son completamente automáticas, no se pueden controlar de forma manual. Los settings generados son:

    • Min exposure: 1/6400
    • Max exposure: 1/100

    El stitching en este caso, lo hago con Merge HDR Pro en Photoshop, ya que Ptgui no hace stitching de fotografías equirectangulares, (si rectilíneas y fish eye). Nunca deberías utilizar Photoshop para trabajo de datos, así que una vez generado el HDRI guarda como .exr y nunca más la abras en Photoshop.

    Me llevo los dos panoramas a Nuke, para neutralizarlos en base a mis referencias. También para limpiar artefactos si fuese necesario, aunque en este caso he pasado olímpicamente de ello.

    Si bajamos la exposición en viewport y analizamos el punto de mayor valor lumínico en la imagen, es decir el sol, veremos la brutal diferencia entre un panorama y otro.

    • 5D Mark III = 431
    • Ricoh Theta: 3.8

    Esta información ya debería de ser una valiosa pista del comportamiento de un panorama u otro cuando creemos nuestros setup IBL.

    0013.png

    Ya en Maya, creo dos setups de IBL diferentes, uno para cada panorama. Las diferencias son evidentes, especialmente en la densidad de las nombras y la distribución de la luz.

    5D Mark III

    Ricoh Theta

    ¿Eres suscriptor de elephant vfx pro? Descárgate el material utilizado en este post y analízadlo tranquilamente en tu casa.