Como muitos programadores, minha primeira exposição ao traçado de raios estava em meu venerável Commodore Amiga. É uma demonstração icônica do sistema que todo usuário do Amiga já viu em algum momento: veja o robô fazendo malabarismos com esferas de prata!
Assim começa o artigo da AmigaWorld de maio/junho de 1987, no qual Eric Graham explica como o Juggler foi criado. O programa (“com interface Intuition completa”) prometido no final do artigo era Sculpt 3D para o Amiga, lançado no outono de 1987. A Byte by Byte vendeu variantes do Sculpt para Amiga e depois para Macintosh e Windows por mais de uma década.
Eric renderizou os quadros em um raytracer que ele escreveu chamado ssg, um precursor do Sculpt. As imagens renderizadas foram codificadas no modo de exibição HAM do Amiga e, em seguida, reunidas em um único arquivo de dados usando um esquema de compactação delta sem perdas, semelhante ao método que mais tarde seria adotado como padrão no formato de arquivo ANIM do Amiga.
Eric e sua esposa Cathryn promoveram ativamente o raytracing no Amiga. Cathryn escreveu o manual do usuário do Amiga Sculpt 3D e compilou um boletim eletrônico distribuído em uma série de discos. O Raytracing 1.0, o mais antigo deles, contém o ssg e a geometria estática do objeto juggler, juntamente com os dados de imagem do Juggler e o programa do jogador.
O Juggler foi uma demonstração surpreendente em sua época. Lembro-me pessoalmente de ficar olhando para ela por vários minutos pela janela da frente de um revendedor Amiga local, imaginando como ela “funcionava”. Muitas pessoas se inspiraram no Juggler e nas animações do Amiga que se seguiram para seguir uma carreira em gráficos 3D. Nada parecido com isso poderia ter sido executado em qualquer outro computador pessoal de estoque em 1986.
Na verdade, Eric relembrou recentemente, o departamento jurídico da Commodore inicialmente “achou que era uma farsa e que eu tinha feito a animação em um mainframe”. Ele lhes enviou seu renderizador para que eles mesmos pudessem gerar e compilar os quadros.
O malabarista pode parecer primitivo para os padrões atuais. Talvez seja mesmo. Já fui submetido a imagens de assinatura de fóruns com mais quadros de animação. Mas isso foi revelador em 1986. O Amiga trouxe os gráficos de raytracing 3D para as massas pela primeira vez. O traçado de raios é extremamente intensivo em termos de computação, mas hiper-realista. Basicamente, ele calcula o resultado de cada raio de luz individual em uma cena.
Dado o explosão do poder de computação, o nos 22 anos desde que o Juggler foi lançado, o senhor poderia pensar que todos os gráficos 3D já estariam sendo renderizados por meio de ray tracing. Até certo ponto, isso é verdadeiro; muitos filmes de animação por computador são renderizados por meio de técnicas de traçado de raios, como o filme da Pixar PhotoRealistic RenderMan.
A Pixar tem fez um trabalho incrível em renderização 3D, mas não é exatamente o que eu chamaria de tempo real. Cortesia de Chris Anderson, aqui está Um pequeno questionário sobre a Pixar:
Em um hardware de computador de 1995, o quadro médio de Toy Story levou duas horas para ser renderizado. Uma década depois, em um hardware de 2005, quanto tempo levou para renderizar o quadro médio de Carros?
- 30 minutos
- 1 hora
- 2 horas
- 15 horas
Answer: D. O quadro médio do Cars levou 15 horas, apesar de um aumento geral de 300 vezes no poder de computação. Os artistas têm um apetite essencialmente infinito por detalhes e realismo, e os recursos da Pixar aumentaram ao longo da década, de modo que a empresa pode se dar ao luxo de alocar mais computadores para a tarefa, permitindo que cada um seja executado por mais tempo para atingir as ambições do artista e do animador para as cenas.
Surpreendentemente, Carros foi o primeiro filme da Pixar a ser renderizado com as técnicas de traçado de raio, mais lentas e precisas; os filmes anteriores usavam principalmente a renderização de linha de varredura. Há uma excelente apresentação de Per Christensen, da Pixar (ppt) que descreve as diferenças em detalhes, caso o senhor esteja curioso. E se quiser experimentar o traçado de raios por conta própria, há sempre o POV-Ray, que produz alguns resultados impressionantes também.
Os filmes, é claro, não precisam ser renderizados em tempo real. Mas, mesmo com a liberdade de levar o tempo que for necessário por quadro, o ray tracing costuma ser muito caro. Imagine a dificuldade, então, de colocar o ray tracing em mecanismos 3D em tempo real. As GPUs modernas são peças de silício impressionantes, mas elas enganam poderosamente quando se trata de renderizar uma cena 3D. Eles precisam fazer isso, caso contrário nunca conseguiriam gerar os 30 ou 60 quadros por segundo necessários para proporcionar a ilusão de um mundo interativo.
É claro que isso não impede que as pessoas tentem. A tentativa de ray tracing em tempo real mais impressionante que já vi foi a de Daniel Pohl e seu Projeto de traçado de raios em tempo real OpenRT. Daniel fez um trabalho fascinante de prova de conceito com o Quake 3 e Quake 4.
Mas o desempenho continua sendo um problema, mesmo no hardware mais recente e melhor:
Então, por que não vemos o raytracing nos jogos atualmente? O problema ainda é o desempenho. Renderizar todos esses efeitos por meio da CPU não é tão rápido quanto usar hardware para fins especiais, como as placas gráficas atuais para o algoritmo de rasterização. Mas a evolução das CPUs é rápida. A velocidade do Q3RT aumentou em mais de um fator de 4 desde 2004. O novo quad core da Intel foi lançado e a eficiência usando a mesma taxa de clock da CPU é cerca de 30% maior.
Uma grande vantagem do raytracing é que ele é perfeito para a paralelização. Conforme explicado na introdução, um raio é disparado pela cena 3D para cada pixel. Se o senhor renderizar uma imagem com 640×480 pixels, terá cerca de 300.000 raios. Cada um deles pode ser calculado independentemente dos outros. Isso significa que a imagem pode ser dividida em quatro partes e cada núcleo de uma CPU quad-core pode calcular os valores de cor da imagem sem esperar por nenhum dos outros núcleos para obter resultados intermediários. Portanto, o dimensionamento do desempenho com o número de núcleos no Quake 4: Ray traced with OpenRT na CPU quad-core da Intel é excelente. Os benchmarks a seguir foram obtidos em uma resolução de 256×256 pixels no mapa do Quake 4 “Over the Edge (Q4DM7)”.
4 núcleos 16,9 fps Dimensionamento de 3,84x 2 núcleos 8,6 fps Dimensionamento de 1,96x 1 núcleo 4,4 fps 1x escalonamento
É é difícil encontrar muitos softwares que sejam dimensionados para além de dois núcleos. Portanto, o surgimento de um futuro com muitos núcleos é uma bênção para os algoritmos de traçado de raios, que escalam quase perfeitamente.
As dimensões do juggler original são 320 x 200. Esse é aproximadamente o mesmo número de pixels que o benchmark de 256 x 256 do Quake 4 apresentado acima. É possível que pudéssemos renderizar o malabarista do Amiga traçado por raios hoje em tempo real a cerca de 30 fps… mas o mal. Apesar de muitas alegações hiperbólicas de marketing de “renderização de Toy Story em tempo real”, o ray tracing em tempo real continua sendo uma espécie de santo graal na prática, considerando que Toy Story foi renderizado em 1536 x 922. Quem sabe o que poderemos renderizar nos próximos 20 anos?