gustavobraga.com

Uma semana em Boston, imerso na feira: A Siggraph deste ano trouxe boas novidades para usuários do RenderMan.
A Nvidia mostrou o Gelato 2, uma versão que tem uma integração muito boa com o Maya. A utilização das placas gráficas no auxílio do render parece ser uma tendência que chegou para ficar e diversos efeitos podem ser ajustados quase que em “real time” justamente devido ao fato do Gelato tomar proveito da velocidade de cálculo das últimas placas Quadro da Nvidia. A versão básica do Gelato está disponível para download gratuito no site da Nvidia.
Já no stand da Pixar ocorreram as demonstrações das versões alpha do RenderMan Studio 1.0, com o novo Slim e do RenderMan for Maya 2.0. A Pixar promete o lançamento destas novas versões até o final do ano. O RenderMan Studio é a nova versão do RenderManProServer/RAT. A mudança significativa é que o RenderMan Studio é montado sobre a base criada para o RenderMan for Maya. Desta maneira, foi decretada a morte do MTOR e o Slim passa a ser apenas uma ferramenta para criação de shaders. A partir desta versão você vai criar o shader no Slim e através de um simples clique exportá-lo para o Maya; depois no Hypershade, fazer o assign deste shader para as superfícies.
A grande novidade para os usuários de RenderMan for Maya é que a versão 2 vai ser “multithread”. Além disto teremos novos algoritmos para o cálculo de occlusion (sem precisarmos de raytracing) e caustics incorporada ao software. Me pareceu que o RenderMan for Maya 2 ainda não tem todas as suas novas features definidas, que dependerão muito do que for pedido durante a fase beta do produto.
Não posso deixar de mencionar as duas apresentações que fiz no stand da pixar falando sobre como utilizamos o RenderMan for Maya na produção da série de comerciais dos Limões da Pepsi. Comentei como foi a nossa transição de Maya Software/Mental Ray para RenderMan for Maya, o que melhorou e como nosso pipeline foi modificado.
Também tivemos o encontro de usuários do RenderMan. Onde a equipe da Pixar comentou o ano passado e mostrou o road map dos produtos para os próximos anos. E para terminar a noite, as já conhecidas Stupid Rat Tricks.

Ao escrever um shader que precisava da leitura de algumas texturas. Percebi a quantidade de pequenas coisas que temos de lembrar quando utilizamos arquivos de textura em nossos shaders. Resolvi então colocar estas pequenas coisas neste artigo.
Abaixo está o primeiro shader, ele recebe como parâmetro o nome de um arquivo de textura e o aplica a uma superfície.

Na linha 6, a variável Ct recebe a cor da textura. Isto é feito através da função texture que tem neste exemplo os parâmetros: o nome da textura (texturename), as coordenadas do ponto (s e t), o parametro extra “fill” e o seu valor 1.
A primeira observação é que a função texture pode retornar valores dos tipos float ou color, então temos sempre que utilizar um “cast” para definirmos que tipo de valor de retorno queremos. Se o tipo for color, por default, ela retorna os canais de índices 0,1 e 2 que correspondem à cor. Já se o “cast” for float, devemos especificar qual canal queremos. Normalmente utilizamos o float para lermos o alpha da imagem, o canal de índice 3.
O parâmetro extra “fill” é utilizado para ajustar um valor de retorno para situações em que a função texture não retorna um valor válido. Como por exemplo quando buscamos a informação de alpha de uma imagem que não contém alpha.
Existem diversos parâmetros extras e formas de chamar a função texture; para mais informações consulte a documentação do RenderMan.
Depois de compilarmos o shader e carregá-lo no Maya, para testá-lo precisamos de uma imagem. O RenderMan não manuseia arquivos de imagem comums (tiff, jpg, iff) mas um formato proprietário (normalmente estes arquivos são nomeados com o sufixo .tex). Então precisamos converter a imagem para este formato .tex utilizando o aplicativo txmake (ele é instalado automaticamente tanto no RAT como no RfM).

Para os próximos exemplos utilizaremos uma imagem chamada de textura1.tif que está gravada no diretório c:\temp.
Para convertê-la em .tex executamos o seguinte comando:

C:\temp> txmake textura1.tif textura1.tex


No Maya podemos incluir no atributo texturename a localização do arquivo de textura, veja na figura ao lado o attribute editor do primeiro shader. Repare que colocamos o caminho para o arquivo com barras invertidas como se fosse um sistema unix. Mesmo que exista espaços em branco no nome dos diretórios, não precisamos colocar o path entre aspas.
Nas figuras abaixo temos três renders diferentes. À esquerda o RenderMan Shader filemapping1.slo aplicado ao plano e processado pelo RfM. No meio, um surfaceShader/file texture do Maya aplicado ao plano e processado pelo RfM. Na esquerda, com um surfaceShader/file texture do Maya aplicado ao plano e processado pelo render do Maya. Modifiquei o background para cinza para melhor visualização.

