Comment optimiser les fichiers GLB pour le Web : Draco, Meshopt et KTX2 (2026)

Dernière mise à jour : septembre 2026.

Pour optimiser un GLB pour le Web, procédez dans cet ordre : commencez par réduire les textures (limitez-les à 1024 ou 2048, puis réencodez-les en WebP pour réduire la taille du téléchargement ou en KTX2 pour économiser la mémoire GPU), quantifiez les données de sommets, compressez la géométrie avec Meshopt (ou Draco si gagner les dernières centaines de kilo-octets compte davantage que le temps de décodage), simplifiez le maillage si le nombre de triangles reste déraisonnable, puis élaguez, dédupliquez et fusionnez ce qui reste. Une seule commande se charge de l’essentiel : gltf-transform optimize in.glb out.glb --texture-compress webp. L’ordre est important, car les textures représentent généralement au moins 80 % du fichier et l’intégralité de la mémoire vidéo.

Réponse rapide

• Modèle riche en textures (la plupart des modèles) : redimensionnez-les à 1024 ou 2048, puis utilisez gltf-transform webp. Si le modèle saccade ou plante sur les téléphones, convertissez plutôt les textures en KTX2, dans le navigateur avec le compresseur KTX2 ou avec gltf-transform etc1s/uastc.
• Modèle riche en géométrie (scans, CAO, génération par IA) : utilisez gltf-transform simplify, puis meshopt. Draco produit des fichiers un peu plus petits, mais son décodage est plus lent et son décodeur est dix fois plus volumineux.
• Personnage animé : Meshopt, pas Draco. Draco ne modifie ni les pistes d’animation ni les cibles de morphing.
• Le fichier doit s’ouvrir dans un moteur que vous ne contrôlez pas : utilisez gltf-transform quantize. Aucun décodeur n’est nécessaire, seulement KHR_mesh_quantization, que tous les chargeurs présentés ici prennent en charge.
• Pas de terminal : l’optimiseur GLB exécute dans votre navigateur l’élagage, la soudure, la fusion, la simplification, le redimensionnement des textures en WebP et Meshopt, avec un relevé de la taille à chaque étape.

Référence rapide

	Quantification seule	Meshopt	Draco
Extension	KHR_mesh_quantization	EXT_meshopt_compression (+ quantification)	KHR_draco_mesh_compression
Ce qui est compressé	Attributs de sommets (moins de bits)	Sommets, indices, cibles de morphing, animation	Géométrie des maillages triangulaires uniquement
Taille sur notre modèle de test de 28 Mo	22,8 Mo (8,1 Mo avec gzip)	5,1 Mo (3,3 Mo avec gzip)	2,6 Mo (2,5 Mo avec gzip)
Décodeur	Aucun	Module JS de 32 Ko avec WASM intégré	192 à 286 Ko de WASM, plus une enveloppe de 58 Ko et une solution de repli JS de 719 Ko
Vitesse de décodage	Instantanée, le GPU le lit directement	Environ 1 Go/s avec WASM SIMD, selon la spécification	Nettement plus lente que Meshopt, selon la documentation de glTF-Transform
Nécessite gzip/brotli sur le serveur	Très utile	Oui, conçu pour cela	Faible gain
Chargeurs	three.js, Babylon.js, PlayCanvas, glTFast	three.js r122+, Babylon.js 5.0+, glTFast (paquet supplémentaire), pas PlayCanvas	three.js, Babylon.js, PlayCanvas, glTFast (paquet supplémentaire)

Les mêmes chiffres sous forme de barres, accompagnés des résultats de gltfpack et de la simplification issus de notre comparatif.

Draco l’emporte sur le nombre d’octets, mais gzip ne lui apporte presque aucun gain, tandis que Meshopt et la sortie quantifiée s’appuient sur la compression du serveur. La simplification est la seule étape qui modifie le nombre de triangles : ses 8,1 Mo constituent donc un nouveau point de départ, et non un résultat final.

Où se trouvent les octets dans un GLB

