sprites & opacityPP

Algo que no había probado son los sprites (y deepshadows). La ultima vez que lei algo sobre el tema (con 3delight), vi que muchos parámetros no eran exportados, por lo que el shading no jalaba al 100% (creo que fue el plugin 3dfm para maya 8.0!).

Hoy mientras espero la luz verde del proyecto en que estamos trabajando, aproveche para darle otro vistazo - mas a fondo:

• El wizard de maya funciona perfecto y todos los parámetros de animación de los sprites son respetados por 3delight.
• Si decides meterle expresiones a las partículas por tu cuenta (asi como los sprites en secuencia) también funciona.
• Lo que NO funciona, es el opacityPP (cuando creas un arrayMapper para que sean mas transparentes conforme alcanzan el ocaso de su existencia PP).

Este valor (con su rampa) le añade al render la posibilidad de "suavizar" el look. Aparte de que permite ajustar el problema que surge a veces con los sprites y las sombras (y que en general se controla con el 'bias' de las luces). En la imágen de la derecha hay un side by side.



A través de un nodo delightAttributes en las partículas podemos exportar los valores de opacityPP que devuelve el arrayMapper (un float exportado en el rib), pero no se consideran a nivel de shading, por lo que hay que crear una conexión entre opacityPP y el shader asigando a las partículas. Generalmente el shader creado por el wizard de maya es un lambert, por lo que solo es necesario 'insertar' el valor adicional y no crear todo de nuevo.

La forma de insertarlo, es creando un nodo rendermanCode, con las siguientes lineas en shading parameters:

shader_input varying float opacityPP
color mayaOpacity
output color o_opacityPP

Y las siguientes lineas en shading code:

o_opacityPP = 1 - (( 1 - mayaOpacity) * (1 - opacityPP));

La forma de conectarlo es:

• La salida "outTransparency" del file node donde leemos la secuencia de sprites a "mayaOpacity" del rendermanCode. Aqui llevamos la información del alpha de los sprites, y vamos a sumarle lo que hay en el arrayMapper.
• Ahora del rendermanCode, conectamos "o_opacityPP" a "transparency" del lambert.
• En el nodo delightAttributes, exportar "opacityPP" de las particulas.
• Voila!

En los parámetros que definimos, hay una entrada 'shader_input varying float opacityPP' que se inserta en el shader al momento de generar el rib. Lo demas es una resta del valor alpha menos lo que tenemos en el arrayMapper.

En cuanto este el render, lo posteo ;)

Tequisquapan

Hace como un mes, nos fuimos a dar la vuelta a Tequisquiapan, a unos 40 minutos de Queretaro. La idea era ir a volar en globo y despues viajar a Queretaro. No tenia idea de como era (me lo imaginaba como Tequesquitengo :p ), y me quede con ganas de volver por ahi del 29 de mayo (Feria Nacional del Queso y el Vino!!!).

http://www.tequis.info/ferias.html

Y bueno, aqui una foto del inicio del vuelo. Tengo mas, pero esas mejor las meto al flickr.
Ese dia no estaba muy bueno porque la velocidad del viento era muy alta (ademas del peligro, el vuelo iba a durar muy poco). Al principio parecia que se iba a cebar, pero justo cuando desayunabamos, nos avisaron que se podia volar desde otro punto!

Nuestro vuelo duro como 40 minutos.. es diferente a aventarse de paracaidas, pero tambien vale la pena.

delayed rib archives

Este ejercicio fue para probar DRAs o delayed rib archives. Esto es, escribir una secuencia de ribs y leerla al momento de renderear y solamente cuando sea visible en la camara (es la diferencia entre 'delayed' e 'immediate'). Esto permite ahorrar memoria ram cuando tenemos muchos elementos (Los habia usado para algunos shots de Navidad S. A., pero esta fue mi primera vez con 3delight, ademas, esta ocasión si pude especificar que pasadas queria tener :p ).

Para este render, se usaron 180 ribs (que incluyen shaders con AOVs) integrados a la escena de maya con "cajas" donde se leen los archivos (3delight > Add Rib Archive).

Este nodo se puede duplicar y mover en la escena, lo que crea nuevas instancias del objeto que se esta leyendo. Pero que pasa si es un ciclo? Bueno, hice un pequeño mel que permite ciclar los archivos (solo duplica el Add Rib Archive el numero que quieras y selecciona todos los nodos antes de ejecutar el script):

