Any3DAny3D
·Any3D Team

Por Que os Modelos 3D São Tão Pesados?

3d-compressiongltfwebglperformance

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:

ComponenteO que éProporção típicaObservações
Texturasalbedo, normal, roughness, metallic, AO, etc.70-85%Quase sempre a maior parte
Dados de vérticesposição, normal, UV, tangente, cor10-20%Depende da complexidade do modelo
Dados de animaçãoesqueletos, skinning, quadros-chave0-15%Somente quando animado
Outrosdefiniçõ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étricaValor
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érticesCompressão de texturas
O que reduzDados geométricosTexturas
Efeito típico50-90% menor50-70% menor no disco, 75% menos VRAM
Com perdas?Sim, perda de precisãoSim, perda de qualidade
Melhor paraModelos com muitos vérticesQuase todo modelo PBR
VerParte 2Partes 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árioGargalo principalFoco
Apresentação web desktopVelocidade de downloadTamanho do arquivo
Navegador mobileVRAMCompressão de texturas
Óculos de VRVRAM + taxa de quadrosCompressão de texturas + simplificação de vértices
Mini Programa WeChatTamanho do pacote + compatibilidadeOpções leves (MeshOpt)
Cenas grandesVRAM + chamadas de desenhoCompressã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.

Apoie-nos