Exécutez gltf-transform inspect model.glb avant toute autre opération. Cette commande répertorie chaque maillage avec son nombre de sommets et ses types d’attributs, chaque texture avec sa taille encodée et sa valeur gpuSize, ainsi que chaque animation avec son nombre d’images clés. Les chiffres de ce guide proviennent de la documentation des outils et des spécifications des extensions, ainsi que d’un comparatif que nous avons réalisé cette semaine avec gltf-transform 4.5.0 et gltfpack 1.2 sur deux fichiers réels. Ils illustrent les deux types de modèles que vous rencontrerez.

Un accessoire Sketchfab de 2,2 Mo (une tasse low poly) comptait 680 triangles et 39 Ko de géométrie. Les 2,18 Mo restants correspondaient à trois PNG de 1024×1024 : les textures représentaient donc 98 % du fichier, et inspect estimait que chacune occupait 5,59 Mo de VRAM avec ses mipmaps. C’est le cas le plus fréquent pour les ressources créées manuellement.

Une sortie TRELLIS.2 de 28,7 Mo présentait la situation inverse : 978 226 triangles et 27,5 Mo de géométrie float32, pour seulement 1,1 Mo de textures. Mais ces deux textures mesuraient 4096×4096, ce qui, selon inspect, correspond à 89,5 Mo de VRAM chacune. Les modèles issus du générateur de modèles 3D et des outils similaires arrivent régulièrement dans cet état, avec une géométrie dense et des textures surdimensionnées. Ils nécessitent donc d’optimiser aussi bien la géométrie que les textures.

La ligne « classique » correspond à la règle générale, tandis que les deux autres représentent les fichiers réels de notre comparatif. Observez la colonne de droite : les textures 1024 de la tasse et les textures 4096 de TRELLIS.2 sont toutes petites sur le disque, mais occupent des quantités de mémoire vidéo radicalement différentes.

Notez que la taille encodée d’une texture et sa taille sur le GPU n’ont aucun rapport. Un PNG de 4 Mo et un WebP de 200 Ko représentant la même image de 2048×2048 occupent tous deux environ 22 Mo en mémoire vidéo, entre les pixels bruts et les mipmaps. Seul KTX2 modifie cette valeur.

Les six étapes ci-dessous s’exécutent dans cet ordre, car chacune réduit la quantité de données que la suivante devra traiter.

Suivez les numéros de haut en bas. Les étapes 1 et 4 concentrent la plupart des octets, l’étape 2 est invisible sauf sur un immense maillage unique, et l’étape 5 doit être appliquée avec prudence à un personnage riggé, car la fusion soude des parties qui doivent bouger.

Étape 1 : les textures

Deux problèmes distincts, deux solutions distinctes.

La taille du téléchargement se réduit en redimensionnant et en réencodant. Peu d’objets nécessitent plus de 1024×1024, et même un personnage principal a rarement besoin de plus de 2048. gltf-transform resize --width 1024 --height 1024 plafonne les dimensions sans jamais agrandir l’image, et gltf-transform webp la réencode avec sharp. Sur la tasse, WebP seul a réduit le fichier de 2,23 Mo à 246 Ko. Un redimensionnement préalable à 512 l’a ramené à 96 Ko, sans différence visible sur un objet de cette taille. WebP nécessite EXT_texture_webp, que les moteurs web prennent en charge, contrairement à glTFast de Unity (son tableau de fonctionnalités indique que cette extension « ne sera pas prise en charge »).

La mémoire GPU et le temps de téléversement ne peuvent être réduits qu’avec KTX2 et la supercompression Basis Universal, qui conserve la texture dans un format de blocs GPU jusque dans la VRAM, avec une consommation mémoire 4 à 8 fois inférieure au RGBA brut. Une section entière lui est consacrée plus bas, car les réglages ont leur importance.

Une mise en garde tirée du comparatif : gltf-transform optimize utilise par défaut --texture-compress auto, qui réencode les textures dans leur format d’origine. Sur la tasse, cela a alourdi les PNG et fait passer le fichier de 2,2 Mo à 2,8 Mo. Indiquez explicitement webp ou ktx2.

Étape 2 : quantifier

