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

5 2 votes
Avalie o nosso artigo

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.





5 2 votes
Avalie o nosso artigo
5 Comentários
Antigos
Recentes
Inline Feedbacks
Ver todos os comentários
Sparrow81
Sparrow81
1 mês atrás
Avalie o nosso artigo :
     

SS com rendimento interno de 533p. Se não fosse a Coalition otimizando, nem rodaria. Tenso.

Hennan
Hennan
1 mês atrás

Feliz Natal pra você Mário e todos que fazem parte dessa comunidade.

Eraser
Eraser
29 dias atrás
Avalie o nosso artigo :
     

Desfrutem desta demo, é que o filme é uma valente B*sta com B grande.

Eraser
Eraser
Responder a  Mário Armão Ferreira
29 dias atrás

Para mim é. Pode não ser o teu caso, mas quem gostou dos dois primeiros certamente não deve gostar deste.

error: Conteúdo protegido