Imagínate que haces una escena en la que sabes que la luz no se va a mover. En esta escena tienes varios elementos estáticos, por lo tanto también sabes que no se van a mover. Pongamos una habitación con una ventana, una cama y un escritorio.
Si todo eso no va a cambiar, puedes hacer tus texturas incluyendo ya las sombras y el efecto de la luz. Por ejemplo la textura de la sábana ya tiene oscurecida la parte donde no da el sol de la ventana y la del escritorio tiene más brillo ahí donde el sol refleja en la madera.
Queda muy realista porque el cálculo lo has hecho en producción y además eso permite al motor ahorrarse cálculos de luz. Simplemente pone la textura en su sitio y listos.
Pero claro, no puedes mover el sol de sitio porque entonces la luz y las sombras que precalculaste no cuadran. Tampoco puedes mover la cama ni el escritorio porque cantaría como una almeja.
Este es el sistema mas clasico, el que menos costo de recursos tiene (no tiene calculo adicional, porque ya la luz vino como un dato fijo aplicado, lo unico que pones en pantalla es la textura). El problema de este sistema empieza cuando algo altera la fuente de luz y la sombra "no cambia". En ese ejemplo, entraste a la habitacion y te paraste frente a la ventana mirando a la cama, no le generaste ninguna sombra adicional, osea bloqueaste la luz pero la luz llega igual como si fuera tu personaje de vidrio; y por el contrario, si entras con una linterna y enfocas la cama donde da la sombra, esta sigue sombreada como si ninguna luz estuviera dandole de frente. Ahi es, en el sitema clasico, donde empiezan las correcciones adicionales que tienen calculo adicional. Por ejemplo, a tu personaje se le pone sombra dinamica, entonces al bloquear proyectas sombra. Y en el caso contrario, si entras con una linterna a la habitacion y enfocas la cama, la sombra pegada "se aclara un poco" para disimular que venia pegada (pero si igual te fijas bien se nota un poco que la sombra sigue estando ahi abajo solo que se aclaró un poco toda la textura y se dificulta notarla). Otros efectos para disimular la luz pegada es que la textura cambie, por ejemplo si ponias en esa habitacion una vela, la luz pegada a la textura haria un circulo de luz alrededor de la misma aclarando un poco la textura de la mesa donde la vela se apoye, si quieres darle mas realismo como que la vela esta encendida haces que ese circulo oscile un poco agrandandose y achicandose como dando la sensacion de que el movimiento del fuego por el aire genera ese cambio de luz, pero de vuelta es falso, si te cruzas con el personaje cerca de la vela no alteras la oscilacion, y de vuelta hay que usar trucos de poner otra sombra arriba de esa otra o aclarar la textura si le pones alguna otra luz encima.
Todo esto si bien no tiene tanto consumor de recursos como el RT es trabajo adicional ya que hardware no interpreta la escena, solo tiene datos pegados sin entender si esa textura mas clara es mas clara porque asi es su color o porque el creador queria que eso simule ser luz. El hardware no tiene idea de que es lo que significa ese dato. Por eso no le calcula nada adicional. Todos los retoques para hacer mas creible la luz se ponen "a mano", y si en ese proceso, ademas de largo y tedioso, hay algun olvido o equivocacion, luego se percibe como un error de diseño en el juego.
El RT lo que hace es interpretar la escena y decirle a la placa de video "ahora vamos a calcular luz, que viene desde tal direccion, enfoca de esta manera, y rebota de esta otra, y ademas entiende como rebota segun si la superficie es lustrosa o no". El creador del juego se ahorro monton de trabajo. La luz generada es mucho mas realista y se ahorran los posibles errores. Pero el costo de recursos se dispara.
Es eso..., en halo 6 crearon todo el motor para que el desarrollador no tenga que hacer el calculo a mano de cada fuente de luz, algo mas que dificil si calculamos que encima es un entorno abierto. Ese trabajo lo haria el RT, pero como lo que vimos no tiene RT entonces notamos que a todas las texturas les "falta algo" y es la sombra y reflejo de lo que esta cerca. Y ahi esta la duda, tiene Serie X la suficiente potencia para meter un RT a tiempo real completo en esa escena a 4K y mantener los 60 fps, o van a capar el RT a un RT parcial, asi no afectan el rendimiento total de resolucion y fps pero entonces la esperada mejora de texturas por las luces, reflejos y sombras nunca llegaria?Yo comparo el motor de Halo 6 por ejemplo con la demo de UE5 y ahi eligieron el otro camino, renunciaron a todo el RT a cambio de tener flor de geometria y texturas, luego crearon las luces y sombras en todo tiempo real, pero combinandola con algunas pegadas a la textura y sin ningun reflejo, y eso se nota en que por mucho que la luz se acerque a la textura no se ve nada reflejado por ningun lado y la sombra pegada en la textura aun con la luz dandole con todo de frente no termina nunca de desaparecer sino que se "abrillanta" para disimularla. Encima todo ese trabajo supuso un capamiento de resolucion y frames importante al punto de que si quieren subir fps tambien tienen que sacar a lumen. Por logica, RT en ese motor seria inviable. Parece que epic ya renuncio al RT en total tiempo real y se enfoco en texturas y geometria con lumen arriba.
![[facepalm]](/images/smilies/facepalm.gif "facepalm")
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
![[reves]](/images/smilies/nuevos2/delreves.gif "del resves")
Y por eso los personajes tienen una iluminación que no siempre cuadra con la escena y por el mismo motivo en las escenas in-engine lucen mucho mejor: porque la iluminación está controlada. ![[bye]](/images/smilies/nuevos2/adio.gif "adios")
![[triston]](/images/smilies/nuevos/triste_ani2.gif "tristón")