La quantification stocke chaque attribut de sommet avec moins de bits. Une position passe de trois nombres flottants de 32 bits à trois entiers de 16 bits, l’échelle et le décalage étant intégrés à la transformation du nœud (ou à inverseBindMatrices pour les maillages skinnés). La spécification KHR_mesh_quantization estime qu’un sommet typique occupe environ 20 octets au lieu de 48. C’est une extension Khronos ratifiée qui ne nécessite aucun décodeur : le GPU lit directement les attributs entiers, si bien que les fichiers quantifiés consomment moins de VRAM tout en étant plus légers à transférer.

Les valeurs par défaut de glTF-Transform sont de 14 bits pour les positions, 10 pour les normales et les tangentes, 12 pour les UV, et 8 pour les couleurs et les poids. Celles de gltfpack sont respectivement 14, 8, 12 et 8. Les deux sont imperceptibles, sauf sur un immense maillage unique où 14 bits répartis sur toute l’étendue peuvent produire des facettes visibles. Seule, la quantification apporte un gain modeste : notre modèle de 28 Mo est passé à 22,8 Mo brut et 8,1 Mo avec gzip. Son véritable rôle est de constituer la première moitié de Meshopt, et d’offrir une sortie sûre lorsque la compatibilité du chargeur de destination est incertaine. Draco effectue sa propre quantification avec les mêmes valeurs par défaut ; n’exécutez donc pas quantize avant draco.

Étape 3 : Meshopt ou Draco

Tous deux sont des codecs géométriques avec perte qui décodent les données en tampons ordinaires avant leur téléversement vers le GPU ; aucun ne rend donc le modèle plus rapide à afficher. Ils réduisent la taille du téléchargement. Leurs différences portent sur ce qu’ils compressent, leur vitesse de décodage et le poids du décodeur à distribuer.

Meshopt (EXT_meshopt_compression) fonctionne au niveau des bufferViews : les attributs de sommets, les indices, les deltas de cibles de morphing et les images clés d’animation sont donc tous compressés. Il est conçu pour s’appliquer après la quantification et avant gzip ou brotli : le codec régularise les octets, puis le compresseur généraliste du CDN fait le reste. La spécification annonce des vitesses de décodage d’environ 1 Go/s avec le SIMD WebAssembly, et le décodeur three.js tient dans un unique module de 32 Ko. Sur le modèle de test : 5,1 Mo brut et 3,3 Mo avec gzip, au niveau par défaut --level high.

Draco (KHR_draco_mesh_compression) ne compresse que les primitives de maillages triangulés. Les animations, les cibles de morphing, les points et les lignes restent intacts. Il compresse davantage — 2,6 Mo sur le même modèle — et gzip apporte à peine un gain, car la sortie est déjà très dense. Cela se paie en temps de décodage et en poids du décodeur : la documentation de glTF-Transform indique clairement que le décodage Meshopt est nettement plus rapide, tandis que le décodeur WASM fourni avec three.js pèse 286 Ko (192 Ko pour la version de la branche glTF), auxquels s’ajoutent un wrapper de 58 Ko et une solution de repli JavaScript de 719 Ko. Draco réorganise également les sommets et peut en modifier le nombre.

En résumé : Meshopt pour tout contenu animé, tout contenu avec des cibles de morphing, tout projet où le temps de chargement sur téléphone est prioritaire, et tout contenu servi avec brotli activé. Draco lorsque l’asset est un maillage statique, que la géométrie domine et qu’une réduction de 20 à 30 % du transfert justifie une première image plus lente. Un doute ? Choisissez Meshopt. L’option -cc de gltfpack (Meshopt dans son mode le plus puissant) a produit un fichier de 4,4 Mo brut et 3,1 Mo avec gzip à partir du même modèle.

Étape 4 : simplifier

Si le modèle reste volumineux après compression, c’est qu’il contient trop de triangles, et aucun codec ne corrigera cela. Les deux outils utilisent le simplificateur de meshoptimizer, qui accepte un ratio cible et une limite d’erreur, puis s’arrête dès que l’un des deux seuils est atteint.

