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.
Respostas:
Então, basicamente, o uso do RTT oferece mais liberdade para todos.
fonte
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 funcionamNOTA: 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.
fonte
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.
fonte
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.
fonte