Pool de Streaming de Texturas do UE5 Estourou: Como Diagnosticar e Corrigir

Resposta direta: corrija "Pool de Streaming de Texturas Acima do Orçamento" sem esconder a causa

"Pool de Streaming de Texturas Acima do Orçamento" significa que o streamer de texturas da Unreal quer mais memória de texturas do que o pool atualmente permite para a cena e visualização. Comece com STAT STREAMING, reproduza o aviso do mesmo caminho da câmera e identifique se o excesso vem de mips de textura superdimensionados, mips ausentes ou inutilizáveis, ativos Never Stream, alocações inesperadas não relacionadas a streaming ou um orçamento de pool que é realmente pequeno demais para o hardware alvo. Use r.Streaming.PoolSize apenas como variável de teste medida. Não escolha um valor universal de megabyte nem aumente o pool até que o aviso desapareça.

A solução duradoura é uma decisão de conteúdo e plataforma: definir um orçamento de memória de texturas para cada classe alvo, tornar as texturas caras streamáveis, reduzir a resolução apenas onde o resultado visual sobrevive, preservar as cadeias MIP e compressão necessárias, e então validar a mesma rota representativa no editor, PIE, standalone e uma build empacotada. Texturização Virtual pode ajudar cargas de trabalho grandes ou em camadas específicas, mas não é uma substituição automática para o diagnóstico do streaming de texturas convencional.

Checklist de triagem rápida

1. Reproduza o aviso a partir de um mapa nomeado, rota da câmera, resolução, nível de escalabilidade e RHI alvo.
2. Execute STAT STREAMING e capture o pool, pool necessário, mips visíveis, mips ocultos, mips forçados e valores não streaming.
3. Inspecione as maiores texturas contribuintes antes de mudar as configurações do projeto.
4. Teste uma alteração de cada vez: dimensões de textura, disponibilidade de mip, viés LOD ou grupo de textura, compressão, Never Stream, uso de material ou tamanho do pool.
5. Reexecute a mesma rota da câmera e compare memória, qualidade de imagem, pop-in e ritmo de quadros.
6. Confirme o resultado em uma build independente ou empacotada em dispositivos representativos de baixa memória, média e alta.

O que o aviso realmente mede

O streamer de texturas da Unreal seleciona quais mips devem permanecer residentes para as visualizações atuais, respeitando um pool de memória. O pool não é simplesmente "todas as texturas coloridas visíveis." O Texture Streaming Configuration da Epic observa que r.Streaming.PoolSize é expresso em megabytes e que o pool de texturas pode incluir texturas de interface, texturas NeverStream, cubemaps e, em algumas plataformas, recursos de GPU que não sejam texturas. Por isso, um aviso pode persistir mesmo quando as texturas mais próximas da câmera parecem normais.

O aviso é um sinal de orçamento, não uma prova de um ativo ruim em particular. Uma cena pode exceder seu orçamento porque vários conjuntos de texturas individualmente razoáveis se tornam residentes juntos, porque uma câmera cinematográfica torna muitos mips de alto detalhe desejáveis, porque um ativo não tem cadeia de mip utilizável ou porque alocações não relacionadas ao streaming consomem headroom. Por outro lado, um pool maior pode ser correto quando o pool existente é menor do que o orçamento medido disponível no hardware de envio. A decisão deve estar atrelada a um perfil de plataforma e a uma carga de trabalho reproduzível.

Não confunda esse aviso com um crash genérico de GPU fora de memória. O streamer pode estar sobre o pool solicitado enquanto o processo ainda está em rodamento. Ele responde descartando os mips desejados, o que pode causar texturas borradas, mudanças tardias nos detalhes, residência instável ou avisos repetidos do pool. Um crash, remoção de dispositivo ou exaustão mais ampla da memória de renderização exige uma investigação mais ampla da memória da GPU.

Diagnostice o aviso com STATIC STREAMING

Abra o mapa afetado, coloque a câmera na rota que está falhando, espere o carregamento estabilizar e execute:

STAT STREAMING

