Léger, et à la bonne échelle.
Un modèle 3D dans une page web se juge sur deux chiffres : son poids et son nombre de faces. Un modèle de production de quarante mégaoctets fait tomber la page ; la préparation est l’essentiel du travail.
GLBLes étapes, dans l’ordre.
- On allège, sans perdre la silhouette. Réduction du maillage, fusion des matériaux, textures aux dimensions réelles. Le but est le profil de l’objet, pas la précision d’usinage.
- Les textures, intégrées. Dans le fichier, pour qu’il voyage seul. Une texture voisine absente laisse un objet gris que personne ne sait expliquer.
- L’échelle, en mètres. Un export qui n’applique pas l’échelle de la scène donne un objet cent fois trop grand. La conversion se fait à un seul endroit, et elle est écrite.
- On mesure dans la page. Poids du fichier, temps de premier affichage, comportement sur un téléphone. Un modèle qui tourne sur un poste de travail n’est pas un modèle validé.
À la fin, vous avez ça.
- Le modèle en glTF binaire, textures intégrées, à l’échelle en mètres
- Le poids et le nombre de faces mesurés, avant et après allègement
- L’intégration dans la page, essayée sur un téléphone
- La note d’export : ce qui a été approximé ou laissé de côté
Les fonctionnalités qui servent ici.
Les questions qu’on nous pose.
Et s’il en manque une, le Discord répond plus vite que cette page.
Quel poids viser ?
Le moins possible, et cela se mesure page par page : un modèle est une ressource lourde parmi d’autres. En dessous de quelques mégaoctets on reste tenable ; au-delà, il faut une interaction explicite pour le charger.
Faut-il une bibliothèque de rendu ?
Pour un objet qui tourne, un lecteur de modèle suffit souvent et pèse peu. Une bibliothèque complète se justifie quand il y a une scène, des interactions et une caméra à piloter.
Et sur mobile ?
C’est là qu’on décide : beaucoup de téléphones affichent correctement un modèle léger et renoncent sur un modèle de production. On essaie sur un appareil réel avant de promettre.