Otimização de PC para jogos em Unreal Engine 5: configurações, VRAM e requisitos

A otimização de PC para jogos em Unreal Engine 5 gira em torno de poucas decisões: a resolução interna em que o jogo renderiza (definida pelo modo do upscaler), a qualidade da iluminação global e das sombras, os efeitos volumétricos, como nuvens e neblina, e até onde o jogo desenha detalhes. A memória de vídeo é um limite à parte: quando ela acaba, a taxa de quadros desaba, por mais rápida que seja a GPU. Este guia explica cada alavanca, como ler os requisitos de sistema de um jogo e o que aprendemos medindo um planeta inteiro em COLONIZED.

As configurações que importam, em ordem

Configuração	O que muda	Impacto	O que fazer primeiro
Modo do upscaler (DLSS, TSR)	A resolução interna	A maior alavanca isolada	Use DLSS Qualidade ou DLAA em placas RTX e TSR nas demais; reduza o modo antes de reduzir a resolução de saída
Iluminação global (Lumen)	Como a luz rebate	Alto: a Epic reserva cerca de 4 ms por quadro para 60 FPS em console	Descer um nível reduz o custo aproximadamente à metade
Sombras	Resolução e distância das sombras	Alto em cenas abertas e ensolaradas	Desça um nível; mantenha nítidas as sombras do sol, se puder
Nuvens e neblina volumétricas	Céu e atmosfera	Alto em altitude ou com clima pesado	Reduza a qualidade antes de desligar
Distância de visão e vegetação	Até onde chegam os detalhes e a vegetação	Médio a alto em mundos abertos	Reduza a densidade antes da distância
Texturas	Detalhe das superfícies	Baixo nos FPS, alto na memória de vídeo	Ajuste à VRAM da sua placa
Geração de quadros	Quadros extras gerados	Mais fluidez, mais latência	Só a partir de uma taxa de quadros já jogável; veja nosso guia de DLSS

Duas regras práticas facilitam o uso da tabela. Mude uma configuração por vez e meça sempre no mesmo lugar, porque o céu, a hora do dia e o número de objetos na tela podem alterar o frame time em vários milissegundos. E prefira o upscaling de qualidade à resolução menor: reconstruir a partir de uma resolução interna mais baixa quase sempre fica melhor que uma saída borrada.

Por que a memória de vídeo acaba

A memória de vídeo (VRAM) guarda tudo o que a GPU precisa para desenhar um quadro: texturas, geometria, mapas de sombra, os buffers de histórico dos upscalers temporais, os dados de cena da iluminação global e dezenas de pools internos. Quando o total deixa de caber, o driver começa a mover dados para dentro e para fora da memória do sistema, e o frame time fica irregular.

A suposição comum é que as texturas são o problema. Muitas vezes são só uma parte. Na cena de teste de planeta que descrevemos abaixo, o processo registrou 3.774 MB de “texturas”, e apenas 667,6 MB delas, 17,7%, eram arte de verdade. O resto era andaime do motor: render targets, buffers de histórico, dados de iluminação global e texturas que ninguém conseguia ver naquela resolução.

Como ler os requisitos de sistema

• Mínimo costuma significar que o jogo roda em predefinição baixa, em 1080p ou com upscaling pesado, a cerca de 30 FPS. Recomendado costuma significar uma experiência confortável em predefinição mais alta. A menos que a publisher informe resolução e taxa de quadros, trate ambos como aproximados.
• A memória de vídeo é a linha a ler primeiro em 2026: costuma ser a primeira parede que um grande mundo aberto encontra, antes da velocidade bruta da GPU.
• O tipo de armazenamento importa mais do que antes. Motores que transmitem geometria e texturas continuamente, como faz o Nanite, recomendam um SSD.
• O upscaler faz parte do requisito. Muitas especificações recomendadas pressupõem que DLSS, TSR ou uma tecnologia parecida esteja ativada.

Um caso real: um planeta, medido

COLONIZED é um MMORPG de sobrevivência espacial em desenvolvimento, feito em Unreal Engine 5.8, e um planeta que você percorre do solo até a órbita é uma das coisas mais difíceis de fazer rodar bem. Estes números vêm da nossa build de desenvolvimento, medidos a 3440×1440 nativo em uma RTX 5070 Ti de 16 GB. São medições de desenvolvimento, não requisitos de sistema.

Memória de vídeo: de 12.480 MB para 5.256 MB

