Comment convertir un glTF en GLB (modèles 3D en un seul fichier)
glTF vs GLB : Qu'est-ce qui différencie vraiment ces deux formats
Au fond, glTF et GLB sont la même chose. Ils sont définis par la même spécification du Khronos Group et partagent des structures de données identiques, prenant en charge les mêmes matériaux PBR, animations et hiérarchies de scène. La seule vraie différence, c'est le packaging. Un asset glTF standard est toute une collection de fichiers qui doivent rester ensemble. Tu as un fichier JSON .gltf lisible par un humain qui décrit la scène, les matériaux et la topologie du maillage. À côté, tu trouveras un ou plusieurs fichiers .bin contenant les données brutes de la géométrie — positions des sommets, normales, UV, etc. Puis, il y a un dossier d'images de texture, généralement des PNG ou des JPEG. Un modèle de personnage modérément complexe pourrait être livré sous la forme de character.gltf, character0.bin, et un dossier textures/ contenant dix images. Si tu perds un seul de ces fichiers, le modèle ne se chargera tout simplement pas. Le GLB, en revanche, est la version conteneur binaire. Il rassemble proprement le JSON, les données binaires et toutes les textures dans un unique fichier .glb. Le tout est maintenu par un minuscule en-tête de 12 octets contenant un nombre magique (0x46546C67, ce qui correspond à 'glTF' en ASCII), un champ de version (actuellement 2), et la longueur totale du fichier. Le reste du fichier n'est qu'une séquence de blocs de données. Cela rend un fichier GLB complètement autonome. Tu peux l'envoyer par e-mail, le glisser dans un configurateur de produit web, ou le donner à un client sans te soucier des chemins cassés ou des textures manquantes. La taille du fichier est presque toujours à 1-3 % près de celle du pack d'origine, donc tu ne paies aucune réelle pénalité de stockage pour cet immense avantage pratique.
Quand convertir un glTF en GLB (et quand ne pas le faire)
Pour la livraison finale et le déploiement, mon choix par défaut est toujours le GLB. La simplicité d'un fichier unique et autonome est tout simplement trop belle pour s'en passer. Mais pendant le développement actif, s'en tenir au format glTF multi-fichiers peut en fait être le choix le plus malin. L'argument en faveur du GLB est le plus fort lorsque tu déploies un modèle sur un visualiseur web comme model-viewer, Babylon.js ou Three.js. Une seule requête de récupération est toujours préférable à une cascade d'appels réseau pour chaque fichier binaire et texture. Un GLB de 4 Mo se chargera sensiblement plus vite sur une connexion mobile que le même modèle divisé en un .gltf de 120 Ko, un .bin de 2,1 Mo et six textures totalisant 1,8 Mo. Pourquoi ? Parce que chaque fichier séparé nécessite son propre aller-retour HTTP. Tu devrais aussi convertir en GLB lors de la distribution à des clients ou sur des marketplaces ; des plateformes comme l'Unity Asset Store, Sketchfab et le pipeline AR Quick Look d'Apple fonctionnent toutes parfaitement avec ce format. Alors, où est-ce que le glTF multi-fichiers brille ? Pendant la création de contenu. Si un artiste de textures est en train de travailler sur une map de rugosité 2K, il peut simplement glisser un nouveau PNG dans le dossier des textures et rafraîchir. C'est beaucoup plus rapide que de re-packager l'asset entier à chaque fois. La même logique s'applique aux systèmes de build automatisés. Si ton pipeline exécute une compression de textures pour générer des variantes KTX2 ou Basis Universal, il est bien plus simple d'opérer sur des fichiers individuels séparés que de décompresser et recompresser un GLB à chaque build. Et voici une limite clé à retenir : par conception, le GLB ne peut pas référencer de textures externes. Si ton glTF d'origine était intelligemment configuré pour pointer vers des textures sur un CDN — une pratique pour partager des atlas de textures entre plusieurs modèles — le convertir en GLB intégrera des copies locales et brisera ce modèle de ressource partagée.
Comment convertir un glTF en GLB avec CocoConvert
Utiliser l'outil en ligne de CocoConvert est le moyen le plus simple d'obtenir un GLB, car il ne nécessite aucune installation de logiciel. L'ensemble du processus fonctionne côté client pour les fichiers de moins de 100 Mo, ce qui signifie que tes précieuses données de géométrie et de texture ne quittent même pas ta machine. Étape 1 — Prépare tes fichiers. Un asset glTF est un tout, tu dois donc tout téléverser ensemble. La seule façon de faire ça est de zipper ton fichier .gltf, tous ses fichiers .bin associés et le dossier entier des textures dans une seule archive. Il est crucial de garder la structure interne des dossiers intacte. Le fichier .gltf se base sur des chemins relatifs comme ./textures/baseColor.png, et le convertisseur a besoin que ces chemins soient corrects à l'intérieur du zip. Étape 2 — Ouvre le convertisseur. Rends-toi sur /convert/gltf-to-glb et clique sur la zone de téléversement ou glisse simplement ton fichier .zip sur la page. L'outil est assez malin pour trouver le point d'entrée glTF automatiquement. Si pour une raison quelconque ton zip contient plusieurs fichiers .gltf (comme des variantes LOD), une liste déroulante apparaîtra pour que tu puisses choisir le bon à utiliser comme racine. Étape 3 — Vérifie les options de conversion. CocoConvert te donne quelques réglages. 'Intégrer les textures' est activé par défaut, ce qui est exactement ce que tu veux pour un vrai GLB en un seul fichier. Si tu désactivais cette option, le fichier de sortie ferait référence à des URI de textures externes, ce qui irait à l'encontre de l'objectif de la conversion. L'autre option est 'Aplatir le buffer'. Mon conseil ? Laisse cette option activée. Elle fusionne plusieurs fichiers .bin en un seul bloc binaire, ce qui est le comportement standard du GLB. Étape 4 — Télécharge. Et voilà. La conversion prend généralement entre 5 et 20 secondes, selon le nombre de textures que tu as et la taille totale du fichier. Tu obtiendras un unique fichier .glb, prêt pour le déploiement.
Alternative en ligne de commande : utiliser gltf-pipeline pour les workflows automatisés
Quand tu convertis des dizaines de modèles dans le cadre d'un pipeline de build, utiliser une interface web fichier par fichier n'est tout simplement pas pratique. Pour tout type de workflow automatisé, l'outil Node.js gltf-pipeline de l'équipe Cesium est l'option open-source la plus fiable qui soit. D'abord, installe-le globalement avec npm : `npm install -g gltf-pipeline`. Convertir un seul asset est alors simple : `gltf-pipeline -i scene.gltf -o scene.glb`. L'option -i pointe vers ton fichier .gltf d'entrée. Contrairement à un outil web, gltf-pipeline trouve automatiquement les fichiers .bin et les textures associés dans le même répertoire, donc pas besoin de zipper quoi que ce soit. L'option -b (pour --binary) est implicite lorsque ton nom de fichier de sortie se termine par .glb, ce qui est une commodité appréciable. Pour traiter un répertoire entier par lots, une simple boucle shell est ton amie : `for f in models/*.gltf; do gltf-pipeline -i "$f" -o "${f%.gltf}.glb"; done`. La commande équivalente pour Windows PowerShell est `Get-ChildItem -Filter *.gltf | ForEach-Object { gltf-pipeline -i $_.FullName -o ($_.FullName -replace '.gltf','.glb') }`. gltf-pipeline prend également en charge la compression de maillage Draco avec l'option --draco.compressionLevel (valeurs de 0 à 10, 7 par défaut). Pour tout modèle avec un maillage dense, tu devrais absolument l'activer. Ça peut réduire la taille de la géométrie de 60 à 80 %. Un scan de 500 000 polygones qui pèse 18 Mo non compressé peut être réduit à environ 4 Mo avec le niveau 7 de Draco. Le temps de décodage légèrement plus long dans le navigateur en vaut presque toujours la peine. La seule limitation majeure de l'outil est qu'il ne gère pas la compression de textures (KTX2/Basis). Pour cela, tu auras besoin d'une étape distincte dans ton pipeline en utilisant un outil comme toktx ou basisu, que ce soit avant ou après avoir packagé le GLB.
Valider ton fichier GLB avant le déploiement
Ne saute pas cette étape. Un GLB qui s'ouvre parfaitement dans un visualiseur peut échouer silencieusement dans un autre s'il contient des données non conformes. Fais de la validation une partie standard de ton processus avant de livrer un asset converti. Le validateur glTF de Khronos est la seule source de vérité. Tu peux l'utiliser en ligne sur validator.khronos.org — il suffit de glisser ton .glb sur la page. Il te sortira un rapport JSON structuré détaillant les erreurs, les avertissements et d'autres infos. Les erreurs sont rédhibitoires. Des choses comme des incohérences de `componentType` dans un accesseur ou des vues de buffer qui dépassent la longueur déclarée du buffer feront que la plupart des chargeurs rejetteront le fichier sur-le-champ. Les avertissements sont moins graves mais méritent quand même d'être lus ; un avertissement courant comme 'MESH_PRIMITIVE_UNUSED_TEXCOORD' signifie simplement que tu as un ensemble d'UV qu'aucun matériau n'utilise. Pour les pipelines automatisés, tu peux installer le validateur en tant que package Node : `npm install -g gltf-validator`. Ensuite, exécute `gltf-validator scene.glb --stdout > report.json` et envoie ce rapport dans une vérification de CI. Un build devrait absolument échouer si le nombre d'erreurs est supérieur à zéro. Au-delà de la stricte conformité aux spécifications, fais toujours une vérification visuelle dans au moins deux moteurs de rendu différents. Je te recommande model-viewer (modelviewer.dev) et le Sandbox de Babylon.js (sandbox.babylonjs.com). Ils utilisent des implémentations WebGL différentes et sont excellents pour exposer des problèmes de matériaux subtils. Quiconque s'est déjà battu avec une normal map qui semblait parfaite dans son outil de création mais qui était mystérieusement inversée sur le web connaît cette douleur. La spécification glTF exige des normales de type OpenGL (axe Y vers le haut), mais de nombreux outils exportent par défaut des normales de type DirectX (axe Y vers le bas). Si ton éclairage ressemble à des bosses inversées, inverse le canal vert de ta normal map et reconvertis.
Erreurs de conversion courantes et comment les corriger
La plupart des erreurs de conversion de glTF en GLB sont frustrantes mais, heureusement, ont des solutions simples. Voici les problèmes qui reviennent sans cesse. Textures manquantes en sortie : C'est le problème numéro un. Le coupable est presque toujours que les chemins URI des textures dans le fichier .gltf n'ont pas pu être résolus lors de la conversion. Pour déboguer ça, ouvre ton .gltf dans un éditeur de texte et trouve le tableau `images`. Tu verras des entrées comme `"uri": "textures/Material_baseColor.png"`. Tu dois t'assurer que ces fichiers existent exactement à ce chemin relatif à l'intérieur de ton archive zip ou de ton répertoire de travail. N'oublie pas que les séparateurs de chemin et la casse sont importants sur les serveurs : `Textures/BaseColor.png` n'est pas la même chose que `textures/baseColor.png`. Fichier de sortie trop volumineux : Si ton GLB est anormalement gros, la cause est presque certainement tes textures. Un seul PNG RGBA de 4096×4096 peut peser 64 Mo non compressé en mémoire. Bien que le PNG lui-même utilise une compression sans perte, un GLB se contente d'intégrer les octets bruts du fichier PNG. Cela signifie que ta texture PNG de 12 Mo ajoute 12 Mo au GLB. Pour une utilisation web, tu devrais sérieusement envisager de réduire la taille de tes textures à 2048×2048 (la différence visuelle est souvent négligeable) ou d'appliquer une compression KTX2 avant de packager le GLB. Animations qui ne se lancent pas : Si ton glTF source avait des animations squelettiques mais qu'elles ont disparu dans le GLB, cela signifie probablement que les données d'animation n'ont jamais été incluses. Certains exportateurs 3D écrivent les données d'animation dans un fichier .bin séparé. Si ce fichier manquait lors de ta conversion, les données d'animation sont tout simplement perdues. La solution est de ré-exporter depuis ton outil 3D, en t'assurant que toutes les données binaires sont écrites dans un seul fichier .bin, puis de relancer la conversion. CocoConvert signalera un avertissement dans son journal s'il détecte des fichiers référencés qu'il n'a pas pu trouver dans ton archive. Vérifie toujours le journal avant de télécharger.
Taille de fichier, performance et à quoi s'attendre dans de vrais projets
Laissons la théorie de côté. Des attentes concrètes valent mieux que de vagues promesses, alors voici à quoi ressemble réellement le processus de conversion pour quelques assets typiques. Un modèle de meuble simple — un maillage, deux matériaux, quatre textures 1K — pourrait commencer comme un pack glTF multi-fichiers de 3,2 Mo. Après conversion, il devient un GLB de 3,1 Mo. Cette légère réduction de taille vient de l'élimination des espaces blancs du JSON et de la fusion des en-têtes de buffer. Sur un ordinateur de bureau avec une connexion rapide, tu ne remarqueras aucune différence de temps de chargement. Mais sur une connexion mobile 4G, ce GLB en un seul fichier commencera à s'afficher 300 à 500 ms plus tôt en évitant la surcharge de multiples requêtes HTTP. Maintenant, imagine un personnage complexe avec une animation squelettique, 12 matériaux et des textures 2K. Cela pourrait être un pack glTF de 28 Mo. En tant que GLB simple, il pèse environ 27,4 Mo. Si tu ajoutes la compression Draco pour la géométrie, il pourrait tomber aux alentours de 22 Mo. Mais si tu appliques d'abord une compression de texture KTX2 Basis Universal, le GLB final pourrait ne peser que 9 à 11 Mo. CocoConvert gère parfaitement le packaging de base glTF vers GLB, mais il n'applique actuellement ni Draco ni KTX2. Pour ces optimisations avancées, tu devras utiliser des outils comme gltf-pipeline et toktx dans une étape séparée. Pour les projets AR, la taille du fichier est critique. AR Quick Look d'Apple et Scene Viewer de Google ont tous deux des limites documentées. Apple suggère de garder les GLB sous la barre des 20 Mo pour un chargement fiable sur un réseau mobile. La limite stricte de Google est de 200 Mo, mais ils recommandent de rester sous les 15 Mo pour de bonnes performances. Si ton GLB converti dépasse ces limites, ne te jette pas immédiatement sur les outils de simplification de la géométrie. Ta première action, et celle qui aura le plus d'impact, est presque toujours la compression des textures. La conversion elle-même sur /convert/gltf-to-glb est sans perte en ce qui concerne les données 3D — la géométrie, les matériaux, les animations et la hiérarchie de la scène sont préservés à l'identique. Ce que tu y mets est ce que tu en sors, simplement reconditionné pour une portabilité maximale.