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.

1. Otimização em Unity
Fazendo seu jogo rodar no PC da sua avó

2. Otimização em Unity
Fazendo seu jogo rodar no PC da sua avó
(e no celular da sua avó)

5. Como?
E quais os problemas mais comuns?

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

7. Nível 1
Aproveitando o que a Unity tem a oferecer

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

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

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

14. Nível 2
Otimização na criação de Assets

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

17. Shader Model 2.0

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

23. Nível 3
Otimização de tamanho de arquivo

24. Utilizando assets com inteligência
• Texturas
• Resolução
• Compressão
• Som
• Sample rate
• Formato
• Bitrate
• Malhas
• Compressão
• Remoção de polígonos inúteis
• Animações
• Compressão
• Reutilização
• Layers
• Mixing Transforms
• Animações aditivas

25. Asset bundles!

27. Trick Question
• Qual o tamanho desta textura
no build?
• 512x512
• Diffuse + Normal

28. Trick Question
• 2MB?

29. Trick Question
• 2MB?
• 1MB?

30. Trick Question
• 2MB?
• 1MB?
• 512KB?

31. Trick Question
• 2MB?
• 1MB?
• 512KB?
• 256KB?

32. Trick Question
• 2MB?
• 1MB?
• 512KB?
• 256KB?
• 128KB?

33. Trick Question
• 2MB?
• 1MB?
• 512KB?
• 256KB?
• 128KB?
• 64KB?

34. Trick Question
• 2MB?
• 1MB?
• 512KB?
• 256KB?
• 128KB?
• 64KB?
• 32KB?

35. Trick Question
• 2MB?
• 1MB?
• 512KB?
• 256KB?
• 128KB?
• 64KB?
• 32KB?
• 16KB?

36. Trick Question
• 2MB?
• 1MB?
• 512KB?
• 256KB?
• 128KB?
• 64KB?
• 32KB?
• 16KB?
• 8KB?

37. Trick Question
• 2MB?
• 1MB?
• 512KB?
• 256KB?
• 128KB?
• 64KB?
• 32KB?
• 16KB?
• 8KB?
• 4KB?

38. Trick Question
• 2MB?
• 1MB?
• 512KB?
• 256KB?
• 128KB?
• 64KB?
• 32KB?
• 16KB?
• 8KB?
• 4KB?
3,72KB

40. ~20MB

41. ~20MB (quase tudo lightmap)

42. Nível 4
Soluções criativas

44. Sombras dinâmicas?

45. Sombras dinâmicas?
Nope, Chuck Testa

52. Nível 4
Cuidados com programaçã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

56. Perguntas?
Bruno “Tinnus” Ferreira
tinnus@gmail.com
bruno.ferreira@aquiris.com.br