Copyright SPI.

¿Qué es un scene assembler?

Un scene assembler, por definirlo de forma muy primaria, podríamos decir que es un contenedor, un recipiente. Un software donde recolectamos todo el material creado que formaría parte de un plano, o de una secuencia completa. Estamos hablando principalmnete de assets, animaciones, fx, cámaras, etc. Y lo ponemos junto para trabajar el look de todo ese material, para posteriormente iluminar los planos, renderizarlos y enviarlos al equipo de compositores.

Es decir, un scene assembler no es un software DCC donde creamos contenido, si no donde utilizamos el contenido ya creado, para darle vida en cuanto a los requerimientos del plano y secuencia se refiere.

Las tareas principales que vamos a realizar en un scene assembler, son las de look-dev, lighting y render, aunque también podemos realizar otras como layout, set dressing y pre-compositing.

La característica principal que define a un scene assembler, es que trabaja de forma procedural y no destructiva. Lo que llamamos “streamlined”. Siguiendo una serie de jerarquías y órdenes definidas por el usuario, vamos creando diferentes opciones de look, lighting, etc. en función de las necesidades del plano. Si en cualquier momento necesitamos realizar un update de cualquier contenido del plano, bien sea una luz, un personaje, un fx, una cámara, etc. todo el trabajo realizado hasta el momento se actualiza de forma automática, no necesitamos rehacer o reasignar procesos ya establecidos.

Todos estos procesos, que pueden ser muy diferentes, como asignación de shaders, atributos de render, etc. pueden definirse en base a la secuencia y reutilizarse en el resto de planos, sin necesidad de volver a crearlos. De esta forma, estaríamos compartiendo exactamente los mismos procesos en planos que tengan las mismas necesidades. O por dedirlo de otra forma, estaríamos creando y reutilizando templates, lo que nos permite estandarizar la forma en la que trabajamos en cada una de las secuencias de lighting, o incluso a nivel global del show, en cuanto a tareas de look-dev e ingestión se refiere. Estandarizado, algo vital en cualquier facility de efectos visuales.

Esto que hemos contado hasta el momento, no es poco si comparamos las tareas de look-dev y lighting con un software 3D convencional. Pero hay más, como por ejemplo lo que yo llamo “process on demand”. Los diferentes procesos, solo ocurren cuando y donde necesitamos que ocurran. Para empezar, un scene assembler es capaz de cargar una cantidad ingenete de datos, algo que es común en casi cualquier secuencia hoy en dia en proyectos “high end”. Imaginemos una ciudad futurística, con cientos de assets, cientos de luces, miles de texturas, etc. Mover todo eso en un software convencional es prácticamente imposible sin desarrollar herramientas complejas, algo al alcance de pocos. En un scene assembler si somos capaces de hacerlo, gracias entre otras cosas a que los datos, pueden vivir en el script, pero no necesitan ser invocados en todo momento. Esto se denomina “deferring rendering”.

Gracias a estos procesos “on demand” podemos utilizar o no cualquier parte de la escena, tanto en viewport como en render, sin necesidad de passes, overrides, etc. Y en función del plano, podemos indicarle al render lo que necesitamos o no, siempre desde un master template que se mantiene constante en toda la secuencia. Gracias a este sistema de trabajo es muy fácil y rápido gestionar escenas complejas.

Siguiendo ciertos patrones de organización, nomenclatura, etc, podemos organizar los scripts de assembly para que cualquier actualización de un elemento de la escena, sea una actualización ciega, en muchos casos nisiquiera requiere abrir el software para obtener una nueva versión del plano. Todo esto se consigue gracias al sistema procedural de atributos, y al sistema de asignación de shaders, como digo, siempre de forma “streamlined” y siguiendo reglas.

Los scene assembler también permiten crear referencias y sistemas de publicado inteligente, que ayudan a trabajar de forma fluída entre los diferentes artistas y TDs dentro de una misma secuencia y potencialmente el show completo, llegando incluso a trabajar de forma paralela con networks referenciados.

¿Quién utiliza scene assemblers?

