FiveM oversized assets: reduza texturas .ytd sem perder qualidade

Você liga seu servidor de FiveM e o console se enche de avisos como este: “Asset … uses 76.0 MiB of physical memory. Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).” A maioria dos owners ignora, porque o servidor funciona. Aí os jogadores começam a reclamar de ruas que viram uma papa borrada, prédios que nunca carregam, carros que aparecem como caixas cinzas. É o aviso virando realidade. Este guia explica o que a mensagem significa, quanto é grande demais e como reduzir texture dictionaries .ytd pesados sem deixar seus mapas e carros com pior aparência.

O que o aviso significa

Assim aparece a mensagem no console do servidor. Os nomes dos seus resources vão ser outros:

Asset example_resource/example_props_txd.ytd uses 76.0 MiB of physical memory. Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).
Asset example_vehicle/example_vehicle+hi.ytd uses 24.0 MiB of physical memory.

Leia da esquerda para a direita:

• example_resource é o resource que faz o streaming do arquivo, a pasta dentro do seu diretório resources.
• example_props_txd.ytd é o arquivo em si. Um .ytd é um texture dictionary: um pacote de imagens que o jogo pinta sobre os modelos. Os arquivos +hi.ytd guardam as texturas de alto detalhe de um veículo.
• 76.0 MiB of physical memory é a memória gráfica (VRAM) que o arquivo ocupa depois de carregado. Não é o tamanho em disco, e normalmente é maior.

O servidor imprime a linha quando um resource inicia, então ele avisa do problema antes que qualquer jogador veja. O arquivo continua fazendo streaming. O FiveM só está avisando que todo jogador que chegar perto agora precisa carregar 76 MiB de uma vez.

Por que oversized assets quebram o streaming

O GTA V foi feito para carregar o mundo em pedaços pequenos conforme você se move. Ele mantém um pool de memória limitado para o que está ao seu redor e fica trocando coisas dentro e fora dele. Um único texture dictionary de 76 MiB ocupa sozinho uma boa parte desse pool. Quando vários estão na mesma região do mapa, o jogo fica sem espaço e começa a largar coisas de que ainda precisa. Os jogadores veem isso assim:

• Perda de texturas, também chamada de city bug: ruas, paredes e chão ficam em baixa resolução ou borrados e continuam assim.
• Modelos que não carregam nem renderizam: prédios, props ou interiores que nunca aparecem, ou que surgem segundos atrasados.
• Carros sem texturas ou só com o modelo de baixo detalhe, principalmente numa garagem ou num car meet cheio.
• Travadas e telas de carregamento longas, já que arquivos grandes demoram mais para baixar, ler e enviar à placa de vídeo.

Jogadores com muita VRAM percebem mais tarde do que quem tem uma placa de 4 GB, então o mesmo servidor pode parecer bom para o owner e quebrado para metade dos jogadores.

Physical memory versus virtual memory

Todo arquivo em streaming do GTA V é dividido em duas partes. A memória virtual guarda a estrutura: nomes, formatos, a lista de texturas. A memória physical guarda os dados brutos dos pixels que vão para a placa de vídeo. Num .ytd, quase todo o peso é physical, e esse é o número de que o FiveM avisa.

Quanto é grande demais?

A meta usual, a que a maioria dos desenvolvedores de FiveM segue, é 16 MiB de physical memory por asset. Abaixo disso o FiveM fica quieto. Acima, vem o aviso, e quanto mais você passa, mais prováveis ficam os problemas acima. 16 MiB não é um muro, mas trate como orçamento de cada .ytd.

O tamanho de uma textura na memória depende de só três coisas: a resolução, o formato e os níveis de mip. A tabela mostra uma textura com a cadeia de mips completa:

size        DXT1       DXT5       A8R8G8B8 (uncompressed)
4096x4096   10.7 MiB   21.3 MiB   85.3 MiB
2048x2048    2.7 MiB    5.3 MiB   21.3 MiB
1024x1024    0.7 MiB    1.3 MiB    5.3 MiB
 512x512     0.2 MiB    0.3 MiB    1.3 MiB

Ou seja, uma única textura 4096×4096 em DXT5 já custa 21,3 MiB, mais que o orçamento inteiro. Um pack de mapa com três delas, algumas normal maps e umas texturas de acabamento cai bem nos 76 MiB do exemplo acima. Uma textura 4K sem compressão é ainda pior, com 85,3 MiB sozinha. A maioria dos oversized assets são só texturas 4K que ninguém precisava em 4K.

Encontre todos os oversized assets do seu servidor