O primeiro diagnóstico veio do dump de memória do próprio motor, no momento em que a cena estourou o orçamento pela primeira vez: os vertex buffers eram 56% de tudo o que o renderizador tinha alocado, e as texturas 2D, menos de 2%. O problema não era a arte nem os efeitos: era a geometria do terreno mal empacotada.

Métrica	Antes	Depois
Memória de vídeo do processo	12.480 MB	5.256 MB (nenhuma textura rebaixada)
Memória do sistema do processo	39.873 MB	cerca de 15.500 MB
Chunks de terreno ativos	2.055	752
Triângulos do terreno	69,4 milhões	25,4 milhões
Memória por chunk de terreno	5,80 MiB	0,72 MiB

O que mudou os números:

• Geometria indexada. O caminho padrão do componente de malha dinâmica enviava três vértices por triângulo. Indexá-la, o que é exato porque os chunks não têm costuras de atributos, reduziu o envio de vértices em quase seis vezes.
• Um horizon cull desligado justamente onde as pessoas jogam. Abaixo de 500 metros de altitude, o terreno gerava a malha da esfera inteira, inclusive o outro lado do planeta, a 1.570 km de distância.
• Duas texturas de céu de 384 MB cada. Um dump de recursos com uma linha por alocação mostrou que os cubemaps do campo de estrelas e da nebulosa tinham 8.192 × 8.192 pixels por face, sem mipmaps: mais memória que o terreno inteiro. Na nossa resolução e campo de visão, 4.096 já equivale a um texel por pixel. Limitar o céu economizou 975 MB.
• Cinco pools de memória que ninguém havia decidido. O histórico do upscaler temporal, o streaming do Nanite, a neblina volumétrica, o atlas de iluminação global e as capturas de reflexo estavam nos padrões do motor. Dimensioná-los para o jogo economizou 770 MB.
• Detalhes menores: um index buffer de 16 bits compartilhado por todos os chunks (290 MB) e a retirada das rochas espalhadas da cena de distance field, de que elas não precisavam (312 MB).

Nuvens: de 15,5 ms para 3,5 ms, sem upscaler

Nossas nuvens volumétricas custavam cerca de 15,5 ms por quadro no início da campanha de otimização e 3,5 ms no fim, em resolução nativa. Duas regras ficaram fixas desde o começo: nada de menos amostras por raio, porque as nuvens ficavam pixeladas, e nada de upscaler como solução, porque o upscaling é escolha do jogador, não o nosso remédio. A economia veio de um mapa de clima menor, de reprojeção temporal com borda limpa e de menos amostras nos raios de sombra das nuvens, tudo conferido contra capturas com luz baixa e rasante.

Um campo de grama: de 22,9 ms para 11–12 ms de tempo de GPU

Uma cena grande de gramado passou de 22,94 ms de tempo de GPU (mediana) para 11,1–12,4 ms, dependendo do céu, sem mudar o visual aprovado. O maior ganho isolado foi ativar o instance occlusion culling: −5,16 ms, cinco vezes o que havíamos estimado, porque em colinas suaves a maioria das instâncias fica escondida atrás do terreno. O segundo foi restaurar uma configuração de grama que havia revertido sem aviso, o que levou a cobertura do solo de 2,61 ms para 0,14 ms.

O que aprendemos

• Meça em pares. Números absolutos de duas execuções não são comparáveis: só o céu os move em cerca de 3 ms. Só testes A/B pareados, ou desfazer uma mudança e ver o custo voltar, dizem a verdade.
• Leia o dump de memória antes de chutar. Duas hipóteses “óbvias” (que instâncias de nível colocadas custavam gigabytes e que um pool menor de streaming de texturas liberava memória) estavam erradas; ambas valiam zero.
• Reduzir pode aumentar a qualidade. A memória liberada ao limitar mapas que ninguém consegue resolver pode pagar texturas de solo de maior qualidade, a superfície que cobre 80% da tela.
• Ainda não medimos uma placa de 8 GB de forma honesta. Toda a nossa campanha rodou a 3440×1440, e o motor não consegue simular o orçamento de memória de uma placa menor. Medir em 1080p e em placas menores vem antes de publicarmos qualquer requisito.

O que isso significa para os requisitos de COLONIZED

Eles não foram publicados, e não os publicaremos até medi-los nas placas que as pessoas realmente têm. Quando a solicitação do alpha fechado pergunta sobre sua CPU, sua GPU e sua RAM, é para isso que serve. As tecnologias por trás desses números são explicadas em Nanite e Lumen explicados e em DLSS, Frame Generation e Reflex explicados.