Por Que os Modelos 3D São Tão Pesados?
Seu modelo está ficando pesado às escuras
Você exportou um arquivo GLB—10MB, parece normal. Ao abrir no celular: tela branca, travamentos ou até um crash direto.
No computador tudo funciona, mas no celular expluda. Isso não é culpa do seu código. É uma propriedade contraintuitiva dos modelos 3D: no disco e na VRAM, eles têm tamanhos completamente diferentes.
Uma imagem JPG pode ter apenas 200KB no disco. Mas a GPU não entende JPG; ela só entende pixels brutos. Portanto, antes de ser carregada na VRAM, a imagem é completamente descomprimida. Uma textura de 2048x2048 consome cerca de 22MB de VRAM após a descompressão. Se você usar 6 texturas (albedo, normal, roughness, metallic, AO, emissive), um único material custa 132MB.
Um celular pode ter apenas 2-4GB de VRAM no total, e as texturas de um único modelo consomem 3-6% disso. Agora imagine 10 modelos na cena.
Detalhando: para onde vão os bytes
Um modelo GLB típico tem três partes principais: dados de vértices, texturas e metadados mais animações.
Pegue um modelo PBR real:
| Componente | O que é | Proporção típica | Observações |
|---|---|---|---|
| Texturas | albedo, normal, roughness, metallic, AO, etc. | 70-85% | Quase sempre a maior parte |
| Dados de vértices | posição, normal, UV, tangente, cor | 10-20% | Depende da complexidade do modelo |
| Dados de animação | esqueletos, skinning, quadros-chave | 0-15% | Somente quando animado |
| Outros | definições de material, estrutura da cena, câmeras | < 2% | Irrelevante |
Texturas ocupam cerca de 80%. Muitas vezes você pensa que são os vértices que precisam de otimização, mas o que realmente ocupa o espaço são as texturas.
"Pequeno no disco" não significa "pequeno na VRAM"
Este pode ser o ponto mais importante para entender o desempenho 3D.
PNG e JPG são projetados para transferência pela web—pequenos no disco, rápidos para baixar. Mas a GPU não pode usá-los diretamente; eles precisam ser completamente descomprimidos em pixels brutos primeiro. A fórmula:
VRAM = largura * altura * 4 bytes (RGBA) * 1.333 (com mipmaps)
Uma textura RGBA de 4096x4096:
| Métrica | Valor |
|---|---|
| Tamanho do arquivo PNG | ~8MB |
| Tamanho do arquivo JPG | ~1.5MB |
| Uso de VRAM (com mipmaps) | ~87MB |
Um JPG de 1.5MB se torna 87MB na VRAM.
O que são mipmaps? A GPU gera uma série de versões progressivamente menores de uma textura, do tamanho original até um pixel 1x1, cada nível com metade do anterior. Isso torna o render de objetos distantes mais rápido e nítido, mas custa cerca de 33% mais VRAM. Quase todo aplicativo 3D usa mipmaps, então essa sobrecarga é essencialmente padrão.
Então PNG e JPG são como sacos de vácuo—comprimidos pequenos para a viagem, mas você precisa expandi-los completamente ao chegar ao destino. O download ficou mais rápido, mas economia de VRAM: zero.
O que acontece quando a VRAM acaba
Você não receberá um elegante diálogo de "memória insuficiente". A realidade é pior:
- Mobile: tela branca, ou o sistema operacional mata a aba diretamente
- Óculos de VR: queda de quadros. No VR, um quadro perdido não é "um pouco de lag"—ele causa enjoo
- Desktop: cintilação de texturas, degradação, renderização mais lenta
No Reddit, um desenvolvedor criou uma galeria WebXR e enfiou 60 imagens estereoscópicas em um Quest. Funcionou no início, depois ficou cada vez mais instável até travar. Ele passou dias depurando seu código antes de perceber que nunca havia pensado seriamente sobre VRAM—simplesmente continuava empurrando JPGs para a GPU.
Dois caminhos para compressão
A compressão de modelos 3D se divide em duas direções:
Compressão de vértices—armazena dados geométricos (coordenadas de vértices, normais, UVs) de forma mais compacta. Por exemplo, trocar floats de 32 bits por inteiros de 16 bits (isso se chama quantização). Soluções representativas: Draco, MeshOpt, KHR_mesh_quantization.
Compressão de texturas—mantém as texturas comprimidas mesmo dentro da VRAM. A GPU decodifica blocos individuais de pixels em tempo real durante a amostragem, com custo de desempenho praticamente zero. Solução representativa: KTX2 + Basis Universal.
| Compressão de vértices | Compressão de texturas | |
|---|---|---|
| O que reduz | Dados geométricos | Texturas |
| Efeito típico | 50-90% menor | 50-70% menor no disco, 75% menos VRAM |
| Com perdas? | Sim, perda de precisão | Sim, perda de qualidade |
| Melhor para | Modelos com muitos vértices | Quase todo modelo PBR |
| Ver | Parte 2 | Partes 3 e 4 |
Um equívoco comum: comprimir os vértices com Draco e considerar pronto. Mas texturas são 80% do tamanho do modelo—reduzir os vértices pela metade pode fazer o todo encolher apenas 10%. Você precisa trabalhar nos dois lados.
Nenhum método vence em todos os cenários
Este é o tema central de toda a série:
Plataformas diferentes, dispositivos diferentes, casos de uso diferentes exigem estratégias de compressão diferentes.
| Cenário | Gargalo principal | Foco |
|---|---|---|
| Apresentação web desktop | Velocidade de download | Tamanho do arquivo |
| Navegador mobile | VRAM | Compressão de texturas |
| Óculos de VR | VRAM + taxa de quadros | Compressão de texturas + simplificação de vértices |
| Mini Programa WeChat | Tamanho do pacote + compatibilidade | Opções leves (MeshOpt) |
| Cenas grandes | VRAM + chamadas de desenho | Compressão completa + LOD |
Cada artigo a seguir não vai apenas dizer "use X e pronto". Vai explicar: onde X brilha, quando realmente causa problemas e quando você deve recorrer a Y.
Próximo passo
Este artigo definiu o problema. O próximo será prático—conhecer as três ferramentas da compressão de vértices: quantização, MeshOpt e Draco.