Introduction
It's a common story in hundreds of development studios: the game reaches the final production phase, test builds are sent out, and the QA report comes back painted in red. The FPS doesn't go past 25 on mid-end hardware, and stutters are constant.
The team's immediate instinct is drastic: "We need to reduce polygons! Cut the texture resolution in half! Remove the lights!".
But what if we told you that in 90% of indie and AA projects, the problem is not your art?
The true root cause of frame rate drops in Unity is rarely the complexity of the 3D model. The problem lies in how the CPU organizes and sends this data to the graphics card.
In this technical guide, we will dive into the 3 biggest silent FPS killers in Unity and how to solve them.
1. CPU Bottleneck: Draw Calls and the SRP Batcher
To render an object on the screen, the CPU must prepare the data (position, rotation, texture, shader) and send it to the GPU through a command called a Draw Call.
The Classic Bottleneck
If you have 1,000 boxes in the scene, but each box uses a different Material, the CPU will make 1,000 Draw Calls. Your graphics card (GPU) will sit idle waiting for the overworked CPU to send the orders.
To double your FPS in this scenario, you don't need boxes with fewer polygons. You need Batching.
In the Universal Render Pipeline (URP), the best tool for this is the SRP Batcher. The SRP Batcher doesn't merge 3D meshes (like classic Static Batching); instead, it focuses on sending material properties in a large, contiguous block of memory to the GPU.
How to ensure the SRP Batcher works:
- Use the same Shader for as many objects as possible.
- Make sure the shader is compatible with the SRP Batcher (material properties must be encapsulated in a
CBUFFER). - Group different textures into a single massive file (Texture Atlasing).
2. Overdraw: The Transparent Enemy
If the CPU's problem is Draw Calls, the classic GPU problem (besides dynamic lights) is Overdraw.
Overdraw happens when the game renders a pixel on the screen that is behind another transparent pixel, and then renders the front one on top. This forces the GPU to calculate color, lighting, and depth for that same screen space multiple times in a single frame.
Optimizing Particles
Particle systems with giant smoke sprites that fill the entire screen are fatal for mobile and mid-end hardware. Always prefer more, smaller particles rather than a few particles with massive textures covering the camera.
Practical steps:
- In the Unity Scene View panel, change the view mode to Overdraw. Anything that glows too brightly (in white) is being rendered multiple times.
- Eliminate invisible transparent panels (with 0 alpha) in your UI (Canvas). Uncheck the Raycast Target for texts and images that don't need to be clicked.
3. GC Spikes: Trash in Update()
A game running at 60 FPS has about 16 milliseconds to complete all frame calculations. What happens when you write this?
Every time you concatenate a string (+) in C#, you create a new memory object. The old string is abandoned in memory. Every frame. 60 times a second.
Eventually, the memory "fills up" and the C# Garbage Collector (GC) has to step in to clean up the trash. The problem? The GC "freezes" the game's main thread. The result is that horrible stutter that happens right in the middle of combat.
The Golden Rule:
- Never allocate memory (
new, string concatenation,Instantiate()) inside theUpdate()method. - Use Object Pooling to instantiate all bullets, enemies, and special effects during the scene's Loading phase, and at runtime just enable (
SetActive(true)) and disable them.
Automated Engineering: Stop Wasting Time
Fixing these architectural bottlenecks requires attention. But what consumes the most engineering time isn't fixing one material, but rather balancing how the game will handle these things depending on the player's PC.
Ensuring textures don't exceed VRAM limits and configuring Quality Tiers that dynamically toggle heavy effects takes weeks of development in any studio.
That's exactly why we built the Automatic Graphics Settings (AGS).
AGS monitors the health of the FrameTimingManager and manages level of detail and shader caching in the background. It features a SoftScaling system that reacts to frame drops, adjusting Texture Streaming and reducing graphical load moments before the player ever feels a stutter. And the best part: you hook it into your game via Reflection, without needing to write a single line of UI code.
Introdução
É uma história comum em centenas de estúdios de desenvolvimento: o jogo chega na fase final de produção, os builds de teste são enviados e o relatório do QA volta pintado de vermelho. O FPS não passa de 25 em hardware mid-end, e os travamentos são constantes.
O instinto imediato da equipe é drástico: "Precisamos diminuir os polígonos! Reduza a resolução das texturas pela metade! Remova as luzes!".
Mas e se nós dissessemos que o problema, em 90% dos casos de projetos indie e AA, não é a sua arte?
A verdadeira causa raiz das quedas de frame rate no Unity raramente é a complexidade do modelo 3D. O problema está na forma como a CPU organiza e envia esses dados para a placa de vídeo.
Neste guia técnico, vamos mergulhar nos 3 maiores "assassinos silenciosos" de FPS no Unity e como resolvê-los.
1. O Estrangulamento da CPU: Draw Calls e o SRP Batcher
Para renderizar um objeto na tela, a CPU precisa preparar os dados (posição, rotação, textura, shader) e enviá-los para a GPU através de uma chamada chamada Draw Call.
O Gargalo Clássico
Se você tem 1.000 caixas na cena, mas cada caixa usa um Material diferente, a CPU fará 1.000 Draw Calls. A sua placa de vídeo (GPU) ficará ociosa esperando a CPU (que está sobrecarregada) enviar as ordens.
Para dobrar o seu FPS nesse cenário, você não precisa de caixas com menos polígonos. Você precisa de Batching.
No Universal Render Pipeline (URP), a melhor ferramenta para isso é o SRP Batcher. O SRP Batcher não junta as malhas 3D (como o Static Batching clássico); em vez disso, ele foca em enviar as propriedades do material em um grande bloco de memória contígua para a GPU.
Como garantir que o SRP Batcher funcione:
- Use o mesmo Shader para o máximo de objetos possível.
- Certifique-se de que o shader é compatível com o SRP Batcher (as propriedades de material devem estar encapsuladas em um
CBUFFER). - Agrupe texturas diferentes em um único arquivo gigantesco (Texture Atlasing).
2. Overdraw: O Inimigo Transparente
Se o problema da CPU são as Draw Calls, o problema clássico da GPU (além de luzes dinâmicas) é o Overdraw.
Overdraw acontece quando o jogo renderiza um pixel na tela que está atrás de outro pixel transparente, e depois renderiza o da frente por cima. Isso força a GPU a calcular cor, iluminação e profundidade para aquele mesmo espaço de tela múltiplas vezes em um único frame.
Otimizando Partículas
Sistemas de partículas com sprites de fumaça gigantes que ocupam a tela toda são fatais para mobile e hardware mid-end. Sempre prefira mais partículas menores do que poucas partículas com texturas massivas cobrindo a câmera.
Passos práticos:
- No painel Scene View do Unity, altere o modo de visualização para Overdraw. Tudo que brilhar muito forte (em branco) está sendo renderizado diversas vezes.
- Elimine painéis transparentes invisíveis (com alpha 0) na sua UI (Canvas). Desmarque o Raycast Target de textos e imagens que não precisam ser clicados.
3. GC Spikes: O Lixo no Update()
Um jogo rodando a 60 FPS tem cerca de 16 milissegundos para concluir todos os cálculos do frame. O que acontece quando você escreve isso?
Toda vez que você concatena uma string (+) in C#, você cria um novo objeto de memória. A velha string fica abandonada na memória. A cada frame. 60 vezes por segundo.
Eventualmente, a memória "enche" e o Garbage Collector (GC) de C# precisa entrar em ação para limpar o lixo. O problema? O GC "congela" a thread principal do jogo. O resultado é aquele travamento brusco (stutter) horrível que acontece no meio do combate.
A Regra de Ouro:
- Nunca aloque memória (
new, concatenação de strings,Instantiate()) dentro do métodoUpdate(). - Use Object Pooling para instanciar todas as balas, inimigos e efeitos especiais durante o Loading da cena, e no runtime apenas ative (
SetActive(true)) e desative.
A Engenharia Automatizada: Pare de Perder Tempo
Corrigir esses gargalos na arquitetura exige atenção. Mas o que consome mais tempo dos engenheiros não é corrigir um material, mas sim balancear como o jogo vai lidar com essas coisas dependendo do PC do jogador.
Garantir que as texturas não estourem a VRAM e configurar Quality Tiers que ativem ou desativem efeitos pesados dinamicamente toma semanas de desenvolvimento em qualquer estúdio.
Foi para resolver exatamente isso que construímos o Automatic Graphics Settings (AGS).
O AGS monitora a saúde do FrameTimingManager e gerencia os níveis de detalhe e cache de shaders em background. Ele possui um sistema de SoftScaling que reage a quedas de frame, ajustando o Texture Streaming e reduzindo a carga gráfica instantes antes do jogador sentir o stutter. E a melhor parte: você o conecta no seu jogo via Reflection, sem precisar escrever uma única linha de código na interface.
Automatic Graphics Settings
Effortlessly build robust graphics menus, manage cross-platform presets, and maintain smooth FPS.
View Asset