Os documentos Texture Streaming Metrics da Epic STAT STREAMING como a visão principal do desempenho do streaming de texturas e contadores de memória. Capture após uma carga fria e novamente após a travessia representativa; uma única captura de tela do editor ocioso pode perder o pico. Mantenha a versão do motor, resolução da tela, nível de escalabilidade, modo viewport do editor e RHI com a captura para que outro desenvolvedor possa repetir.

Leia os grupos como um mapa de causas, em vez de caçar um número vermelho:

• Mips exigidos ou desejados excedem o pool de streaming: A visualização atual pede mais detalhes transmitidos do que o orçamento permite. Ordenar texturas grandes, inspecionar as dimensões desejadas e comparar a política de grupos de texturas.
• Mips forçados são altos: ativos, componentes, cinemáticas ou código podem forçar residência. Encontre configurações residentes na Força e prove que são necessárias para a tomada ou jogabilidade.
• NonStreaming Mips estão altos: memória fora da residência streamable normal está consumindo headroom. Inspecione Never Stream, UI, cubemaps, alvos de renderização e outras alocações antes de levantar o pool.
• Mips visíveis aumentam apenas em uma rota específica: distância da câmera, campo de visão, oclusão ou um aglomerado denso de materiais impulsionam o pico. Perfile esse roteamento e reduza a demanda simultânea de alta resolução.
• O aviso aparece apenas após viagens repetidas: referências obsoletas, caches quentes ou comportamento do ciclo de vida podem estar envolvidos. Compare um lançamento limpo, viagens repetidas e desmontagem com a mesma sequência de teste.

Os nomes exatos dos contadores e o layout podem mudar entre as versões do Unreal. Use o seletor de versões da documentação Epic que corresponda ao projeto e grave o resultado completo, em vez de copiar um limite de uma captura de tela do fórum.

Encontre os assets e configurações que criam o pico

Comece com evidências da visão que falha, depois inspecione os assets mais prováveis de explicá-la. Verificações úteis incluem dimensões de textura, formato de pixel, configuração de compressão, grupo de texturas, viés LOD, configuração de geração MIP, número de mips, Never Stream e todo caminho de material ou interface que referenciam a textura. Uma textura 4K não está automaticamente errada; ela está errada quando seu detalhe residente custa mais do que sua contribuição visual mensurável na visualização e hardware alvo.

Para ativos importados de FBX, GLB, OBJ, USD, escaneamento ou gerados por IA, mantenha a transferência completa visível: Upload ou Importar → Prévia → Corrigir → Otimizar → Converter → Exportar → validação do Unreal. Verifique se os pacotes fonte não anexaram múltiplos mapas 4K quase idênticos, incorporaram materiais não utilizados, exportaram uma máscara como uma textura de cor não comprimida ou omitiram dimensões prontas para MIP. A limpeza pré-importação reduz o ruído, mas a decisão final de residência ainda precisa ser verificada no Unreal porque materiais, grupos de texturas, regras de streaming e perfis de plataforma são nativos do projeto.

Dê atenção especial a essas causas profundas:

• Resolução da fonte sobredimensionada: a textura contém detalhes que o ativo nunca apresenta na tela. Compare o tamanho máximo projetado na rota real da câmera antes de reduzi-lo.
• Geração de mip ausente ou desativada: o streamer não pode selecionar níveis de detalhamento mais baratos e baixos. Corrija a política de importação ou geração de mip e inspecione a qualidade à distância.
• Política de grupo de textura inadequada ou LOD: um grupo amplo pode manter mais detalhes do que essa classe de ativos precisa. Prefira uma política de grupo de propriedade a exceções dispersas por ativo.
• Tipo de compressão ou semântico errado: normais, máscaras, dados HDR, UI e texturas de cor têm requisitos diferentes. Selecione compressão pelo significado dos dados, não apenas pela extensão do arquivo.
• Never Stream ou residência forçada: reserve esses ativos para ativos que realmente exigem residência estável e detalhada. Remova-os somente após verificar se não há necessidade de interface, cinemática ou jogabilidade.
• Referências duplicadas ou não usadas: instâncias de material, malhas ocultas, variantes ou conteúdo obsoleto podem manter texturas evitáveis relevantes. Remova referências por meio de revisão normal de controle de versão, então cozinhe e teste novamente.

