Archive for January, 2006

Bug ou feature??

Alguns dias atrás recebi um e-mail de um estudante de animação da Ringling School of Art and Design (Kristafer Vale) me perguntando como conseguir a mesma funcionalidade do Use Background no RenderMan for Maya. Sugeri a utilização do Secondary Outputs; desta forma ele teria o canal de sombra separado. Para minha surpresa, ele falou que a imagem do diffuse output estava vindo com sombra. Resolvi fazer um pequeno teste e ele estava correto. Entrei no forum da Pixar e comentei o caso, logo me responderam explicando como o calculo é feito e que é normal ter a sombra no canal diffuse. A partir deste ponto criou-se um impasse e após alguns posts de outros usuários e meus o pessoal da Pixar resolveu abrir um chamado de bug.
Veja as imagens abaixo:

A primeira (da esquerda para direita) é o frame final, a segunda é o diffuse output, a terceira é o shadow output e a quarta é o que acho que deveria ser o diffuse output. A minha opinião é que os secondary outputs deveriam funcionar de uma forma que se juntarmos todos os outputs teríamos a imagem final e que cada informação deve estar separada em seu próprio output e somente nele. Desta forma podemos controlar cada passe de uma maneira melhor.
Se você quiser acompanhar a discussão, abaixo estão os dois tópicos abertos no fórum da Pixar:
https://renderman.pixar.com/forum/showthread.php?s=&threadid=4770
https://renderman.pixar.com/forum/showthread.php?s=&threadid=4804

Comments (2)

Filme Pepsi Twist - Peitos

Na seqüência dos últimos dois filmes de Pepsi Twistão, voltamos para a Pepsi Twist com seu novo filme de Verão. E os nossos limões estão com a corda toda! Depois de um dia de praia, nada melhor do que uma Pepsi Twist gelada; é assim que começa… Mas por mais incrível que pareça, o limão magro está carente e sentindo falta de uma “limôazinha” para dividir a sua Pepsi Twist. Antes mesmo de começar a gozação – sempre presente no espírito dos nossos mascotes - os dois são surpreendidos com a chegada de uma garota com um biquíni cheio de “limôas”. O limão magro, agora animado, tenta mostrar ao gordo como se dá uma cantada. Mas quem se dá bem é o limão gordo que acaba sendo levado pela garota junto com a lata do refrigerante.

As novidades técnicas deste filme são: mudança nos shaders dos limões e das gotas e a melhora no passe de occlusion que agora leva em consideração os displacements.
Com este filme conseguimos terminar a migração para o RenderMan for Maya e todos os renders foram feitos nele.

Algums frames:

Comments

Occlusion no RenderMan

Há alguns dias, li o ‘Application Note #35’ do RAT sobre Ambient Occlusion, ImageBased Ilumination e Global Illumination; acabei fazendo alguns testes e resolvi colocar aqui um resumo do que li e testei.
O que chamamos de occlusion é uma aproximação do cálculo de uma sombra de contato difusa. Ele é feito através do cálculo por ponto de quanto do hemisfério acima é coberto por outros objetos.
No RenderMan podemos calcular o occlusion de duas formas: utilizando um “gather loop” ou a função pré-definida “occlusion”.
O primeiro shader, occlgather.sl, utiliza um “gather loop”. Para cada shading point ele projeta raios (quantidade especificada no atributo samples) em direções randomicas no hemisfério. Para cada raio que acerta um objeto, a variável hits é incrementada. Depois do looping, o occlusion é computado dividindo o número de hits pelos samples. Quanto mais raios (samples), mais qualidade (menos ruído), mas o cálculo acaba sendo mais demorado.
Normalmente, a sombra de contato varia muito pouco em posições distantes de outros objetos. Nestas posições, o cálculo em cada shading point acaba sendo um grande desperdício. Neste caso, a forma mais eficiente de fazer o cálculo, é simplesmente calcular nos cantos do micropolígono e fazer a interpolação nos outros shading points. É neste conceito que se baseia a função occlusion.
O segundo shader, occlfunction.sl, utiliza a função occlusion. Neste, através do atributo maxvariation controla-se o tradeoff entre qualidade e velocidade no cálculo. Quanto maior for o valor de maxvariation, mais interpolação vai ocorrer e mais rápido será o render. Se maxvariation for 0, o cálculo é feito em cada shading point sem nenhuma interpolação, como se fosse um “gather loop”. Com valores maiores que 0 a interpolação é realizada. Valores entre 1 e 10 são comumente utilizados para rápidos previews (quanto maior o valor, maior a probabilidade de “flickering”); já para renders finais, os valores ficam entre 0.01 e 0.1.
Esta função, além de receber como parâmetros o ponto (P), sua normal na superfície (Ns) e o número de raios a serem emitidos (samples), também recebe duplas de parâmetros opcionais, como por exemplo, o maxvariation e o seu respectivo valor. Utilizando estes parâmetros conseguimos especializar e otimizar ainda mais o cálculo do occlusion.
Além do maxvariation, existem aproximadamente outros vinte parâmetros, dentre eles, vale a pena citar:
- maxdist: distância em que um ponto pode causar occlusion; quanto menor o valor mais local o efeito;
- coneangle: ângulo do hemisfério acima do ponto a ser considerado; o default é de 180 graus (pi/2). Quanto menor o ângulo mais “duro” é o efeito. Na Env Light do RfM coneangle é chamado de Diffuse Softness sendo o valor de 1 igual a 180 graus.
- hitmode: determina se a transparência deve ser levada em consideração para cálculo de occlusion. Para objetos transparentes use hitmode com o valor “shader”.

Este ajuste pode ser feito tanto no shader ou localmente por superfície. No RfM, se estivermos usando uma Env Light só podemos fazer este ajuste por superfície. Para isto basta selecionar a superfície, adicionar o atributo do Renderman “Diffuse Ray Shading” e ajustar o seu valor para “shader”. A figura ao lado ilustra o resultado com o hitmode em “default” e em “shader”.

Abaixo estão três imagens para comparação de qualidade e tempo, feitas com os dois shaders de occlusion.

Comments