global proc exp_delay(string $path_rib, int $maximo)
{
int $num;
string $temporal;
string $sse []= `ls -sl -dag`;

for ($num = 0; $num < variacion =" floor" temporal = "int $currentFrame = `currentTime -q` + " ribnum =" \" ribpath =" \" currentframe =" fmod(">= 100)\n $ribNum = ( \"0\" + string( $currentFrame ) );\nelse if ($currentFrame >= 10)\n $ribNum = ( \"00\" + string( $currentFrame ) );\nelse\n $ribNum = ( \"000\" + string( $currentFrame ) );\n\n$ribPath = \"" + $path_rib + "\" + \".\" + $ribNum + \".rib\";\nsetAttr -type \"string\" \"" + $sse[$num + 1] + ".ribFilename\" $ribPath;";

print ($sse[$num + 1] + " \n");

expression -s $temporal -name ($sse[$num + 1] + "_readRib");
print ("listo " + $sse[$num + 1] + " \n");

}
}

Ese codigo en el script editor se manda a llamar con:
exp_delay("/mnt/projects/rib_arch/3delight/source/rib/rib_source", 180);

donde la primera cadena es la ruta a los archivos. No tiene extension ni tampoco el padding del numero (el script considera algo como source.0000.rib). El numero '180' es el numero de ribs que tenemos (181, si contamos el 0000). Y 'enter'.

Este script crea expresiones que no estan unidas al nodo en si, pero permite asignar una nueva cadena de texto cada vez que avanzamos en el tiempo. Esto tiene la ventaja de que no tocamos el pre-MEL en el renderpass. Ademas, puede haber un gran numero de nodos y podemos asignar nuevas expresiones cada vez (eliminando las anteriores, claro).

Lo que estoy pensando ahora es que los nodos donde leemos los ribs deben estar fuera de grupos (en la "raiz" del outliner), porque el script no considera grupos (creo que debe ser`ls -l -sl -dag`).

El modelo es de Juan Carlos Lepe. Animación y rig de Fernando Najera (gracias chicos, sin ustedes nada de esto seria posible!!).

Y render con algo de compuesto y algunas pasadas:

AOVs & rendermanCode

Cuando instalé la version 8.0.1 de 3delight, pense en como implementar código que ya existia en nodos que pudieran conectarse cuando fueran necesarios, que permitieran entradas o salidas con nodos de maya (en el hypershade) y sobre todo que permitieran definir AOVs (render passes). Primero pense en compilar archivos .sl y quedarme con .sdl que tuviera las pasadas mas comunes: constant color, diffuse, specular, reflection, occlusion, subsurface scattering, normals, depth y un par de mattes. Con cada variación en cada pasada; el código creció. Utilizando headers y separando secciones se tiene organización, pero no es posible conectar un "file node" a los sdls.

La respuesta estaba en el nodo rendermanCode. Aqui se pueden definir variables (shading parameters) y el código que utiliza esas variables (shading code). También se pueden definir variables de salida que se conectan a otros nodos usando el hypershade y también variables que podemos usar como AOVs. Asi descartartamos fragmentos cuando no son necesarios.

Con la versión 8.0.1, tenia un problema con la pasada de environment reflection y subsurface: un poco del reflejo se sumaba al subsurface. Al parecer entre esa version y la que estoy usando ahora (8.0.39), se corrigió ese "detalle" y las pasadas ya no tienen mas errores.

Estos dias con la depurada de archivos en el servidor (al menos la basura que yo genero), me encontre con mis primeros renders de fur:

• resolución alta (HD)
• dof
• motion blur
• densidad
  
• deepshadows
• dynamic hair

Asi que recorte un pedacito de un cuadro y aqui esta. Es la primer revision del srf_fur y no habia modificado algunas variables (como surfacenormal o basecolor). Tampoco tenian atenuación.

Animación:

renderman

Estos dias me reencontre con renderman. No con prman, sino con 3delight (ya saben, el de la primera licencia gratuita en http://www.3delight.com).

El reto fue fur (mas bien lo que me obligo a retomarlo). Y como la ultima vez que lo intente no me fue nada bien (mental ray + maya fur + hair), pense que esta vez tambien iba a chaquetear!

La verdad, la forma en que manejan los modulos (con el plugin para maya 2009 - 3dfm), es un poco mas complicado que con prman. Al final, entendiendo como funcionan los Attributes (geo, light, etc etc) y los renderpasses (con sus respectivos render layers) y shaderdl y los parametros para render desde terminal, ya es mas facil.

Creo que mas adelante podre postear un par de cosas, pero por lo pronto un pequeño fragmento de un still (es lo que puedo mostrarles).

El shader es modificado (con atenuacion, AOVs y un par de cosas mas de http://www.renderman.org/RMR/Shaders/SIG2000/SIG2k_srf_fur.sl).

En la imagen tenemos motion blur + depth of field y es bastante eficiente. La resolucion es HD720.
Aunque es posible renderear pasadas, no es lo recomendable.

creo que es todo (ya puedo subir imagenes!).