El UV mapping en VFX es una tarea de la que por lo general se ocupan los modeladores. Todos los assets, y todas las partes de las que estos se componen, necesitan UV mapping. El UV mapping hay que cuidarlo y dedicarle el suficiente tiempo para asegurarse de la calidad del mismo. Nunca se utiliza UV mapping automático.

Antes de realizar cualquier tarea de UV mapping, el modelador y el texturizador necesitan entablar conversaciones para establecer unos mínimos para asegurarse de la eficiencia del UV mapping y su viaje a través del pipeline.

En VFX tendemos a trabajar en paralelo en diferentes departamentos, así que un asset puede estar siendo texturizado al mismo tiempo que un modelador realiza ajustes a su modelo. Además de comunicación constante entre ambos departamentos, es necesario preservar las UVs existentes en la medida de lo posible.

Estos son algunos de los conceptos más importantes relacionados con UV mapping que necesitas conocer.

Overlapping
Siempre evita el overlapping, o superposición de unas UVs sobre otras. Dentro del mismo mesh o entre varios meshes, overlapping es probablemente el error más grave que puede darse durante el proceso de UV mapping, y sin duda, el más frustrante para los texture artists.
La mayoría de herramientas 3D tienen opciones para visualizar overlapping y ayudarte a corregirlo.

UVs fuera de rango
Asegúrate de que tus UVs no se encuentran fuera del rango (o espacio UV). Aunque en ocasiones pueda utilizarse, procura que las UVs no se salen de su rango ni están colocadas de forma continua entre espacios UVs. En la mayoría de ocasiones suele generar problemas de diferente índole. También asegúrate de no utilizar espacios de UV negativos.

Bleeding
Es importante dejar suficiente espacio dentro del espacio UV para el bleeding (o sangrado), incluso si ello conlleva a la utilización de mas UDIMs. En algunos software 3D puedes indicar la cantidad de bleeding en pixels que quieres utilizar, asociado a la resolución de textura.
El bleeding también facilita la labor de los texture artists a la hora de seleccionar partes del asset en Mari.

Seams
UV seams no son tan problemáticos como solían serlo, ya que nadie pinta en un espacio 2D como Photoshop. Aunque en algunas ocasiones solemos utilizar Nuke para texturizar ciertos assets. Cuantos menos seams y más escondidos a cámara mejor. Si necesitas más seams para evitar males mayores como overlapping, stretching, etc. no dudes en realizar más cortes.

Stretching
Procura que exista la menor distorsion posible en tus UVs. Software como UV Layout te ayuda a visualizar el stretching en tiempo real. Utiliza siempre un texture checker para evitar este tipo de problema.

Escala
Es extremadamente importante establecer una escala global y comun para cada show. De esta forma todos los assets pueden convivir juntos en el pipeline de texturizado y look-dev. Seremos capaces de reutilizar texturas y shaders sin preocuparnos por problemas de escalas.

Los hero assets pueden sufrir cambios de escala con respecto al resto de assets en funcion de su condicion de extraordinarios.

Orientación
Procura mantener la orientación natural de los objetos en el espacio UV. De esta forma resultará más cómodo y rápido pintar detalles sin necesidad de reorientar el lienzo. En el caso de assets tipo tablas de madera, mantener la misma orientación ayudará a repetir texturas sin necesidad de crear mascaras secundarias para diferentes tipos de rotación.

UDIMs
En VFX llevamos utilizando el sistema UDIM tile alrededor de 10+ años. Hero assets generalmente tienen más de 50 UDIMs proporcionando resolución de textura más que suficiente para la mayoría de planos del show.

Es conveniente mantener cierta lógica y orden en la organización de los UDIMs, colocando siempre en el mismo lugar las extremidades de un personaje, o los ojos, o la ropa, etc. También es común agrupar partes de un asset similares en cuanto a morfología o tipo de material, de esta forma facilitaremos la labor de los texture artists.

La estandarización de los UDIMs es vital en el pipeline de un facility VFX.
El diseño de templates de UDIMs varia en función del tipo de asset (personajes, entornos, props, entornos, etc.).

Siempre preferimos más UDIMs que mayor resolución de textura.

