Hay una idea que arruina más portfolios de los que deberían: la de que la optimización es "un tema técnico aparte", algo que se resuelve al final apretando un par de botones. No. En real-time, la performance no es opcional: es parte del oficio, tanto como la composición o la luz. Una escena que se ve hermosa pero corre a los tirones no está terminada; está a medias. Y esto vale igual para juegos que para virtual production, porque los dos se juegan en el mismo terreno: el motor tiene que dibujar la imagen mientras vos la mirás.
Real-time significa que hay un reloj corriendo
La diferencia entre un render offline y una escena en Unreal es brutal. En offline, si un cuadro tarda horas en calcularse, no importa: lo ves cuando termina. En tiempo real, el motor tiene que armar cada imagen ahora mismo, muchas veces por segundo, sin que vos esperes. Ese es el trato: tenés una cantidad de tiempo fija para cada cuadro, y todo lo que pongas en la escena —geometría, materiales, luces, efectos— se paga dentro de ese tiempo.
A eso se le llama presupuesto de frame: el tiempo que el motor tiene para construir cada imagen antes de mostrar la siguiente. No es un número que yo te vaya a inventar acá, porque depende del proyecto, del hardware objetivo y del framerate que apuntes. Lo importante es la idea: es un presupuesto, y se gasta. Cada asset pesado, cada material caro, cada luz de más, le saca plata a esa billetera. Optimizar es, básicamente, administrar ese presupuesto con criterio en vez de gastarlo a ciegas.
Los conceptos que tenés que tener en la cabeza
No hace falta ser ingeniero para optimizar bien. Hace falta entender de dónde sale el costo. Estos son los conceptos base con los que vas a convivir siempre:
- Draw calls. Cada vez que el motor le pide a la placa que dibuje algo, eso tiene un costo de comunicación. Muchos objetos sueltos, cada uno con su material distinto, disparan un montón de draw calls y ahogan la escena aunque el conteo de polígonos sea bajo. Por eso importa reusar materiales y agrupar geometría en vez de tirar mil piezas independientes.
- LODs (niveles de detalle). Un objeto lejos ocupa poquitos píxeles en pantalla; no tiene sentido dibujarlo con toda su malla de alta. Los LODs son versiones más simples del mismo asset que el motor usa a medida que se aleja. Bien puestos, ahorran muchísimo sin que el ojo lo note.
- Texturas. No es solo cómo se ven: es cuánta memoria de video ocupan. Texturas enormes donde no hacen falta llenan la placa y te penalizan sin dar nada a cambio. Resolución acorde al tamaño real en pantalla, y reuso de materiales, valen oro.
- Culling. El motor tiene formas de no dibujar lo que no se ve —lo que queda fuera de cámara o tapado por otra cosa. Diseñar la escena para que ese descarte funcione a tu favor (en vez de en contra) es media batalla ganada.
Fijate el patrón: casi todo se reduce a no hacerle gastar al motor en cosas que no aportan a la imagen final. Ese es el corazón de la optimización, y es más una forma de pensar que una lista de trucos.
El mito de que Nanite y Lumen te salvan
Con Unreal 5 apareció una idea peligrosa: que con Nanite y Lumen ya no hace falta optimizar, que podés tirar geometría infinita e iluminación dinámica y el motor se arregla. Es media verdad, y las medias verdades en producción se pagan caro.
Nanite cambia la forma en que se maneja la geometría muy densa, y Lumen resuelve iluminación global en tiempo real de un modo que antes era impensado. Son herramientas enormes. Pero no son magia gratis: tienen su propio costo, sus casos donde brillan y sus casos donde no conviene usarlas. No todo tipo de asset se lleva bien con Nanite, y una escena mal pensada puede hacer trabajar de más a Lumen igual que a cualquier otro sistema. Cambian qué optimizás y cómo, no si tenés que hacerlo.
El artista que entiende esto usa las herramientas nuevas con criterio: sabe cuándo apoyarse en ellas y cuándo un método más clásico rinde mejor. El que las trata como excusa para no pensar en performance termina con una escena que se ve moderna y corre mal. Y en un estudio, eso se nota al toque.
La optimización empieza en el diseño de la escena
Acá está la parte que casi nadie te dice: la mejor optimización no es la que hacés al final, es la que ya está tomada en las decisiones de armado. Cuando pensás la escena modular —con piezas que se reusan, materiales compartidos, una estructura que le facilita el trabajo al motor— la mitad del laburo de performance ya viene resuelto de fábrica.
Al revés, si armás todo suelto, con assets únicos por todos lados y materiales distintos en cada objeto, después vas a estar peleándola para exprimir cada milisegundo. Optimizar sobre una escena mal planteada es tapar agujeros; diseñarla bien desde el principio es no hacerlos. Por eso la performance no es el último capítulo de un proyecto: es una decisión que atraviesa todo el flujo, desde el blockout.
Esto también cambia cómo ves tu propio portfolio. Una escena que corre fluida le dice al que la mira algo que ninguna captura linda transmite: que entendés el medio en el que trabajás. Que no hacés imágenes bonitas de casualidad, sino que sabés construir algo que un juego o una producción de verdad podría usar. Esa prolijidad técnica es exactamente lo que separa a un environment de portfolio de uno de producción.
Cómo se aprende esto en serio
La optimización no se aprende leyendo una lista de tips sueltos. Se aprende armando escenas reales, viendo dónde se cae la performance, entendiendo por qué, y corrigiéndolo con criterio —no a los manotazos. Necesitás un recorrido que integre la parte artística y la técnica desde el principio, en vez de tratarlas como mundos separados, porque en producción nunca lo están.
