3Delight thread! @ deathfall.com

Voy a tratar de hacer algunos tutoriales para 3Delight for Maya. Mi intencion es que sean constantes hasta donde me sea posible. El link es http://www.deathfall.com/forums/showthread.php?p=105753#post105753 y los primeros 3 son de instalacion y render basico.

Tengo algunas ideas, pero ya las pondre por alli.

3Delight 9.0 /3Delight For Maya 5.0

Ya salio la nueva version de 3Delight!!

Changelog
http://www.3delight.com/en/modules/d...ight_changelog

Descarguen de aqui:
http://www.3delight.com/en/index.php/download/step_1

Ya imaginaba que iba a salir estos dias, ademas de que houdini anunció también soporte para la versión 9!!

Pensaba postear un par de cosas en el ftp, pero aplus.net es una mierda del tamaño de un lobo feroz >_<

Edit: Esta es la lista de cosas oficial para este release
3DELIGHT 9.0 AND 3DELIGHT FOR MAYA 5.0
============================
December 2009

New Unlimited-threads License
* A new unlimited-threads license is now available for both
the 3Delight standalone renderer and the 3Delight for Maya
plug-in. Clients that purchased the 8-thread license (and
under yearly support) are automatically upgraded to
unlimited-threads. The 8-thread license will no longer be
available, but the 4-threads and 2-threads will continue to
be available at a reduced pricing.

3Delight For Maya
* Introducing RIB Fragments: a user-friendly and flexible way
of creating and managing RIB archives. This feature is
useful to accelerate re-renders.

* The display drivers UI has been improved and simplified
making it easier to manage and visualize output variables
(AOVs). "Primary Displays" and "Secondary Displays" have
been collapsed into the same UI.

* Major performance improvements to the 3Delight Relationship
Editor which make it responsive even with very large scenes.

* Improved UI in the 3Delight Relationship Editor by using
distinctive icons for different shaders and attributes.

* Added support for many useful Hypershade nodes, most
importantly: misss shaders, car paint, metallic paint,
glossy reflection and glossy refraction.

* Scene parsing optimizations reduce RIB output time by 20%.

* It is now possible to render Shave and a Haircut nodes
without loading the 3dfmShave plug-in: 3Delight for Maya
automatically uses Shave plug-in's RIB export function in
that case.

* Maya sprite particles can now be rendered as "volumes" for
correct shadowing.

* Maya fluids implementation enters a beta stage. All current
limitations are listed in the user's manual in the
Rendering Guidelines chapter.

* Added Maya 2010 support and dropped Maya 8.0 support.

3Delight Features
* Introducing multi-camera rendering. This features enables
the output of many camera views from a single render. This
functionality is especially useful for stereo rendering as
it saves rendering time.

* Improvements to point-based occlusion quality: concave
corners are rendered more accurately.

* The subsurface shadeop can proceed from a point-cloud file.
This can save a potentially costly pre-processing step when
rendering sequences.

* Billboard particles can now be rendered with a "thickness"
for correct shadow casting.

* Network caching, a feature unique to 3Delight, is now
available on Windows systems.

* Added detailed memory statistics to 3Delight to better
track memory usage.

3Delight Performance
* Improved performance of occlusion() and indirectdiffuse()
shadeops when rendering dense meshes. Speedups can reach
200%.

* Improved multi-threading performance on scenes containing
procedural geometry (such as delayed read archives).
Procedurals are now allowed to execute in parallel which
can lead to speed improvements linear to the number of
threads used.

* Accelerated point-based occlusion as it now supports the
"irradiance shadingrate". Speedups with default settings
are in the range of 200% to 300%.

* Improved multi-threading performance and memory consumption
of subsurface scattering algorithm.

* Improved deep shadow map creation performance. On large
shadow maps, performance increases linearly with the number
of cores. Temporary disk space usage during DSM creation
has been reduced three-folds.

* A new memory allocation scheme in the ray-tracer
significantly lowers memory consumption when rendering
object: only one object instance is kept in memory at any
time. This feature is enabled through a special variable.

* Improved point-cloud loading time. This has a positive
performance impact on effects such as point-based occlusion
and color bleeding.

Shader Compiler
* RSL 2.0 improvements including resizeable arrays, better
supports for shader classes and more efficient execution.

Pipeline & API
* Introducing the "VolumeTracer" API. This RSL plug-in allows
user to easily write volume renderers.

* The "Sx" shader evaluation API is now embedded with the
3Delight library (takes a single 3Delight license when
used).