gltf-transform simplify --ratio 0.25 --error 0.01 vise 25 % des sommets avec un écart maximal égal à 1 % du rayon du maillage. Sur le modèle de 978 000 triangles, cela a donné 244 556 triangles et 8,1 Mo avant compression, sans différence à distance de jeu. Les valeurs par défaut d’optimize sont plus agressives qu’on pourrait le penser : --simplify-ratio 0 avec --simplify-error 0.0001, soit « supprimer autant que possible dans une limite d’erreur de 0,01 % ». Sur le même modèle sur-tessellé, cela l’a ramené à 6 582 triangles, car le générateur avait consacré près d’un million de triangles à des surfaces planes. Soudez les sommets avant la simplification (optimize le fait), car les sommets séparés bloquent le simplificateur au niveau des coutures.

L’option -si 0.25 de gltfpack applique le même principe, avec -se 0.01 comme limite d’erreur par défaut, -sa pour atteindre le ratio quelle que soit la qualité, et -slb pour verrouiller les sommets de bordure afin d’éviter l’apparition d’interstices entre les maillages modulaires. Les objets hard surface supportent facilement une réduction de 50 %, les maillages scannés et générés par IA tolèrent généralement la suppression de 90 % des triangles, tandis que les personnages riggés exigent de la prudence près des articulations, car fusionner des sommets fusionne aussi leurs poids de skinning.

Étape 5 : élaguer, dédupliquer, fusionner, instancier

Ces opérations apportent des gains gratuits et optimize les exécute toutes. prune supprime les matériaux, textures, accesseurs et nœuds qui ne sont référencés par rien, et convertit les textures monochromes en facteurs de matériau. dedup fusionne les accesseurs et textures identiques qu’un exportateur a écrits en double. flatten aplatit la hiérarchie et join fusionne les maillages partageant un matériau, ce qui réduit 200 appels de rendu à une poignée. instance (à partir de 5 copies) convertit les maillages répétés en EXT_mesh_gpu_instancing, tandis que palette fusionne les matériaux qui ne diffèrent que par leur couleur.

N’utilisez pas join ou flatten sur un personnage riggé ni sur un élément dont le jeu déplace séparément certaines parties, car celles-ci disparaîtraient dans un maillage unique. Avec gltfpack, utilisez -kn (conserver les nœuds nommés) et -km (conserver les matériaux nommés).

Étape 6 : l’animation

Les exportateurs créent souvent une image clé à chaque frame. gltf-transform resample supprime les images clés situées sur la ligne entre leurs voisines (tolérance de 1e-4 par défaut), ce qui est sans perte en pratique. L’option -af 30 de gltfpack rééchantillonne chaque piste à 30 Hz et quantifie les translations sur 16 bits, les rotations sur 12 et l’échelle sur 16 (-at, -ar, -as) avant leur compression par Meshopt. Sur un personnage classique doté de quelques clips, le gain est faible. Sur une bibliothèque de mouvements, cette étape peut éliminer la majorité des octets.

Les lignes de commande

Pour installer la CLI de glTF-Transform, utilisez npm install --global @gltf-transform/cli, ou lancez-la avec npx @gltf-transform/cli. En une seule commande :

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

Cette commande exécute, dans l’ordre, la déduplication, l’instanciation, la création de palettes, l’aplatissement, la fusion, la soudure, la simplification (ratio 0, erreur 0.0001), le rééchantillonnage, l’élagage, la conversion en données creuses, la compression des textures avec une limite de 1024, puis Meshopt au niveau élevé. Ajoutez --compress draco pour Draco, --compress quantize pour la quantification seule, --no-join --no-flatten pour les modèles riggés ou articulés, --simplify false si la silhouette compte davantage que les octets, et --texture-compress ktx2 si KTX-Software est installé.

Les étapes individuelles, pour garder le contrôle :

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

Remplacez la dernière ligne par gltf-transform draco d.glb out.glb (--encode-speed et --decode-speed vont de 0 à 10, avec 5 par défaut ; une valeur plus basse produit un fichier plus petit) ou par gltf-transform quantize d.glb out.glb.

gltfpack s’installe avec npm install -g gltfpack ou sous forme de binaire natif depuis les versions publiées de meshoptimizer, ce que le README recommande pour les fichiers volumineux. Ses réglages par défaut appliquent déjà la quantification, optimisent l’ordre des sommets pour le cache GPU et fusionnent les maillages :

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

