Como otimizar arquivos GLB para a web: Draco, Meshopt e KTX2 (2026)

Última atualização: setembro de 2026.

Para otimizar um GLB para a web, siga esta ordem: primeiro reduza as texturas (limite-as a 1024 ou 2048 e recodifique-as como WebP para diminuir o tamanho do download ou como KTX2 para reduzir o uso de memória da GPU), quantize os dados dos vértices, comprima a geometria com Meshopt (ou Draco, quando economizar as últimas centenas de quilobytes for mais importante do que o tempo de decodificação), simplifique a malha caso a contagem de triângulos ainda seja absurda e, então, remova o que não é usado, elimine duplicatas e una o que restou. Um comando faz a maior parte disso: gltf-transform optimize in.glb out.glb --texture-compress webp. A ordem importa porque as texturas geralmente representam 80% ou mais do arquivo e toda a memória de vídeo.

Resposta rápida

• Modelo com muitas texturas (a maioria dos modelos): redimensione para 1024 ou 2048 e, depois, use gltf-transform webp. Se houver travamentos ou engasgos em celulares, converta para KTX2 — no navegador com o compressor KTX2 ou com gltf-transform etc1s/uastc.
• Modelo com muita geometria (escaneamentos, CAD, gerados por IA): use gltf-transform simplify e, depois, meshopt. O Draco comprime um pouco mais, mas decodifica mais devagar e exige um decodificador dez vezes maior.
• Personagem animado: Meshopt, não Draco. O Draco não altera trilhas de animação nem morph targets.
• O arquivo precisa abrir em uma engine que você não controla: use gltf-transform quantize. Não há decodificador, apenas KHR_mesh_quantization, compatível com todos os loaders citados aqui.
• Sem terminal: o otimizador de GLB executa remoção de dados não usados, soldagem, união, simplificação, redimensionamento de texturas para WebP e Meshopt no navegador, exibindo o tamanho a cada etapa.

Referência rápida

	Somente quantização	Meshopt	Draco
Extensão	KHR_mesh_quantization	EXT_meshopt_compression (+ quantização)	KHR_draco_mesh_compression
O que comprime	Atributos de vértices (menos bits)	Vértices, índices, morph targets, animação	Somente geometria de malha triangular
Tamanho em nosso modelo de teste de 28 MB	22,8 MB (8,1 MB com gzip)	5,1 MB (3,3 MB com gzip)	2,6 MB (2,5 MB com gzip)
Decodificador	Nenhum	Módulo JS de 32 KB com WASM incorporado	192 a 286 KB de WASM mais um wrapper de 58 KB e fallback JS de 719 KB
Velocidade de decodificação	Instantânea; a GPU lê os dados diretamente	Cerca de 1 GB/s com WASM SIMD, segundo a especificação	Consideravelmente mais lento que o Meshopt, segundo a documentação do glTF-Transform
Precisa de gzip/brotli no servidor	Ajuda bastante	Sim, foi projetado para isso	Pouco benefício
Loaders	three.js, Babylon.js, PlayCanvas, glTFast	three.js r122+, Babylon.js 5.0+, glTFast (pacote adicional), não PlayCanvas	three.js, Babylon.js, PlayCanvas, glTFast (pacote adicional)

Os mesmos números em barras, acompanhados dos resultados do gltfpack e da simplificação em nosso comparativo.

O Draco ganha em número de bytes, mas o gzip quase não oferece benefício adicional, enquanto as saídas do Meshopt e da quantização dependem do compressor do servidor. A simplificação é a única etapa que altera a contagem de triângulos; portanto, seus 8,1 MB são um novo ponto de partida, não a linha de chegada.

Para onde vão os bytes em um GLB

Execute gltf-transform inspect model.glb antes de qualquer outra coisa. Ele lista cada malha com a contagem de vértices e os tipos de atributos, cada textura com seu tamanho codificado e gpuSize e cada animação com sua contagem de keyframes. Os números deste guia vêm da documentação das ferramentas e das especificações das extensões, além de um comparativo que realizamos esta semana com gltf-transform 4.5.0 e gltfpack 1.2 em dois arquivos reais. Eles mostram os dois tipos de cenário que você encontrará.