Absolutamente todos los vfx facilities, y la mayoría de boutiques medianas. Cualquier empresa de efectos visuales que trabaje en proyectos vfx high end, se va a encontrar en la situación de tener que realizar planos muy complejos, que sólo podrán ejecutarse si el software de render permite realizar ciertas tareas. Por ello, los grandes estudios de efectos visuales y de animación utilizan siempre algún tipo de scene assembler para sacar adelante sus producciones más ambiciosas.

¿Puede beneficiarse un estudio más modesto o un freelancer de un scene assembler?

Sin duda. Depende del tipo de trabajo, el contexto de tu empresa y un largo etc. En ocasiones puede que utilizar un scene assembler sea como matar moscas a cañonazos, pero a largo plazo incluso para un estudio de menos de 10 personas, los beneficios de basar su pipeline de finishing en reglas y templates es más que evidente.

¿Qué scene assemblers están disponibles en el mercado?

Hay varios scene assemblers en el mercado, además de algunos propietarios. Cuando yo trabajaba en MPC, o cuando llegué a Double Negative, no había ningún scene assembler comercial, y teníamos herramientas propietarias, desarrolladas durante años, para sacar adelante las difrentes secuencias de películas como Harry Potter, Narnia, Piratas del Caribe, Batman, etc. Posteriormente estos estudios, y otros para los que también he trabajado, han ido de forma gradual adoptando diferentes scene assemblers comerciales que están siendo desarrollados por terceros.

Foundry Katana

El scene assembler por excelencia. Desarrollado por Sony Pictures Imageworks durante años y ahora comercializado y desarrollado por Foundry. Al igual que Nuke o Mari, Foundry ha sabido poner al servicio de todos una herramienta propietaria, desarrollada en exclusividad para proyectos de efectos visuales y animación.

Katana es el scene assembler más extendido, utilizado por Sony, Weta, ILM, MPC, etc. No es el más sencillo de utilizar de todos, pero tampoco es muy complejo. Basta con recibir un training introductorio y tendrás suficiente para empezar a trabajar en planos.

El viewport de Katana ha mejorado mucho con los años, y ahora ya es posible tener visualización PBR, previsualizar volumes, etc. Con escenas complejas se vuelve lento e inestable, pero la realidad es que a nadie le importa la visualización en viewport, lo que importa es una buena gestión de la escena, y que responda rápido de cara al render. La visualización en viewport, al menos en vfx, es algo secundario.

La navigación de la escena es muy buena en Katana, prácticamente igual que en Nuke, rápida, efectiva, no se puede pedir más.

Katana también ofrece diferentes opciones de render, desde Renderman a Arnold, pasando por 3Delight, que además ahora viene instalado por defecto y se puede utilizar de forma gratuita para aprender.

Mi opinión personal, es que Katana es el mejor scene assembler disponible en el mercado, y si de mi depende basaría el pipeline de look-dev, lighting y render de cualquier estudio high end de vfx en Katana. El único problema, es que es muy caro.

Isotropix Clarisse

Clarisse es otro scene assembler muy utilizado en la industria, siendo sobretodo Double Negative su mayor cliente. ILM, Tippet Studios, ILP, etc. son también algunos de sus usuarios. Yo tengo el dudoso privilegio, de haber sido la primera persona en renderizar un plano con Clarisse para una película, Godzilla.

Lo mejor que tiene Clarisse, son sus herramientas para realizar tareas de layout y set dressing. Los sistemas de scattering e instanciado de Clarisse son simplemente geniales. Extremadamente sencillos de utilizar, rapidísimos y sobre todo, efectivos.

Clarisse es muy sencillo de aprender, mucho más que otros scene assemblers, lo que permite una productividad elevada a un equipo pequeño. Sin duda, mi software de elección para estudios medianos y pequeños.

El viewport de Clarisse es de lejos el mejor de todos, permitiendo una visualización de componentes de shading y lighting en tiempo real, incluso con escenas enormes y complejas. La navegación por otro lado, no es tan buena como en Katana, ya que se basa en “contexts” o carpetas. La funcionalidad es exactamente la misma, también permite crear atributos de render, reglas, jerarquías, etc, pero la visualización es diferente y más incómoda. Esto de todas formas, cambiará con la nueva versión Clarisse Builder.

