Tomando AC: Unity como exemplo, que tipo de acções podem ser feitas num jogo como esse para se remover carga do CPU?
As declarações da Ubisoft.
Vincent Pontbriand, Produtor Sénior da Ubisoft:
Tecnicamente estamos presos pelo CPU. Os GPUs são realmente poderosos, e obviamente os gráficos são bastante bons, mas é o CPU que tem de processar a Inteligência Artificial, o número de NPCs no ecrã, e todos os sistemas que correm em paralelo. Rapidamente ficamos bloqueados com eles, e isso foi um pouco frustrante, porque achávamos que isto iria ser uma melhoria de dez vezes sobre tudo em termos de IA, e percebemos que isso iria ser bastante difícil. Não é o número de polígonos que afecta o framerate. Podíamos estar a correr a 100 fps se fosse apenas gráficos, mas devido à IA, estamos limitados a 30 frames por segundo.
A serem tomadas como verdadeiras as frases de cima há várias conclusões a tomar:
1 – Vincente deixa claro que os GPUs não estão limitados. Segundo ele, se fosse por eles o jogo poderia estar a 100 fps (provavelmente apenas uma força de expressão, mas que prova que os mesmos não estão limitados). Desta forma, pela parte que toca ao GPU, a resolução superior poderia ser alcançada.
2 – O factor limitativo neste jogo é o CPU. Ele está de tal forma saturado que o pequeno impacto que para si acarreta o aumento de resolução, não pode ser aplicado, forçando o jogo a 900p
3 – O que leva o CPU a ser o elemento limitador é o facto de ter de lidar com a inteligência artificial. Ora esta IA está associada aos NPCs e acima de tudo ao seu elevado número presente no jogo.
E efectivamente os NPCs são em número bastante elevado, como o comprova a imagem que se segue:
São alguns milhares de NPCs no ecrã. Impressionante!
Vamos então ver algumas tecnologias que existem e que num jogo como este serviriam para minorar o uso do CPU.
O uso dos APIs de baixo nível, proprietários das consolas
Tanto XBox One como PS4 possuem APIs de baixo nível. A vantagem destes APIs é que a sobrecarga no CPU mediante idêntico trabalho gráfico solicitado com um API de Alto Nível, é menor, e basicamente consegue-se, em média, reduzir a sobrecarga no CPU para metade.
Apesar das suas vantagens, o uso destes APIs obriga a programação dedicada. Por outras palavras, o código DirectX 11 usado nos PCs, apesar de poder ser convertido na perfeição para ambas as consolas, não faz chamadas de baixo nível, e como tal não tira qualquer partido desta característica das consolas. É assim necessário programar de forma dedicada!
A realidade é que a compatibilidade com o PC leva a que por questões de tempo, se opte pelo caminho mais curto, a de um código único e genérico para todos os sistemas. O DirectX 11 é compatível com ambas as consolas e com o PC mas, como referido, não tira partido dos APIs de baixo nível exclusivos destas últimas, requerendo por isso que o código seja posteriormente substituído por outro mais específico. Tal implica equipas dedicadas que muitas vezes não existem.
Para se evitar essa situação, a melhor forma de se obter um código de baixo nível compatível com as consolas, mas programado no PC é com o uso do Mantle. Este API da AMD é facilmente convertido para os APIs das consolas e é actualmente o único API PC que possui acessos de baixo nível que poderia ser usado para uma programação base de baixo nível nos 3 sistemas. No entanto, neste caso, o suporte ao Mantle da AMD, estava fora de hipótese pelo facto de este ser um jogo patrocinado pela Nvidia.
Diga-se ainda que a preferência pela programação genérica como base de trabalho PC é algo comum. Mesmo equipas First Party da Sony começam a programar em código de alto nível e só passam para baixo nível se encontrarem limitações. Tal aconteceu com a Guerrilla e com Killzone: Shadow Fall, como pode ser confirmado na página 28 deste documento, e onde a equipa refere que recuperou cerca de 50% de CPU ao alterar algum código de alto nível.
Como já foi dito, dada a ausência de declarações da Ubisoft nesse sentido, desconhece-se se AC: Unity jogo teve direito a optimizações deste género para as consolas, e se o teve, a que nível.
Geometry Instancing
Em uma cena gerada por computador é normal termos por vezes milhares ou até milhões de cópias de um objecto.
Infelizmente esse tipo de situação era demasiadamente penosa para o CPU e GPU que tinham de trabalhar em conjunto na criação, a partir do zero, de cada nova cópia do objecto, pelo que o DirectX 9.0 passou a incluir na sua norma uma nova característica, a “geometry instancing” por hardware que passou a ser comum em todas as placas gráficas.
Basicamente o que esta caracteristica faz é evitar que cada objecto tenha de ser rendido novamente sempre que entra em cena. Em objectos como relva, arvores, edifícios, e mesmo personagens, usando-se esta característica do hardware, várias cópias podem ser colocadas em cena sem terem de ser recalculadas. Tal permite cenas muito mais complexas, sem a penalização que existia antes no CPU e no GPU no re-cálculo das cópias, sendo toda a tarefa realizado internamente no GPU mediante uma cópia básica.
Este documento da Nvidia, de 2004, demonstra a técnica e as suas vantagens, referindo que “com o mínimo de sobrecarga no CPU e de gastos de memória, esta técnica permite de forma eficiente render muitas cópias da mesma geometria e é a solução ideal em muitos cenários” (não confundir com as sobrecargas causadas pelos acessos de alto nível). Infelizmente na altura em que a técnica foi descrita o hardware que a suportava ainda estava nos seus primórdios, e como tal o documento ainda apresenta alguns inconvenientes, que desapareceram ou foram minimizados com a introdução do DX 10 e DX 11.
Basicamente a técnica passa, totalmente e sem grande carga, para o GPU todo o processo de repetição de personagens, não criando assim grande peso no CPU!
O principal defeito desta técnica, quando ela foi apresentada, é que a mesma criava cópias dos objectos. Ou seja, eles eram todos iguais!
Para se resolver isso, a técnica evoluiu, e cada cópia passou a ter parâmetros diferenciadores (por exemplo, em personagens podemos mudar cor, esqueleto, roupa, pose de animação, etc), reduzindo assim a ideia de repetição.
Eis exemplos aplicados à relva:
Aplicados às arvores:
E aplicados a personagens, no velhinho LOTR: The Battle for Middle-Earth, de 2004 (poderia igualmente falar de Rome Total War da mesma data).
Sim, estamos a ver aqui uma largas centenas ou mesmo milhares de personagens rendidas num PC de 2004 (Um Pentium 4 a 3,2 Ghz com uma Geforce 6800 era o recomendado para detalhe máximo), usando esta característica. E onde devido aos parâmetros usados, a ideia de repetição está minimizada!
Eis mais exemplos de Geometry instancing realizada pelo GPU:
É quase impossível que esta tecnica não seja usada em AC: Unity para a criação dos vários NPCs. No entanto, apenas como referência, caso não o fizesse, a sobrecarga no CPU e GPU seria enorme perante a quantidade de NPCs no ecrã, encontrando muito certamente severas limitações no CPU, o mais fraco dos elementos.
IA pelo e física pelo GPU
Apesar de termos razões para acreditar que pelo menos parte da física do jogo de AC: Unity está a ser calculada pelo GPU (física de tecidos), não se sabe que mais foi passado para lá, libertando-se o CPU.
Assassins Creed 4: Black Flag calcula o nevoeiro pelo GPGPU da PS4, e não há motivos para que tal não aconteça igualmente aqui. Da mesma forma os efeitos de chuva e animação das gotas que caem ao chão, igualmente existentes em Black Flag e processados pelo GPU, deverão estar a ser processados da mesma forma neste jogo.
O que falta saber é se perante tantos NPCs, o processo de “path finding” (encontrar caminhos) de todos os personagens que se movem no ecrã, está a ser igualmente processado pelo GPGPU, ou se está atribuído ao CPU.
Este processo de encontrar caminhos é uma grande parte da IA do jogo que é aplicável a todas as personagens em movimento. E dado que a maior parte deles se limita a movimentar-se pela cidade, é algo que terá grande peso nos cálculos da IA geral.
A demonstração que se segue foi criada para demonstrar as capacidades da ATI HD 4800, uma placa de 2008, e mostra técnicas que usam as capacidades de computação paralela da placa gráfica. Ali vemos milhares de personagens com IA personalizada, os Froblins, que são simuladas, animadas e rendidas totalmente no GPU. Cada um dos milhares de personagens que se vêem no ecrã é controladas por um conjunto de 3200 shaders que simulam o comportamento de cada Froblin. A tecnologia usada é o DX 10.1 e calcula todo o processo de “path finding” (descoberta de caminhos), no GPU, demonstrando que a IA pode, pelo menos parcialmente, ser calculada no GPU.
Mais uma vez, desconhece-se se este jogo implementa algo jo género no GPU, ou se é tudo calculado pelo CPU!
Dinamyc LOD
Uma tecnologia usada pelos sistemas informáticos à muito tempo é o Dynamic LOD. LOD é a abreviatura de Level Of Detail, e basicamente traduz-se como Nível De Detalhe.
Dado que os polígonos que constituem uma cena necessitam de ser processados, não há justificação que os mesmos estejam presentes e a acrescentar processamento quando os objectos estão mais distantes. Sendo eles mais pequenos, e com menor detalhe, torna-se desnecessário que eles possuam o mesmo número de polígonos. E daí surge o LOD, onde são criadas cópias dos objectos que são optimizadas para as diversas distâncias. Com o aproximar do jogador, as várias cópias são substituídas por outras com mais detalhe. Eis um exemplo:
A caneca da imagem está apresentada em três níveis de detalhe diferentes. Quando mais a câmara se aproxima, mais detalhe ela apresenta, possuindo três níveis de qualidade!
Visualmente o efeito é quase imperceptível. Com a distância o número de pixels atribuído ao objecto diminui, e torna inútil a presença dos polígonos!
Ora esta tecnologia aplica-se não só aos polígonos, mas igualmente à IA. Apesar de que todas as personagens podem necessitar de possuir um tipo de IA genérica (como o path finding), não há motivo para a qualidade do resto da IA aplicável ser idêntica em personagens a centenas de metros e naquelas com as quais estamos a interagir por estarem nas proximidades.
Ou seja, num jogo como AC: Unity, onde há vários NPCs a distâncias variáveis, não há a necessidade de se gerir com a mesma qualidade de IA todos os NPCs que estão visíveis. É possível possuir-se igualmente vários níveis de IA conforme a proximidade da personagem ao jogador. Assim à distância as personagens secundárias estariam meramente animadas a conversar ou a andar, e só ganhavam a total capacidade de interacção quando o jogador se aproxima.
Mais uma vez não se sabe o que está implementado no jogo, ou as necessidades de IA que a equipa entendeu serem adequadas.
Notas finais
Como já perceberam este artigo pretende concluir nada, sendo apenas uma listagem de tecnologias que no jogo em questão podem ser aplicadas e que desceriam o uso do CPU. Não se sabe, e nem se pretende discutir se elas foram ou não aplicadas em AC: Unity, sendo que o jogo é apenas uma desculpa para se falar nelas.
Seja como for, apesar de muito certamente quase todas estarem aplicadas, falta saber até que ponto as mesmas foram implementadas e optimizadas ou se o resultado poderia ser ainda melhor. Resumidamente, se os 900p aplicados nas consolas poderão ou não ser justificáveis!
O uso dos APIs de baixo nível será algo que melhorará com o tempo. Há uma curva natural de evolução no conhecimento das capacidades e características do mesmo. Mas onde haverá verdadeiros ganhos é no uso do GPGPU. A tecnologia está disponível à anos, existem imensas provas de conceito, mas o seu uso é ainda bastante limitado e longe de explorar o potencial ali escondido.
A Ubisoft parece reconhecer que há mais a evoluir, e nesse sentido parece haver indicações que pretende alterar o seu motor para o próximo jogo. Aparentemente a equipa quer ter uma noção das capacidades dos diversos motores existentes na empresa, e passar a usar um que melhor se adapte às exigências gráficas das novas gerações.