O console só mostra o aviso enquanto o servidor inicia, no meio de todo o resto, e é fácil deixar um passar. Há duas opções melhores.

1. Procure MiB of physical memory no log do console. Cada resultado traz o resource e o arquivo. Uma busca por Oversized assets perde os arquivos entre 16 e 48 MiB, cuja linha termina depois do tamanho.
2. Deixe o Asset Doctor fazer isso. Ele lê cada resource do seu servidor pelo resource da FiveDock e lista todo texture dictionary acima de 16 MiB, com a memória gráfica ao lado do tamanho em disco.

example_resource  stream/example_props_txd.ytd
  this texture dictionary allocates 76.0 MiB of graphics memory (61.2 MiB on disk),
  more than the 16.0 MiB a pack should stay under

O Asset Doctor também marca os modelos que dois packs fazem streaming ao mesmo tempo e os resources que nunca iniciam, então uma varredura cobre os motivos de sempre para um mapa ou carro aparecer errado. Se dois packs trazem o mesmo arquivo de mapa, o guia de conflitos de mapas explica o que isso quebra.

Reduza texturas .ytd sem perder qualidade

Cada textura de um .ytd é guardada várias vezes: em tamanho total, depois pela metade, um quarto, um oitavo e assim por diante até poucos pixels. Essas cópias são os níveis de mip. O jogo escolhe o nível que corresponde ao tamanho da superfície na tela. Uma parede a 20 metros recebe um mip pequeno, e o de tamanho total só é usado quando você cola a cara nela.

Isso dá um jeito de reduzir uma textura sem mexer nos pixels dela: tirar os maiores níveis de mip. Uma textura de 4096×4096 sem os dois primeiros níveis vira uma textura de 1024×1024 cujos pixels são exatamente os que o jogo já mostrava de qualquer distância normal. Nada é redimensionado, recomprimido ou recodificado, então não surge desfoque novo nem artefatos de bloco. Cada nível removido corta a memória para cerca de um quarto.

Lembre de quanta tela existe. Num monitor 1920×1080, até uma parede que ocupa a visão toda nunca mostra mais que uns 2000 pixels de largura, então uma textura 4K num poste ou na porta de um carro é memória gasta num detalhe que nenhum jogador enxerga.

O jeito manual e a pegadinha

Sem uma ferramenta, a correção é assim:

1. Abra o .ytd no OpenIV ou no CodeWalker e exporte todas as texturas.
2. Redimensione as grandes num editor de imagem.
3. Salve de novo como DDS, escolhendo o formato DXT certo e gerando mip maps novos.
4. Importe de volta, salve o .ytd e reinicie.

Funciona, mas salvar em DXT comprime a imagem uma segunda vez, e cada passada acrescenta artefatos, principalmente em normal maps e texto. Num servidor com algumas centenas de carros e uma dúzia de mapas, também são dias de trabalho.

Reduza com o Stream Optimizer

O Stream Optimizer do app desktop da FiveDock aplica o truque dos níveis de mip em todos os .ytd de uma pasta de uma vez. Ele corta as texturas pesadas até o maior nível de mip que cabe no seu limite e deixa o resto dos dados de pixel byte a byte como estava.

1. Abra Otimizador de stream no app desktop e escolha um resource, ou a pasta resources inteira.
2. Escolha uma predefinição (veja abaixo) e uma pasta para os originais.
3. Clique em Analisar. Você vê cada arquivo que seria alterado, cada textura com o tamanho antes e depois, e quanta memória de jogo você economiza.
4. Clique em Otimizar e reinicie o servidor.

A mesma coisa pela linha de comando, com o arquivo do aviso acima:

> fivedock optimize C:\server\resources\example_resource
1 .ytd file under C:\server\resources\example_resource, textures over 1024px
  stream\example_props_txd.ytd  76.0 MiB -> 12.0 MiB
      example_wall_d  4096x4096 -> 1024x1024  DXT5
      example_wall_n  4096x4096 -> 1024x1024  DXT5
      example_floor_d  4096x4096 -> 1024x1024  DXT1
      example_floor_n  4096x4096 -> 1024x1024  DXT1
      example_trim_d  2048x2048 -> 1024x1024  DXT5
      kept example_sign_emis  2048x2048  emissive
Would free 64.0 MiB of game memory. Nothing was written; add --apply --backup <dir>.

Uma análise não grava nada. Adicione --apply --backup <dir> para gravar os arquivos menores e manter os originais nessa pasta. Neste exemplo o arquivo vai de 76,0 MiB para 12,0 MiB, abaixo do orçamento de 16 MiB, e o aviso some na próxima inicialização.

Qual predefinição escolher