Lo peor de Clarisse, en mi opinión, es que sólamente trabaja con su propio renderer. Esto no es necesariamente malo, es un buen render, pero yo al menos sigo prefiriendo Arnold. Por otro lado, por un precio muchísimo más bajo que Katana, obtienes un scene assembler, un motor de render y también un compositor 2D. Aunque para ser sinceros, no vas a realizar planos finales con este compositor (o si), pero al menos los lighters podrán hacer slap-comps sin ocupar licencias de Nuke.

Houdini

Houdini no es un scene assembler dedicado, no es una herramienta nacida para ser un scene assembler, pero ya que Houdini es una herramienta procedural, puedes sin duda montarte tu propio scene assembler. No es tan cómodo, ni tan fácil, ni lo hace tan bien como Katana o Clarisse, pero es factible. Yo mismo he trabajado en varios shows donde Houdini era el scene assembler para realizar todo el look-dev, lighting y render. Actualmente es de hecho el software que utilizo en mi empresa como scene assembler.

El viewport de Houdini no es muy bueno que digamos, especialmente utilizando renderers de terceros, pero es más que aceptable. Houdini también permite tener un script muy complejo con muchos assets, fx, etc. y sólamente invocar lo necesario a la hora de render. No es tan eficaz como Katana en este sentido, pero es mucho mejor que cualquir otro DCC.

En cuanto a opciones de renderer, Houdini viene con su renderer nativo Mantra, que está muy bien, especialmente para ciertas tareas como renderizado de volumes, pero en lineas generales, como motor para todos los aspectos de una producción, es inferior a Arnold o Renderman. Existen otras alternativas, como Arnold, Renderman, Vray, Redshift, etc.

El precio es quizás el punto más favorable al considerar Houdini como scene assembler, ya que exsiten difrentes alternativas muy económicas, y además de obtener un scene assembler, y un rederer muy competente, también tienes todo el potencial de Houdini para la creación de contenidos. La curva de aprendizaje es mucho más lenta que los scene assembler antes mencionados, pero cada vez hay más recursos para ayudarte.

En cuanto a gestión de la escena, moverse por Houdini es en mi opinión mucho mejor que en cualquier otro DCC, pero inferior al sistema nodal de Katana, o potencialmente al nuevo Clarisse Builder.

Las herramientas de Houdini para generar point clouds, scatterers, instancias, digital assets, etc. son también un factor importante a la hora de contemplar Houdini como alternativa a Katana o Clarisse. Si bien estas no funcionan con todo su potencial con renderers de terceros, cada vez es mayor el soporte. Houdini también cuenta con un compositor 2D que permite a los lighter realizar slap-comps sin necesidad de ocupar licencias de Nuke.

Gaffer

Gaffer es un Katana simple. Cuando digo simple no me refiero a que puedas realizar menos tareas con el, si con a la simpleza que carateriza la forma de hacer las cosas dentro de Gaffer.

Gaffer es el scene assembly desarrollado internamente en Image Engine, y utilizado en todas sus producciones desde haces años. Además Gaffer es open source y gratuito. Lo que le convierte en un producto muy atractivo.

Es muy sencillo de utilizar, y a dia de hoy soporta diferentes renderers como Appleseed, Arnold o 3Delight, con otros motores siendo portados en un futuro.

La gestión de la escena es para mi la mejor de todos los nombrados hasta el momento, o como mínimo al mismo nivel que Katana, pero todo presentado de forma más limpia, más simple. El viewport es inferior a todos los anteriores, pero como comentaba más arriba, la visualización de viewport es algo secuandario cuando trabajamos en monstruosas escenas.

En Gaffer se pueden utilizar sistemas de instanciado, crear point clouds, etc. Aunque no está tan bien presentado de cara al usuario como por ejemplo en Clarisse, aunque la tecnología está ahí. Y es que John Haddon e Image Engine ofrecen Gaffer de forma gratuita, pero muchos de los recursos internos utilizados en Image Engine o Cinesite, no están disponibles. Aun así, es perfectamente posible montar un pipeline de look-dev y lighting con Gaffer out of the box.

Más o menos este es el panorama actual en cuanto a scene assembler se refiere. Por supuesto hay herramientas propietarias de las que no voy a hablar, y quizás haya algún otro scene assembler por ahí en desarrollo menos conocido. Pero estos cuatro mencionado aquí son los que te vas a encontrar si un dia trabajas para un big facility, o los que puedes incorporar a tu flujo de trabajo en un boutique o empresa más pequeña.

