Demo tecnológica a 60FPS da LucasArts para Force Unleashed II

Na recente SIGGRAPH 2010, o programador da LucasArts, Dmitry Andreev, mostrou uma demo tecnológica bem impressionante baseada no trabalho que levou a cabo durante o desenvolvimento de Star Wars: The Force Unleashed II. Numa demonstração em vídeo a correr na Xbox 360, mostrou o jogo a operar nos seus pré-definidos 30FPS, mas depois parecendo como que por magia a correr a 60FPS – sem quaisquer aparentes compromissos gráficos a não ser a remoção do motion blur.

É uma demonstração que podem descarregar e ver por vocês próprios agora mesmo, quer seja em HD ou então numa versão bem mais amigável para a largura de banda em definição normal, estando também a apresentação original de Andreev disponível. Dois vídeos AVI (com necessidade de um descodificador h264) estão no pacote: um protótipo original, ao lado de uma mais refinada prova de conceito a correr no motor de jogo de Star Wars: The Force Unleashed II.

Podemos dizer que é um trabalho impressionante que gerou muita discussão dentro da indústria dos jogos.

A nível geral, existe uma razão para que a maior parte dos jogos de consola operem a 30FPS em oposto aos mais preferíveis 60: quanto mais tempo um programador tem para renderizar um fotograma, mais complexo e rico pode ser. Mas e se uma mistura de inteligente tecnologia e exploração da percepção humana pudesse ser usada para criar um motor 30FPS que parece estar a correr ao dobro da velocidade?

Andreev e os seus colegas elaboraram um sistema que dá a espantosa ilusão de verdadeiros 60FPS e usa menos recursos do sistema do que o seu existente código de motion blur. Troquem o blur pelo escalador de rácio de fotogramas e tens efectivamente todas as vantagens visuais de 60FPS “grátis”, uma vez que existe pouca necessidade de correr completo multi-sample motion blur se o teu jogo já corre a 60FPS.

Andreev originalmente teve a ideia para a técnica ao estudar TVs 120Hz que interpolam dois fotogramas para produzir um imagem intermédia, produzindo uma imagem mais suave. Filtros de software em alguns leitores de media (o Trimension da Philips por exemplo, como visto no leitor WinDVD) também foi considerado. Se esta abordagem pudesse ser recriada dentro do motor de jogo, um efeito muito mais agradável que a maioria dos algoritmos de motion blur poderiam ser produzidos. Discussões após a SIGGRAPH 2008 cedo levaram à criação de protótipos.

”Assim que cheguei a casa, começei a experimentar com ele e pouco depois disso compreendi que existem muitos problemas,” revela Andreev.

”Maioritariamente os artefactos de outra espécie, que aparecem em cenas menos ou mais complexas, assim como problemas de performance (é realmente lento quando feito correctamente). E para melhor compreender o problema, fiz um muito rápido e simples protótipo para testar."

O protótipo usou as mesmas técnicas que as soluções disponíveis, estudando a imagem para “vectores de movimento” que mostravam como elementos da imagem se iriam mover de um fotograma para o próximo. O problema era que acrescentava óbvios artefactos, porque não está disponível informação suficiente para reconstruir a imagem intermediária interpolada. Adicionalmente, procurar os vectores de movimento é incrivelmente intenso para o CPU (daí o porquê de codificar decente de vídeo demorar tanto).

Andreev cedo compreendeu que poderiam atribuir novos propósitos aos blocos de construção do processo de renderização e usados.

”Já sabemos como as coisas se estão a mover uma vez que temos total controlo sobre elas. Desta forma não precisámos de qualquer tipo de estimativa,” diz Andreev.

”Mais do que isso, quando fazemos a interpolação, podemos lidar de forma diferente com coisas diferentes, dependendo do tipo de qualidade com a qual ficamos satisfeitos. Acima disso, podemos usar diferentes técnicas de interpolação para diferentes partes da imagem, como as camadas de transparência, sombras, reflexos e mesmo personagens completas."

Mas porque interpolar sequer? Afinal de contas, já existem no mercado alguns títulos 60FPS bem impressionantes. A razão é que baixar para fixos 30FPS trás todo um leque de novas tecnologias de renderização para o alcance dos programadores. Iluminação diferida à escala do visto em jogos como Killzone 2, Blur e o iminente Need for Speed: Hot Pursuit apenas pode realmente funcionar nas consolas com o tempo extra de renderização disponível. Também torna a vida muito mais fácil para o processo básico de construir um jogo.

”Não é impossível fazer um jogo a 60FPS, obviamente, mas requer um processo de produção muito mais restrito para arte, design, e engenharia,” partilha Andreev.

”Podemos dizer que em muitos casos, durante a pré-produção, os estúdios tentam ver o que seria preciso para fazer um jogo a 60FPS. Depois, ficam com algo que não tem bom aspecto a correr a 60, percebendo que toda a arte tem de ser produzida muito cuidadosamente assim como o design de níveis e de jogo."

Uma solução para tornar um título a sólidos 30FPS é usar motion blur, e houveram algumas implementações bem decentes que fazem a imagem parecer muito mais realista e mais fluida. O motion blur requer o gerar de um chamado buffer de velocidade, que define o movimento. No entanto, ao invés de o usar para a criação do motion blur, o buffer é redireccionado para produzir uma imagem intermediária interpolada que é desenhada a meio ponto entre dois fotogramas.

”Renderizar o buffer de velocidade como iríamos fazer para o motion blur. Construir o fotograma do meio. E apresentá-lo no momento de tempo para o qual foi concebido,” diz Andreev.

”Notem que num caso de conversão de 30 para 60FPS, o fotograma interior tem que ser apresentado a meio do fotograma. É tudo o que isto é, nada mais, nada menos. O resto é implementação em si, o que é bem matreiro.”

A chave é re-utilizar tanto do processamento disponível quanto possível. No caso da demo de Andreev, o buffer de profundidade e mapa de velocidade para o próximo fotograma completo são gerados, mas directamente após isto, a meio do processamento, estes dados, combinados com elementos do fotograma anterior, são usados para interpolar a imagem intermédia antes dos cálculos do próximo real fotograma continuarem.

Seria de pensar que esta técnica causasse latência, mas como a imagem interpolada está a ser gerada usando elementos do próximo fotograma “real”, na verdade reduz a latência. A técnica de Andreev é baseada em fotograma único e não duplo fotograma. A segundo abordagem iria precisar do buffering de duas imagens por isso tem uma grande sobrecarga na memória e latência, enquanto que a técnica que Andreev usou efectivamente interpolava no momento usando anteriores e futuros elementos de renderização anteriores e futuros.

”A mais simples e eficiente solução é fazer a interpolação no local, durante o actual fotograma, enquanto que o anterior está no ecrã. Desta forma o anterior buffer frontal pode ser mapeado como uma textura (na Xbox 360) e usado para interpolação directamente,” explica.

”Em termos de latência existe algo interessante a decorrer. Eu disse que não existe latência extra, o que é verdade. Mas se pensares nisso, a latência é na verdade reduzida porque obtemos o novo resultado visual 16.6ms mais cedo. Podes ver o resultado das tuas acções mais cedo.”