Matrix Awakens está longe de estar otimizado – É mais do que tudo, uma prova de conceito.

Os dados revelados pelos programadores da Demo mostram que não só a Demo está por otimizar, como ela implementa muitas situações que são remedeios, dado que o Nanite ainda está em desenvolvimento.

Pois é… O mundo ficou impressionado com o aspeto foto realista, em tempo real de Matrix Awakens.

Basicamente a equipa revela que o motivo pelo qual lançou a demo se prendeu com o ceticismo geral que sabia que ela iria causar. Caso a mesma fosse apenas mostrada em vídeo, as pessoas iriam levantar teorias da conspiração, alegando que aquilo estaria a correr num PC de topo, e que tal nunca veria a luz do dia nas consolas. E desta forma, para calar os céticos, a EPIC decidiu lançar a demo nas consolas.

Acima de tudo a demo mostra uma qualidade gráfica foto realista, com um nível de detalhe no pormenor que nunca se esperaria ver tão cedo. São milhões e milhões de polígonos, tudo em tempo real, e tudo a correr nas consolas que temos em casa.

Claro que a tecnologia é escalável, e nesse aspecto, até a modesta Série S correu a demo. Isto ocorreu com sérios compromissos, mas tal não impediu que a consola mais fraca desta geração conseguisse apresentar a mesma demo com uma qualidade aceitável, e com as devidas performances.

A equipa que trabalho nesta demo tem um histórico fabuloso. Não só foram eles que fizeram a tech demo da Nvidia do Star Wars que, pela primeira vez, nos mostrou RT em tempo real a correr num GPU caseiro, como tambem foi a responsável pela demo “Lumen in the land of Nanite”, e “Valley of the Ancient”. É esta mesma equipa que trabalha com a Lucasfilms noe efeitos CGI de ecrã gigante que temos em “The Madalorian”. Basicamente uma equipa que é o “creme de la creme”, uma equipa de luxo, que resolveu compilar um pouco de tudo o que tem trabalhado e meter tudo na nova geração de consolas.

O facto de o CTO da Epic,  Kim Libreri, ter trabalhado em Hollywood, e em particular nos filmes “The Matrix” abriu portas que permitiram a criação desta demo.

Assim, o conceito de criação de uma mega cidade, em mundo aberto, com vista infinitas era algo que a equipa sabia que poderia ser possível, mas algo nunca tentado antes, pelo que , misturando objetos reais de cidades como Nova Yorque, São Francisco e Chicago, criaram a cidade da demo, provando assim que tal era possível.

Mas aqui a demo não é tão dependente do streaming como em outras demos anteriores. Para diminuir as exigências do streaming, a equipa usou um sistema de geração procedural, usando um software chamado Houdini. A cidade foi assim gerada, mas não é totalmente exportada, sendo apenas gerada uma nuvem de pontos com alguns megabytes que é colocada no motor. Desta forma. com estes dados, a ferramenta “World Processor” do Unreal Engine define a cidade, os contornos, e a grelha da estrura de estradas, as artérias principais, e toda a estrutura principal da cidade que é cheia com o pormenor de mais de 10 milhões de objectos. E aqui sim, o streaming entra novamente em cena, mas graças a um sistema de partição do mundo, a coisa é amenizada.

Esta situação de texturas virtualizadas tornam o Nanite bastante ligeiro em largura de banda, requerendo esta demo apenas 10 MB/ fotograma, ou 300 MB/s numa cena a 30 fps.

Isto quer dizer que os sistemas de I/O das novas consolas não estão a ser minimamente stressados nesta demo. E os engasgos que existem não de devem a eles, mas sim ao facto que o Nanite é ainda trabalho em progresso. Basicamente isso deve-se a problemas ainda por resolver na forma como os dados são inicializados, e isso é a causa dos engasgos. A equipa reconhece que ainda há trabalho a ser realizado no Nanite para eliminar estas situações.