UV sets
Es comun utilizar diferentes UV sets cuando trabajamos con hero assets.
UV sets secundarios generalmente tienen menor resolucion de UV mapping y son utilizados para crear dirt maps, wet maps, dummy textures, fur maps, etc.
Asegurate de crear siempre al menos un UV set extraordinario para previz, rigging y tareas similares.

Diferentes resoluciones
Resulta una práctica común tener diferentes resoluciones de un mismo asset, a todos los niveles. Modelado, texturas, shading, simulación, etc. Como norma general tendemos a texturizar primero los assets de alta resolución y después transferir las texturas a otros UV mapping de baja resolución. Debes dominar las técnicas de transferencia de texturas entre modelos con diferente resolución y diferente layout de UVs.

Mirroring/Symmetry
Si trabajas con assets simétricos, o que son simétricos hasta cierto punto (vehículos, personajes, etc.) procura trabajar siempre en simetría o espejo, de esta forma ahorrarás mucho tiempo a los texture artists. Pese a que las texturas nunca van a resultar simétricas, siempre es bueno poder reutilizar una base y modificarla que empezar el trabajo desde cero.

En el caso de tener objetos duplicados (por ejemplo decenas de tornillos) haz una copia de UVs y muévelas, de esta forma facilitarás la copia de texturas al texture artist. Nunca las dejes unas encima de otras (overlapping).

Una copia es mejor que un flip. Copiar UDIMs en Mari es muy sencillo, un UV flipped necesitas pasos extra, por lo que requiere más tiempo.

Ptex
Nadie en VFX utiliza Ptex (hasta donde yo he podido comprobar).

Todo esto y mucho más, en nuestro curso online de UV Mapping en VFX.

Posted
AuthorXuan Prada

El otro día un alumno del curso "Técnicas guerrilla para la creación de planos VFX" me escribió un email preguntándome si Arnold no tenía AOVs para RAW lighting y albedo, ya que anteriormente trabajaba con otros motores de render que si disponían de los mencionados AOVs.

La respuesta es si y no. Es decir, por defecto si miramos la lista de AOVs de Arnold, no veremos ninguno llamado RAW lighting o albedo. Pero si, podemos fácilmente crearlos, os explico un par de soluciones.

  • En los AOVs de Arnold, como veis en la imagen los AiStandard no disponen de AOVs para RAW lighting o albedo.
  • La solución más sencilla es utilizar los AlShaders. Que como podéis comprobar, si que incluyen AOVs tanto para RAW lighting como albedo. Solucionado.
  • Supongamos que tenemos que utilizar AiStandard, aun así, podemos controlar de forma individual este tipo de información. Lo que necesitamos hacer es renderizar los AOVs que comúnmente renderizamos, dependiendo de las necesidades de cada uno, pero generalmente seran AOVs primarios y AOVs tecnicos.
  • También necesitamos hacer un albedo a mano, es decir, sustituyendo todos los shaders AiStandard de la escena por Surface shaders de Maya, que como sabéis, no les afecta la iluminación. En una escena muy compleja, esta tarea puede ser tediosa, pero raramente necesitaremos el albedo de toda la escena, solo de algunos hero assets. Además, esta tarea puede ser automatizada mediante scripting. ¿Algún voluntario?
  • Una vez en Nuke, voy a importar el beauty y el albedo pass.
  • Si dividimos uno por el otro obtenemos el RAW lighting. Con lo que podemos manipular la iluminación sin afectar a el color.
  • También podremos manipular el color independientemente de la iluminación. En este caso estoy tocando el color utilizando un color correction y clonando parte de la textura utilizando un roto paint.
  • Vuelvo a juntar los dos componentes, luz y color utilizando un multiply.
  • Si no hubiera realizado ningún ajuste a la iluminación o al color, esta operación debería de darnos exactamente el mismo resultado del beauty.
  • Finalmente como tenia tambien la informacion de sombras almacenadas en el alpha, provenientes de un shadow catcher, voy a ponerle un suelo a la imagen :)

Uno de los AOVs que más vamos a utilizar durante la etapa de look-development es el AOV con información de UVs de las diferentes partes de nuestros assets. En este video muestro un par de alternativas para renderizar este AOV en Arnold Render y como utilizarlo en Nuke. El único requisito es que los assets tengan un UV mapping decente.

