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

40

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.

Grumbel
fuente
14
¿Qué pasa si quieres un espejo en una puerta entre dos habitaciones?
Superbest

Respuestas:

37
  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.

serpiente5
fuente
El 3 .: La mayoría de los motores de juegos FPS (más antiguos) usaban algoritmos de bisección (como el famoso "motor de portal" que DOOM usa) que ya recortan los polígonos (muy probablemente cuádruples) para el sacrificio de visibilidad. Tales motores pueden pisar fácilmente un "espejo" cuádruple como un portal de visión en una habitación detrás del espejo sin preocuparse por la geometría reflejada fuera del espejo.
dronus
@dronus ¿Qué? Entonces, ¿por qué molestarse en hacer un "espejo" en primer lugar? Solo abre un agujero en la pared.
S. Tarık Çetin
Debido a que la geometría real puede no dejar espacio detrás de la pared del espejo, como un espejo real no necesita tener una habitación detrás para trabajar.
dronus
29

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.

Luaan
fuente
Aparentemente, la razón de la creencia común de que Duke Nukem 3D funcionó de esta manera es el hecho de que en los diseños de nivel reales, el espacio detrás del espejo es tan grande como la habitación que refleja, a pesar de que el motor de renderizado en realidad no lo requiere.
Random832
Además, los portales que no son espejo no, bueno, reflejan cosas, así que no sé cómo "no hay espejos de manejo de código" es posible.
Random832
55
@ Random832 Era un poco obligatorio: había algunos artefactos visuales si aparecía algún sector en el lugar donde se suponía que debía estar la habitación reflejada. Esa es una de esas partes donde la mayoría de las suposiciones inofensivas son importantes para el rendimiento. Si alguna vez jugaste con Build, es posible que hayas notado que cuando dos sectores se cruzan a la misma altura, no se procesarán bien. En cuanto a la duplicación, funciona de la misma manera que los reflejos de la vida real. ¿Te has preguntado alguna vez por qué los espejos solo "giran" en el eje y? Es la misma razón por la que no necesita voltear un portal que lo conecta de nuevo a la misma habitación.
Luaan
El punto es que un portal normal que conduce a una habitación que se enfrenta en la dirección opuesta tendría que girar las cosas 180 grados en lugar de reflejarlas. Por lo tanto, tener la capacidad de no hacerlo cuenta como un manejo especial para los espejos. (No tener la capacidad de hacerlo significaría que los portales no funcionan como portales y solo son adecuados para espejos, en cuyo caso todo el sistema es un manejo especial para espejos). Y sí, sé por qué refleja "solo" voltear "en el eje y". De hecho, giran sobre el eje z. Pero el hecho de que muevan un número impar de ejes los distingue de los portales.
Random832
@ Random832 Depende de lo que llames el eje y, por supuesto :) Y sí, tienes razón, hay un manejo especial. Pero es muy interesante: voltea los datos renderizados, no la geometría (y los sprites y todo ... bastante trabajo, en realidad). El marco del portal se voltea, el portal se representa como de costumbre, y luego todo se representa al revés, línea por línea.
Luaan
3

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.

Ciego67
fuente
1

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í.

Desarrollador de juegos
fuente