-cc utilise Meshopt dans son mode de compression renforcée (-c est le mode rapide, -cf ajoute une version non compressée de secours pour les chargeurs dépourvus du décodeur). -si 0.5 divise le nombre de triangles par deux dans la limite de -se 0.01. -tw convertit les textures en WebP et -tl 1024 plafonne leur taille. -kn conserve les nœuds nommés. Pour KTX2, remplacez -tw par -tc (ETC1S) ou -tc -tu (UASTC), ce qui nécessite une version de gltfpack liée à Basis Universal.

Si aucune des deux CLI ne convient, l’outil dans le navigateur exécute la même séquence.

La méthode sans terminal : élagage, soudure, fusion, simplification, redimensionnement des textures en WebP et Meshopt dans le navigateur, avec la taille affichée après chaque étape pour voir laquelle a produit le gain.

KTX2 : ETC1S ou UASTC

KTX2 est le conteneur de Khronos destiné aux textures GPU. Avec la supercompression Basis Universal, la texture est transcodée au chargement vers le format de blocs pris en charge par l’appareil (BC sur ordinateur, ASTC ou ETC2 sur mobile) et reste compressée en mémoire. L’extension glTF correspondante est KHR_texture_basisu. Basis propose deux modes. ETC1S est le plus compact : le README de Basis indique environ 0,3 à 3 bits par pixel sur disque, avec un réglage de qualité semblable à celui du JPEG (de 1 à 255, 128 par défaut), et il occupe 4 bits par pixel en mémoire dans des formats comme BC1 et ETC1. Utilisez-le pour la couleur de base des objets. UASTC privilégie la qualité : 8 bits par pixel en mémoire, un sous-ensemble à 19 modes d’ASTC 4×4, avec des niveaux de qualité de 0 à 4 (2 par défaut, ce qui correspond à 47,47 dB selon l’aide de glTF-Transform). Les fichiers UASTC sont volumineux sur disque, associez-les donc à Zstandard : la commande uastc de glTF-Transform utilise --zstd 18 par défaut, tandis que ktx create --zstd accepte une valeur de 1 à 22.

Calcul pour une texture 2048×2048 avec mipmaps : environ 22 Mo en RGBA8, 5,6 Mo en UASTC et 2,8 Mo en ETC1S transcodé vers un format à 4 bits par pixel.

Trois règles sont importantes. Les normal maps et les cartes de données nécessitent UASTC et un espace linéaire. glTF-Transform avertit que les normal maps RGB et les cartes d’occlusion/rugosité/métallicité peuvent donner de mauvais résultats avec ETC1S, et la spécification impose de marquer les textures de couleur comme sRGB et les données non colorimétriques comme linéaires. glTF-Transform configure cela automatiquement pour chaque emplacement. Dans le compresseur KTX2, il s’agit du réglage sRGB : activé pour la couleur, désactivé pour les normal maps et les cartes de données. Les dimensions doivent être des multiples de 4, et les puissances de deux sont recommandées. Générez des mipmaps. La spécification indique qu’un fichier KTX2 utilisé avec un filtrage de réduction par mipmaps doit contenir toute la pyramide, faute de quoi le moteur devra le décompresser et la générer à l’exécution. Les mipmaps sont activées par défaut dans glTF-Transform et dans l’outil pour navigateur, et correspondent à --generate-mipmap dans ktx create.

Les commandes glTF-Transform nécessitent le binaire ktx de KTX-Software, en version 4.4.0 ou ultérieure :

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

Appliquez d’abord UASTC aux emplacements de données, puis ETC1S au reste. Cette répartition — ETC1S pour la couleur de base et l’émissif, UASTC pour les normales et l’ORM — est la plus courante.

Charger le résultat

Tous les codecs, à l’exception de la quantification, nécessitent un décodeur côté client.

three.js. GLTFLoader lit KHR_mesh_quantization et EXT_texture_webp sans configuration. Pour les autres, vous devez lui associer des décodeurs, fournis dans le paquet three sous examples/jsm/libs/, dans les dossiers draco/, basis/ et le fichier meshopt_decoder.module.js. Copiez draco/ et basis/ vers un chemin public, puis utilisez :

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)

DRACOLoader choisit le décodeur WASM lorsque le navigateur le prend en charge et se rabat sur JavaScript dans le cas contraire. detectSupport(renderer) permet à KTX2Loader de choisir le format de transcodage adapté au GPU de l’appareil.

