Convertir STL en GLB

Une grande partie des gens qui arrivent à cette page ont reçu une consigne sans négociation. Un champ d’upload sur une fiche produit ou un back-office qui ne liste que `.glb`. Un collègue qui n’a ni slicer, ni CAO, ni rien d’autre qu’un navigateur et qui veut regarder la pièce. Une fonction d’aperçu en réalité augmentée, dans une page de documentation ou un configurateur, qui a été assemblée autour de glTF parce que c’est ce que la bibliothèque de rendu charge.

Dans aucun de ces cas la personne qui convertit ne monte une scène 3D. Elle veut un fichier que l’autre côté ouvre, qui montre la forme, et qu’elle peut envoyer cet après-midi. Cette clarification vaut d’être posée d’entrée, parce que la majorité des conseils qu’on lit sur glTF s’adressent à des gens qui assemblent des scènes et répondent à des questions que ce lecteur n’a pas.

Un GLB est exactement le même document glTF, suivi de ses données de sommets : un en-tête de douze octets dont les quatre premiers épellent `glTF`, puis un chunk JSON, puis un chunk binaire, chacun complété jusqu’à un multiple de quatre octets. Un fichier, une seule requête, rien à côté.

C’est ce qui le distingue de la sortie glTF sur le même site. La conversion glTF embarque son buffer comme URI de données en base64, ce qui coûte quatre caractères pour trois octets — environ 33 pour cent — et ajoute le JSON indenté par-dessus. Le GLB range ces mêmes octets directement, donc il est sensiblement plus petit pour exactement la même géométrie. Si le fichier va être téléchargé, c’est la version à envoyer.

Un STL n’a ni couleur, ni texture, ni coordonnées UV, ni couleurs par sommet, et la conversion écrit une primitive avec un accesseur de positions et un accesseur d’indices, sans aucune référence à un matériau. Ce qui apparaît à l’écran est entièrement produit par les réglages par défaut du visualiseur.

C’est la raison pour laquelle le même fichier peut ressembler à un objet technique solide dans un visualiseur et à une masse grise informe dans un autre. Le remède tient à l’éclairage, pas à la conversion : `<model-viewer>` est livré avec un éclairage d’environnement neutre et un attribut `shadow-intensity`, et ajouter les deux tient en deux attributs et transforme le résultat. En three.js une environment map plus une hemisphere light font le même travail. Si la pièce a réellement besoin d’une couleur, ajoutez un matériau au glTF ensuite avec `gltf-transform` — c’est une petite édition sur un document qui est par ailleurs complet.

C’est le piège qui fait croire que la conversion a échoué. Les logiciels de CAO et le monde entier de l’impression 3D travaillent Z-haut : le plateau est le plan XY et la hauteur est Z. glTF spécifie Y comme axe vertical, et tous les visualiseurs suivent. Rien dans la conversion ne tourne quoi que ce soit, parce qu’inventer une rotation serait deviner la convention suivie par la source.

Une pièce exportée depuis Fusion, SolidWorks, FreeCAD ou un slicer arrive donc dans le visualiseur couchée sur le dos, à quatre-vingt-dix degrés de l’attitude attendue. Corrigez dans la scène, pas dans le fichier : `<model-viewer>` accepte un attribut `orientation="-90deg 0 0"`, et three.js a besoin d’une ligne qui fixe `object.rotation.x`. Le faire dans le visualiseur garde le GLB conforme au STL, ce qui compte si la même géométrie doit aussi aller sur une imprimante.

Aucun des deux formats ne déclare d’unité. Le STL est lu en millimètres par chaque slicer jamais écrit ; le glTF est écrit comme si une unité valait un mètre. Les nombres passent sans modification, donc une pièce de 60 mm devient un objet de 60 unités, ce qu’un visualiseur dimensionné pour des mètres affiche comme une pièce de 60 mètres et cadre de très loin.