Um objeto de cena do Sketchfab com 2,2 MB (um copo low-poly) tinha 680 triângulos e 39 KB de geometria. Os outros 2,18 MB correspondiam a três PNGs de 1024×1024; portanto, as texturas representavam 98% do arquivo, e o inspect estimou 5,59 MB de VRAM para cada uma depois da geração de mipmaps. Esse é o caso mais comum para assets feitos manualmente.

Uma saída do TRELLIS.2 com 28,7 MB era o oposto: 978.226 triângulos e 27,5 MB de geometria float32, com apenas 1,1 MB de texturas. Porém, essas duas texturas tinham 4096×4096, o que, segundo o inspect, resulta em 89,5 MB de VRAM para cada uma. Modelos do gerador de modelos 3D e de ferramentas semelhantes frequentemente chegam assim, densos e com texturas grandes demais. Por isso, eles precisam das etapas de geometria e também das etapas de textura.

A linha “típica” é a regra geral; as outras duas representam os arquivos reais do comparativo. Observe a coluna da direita: as texturas de 1024 do copo e as texturas de 4096 do TRELLIS.2 são pequenas no disco, mas têm usos de memória de vídeo extremamente diferentes.

Observe que o tamanho codificado da textura e seu tamanho na GPU não têm relação entre si. Um PNG de 4 MB e um WebP de 200 KB da mesma imagem de 2048×2048 ocupam cerca de 22 MB na memória de vídeo: pixels brutos mais mipmaps. Somente o KTX2 altera esse número.

As seis etapas abaixo são executadas nesta ordem porque cada uma reduz o que a próxima terá de processar.

Siga os números de cima para baixo. As etapas 1 e 4 concentram a maior parte dos bytes, a etapa 2 é imperceptível, exceto em uma única malha gigantesca, e a etapa 5 deve ser executada com cuidado em um personagem com rig, pois a união funde partes que deveriam se mover.

Etapa 1: texturas

Dois problemas distintos, duas soluções distintas.

O tamanho do download é reduzido redimensionando e recodificando. Poucos objetos de cena precisam de mais de 1024×1024, e até um personagem principal raramente precisa de mais de 2048. gltf-transform resize --width 1024 --height 1024 limita as dimensões sem jamais ampliá-las, e gltf-transform webp faz a recodificação com sharp. No copo, apenas o WebP reduziu o arquivo de 2,23 MB para 246 KB. Redimensioná-lo primeiro para 512 reduziu o tamanho para 96 KB, sem mudança visível em um objeto desse porte. O WebP exige EXT_texture_webp, que os motores web conseguem ler, mas o glTFast da Unity não (sua tabela de recursos diz que ele "não terá suporte").

A memória da GPU e o tempo de upload só são reduzidos pelo KTX2 com supercompressão Basis Universal, que mantém a textura em um formato de blocos da GPU até a VRAM, usando de 4 a 8 vezes menos memória que RGBA bruto. Ele tem uma seção própria abaixo porque as configurações fazem diferença.

Um cuidado revelado pelos testes comparativos: gltf-transform optimize usa --texture-compress auto por padrão, o que recodifica as texturas no formato original. No copo, isso aumentou os PNGs e fez o arquivo crescer de 2,2 MB para 2,8 MB. Informe webp ou ktx2 explicitamente.

Etapa 2: quantização

A quantização armazena cada atributo de vértice usando menos bits. Uma posição deixa de ser composta por três floats de 32 bits e passa a usar três inteiros de 16 bits, com a escala e o deslocamento incorporados à transformação do nó (ou a inverseBindMatrices em malhas com skin). A especificação KHR_mesh_quantization estima aproximadamente 20 bytes por vértice típico, em vez de 48. É uma extensão Khronos ratificada e não exige decodificador: a GPU lê os atributos inteiros diretamente, portanto os arquivos quantizados ocupam menos VRAM e também são menores na transferência.