Babylon.js. Le chargeur glTF prend en charge Draco, Meshopt (depuis la version 5.0, sans configuration) et KTX2 en téléchargeant les décodeurs depuis https://cdn.babylonjs.com et en les exécutant dans des workers web. Pour les auto-héberger, définissez Tools.CDNBaseUrl ou configurez-les individuellement : DracoDecoder.DefaultConfiguration (wasmUrl, wasmBinaryUrl, fallbackUrl), MeshoptCompression.Configuration.decoder.url et KhronosTextureContainer2.URLConfig pour l’ensemble des transcodeurs KTX2. Avec npm, @babylonjs/ktx2decoder inclut les transcodeurs.

PlayCanvas. Draco se configure avec dracoInitialize({ jsUrl, wasmUrl, numWorkers, lazyInit }), et l’éditeur peut appliquer la compression Draco à l’importation. KTX2 passe par basisInitialize({ glueUrl, wasmUrl, fallbackUrl }). EXT_meshopt_compression n’est pas pris en charge par l’analyseur GLB dans la version 2.x du moteur (la demande de fonctionnalité ouverte en 2020 est toujours en attente). Pour PlayCanvas, choisissez donc Draco ou une sortie uniquement quantifiée.

Unity. L’importateur officiel est glTFast (com.unity.cloud.gltfast). KHR_mesh_quantization fonctionne directement, Draco nécessite com.unity.cloud.draco, KTX2 nécessite com.unity.cloud.ktx et Meshopt nécessite com.unity.meshopt.decompress. WebP n’est volontairement pas pris en charge : pour une cible Unity, utilisez KTX2.

Objectifs pour un jeu web mobile

Il n’existe aucune spécification à ce sujet, mais certaines valeurs permettent de préserver les performances des téléphones. Maintenez l’ensemble de la première scène sous environ 10 Mo à télécharger et diffusez progressivement le reste (le tutoriel sur le chargement progressif des ressources présente les différents paliers et le code). Limitez la VRAM des textures à 150–200 Mo, soit quatre ou cinq textures 2048 en RGBA8, ou trente en ETC1S. Limitez les objets à 5 000 triangles et les personnages principaux à 30 000–50 000 triangles, avec un nombre d’appels de rendu ne dépassant pas quelques centaines. Utilisez des textures 1024 pour les objets et réservez les textures 2048 aux éléments dont la caméra s’approche. Servez les GLB avec Brotli ou gzip activé, car Meshopt et les sorties quantifiées en dépendent.

Vérifier avant la publication

La taille du fichier est la mesure la plus simple. Ouvrez le résultat dans la visionneuse GLB pour consulter le reste : le panneau Extensions confirme que EXT_meshopt_compression, KHR_draco_mesh_compression ou KHR_texture_basisu a bien été ajouté au fichier, l’onglet Textures répertorie chaque texture par coût réel en VRAM décroissant, et la barre d’état affiche en direct le nombre d’appels de rendu et de triangles. Vérifiez ensuite les silhouettes et les coutures UV pour repérer les artefacts de simplification à la distance où le joueur les verra, puis lancez les animations afin de vous assurer que la fusion n’a pas regroupé des pièces censées bouger indépendamment. Si le fichier source n’était pas initialement un GLB, convertissez d’abord le FBX ou l’OBJ avec le convertisseur FBX vers GLB, afin de compresser le fichier qui sera réellement chargé.

Ouvrez ici la sortie compressée pour vérifier que l’extension a bien été ajoutée au fichier, puis consultez le nombre d’appels de rendu et de triangles dans la barre d’état, ainsi que le coût réel en VRAM de chaque texture dans l’onglet Textures.

Questions fréquentes

Comment réduire la taille d’un fichier GLB ?

Exécutez gltf-transform inspect pour déterminer si les textures ou la géométrie occupent le plus d’espace. S’il s’agit des textures, redimensionnez-les en 1024 ou 2048 et convertissez-les en WebP ou KTX2. S’il s’agit de la géométrie, simplifiez-la, puis compressez-la avec Meshopt ou Draco. gltf-transform optimize in.glb out.glb --texture-compress webp exécute toute la séquence, tandis que l’optimiseur GLB pour navigateur le fait sans installation.