Divisez par 1000 dans la scène, et vérifiez sur une dimension que vous pouvez contrôler plutôt qu’à l’œil. `<model-viewer>` a un attribut `scale` ; three.js a `object.scale.setScalar(0.001)`. Si le visualiseur rend correctement sans mise à l’échelle, le STL n’était probablement pas en millimètres, ce qui mérite d’être su avant qu’il n’aille sur une imprimante.

Un STL stocke chaque triangle avec trois sommets indépendants et aucun partage, donc un cube arrive en trente-six positions là où huit suffiraient. Le lecteur commence par fusionner les sommets coïncidents, en comparant à six décimales, parce que deux triangles qui partagent une arête divergent en général sur le dernier bit d’un flottant.

Pour un fichier de livraison ce n’est pas un détail. La forme non soudée mettrait quatre à six fois plus de sommets dans le buffer et donc dans le téléchargement, et elle casserait l’ombrage lissé, parce qu’un visualiseur qui moyenne des normales a besoin de sommets partagés pour moyenner. Le résultat est un GLB dont la géométrie est à la fois plus petite et mieux tenue qu’une réécriture naïve ne le produirait.

Tout ce qui se trouve dans le STL est écrit comme un seul mesh avec une seule primitive, parce qu’un STL n’a pas de groupes à préserver. C’est la forme la moins chère à rendre pour un moteur — un seul appel de dessin, aucun changement de matériau — et c’est la forme qu’il faut pour une pièce sur une fiche produit ou dans un panneau d’aperçu.

La primitive utilise des indices uint32 et des positions float32 partout. Des types d’indice plus étroits existent et économiseraient un peu sur un petit modèle, mais un mesh qui dépasse 65 535 sommets demande silencieusement un autre type, ce qui est une condition facile à se tromper pour quelques kilooctets. L’accesseur de positions porte les `min` et `max` que la spécification exige, ce qui permet à un visualiseur de cadrer le modèle au chargement plutôt que de s’ouvrir zoomé sur du vide.

C’est le cas tranquillement utile. Un collègue, un client ou un acheteur doit voir une pièce et n’a aucun logiciel pour — envoyer un STL signifie expliquer ce qu’il faut installer, et envoyer une capture d’écran signifie qu’il ne pourra pas la tourner. Un GLB s’ouvre dans un visualiseur du navigateur sans installation, et chaque téléphone et ordinateur actuel en rend un à travers une page.

Ce qu’il faut envoyer avec : les vraies dimensions, en une phrase, parce que le fichier ne les porte pas et que le visualiseur affichera l’échelle que vous aurez fixée. Et une note sur l’orientation si elle compte. Deux lignes de contexte transforment un objet gris flottant dans un visualiseur en une pièce sur laquelle quelqu’un peut commenter.

En général nettement plus petit. Le STL fait cinquante octets par triangle sans partage ; le GLB stocke chaque sommet une fois en douze octets et chaque indice en quatre, donc un mesh dont les sommets servent cinq ou six triangles chacun se compresse géométriquement bien avant qu’une compression logicielle ne s’applique.

Le plafond gratuit est de 100 Mo, ce qui représente environ deux millions de triangles STL. Bien avant cela, un modèle devient inconfortable à charger dans un navigateur — quelques centaines de milliers de triangles est une borne haute raisonnable pour quelque chose qu’un visiteur ouvrira sur un téléphone. Si le STL est plus dense que cela, décimez avant la conversion ; `gltf-transform` peut aussi appliquer la compression Draco au GLB résultant, mais gardez à l’esprit qu’un fichier compressé en Draco ne peut pas être reconverti sur ce site.

Rien ne quitte. La conversion est du JavaScript ordinaire dans cet onglet, sans module WebAssembly à télécharger, sans téléversement, sans compte et sans quota quotidien. L’onglet réseau pendant une conversion est la vérification.

C’est le point qui compte pour une pièce en cours de préparation pour une fiche ou une revue client, parce que le modèle est souvent non sorti et souvent la propriété de quelqu’un d’autre. Une conversion qui ne transmet jamais la géométrie supprime la question plutôt que d’y répondre avec une politique de confidentialité.