• Seguro não redimensiona nada. Só corrige as texturas script_rt comprimidas, de que o FiveM também reclama.
• Leve mantém texturas de até 2048 px. Bom para assets de destaque que os jogadores olham de perto, como uma concessionária ou uma placa de menu.
• Equilibrado mantém texturas de até 1024 px. É o padrão e a escolha certa para a maioria dos mapas, props e carros.
• Desempenho mantém texturas de até 512 px. Para props de fundo e servidores cujos jogadores têm placas de vídeo mais antigas.

Comece com Equilibrado, passe de carro pelo que mudou e suba para Leve nos poucos assets em que você notar diferença.

O que ele nunca toca

• Render targets (script_rt_* e scr_*) mantêm o tamanho, porque scripts desenham neles numa resolução exata. Os comprimidos viram texturas sem compressão do mesmo tamanho, como o FiveM exige.
• Texturas emissivas: nomes com emis, glow, neon ou terminando em _em mantêm o tamanho, já que padrões de luz e letreiros de neon mostram cada pixel perdido.
• Texturas que já estão abaixo do limite e qualquer coisa num formato que ele não conhece ficam exatamente como estão.

Diminua os lodDistances dos carros addon

Nos veículos, as texturas são só metade da história. Cada carro em vehicles.meta tem uma lista lodDistances: as distâncias, em metros, em que ele troca do modelo de alto detalhe para modelos mais simples, e o último valor é a que distância ele chega a ser desenhado. Muitos carros addon vêm com valores bem acima dos do jogo base, então todo carro numa rua movimentada fica em detalhe total, +hi.ytd incluso, a centenas de metros.

<Item>
  <modelName>example_car</modelName>
  <lodDistances content="float_array">
    40.000000
    80.000000
    200.000000
    400.000000
    1000.000000
    1000.000000
  </lodDistances>
</Item>

Marque Otimizar distância de LOD no Stream Optimizer, ou passe --lod na linha de comando. Cada valor é reduzido para no máximo 15, 30, 70, 140, 250 e 250 metros, perto do jogo base. Um valor que já é menor nunca é aumentado, e só os números do arquivo mudam.

> fivedock optimize C:\server\resources\example_vehicle --lod --no-textures
1 .meta file with lodDistances
  data\vehicles.meta  example_car  40 / 80 / 200 / 400 / 1000 / 1000 -> 15 / 30 / 70 / 140 / 250 / 250
Nothing was written; add --apply --backup <dir>.

Perguntas frequentes

Um oversized asset derruba meu servidor?

Não. O servidor só envia o arquivo. O custo é pago pelo jogo de cada jogador, e aparece como perda de texturas, modelos faltando e crashes no cliente, mais seguido em placas com pouca VRAM.

16 MiB é um limite rígido?

Não, um arquivo de 20 MiB costuma fazer streaming bem sozinho. O problema vem de muitos arquivos pesados no mesmo lugar. 16 MiB por .ytd é o orçamento que te mantém seguro em qualquer mapa, com qualquer quantidade de jogadores por perto.

A partir de que tamanho o FiveM avisa sobre oversized assets?

O FXServer verifica cada arquivo em streaming quando o resource inicia e imprime Asset <resource>/<file> uses <size> MiB of physical memory. para qualquer arquivo acima de 16 MiB, em azul acima de 16 MiB, em amarelo acima de 32 MiB e em vermelho acima de 64 MiB. A frase “Oversized assets can and WILL lead to streaming issues (such as models not loading/rendering).” só é acrescentada acima de 48 MiB. A mesma verificação roda na virtual memory do arquivo, e aí a linha termina em of virtual memory.. Os limites estão no ResourceStreamComponent.cpp do FXServer.

E se o aviso citar um arquivo .yft ou .ydr?

Aí as texturas estão embutidas no arquivo do modelo. O Stream Optimizer só lê arquivos .ytd, então mova antes as texturas para um .ytd separado no OpenIV ou no CodeWalker, ou peça ao autor uma versão mais leve.

Os jogadores precisam fazer alguma coisa?

Não. Depois que você reinicia, os arquivos alterados têm um hash novo, e cada jogador baixa a versão menor na próxima vez que entrar.

Qual plano tem

O Stream Optimizer está em todos os planos, no app desktop e no CLI. Tudo roda na sua máquina, e seus arquivos nunca saem dela. O Asset Doctor faz parte do plano Metro e vigia seu servidor no ar atrás de novos oversized assets, para que o próximo pack de carros em 4K seja pego antes de os seus jogadores acharem. Compare os planos ou veja todos os recursos.