Por último, comentar que Maya, como DCC estandard en la industria de los vfx, aunque no sea un scene assembler y diste mucho de comportarse como tal, en las últimas versiones han sido implementadas ciertas característica para facilitar el trabajo con escenas muy grandes. Por ejemplo los alembic gpu caches, que permiten una carga mucho mayor de assets en una sola escena. Yo los estoy utilizando actualmente y son muy útiles. Por supuesto vestir escenas utilizando ass files de Arnold también es de gran utilidad a la hora de trabajar el dressing de un plano complejo. En resumen, poco a poco queda patente la necesidad de scene assemblers en muchas producciones, ya que los DCC van incorporando en cuanto puedes ciertas características que estamos acostumbrado a ver en scene assemblers. Y además, cada vez son más estudios de vfx de tamaño medio los que comparten secuencias de blockbusters con facilities mayores.

En elephant vfx, tenemos un curso muy completo sobre Isotropix Clarisse, donde mostramos prácticamente todo lo que ofrece el software y diferentes metodologías de trabajo. En cuanto salga de forma pública Clarisse Builder, también prepararemos una formación específica sobre look-dev, lighting y render. Hemos empezado un programa de colaboración con Isotropix para ser evangelistas de sus productos, así que tendréis más formación al respecto.

En cuanto a Katana, por el momento no tenemos ningún tipo de formación, pero ya estamos pensado en un curso que se llamará Katana Fastrack, donde mostraremos como crear un pipeline sencillo de look-dev, lighting y render. Está en nuestra cola de cursos, estad atentos.

En el blog de Xuan Prada podéis encontrar varios videos introductorios a Gaffer, donde podéis ver los primeros pasos en el software. Se postearán más videos sobre Gaffer en el mencionado blog.

También en el blog de Xuan hay una serie de posts sobre la utilización de Houdini como scene assembler. De momento solo se mencionan cosas muy básicas, pero se irá posteando más información de forma periódica.

En esta tercera parte del ejercicio de fotogrametría, vamos a texturizar la roca reproyectando las fotografías originales en el render mesh, con buena topología y buen uv mapping. Todo ello dentro de Photoscan.  Es muy importante, que la posición del asset sea exactamente la misma que tenía cuando salió de Photoscan, si no, las cámaras no se alinearán con el asset y no prodemos proyectar las fotografías de forma adecuada.

Es importante aclarar que el texturizado de assets creados mediante fotogrametría puede realizarse de difrentes formas. En el curso Photogrammetry en VFX, explico de forma detallada diferentes formas. El método que voy a explicar a continuación es probablemente el más sencillo de todos, pero hay que tener en cuenta que en VFX prácticamente nunca vas a utilizar este método. 

En la escena de Photoscan, tenemos que importar el render mesh, éste sustituirá el modelo generado en Photoscan.

El render mesh se alinea perfectamente con las cámaras utilizadas para la creación del mesh original.

Desde el menú workflow, elegimos la opción build texture. Esta herramienta proyectará las fotografías originales en nuestro render mesh.

Muy importante elegir la opción keep uv para que las fotografías se proyecten en el uv mapping que hemos realizado, si no, Photoscan creará un uv mapping automático.

Una vez proyectadas las fotografías, obtenemos un modelo texturizado en el viewport.

Simplemente por motivos de visualización, he importado el render mesh y la textura en Mari. Aquí podemos realizar ajustes si fuese necesario.

El siguiente paso es realizar un delighting de la textura, es decir, eliminar aquella información lumínica ambiental que hayamos podido capturar de forma involuntaria. Hay diferentes forma de realizar delighting, por ejemplo, utilizando HDRIs y dividiendo la iluminación por el albedo, o utilizar las herramientas de Unity, etc. En este caso vamos a utilizar las propis herramientas de Photoscan. Ante, para ayudar al software necesitamos realizar un bake de ambient occlusion. Para ello he utilizado Substance Painter, pero puedes utilizar cualquier otra herramienta.

En Photoscan, en un nuevo proyecto, cargamos el mesh y la textura. Y utilizamos la herramienta remove lighting.

Hay diferentes métodos de cálculo, utiliza el que mejor resultados te de. Cargamos el ambient occlusion y hacemos click en aceptar.

