Por que os jogos modernos usam uma abordagem de renderização em textura para espelhos?

Ao olhar para jogos antigos como Mario64 ou DukeNukem3D, todos os espelhos do jogo são essencialmente apenas buracos na parede com uma cópia espelhada da geometria na frente do espelho colocada atrás deles. No caso do DukeNukem3D, pode-se até ativar no-clip e entrar naquela sala espelhada.

Em contraste, os jogos modernos usam uma abordagem de renderização em textura para espelhos. Isso faz com que os espelhos fiquem visivelmente pixelados ao se aproximar deles. Um dos primeiros jogos que notei essa abordagem foi a Mansão de Luigi, mas parece ser usada em quase todos os jogos modernos.

Que mudança no hardware ou nos motores fez a segunda abordagem se tornar tão dominante hoje em dia e quais são os benefícios para ela? Em termos de visual puro, a primeira abordagem parece superior, pois não sofre de problemas de pixelização.

1. O uso de RTT (renderização em textura) permite dimensionar facilmente a qualidade de renderização (resolução, LOD, complexidade da iluminação) para um desempenho ajustável. O RTT também facilita a substituição da superfície por um mapa cúbico a uma certa distância, onde é difícil ver exatamente o reflexo.
2. Como a saída é uma textura, há mais opções sobre o que pode ser feito posteriormente (iluminação, sombreamento, mesclagem, distorção etc.).
3. Se uma versão espelhada da geometria for colocada em cena, seria necessária uma seleção mais complicada quando cruzar com a geometria real e puder ser vista atrás do canto. Nos jogos mais antigos, os níveis foram projetados para evitar isso. Sem mencionar que alguém tem que fazer o espelhamento real.
4. Se a geometria não for espelhada manualmente, a renderização deverá ser feita alterando a matriz da vista e o modo de descarte (para compensar a inversão de espaço na matriz) e usando o buffer de estêncil para cortar o espelho. Os mecanismos modernos preferem criar todos os estados de renderização antecipadamente; portanto, haveria um pequeno problema ao fazer cópias de cada estado de renderização de cena com as alterações necessárias para a renderização em espelho.

Então, basicamente, o uso do RTT oferece mais liberdade para todos.

Não, você está errado - não foi assim que os espelhos do Duke Nukem 3D funcionaram.

O DN3D usou um mecanismo de portal . Uma articulação entre dois setores era arbitrária até certo ponto e, quando o mecanismo de renderização chegava a um portal, ele sabia que precisava começar a renderizar outro setor. O setor atrás do espelho era basicamente um espaço reservado para lidar com uma peculiaridade do motor - o único ponto do setor era ser maior do que o que você precisava "refletido". Não continha geometria real. De fato, funcionou da mesma maneira que os "portais" funcionam no Portal - exceto que o Portal (que é baseado em um mecanismo de portal) cria os portais em tempo de execução e tem um limite de quantas vezes os portais podem recorrer (ou seja, A -> B -> A -> B -> A ...), enquanto o Build (DN3D) simplesmente travava porque sua pilha transbordava se você apontasse um espelho para outro espelho.

É óbvio como é simples implementar um espelho com isso - crie um portal que aponte de volta para a sala. Isso significava que renderizar o espelho custaria exatamente o mesmo que renderizar a sala em si, proporcionando excelente desempenho e consistência. Contanto que você não aponte um espelho para outro espelho. Se você examinar o código-fonte do mecanismo Build, verá que não há nenhum espelho para manipulação de código - não precisa haver um, porque é assim que os portais funcionam NOTA: na verdade, há código para inverter os pixels renderizados - ele simplesmente não vira a geometria e todos os vários sprites e efeitos. O editor tinha que ser capaz de criar esses portais "falsos", porém - olhando para si mesmo. Se você quiser saber mais sobre o mecanismo Build bastante inteligente, há uma ótima análise de Fabien Sanglard nos internos do mecanismo Build . Todo o mecanismo também foi de código aberto e portado para plataformas modernas, embora o antigo ainda funcione perfeitamente no Windows 10 (testado para você: P). Muitos dos jogos baseados no Build também foram de código aberto e / ou refeitos.

Por que isso não é mais usado? Bem, alguns mecanismos não preferem mais portais, por exemplo. É complicado aplicar muitos hacks gráficos e otimizações - não posso apontar nada específico, mas muito pós-processamento depende de hacks que não funcionariam em um verdadeiro mecanismo de portal (eles fazem muitas suposições que não espera mais). Esse é basicamente o mesmo tipo de problema que esses jogos têm com imagens estereoscópicas - os hacks não funcionam mais.

Mais importante, os espelhos ficaram mais complicados. Eles podem ter formas complexas, texturas, podem estar no solo (também conhecidos como "água") etc. Embora todos esses problemas sejam solucionáveis ​​em um mecanismo de portal, o RTT se torna a escolha mais simples em algum momento, e as GPUs são rápidas o suficiente para lidar com isso.

No entanto, mesmo com tudo isso, há muitos jogos com aceleração 3D de hardware que fazem coisas "reais". Nos jogos mais antigos, Quake 3 ou Alien vs. Predator, por exemplo. Até onde eu sei, os jogos de mecanismo de origem ainda usam espelhos "reais". Se você espera que as pessoas se aproximem do espelho e pode garantir que não haja muitas superfícies refletivas ao mesmo tempo (por exemplo, através do design de nível), os espelhos portais ainda são muito atraentes.

O RTT teria sido usado se fosse possível, mas o pipeline de renderização de hardware era uma maneira.

O hardware mais antigo também tinha limitações que impediam a renderização da textura. Gravar na RAM significa que não pode ser lido ao mesmo tempo. Para melhorar o desempenho da renderização, o buffer de destino foi bloqueado apenas para gravação, apenas o hardware da tela pôde ler a partir dele. Você poderia solicitar a leitura, mas isso bloqueava a RAM e a renderização tinha que esperar a trava desaparecer antes que pudesse iniciar o próximo quadro. O RTT causaria um grande gargalo no oleoduto e, portanto, outras soluções foram usadas.

Você verá que, antes dos pipelines de renderização de hardware, a norma RTT era usada, pois fornecia uma maneira de reduzir a carga de renderização. 3D renderizado para sprites para fornecer conteúdo pseudo 3D. A renderização de textura era muito cara (CPU) para ser usada naquela época, além de máquinas especializadas que estavam fora do mercado de consumo em geral.

Duke Nukem entende que, ao renderizar novamente a geometria atrás do espelho, as outras respostas estão parcialmente corretas. Existem áreas atrás dos espelhos que na verdade não contêm geometria (nos arquivos de dados do jogo), a geometria é renderizada novamente no tempo de execução, a razão para essas áreas existirem é evitar colocar acidentalmente um nível de nível ao editar o nível :

como existe uma área marcada, você não colocará acidentalmente nenhuma geometria nela.