Os padrões do glTF-Transform são 14 bits para posições, 10 para normais e tangentes, 12 para UVs e 8 para cores e pesos. Os do gltfpack são 14, 8, 12 e 8. Ambos são imperceptíveis, exceto em uma única malha gigantesca, na qual 14 bits distribuídos por toda a extensão podem causar facetamento. Sozinha, a quantização produz um ganho modesto: nosso modelo de 28 MB caiu para 22,8 MB bruto e 8,1 MB com gzip. Sua verdadeira função é ser a primeira metade do Meshopt e uma saída segura quando há dúvidas sobre o loader de destino. O Draco faz a quantização internamente com os mesmos padrões, portanto não execute quantize antes de draco.

Etapa 3: Meshopt ou Draco

Ambos são codecs de geometria com perdas que decodificam para buffers comuns antes do upload para a GPU, portanto nenhum deles faz o modelo renderizar mais rápido. Eles reduzem o download. As diferenças estão no que comprimem, na velocidade de decodificação e no tamanho do decodificador que você envia.

O Meshopt (EXT_meshopt_compression) opera no nível de bufferView, portanto atributos de vértice, índices, deltas de morph targets e keyframes de animação são todos comprimidos. Ele foi projetado para ficar sobre a quantização e sob gzip ou brotli: o codec regulariza os bytes e o compressor de uso geral da CDN faz o restante. A especificação cita velocidades de decodificação próximas de 1 GB/s com WebAssembly SIMD, e o decodificador do three.js é um único módulo de 32 KB. No modelo de teste: 5,1 MB bruto e 3,3 MB com gzip, no --level high padrão.

O Draco (KHR_draco_mesh_compression) comprime apenas primitivas de malhas triangulares. Animações, morph targets, pontos e linhas passam sem alterações. Ele comprime mais: 2,6 MB no mesmo modelo, e o gzip quase não ajuda porque a saída já é densa. O custo está no tempo de decodificação e no peso do decodificador: a documentação do glTF-Transform afirma claramente que a decodificação do Meshopt é consideravelmente mais rápida, e o decodificador WASM incluído pelo three.js tem 286 KB (192 KB na compilação da ramificação glTF), além de um wrapper de 58 KB e um fallback em JavaScript de 719 KB. O Draco também reordena os vértices e pode alterar sua quantidade.

Portanto: Meshopt para qualquer conteúdo animado, qualquer conteúdo com morph targets, qualquer caso em que o objetivo seja reduzir o tempo de carregamento em um celular e qualquer conteúdo servido com brotli ativado. Draco quando o asset é uma malha estática, a geometria representa a maior parte do tamanho e uma redução de 20% a 30% na transferência compensa um primeiro frame mais lento. Não tem certeza? Use Meshopt. O -cc do gltfpack (Meshopt em seu modo mais forte) chegou a 4,4 MB bruto e 3,1 MB com gzip no mesmo arquivo.

Etapa 4: simplificação

Se o modelo ainda for grande após a compressão, ele tem triângulos demais, e nenhum codec resolve isso. As duas ferramentas usam o simplificador do meshoptimizer, que recebe uma proporção-alvo e um limite de erro e para quando atinge o primeiro deles.

gltf-transform simplify --ratio 0.25 --error 0.01 busca manter 25% dos vértices com um desvio de até 1% do raio da malha. No modelo de 978 mil triângulos, isso resultou em 244.556 triângulos e 8,1 MB antes da compressão, com aparência idêntica à distância de jogo. Os padrões de optimize são mais agressivos do que você talvez imagine: --simplify-ratio 0 com --simplify-error 0.0001, o que significa "remover o máximo possível dentro de um erro de 0,01%". No mesmo modelo com tesselação excessiva, isso o reduziu a 6.582 triângulos, pois o gerador havia usado quase um milhão de triângulos em superfícies planas. Solde antes de simplificar (optimize faz isso), pois vértices separados interrompem o simplificador nas costuras.

