gustavobraga.com

Uma das propriedades menos conhecidas do RenderMan for Maya é a possibilidade de ler arquivos .slim para montar a interface dos shaders escritos em RSL. Com estes arquivos podemos criar uma interface mais amigável para o usuário, controlar a entrada de dados e facilitar a utilização de imagens comuns como textura nos shaders.
Vamos utilizar o shader abaixo como exemplo.

Este shader é um dos exercícios propostos no post “Usando Texturas em RSL”. Ele tem como parâmetros surfacecolor (cor básica da superfície), texturename (nome do arquivo de textura a ser aplicado sobre a cor), useAlpha (usar alpha da imagem na sobreposição da textura na cor básica), mode (modo de aplicação da textura – over, add, subtract, multiply) e isRfm (inverte a coordenada t se o shader vai ser utilizado no RfM).
O shader recebe o nome de uma textura e a aplica sobre a cor básica da superfície da forma definida pelo atributo mode.
As possibilidades de valores para cada parâmetro são as seguintes:
sufacecolor = uma cor qualquer
texturename = uma string com um caminho para um arquivo .tex;
useAlpha = um número sendo: 0 – não usa o alpha da imagem, 1 – usa o alpha da imagem;
mode = um número sendo: 0 – over, 1 – add, 2 – subtract, 3 – multiply;
isRfm = um número sendo: 0 – RAT, 1 – RfM.
Após compilar o shader e carregá-lo no Maya, temos a seguinte interface:

Os parâmetros surfacecolor e texturename têm entradas condizentes com os seus tipos. O primeiro recebe uma cor e o segundo recebe uma string.
Já para os outros parâmetros que são definidos como float, sua utilização é confusa e não existe nenhum lugar para indicar que valores são corretos. Para useAlpha e isRfm, requer um valor 1 ou 0 de ligado/desligado. O atributo mode requer uma entrada com valores inteiros 0/1/2/3 para selecionarmos a opção de aplicação da textura. Para estes parâmetros o shader funcionaria muito melhor se pudéssemos colocar respectivamente uma “checkbox” e uma “optionbox”.
Quando o RfM carrega um RenderMan Shader, além do arquivo .slo ele procura por um arquivo .slim que será utilizado como guia para a criação da interface do shader. Caso ele não encontre este arquivo a interface é criada de um modo padrão para cada tipo de atributo. Como visto na primeira figura o modo padrão do RenderMan para este caso não é claro o suficiente.
Começamos utilizando o programa toslim para gerar um .slim padrão do shader em questão:
> toslim filemapping6.slo –o filemapping6.slim
Na figura abaixo temos ao lado do Attribute Editor a listagem do arquivo filemapping6.slim.

Para cada atributo do shader no Attribute Editor temos o correspondente bloco de código que define a interface à direita (o arquivo filemapping6.slim).
Modificamos então o filemapping6.slim nos parâmetros texturename, useAlpha, mode e isRfm, adicionando onde se fez necessário as opções subtype e range. Na figura abaixo temos novamente a interface lado a lado com o arquivo de configuração. As mudanças estão a vermelho.

Note que modifiquei o nome (label) de cada atributo. Neste exemplo, os nomes dos atributos não são simplesmente os nomes dos parâmetros, mas nomes mais significativos e com espaços entre as palavras. Os atributos useAlpha e isRfM agora têm uma checkbox para podermos ligar ou desligar (1 ou 0) a opção. O atributo mode (Blending Mode na interface) agora é uma optionbox com as opções referentes a cada um dos modos de aplicação. E o atributo texturename ganhou uma opção para mapear um passe de txmake para a criação da textura.
No filemapping6.slim, além de alterar os labels, cheguei a esta nova interface apenas adicionando aos atributos, as opções subtype e range que servem, respectivamente, para escolher o tipo de elemento de interface e a sua faixa de valores.
No subtipo switch escolhemos os valores 0 e 1 (range {0 1}), sendo o primeiro para desligado e o segundo para ligado. Já para o subtipo selector (atributo mode), na definição da faixa de valores, temos primeiro o texto que aparecerá na caixa de seleção e depois o seu respectivo valor (range {over 0 add 1 subtract 2 multiply 3}).
De todas estas opções, a mais interessante é quando adicionamos o subtype “texture” ao atributo texturename. Fazendo isto cria-se a possibilidade de mapear um passe de txmake ao atributo. Desta forma não é necessário converter a textura em um arquivo .tex para poder utilizá-la no RfM. Podemos carregar um arquivo de imagem qualquer e a conversão é automaticamente feita pelo txmake antes do render. Veja na figura abaixo o Attribute Editor do txmake com as opções de conversão. Repare que para termos a texturização no “padrão Maya” utilizamos os dois wraps como “periodic” e o resize mode como “up-“.