* Added "Implicit Field" plug-in support (extension to the
`RiBlobby' primitive).

* Display drivers can now access 3Delight's deep frame buffer
which provides the list of visible surfaces for each pixel
sample.

* Added new entries to the Ptc API and fixed compatibility
issues.

* `RiNuCurves' now support vertex normals.

simples extras

Ayer estaba revisando algunos scripts. Habia cambios que hacer en algunos procedimientos que cambiaron en 3delight 8.0.43 y es mejor ahora que mas adelante. O lo que es igual: justamente (como finalmente terminé de leer "Hablemos de Kevin", de Lionel Shriver, me lleve mi libro de "Movimiento Perpetuo", de Augusto Monterroso, qepd).

Bueno, la cosa es que necesito estandarizar mis variables de salida, ver si puedo entender coshaders y actualizar los shaders que mas uso, porque ha sido parche sobre parche desde abril 2009.

Pero eso no es lo que queria decir. Mas bien, me di un tiempo para revisar mis salidas extra, las del monton y que no siempre uso. Una de ellas es normales, obviamente, pero de las menos usuales es uv (st) y Point.

Tambien falta utilizar ifdef por si no hay AOVs :/

/* simple_utils */
surface simple_utils (
float salida = 3.0;
output varying color renderAOV_normal = 0.0;
output varying color renderAOV_point = 0.0;
output varying color renderAOV_uv = 0.0;
)
{
normal Nn = normalize(N);
vector In = normalize(I);
extern point P;
Ci = color (mix(0,1,s),0,mix(0,1,t));
if (salida == 1.0)
Ci = color (ntransform ("world", normalize (N)));
else if (salida == 2.0)
Ci = color (P);
renderAOV_normal = color (ntransform ("camera", normalize (N)));
renderAOV_point = color (P);
renderAOV_uv = color (mix(0,1,s),0,mix(0,1,t));
}

p.d. La cirugía de JC (ahora Vanessa) salio perfecta! rofllolzzers. En realidad le retiraron un tumor de la zona mandibular izquierda.

fur

Despues de un rato de no colgar nada por aqui, los actualizo:

* Finalmente estamos organizando archivos que habia en los discos de backup. Mas de 1.5 teras de datos (cerca de 350GB de bootlegs :p).

* Estamos estructurando el reel.

* Ya hay base para pagina web.

Mientras pasa eso, estoy actualizando alguno scripts y shaders. En 3delight 8.5.42:"Added several primitive variables available for output when rendering Maya Fur.". Esto significó retomar el shading de fur, modificar el código que estaba usando (http://www.185vfx.com/resources/coursenotes.html) e implementar self shadows con atenuación, mapas de color sin bakear el FurDescription de maya y como paso siguiente es leer occlusion y radiance de la superficie donde tenemos la raiz de cada pelo.

Estos son algunos renders de pruebas. Aun falta añadirle algo de opciones y probarlo en movimiento. Luego posteare algo acerca de los tiempos de render.

Calavera

Este es un proyecto que hicimos muy rapidamente. Para un concurso de edumac (una escuela de artes digitales).

El tema era la calavera mexicana tipica de este dia de muertos. Y la imagen de la derecha es con la que participamos jc y yo (jc modelado/sculpting) y yo render.

El resto de los participantes esta en http://www.flickr.com/groups/concurso-calavera/pool/

Por cierto, no tiene nada que ver pero pense que seria interesante para todos los que puedan pasar por aqui y leer lo que soñé: Resulta que estaba en medio de una fiesta con unos cuates en el lugar donde crecí (en Colima). Era ya de madrugada en esa fiesta y en un ataque de tos, termine con una flema colgando de la boca. Total que empece a jalar la flema con las dos manos y no se veia que terminara!. El punto donde me detuve fue cuando vi que de la flema venia colgando parte de mis tripas y una cosa parecida a un riñon (los vi en un programa del discovery).

Al ver mis tripas en el suelo, empece a acomodarlas en mi brazo izquierdo (como si fuera un tendedero o un largo cable ethernet de emergencia) y fui por ayuda. Lo malo es que la mayoria andaba ya con muchas copas encima y nadie me hacia caso. Me encabroné y fui por una sabanita para cubrir mis cosas y espere un taxi. Los dos taxis que pasaron tenian poco espacio y yo no cabia con mis tripas (y ni modo de dejarlas en la cajuela).

Ya cuando me habia acostumbrado a la situacion, llegue a un hospital, a la zona de emergencias, pero me dijeron que esperara, porque el servicio empezaba a las 3pm (y eran las 7am!!!).

El despertador (de la vida real) sonó y desperte cuando en mi sueño esperaba pacientemente sentado con mis tripas en un brazo cubiertas con un mantel.

Y eso es solo parte del sueño, tambien estuve caminando por Austin cargando a Gato, visitando a Alvaro y su monton de perros. Al parecer estaba desayunando una copa de vino blanco con un plato de frijoles con queso.

Bueno, es todo. Es de los sueños mas normales que he tenido. Ja!.

root

root

Deathfall is back!

Han pasado mas dias de lo que planeaba para actualizar aqui, pero he estado ocupado. De cualquier forma, no queria dejar pasar esto:

http://www.deathfall.com

Nos vemos ahi ;)

Actualización

Bueno, después de algunos pendientes, puedo actualizar aqui. Y después de que la tormenta se va, viene la calma y el recuento de los daños. :)

