Monday, May 18, 2009

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 ;)

Friday, May 15, 2009

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

Wednesday, May 13, 2009

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

Wednesday, May 6, 2009

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.