O -si 0.25 do gltfpack segue a mesma ideia, com -se 0.01 como limite de erro padrão, -sa para atingir a proporção independentemente da qualidade e -slb para travar os vértices das bordas, evitando que malhas modulares abram lacunas. Objetos hard surface toleram facilmente uma redução de 50%, malhas digitalizadas e geradas por IA normalmente toleram a remoção de 90%, e personagens com rig exigem cuidado perto das articulações, pois recolher vértices também recolhe os pesos de skin.

Etapa 5: remova, elimine duplicatas, una e instancie

Esses são ganhos gratuitos, e optimize executa todos eles. prune remove materiais, texturas, accessors e nós que não são referenciados por nada, além de converter texturas de cor única em fatores do material. dedup combina accessors e texturas idênticos que um exportador gravou duas vezes. flatten achata a hierarquia, e join combina malhas que compartilham um material, reduzindo 200 draw calls a apenas algumas. instance (a partir de 5 cópias) converte malhas repetidas em EXT_mesh_gpu_instancing, e palette combina materiais que diferem apenas na cor.

Não use join nem flatten em um personagem com rig ou em qualquer elemento que o jogo mova em partes, pois as partes desaparecem em uma única malha. A saída no gltfpack é -kn (manter nós nomeados) e -km (manter materiais nomeados).

Etapa 6: animação

Os exportadores frequentemente geram um keyframe em cada frame. gltf-transform resample remove keyframes que ficam sobre a linha entre seus vizinhos (tolerância 1e-4 por padrão), o que na prática não causa perdas. O -af 30 do gltfpack reamostra cada trilha a 30 Hz e quantiza translações para 16 bits, rotações para 12 e escala para 16 (-at, -ar, -as) antes que o Meshopt as comprima. Em um personagem típico com alguns clipes, essa etapa tem pouco impacto. Em uma biblioteca de movimentos, ela pode eliminar a maior parte dos bytes.

As linhas de comando

A CLI do glTF-Transform é instalada com npm install --global @gltf-transform/cli ou executada com npx @gltf-transform/cli. Tudo de uma vez:

gltf-transform optimize in.glb out.glb --texture-compress webp --texture-size 1024

Isso executa, nesta ordem, dedup, instance, palette, flatten, join, weld, simplify (proporção 0, erro 0,0001), resample, prune, sparse, compressão de texturas com limite de 1024 e Meshopt no nível high. Adicione --compress draco para usar Draco, --compress quantize para usar apenas quantização, --no-join --no-flatten para modelos com rig ou articulados, --simplify false se a silhueta for mais importante que o tamanho, e --texture-compress ktx2 se o KTX-Software estiver instalado.

As etapas individuais, quando você quiser mais controle:

gltf-transform inspect in.glb
gltf-transform resize in.glb a.glb --width 1024 --height 1024
gltf-transform webp a.glb b.glb --quality 80
gltf-transform weld b.glb c.glb
gltf-transform simplify c.glb d.glb --ratio 0.5 --error 0.001
gltf-transform meshopt d.glb out.glb --level high

Troque a última linha por gltf-transform draco d.glb out.glb (--encode-speed e --decode-speed vão de 0 a 10, com padrão 5; valores menores geram arquivos menores) ou gltf-transform quantize d.glb out.glb.

O gltfpack é instalado com npm install -g gltfpack ou como um binário nativo disponibilizado nas versões do meshoptimizer, opção recomendada pelo README para arquivos grandes. Seus padrões já fazem a quantização, otimizam a ordem dos vértices para o cache da GPU e combinam malhas:

gltfpack -i in.glb -o out.glb -cc -si 0.5 -tw -tl 1024 -kn

-cc é o Meshopt no modo de compressão mais alta (-c é o modo rápido, e -cf adiciona um fallback não comprimido para loaders sem o decodificador). -si 0.5 reduz pela metade os triângulos dentro de -se 0.01. -tw converte as texturas para WebP, e -tl 1024 limita seu tamanho. -kn mantém os nós nomeados. Para KTX2, troque -tw por -tc (ETC1S) ou -tc -tu (UASTC), o que exige uma compilação do gltfpack vinculada ao Basis Universal.

Se nenhuma das CLIs for uma opção, a ferramenta para navegador executa a mesma sequência.