Un pipeline o flujo ideal siempre cambia, por mas mínimo que sea, para mejorar. Y puede ser desde una implementación a nivel hardware (todos los nodos conectados al servidor por ocfs2: no más autofs/nfs4) o un cambio en alguna parte del software (digamos, un script de bash para convertir sl a sdl en linux/windows con paths acordes al sistema) o simplemente a nivel usuario: cuanta agua necesita la cafetera para 4 tazas de té sin que quedes corto o no quede agua en la cafetera para que se evapore con el calor restante justo antes de apagarla.

Bueno, al final es regresar a lo mas simple, ver que tan eficiente, útil, compacto, elegante y portable es en relación a lo que puede llegar a ser. El tiempo necesario para llegar a ese punto "ideal" es lo de menos, finalmente, vendrán nuevas tormentas, trayendo consigo modificaciones simples que nos harán exclamar "aahh claro, eso era así".

¿El punto? El punto es que es el momento de regresar a lo mas simple, ver que tan eficiente, útil, compacto, elegante y portable es.

Un ejemplo:

/* simple_ptc_sss */

surface simple_ptc_subsurface(
string bakefile = "";
color albedo = color (0.830, 0.791, 0.753);
color dmfp = color (8.51, 5.57, 3.95);
float ior = 1.5;
float scale = 1.0;
)
{
normal Nf = transform ("world", "camera", normalize(normal N));
color sss = 0;
point Pcam = transform ("world", "camera", point P);

sss = subsurface (Pcam, Nf,
"filename", bakefile,
"diffusemeanfreepath", dmfp,
"albedo", albedo,
"scale", scale,
"ior", ior);
Ci = sss;
}

Mas detalles el viernes ;)

¡chan chan chanchaaaaannnnnn!

SAMAEL & raytraced reflections / ptc

¡SAMAEL de regreso en México!
19/Septiembre/2009 | ¿quien se apunta?.. yo ya tengo mi boleto :p


Y en cuanto a raytraced reflections, con 3delight 8.5.24, exportando un point cloud para leer "radiance", olvidé desactivar raytraced reflections. El resultado es que todo se transforma en luces aleatorias afectando difuso, el propio valor de radiance y color. De soporte me comentaron que no era necesario ni siquiera tener specular (de ser posible). Así que ustedes no lo olviden: no raytraced reflections cuando "beikien" point clouds.

ROFL
http://granades.com/2007/05/02/loltrek/

BTW may be old.

Yay! - 2.0

glossy reflections

Después de un proyecto mas en el estudio, estoy modificando algunos shaders que tenía pendientes. Principalmente convertir la sección de point clouds a un attributo mas, en lugar de a través de luces ambientales :)

Y parte de esa modificación incluye en algunas partes glossy reflections usando el mismo point cloud que uso para radiance.

Este código esta en el foro de 3delight, y se basa en indirectdiffuse con un ángulo de menos de 90 grados.

surface
ptc_glossyReflection (
string filename = "", sides = "front";
float clampbleeding = 1, sortbleeding = 1,
maxdist = 10, falloff = 0, falloffmode = 0,
coneangle = 0.2,
samplebase = 0.0, bias = 0.01,
maxsolidangle = 0.1;
)
{
normal Nn = normalize(N);
vector refl = reflect(I, Nn);
color irr;

irr = indirectdiffuse(P, refl, 0, "pointbased", 1, "filename", filename,
"hitsides", sides, "clamp", clampbleeding,
"sortbleeding", sortbleeding,
"maxdist", maxdist, "falloff", falloff,
"falloffmode", falloffmode,
"coneangle", radians (coneangle),
"samplebase", samplebase, "bias", bias,
"maxsolidangle", maxsolidangle);

Ci = irr;
}

Kung Pao

Hoy para comer, preparamos Kung Pao, con un sobrecito de Asian Gourmet. ¿Las han probado o visto en algun supercito? http://www.asianhomegourmet.com.sg/

Estan bastante buenas. También hemos preparado el Kaang Daeng, y vale la pena. Una vez compramos uno en superama (no recuerdo el nombre) pero como que suavizan un poco las especias para que no peguen y se supone que era un Tikka Masala.

Estos los pueden comprar en la naval, superama, mikasa, entre otros. Y si donde viven no tienen y quieren probar, ya estamos exportando a la hermosa ciudad de Colima. :)

JC & Nothin' But Net!

Lacrimosa - 20 julio 2009 -Circo Volador

RiArchiveRecord

3delight for maya incluye algunos MEL bindings:

print `help -list "Ri*"`;

Pero no todos estan disponibles. Para el caso especifico de algunos DSO's es sencillo incluir una linea con `RiProcedural`, pero para algunos casos (massive, realflowRenderKit), es necesario utilizar `RunProgram`. Para eso, se usa una linea mas o menos como esta:

Procedural "RunProgram" ....

Este binding no esta definido para usarse en maya, asi que es mas sencillo usar RiArchiveRecord. Este comando inserta una línea de texto directo al rib que se genera. Asi que podemos decir que si hacemos una interfaz donde especificamos parámetros, una expresión para modificar el frame y tal vez una o dos cosas mas, es fácil de usar ;) .

