1. Verifique o limite MegaLights do UE 5.8 antes do profiling
Comece registrando a build exata do Unreal Engine 5.8, RHI, plataforma alvo, configurações do renderizador do projeto, método de anti-aliasing, política de resolução e nível de escalabilidade. Confirme a disponibilidade e limitações do MegaLights conforme a documentação da Epic para essa build. Um screenshot de outra release ou de um projeto com suporte diferente a ray tracing não é uma baseline válida.
Crie um mapa de benchmark pequeno ou um conjunto de câmeras de produção travado. Preserve a revisão da fonte, mapa, perfil de dispositivo, snapshot de variáveis de console, configurações de mobilidade e sombra de luz, estado do Lumen e a célula de conteúdo que será carregada. O objetivo é tornar o teste repetível após uma atualização da engine ou mudança de configuração, não produzir a captura mais favorecida.
Escreva o target de aceitação antes de fazer profiling: orçamento de tempo de frame, tolerância de frame pacing, tier de hardware suportado, faixa de resolução e piso visual. Mantenha a conveniência do editor separada da evidência de shipping. Se o limite de recurso documentado não incluir o caminho alvo, pare e escolha um plano de iluminação suportado em vez de extrapolar de uma demonstração desktop.
Verifique o limite MegaLights do UE 5.8 antes da checklist de profiling
- Registre a build exata do UE 5.8, RHI, plataforma, configurações do renderizador, perfil de dispositivo e revisão de origem.
- Confirme o suporte e as limitações do MegaLights na documentação da Epic para essa build.
- Defina os objetivos de tempo de frame, frame pacing, hardware, resolução e aceitação visual.
- Bloqueie um mapa e uma sequência de câmera representativos antes de alterar configurações.
- Pare se o renderer ou a plataforma alvo estiver fora do limite de recurso documentado.
2. Capture uma baseline reproduzível de GPU
Capture a mesma sequência de câmera com stat unit e stat gpu visíveis por tempo suficiente para distinguir limites de Game, Draw e GPU. Use ProfileGPU e GPU Visualizer para um frame representativo, depois use Unreal Insights GPU timing quando a plataforma alvo e o build expuserem o trace necessário. Salve a captura ao lado da revisão do projeto e do registro de hardware.
Aqueça a cena antes de gravar, depois mantenha fixos trilho de câmera, resolução, screen percentage, VSync ou frame cap, escalabilidade e carga em background. Grave mais de um frame: median e tail do tempo de frame revelam picos que um único snapshot do GPU Visualizer pode perder. Repita uma carga fria separadamente para que compilação de shader ou streaming não seja confundida com o custo de iluminação em estado estável.
Uma linha de base útil identifica os passes caros e seus responsáveis. Se a GPU não for o recurso limitante, não diga que houve otimização do MegaLights a partir de uma taxa de quadros inalterada. Se a GPU for limitante, preserve a captura anterior e altere uma variável de iluminação por vez para que o próximo trace consiga atribuir a diferença.
Capture uma checklist de baseline de GPU reprodutível
- Capture stat unit e stat gpu para a sequência fixa após um warm-up consistente.
- Salve uma captura de ProfileGPU ou GPU Visualizer para frames representativos e de pior caso.
- Colete um trace GPU do Unreal Insights onde a build alvo suportar.
- Rotule separadamente o trabalho de cold-load, shader e streaming do custo de iluminação em estado estável.
- Preserve a linha de base antes de alterar um proprietário suspeito.
3. Separe o custo do MegaLights do restante do frame
MegaLights compartilha o frame com Lumen, materiais, Nanite ou geometria convencional, Virtual Shadow Maps ou outros caminhos de sombra, translucência, pós-processamento e custo de resolução. Use capturas pareadas para identificar qual passe muda quando o MegaLights é habilitado, desabilitado ou configurado de forma diferente em um branch de teste suportado. Não atribua todo o delta de GPU ao recurso apenas pelo nome.
Construa casos A/B controlados a partir da mesma câmera e da mesma revisão de conteúdo. Primeiro mantenha geometria e materiais constantes ao mudar o conjunto de luzes; depois mantenha a iluminação constante ao testar o material, sombra ou responsável do Lumen suspeito. O ProfileGPU e o GPU Visualizer devem mostrar se o passe pretendido se moveu. Registre as diferenças de imagem para que um resultado mais rápido não seja aceito depois de remover silenciosamente sombras obrigatórias ou resposta de luz necessária.
Reporte tanto o delta de tempo de frame quanto a troca visual. Uma mudança só é útil quando sobrevive à resolução alvo e ao nível de qualidade, não desloca o gargalo para outro passe e mantém a legibilidade de gameplay. Preserve qualquer inferência sem suporte como uma dúvida para o owner de engine ou rendering, em vez de transformá-la em uma regra universal de MegaLights.
Checklist para separar custo do MegaLights do restante do frame
- Compare configurações de MegaLights suportadas com câmera, resolução e configurações de conteúdo correspondentes.
- Separe os passes de luz e sombra de Lumen, material, geometria, pós-processamento e custo de resolução.
- Anexe imagens equivalentes para que mudanças de desempenho não ocultem uma regressão visual.
- Rejeitar uma mudança que apenas move o gargalo para outro passe de GPU.
- Registre qualquer atribuição não suportada como uma hipótese, não como resultado.
4. Aplicar estresse em câmeras representativas e densidade de luz
Escolha câmeras de jogabilidade real: uma visão de travessia normal, o cluster de luzes autoral mais denso, um momento com luzes em movimento ou animadas, uma transição de streaming e o encontro conhecido como pior caso. Inclua a máxima densidade visível esperada de luz e sombra, materiais representativos, partículas, translucidez e geometria. Uma sala de teste esparsa não estabelece o budget de shipping para um nível de produção.
Execute a mesma sequência de câmera determinística para cada configuração candidata. Capture percentis de frame-time da GPU, os passes de GPU mais caros, frame pacing, pressão de memória e artefatos visíveis. Onde a plataforma-alvo suportar, colete a cronologia do Unreal Insights durante a sequência completa em vez de depender apenas de um overlay do editor. Mantenha as execuções quentes e frias rotuladas separadamente.
Rejeite uma configuração que passe apenas em uma vista, falhe quando as luzes se sobrepõem, engasgue durante travessias ou produza sombras instáveis e transições de iluminação óbvias. Se uma cena for uma exceção, isole o conjunto de luzes, material, região de geometria ou evento de streaming responsável e anexe essa evidência ao problema. Não dilua uma falha de shipping na média do relatório.
Checklist de estresse para câmeras representativas e densidade de luz
- Teste câmeras de jogabilidade normal, densa de luz, luz em movimento, streaming e pior caso.
- Use overlap de luzes, geometria, materiais, partículas e translucidez semelhantes à produção.
- Registre percentis de GPU, passes caros, frame pacing, pressão de memória e artefatos.
- Investigue outliers por conjunto de luzes, material, região de geometria ou evento de streaming.
- Rejeitar uma configuração que tenha sucesso apenas em uma sala de teste esparsa.
5. Construa uma matriz de escalabilidade e fallback
Defina cada nível de qualidade suportado antes dos testes. Para cada nível, registre resolução ou percentual de tela, política de sombras e Lumen, orçamento de luzes, estado do MegaLights e o fallback usado quando o recurso ou a meta de desempenho não estiver disponível. Use as mesmas câmeras para que os revisores possam comparar custo e comportamento visual diretamente.
O fallback deve preservar navegação do jogador, perigos, legibilidade de interações, separação de personagens e pistas de clima obrigatórias. Compare imagens pareadas e timings, depois teste transições entre perfis de dispositivo ou configurações de qualidade em uma build empacotada. Um fallback que atinge o orçamento de frame tornando a informação de gameplay ilegível não passa.
Mantenha exceções específicas por plataforma. Se um hardware tier exigir um conjunto de luzes authoring diferente ou solução bakeada, documente a propriedade e o impacto no conteúdo em vez de apresentar como um toggle automático de escalabilidade. Armazene a última configuração aprovada e a condição que dispara rollback quando uma mudança posterior de luz, material ou mundo exceder o budget.
Checklist de construção de matriz de escalabilidade e fallback
- Documente todos os níveis de qualidade suportados, perfil de dispositivo, política de resolução e fallback de iluminação.
- Compare as mesmas câmeras e imagens emparelhadas em todos os níveis.
- Verifique se navegação, obstáculos, interativos, personagens e clima de humor necessário permanecem legíveis.
- Teste transições de qualidade ou de perfil de dispositivo em uma build empacotada.
- Mantenha uma configuração de último estado conhecido e um gatilho de rollback.
6. Valide o hardware-alvo e builds empacotadas
O profiling no editor é diagnóstico, mas o gate de shipping pertence ao build de alvo. Empacote a fatia representativa com configurações semelhantes às de shipping, execute em uma GPU e CPU named tier, e repita a sequência fixa de câmera após um aquecimento consistente. Registre driver, sistema operacional, modo de energia, resolução, configuração de build e qualquer profiler da plataforma utilizado.
Compare os percentis de GPU em estado estável com frame pacing, travamentos de carregamento e streaming, pressão de memória e uma execução mais longa que possa expor mudanças de clock ou térmicas. Mantenha compilação de shaders e trabalho de cache de primeira execução separados do resultado em estado estável. Se o build empacotado divergir do editor, a evidência empacotada dita a decisão de release.
Teste pelo menos o tier mínimo suportado e o alvo de qualidade principal. A captura em uma workstation de alto desempenho não prova o nível inferior. Publique a faixa suportada e a fatia exata de conteúdo medida, e encaminhe falhas específicas de plataforma para o responsável de rendering ou plataforma com as capturas necessárias para reproduzi-las.
Checklist de validação de hardware-alvo e builds empacotadas
- Execute a sequência fixa em build empacotado nos níveis mínimo e principal de hardware.
- Registre driver, sistema operacional, modo de energia, resolução, configuração de build e política de aquecimento.
- Compare percentis de GPU, frame pacing, memória, loading, streaming e comportamento em execuções longas.
- Trate a evidência do target empacotado como definitiva quando ela divergir do editor.
- Publique o hardware testado e a faixa de conteúdo em vez de uma afirmação universal.
7. Congelar o gate de shipping e o registro de regressão
Uma decisão de MegaLights com potencial de shipping inclui a revisão do projeto, build do UE 5.8, configurações de renderer e escalabilidade, hardware e driver, sequência de câmera, capturas raw de stat, evidência de ProfileGPU ou GPU Visualizer, trace do Unreal Insights quando disponível, imagens pareadas e o resultado da build empacotada. Vincule cada conclusão ao artefato que a suporta.
Converta o resultado em um teste de regressão com um proprietário nomeado e um limiar. Reexecute-o após atualizações da engine, edições do perfil de dispositivo, alterações significativas de luz ou sombra, reescritas de materiais, mudanças de world partition ou atualizações de hardware-alvo. Mantenha o mesmo caminho de benchmark e adicione um novo caso apenas quando representar um risco real de shipping.
O gate de release só é aprovado quando cada tier suportado atende ao frame-time e ao mínimo visual, o fallback está documentado e outro desenvolvedor consegue reproduzir o resultado. Registre o gatilho de rollback e as últimas configurações consideradas boas. O SEELE AI pode ajudar a estruturar esse plano, mas nenhum profiling nativo de Unreal foi executado como evidência para este guia.
Checklist de congelar o gate de shipping e o registro de regressão
- Arquive captures brutas de timing, traces, imagens, configurações, hardware, build e revisão do projeto.
- Defina um dono e um limiar para o teste repetível de regressão de desempenho.
- Reexecute após mudanças de engine, perfil de dispositivo, iluminação, material, world ou hardware.
- Exija que todo tier suportado atenda tanto aos gates de desempenho quanto aos visuais.
- Documente o rollback e o fato de que este guia não executou profiling nativo da Unreal.
Fluxo de trabalho SEELE AI no Unreal 5: gerar, visualizar, otimizar, empacotar e publicar
SEELE AI é útil antes ou ao lado da produção no Unreal quando a equipe precisa comparar direção de cena, loop do jogador, sensação de câmera, briefing de conteúdo ou plano de testes. Abra a página canônica do Unreal, escolha um card de workspace real e leve o prompt para o workspace de geração do navegador com sua atribuição de origem intacta.
A SEELE AI pode gerar um jogo nativo Unreal 5, visualizá-lo no navegador, otimizá-lo e empacotá-lo, e fornecer um jogo para download ou construção empacotada para publicação externa ou jogos Seele pagos. Vendas não são garantidas.
Fontes oficiais e guias relacionados da Unreal
Esta página é um guia de fluxo de trabalho independente. Mudanças de comportamento do engine variam entre releases, plugins, plataformas e configurações de projeto, portanto confirme os detalhes específicos de versão na documentação da Epic e preserve a evidência usada para sua decisão.
Unreal Engine é uma marca registrada da Epic Games. SEELE AI é independente e este guia não constitui endosso da Epic.
- Documentação oficial do MegaLights — material de primeira parte para escopo de produto, fluxo de trabalho, versão ou verificações de política; use apenas as alegações que a fonte realmente afirma.
- Notas oficiais da versão do Unreal Engine 5.8 — material de primeira parte para escopo de produto, fluxo de trabalho, versão ou verificações de política; use apenas as alegações que a fonte realmente afirma.
- Renderização e gráficos — material de primeira parte para escopo de produto, fluxo de trabalho, versão ou verificações de política; use apenas as alegações que a fonte realmente afirma.
Perguntas frequentes
O MegaLights é um switch de performance de luz ilimitada?
Não. Processe câmeras representativas e hardware-alvo porque luz, sombra, Lumen, material, geometria, resolução e custos de plataforma ainda determinam o resultado. Trate o MegaLights como uma decisão de renderer medida, preserve a baseline e publique a faixa testada em vez de prometer luzes ilimitadas.
Quais ferramentas da Unreal devo usar primeiro?
Comece com stat unit e stat gpu para confirmar o thread limitante, depois capture evidência do ProfileGPU ou GPU Visualizer para frames representativos. Adicione um trace de Unreal Insights GPU onde o build permitir, mantendo fixos câmera, resolução, escalabilidade, revisão de conteúdo e política de warm-up.
Como isolo o custo do MegaLights?
Use capturas A/B emparelhadas com câmeras fixas, conteúdo, resolução e escalabilidade iguais. Altere um proprietário de iluminação, inspecione os passes de GPU afetados e compare imagens emparelhadas. Não atribua todo o delta de frame ao MegaLights quando Lumen, sombras, materiais, geometria ou pós-processamento também mudaram.
Quais câmeras fazem parte do benchmark?
Inclua a movimentação normal, luzes sobrepostas densas, luzes em movimento, transições de streaming e o pior caso de produção em vez de apenas uma sala de teste esparsa. Use materiais, partículas, translucidez, geometria e sobreposição de sombra semelhantes aos da produção, depois registre percentis, frame pacing, passes caros e artefatos visíveis.
Uma captura no editor comprova performance de shipping?
Não. Repita a sequência fixa em uma build empacotada nos tiers mínimo e principal de hardware. Registre driver, modo de energia, resolução, configuração da build, percentis de frame-time, frame pacing, memória, streaming e comportamento em execução prolongada. A evidência do alvo empacotado controla a decisão de shipping quando for diferente da do editor.
A SEELE AI executou esses perfis do Unreal?
Não. Este guia define um plano de testes e contrato de evidências; ele não afirma que a SEELE AI executou tests de stat gpu, ProfileGPU, GPU Visualizer, Unreal Insights ou testes de build empacotado. Um proprietário de renderização deve rodar essas verificações no projeto UE 5.8 real e manter as capturas.