Corrija a causa raiz na ordem correta

Use a menor alteração reversível que aborde a causa medida. Essa ordem mantém a qualidade visual e as limitações da plataforma visíveis.

1. Congele a linha de base. Salve a captura falhada STAT STREAMING captura, rota, identidade de construção, configuração do pool e capturas de tela em pontos de vista comparativos.
2. Disponibilidade de mip reparada. Garantir que as texturas de mundo streamáveis tenham cadeias de mip válidas e que a geração de mip não tenha sido desativada acidentalmente. Reimportar apenas de um ativo de código fonte controlado.
3. Tamanho correto das texturas mais pesadas. Reduzir dimensões ou aplicar viés LOD onde a câmera alvo não conseguir resolver o detalhe removido. Verifique objetos heróis e closes separadamente dos recursos de fundo.
4. Política correta de grupo e compressão. Coloque ativos relacionados sob um grupo de texturas deliberado e compressão adequada aos dados. Verifique novamente o tamanho do pacote, memória e artefatos visíveis.
5. Remover residência forçada injustificada. Auditoria Never Stream e comportamento de residente forçado, depois teste cinemáticas, interface, giros rápidos e casos de teletransporte para pop-in inaceitável.
6. Reduzir a demanda simultânea. Dividir conjuntos de materiais excessivamente densos, remover mapas duplicados, simplificar variantes distantes ou alterar a composição de nível quando muitas texturas de alto custo se tornarem necessárias ao mesmo tempo.
7. Avalie o pool por último. Se o conteúdo otimizado ainda se encaixar no orçamento GPU-memória medido pelo hardware com headroom seguro, defina deliberadamente um pool específico para a plataforma e documente o motivo.

Durante o diagnóstico, você pode alterar o valor de execução como experimento:

r.Streaming.PoolSize 1500

Esse número é um comando de exemplo, não é um valor de produção recomendado. Uma troca de console é temporária e ajuda a responder "será que mais margem de pool removeria essa pressão específica?" A configuração persistente pertence à configuração revisada do projeto e à estratégia de perfil do dispositivo. O valor correto varia conforme a plataforma, memória da GPU, resolução, outros recursos de renderização e o pico da cena. Teste dispositivos com baixa memória primeiro; uma estação de trabalho editor pode ocultar uma escolha de envio insegura.

Decida quando a Texturização Virtual é relevante

O streaming de texturas convencional e a Texturização Virtual resolvem problemas de residência sobrepostos, mas diferentes. A visão geral Visão Geral de Streaming de Textura da Epic explica o fluxo de trabalho convencional do streamer; Texturização Virtual em Tempo de Execução e Texturização Virtual em Streaming introduzem suas próprias considerações de produção de tiles, feedback, material, cache e plataforma. Não ative a texturização virtualizada apenas porque apareceu um aviso convencional de pool.

Texturização Virtual merece uma avaliação separada quando a carga de trabalho contém superfícies muito grandes, dados de paisagem em camadas ou conjuntos de texturas cujo padrão de acesso em mosaico é melhor do que a residência completa do MIP. A avaliação deve incluir compatibilidade de material, comportamento de upload de tiles, pressão de cache, latência visual, tamanho de cozimento, suporte à plataforma de destino e custo de shader ou amostragem. Mantenha um plano B e compare ambos os caminhos sob a mesma rota de câmera e revisão de conteúdo.

Se o problema for texturas 4K duplicadas, mips ausentes, formato de compressão incorreto ou Never Stream injustificado, converter a carga de trabalho pode transferir o custo sem corrigir o erro de conteúdo. Corrija esses problemas de autoria primeiro. Use o guia dedicado Runtime Virtual Texturing dedicado para a decisão separada do RVT, em vez de misturar duas migrações em uma única passagem de solução de problemas.

Valide a qualidade da imagem, o desempenho e a embalagem