El procedimiento es crear un dummy, asignar geometry attributes, desactivar 'output geometry', activar el atributo Pre Geo Mel y usar algo como:

RiArchiveRecord -m "verbatim" -t "Surface \"simple_ss\" Procedural \"RunProgram\" [\"myRunProgram\" \"-myVeryOwnParameters valueA -secondOneParameter valueB \"] [-1 1 -1 1 -1 1]"

Y Voilá!


edited: this is from a test done in the future (2011):

Realflow RenderKit

Estoy hundido.
O mejor, con el agua hasta el cuello, en medio de un proyecto donde se necesitan fluidos. Primero habia pensado en realflow, pero al avanzar el proyecto, se hablo de formas mucho mas controladas, movimientos mas 'orgánicos' y creo que puede ser mejor usar blendshapes y animar geometría con algunos deformadores para simular el movimiento del liquido; mucho de los requerimientos del director se enfocan mas en el look.

Y hablando de look, mucho de la simulación puede hacerse con nParticles de Maya, renderear usando blobbies y usar varias capas de particulas para tener variación en el mesh final.

Probablemente la ventaja de usar realflow, es combinarlo con el DSO que genera un mesh en tiempo de render. Aunque tambien es posible generar simulaciones con nParticles, exportar información de velocidad, uv, etc para poder usar el DSO.. o al menos espero que sea asi.

Vamos a pedir el demo y jugar con el (pero hasta dentro de un par de semanas).

http://www.realflow.com/rfrk/

김치 볶음밥 (kimchi bukumbap)

Hace un par de dias, después de juntas, revisiones, ajustes, calendarios, lluvia, charcos, spots de partidos politicos, videos y canciones de maicol yacson por todas partes, sentia un poco de estres.

¿Y que fue lo que hice para manejarlo?
Estrene mi nuevo wok y prepare kimchi!

• En un wok caliente, freimos cebolla, zanahoria, calabacitas (pueden añadir ajo picado también).

• Una vez que esta dos tres listo, añadimos tocino coreano (el normal puede funcionar si viene en trozos mas o menos grandes).

• Antes de que este completamente cocido el tocino, pueden agregarle aceite de ajonjolí (a mi se me olvido y me acorde 12 horas después). Una vez que esta cocido el tocino, añadimos el kimchi. mezclamos.

• Después del kimchi, agregamos la pasta de chile. Mezclamos perfectamente.

• Una vez que esta cocinado, bajamos el fuego y añadimos arroz al vapor (para sushi).

• Se integra perfectamente y esta listo para servirse.

• Puede acompañarse con kimchi, soju y un huevo frito (que se mezcla con el arroz preparado en el plato).

^_^ ^_^ ^_^

Y si eso no funciona, puede que esto si:

Monterrey Metal Fest - vol 4!

http://www.mmf.com.mx/vol4_bandas.php

something fishy

Parece que hay algo raro con 3delight.

Les dejo el link del post: http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=1519 [Point based approximate: very long rendertime].

bent normals

occlusion y bent normals estan relacionadas. Ambos se calculan al mismo tiempo y es posible calcularlos cuando usamos raytracing o cuando usamos point clouds y la diferencia que tenemos es la misma que con occlusion (grano con raytracing dependiente del numero de samples por ejemplo).

Este resultado no es igual a calcular N (pero se pueden usar ambos en compuesto). Y el renderearlo/calcularlo es opcional y dependiente del proyecto. Hay mucha discusión entre su utilidad. Personalmente, es poca la utilidad para reiluminar (como difusos/rims) y siempre termina controlando otras partes del compuesto.

surface bentnormals (
string ptcfile = "";
)
{
extern normal N;
extern point P;
extern vector I;
float bleeding;
vector bentNormal;
vector Nn = normalize (N);

if (ptcfile != "")
{
bleeding = occlusion(P, Nn, 0, "pointbased", 1, "filename", ptcfile, "environmentdir", bentNormal, "clamp", 1, "sortbleeding",1);
}
else
{
bleeding = occlusion(P, Nn, 128, "environmentdir", bentNormal);
}

Ci = color(normalize(vtransform("world",bentNormal)));
//cambiar dependiendo al espacio que se necesite
}

Originalmente, jc iba a subir esto, pero le quite el source y sus notas ;)

Notas:

• En el código, estamos calculando bent normals en world space. Aqui podemos usar "current" (que es "camera" con 3delight).

!!!

feria nacional del queso y del vino 2009

http://www.tequis.info/feria nacional del queso y el vino 2009.html

occlusion: ¿raytrace o point clouds?

Actualizando algunos shaders, llegue de nuevo al tema del occlusion. Hasta este momento, no habia considerado la posibilidad de usarlo en base a point clouds por dos razones:

• Hay una diferencia visual entre el generado con raytrace.
• El proceso de generar el point cloud solamente para calcular occlusion no significaba un ahorro de tiempo.

Ahora, viendo el resultado de ambos métodos llegue a la conclusión de que:

• Todos los cuadros de la pasada de occlusion van a ser calculados con el mismo método, por lo que no habrá variación en el render final (si 50 cuadros se calcularan con point clouds y 50 con raytracing de una secuencia de 100, es lógico que tendriamos un problema).
• Si estoy calculando el indirectdiffuse, es necesario generar el point cloud. Y si ya hay un point cloud, ¿porque no utilizarlo para sacar el occlusion también?

Bueno, ahora los renders:
En el render de la izquierda, estoy usando raytracing. El código es

surface
ambocc(
float maxhitdist = 10;
float bias = .005;
float num_samples = 256;
float angle = 90;
)
{
float is_matte;
attribute("user:delight_is_matte", is_matte);
if (is_matte == 0)
{
normal Nf = faceforward( normalize(N), I);
uniform float adaptive = num_samples >= 256 ? 1 : 0;
float a = 1 - occlusion (P, vector(Nf), num_samples, "adaptive", adaptive,
"angle", radians(angle), "maxdist", maxhitdist, "bias", bias);
Ci = a;
}
else
Ci = Cs;
Oi = Os;
Ci *= Oi;
}

Usando los valores declarados en el shader, aun tenemos algo de grano y el caracteristico borde blanco en superficies (que puede arreglarse como se explica aqui http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=1411) . El tiempo de render de ese still fue de 223 segundos (3.7 minutos aprox).

Ahora, usando point clouds, obtenemos el render de la izquierda. Tenemos menos contraste que en el render anterior. El código es (usando renderman codes porque aun no lo hago sl):

float radius = 90
float occ_bias = 0.001
string ptc_file = "myptc.ptc"
float aoMaxSolidAngle = 0.010
output color result_BT

extern normal N;
extern point P;
extern vector I;

normal n = normalize(N);
color result_OCC = color (1);

result_OCC = 1 - occlusion( P, n,
"filename", ptc_file, "pointbased", 1,
"coneangle", radians (radius),
"maxdist", 20,
"maxsolidangle", aoMaxSolidAngle,
"bias", occ_bias, "clamp", 1, "hitsides", "front" );

result_BT = result_OCC;

Los valores que hay que usar son los definidos en "Shading Parameters". Y lo que pueden ver es que no tenemos grano (el contraste se puede controlar en compuesto haciendo "clamp", 0). Otra forma de acercarnos mas al render de arriba, es haciendo maxdist mas grande. En el ejemplo con raytracing maxdist = 10, y usando point clouds maxdist = 20. Posiblemente aumentando la distancia, podamos acercarnos mas. De nuevo, como todo esto se maneja sin variación, el compuesto no debe tener mucha bronca.

El tiempo de render de la imagen de arriba es de 152 segundos (2.5 minutos aprox). Eso es casi 1 minuto de diferencia!!. Entre las ventajas de usar este método, aparte del minuto de diferencia, esta la posibilidad de calcular occlusion + displacement de forma rapida.

Creo que la mejor manera de ver si esto se rompe, es utilizandolo en un proyecto real. Por lo pronto, cualquier shader puede integrar la opcion de calcular occlusion usando point clouds si es que tenemos presente el archivo (sobre todo si estamos calculando indirectdiffuse) y agregando una opcion para que el usuario lo use o no.

Ya les dire despues si se rompe o no ;)

edit: En el render de point cloud, tambien hay algo raro en las esquinas superiores. Esto es porque cuando exporte el archivo usando bake3d(), la camara no tenia visible toda la geometria. Esto es importante ;)

Yay!

un simple displacement shader

Bueno, justo despues de ep_simple.sl, leia acerca de displacement shaders. Algunas veces, no es necesario calcular el occlusion de la geometria con displacement, pero si el surface shader no tiene acceso a P antes del displace, es obligado usar "trace displacement".

Asi que basandome en código que postearon el el foro, un displacement shader que encontre en highend y algunas opciones extra, surgió ep_displace.sl:




Básicamente permite manejar displacement y un bump. Si solo hay un mapa y disp_enable == 0, solo generamos un bump. También, internamente, hace una copia de N y P que estan disponibles para surface shaders que detectan que el "trace displacement" esta prendido o apagado. Y en combinación con este displacement shader, modifique ep_simple.sl para aprovechar estas variables.. el archivo actualizado ya lo pueden descargar de highend.. el de displacement lo pego por aqui cuando lo aprueben...

Listo!
http://www.highend3d.com/f/5752.html

un simple surface shader

Usar renderman Code para crear shading networks es una buena manera de aprender rsl. El siguiente paso es crear objetos a partir de archivos sl, asi que una buena forma de entrenarse, es crear pequeños shaders que incluyan las pasadas mas comunes y poco a poco, ir creando nuevos shaders especificos o versiones de shaders mas complejos.

En mi caso, los componentes mas comunes en cualquier revision de look para comerciales es: color, difuso, occlusion y reflejos de algun ambiente. A manera de precompuestos, tambien puedo incluir algun ambient (con GI) y una serie de mates.

