¿Por qué los juegos modernos usan un enfoque de renderizado a textura para los espejos?

Al mirar juegos antiguos como Mario64 o DukeNukem3D, todos los espejos en el juego son esencialmente agujeros en la pared con una copia reflejada de la geometría frente al espejo puesta detrás de ellos. En el caso de DukeNukem3D, incluso se puede activar sin clip y entrar en esa habitación reflejada.

En contraste, los juegos modernos utilizan un enfoque de renderizado a textura para los espejos. Esto lleva a que los espejos se pixelen notablemente al acercarse a ellos. Uno de los primeros juegos en los que noté este enfoque fue Luigi's Mansion, pero parece usarse en casi todos los juegos modernos.

¿Qué cambio en el hardware o los motores hizo que el segundo enfoque se volviera tan dominante en estos días y cuáles son sus beneficios? En términos de imágenes puras, el primer enfoque parece superior, ya que no sufre problemas de pixelación.

1. El uso de RTT (render-to-texture) permite escalar fácilmente la calidad de renderizado (resolución, LOD, complejidad de iluminación) para un rendimiento ajustable. RTT también hace que sea más fácil reemplazar la superficie con un mapa de cubos a una cierta distancia donde es difícil ver exactamente el reflejo.
2. Dado que la salida es una textura, hay más opciones con respecto a lo que se puede hacer después (iluminación, sombreado, fusión, distorsión, etc.).
3. Si se coloca una versión reflejada de la geometría en la escena, requeriría un sacrificio más complicado cuando se cruza con la geometría real y podría verse detrás de la esquina. En juegos más antiguos, los niveles fueron diseñados para evitar esto. Sin mencionar que alguien tiene que hacer el reflejo real.
4. Si la geometría no se refleja manualmente, la representación se debe hacer cambiando la matriz de vista y el modo de selección (para compensar la inversión de espacio en la matriz), y utilizando el búfer de la plantilla para cortar el espejo. Los motores modernos prefieren crear todos los estados de renderizado de antemano, por lo que habría un problema menor al hacer copias de cada estado de renderizado de escena con los cambios necesarios para el renderizado espejo.

Entonces, básicamente, usar RTT da más libertad a todos.

No, te equivocas, no es así como funcionaban los espejos de Duke Nukem 3D.

DN3D utilizó un motor de portal . Una unión entre dos sectores cualquiera era arbitraria hasta cierto punto, y cuando el motor de renderizado llegó a un portal, sabía que tenía que comenzar a renderizar otro sector en ese sentido. El sector detrás del espejo era básicamente un marcador de posición para lidiar con una peculiaridad en el motor: el único punto del sector era ser más grande de lo que sea que se "refleje". No contenía ninguna geometría real. De hecho, funcionó más o menos de la misma manera que los "portales" funcionan en el Portal, excepto que el Portal (basado en sí mismo en un motor de portal) crea los portales en tiempo de ejecución y tiene un límite de cuántas veces pueden volver a aparecer los portales (es decir, A -> B -> A -> B -> A ...), mientras que Build (DN3D) simplemente se bloqueaba cuando su pila se desbordaba si apuntabas un espejo a otro espejo.

Es obvio lo fácil que es poner en práctica un espejo con que - hacer un portal que los puntos atrás en la habitación. Esto significaba que renderizar el espejo costaría exactamente lo mismo que renderizar la habitación en sí, lo que da un gran rendimiento y consistencia. Siempre y cuando no apuntes un espejo a otro espejo, eso es. Si mira a través del código fuente del motor de compilación, verá que no hay espejos de manejo de código en absoluto; no es necesario que haya uno, porque así es como funcionan los portales NOTA: en realidad, hay código para voltear los píxeles renderizados: simplemente no voltea la geometría y todos los diversos sprites y efectos. Sin embargo, el editor tenía que poder hacer estos portales "falsos", mirando hacia atrás. Si desea obtener más información sobre el motor Build bastante inteligente, Fabien Sanglard hace un excelente análisis en las partes internas del motor Build . Todo el motor ha sido abierto y portado a plataformas modernas también, aunque el antiguo todavía funciona perfectamente en Windows 10 (probado para usted: P). Muchos de los juegos basados ​​en Build también han sido de código abierto y / o rehechos.

¿Por qué ya no se usa esto? Bueno, algunos motores ya no prefieren portales, por ejemplo. Es complicado aplicar muchos hacks gráficos y optimizaciones: no puedo señalarle nada específico, pero una gran cantidad de postprocesamiento depende de hacks que no funcionarían en un verdadero motor de portal (hacen muchas suposiciones que ya no aguanta) Este es básicamente el mismo tipo de problema que estos juegos tienen con las imágenes estereoscópicas: los hacks ya no funcionan.

Lo más importante, los espejos se volvieron más complicados. Pueden tener formas y texturas complejas, pueden estar en el suelo (también conocido como "agua"), etc. Si bien todos esos problemas se pueden resolver en un motor de portal, RTT se convierte en la opción más simple en algún momento, y las GPU son lo suficientemente rápidas para manejarlo

Sin embargo, incluso con todo eso, hay muchos juegos con aceleración 3D de hardware que hacen cosas "reales". De los juegos más antiguos, Quake 3 o Alien vs. Predator, por ejemplo. Hasta donde yo sé, los juegos de motor Source aún usan espejos "reales". Si espera que las personas se acerquen al espejo, y puede garantizar que no haya demasiadas superficies reflectantes al mismo tiempo (por ejemplo, a través del diseño de nivel), los espejos de portal siguen siendo muy atractivos.

RTT se habría utilizado si fuera posible, pero la canalización de representación de hardware era unidireccional.

El hardware más antiguo también tenía limitaciones que impedían renderizar a la textura. Escribir en RAM significa que no se puede leer al mismo tiempo. Para mejorar el rendimiento de representación, el búfer de destino se bloqueó para escribir solo, solo el hardware de la pantalla podía leerlo. Puede solicitar la lectura, pero eso bloqueó la RAM y el renderizado tuvo que esperar a que se desbloqueara el bloqueo antes de que pudiera comenzar el siguiente marco. RTT causaría un importante cuello de botella a la tubería y, por lo tanto, se usaron otras soluciones.

Encontrará que antes de que las tuberías de renderizado de hardware fueran la norma RTT se utilizó, ya que proporcionaba una forma de reducir la carga de renderizado. Representación 3D en sprites para proporcionar contenido pseudo 3D. El procesamiento de texturas era demasiado costoso (CPU) para ser utilizado en ese entonces, aparte de las máquinas especializadas que estaban fuera del mercado general de consumo.

Duke Nukem maneja que al volver a representar la geometría detrás del espejo, las otras respuestas son parcialmente correctas. Hay áreas detrás de los espejos que en realidad no contienen geometría (en los archivos de datos del juego), la geometría se vuelve a representar en el tiempo de ejecución de hecho, la razón de que existan esas áreas es para evitar colocar accidentalmente una pieza de nivel al editar el nivel :

Como hay un área marcada, no colocará accidentalmente ninguna geometría allí.