Um resultado de aprovação precisa de mais do que um aviso aprovado. Execute uma matriz repetível e mantenha as evidências antes e depois:

• Viewport do editor: captura STAT STREAMING, capturas de tela da câmera de referência e valores do pool mais não-streaming. Passe quando o aviso for explicado e o detalhe pretendido permanecer estável.
• PIE: captura inicial, travessia, pop-in de texturas e pacing de quadros. Passe quando a rota de gameplay se mantém dentro do orçamento sem mips tardios inaceitáveis.
• Standalone: use um lançamento a frio e repita a rota em resolução representativa. Passe quando o resultado não depender do estado quente apenas do editor.
• Build empacotada: executa uma build de Desenvolvimento ou Teste em cada classe de hardware. Aprove quando a política do pool, MIPS cozidos, compressão e qualidade correspondem à configuração de envio.
• Rota de estresse: exerce viagem rápida, teletransporte, cortes de câmera, uma cena densa ou viagens repetidas no mapa. Passe quando o pico se recupera previsivelmente sem acumular residência inexplicável.

Compare a memória da GPU junto com o tempo de quadro e a saída visual. Um pool menor pode reduzir a residência, mas causar desfoque ou churn distrativo; um pool maior pode suprimir o aviso enquanto rouba headroom do Nanite, Lumen, alvos de renderização ou outros recursos da GPU. Defina um requisito explícito de headroom e falhe no teste quando outro recurso de renderização ficar instável.

Valide nos percentuais reais de tela e nos níveis de escalabilidade do projeto. Uma captura fixa de desktop não prova comportamento de console, laptop, streaming em nuvem ou móvel. Se uma plataforma expor um conjunto diferente de contadores ou compartilhar memória com a CPU, documente esse limite e use sua orientação nativa de perfilamento em vez de traduzir mecanicamente um orçamento de GPU discreta.

Correções comuns que falharam e o que fazer em vez disso

"Defina o pool para um valor enorme e envie"

Isso esconde o aviso sem provar que o hardware tem margem segura. Use um valor maior apenas como experimento controlado, depois crie orçamentos por plataforma a partir de builds empacotadas medidas.

"Executar DisableAllScreenMessages"

Suprimir mensagens na tela não reduz o conteúdo de residência ou reparação. Preserve os avisos durante o diagnóstico e resolva ou aceite explicitamente a condição orçamentária medida.

"Converter toda textura para Texturização Virtual"

Blocos virtualizados adicionam um fluxo de trabalho e custo de execução diferentes. Selecione-os para uma carga de trabalho adequada após um perfil lado a lado, não como uma reação global a um único aviso de pool.

"Reduza a escala de todas as texturas"

A redução geral pode danificar os ativos do herói, a interface, as cenas cinematográficas ou a legibilidade de curta distância. Classifique os assets por contribuição de memória e tamanho projetado, então tome decisões reversíveis em grupo ou por recurso.

"Passa no PIE, então está fixo"

O PIE pode reutilizar o estado do editor e não comprova dados cozidos ou perfis de envio. Repita a rota freealone e package em hardware de classe alvo.

Lista de verificação de passagem de equipes

• Unreal Engine versão, revisão do projeto, RHI alvo, perfil do dispositivo, resolução da tela e escalabilidade do nível.
• Mapa falhando e câmera determinística ou rota de jogabilidade.
• Capturas antes e depois STAT STREAMING, incluindo pool e contexto de Mips Não Streaming.
• Alterei texturas, arquivos fonte, dimensões, configurações MIP, compressão, grupos e flags de residência.
• Valores temporários do console mantidos separados das mudanças persistentes de configuração.
• Pontos de comparação visual e exceções conhecidas para heróis, interface, cinemas ou recursos de acessibilidade.
• Resultados PIE, standalone e compilações empacotadas em todas as classes de hardware reivindicadas.
• Revisão de reversão e a condição que reabre a decisão orçamentária.

SEELE AI transferência e fronteira de produto