Asi que para brincarme el paso de crear y conectar nodos en hypershade, hice un surface shader que incluye lo mas comun. Las ventajas de hacerlo asi es que los ciclos de illuminance los controlo con categorias, por lo que si utilizo un domo de luces que solo contribuyen al difuso, no se consideran dentro del ciclo usando lightsource(). Otra cosa es que aunque incluyo codigo para specular, occlusion y environment reflections, puede evitarse el calculo.

Creo que lo mas importante es que sirve como referencia para cualquiera que tenga ganas de empezar a escribir sus propios sl y/o añadir funcionalidad (como scatter, reflection occlusion, raytraced reflections, z, etc).

Estso son los valores default. Lo mas importante es que se usan shaders precompilados. Para un point light en maya, es necesario asignarle un maya_pointlight.sdl (que vienen incluidos en $DELIGHT/shaders). Para conectar intensity, lightcolor y shadowcolor, se puede usar un script en mel o python que lo haga automatico. Es necesario especificar las categorias en diffuse y specular solamente. Ambient viene por default si se usa el que incluye dna.


El shader permite cargar imagenes con alpha (optimizadas con tdlmake). Los resultados de las demas pasadas incluyen el alpha. A la geometria se le asignan atributos para calcular occlusion (diffuse visibility 3 - shader opacity) y se puede calcular tambien occlusion.



Algo que se usa mucho es compuesto es colorear el occlusion, asi que inlcui una opcion para multiplicar el resultado del occlusion con el color, en un rango de 0-1; 0 es occlusion en negro y 1 es completamente coloreado por el color.



Y finalmente, tambien se incluyen opciones de specular y 3 modos: 0 corresponde al modelo Blinn, 1 al Phong y 2 cartoon (que una vez postearia zj como zj_pecularPass.slim). El codigo de esta seccion pueden bajarla y convertirla de slim a sl de: http://www.highend3d.com/renderman/downloads/shaders/ZJ-specularPass-1863.html

El shader incluye codigo para calcular environment reflections, que es el mapeo de una textura (casi siempre un HDR convertido a tdl) y crear la sensacion de que estamos 'reflejando' el exterior.

Es sencillo modificar el codigo para que el resultado del render 'disuelva' los reflejos y speculars donde tenemos occlusion, asi que son libres de modificar, mejorar, o ignorar completamente este shader :)

Ah y finalmente, las variables de salida estan definidas en la linea 168 del archivo sl, asi que de ahi pueden tomar los nombres para definirlos en el renderPass (o ahi es donde pueden modificarlos y usar sus variables).

como carajos posteo el archivo?

Ya.. esta en highend3d, pero espero poder subirlo a otro lado pronto:
http://www.highend3d.com/renderman/downloads/shaders/5751.html

3delight 8.5

Ya se dieron cuenta de que 3delight 8.5 ya esta listo para descargarse de la pagina de dna research? Al parecer esta en linea desde ayer 5 de mayo.

Que hay de nuevo? Esto es lo que viene en changes.txt, pero por lo que veo, hay nuevos sdl's - shaders.otl tambien esta incluido (no recuerdo si venia en el 8.0) - el preprocesador de C es mas rapido!

update 1: nah, el preprocesador es una basura (pero con interfaz ^_^). shaders.otl si vienen en cada release (solo que antes no me interesaba ;) ).

http://www.delight.com/en

3delight 8.5 and 3Delight For Maya 4.5

3Delight For Maya

• Introducing the 3Delight Relationship Editor. This new user interface replaces the now deprecated Shader Manager and Attribs Node Manager and makes it much easier to view, assign and modify 3delight shaders and attributes, in a centralized location. The usability of shader and attribute collections is substantially improved thanks to this same feature and one can inspect, for each pass and at a glance, what attributes and shaders are in effect.
• Introducing “Pass Templates” It is now possible to save a given render pass as a template and create new passes based on existing templates.
• A new "round edge" features enables automatic edge rounding of sharp geometric features. Using this feature, one can round edges at render time (such as a table edge) instead of performing a costly modeling-time operator.
• Added a "dicing camera" attribute in the geometry attributes node (in the "Culling and Dicing" section). This features is useful to stabilize popping displacement during animation.
• Updates to HyperShade:
  • The “useBackground” node is fully supported.
  • Checker node with much better anti-aliasing.
  • 3D texture nodes now use texture reference objects if these are exported.
• Scene export has been optimized and runs twice as fast for certain scenes.
• The following MEL bindings have been added: RiBound, RiDetail, RiDetailRange, RiOrientation and RiShadingInterpolation.

3Delight Performance

• An overall speed increase of 20% is to be expected on all scenes thanks to SSE2 optimizations.
• Ray-tracing speed on displaced surfaces has been substantially improved. The increase can reach tenfold with large displacement.
• Cubic curve primitives take up to 20% less memory and can render up to 50% faster when using Ray-tracing.
• Improved performance of RIB reading on Windows to match that of other operating systems.
• Procedurals generated through RiProcRunProgram require much less peak memory, especially for very large primitives.

Improvements to multi-process rendering include:

• Multi-machine rendering is fully supported on Windows platforms.
• Baking 3D point-clouds using many machines is now possible.
• “Ri Filters” are supported in multi-host rendering.
• Improved behaviour with unresponsive or crashing rendering hosts.

Pipeline & API

• Array support has been added to the Ptc API. This also means that texture3d() and bake3d() accept array parameters.
• Helper functions have been added to the Display Driver API.

Shader Compiler

• 3Delight now supports co-shaders (as per RSL 2.0) and completes the implementation of shader classes.

car paint

Hace unos dias empece con un proyecto donde necesito metales. Los mas comunes son el cromo y acero (con y sin cepillar - anisotropico). También plastico (con mucho brillo y casi mate). Tal vez uno o dos componentes con pintura (como el mia_car_paint ).

En 3delight no hay un nodo que traduzca este nodo de mental ray (como el architectural.sl) y aunque esta planeado junto con otro nodos (http://www.jupiter-jazz.com/wiki/doku.php?id=wiki:software), esperar la proxima version no es una opcion ;)

Asi que buscando en google encontre esto: http://sfdm.ca.scad.edu/faculty/mkesson/vsfx319/wip/best_fall2008/martin_sawtell/car_paint/car_paint.html, pero no me convencio la forma de resolver los componentes, asi que empece con un rendermanCode node y un mia_car_paint_phen. La documentacion (http://download.autodesk.com/us/maya/2009help/mr/shaders/paint/paint.html) me hizo recordar un shader que maneja difuso con un falloff. El shader lo escribio Matt Pharr pueden ver el código en la página 65 y 6 de este documento http://www.scribd.com/doc/886637/sig02-course16.

El componente difuso cambia en base al angulo de la superficie con la cámara. También el inverso del "facing ratio" actua como difuso, pero en la pintura de autos nuevos es negro. Y finalmente, el angulo de la superficie con los puntos de luz tambien tienen una variación. Por lo que cada componente de difuso (base, edge y lit) tiene tambien un color correspondiente. El código en los tres casos es muy similar (en lit, el lugar de calcular el ciclo de illuminance con el vector de cámara I, usamos L, que son los puntos de luz). Al final, cada componente se suma.

A la derecha hay un render de los componentes del difuso. Abajo mental ray y arriba 3delight. Hay algunas diferencias, pero no son significativas. Ademas, con este shader trato de aproximarme lo mas posible al resultado de mental ray.

Los componentes de specular estan basados en el modelo Phong y para evitar problemas de multiples puntos a lo largo de la superficie (que sucede cuando se usan scripts como el generado por Binary Alchemy o HDRShop), el shader utiliza categorias (message passing).

La sección de reflection la robé directamente del código de architectural.sl, incluida en la distribución de 3delight. Honestamente, es la parte mas tricky para mi y por un momento pense en hacer esta pasada por separado, pero no existe (o aun no se como resolver) algo como mip_rayswitch de mental ray :)

Dentro del código y como mera joteria, se incluye la opción de calcular occlusion , reflection occlusion (solo por protocolo :p ), normales y un par de mates.

Este es un render comparativo (arriba el de 3delight):
Las principales diferencias estan en el edge_color (mas azul en el de 3delight), la dirección del ambiente HDR y un poco del blur o glossy. Haciendo un difference entre las dos imagenes, el ambiente HDR es lo que mas salta, pero creo que se debe a la forma de crear el archivo con tdlmake.

En still funciona perfecto.. pero si no se mueve no cuenta ;)

Algo que no esta resuelto es la parte de flakes :) Tengo algunas texturas procedurales, pero las opciones que tiene el mia_car_paint van mas alla de lo que puedo resolver en lo que me queda para tener listo el shading. Asi que mi plan B es hacer un bake con mental ray y utilizar esta textura para "mattear" un reflejo.

Y porque no lo hice en mental ray? buena pregunta...

ptc based GI - animation

Este es una animacion (simulacion con nCloth) aplicando GI.

Oldman sketch

Ya se, no habia publicado nada.
Finalmente aqui esta algo que habia hecho hace como un mes (antes de la cirugia en mi muñeca derecha) La idea surgio de estar navegando en la pagina de ArtRenewal, vi una escultura de un hombre viejo hecha por Valentin Okorokov y pense que seria un buen ejercicio empezar desde un cubo y asi fue.

Hecha entre mudbox 1.0.7 y zbrush. Espero pronto hacer un ejercicio de cuerpo completo.


Les dejo una imagen de los niveles (el ultimo nivel fue de 1.9m de polys), un render desde Zbrush, y un 360.

point cloud based GI

Hace dias trataba de hablar de los "point clouds" y occlusion, pero no tenia un ejemplo sencillo a la mano. Cuando tuve el ejemplo sencillo, no encontre mucha diferencia entre usar raytraced occlusion y el point cloud based occlusion (incluso usando displacement).

Al final, decidi que era un mejor ejercicio usar GI. Primero, el ejemplo es algo similar al cornell box con su point light y sombras.