Face à demo “Lumen in the land of Nanite”, o Lumen foi muito melhorado. E foi acrescentado suporte hardware ao RT, o que permite que esta demo já use essa situação, permitindo reflexos e sombras mais realistas.

Uma situação perfeitamente desnecessária, mas usada nesta demo como prova de conceito é que o jogo mantêm sempre presente a posição de um total de 35 mil peões que se deslocam na cidade, bem como 40 mil carros parados e 18 mil veículos em movimento. Quer eles estejam no ecrã, ou não, o jogo sabe sempre onde eles estão, e tudo como prova de conceito do potencial da IA do novo Unreal Engine. Isto não será uma situação que veremos em jogos, onde a necessidade de tal não existe.

Onde o Nanite demonstra as suas fraquezas é nas colisões e deformações de objetos. Na realidade o Nanite foi criado para lidar apenas com objectos rígidos, e apesar de a cidade em movimento dar algum aspeto de dinamismo, a fraqueza dos Nanite aparece quando os objetos se deformam. E esse é o motivo porque quando há um acidente os fps caem. Basicamente esta é uma situação que ainda está por implementar no Nanite, e que obrigou a equipa a recorrer a uma solução alternativa para os acidentes e deformações.

O que acontece então?

Bem, a partir do momento em que o veiculo bate, ele passa a ser rasterizado por metodologias tradicionais, o que causa situações de quebras de performance. É mais uma situação não optimizada que está ainda para ser corrigida. A explosão da ponte, na sequencia de perseguição, obrigou a pré calcular toda a explosão, de forma a que tal seja um mero script. Isto para que as performances do Nanite com as deformações não caíssem a pique.

O video que se segue mostra claramente o que é lidado com o Nanite e o que é Rasterizado. E permite ver como os carros, após baterem, passam a ser rasterizados.

Repare-se tambem que as arvores são Rasterizadas, pois o Nanite ainda não lida com elas.

Não lida… mas eventualmente vai lidar, pois como mostra a demo que se segue, a Epic está a trabalhar nelas:

Resumidamente, isto mostra que o que vimos nesta demo está longe de ser algo otimizado. É trabalho em progresso. A própria demo mostrou-se muito relevante na perceção dos problemas do Nanite. Tanto que a equipa confessa que a demo a determinada altura foi toda deitada fora, e começada do inicio. As coisas iam sendo remediadas à medida que os problemas apareciam, mas a determinada altura as correçõesa muitas dessas situações apareceram e tornou-se preferível começar do zero. Basicamente, com as coisas resolvidas, era mais rápido começar tudo de novo, do que continuar o que existia.

Outra situação que a equipa explica é que a sequencia de perseguição foi, por questões artísticas, pré definida para correr a 24 fps, uma cadência de cinema. O problema é que os monitores tem sérios problemas em apresentar 24 fps quando bloqueados a múltiplos de 30. Esta situação cria um frame pacing inconsistente que podem levar os fotogramas aos 100 ms. Associem isto aos acidentes e quebras de performance aí, e estão explicadas as quebras até aos 20 ms.

A equipa explicita esta situação, para que não se julgue que estas quebras são normais ou expectáveis neste hardware. Na realidade elas estão explicadas e nada tem a ver com as performances das máquinas.

Deixo-vos com alguns tweets de alguem que obteve feedback dos programadores da demo.

Also: “getting things on Series S was a little bit scary…But to be fair to Microsoft, it’s a pretty good experience on series S. Yeah, sure, we’re running at lower resolution or resolution, and the @digitalfoundry guys will see there are a few other compromises…”

— Stephen Totilo (@stephentotilo) December 13, 2021

Can it run on Switch? “No… at some point we have to work out how do we author assets at this fidelity that could work on Switch, but one step at a time.”

Want to bring it to PC? “We’ll see…” but then said it’d require lots of testing for different specs. Sounded unlikely

— Stephen Totilo (@stephentotilo) December 13, 2021