Finalmente esta es la textura exportada tras el delighting.

Y para terminar, unos renders de la roca, incluyendo el displacement y un albedo.

Beauty render.

Albedo render.

Displacement render.

Finalmente para convertir la roca en un digital asset que reutilicemos, tendríamos que eliminarle la zona de cesped y añadir cesped “real” si así lo creyésemos oportuno.

Los usuarios de elephant vfx pro podéis descargar los assets desde vuestra página de descarga.

Una vez hemos generado el mesh, como vimos en el post anterior, llega el momento del clean up. En el caso de tratar con assetsmuy densos, generados a través de lidar, antes de realizar cualquier operación seguramente tengamos que decimarlos utilizando el software específico del escaner. No hay ningún software DCC capaz de gestionar semejante cantidad de información. En nuestro caso, es un modelo sencillo, así que podemos dirctamente importarlo en Zbrush para realizar labores de clean up.

Lo que siempre hago es descartar las partes del mesh que no me interesan, en este caso en particular me interesa nada más la roca. Voy a dejar un margen de suelo, pero no creo que lo utilice en el futuro. En Zbrush podemos fácilmente enmascarar aquellas partes a desechar, tanto mediante selección como pintando. Una vez elimandas aquellas partes que no nos interesan, suelo darle un repaso general al mesh para eliminar ruido y spikes, utilizando para ello el pincel flaten y soft. En caso de ver algún error también podemos solucionarlo, o también por ejemplo podemos refinar algunas zonas que no hayan sido capturadas con suficiente detalle. En este caso, todo ha sido capturado perfectamente.

Por mantenr cierto orden, he creado varios directorios llamados respectivamente, zbrush_in, zbrush_out y zbrush.

Clean up.

Una vez estamos satisfechos con la apariencia del mesh, tenemos dos opciones. Cear una geometría apta para producción, es decir, con una topología ordenada y eficiente. O por el contrario, crear una versión decimada donde conservamos todo el detalle original del scan pero cuya topología es desordenada y sucia. La elección depende de lo que tu necesites. En el caso de vfx, lo normal es generar una versión con topología correcta.

Para ello, lo ideal es generar una versión decimada para llevarnos a Maya y hacer la retopología encima. No queremos lidiar con la versión de alta resolución. En mi caso conreto, como no estoy realizando este asset de verdad, es sólo una demo, y además, porque tengo más cosas que hacer y soy un vago, voy a realizar una retopología automática dentro de Zbrush. No es la mejor topología del mundo, pero es mejor que una versión decimada y simula el paso de generar una retopología en base a un scan.

Decimation, no apto par vfx pipeline.

Automatic retopo en Zbrush.

El siguiente paso es realizar un uv mapping decente. Si no te desenvuelves bien con el uv mapping, échale un ojo a este curso. Buenas uvs son indispensables en un pipeline de producción de vfx, muy importantes. Para este asset, que es relativamente pequeño, voy a utilizar un sólo UDIM. Generalmente nunca utilizo un sólo UDIM, pero trabajar con UDIMs requiere ciertos pasos extras cuando trabajamos con fotogrametría, así que ya hablaremos de eso en otra ocasión.

UV mapping.

Una vez tenemos el asset con su buena topología y su uv mapping, deberíamos de crear una versión para fx, en el caso de que fuera necesario. En este caso no lo es. Este es el mesh que se va a utilizar para el render, tal cual está. Lo siguiente que necesitamos es reproyectar los detalles que teníamos en el scan original y extraer un displacement map, para que a la hora del render, esta simple geometría tenga es aspecto que deseamos.

En Zbrush, subdividimos un par de veces el asset, y reproyectamos e scan. Extraemos los mapas en EXR 32 bit con el midpoint a cero. De esta forma no tendremos que preocuparnos por absolutamente nada, con aplicar el displacement en Maya todo se verá perfectamente.

Zbrush reprojeciton.

Finalmente, en Maya realizamos un render test con el displacement aplicado. Todo el detalle debería de estar ahí, pero si quieres estar seguro, puedes realizar un render del scan original y compararlo con el estado actual del asset.

Render test.

Los usuarios de elephant vfx pro pueden descargarse el material utilizado en este post.