A opção sem terminal: remoção, soldagem, união, simplificação, redimensionamento de texturas para WebP e Meshopt no navegador, com o tamanho exibido após cada etapa para que você veja qual delas fez a diferença.

KTX2: ETC1S ou UASTC

KTX2 é o contêiner da Khronos para texturas de GPU. Com a supercompressão Basis Universal, a textura é transcodificada durante o carregamento para o formato de blocos disponível no dispositivo (BC em desktops, ASTC ou ETC2 em dispositivos móveis) e permanece comprimida na memória. A extensão glTF é KHR_texture_basisu. O Basis tem dois modos. ETC1S é o mais compacto: o README do Basis indica aproximadamente 0,3 a 3 bits por pixel em disco, com um ajuste de qualidade semelhante ao do JPEG (1 a 255, padrão 128), e na memória ele ocupa 4 bits por pixel em formatos como BC1 e ETC1. Use-o para a cor base de objetos de cena. UASTC é o modo de maior qualidade: 8 bits por pixel na memória, um subconjunto de 19 modos do ASTC 4×4, com níveis de qualidade de 0 a 4 (padrão 2, que a ajuda do glTF-Transform lista como 47,47 dB). Os arquivos UASTC são grandes em disco, então combine-os com Zstandard: o comando uastc do glTF-Transform usa --zstd 18 por padrão, e ktx create --zstd aceita valores de 1 a 22.

O cálculo para uma textura de 2048×2048 com mipmaps: cerca de 22 MB como RGBA8, cerca de 5,6 MB como UASTC e cerca de 2,8 MB como ETC1S transcodificado para um formato de 4 bpp.

Três regras são importantes. Mapas de normais e de dados devem usar UASTC e espaço linear. O glTF-Transform alerta que mapas de normais RGB e mapas de oclusão/rugosidade/metallicidade podem ficar ruins com ETC1S, e a especificação exige que texturas de cor sejam marcadas como sRGB e dados que não representam cores, como lineares. O glTF-Transform configura isso por slot para você. No compressor KTX2, essa é a opção sRGB: ativada para cores e desativada para mapas de normais e de dados. As dimensões devem ser múltiplos de 4, sendo recomendadas potências de dois. Gere mipmaps. A especificação determina que um KTX2 usado com minificação por mipmaps deve conter a pirâmide completa; caso contrário, o motor precisa descompactá-lo e gerá-la em tempo de execução. Os mipmaps ficam ativados por padrão no glTF-Transform e na ferramenta do navegador, e são habilitados por --generate-mipmap no ktx create.

Os comandos do glTF-Transform exigem o binário ktx do KTX-Software, versão 4.4.0 ou posterior:

gltf-transform uastc in.glb a.glb --level 2 --zstd 18 --slots "{normalTexture,occlusionTexture,metallicRoughnessTexture}"
gltf-transform etc1s a.glb out.glb --quality 128

Primeiro, aplique UASTC aos slots de dados; depois, ETC1S ao restante. Essa divisão — ETC1S para cor base e emissão, e UASTC para normais e ORM — é a mais comum.

Como carregar o resultado

Todos os codecs, exceto a quantização, precisam de um decodificador no cliente.

three.js. O GLTFLoader lê KHR_mesh_quantization e EXT_texture_webp sem nenhuma configuração. Para os demais, você conecta decodificadores, que vêm no pacote three, em examples/jsm/libs/, nas pastas ou arquivos draco/, basis/ e meshopt_decoder.module.js. Copie draco/ e basis/ para um caminho público e então use:

import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js'
import { DRACOLoader } from 'three/addons/loaders/DRACOLoader.js'
import { KTX2Loader } from 'three/addons/loaders/KTX2Loader.js'
import { MeshoptDecoder } from 'three/addons/libs/meshopt_decoder.module.js'

const draco = new DRACOLoader().setDecoderPath('/libs/draco/')
const ktx2 = new KTX2Loader().setTranscoderPath('/libs/basis/').detectSupport(renderer)
const loader = new GLTFLoader()
  .setDRACOLoader(draco)
  .setKTX2Loader(ktx2)
  .setMeshoptDecoder(MeshoptDecoder)