Luego, hay que escribir el ptc (point cloud) al disco. Para esto, estoy usando un atmosphere shader. Esto permite iluminar y crear los shaders de manera independiente y sin considerar integrar o modificar la parte de escritura en los shaders mismos (lo dejamos al final). Por default, lo que esta fuera de la vista de la camara no entra al ptc, por eso es necesario definir un par de opciones en el pre-World mel del render pass (y habilitar "Standard Atmosphere"):

RiAttribute -n "cull" -p "hidden" "integer" "0" -p "backfacing" "integer" "0";
RiAttribute -n "dice" -p "rasterorient" "integer" "0";

Con esto, obtenemos un ptc de la escena. Aqui entra Ci (o surface color) y algunas otras variables. Una vez que tenemos el ptc, es necesario definir como se va a utilizar: como surface shader? atmosphere shader?

En mi caso, yo preferí light shader. De esta forma es sencillo utilizar el resultado, sumarlo a la iluminación actual y bakear de nuevo.

Primero, el render usando un ambient light con indirect diffuse en base al ptc se ve como en la imagen de la derecha.

En esta imagen, tenemos la parte de luz indirecta, pero abajo de la esfera hay una "fuga", probablemente porque en el shader de esfera y caja no tengo occlusion. Al no considerarse al momento de escribir el ptc, el calculo de gi bla bla... en fin, la imagen se ve bien, pero tiene un no se que que me ladra. Le falta "textura de occlusion indirecta" ;)

Para no modificar mis luces ni shaders, puedo bakear esta solución y re-renderear. Para esto, se usa el render pass donde tenemos los atributos de "dicing", "backface culling" y "hidden" en 0.

También asignamos de nuevo el atmosphere shader que escribe el archivo. Obviamente usamos un nuevo nombre para escribir el ptc, de lo contrario, el shader asignado al ambient light (que calcula gi) tratara de leer de un archivo que esta siendo abierto para escribir lo que esta leyendo.

Una vez listo, desconectamos el atmosphere shader y leemos en el ambien light el ptc recien escrito.

El render ya incluye un rebote de luz mas (secondary diffuse bounces).

El proceso se puede convertir en: aplique, enjuague, repita.
Y depende del look que se este buscando, pero por ahi del 4o rebote ya no es significativo el cambio (al menos en este ejemplo).

Finalmente, esta es la imagen y ptc del 4o rebote. El shading rate es de 1, con una resolucion de 640x480. El render time es de 77 segundos. Ahora, el reto es probar el mismo workflow con una secuencia, donde intervenga subdivs, motion blur y tal vez mas elementos.

Pueden encontrar el código y explicación aqui:
http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=1365

/sbin/init 6

Please stand by while rebooting the system...

SCARRED

Hi, I'm jc and this is my scarred story...

Bueno, esto es 8 dias después de la extracción. La herida no es tan pequeña como se hubiera esperado, pero con un poco de baba de caracol todo se soluciona. La hinchazón todavia es notoria, pero según el médico, es normal. Al parecer el higroma se había extendido un poco.

Aún existe un 5% de probabilidades de reincidencia ^_^

cel shading

3delight permite renderear outlines de cualquier variable, que es muy util cuando se esta trabajando toon rendering o ilustración. Esta opción esta disponible en "Secondary displays", en el checkbox "Edge detection" y pueden utilizarse mas de una variable en el mismo AOV (separados por comas: Ci,Oi,z).

Una vez que se habilita esa salida, es necesario definir un "secondary display" (en Add) y definir un path para la imagen y un nombre de variable de salida. Por default, el edge detection se realiza sobre Ci (que es el color de la superficie) y se basa en la iluminación que tenemos en la escena. Es decir, si tenemos un point light, el edge detection se basa en las zonas iluminadas por el point light (y el shader que por default es un lambert). Para obtener una salida independiente, podemos definir que la variable a detectar sea diferente a Ci (puede ser P, Oi, z, N) y que el "Display AOV" sea un componente que este presente en el calculo pero que no tenga ningun valor (en mi caso, estoy usando specular para obtener N en fondo negro). Si se utiliza el default, se considera rgba (el resultado del edge detect se suma a rgba).

Utilizando estas salidas, una pasada de normales y nuke, podemos convertir un aburrido espacio inutilizado en un refrescante espacio de expresión artística!

sprites & opacityPP - secuencia

Esta es la secuencia de los sprites. La mitad del cuadro es del blast. Como pueden ver, el exporter de 3delight no soporta aun el "camera shake" ;)

El render tomo cerca de 70 horas. Tenemos 1600 archivos de la simulación de Maya con un warp a 300 frames (para tener motion blur con un multiples exposiciones, que en el video de youtube no van a poder observar), dof, mb y un shading rate muy bajo (creo que lo ideal es renderear los sprites en una capa con un shading rate alto) y algunas pasadas.

Hay un pop como a la mitad del video. No he revisado los renders de pasadas, pero creo que es el diffuse cuando hay cambio en el ángulo entre el sprite, el spotLight y la camara.