Hace ya algunos años, publicamos en este blog un completísimo curso online sobre photogrammetry, o fotogrametría (parece ser) en castellano. Desde entonces han aparecido nuevos software, alguna que otra herramienta, y quizás algunos de los procesos han cambiado ligeramente, aunque nada revolucionario, la verdad. Por mi parte, hace tiempo que no trabajo en un proyecto donde requiera de la captura de assets mediante fotogrametría, el útimo show en el que utilicé de forma notoria técnicas de fotogrametría fue Assassin´s Creed.

En aquella ocasión capturé y recreé posteriormente parte del vestuario y props utilizados por Michael Fassbender y Ariane Labed. Tras aquel trabajo, no he realizado más que tareas muy esporádicas y sencillas, en cuanto a fotogrametría se refiere. Aun así, he ido seguiendo nuevas técnicas, herramientas y formas de hacer las cosas, y practicando algunas de ellas cuando el tiempo me lo ha permitido.

En un futuro, pretendo crear un nuevo curso de fotogrametría, expandiendo los conocimientos adquiridos en el primer curso publicado, y actualizando todo aquello que ha cambiado durante estos años. En este post, y en una serie de post que vendrán en un corto periodo de tiempo, pretendo mostraros a aquellos que no tengáis demasiada experiencia en técnicas de fotogrametría, como capturar un par de assets sencillos, utilizando para ello diferentes técnicas y herramientas. Hay que tener en cuenta que no todas las tareas de fotogrametría son iguales, y que no se aplican de la misma forma en todas las industria. Por ello, siempre estaré hablando desde el punto de vista de efectos visuales.

Pasaremos por todas las fases comunes de un proyecto de fotogrametría, incluyendo captura, shooting pattern, color correction, software de fotogrametría, reconstrucción del asset, clean-up, retopología, de-lighting, texturizado, look-dev, y render test.

Este es el asset que pretendemos capturar, una roca incrustada en el suelo. No nos preocuparemos de la hierba, simplemente de la superficie rocosa. Siempre que capturo un asset, hago una fotografía de contexto o staging, simplemente para mostar cual es el asset a capturar y el entorno que le rodea, para tener en cuenta el contexto de cara a una futura reconstrucción.

Los suscriptores de elephant vfx pro, podéis descargaros las fotografías raw para trabajar en este proyecto.

Este tipo de assets son muy sencillos de capturar. Basta con hacer un “turntable” con un par de alturas diferentes. Sin necesidad de utilizar trípode. El único equipo utilizado es una Sony A6000 con un milti zoom y una Macbeth Chart. También conviene utilziar sistemas de medición o escala a la hora de captuar. En este caso no he utilizado ninguno, pero siempre tengo un macbeth chart en frame, con tamaño conocido, así que puedo escalar el asset para obtener una escala real posteriormente.

Los settings de cámara, para este caso en particular, son extremadamente básicos. Fstop 11, ISO 300, aperture priority, es decir, ajuste automático en función de la apertura. White balance fijo, no importa cual (disparamos raw), en este caso nublado, y foco automático. La iluminación es natural, así que no nos preocupamos en ese aspecto. Como decía, este es el “pattern” utilizado para realizar las fotografías.

Mi organización de ficheros, por el momento al menos, es muy sencilla. Diferentes directorios para cada tipo de formato fotográfico.

Quiero utilizar la herramienta color checker passport para calibrar el color de mis fotografías adecuadamente, pero para ello necesito antes convertir las fotografías a DNG. No es necesario convertir toda la secuencia, basta con convertir una sola fotografía en la que el Macbeth chart esté en foco y bien expuesto. Una ve convertida, podemos utilizar la herramienta color checker passport con ella.

Automáticamente los swatches del color chart serán seleccionados, de no ser así puedes ajustarlos a mano. Una vez hecho esto, el software ajustará los valores de los swatches de la fotografía acorde a los valores de medición ideales del fabricantes del color chart. Y con ello crearemos un perfil de cámara que reutilizaremos posteriormente en Adobe Camera Raw para aplicar a todas las fotografías del shoot.

Una vez creado el perfil de cámara, abrimos la fotografía con Adobe Camera Raw. Lo primero que necesitamos hacer es aplicar el perfil creado anteriormente.

