Optimización en PC para juegos de Unreal Engine 5: ajustes, VRAM y requisitos

El rendimiento de un juego de Unreal Engine 5 en PC depende de unas pocas decisiones: la resolución interna a la que pinta el juego (la fija el modo del reescalador), la calidad de la iluminación global y de las sombras, los efectos volumétricos como las nubes y la niebla, y hasta dónde dibuja el detalle. La memoria de vídeo es otro límite aparte: cuando se agota, los fotogramas por segundo se hunden por rápida que sea la GPU. Esta guía explica cada palanca, cómo leer los requisitos de un juego y qué aprendimos midiendo un planeta entero en COLONIZED.

Los ajustes que importan, por orden

Ajuste	Qué cambia	Impacto	Qué hacer primero
Modo del reescalador (DLSS, TSR)	La resolución interna	La palanca más grande	DLSS Calidad o DLAA en tarjetas RTX, TSR en las demás; baja el modo antes que la resolución de salida
Iluminación global (Lumen)	Cómo rebota la luz	Alto: Epic presupuesta unos 4 ms por fotograma para 60 fps en consola	Bajar un nivel reduce su coste a más o menos la mitad
Sombras	Resolución y distancia de las sombras	Alto en escenas abiertas y soleadas	Baja un nivel; mantén nítidas las sombras del sol si puedes
Nubes y niebla volumétricas	Cielo y atmósfera	Alto en altura o con clima denso	Baja la calidad antes que apagarlas
Distancia de dibujado y vegetación	Hasta dónde llegan el detalle y la vegetación	Medio o alto en mundos abiertos	Reduce la densidad antes que la distancia
Texturas	Detalle de superficies	Bajo en fotogramas, alto en memoria de vídeo	Ajústalas a la VRAM de tu tarjeta
Generación de fotogramas	Fotogramas extra generados	Más fluidez, más latencia	Solo a partir de una tasa ya jugable; lee nuestra guía de DLSS

Dos reglas facilitan el uso de la tabla. Cambia un ajuste cada vez y mide en el mismo sitio, porque el cielo, la hora del día y la cantidad de objetos en pantalla pueden mover el tiempo de fotograma varios milisegundos. Y prefiere reescalar con calidad a bajar la resolución: reconstruir desde una resolución interna menor casi siempre se ve mejor que una salida borrosa.

Por qué se agota la memoria de vídeo

La memoria de vídeo (VRAM) guarda todo lo que la GPU necesita para pintar un fotograma: texturas, geometría, mapas de sombras, los búferes de historial de los reescaladores temporales, los datos de escena de la iluminación global y decenas de reservas internas. Cuando el total deja de caber, el controlador empieza a mover datos a la memoria del sistema y de vuelta, y el tiempo de fotograma se vuelve errático.

Lo habitual es pensar que el problema son las texturas. Muchas veces solo son una parte. En la escena de prueba planetaria que contamos más abajo, el proceso decía tener 3.774 MB de «texturas», y solo 667,6 MB, el 17,7 %, eran arte de verdad. El resto era andamiaje del motor: objetivos de renderizado, búferes de historial, datos de iluminación global y texturas que nadie podía ver a esa resolución.

Cómo leer los requisitos del sistema

• Mínimos suele significar que el juego funciona en un ajuste bajo, a 1080p o con mucho reescalado, a unos 30 fps. Recomendados suele significar una experiencia cómoda en un ajuste más alto. Si la editora no indica resolución y fotogramas por segundo, tómalos como orientativos.
• La memoria de vídeo es la primera línea que hay que leer en 2026: suele ser el primer muro con el que choca un mundo abierto grande, antes que la velocidad bruta de la GPU.
• El tipo de almacenamiento importa más que antes. Los motores que cargan geometría y texturas de forma continua, como hace Nanite, recomiendan un SSD.
• El reescalador forma parte del requisito. Muchos requisitos recomendados dan por hecho que DLSS, TSR o una tecnología parecida están activados.

Un caso real: un planeta, medido

COLONIZED es un MMORPG de supervivencia espacial en desarrollo, hecho con Unreal Engine 5.8, y un planeta que se recorre del suelo a la órbita es de lo más difícil de hacer funcionar bien. Estas cifras salen de nuestra build de desarrollo, medidas a 3440×1440 nativos en una RTX 5070 Ti de 16 GB. Son medidas de desarrollo, no requisitos del sistema.

Memoria de vídeo: de 12.480 a 5.256 MB

