- RenderFormer é um pipeline de renderização neural que implementa diretamente até os efeitos de iluminação global em cenas baseadas em malhas triangulares
- Não exige treinamento separado nem ajuste fino para cada cena
- Define a renderização como uma transformação sequência-para-sequência, convertendo diretamente tokens de triângulos em tokens de patches de pixels
- Todo o pipeline é projetado com base em transformers, aplicando apenas o mínimo de restrições prévias
- Gera imagens sem usar rasterização nem ray tracing
Introdução
- O RenderFormer é um pipeline neural que renderiza imagens diretamente a partir de uma representação de cena baseada em triângulos
- Produz imagens com efeitos de iluminação global totalmente aplicados
- Funciona com uma estrutura que não requer treinamento nem fine-tuning separado para cada cena
Abordagem
- Diferentemente das abordagens tradicionais de renderização fisicamente baseada, redefine a renderização como um problema de transformação sequência-para-sequência
- Converte uma sequência de tokens contendo triângulos e características de reflexão em uma sequência de tokens de saída, cada um transformado em pequenos patches de pixels
Estrutura do pipeline
- O RenderFormer é composto por uma estrutura em duas etapas
- Etapa independente da visão: modela o fenômeno de transporte de iluminação entre triângulos
- Etapa dependente da visão: converte tokens que representam feixes de raios em valores de pixel. Nessa etapa, a sequência de triângulos da fase anterior atua como guia
- Ambas as etapas são baseadas em uma arquitetura transformer
- O treinamento aplica apenas restrições prévias mínimas
Características técnicas
- Durante a renderização, não usa de forma alguma métodos tradicionais como rasterização ou ray tracing
- Explora ativamente a capacidade de transformação de sequências dos transformers
Conclusão
- Em comparação com as técnicas existentes de renderização neural, é uma abordagem que gera imagens flexíveis e de alta qualidade sem exigir preparação prévia adicional nem ajustes por cena
1 comentários
Comentários do Hacker News
O ponto mais impressionante é a velocidade. Na mesma cena, o RenderFormer termina em 0,076 s, enquanto o Blender Cycles leva 3,97 s (ou 12,05 s em configurações mais altas). Ainda assim, o índice de similaridade estrutural (SSIM) é 0,9526, então a diferença é quase imperceptível. Recomendo ver as tabelas 2 e 1 do artigo. Na prática, isso significa que designers 3D poderiam ver prévias de renderização instantâneas com qualidade muito mais alta em modelos transformer rodando on-device na web ou em apps nativos. Claro, esses resultados foram medidos em uma GPU A100 sem otimizações de PyTorch, então GPUs de usuários comuns não devem atingir essa mesma velocidade, mas ainda assim dá para esperar um ganho de desempenho suficiente em relação ao rendering tradicional. Ou, em um sistema web, também seria possível conectar ao backend com A100 e fazer streaming das imagens renderizadas para o navegador. As limitações, porém, também são claras. À medida que a cena fica mais complexa, a precisão cai, e especialmente em sombras complexas (incluindo partículas ou cabelo) a chance de erro é alta, então o render final ainda precisaria ser feito com métodos tradicionais para evitar artefatos comuns em imagens e vídeos baseados em IA. Mesmo assim, se o ganho de velocidade for grande o bastante, imagino que isso possa ser útil em grandes estúdios de animação que precisam de renders de prévia com duração de filme inteiro, para revisão de música ou da história, por exemplo
Não acho que os pesquisadores tenham distorcido os fatos de propósito, mas se o Blender Cycles estivesse usando uma GPU com esse nível de desempenho, ele renderizaria todas as cenas do artigo em menos de 4 segundos. As cenas usadas no artigo em si têm baixa complexidade, e o Blender foi configurado para fazer 4.000 amostragens por repetição, embora na prática ele chegue a uma qualidade quase final em algumas centenas, então o restante quase não faz diferença. No fim, isso só consome recursos de GPU sem necessidade. Além disso, parece que o processo inicial de preparação do render do Blender foi incluído no tempo de renderização, enquanto o tempo de inicialização do transformer foi excluído. Também tenho curiosidade sobre o tempo para renderizar o segundo frame em cada sistema. Meu palpite é que o Blender seria muito mais rápido. De qualquer forma, os resultados do artigo em si são interessantes, mas há nuances na comparação de configurações e tempos com o Blender
Pelas cenas mostradas, 76 ms na verdade parece até demorado. Claro, acho que isso vai ficar muito mais rápido no futuro, mas ainda é cedo para dizer que já é melhor do que rendering tradicional
A comparação de tempo no artigo é um pouco imprecisa. Em ray tracing, o erro diminui de acordo com a raiz quadrada do número de amostras. No artigo, foi usado um número de amostras irrealisticamente alto para gerar a imagem de referência, enquanto renderizadores offline reais usam de 10 a 100 vezes menos amostras. Imagens feitas com tantas amostras como no artigo servem para comparar qualidade, mas usá-las para comparar tempo não é algo comum. Como o resultado não é rigoroso, seria mais justo comparar com outros algoritmos de renderização que produzam aproximações semelhantes. Hoje em dia, combinações de path tracers em tempo real com denoisers também conseguem renderizar cenas muito mais complexas em menos de 16 ms em GPUs de consumidor. Em especial, modelos transformer gastam tempo proporcional ao quadrado tanto do número de triângulos quanto do número de pixels. Talvez haja melhorias em pesquisas mais recentes de machine learning, mas será difícil superar o escalonamento O(log n triangles), O(n pixels) de um path tracer tradicional (na prática, ele é ainda menos sensível ao aumento de pixels graças à coerência entre pixels adjacentes)
Fiquei surpreso com a reação à alegação de velocidade. Dei uma olhada rápida no artigo e não consegui confirmar se o Blender Cycles usou a CPU da A100 ou kernels CUDA. Se foi um único frame, parte do tempo de inicialização do renderizador pode ter sido incluída. Se foi renderização em sequência, o tempo por frame cai bastante. E a complexidade em número de triângulos que outra pessoa mencionou (escalonamento O(n^2)) certamente também deve influenciar
O artigo afirma que "a complexidade de runtime da camada de Attention aumenta quadraticamente com o número de tokens, ou seja, neste caso, o número de triângulos. Por isso, limitamos o número de triângulos na cena a no máximo 4096"
Deep learning também vem sendo usado com muito sucesso para denoise (remoção de ruído) em imagens renderizadas com global illumination. A abordagem é gerar uma imagem bruta de global illumination com ray tracing tradicional e deixar a rede neural remover o ruído da imagem final. Link relacionado: Open Image Denoise
Tenho um amigo que realmente desenvolve renderizadores fisicamente baseados para a indústria do cinema, e sempre acho interessante ouvir como esse setor trabalha e as histórias da área. Fico curioso para saber quais empresas estão contratando gente assim hoje em dia. Também queria saber se empresas de IA contratam engenheiros de rendering para construir ambientes de treinamento. Se alguém estiver querendo contratar um engenheiro experiente de pesquisa/indústria em rendering, posso fazer a ponte, já que meu amigo não usa redes sociais
Achei curioso que nenhum dos exemplos mostre objetos atrás da câmera. Não sei se isso é uma limitação desses exemplos específicos ou da abordagem em si, mas, ao considerar reflexos e iluminação, o que está atrás da câmera é um fator muito importante
Mais um momento em que "the bitter lesson" se faz sentir. Agora essa tendência também está chegando ao campo de graphics rendering. O NeRF usava parcialmente priors baseados em ray tracing, e o Gaussian splat usava priors baseados em rasterização, mas essa abordagem tenta resolver tudo jogando fora esses priors de domínio e esse conhecimento especializado, usando apenas dados e attention. Dá a sensação de que esse é o futuro
É impressionante que agora exista uma estrutura circular entre rendering e compute centrada na GPU
O resultado até é bom, mas parece um pouco borrado. Eu gostaria de ver mais comparações de tempo de render entre redes neurais e renderizadores clássicos
Nas animações (especialmente Animated Crab e Robot Animation), há artefatos bem típicos de arte por IA: um efeito de redemoinho artificial em volta do modelo quando o objeto ou a câmera se movem
Há alguma discussão sobre comparação de tempo no artigo. Em comparação com o Blender Cycles (path tracing), a abordagem neural é muito mais rápida, pelo menos em cenas com até 4K triângulos. Mas pode não se adequar bem a cenas mais complexas do que isso (já que o runtime da attention cresce com o quadrado do número de triângulos). Link do artigo: PDF do artigo RenderFormer. Na minha opinião, uma abordagem prática pode ser usar o método neural só para iluminação indireta, gerar a imagem base com um rasterizador tradicional e aplicar apenas o Global Illumination de forma neural por cima
Talvez eu não esteja entendendo bem, mas se essas cenas acabam sendo renderizadas mais ou menos da forma esperada, por que essa abordagem tem vantagem sobre métodos diretos mais simples? (Se nem for mais rápida, fico me perguntando por que usá-la)
Na verdade, esse método talvez possa gerar efeitos mais interessantes do que parece à primeira vista. Por exemplo, dá para tratar a cena como um único bloco de pesos de entrada, adicionar ruído a ela ou interpolar (misturar) cenas diferentes para obter resultados inesperados
No fim das contas, acho que isso está mais para "Cool Research". A utilidade prática é baixa, porque o custo cresce quadraticamente conforme aumenta o número de triângulos. Por isso o artigo limita cada cena a 4096
Como outro comentário já mencionou, esse método realmente é mais rápido. Global illumination é extremamente lento por métodos diretos
Parece uma pesquisa inovadora. Como transformers podem ser aplicados não apenas a linguagem natural, mas a vários domínios com entradas contínuas e correlações entre tokens, fico curioso para ver mais pesquisa no futuro aplicando isso a domínios não textuais. Quais domínios não textuais os usuários do Hacker News acham mais interessantes e adequados para transformers?
Acho uma ideia extremamente inteligente e interessante. Treinar um transformer para converter uma descrição de cena baseada em um conjunto de triângulos em uma matriz 2D de pixels, produzindo instantaneamente uma imagem quase igual à saída de um renderizador clássico de global illumination. Depois de ver as pesquisas dos últimos 5 anos, talvez a gente nem devesse mais se surpreender que isso seja possível, mas ainda assim continua sendo muito impressionante. Dá para sentir como a arquitetura transformer é versátil. A velocidade também é absurda, a saída é quase igual à do Blender, o modelo tem cerca de 1B de parâmetros e o arquivo tem 2 GB, embora eu não tenha certeza se é fp16 ou 32. Eu gostaria de ver demos com cenas mais realistas, mas também gosto do fato de poder baixar e testar isso no meu Mac agora mesmo