Lo que pretendemos con este proceso es linearizar la imagen. Linearizar es un término utilizado para diferentes propósitos en vfx, en este caso nos referimos a dejar la imagen lo más neutra posible, entendiendo por neutra, plana.

El tipo de curva debe ser linear, para que la transformación aplicada sea lo menor posible, y todos los ajustes deberán desactivarse para neutralizar la imagen de la mejor forma posible.

Ahora toca utilizar al herramienta white balance para eliminar la mayor parte de transformación de color aplicada por tu cámara, en este caso, la mia :)
Después, selecciona dos o tres swatches para matchear los valores proporcionados por el fabricante, en este caso 243, 160 y 52 aproximadamente. Una vez terminado, hacemos click en “done” y toda la información será guardada en los meta datos de la imagen.

Abrimos todas las imágenes en Lightrooms y sincronizamos los settings acorde a la imagen DNG que hemos corregido en Adobe Camera Raw. De esta forma todas las imágenes, que han sido realizadas bajo las mismas condiciones lumínicas y con casi idénticos settings de cámara, vivirán en el mismo contexto. Las imágenes resultantes las exportamos como .JPG El software de fotogrametría, aunque entiende imágenes de alto rango dinámico, no lo utiliza para nada, así que siempre vamos a utilizar imágenes de bajo rango dinámico. El resultado será el mismo pero el tiempo de computación será mucho menor.

Como software de fotogrametría en este particular ejemplo, vamos a utilizar Agisoft photoscan. Las licencias personales son realmente asquibles, y los resultados obtenidos en este software son excelentes. El otro software hot del momento es Reality Capture, que es considerablemente más caro, pero muchísimo más rápido, especialmente cuando trabajamos proyectos con varios cientos de fotografías.
La rapides, es lo único que en mi parecer es mejor en Reality Capture que en Photoscan, el resto, prefiero Photoscan. En el futuro utilizaremos Reality Capture para varias tareas.

Nota importante, Reality Capture no está disponible ni para Mac ni para Linux.

Lo primero que conviene realizar en Photoscan es analizar la calidad de las fotografías y descartar aquellas por debajo de 0.2

Este asset es muy sencillo, y no utilizamos ningún setup especial para capturar las imágenes, así que poco más necesitamos hacer en Photoscan. Tenemos que alinear las imágenes en primera instancia. Tenemos unas 90 imágenes, con suficiente overlapping entre ellas, así que la tarea de alineación se con total seguridad que será un éxito. Procursa siempre realizar suficientes fotografías para generar un point cloud suficientemente detallado.

Tras unos minutos las fotografías son alineadas y una cámara es virtual por cada disparo. En esta ocasión todas las cámaras han sido perfectamente alineadas, sin ningún descarte. Sinónimo de que el material fotográfico es bueno.

El siguiente paso es generar el point cloud. Este es el proceso que más tiempo requiere, en mi caso, utilizando un iMac 2013 ha tardado alrededor de 4 horas y media. Conviene utilizar la calidad más baja posible, simplemente para testear que todo funciona correctamente. Con esta calidad tardará apenas uno minutos. Si prevees que todo está ok, utiliza calidad alta y genera el point cloud.

Una vez terminado el proceso, podremos ver un point cloud, incluyendo vertex colors (no teturas) bastante detallado. Eso simplemente es un point cloud, aun tenemos que generar el mesh y las texturas. La densidad del mesh dependerá de la calidad del point cloud generado.

Una vez finalizada la generación del mesh y de las texturas, podemos exportar el proyecto mediante .fbx de esta forma conseguiremos la geometría y las cámaras para su posterior utilización en Maya, Mari, etc. Ten en cuenta de que tanto el mesh como las texturas son simplemente placeholder, vamos a generar un mesh y unas texturas aptas para el trabajo de producción. Lo que estamos exportando desde Photoscan no nos sirve para viajar a traves del pipeline de vfx.

Importamos en Maya el .fbx y obtenemos el mesh, las texturas y las cámaras. Para alinear o escalar el asset es muy importante agrupar todo el contenido dentro de un locator o similar. Necesitamos las transformaciones originales para seguir trabajando el asset en el futuro.

Continuaremos trabajando este asset en el siguiente post.
Los suscriptores de elephant vfx pro, podéis descargaros las fotografías raw para trabajar en este proyecto de fotogrametría.

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.