O documento discute técnicas de otimização em Unity para melhorar o desempenho de jogos, incluindo usar lightmaps e light probes para iluminação estática, batching para reduzir draw calls, occlusion culling para objetos ocultos, criar assets com baixa poligonalidade e texturas, e programação eficiente evitando repetições desnecessárias.
6. Problemas de otimização
• Abuso de iluminação dinâmica
• Muitas draw calls
• Muitos objetos na cena
• Muitos vértices e polígonos por
objeto
• Texturas com resolução muito
alta
• Shaders pesados
• Muitas texturas diferentes
• Muitas malhas diferentes
• Tamanho final do build muito
grande
• Abuso de features gráficas:
sombras, pós-processamento
• Scripts lentos
8. Lightmaps & Light Probes
• Lightmaps
• Cálculo de luz em tempo de projeto
• Prós
• Número arbitrário de luzes
• Permite efeitos complexos
• Custo baixíssimo em runtime
• Contras
• Só funciona em objetos estáticos
9. Lightmaps & Light Probes
• Light probes
• Aproximação de luz global para
objetos dinâmicos
• Prós
• Melhora iluminação em objetos dinâmicos
• Funciona com shaders padrão e é fácil de
adicionar nos seus shaders
• Contras
• Menos preciso
• Informação de luz de baixa frequência
10.
11. Static & Dynamic batching
• Batching: combina objetos que utilizam mesmo material em uma
única draw call
• Static batching
• Combinação em tempo de projeto para objetos estáticos
• Dynamic batching
• Funciona automagicamente em runtime com todos os objetos
• Porém, tem um custo mais alto de CPU
12.
13. Occlusion culling
• Desliga o rendering de objetos que estão totalmente ocludidos por
outros na cena
• Requer pré-cálculo e ajuste em tempo de projeto
• Oclusores precisam ser estáticos, mas ocludidos podem ser dinâmicos
15. Cuidados constantes na criação
• Contagem de polígonos e vértices
• Personagens e cenário
• Escolher onde gastar seu “orçamento”
• Trade-offs entre complexidade na malha e no shader
• Malha usada na física
• Resolução de texturas
• Memória de vídeo é limitada
• Escolher, de novo, onde gastar o orçamento
• Tamanho da textura exibida na tela
• Detalhes de alta frequência são uma ideia perigosa
16. Complexidade de shaders
• Considerar o shader certo para cada situação
• Aquela peça de decoração não precisa de 5 mapas de detalhe + normal +
specular + cubemap + AO
• Colocar um target estrito e baixo nos shaders…
• Por exemplo, Shader Model 2.0
• Garante um custo baixo
• Incentiva programação bem otimizada
18. Texture Atlas
• Assets que utilizam o mesmo
shader podem compartilhar o
material…
• Se suas texturas forem combinadas
em uma só
• Extremamente importante
• Static & Dynamic Batching
19. Reutilização de assets
• Model & texture once, use everywhere
• Reduz o custo de criação e de runtime
• Menos malhas e texturas únicas
• Menos memória
• Especialmente relevante em mobile…
• Reutilização criativa evita a repetição
53. Armadilhas na API da Unity
• FindObject[OfType]
• GetComponent[s]InChildren
• GetComponent
• renderer.material
54. Cuidados gerais
• Não refazer cálculos quando as entradas não mudam
• Calcule a primeira vez, guarde para consulta
• Não refazer o mesmo cálculo em vários lugares
• Centralize o cálculo (por exemplo em um Manager)
• Distribuir cálculo pesado por vários frames
• Exemplo: determinar visibilidade entre todos os jogadores
• Tradeoff: desempenho X precisão
• Quase sempre a precisão não precisa ser de um frame…
55. Mais alternativas
• Desligar objetos “inúteis” para evitar gastar CPU
• Update, FixedUpdate
• Física
• Culling
• Multithreading para computação pesada
• !!CUIDADO!! – API da Unity *NÃO* é thread-safe
• Mas um bom isolamento de código vai longe
• Exemplo clássico: IA