El primer diagnóstico salió del volcado de memoria del propio motor en el momento en que la escena se pasó de presupuesto por primera vez: los búferes de vértices eran el 56 % de todo lo que había reservado el renderizador, y las texturas 2D, menos del 2 %. El problema no era el arte ni los efectos: era la geometría del terreno, mal empaquetada.

Medida	Antes	Después
Memoria de vídeo del proceso	12.480 MB	5.256 MB (sin bajar ninguna textura)
Memoria del sistema del proceso	39.873 MB	unos 15.500 MB
Trozos de terreno vivos	2.055	752
Triángulos de terreno	69,4 millones	25,4 millones
Memoria por trozo de terreno	5,80 MiB	0,72 MiB

Lo que movió las cifras:

• Geometría indexada. El camino por defecto del componente de malla dinámica subía tres vértices por triángulo. Indexarlo, que es exacto porque los trozos no tienen costuras de atributos, dividió casi por seis los vértices que se suben.
• Un recorte de horizonte que no funcionaba donde se juega. Por debajo de 500 metros de altura, el terreno mallaba la esfera entera, incluida la cara opuesta del planeta, a 1.570 km.
• Dos texturas de cielo de 384 MB cada una. Un volcado de recursos con una fila por reserva descubrió que los cubemaps del firmamento y de la nebulosa tenían 8.192 × 8.192 píxeles por cara y ningún mipmap: más memoria que todo el terreno. A nuestra resolución y campo de visión, 4.096 ya es un texel por píxel. Limitar el cielo ahorró 975 MB.
• Cinco reservas de memoria que nadie había decidido. El historial del reescalador temporal, la carga de Nanite, la niebla volumétrica, el atlas de la iluminación global y las capturas de reflejos iban con los valores por defecto del motor. Dimensionarlas para el juego ahorró 770 MB.
• Detalles menores: un búfer de índices de 16 bits compartido por todos los trozos (290 MB) y sacar las rocas y plantas dispersas de la escena de campos de distancia que no necesitaban (312 MB).

Nubes: de 15,5 a 3,5 ms, sin reescalador

Nuestras nubes volumétricas costaban unos 15,5 ms por fotograma al empezar su campaña de optimización y 3,5 ms al terminarla, a resolución nativa. Desde el principio hubo dos reglas fijas: no bajar las muestras por rayo, porque las nubes se veían pixeladas, y no usar el reescalador como arreglo, porque reescalar es una opción del jugador, no nuestra solución. El ahorro salió de un mapa de clima más pequeño, una reproyección temporal con el borde limpio y menos muestras en los rayos de sombra de las nubes, todo comprobado con capturas con el sol rasante.

Una pradera: de 22,9 a 11-12 ms de GPU

Una escena de pradera extensa pasó de 22,94 ms de tiempo de GPU (mediana) a 11,1-12,4 ms, según el cielo, sin cambiar el aspecto aprobado. La mayor ganancia individual fue activar el descarte por oclusión de instancias: −5,16 ms, cinco veces lo que habíamos calculado, porque en un terreno de lomas casi todas las instancias quedan tapadas por el relieve. La segunda fue recuperar un ajuste de la hierba que se había revertido sin que nadie lo viera, y que bajó la alfombra vegetal de 2,61 a 0,14 ms.

Lo que aprendimos

• Mide por parejas. Las cifras absolutas entre dos arranques no se pueden comparar: solo el cielo las mueve unos 3 ms. Solo las pruebas A/B emparejadas, o deshacer un cambio y ver volver el coste, dicen la verdad.
• Lee el volcado de memoria antes de suponer. Dos hipótesis «evidentes» (que las instancias de nivel colocadas costaban gigas y que una reserva de carga de texturas más pequeña libera memoria) eran falsas: las dos valían cero.
• Bajar puede subir la calidad. La memoria que liberan los mapas que nadie puede apreciar puede pagar texturas de suelo de más calidad, la superficie que ocupa el 80 % de la pantalla.
• Aún no hemos medido con honestidad una tarjeta de 8 GB. Toda la campaña se hizo a 3440×1440, y el motor no puede simular el presupuesto de memoria de una tarjeta más pequeña. Medir a 1080p y en tarjetas menores va antes de publicar ningún requisito.

Qué significa para los requisitos de COLONIZED

No se han publicado, y no los publicaremos hasta haberlos medido en las tarjetas que tiene la gente de verdad. Cuando la solicitud de la alfa cerrada pregunta por tu CPU, tu GPU y tu RAM, es para eso. Las tecnologías que hay detrás de estas cifras se explican en Nanite y Lumen explicados y en DLSS, generación de fotogramas y Reflex explicados.