Mis à jour 13 septembre 2026
Ce qu'une conversion 3D conserve et à quel prix
Convertir un maillage n'est pas gratuit et n'est pas une opération sans perte. GLB et glTF conservent tout. OBJ conserve les objets séparés et leurs noms de matériau, mais supprime la couleur par sommet. STL ne conserve que les triangles. PLY conserve la couleur par sommet, mais aplatie la scène en un seul maillage. USDZ a conservé les deux objets et les UV, a perdu la couleur par sommet et les noms de matériau lors de sa relecture, et écrit un zip de USDA. Les chiffres ci-dessous ont été mesurés, pas estimés.
Chaque chiffre de cette page provient de l'exécution du même convertisseur utilisé par ce site, avec des fichiers réels, et de la lecture des attributs directement à partir des octets qu'il a écrits. Mesuré le 13 septembre 2026 avec three.js r179. La méthode est à la fin de la page et le script est dans le dépôt.
Que conserve chaque format ?#
Une scène de référence avec deux cubes aux noms différents, chacun avec son propre matériau métallique nommé, couleur par vertex, coordonnées UV et normales, a été convertie vers les six destinations. GLB et glTF sont revenus complets. Tous les autres formats ont perdu quelque chose, et chacun a perdu quelque chose de différent.
| Destination | Deux objets | Coordonnées UV | Couleur par sommet | Noms de matériau | Nombre de vertices |
|---|---|---|---|---|---|
| GLB | Se conservent les 2 | Se conserve | Se conserve | Se conserve | 48 vertices |
| glTF | Se conservent les 2 | Se conserve | Se conserve | Se conserve | 48 vertices |
| OBJ | Se conservent les 2 | Se conserve | Se perd | Se conserve | 72 vertices |
| STL | Fusionnés en 1 | Se perd | Se perd | Se perd | 72 vertices |
| PLY | Fusionnés en 1 | Se conserve | Se conserve | Se perd | 48 vertices |
| USDZ | Se conservent les 2 | Se conserve | Se perd | Se perd | 72 vertices |
Pourquoi STL et PLY fusionnent-ils une scène en une seule mesh ?#
Aucun des deux formats n'a de graphe de scène. GLB, glTF et OBJ peuvent décrire plusieurs objets nommés dans un même fichier ; STL décrit un solide unique et PLY une seule liste d'éléments, donc les deux cubes arrivent comme une seule mesh et il n'y a aucun moyen de les séparer à nouveau.
C'est la perte qui surprend le plus, parce qu'elle ne se voit pas. Le modèle converti paraît identique dans un visualiseur. Ce n'est que lorsque vous essayez de sélectionner, de changer le matériau ou d'animer une de ses parties que vous découvrez que les parties n'existent plus.
Si le modèle doit rester séparable, la destination doit être GLB, glTF ou OBJ. S'il va vers un laminage ou une impression en un seul matériau, la fusion ne vous coûte rien.
De combien le fichier augmente-t-il ?#
Plus que la plupart ne l'espèrent. Dans un maillage réel généré, le OBJ occupait 5,6 fois ce que le GLB d'origine, et le PLY 1,4 fois. Les deux contiennent la même géométrie.
| Conversion | Origine | Résultat | Proportion | Vertices écrits |
|---|---|---|---|---|
| mug.glb a GLB | 880 KB | 1 173 KB | 1,3x | 25 000 |
| mug.glb a glTF | 880 KB | 1 564 KB | 1,8x | 25 000 |
| mug.glb a OBJ | 880 KB | 4 928 KB | 5,6x | 150 000 |
| mug.glb a STL | 880 KB | 2 441 KB | 2,8x | 150 000 |
| mug.glb a PLY | 880 KB | 1 221 KB | 1,4x | 25 000 |
| mug.glb a USDZ | 880 KB | 2 927 KB | 3,3x | 150 000 |
| lion.glb a GLB | 8 768 KB | 11 690 KB | 1,3x | 249 369 |
| lion.glb a glTF | 8 768 KB | 15 587 KB | 1,8x | 249 369 |
| lion.glb a OBJ | 8 768 KB | 51 880 KB | 5,9x | 1 496 202 |
| lion.glb a STL | 8 768 KB | 24 352 KB | 2,8x | 1 496 202 |
| lion.glb a PLY | 8 768 KB | 12 176 KB | 1,4x | 249 369 |
| lion.glb a USDZ | 8 768 KB | 30 487 KB | 3,5x | 1 496 202 |
Pourquoi OBJ et STL multiplient-ils le nombre de vertices ?#
Parce qu'aucun des deux ne partage des sommets entre les triangles. Un maillage bien indexé garde chaque coin une seule fois et le référence depuis tous les triangles qui le touchent ; OBJ et STL, tels qu'ils sont écrits ici, gardent séparément les trois coins de chaque triangle. Dans le test avec lion.glb, cela a transformé 249 369 sommets en 1 496 202, environ 6 fois plus.
La géométrie ne change pas. Même surface, mêmes triangles, même silhouette ; seule la comptabilité devient plus coûteuse, et le fichier croît à peu près dans la même proportion.
PLY est l'exemple contre-exemple utile. Il conserve l'index, donc le même maillage s'écrit avec une taille proche de l'original et continue de transporter la couleur par sommet. Pour un grand maillage où il suffit de conserver la géométrie, PLY est la destination honnête la moins chère de cette liste.
Le texte par rapport au binaire l'aggrave. glTF est du JSON avec les tampons codés en base64, ce qui coûte environ un 33 pour cent de plus que le GLB identique, parce que le base64 convertit chaque trois octets en quatre.
Pourquoi le fichier a-t-il grossi même en convertissant de GLB à GLB ?#
Parce que le convertisseur calcule les normales de sommet de n'importe quel maillage qui arrive sans elles et ensuite les écrit. Un maillage généré ne possède souvent aucun attribut de normales, donc l'aller-retour ajoute un vecteur complet de plus par sommet.
Le test avec mug.glb est un exemple clair : entrent 880 KB et sortent 1 173 KB, sans aucun changement dans la géométrie. Les normales ajoutées font la différence.
C'est une décision délibérée, pas un défaut. Un maillage sans normales apparaît avec un ombrage plat et facetté dans la plupart des visionneuses, donc le convertisseur les calcule une fois lors du chargement au lieu de laisser chaque outil ultérieur devoir les deviner.
La conversion change-t-elle la forme ?#
Non. Chaque destination a été convertie puis relue, et la surface est ressortie identique : le même nombre de triangles et la même aire de surface totale, jusqu'à la limite de la mesure, dans un maillage de 498 734 triangles. La géométrie est la partie d'un fichier 3D qui reste intacte après la conversion.
| Destination | Triangles après | Erreur de surface | Comment les coordonnées sont enregistrées |
|---|---|---|---|
| GLB | sans changements | 0% | float32 binaire |
| glTF | sans changements | 0% | buffer en base64 |
| OBJ | sans changements | 0% | texte avec 17 décimales |
| STL | sans changements | 0% | float32 binaire |
| PLY | sans changements | 0% | float32 binaire |
| USDZ | sans changements | 0% | zip de USDA |
Alors, la conversion 3D engendre-t-elle des pertes ou non ?#
Les deux, et la distinction est ce qui est utile. La géométrie ne perd rien : la forme qui entre est la forme qui sort. Tout ce qui entoure la géométrie se perd, et quelles parties tu perds dépend entièrement de la destination que tu as choisie.
Ici, rien ne tronque les coordonnées. GLB, STL et PLY écrivent des floats binaires de 32 bits. glTF intègre le même tampon binaire en base64 dans son JSON. USDZ écrit un zip de USDA. OBJ est le seul à écrire les positions en texte décimal, et il les écrit avec une précision complète au lieu de les arrondir, ce qui fait partie de la raison pour laquelle ses fichiers sont beaucoup plus volumineux.
Cela signifie que la préoccupation habituelle, que chaque conversion dégrade un peu le modèle, comme sauvegarder de nouveau un JPEG, ne s'applique pas. Convertir de GLB à OBJ et revenir ne lisse pas le maillage.
Ce qu'il fait effectivement, c'est écarter ce qui apparaît plus haut sur cette page : le graphe de scène dans STL et PLY, la couleur par sommet dans OBJ, STL et USDZ, les noms de matériaux dans STL, PLY et USDZ, et les UV dans STL. Ces pertes sont permanentes, dans le sens où reconvertir ne peut pas les réinventer.
Quel destin devriez-vous choisir ?#
Choisissez le destin selon ce qui doit survivre, pas selon l'extension que l'outil récepteur met en premier sur sa liste. Voici les choix défendables à partir de ce qui a été mesuré ci-dessus.
| Si vous avez besoin | Choisissez | Pourquoi |
|---|---|---|
| Tout conservé, dans un seul fichier | GLB | La seule destination qui a conservé ensemble le graphe de scène, les noms de matériau, les UV et la couleur par vertex, avec la plus petite taille des formats complets. |
| Tout conservé, lisible par une personne | glTF | Le même contenu que GLB, environ un 33 pour cent plus grand parce que les tampons sont en base64 à l'intérieur du JSON. |
| Objets séparés avec nom dans un programme de bureau | OBJ | A conservé les deux objets et les deux noms de matériau. Ignore la couleur par vertex et écrit le fichier le plus grand des six. |
| Impression 3D | STL | Triangles et rien de plus, ce qui est tout ce qu’un trancheur lit. La plus petite des destinations qui ne sont pas glTF dans un maillage réel. |
| Géométrie et couleur par vertex, avec peu de poids | PLY | La seule destination qui n'est pas glTF qui a conservé la couleur par sommet, et maintient l'indice, donc elle reste proche de la taille de l'origine. |
| Quick Look d'Apple / AR sur iPhone | USDZ | A conservé les deux objets et les UV dans la scène de référence. A perdu la couleur par sommet et les noms des matériaux en le relisant. Un zip de USDA qu'un téléphone peut ouvrir. |
Ce qui définit ces formats#
Les mesures ci-dessus sont les nôtres ; ce que chaque format peut contenir n'est pas décidé par nous. Ce sont les spécifications et les références de format qui le décident, afin que ce que cette page dit puisse être vérifié à la source plutôt que d'être cru simplement.
- Spécification de glTF 2.0The Khronos Group
Définissez le graphe de scène, les matériaux et les accessoires portés par GLB et glTF, et expliquez pourquoi ils ont été les seules destinations à survivre intactes ici.
- Type de média model/gltf-binaryIANA
Le type enregistré pour GLB, le conteneur binaire qui a été mesuré ci-dessus.
- Type de média model/stlIANA
STL tel qu'il est enregistré : triangles et normales de face, sans aucun champ pour la couleur, les UV, les matériaux ni les noms d'objet.
- Le format de fichier Wavefront OBJPaul Bourke
La référence classique pour OBJ, qui n'a pas de champ propre pour la couleur par sommet, ce qui correspond à ce qui a été éliminé lors de la conversion.
- Le format de fichier de polygones PLYPaul Bourke
Documente les propriétés par sommet, couleur incluse, qui font de PLY la seule destination qui n'est pas glTF à les conserver ici.
- Spécification du format de fichier USDZPixar / OpenUSD
USDZ est un zip dont la première entrée est la scène USDA. C’est le paquet que ce convertisseur écrit et lit.
Comment cela a été mesuré#
La mesure exécute le produit, pas une description de celui-ci. Le script importe les mêmes chargeurs et exportateurs que le convertisseur du navigateur, avec les mêmes options, et se trouve dans le dépôt pour que les chiffres puissent être reproduits ou discutés.
- Construire une scène de référence avec deux cubes nommés, chacun avec un matériau métallique nommé, couleur par sommet, coordonnées UV et normales.
- Charger des maillages générés réels de la même manière que le convertisseur charge le fichier que vous lui donnez, y compris l'étape qui calcule les normales de sommet lorsque un maillage arrive sans elles.
- Exporter vers GLB, glTF, OBJ, STL, PLY et USDZ avec les mêmes exportateurs que ceux appelés par le convertisseur et les mêmes paramètres binaires.
- Enregistrer la taille en octets de chaque résultat.
- Lire les attributs directement à partir des octets écrits et non depuis une scène rechargée, car un chargeur invente ce que le fichier ne contient pas : un OBJ sans lignes vn se recharge quand même avec un attribut de normales synthétisé.
- Publier le tableau directement à partir de ce résultat. Mesuré le 13 septembre 2026 avec three.js r179.
Questions
- La conversion d'un fichier 3D fait-elle perdre de la qualité ?
- La forme non. Chaque destination a été convertie puis relue, et le nombre de triangles ainsi que la surface totale étaient identiques sur un maillage de 498 734 triangles, sans tronquer les coordonnées dans aucun format. Ce qui se perd, c'est tout ce qui entoure la géométrie, et cela dépend de la destination : STL supprime les UV, la couleur, les matériaux et le graphe de scène ; OBJ supprime la couleur par sommet ; PLY supprime les noms des matériaux et fusionne la scène ; USDZ supprime la couleur par sommet et les noms des matériaux lors de la relecture ; GLB et glTF ont tout conservé.
- Quel format 3D prend le moins de place ?
- GLB, sur un véritable maillage. Dans ces tests, GLB a écrit 1 173 KB olà où OBJ a écrit 4 928 KB pour le même modèle, parce que GLB est binaire et maintient un indice de sommets partagé, tandis que le OBJ résultant est texte et enregistre séparément chaque coin de chaque triangle.
- Pourquoi mon OBJ occupe-t-il beaucoup plus que le GLB dont il est issu ?
- Pour deux raisons, les deux mesurées : OBJ est texte et non binaire, et le OBJ qui est écrit ici ne partage pas de sommets entre les triangles, donc le nombre de sommets est multiplié par quelques 6 dans un maillage bien indexé. La surface est identique ; la comptabilité ne l'est pas.
- STL conserve-t-il la couleur ?
- Non. Un STL binaire garde une normale par face et trois coins par triangle, et il n'a aucun champ pour la couleur, les UV, les matériaux ou les noms d'objet. Cela a été respecté dans tous les STL écrits dans ces tests.
- Puis-je conserver la couleur par sommet sans utiliser GLB ?
- Oui, avec PLY. Dans ces tests, c'était la seule destination qui n'est pas glTF et qui déclarait une propriété de couleur dans son en-tête. Cela dit, elle aplatie une scène de plusieurs objets en un seul maillage, donc vous conservez la couleur et perdez les parties.
- Est-ce que convertir un modèle 3D encore et encore le dégrade ?
- Non. Contrairement à la sauvegarde répétée d’un JPEG, une conversion 3D n’accumule pas d’erreur : les coordonnées sont copiées comme des floats binaires ou, dans le cas de OBJ, elles sont écrites comme des décimales avec précision complète. Un aller-retour par l’un de ces formats a rendu la surface identique. Ce qui ne revient pas, c’est l’information des matériaux et de la scène que la destination ne pouvait pas prendre en charge dès le début.
- Puis-je reproduire ces chiffres ?
- Oui. Le script de mesure est dans le dépôt, dans scripts/measure-conversions.mjs, et écrit le JSON que cette page lit. Il a été exécuté pour la dernière fois le 13 septembre 2026 avec three.js r179.