Draco ou Meshopt : lequel est le meilleur ?

Meshopt pour la plupart des jeux web. Son décodage est beaucoup plus rapide, son décodeur ne pèse que 32 Ko au lieu de quelques centaines de kilo-octets de WASM, et il compresse les animations ainsi que les cibles de morphing, que Draco ignore. Draco produit des fichiers plus petits pour les maillages statiques (2,6 Mo contre 3,3 Mo après gzip sur notre modèle de test de 28 Mo) et il est pris en charge par PlayCanvas. Il est donc préférable lorsque la ressource est un scan statique et que la géométrie représente la majeure partie des données.

Qu’est-ce que KTX2 et en quoi diffère-t-il de Basis ?

Basis Universal est le codec de compression, avec deux modes : ETC1S et UASTC. KTX2 est le format conteneur de Khronos qui stocke les données de texture compressées avec Basis, ainsi que les mipmaps et les métadonnées. C’est le format référencé par glTF via KHR_texture_basisu. Les anciens pipelines utilisaient un simple fichier .basis. Utilisez .ktx2.

Dois-je utiliser ETC1S ou UASTC ?

Utilisez ETC1S pour la couleur de base et tout ce qui n’est pas observé de près : des fichiers compacts et 4 bits par pixel en VRAM. Utilisez UASTC pour les normal maps, les cartes de rugosité/métallicité/occlusion et les textures principales, avec la supercompression Zstandard activée afin de conserver une taille de téléchargement raisonnable. Marquez les textures de couleur comme sRGB et les textures de données comme linéaires, sinon l’éclairage des normales sera incorrect.

Comment compresser les textures glTF ?

Pour réduire la taille de téléchargement, utilisez gltf-transform resize, puis gltf-transform webp. Pour réduire la mémoire GPU, utilisez gltf-transform etc1s ou uastc avec KTX-Software installé, ou déposez les PNG dans le compresseur KTX2. Dans tous les cas, limitez d’abord les dimensions : une texture 4096 occupe 89 Mo de VRAM en RGBA8 et il n’y a presque jamais de raison d’en fournir une dans un navigateur.

Pourquoi mon GLB est-il trop volumineux pour three.js sur mobile ?

En général, le problème ne vient pas de la taille du fichier, mais de la mémoire des textures. Quatre textures 2048 en RGBA occupent environ 90 Mo de VRAM avant même que la scène ait affiché quoi que ce soit, et les navigateurs mobiles ferment l’onglet au-delà de quelques centaines de mégaoctets. Convertissez les textures en KTX2 afin qu’elles restent compressées sur le GPU, limitez-les à 1024 lorsque c’est possible et appelez KTX2Loader.detectSupport(renderer) pour qu’elles soient transcodées vers le format de l’appareil.

gltfpack fait-il la même chose que gltf-transform ?

Dans l’ensemble, oui. gltfpack est un binaire natif unique issu du projet meshoptimizer qui quantifie les données, réorganise les sommets pour le cache GPU, fusionne les maillages et applique par défaut la compression Meshopt. glTF-Transform est une bibliothèque Node et une interface en ligne de commande proposant les mêmes opérations sous forme d’étapes scriptables distinctes, ainsi qu’une sortie Draco, que gltfpack ne génère pas. Sur notre fichier de test, leurs sorties Meshopt différaient d’environ 10 % au maximum.

Contenus associés

• Chargement progressif des ressources pour les jeux web : paliers, files de priorité et barres de progression pour les fichiers que vous venez de réduire
• Stack technique des jeux web en 2026 : WebGL, WebGPU, Wasm et formats de ressources au niveau des API
• Sites de modèles 3D gratuits : origine des modèles et raisons pour lesquelles ils sont si lourds
• Meilleurs générateurs de modèles 3D par IA : formats produits par les générateurs et densité de leur géométrie
• Three.js ou Babylon.js : les deux chargent Draco, Meshopt et KTX2, mais avec des configurations différentes
• PlayCanvas ou Three.js : moteur contre bibliothèque, y compris les pipelines de ressources