O DRACOLoader escolhe o decodificador WASM quando o navegador oferece suporte e recorre ao JavaScript como alternativa. detectSupport(renderer) permite que o KTX2Loader escolha o formato de transcodificação adequado à GPU do dispositivo.

Babylon.js. O carregador de glTF lida com Draco, Meshopt (desde a versão 5.0, sem configuração) e KTX2 baixando os decodificadores de https://cdn.babylonjs.com e executando-os em web workers. Para hospedá-los por conta própria, defina Tools.CDNBaseUrl ou configure-os individualmente: DracoDecoder.DefaultConfiguration (wasmUrl, wasmBinaryUrl, fallbackUrl), MeshoptCompression.Configuration.decoder.url e KhronosTextureContainer2.URLConfig para o conjunto de transcodificadores KTX2. Com npm, @babylonjs/ktx2decoder inclui os transcodificadores.

PlayCanvas. O Draco é configurado com dracoInitialize({ jsUrl, wasmUrl, numWorkers, lazyInit }), e o Editor pode aplicar compressão Draco durante a importação. O KTX2 usa basisInitialize({ glueUrl, wasmUrl, fallbackUrl }). EXT_meshopt_compression não faz parte do analisador de GLB no motor 2.x (a solicitação do recurso feita em 2020 continua em aberto), portanto, para PlayCanvas, escolha Draco ou uma saída apenas com quantização.

Unity. O importador oficial é o glTFast (com.unity.cloud.gltfast). KHR_mesh_quantization funciona sem configuração, Draco exige com.unity.cloud.draco, KTX2 exige com.unity.cloud.ktx e Meshopt exige com.unity.meshopt.decompress. WebP não é compatível por decisão de projeto; portanto, para um projeto destinado ao Unity, use KTX2.

Metas para um jogo web mobile

Não existe uma especificação para isso, mas há números que funcionam bem em celulares. Mantenha toda a primeira cena abaixo de aproximadamente 10 MB transferidos pela rede e carregue o restante por streaming (o tutorial de carregamento de assets por streaming aborda as camadas, as filas de prioridade e o código). Mantenha o uso de VRAM das texturas abaixo de 150 a 200 MB, o equivalente a quatro ou cinco texturas 2048 em RGBA8 ou trinta em ETC1S. Mantenha objetos de cena abaixo de 5.000 triângulos, um personagem principal abaixo de 30.000 a 50.000 e as draw calls na casa das poucas centenas. Use texturas 1024 para objetos de cena e reserve 2048 apenas para aquilo de que a câmera se aproxima. Sirva os GLBs com Brotli ou gzip ativado, pois o Meshopt e a saída quantizada dependem disso.

Verifique antes de publicar

O tamanho do arquivo é o número mais fácil de conferir. Abra o resultado no visualizador de GLB e examine o restante: o painel Extensions confirma se EXT_meshopt_compression, KHR_draco_mesh_compression ou KHR_texture_basisu realmente foi incluída no arquivo; a aba Textures lista cada textura por seu custo real de VRAM, da maior para a menor; e a barra de status mostra a contagem de draw calls e triângulos em tempo real. Depois, verifique as silhuetas e as costuras de UV em busca de artefatos de simplificação na distância em que o jogador verá os modelos, e reproduza todas as animações para garantir que a união não fundiu uma parte que deveria se mover. Se o arquivo de origem não era um GLB, passe primeiro o FBX ou OBJ pelo conversor de FBX para GLB, para que você compacte o arquivo que realmente será carregado.

Abra aqui a saída compactada para confirmar se a extensão realmente foi incluída no arquivo; depois, consulte as draw calls e a contagem de triângulos na barra de status e o custo real de VRAM de cada textura na aba Textures.

Perguntas frequentes

Como reduzir o tamanho de um arquivo GLB?