Estas metodologías y otras similares las pondremos en practica en el curso "Texturizado y look-dev avanzado".

Edito: En el video se me ha olvidado mostrar que en el nodo aiUtility el shade mode tiene que ser flat, si no, encontrarás distorsiones o errores de escala en tu AOV de UVs.

Posted
AuthorXuan Prada

Llego tarde, pero más vale tarde que nunca. Aunque ya hace tiempo que estoy interesado en VR (realidad virtual) y AR (realidad aumentada) apenas he tenido tiempo de estudiar al respecto y realizar pruebas. Hasta el momento he estado más interesado en capturar live action para VR que en generar contenido 3D, aunque ahora también estoy empezando a estudiar al respecto.

Hace un par de días tuve la oportunidad de probar el HTC Vive durante unas cuantas horas y definitivamente, poco a poco iré realizando más pruebas relacionadas con realidad virtual, al tiempo que voy estudiando la materia. Me interesa especialmente la evolución que sufrirá la narrativa, y los cambios que veremos en el lenguaje cinematográfico tal cual lo conocemos hoy.

Probando el HTC Vive.

Probando el HTC Vive.

Como primer ejercicio tanto de captura como de generación de contenido 3D, he realizado una prueba muy sencilla, pero que me sirve como primer contacto para renderizar imágenes estereoscópicas mediante estereográfica y probarlas utilizando el headset más simple y barato del mercado, Google Cardboard y UMI 3D. (más info abajo).

Antes de explicar la sencillísima forma de renderizar este tipo de imágenes, vamos a explicar un poco del contexto necesario para entender de forma muy básica algunos principio de VR.

Existen dos tipo de sistemas de realidad virtual. Aquellos en los que podemos rotar la cabeza alrededor de un mundo virtual, y aquellos en los que además de rotar, también podemos trasladarnos por el espacio, incluso interactuar con el. En el caso de las Google Cardboard y otros headsets para smartphones, solo podemos rotar la cabeza para inspeccionar alrededor del entorno. Para ello, nos servimos del giroscopio y del acelerómetro que incorporan los teléfonos hoy en día.

Hoy por hoy utilizamos dos tipos de formatos de imagen. Cuando hablamos de contenido pre-renderizado. Por un lado tenemos las imágenes lat-long, o también llamadas equirectangular, y por otro lado las imágenes cúbicas. Las dos se mapean de forma esférica para crear un mundo virtual. Básicamente necesitaremos generar dos imágenes esféricas, una para cada ojo.

Las imágenes lat-long son geniales, porque podemos ver todo el mundo en un solo golpe de vista. El problema que acarrean, es que el 66% de la imagen corresponde a los polos de la esfera virtual donde se mapean, y en esos polos hay demasiada distorsión.

Proyeccion lat-long.

Las imágenes cúbicas para este tipo de contenido son quizás más efectivas que las lat-long, ya que las imágenes se mapean virtualmente en el interior de un cubo, de tal forma que los polos estarán proyectados en dos caras del cubo, lo que corresponde a un 33% del total de la imagen. Esto significa menos distorsión cuando se convierte a espacio esférico.

Proyección cúbica.

Estereografía. Es el acto de proporcionar dos imágenes desde dos cámaras distintas. Entre cada una de las dos cámaras existe un desfase que representa la distancia entre un ojo y el otro. En el caso de cine stereo, esto se realiza renderizando una imagen para el ojo izquierdo y otra para el derecho, y ambas se proyectan en una pantalla plana. 
En el caso de VR, necesitamos renderizar no solo izquierda y derecha, si no también frontal y trasera, siempre manteniendo el mismo desfase entre cámaras, para así poder rotar en todas direcciones.

Por supuesto, hay mucha teoría y conceptos básicos que necesitamos conocer a la hora de trabajar con VR, pero para este simple ejercicio, creo que este es contexto suficiente.