Para um novo conceito, SEELE AI pode gerar um jogo nativo do Unreal 5, fornecer uma prévia do navegador, suportar otimização e empacotamento, e fornecer o projeto ou a saída empacotada para download. O Unreal game creator cobre esse caminho de criação, enquanto o Unreal 3D asset optimizer suporta revisão de ativos exportados antes da importação do Unreal.

Esse fluxo de trabalho de novo projeto é separado da resolução de problemas de um projeto existente. O trabalho de texturas de projetos existentes permanece com a equipe da Unreal: abrir e editar os .uproject atuais, alterar DefaultEngine.ini ou perfis de dispositivo, alternar o Virtual Texturing, modificar recursos de textura, executar STAT STREAMING, preparar a build e comprovar o orçamento da plataforma. Unreal Engine é uma marca registrada da Epic Games; este guia independente não implica endosso da Epic.

Fontes oficiais e guias relacionados do Unreal

• Configuração de Streaming de Textura em Unreal Engine — variáveis de console e configuração do pool.
• Métricas de Streaming de Texturas em Unreal Engine — STAT STREAMING e métricas de memória/desempenho.
• Visão geral de streaming de texturas para Unreal Engine — visão geral de primeira parte do streaming convencional de texturas.
• ⟧Unreal Engine biblioteca de guias de renderização — workflows relacionados a renderização, VFX e performance.
• Unreal Runtime Virtual Texturing guide — avalie o RVT como uma decisão separada sobre carga de trabalho.

Perguntas frequentes

O que significa "Pool de Streaming de Texturas Acima do Orçamento" no UE5?

Isso significa que o streamer de texturas quer mais memória para as visualizações atuais do que seu pool configurado permite. Ele não identifica uma textura ruim sozinho. Capture STATIC STREAMING e inspecione a demanda transmitida, forçada e não transmitida antes de decidir se a causa raiz é conteúdo, política de residência ou um orçamento de plataforma realmente subdimensionado.

Qual comando mostra a memória de streaming de texturas em Unreal Engine?

Use STAT STREAMING no console Unreal e reproduza o aviso por meio de uma câmera fixa ou rota de jogo. Salve a captura completa com a versão do motor, RHI, resolução, nível de escalabilidade, mapa e identidade da build. O layout do contador pode variar conforme a versão do motor, então use a versão correspondente da documentação Epic.

Aumentar o r.Streaming.PoolSize é uma solução válida?

Pode ser válido quando as medições de build em pacotes mostram que conteúdo otimizado precisa de um pool maior e o hardware alvo mantém margem segura para memória da GPU. Não é uma solução universal. Use-a temporariamente para testar a hipótese e depois documente um orçamento persistente específico da plataforma em vez de copiar um valor de um megabyte entre dispositivos.

Por que os Mips NonStreaming estão altos?

Mips não Streaming, com alta frequência, podem apontar para memória que o streamer normal não pode reduzir livremente, incluindo texturas Never Stream, residência forçada, texturas de interface, cubemaps ou outras alocações incluídas no pool em algumas plataformas. Rastreie os assets e tipos de recursos contribuintes antes de aumentar o pool ou reduzir texturas transmitidas não relacionadas.

Devo ativar o Virtual Texturing para remover o aviso do pool?

Não automaticamente. Texturização Virtual é um fluxo de trabalho separado de continuidade em blocos (tiled) com trade-offs de material, cache, feedback, preparo (cook), shader e plataforma. Primeiro conserte mips ausentes, mapas de origem muito grandes, compressão ou grupos de textura incorretos e residência forçada sem motivo. Compare a Texturização Virtual apenas para tarefas que realmente se beneficiam do acesso em blocos.

Como posso verificar uma correção de streaming de textura antes de lançar?

Repita a mesma rota representativa no editor, PIE, standalone e numa build empacotada em cada classe de hardware especificada. Compare STAT STREAMING, memória total da GPU, ritmo de quadros, clareza das texturas, pop-in, comportamento de carregamento a frio e recuperação após cortes de câmera ou viagens. Mantenha uma revisão de rollback e um requisito de folga documentado.