Execute gltf-transform inspect para descobrir se as texturas ou a geometria são responsáveis pela maior parte do tamanho. Se forem as texturas, redimensione-as para 1024 ou 2048 e converta-as para WebP ou KTX2. Se for a geometria, simplifique-a e depois compacte-a com Meshopt ou Draco. gltf-transform optimize in.glb out.glb --texture-compress webp executa toda a sequência, e o otimizador de GLB faz isso no navegador, sem instalação.

Draco ou Meshopt: qual é melhor?

Meshopt para a maioria dos jogos web. Ele decodifica muito mais rápido, usa um decodificador de 32 KB em vez de algumas centenas de quilobytes de WASM e compacta animações e morph targets, que o Draco ignora. O Draco produz arquivos menores para malhas estáticas (2,6 MB contra 3,3 MB com gzip em nosso modelo de teste de 28 MB) e é a opção compatível com PlayCanvas. Portanto, ele vence quando o asset é uma digitalização estática e a geometria representa a maior parte dos bytes.

O que é KTX2 e como ele difere do Basis?

Basis Universal é o codec de compressão, com dois modos: ETC1S e UASTC. KTX2 é o arquivo contêiner da Khronos que armazena dados de textura compactados com Basis, além de mipmaps e metadados, e é o formato referenciado pelo glTF por meio de KHR_texture_basisu. Pipelines mais antigos usavam um arquivo .basis avulso. Use .ktx2.

Devo usar ETC1S ou UASTC?

Use ETC1S para a cor base e tudo o que não será visto de perto: arquivos pequenos e 4 bits por pixel na VRAM. Use UASTC para mapas de normais, rugosidade/metallicidade/oclusão e texturas de elementos principais, com supercompressão Zstandard ativada para manter o download em um tamanho razoável. Marque texturas de cor como sRGB e texturas de dados como lineares; caso contrário, o sombreamento das normais ficará incorreto.

Como compactar texturas glTF?

Para reduzir o tamanho do download, use gltf-transform resize e depois gltf-transform webp. Para reduzir o uso de memória da GPU, use gltf-transform etc1s ou uastc com o KTX-Software instalado, ou solte os PNGs no compressor KTX2. Em qualquer caso, limite primeiro as dimensões: uma textura 4096 ocupa 89 MB de VRAM como RGBA8, e quase nunca há motivo para enviar uma dessas em um navegador.

Por que meu GLB é grande demais para o three.js em dispositivos móveis?

Geralmente, o problema não é o tamanho do arquivo, mas a memória das texturas. Quatro texturas 2048 em RGBA ocupam cerca de 90 MB de VRAM antes mesmo de a cena renderizar qualquer coisa, e navegadores de celulares encerram a aba ao ultrapassar algumas centenas de megabytes. Converta para KTX2 para que as texturas permaneçam compactadas na GPU, limite-as a 1024 quando possível e chame KTX2Loader.detectSupport(renderer) para transcodificá-las para o formato do dispositivo.

O gltfpack faz a mesma coisa que o gltf-transform?

Em grande parte. O gltfpack é um único binário nativo do projeto meshoptimizer que, por padrão, quantiza, reordena vértices para o cache da GPU, combina malhas e aplica compressão Meshopt. O glTF-Transform é uma biblioteca Node e uma CLI com as mesmas operações como etapas separadas e automatizáveis por scripts, além de gerar saídas Draco, algo que o gltfpack não faz. Em nosso arquivo de teste, as saídas Meshopt dos dois ficaram a aproximadamente 10% uma da outra.

Conteúdo relacionado

• Carregamento de assets por streaming para jogos web: camadas, filas de prioridade e barras de progresso para os arquivos que você acabou de reduzir
• Stack de tecnologias para jogos web em 2026: WebGL, WebGPU, Wasm e formatos de assets no nível das APIs
• Sites gratuitos de modelos 3D: de onde vêm os modelos e por que eles chegam tão pesados
• Melhores geradores de modelos 3D com IA: o que os geradores produzem e qual é a densidade dos modelos
• Three.js vs. Babylon.js: ambos carregam Draco, Meshopt e KTX2, mas com configurações diferentes
• PlayCanvas vs. Three.js: motor versus biblioteca, incluindo pipelines de assets