Trabajando en software 3D

  • En esta ocasión, voy a combinar material rodado con material generado mediante VFX.
  • Ya tendremos tiempo en otra ocasión para hablar sobre sistemas y metodologías de captura de fotografía y video. Hoy nos basta con saber que he capturado una imagen panorámica utilizando un rig Nodal Ninja y un fisheye lens, montado sobre una Canon 5 Mark III. La resolución capturada es de alrededor de 12k
  • Con esa imagen puedo fácilmente crearme un mundo virtual fotorrealista, ya que está basado en fotografías. Como este es un ejemplo sencillo, no quiero perder tiempo en crearme un mundo virtual por completo empezando desde cero. Además, lo que más me interesa en VR es precisamente combinar elementos reales con elementos virtuales.

Tate Modern, Londres.

  • Esta imagen de arriba es el panorama que he creado a partir de varias fotografías realizadas en Tate Modern, aquí en Londres. Puedes descargarte este panorama y otros completamente gratuitos aquí. Además, son imágenes HDRI, con lo que podré utilizar el mismo mapa para iluminar mi escena, al menos en parte.
  • Como el mapa panorámico es 360 x 180 puedo cubrir todo el campo de visión para posteriormente rotar mi cabeza con el headset de VR y mirar en cualquier dirección.
  • El siguiente paso es crear los elementos virtuales de mi escena. En este ejercicio simplemente voy a posicionar un robot en el centro de la escena y un par de esferas.
  • Lo ideal es colocar la cámara virtual en aquella posición del entorno donde quieres que los espectadores estén colocados posteriormente en la experiencia de realidad virtual. Recuerda que en este ejemplo utilizamos un headset de smartphone, con lo que el espectador no podrá caminar alrededor del entorno, solo mirar en todas direcciones.
  • Como podéis ver más abajo, la escena es muy simple. Utilizo el propio HDRI panorámico para iluminar. También estoy utilizando un par de softboxes como key lights.
  • Vray no renderiza el fondo en sus environment lights (how clever...). Así que como quiero ver el entorno en el render tengo que crear un environment override con la misma imagen panorámica que utilizo para iluminar, asegurándome que está en la misma orientación.
  • Tambien utilizo un shadow catcher para proyectar las sombras de mis assets 3D en el entorno live action.
  • En este punto, si realizo un render, deberia de obtener el resultado esperado. Simplemente trabajo mi escena como lo haria en cualquier otra ocasion. En este caso con una camara rectilinear y con resolucion HD.
  • El siguiente paso es añadir un Vray extra attribute para convertir nuestra cámara en una cámara estereoscópica. Por defecto dejamos la distancia entre ojos A 6.5cm que es más o menos lo normal en el ser humano. También dejamos desactivada la opción de especificar un punto de enfoque concreto, a menos que creativamente queramos dirigir la mirada del espectador a un lugar concreto del entorno.
  • Si volvemos a renderizar, obtendremos un render para cada ojo. Ya tenemos estereoscopía.
  • Ahora que ya tenemos un render para cada ojo, lo siguiente que tenemos que hacer es renderizarlo de forma esférica para poder mapearlo en un mundo virtual. En este caso vamos a utilizar una proyección cúbica, que como vimos anteriormente tiene menos distorsión.
  • Para ello basta con crear un override de camara tipo cube 6x1
  • Finalmente tenemos que indicar la resolución del render. Esto depende del dispositivo VR que vayas a utilizar, aplicación, soporte, etc. Los desarrolladores de hardware tienen documentación al respecto, recurre a ella. En este caso, para Google Cardboard y similares utilizamos una resolución de 9216x1536. 
  • Como buena práctica es recomendable desactivar el filtrado, para así no acentuar los posibles errores de stitching.
  • Si chequeamos el render en Nuke obtendremos algo similar a esta imagen.
  • Perfecto, ya solo nos queda publicar nuestra imagen para visualizarla en un dispositivo VR.
  • Estoy utilizando irisVR que permite subir las imágenes a través de una aplicación web, para posteriormente visualizarlas a través de su propia app (apple y android) utilizando tu VR headset.
  • Simplemente tienes que crearte una cuenta gratuita y subir las imágenes.
  • Una vez subidas las imagenes, apareceran en tu libreria.
  • Ya utilizando tu smartphone, ejecuta la app de irisVR llamada Scope y en tu libreria podras ver todas tus imagenes subidas a traves de la web.
  • Selecciona cualquier de ellas y la propia app te indicara que coloques tu movil en el VR headset.
  • En este caso estoy utilizando dos diferentes, Google Cardboard y UMI Box 3.
  • Y con esto ya tenemos nuestros renders 3D y fotografias listas para ver en un VR headset.
  • Asi es como se ven el el movil cuando no tenemos el headset puesto.
  • Obviamente esta experiencia dista mucho de interactuar con contenido digital o fotogrametría dentro de un headset como el HTC Vive, pero como primer ejercicio no estaámal. Seguiremos hablando de VR en el futuro a medida que aprendamos mas al respecto.