A tradução feita pelo RfM dos shaders do Maya é correta e idêntica ao render do Maya; já a interpretação feita pelo RfM do nosso primeiro shader é diferente em dois pontos: a textura não foi esticada e esta invertida na vertical.
Na verdade, a maneira como o txmake traduz a imagem para um arquivo de textura é que vai determinar como será aplicada a textura na superfície. Para que tenhamos a conversão idêntica no RfM da maneira como o Maya trabalha, a sintaxe correta do txmake é:
C:\temp> txmake –mode periodic –resize up- arqEntrada arqSaida
O parâmetro –mode periodic ajusta a textura para fazer a sua repetição para cada valor de s e t fora da faixa de 0 a 1. Já o parâmetro -resize up- faz com que a textura seja escalada para que cubra a superfície inteira.
Aplicando isso ao exemplo, criamos um novo arquivo de textura:
C:\temp> txmake –mode periodic –resize up- textura1.tif textura2.tex

Ao lado está o render já com a textura2.tex aplicada ao plano. Ainda temos o problema da textura estar invertida em t. Isso ocorre porque a maneira como o RenderMan e o Maya interpretam a superfície para fazer a colocação da textura é diferente. Quando o RfM traduz um shader do Maya, ele faz a conversão, o mesmo já não acontece nos shaders escritos em RSL. Para termos o mesmo comportamento precisamos inverter o valor em t. Veja a sexta linha do shader filemapping2.sl no lugar de t, agora temos (1-t).

Após compilarmos, carregarmos no Maya e ajustarmos o atributo texturename para o arquivo textura2.tex, temos o resultado a imagem ao lado:
Se você pretende que os shaders possam ser utilizados tanto no RAT como no RfM, é necessário colocar uma variável que indique como t vai ser interpretado. No shader abaixo criamos o parâmetro isRfM, caso seu valor seja 1, temos t sendo interpretado de forma invertida (padrão RfM), para qualquer outro valor utilizamos t sem a inversão (padrão RAT).

Como mencionado anteriormente, podemos também acessar a máscara da imagem. É imprescindível se desejarmos aplicar texturas como decalques em superfícies. O próximo shader leva em consideração a máscara da textura para definir a opacidade da superfície.

Usando o shader filemapping4.slo temos a imagem à esquerda. Agora a parte visivel do plano é apenas aquela contida na máscara da imagem.
Na linhas 16 e 17 temos:

opacity= float texture(texturename[3],s,tt);
Ct= color texture(texturename,s,tt,"fill",1);

Na linha 16, a variável opacity recebe o valor da máscara. Reparem nas diferenças em relação a chamada da função texture na linha 17. Primeiro, o “cast” float e depois a referência ao canal [3] em texturename.
Repare que a maneira como escolhemos os canais se parece com a que utilizamos nos arrays. Isto acontece porque esta chamada aos canais de textura foi implementada quando a linguagem ainda não suportava arrays. Quando arrays foram adicionados criou-se uma pequena confusão. O compilador consegue distinguir muito bem o que queremos fazer a não ser quando temos um array de strings com nomes de arquivos e queremos utilizar este array na função texture. Temos então, que usar parenteses como separadores. Veja o exemplo abaixo:

string files[5];
Ci = float texture ((files[i])[3], s, t);

No próximo e último shader temos uma variação em relação ao anterior. Agora utilizamos o parâmetro surfacecolor para controlar a cor da superfície. A textura dada em texturename é aplicada como se fosse um decalque sobre a superficie, utilizando a máscara aplicamos somente a parte válida da imagem respeitando as transparências.

A imagem ao lado é o resultado do shader filemapping5.slo com o atributo surfacecolor ajustado para azul.
Estes exemplos são apenas uma introdução sobre o que se pode fazer na manipulação de texturas. Como exercício podemos pensar no que seria um próximo passo. Que tal criarmos um shader que sobreponha diversos layers de imagens, utilizando diversos esquemas de sobreposição (Add, Multiply, etc)? Ou ainda um esquema de posicionamento das texturas de uma forma analoga ao nodo place2Dtexture do Maya? Agora é só programar…
O Arquivo com os shaders e texturas usadas neste artigo:fileMappingFiles.zip

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.