A partir de agora, quando criar shaders em RSL lembre-se que você pode construir uma interface e controlar/facilitar a entrada de dados do usuário usando arquivos “.slim”.
Arquivo zip com o shader e slim files mostrados no post: slimFiles.zip
Outros exemplos de utilização de arquivos .slim podem ser vistos em:
http://www.fundza.com/rman_slim/slim_file/slimfile_quickref.html

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.

Nas próximas terça e quarta-feira, dias 1 e 2 de agosto, às 16:00h os limões da Pepsi Twist estarão no estande da Pixar, na Siggraph (congresso mundial de computação gráfica) em Boston, EUA. Se você está pensando em ir ao congresso e quiser saber como o RenderMan for Maya ajudou na produção dos filmes da Pepsi Twist venha assistir à apresentação que farei sobre a campanha publicitária.

Quando o RfM processa uma cena ele começa transformando as imagens que vão ser usadas como texturas em arquivos “.tex” e convertendo os shaders da cena para arquivos “.slo”. Estes arquivos são usados logo após quando o processo de render começa.
Mas existe um problema que passa desapercebido à maioria dos usuários: o acesso concorrente de diversas máquinas (ou processos) a estes arquivos. Por exemplo, quando mandamos uma cena para ser processada numa render farm, a primeira máquina começa o processo de conversão de texturas e shaders, terminado este processo, inicia-se o render. Uma outra máquina começa um pouco depois e inicia o seu processo também com a conversão dos arquivos. Digamos que durante esta conversão de arquivos da segunda máquina, a primeira precisa ler uma das texturas que está sendo convertida naquele instante. O que acontece? Um erro de leitura de textura que acaba acarretando um erro na execução do shader e a superfície é renderizada incorretamente.
A primeira saída para este problema é guardarmos estes arquivos temporários no disco local de cada máquina pertencente a render farm. Desta maneira, cada máquina teria os seus arquivos e não haveria um acesso concorrente. Mas o que fazer se lançarmos dois ou mais processos de render em uma única máquina? Teremos estes processos novamente acessando os mesmos arquivos quase ao mesmo tempo e o problema poderia vir a acontecer novamente.
Para resolver este problema temos que nos certificar que cada processo de render terá um diretório exclusivo para guardar os seus dados. Fazemos isso abrindo o Render Globals na Aba Advanced, na Divisão Output Directories e ajustando os atributos para:
Texture Cache: renderman/${SCENE}/$env(COMPUTERNAME)/${JOBID}/textures
Shaders: renderman/${SCENE}/$env(COMPUTERNAME)/${JOBID}/shaders
Render Data: renderman/${SCENE}/$env(COMPUTERNAME)/${JOBID}/data
Temos então que estes dados serão guardados em uma árvore de diretórios dentro do projeto em renderman/nome da cena/nome do computador/número do processo de render. Como não podem existir duas máquinas com o mesmo nome na rede e não temos dois processos com a mesma identificação em cada máquina todos os processos terão um endereço exclusivo para guardar seus dados.

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

Uma ótima notícia para quem deseja aprender RenderMan for Maya: a Pixar acaba de disponibilizar para download uma versão de aprendizado chamada EVAL. É gratuita e não precisa de licença para rodar o software. A única diferença entre o RfM e o RfM EVAL é que todas as imagens geradas pelo segundo tem uma marca d’agua.
Segue o endereço para fazer o download:
https://renderman.pixar.com/products/tools/rfm_splash.html

Há uma semana, a Pixar lançou o RenderMan for Maya 1.2. É a segunda versão para correção de bugs poucos meses depois do lançamento do programa, o que demonstra um grande comprometimento deles com o software e com os seus clientes.
As principais melhorias em relação a versão 1.1 do RfM, na minha opinião, são:

• Dois novos tipos de outputs: diffuse_noshadow e surfacecolor. Os outputs agora são pré multiplicados pela opacidade;
• Os nodos useBackground e +/- agora são totalmente suportados;
• Hair e fur suportam global illumination;
• RfM agora pode acessar mais memória se o windows XP estiver ajustado com a /3GB set no boot.ini.

Não foi à toa que coloquei os novos tipos de outputs como o primeiro item da lista; a discussão sobre eles começou neste site (veja o post “Bug ou feature?”). Depois de abrir um tópico no fórum da Pixar, começamos uma calorosa discussão sobre como deveriam ser os outputs e agora temos como resposta da Pixar estas melhorias: o canal de diffuse sem sombra e sem cor e um canal somente com a cor.
Os principais bugs que foram consertados:

• “Bad Nesting Error” crash relacionado ao tipo Catmull-Clark de subdivision surface;
• Settings de reflexões são devidamente respeitadas no paint effects;
• Imagens para mapas de atributos do fur podem ser de qualquer tipo, não somente maya iff;
• Ramps com os valores das cores animados agora são interpretados corretamente;
• Suporte para animação em motion paths;
• Bug onde os nodos File conectados a luzes não eram convertidas;
• Bug relacionado ao nodo samplerInfo não funcionando em displacements;
• Bug onde as reflexões e refrações do fur não pareciam corretas.

Mas nem tudo neste release é boa notícia. Infelizmente, um grave bug com Area Lights causando pixels brancos nas imagens ainda não foi totalmente solucionado. No release de lançamento da versão 1.1, a Pixar já dava este bug como consertado, mas ele ainda estava lá. Agora no 1.2, ela novamente dá como bug consertado, mas ele ainda está lá.

No RenderMan for Maya é possivel ajustar atributos do RenderMan por superfície e por grupo de superfícies. Isso gera a possibilidade de ter o valor dos atributos (shading rate, subdivision scheme, shadow type, etc.) variável conforme as necessidades das superfícies.
Por exemplo, imaginemos uma cena em que tenhamos uma chuva de esferas. Podemos ter para a cena o valor do shading rate em 1; para as esferas em primeiro plano, um valor menor (0.5) para terem mais qualidade; já as esferas que caem no background, que não precisam ter tanta qualidade, podem ter um valor maior (5). Deste modo, otimizando a cena, há um ganho de desempenho.
Para adicionar atributos em apenas uma superfície abra o Attribute editor da mesma e adicione o atributo desejado através da janela Add/Remove Attributes… (Attributes > RenderMan > Manage Attributes…).
Para adicionar atributos a um grupo de superfícies temos que ligar um nodo de settings a elas. Para a criação de um nodo de settings, abra o RenderMan Shared Geometric Attr Nodes (Rendering Editors > RenderMan > Shared Geometric Attributes) e clique no botão create. Nesta janela, você controla todos os nodos de settings.
O nodo é criado sem nenhum atributo; você terá que adicioná-lo e pode fazê-lo da mesma forma que nas superfícies (através do Attributes > RenderMan > Manage Attributes…). Feito isso, é só selecionar todas as superfícies que você pretende que tenham o mesmo setting (com o nodo selecionado na janela RenderMan Shared Geometric Attr Nodes) e clicar no botão Attach. Para ter certeza que a superfície está conectada ao nodo de setting, abra o seu Attribute Editor; uma das abas deve ser a do nodo de setting.
É possível criar e apagar novos nodos, conectá-los e desconectá-los a superfícies, editar seus valores e selecionar os objetos a que estão ligados através da janela RenderMan Shared Geometric Attr Nodes.
Através da utilização do nodo de setting, com apenas uma mudança no valor do atributo do nodo, todas as superfícies ligadas a ele refletirão a mudança.

A equipe do site Digital Tutors está vendendo um dvd de introdução ao RenderMan for Maya - Introduction to RenderMan for Maya - com 3 horas de duração. Ainda não tive a oportunidade de ver, mas parece ser uma boa aquisição para aqueles que estão começando a desvendar o software.
Mais informações no link:
http://www.digitaltutors.com/store/product.php?productid=1027

Aqueles que já o adquiriram e quiserem colaborar, deixem seus comentários sobre o conteúdo.

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