Estas son las mejores opciones a la hora de exportar meshes desde Maya a Mari, para poder pintar en las condiciones adecuadas, sin distorsiones ni stretching.
Si, ya se que Mari 3.0 soporta OpenSubdiv, pero ya me he encontrado varias situaciones donde Mari genera artefactos en la geometría, especialmente con meshes complejas o formadas por muchas piezas independiente. Así que por el momento, seguiré utilizando las opciones de subdivisión tradicionales de Maya.

Posted
AuthorXuan Prada

Una de las situaciones más comunes que nos podemos encontrar durante la etapa de look-dev de un asset, es que tengamos mapas de desplazamiento procedentes de diferentes aplicaciones. Generalmente Zbrush/Mudbox y Mari. Esto puede suponer un par de problemas, el primero las diferentes escalas para cada una de las capas, y el segundo, el offset, o también llamado valor de no-desplazamiento.

Lo más inteligente es trabajar siempre con .exr 32 bits, para al menos solventar el segundo problema, ya que el primero siempre estará presente. De todas formas, veamos como solventar esta situación en Clarisse. Ya habíamos visto hace tiempo como hacerlo en Maya/Arnold.

  • Empecemos echando un vistazo a los mapas que vamos a utilizar. En este ejercicio tendremos tres capas de desplazamiento diferentes.
  • La primera capa ha sido realizada en Zbrush. Ha sido exportado como .exr 32 bits cuyo valor de no-desplazamiento es cero.
  • La segunda capa es un high frequency realizado en Mari. Ha sido exportada también como .exr 32 bits cuyo valor de no-desplazamiento es también cero. Es decir, técnicamente este mapa y el de Zbrush son iguales, la única diferencia es la escala.
  • La tercer capa de desplazamiento es un low frequency y también viene de Mari, pero en este caso se trata de un .tif de 16 bits cuyo valor de no-desplazamiento es 0.5
  • El objetivo es combinar todas las capas en Clarisse y utilizar el resultado como desplazamiento.
  • Antes de nada, crea version mipmapped de todos los mapas. Conviértelos a .tx
  • Lo primero que tenemos que hacer es crear un nodo displacement y conectarlo al asset 3D.
  • Vamos a considerar la capa de Zbrush como nuestra capa primaria, así que el displacement deberá tener un front value de 1 y un offset de cero. Esto quiere decir que el valor de no-desplazamiento es cero, como corresponde a los mapas de 32 bits. Y si conectamos nuestro mapa de Zbrush, se verá exactamente igual a como lo veíamos en Zbrush, no necesitamos ajustar nada.
  • Con todos los mapas en el material editor, lo primero que hago es conectar un multiply node delante de cada textura, así puedo controlar fácilmente la intensidad. Por defecto se multiplica por 1, es decir, se queda como está. Aumentando o disminuyendo valores afectaremos la potencia de cada capa de desplazamiento.
  • En el caso del desplazamiento de Zbrush no necesitas tocar su intensidad (a menos que quieras hacerlo). Si deberás reducir la intensidad de los desplazamientos de Mari, ya que están en una escala completamente diferente a Zbrush.
  • Delante del desplazamiento de 16 bits cuyo valor de no-desplazamiento es 0.5 he puesto un nodo add donde le resto -0.5 para así re-mapearlo a valor de no-desplazamiento cero, para que se iguale al resto de capas de desplazamiento.
  • Finalmente sumo todo con nodos add y conecto el resultado al nodo de desplazamiento.
  • Es buena practica testear cada capa por separado hasta encontrar el look que buscamos, para que después la mezcla funcione correctamente.
  • No desplazamiento.
  • Capa de Zbrush.
  • Capa de Mari high frequency.
  • Capa de Mari low frequency.
  • Todas las capas de desplazamiento juntas.