Por que os modelos 3D são tão pesados?
Seu modelo está engordando escondido
Você exportou um arquivo GLB, 10MB, até que parece ok. Mandou pro celular e abriu — tela branca, lag, ou simplesmente crashou.
No desktop funciona, no celular explode. Isso não é culpa do código, é uma característica nada intuitiva dos modelos 3D: o tamanho no disco e o tamanho na memória da GPU são completamente diferentes.
Uma imagem JPG no disco pode ter só 200KB. Mas a GPU não entende JPG, ela só conhece pixels brutos. Então antes de subir pra VRAM, a imagem é totalmente descomprimida. Uma textura 2048x2048, descomprimida, consome cerca de 22MB de VRAM. Se você usa 6 mapas (albedo, normal, roughness, metallic, AO, emissive), só um material já pesa 132MB.
O celular tem talvez 2-4GB de VRAM no total. As texturas de um modelo já comem 3-6%. E se a cena tiver 10 modelos?
Abrindo o modelo: pra onde vai o peso
Um GLB típico tem três partes principais: dados de vértice, texturas, e metadados/animações.
Pegando um modelo PBR real:
| Componente | O que inclui | % típica | Descrição |
|---|---|---|---|
| Texturas | albedo, normal, roughness, metallic, AO, etc. | 70-85% | Quase sempre o vilão |
| Vértices | posição, normal, UV, tangente, cor | 10-20% | Depende da complexidade |
| Animação | ossos, skinning, keyframes | 0-15% | Só se tiver animação |
| Outros | definição de materiais, estrutura da cena, câmera | < 2% | Desprezível |
Texturas respondem por cerca de 80% do peso. Muita gente acha que precisa otimizar vértices, mas o que realmente ocupa espaço são as texturas.
"Disco pequeno" ≠ "VRAM pequena"
Esse é talvez o ponto mais importante pra entender performance 3D.
PNG e JPG foram feitos pra transmissão na rede — pequenos no disco, download rápido. Mas a GPU não pode usá-los diretamente, precisa descomprimir tudo em pixels brutos. A conta é:
VRAM usada = largura * altura * 4 bytes (RGBA) * 1.333 (com mipmap)
Uma textura RGBA de 4096x4096:
| Métrica | Valor |
|---|---|
| Tamanho do arquivo PNG | ~8MB |
| Tamanho do arquivo JPG | ~1.5MB |
| VRAM usada (com mipmap) | ~87MB |
Um JPG de 1.5MB vira 87MB na VRAM.
O que é Mipmap? A GPU gera uma série de versões reduzidas da textura, do tamanho original até 1x1 pixel, cada nível com metade do anterior. Isso deixa a renderização de objetos distantes mais rápida e nítida, mas custa cerca de 33% a mais de VRAM. Quase toda aplicação 3D usa mipmap, então esse custo é praticamente padrão.
Ou seja: PNG/JPG são como saco a vácuo de viagem — comprime tudo pra caber na mala, mas ao chegar no destino você precisa estufar tudo de novo. O download é rápido, mas a VRAM não economiza nada.
O que acontece quando falta VRAM
Não aparece uma janelinha "memória insuficiente". A realidade é pior:
- Mobile: tela branca, ou o sistema simplesmente mata a aba do navegador
- VR headsets: queda de frames. Em VR, drop de frame não é "um pouco lagado", é enjoo na hora
- Desktop: texturas piscando, degradando, render mais lento
Tinha um dev no Reddit fazendo uma galeria WebXR, enfiou 60 fotos estereoscópicas no Quest. No começo funcionava, depois foi ficando instável até crashar. Ele passou dias caçando bug no código, até perceber que nunca tinha pensado em VRAM — ficou o tempo todo empurrando JPG pra GPU.
Os dois caminhos da compressão
Compressão de modelos 3D tem dois rumos principais:
Compressão de vértices — armazenar coordenadas, normais, UVs e outros dados geométricos 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 — fazer com que as texturas permaneçam comprimidas também na VRAM. A GPU decodifica pixels individuais em tempo real, quase sem custo de performance. Soluções representativas: KTX2 + Basis Universal.
| Compressão de vértices | Compressão de texturas | |
|---|---|---|
| O que reduz | Dados geométricos | Texturas |
| Efeito típico | Reduz 50-90% | Disco -50-70%, VRAM -75% |
| Com perdas? | Sim, perde precisão | Sim, perde qualidade visual |
| Quando usar | Modelos com muitos vértices | Quase todo modelo PBR |
| Detalhes | Parte 2 | Partes 3 e 4 |
Um erro comum: achar que comprimir vértices com Draco resolve tudo. Mas se a textura é 80% do peso do modelo, você corta os vértices pela metade e o total emagrece só 10%. Precisa cuidar dos dois lados.
Nenhum método serve pra tudo
Essa é a ideia central da série:
Plataformas, dispositivos e casos de uso diferentes exigem estratégias de compressão diferentes.
| Cenário | Gargalo principal | Foco principal |
|---|---|---|
| Web no desktop | Velocidade de download | Tamanho do arquivo |
| Navegador mobile | VRAM | Compressão de texturas |
| VR headset | VRAM + frame rate | Compressão de texturas + simplificação de vértices |
| Mini-apps (WeChat) | Tamanho do pacote + compatibilidade | Soluções leves (MeshOpt) |
| Cenas grandes | VRAM + draw calls | Compressão completa + LOD |
Cada artigo daqui pra frente não vai só dizer "use X e pronto". Vai explicar: pra que cenário X serve, quando ele atrapalha, e em que caso você deveria usar Y.
Próximo passo
Esse artigo esclareceu o problema. O próximo é mão na massa — conhecer as três ferramentas de compressão de vértices: quantização, MeshOpt e Draco.