A Pixar acaba de lançar o RenderMan for Maya, um plug-in para utilizar o RenderMan integrado ao Maya.
Os primeiros testes, na Siggraph de 2004, me impressionaram de imediato. Fomos um dos primeiros a começar a testar a versão beta em maio deste ano. Logo percebemos que a Pixar tinha acertado em cheio.
O plug-in é muito fácil de usar, totalmente integrado ao Maya, é só trocar o render para RenderMan no Render Globals. Você continua fazendo os renders no Render View e montando os shaders da mesma forma no hypershade; para além disso, não há necessidade de aprendizagem de novos editores ou ferramentas.

Além de aceitar quase todos os nodos do hypershade você ainda pode programar um shader através de RSL. Dá para usar toda a biblioteca de shaders já existente para o RenderMan. Para quem tem o Slim é só compilar o shader e mandar para o RenderMan for Maya; a compatibilidade é total.
Com o RenderMan for Maya o artista tem em mãos um render muito robusto e que calcula global illumination, color bleeding e occlusion, além dos algoritmos patenteados pela pixar de deep shadows e motion blur.
Se você trabalha com superfícies Nurbs, pode esquecer os problemas de facetamento já que o RenderMan for Maya é um “true nurbs renderer”. Para os que preferem subdivision surfaces ele trabalha de uma forma bem mais rápida que o render nativo do Maya. Era de se esperar, visto que a Pixar foi a primeira empresa a implementar subdivision surfaces. Além disso, ele tem um gerenciamento de memória bem melhor do que outros renders, possibilitando o processamento de cenas muito mais pesadas.

Já estamos utilizando o plug-in em produção desde junho. Algumas cenas do filme “Chuva” da Claro, outras do filme do Tim Festival 2005 e a totalidade do filme “Vegetalização” da Natura (as figuras do post são dois momentos deste filme) foram processadas com este novo software.
Como participamos ativamente do processo de teste, uma das conversas que tive com o pessoal da Pixar, sobre as mudanças no nosso pipeline foi utilizada no press release de lançamento do plug-in.

O Ultraedit-32 é um ótimo editor de texto voltado para programadores. Além de ter todos os recursos básicos, ele possibilita ao usuário adicionar módulos de visualização para novas linguagens de programação. Como sempre o uso para escrever meus programas, resolvi montar um “RSL mode”. Agora o utilizo também para escrever meus shaders. O editor faz o highlight de todas as palavras reservadas, funções e variáveis pré-definidas do RenderMan(de uma olhada em um screenshot).
Se você tem o editor é só baixar o arquivo zipado do wordfile.txt e gravá-lo no diretório do Ultraedit (normalmente C:\Program Files\UltraEdit). Caso você já tenha modificado o wordfile.txt do seu Ultraedit é só copiar a linguagem 8 do meu wordfile.txt e adicioná-lo ao seu. A próxima vez que abrir o editor, você poderá escolher a opção RSL no menu View>View As(Highlighting File Type)>RSL.

Decidi começar o tópico RenderMan comentando sobre este livro que pode ser uma porta de entrada para aqueles que querem aprender um pouco sobre o assunto.
Atualmente, RenderMan significa duas coisas um pouco diferentes. A primeira é o nome dado ao padrão de comunicação (criado pela Pixar) entre um programa de modelagem e um programa de render, assim como postscript é um padrão entre um editor de texto e a impressora. Também é o nome do próprio software feito pela Pixar que implementa este padrão de comunicação. Na verdade, o termo correto do software é Photorealistic RenderMan ou PRMan, mas nos acostumamos a chamá-lo de RenderMan.
Falando um pouco do livro, como o título já deixa claro, ele é voltado para iniciantes. O começo é bom; os dois primeiros capítulos são usados para um breve introdução a alguns conceitos da computação gráfica 3D, histórico e estrutura básica de funcionamento do RenderMan. Mas a partir do terceiro capítulo, o livro enfoca em demasia a sintaxe de um arquivo RIB (arquivo que contém a descrição da cena) e acaba se tornando chato - a não ser que “o iniciante” queira escrever um plugin para exportar/importar arquivos RIB. O que atualmente já existe para a maioria dos softwares, deixando este tipo de informação sem muita importância.
No capítulo sobre RSL, onde o livro deveria dar mais ênfase, ele acaba sendo superficial. É a sua grande falha. O livro fica sendo um grande exemplo ilustrado do que se pode fazer em materia de shaders. Existe muito pouca discussão sobre como os shaders são montados. Excetuando-se o caso do Fresnel, apenas uma ou outra linha é comentada. Se o livro fosse mais didático e profundo o iniciante poderia ao terminá-lo começar a programar seus próprios shaders, coisa que não acontece.
De um modo geral, o livro é bem escrito e os exemplos são bons, mas se realmente você pretende aprender a escrever shaders em RSL, este livro não é uma boa escolha. Os arquivos dos exemplos mostrados estão no site da editora e podem ser baixados. Mas até nisso o autor peca, já que o site é uma bagunça.