Pourquoi les modèles 3D sont-ils si lourds ?

Votre modèle grossit en secret

Vous avez exporté un fichier GLB, 10 Mo, ça semble correct. Vous l'ouvrez sur votre téléphone : écran blanc, saccades, voire un plantage pur et simple.

Aucun problème sur ordinateur, mais ça explose sur téléphone. Ce n'est pas la faute du code. C'est une propriété contre-intuitive des modèles 3D : sur le disque et en VRAM, la taille est complètement différente.

Une image JPG sur le disque peut ne faire que 200 Ko. Mais le GPU ne comprend pas le JPG ; il ne comprend que les pixels bruts. Donc, avant d'être chargée en VRAM, l'image est entièrement décompressée. Une texture 2048x2048 consomme environ 22 Mo de VRAM une fois décompressée. Si vous utilisez 6 textures (albedo, normal, roughness, metallic, AO, emissive), un seul matériau coûte 132 Mo.

Un téléphone n'a peut-être au total que 2-4 Go de VRAM, et les textures d'un seul modèle en consomment 3-6 %. Et s'il y a 10 modèles dans la scène ?

Ouvrons-le : où vont les octets

Un modèle GLB typique comporte trois parties principales : les données de sommets, les textures, et les métadonnées plus les animations.

Prenons un vrai modèle PBR :

Composant	Ce que c'est	Part typique	Remarque
Textures	albedo, normal, roughness, metallic, AO, etc.	70-85 %	Presque toujours le gros
Données de sommets	position, normal, UV, tangent, color	10-20 %	Dépend de la complexité
Données d'animation	squelettes, skinning, images clés	0-15 %	Seulement si animé
Autre	définitions de matériaux, structure de scène, caméras	< 2 %	Négligeable

Les textures représentent environ 80 %. Souvent, on pense que ce sont les sommets qu'il faut optimiser, mais ce qui prend vraiment de la place, ce sont les textures.

« Petit sur le disque » ne veut pas dire « petit en VRAM »

C'est peut-être le point le plus important pour comprendre la performance 3D.

Le PNG et le JPG sont conçus pour le transfert réseau——petits sur le disque, téléchargement rapide. Mais le GPU ne peut pas les utiliser directement ; ils doivent d'abord être entièrement décompressés en pixels bruts. La formule :

VRAM = largeur * hauteur * 4 octets (RGBA) * 1.333 (avec mipmaps)

Une texture RGBA 4096x4096 :

Indicateur	Valeur
Taille du fichier PNG	~8 Mo
Taille du fichier JPG	~1.5 Mo
Utilisation VRAM (avec mipmaps)	~87 Mo

Un JPG de 1.5 Mo devient 87 Mo en VRAM.

Qu'est-ce que les mipmaps ? Le GPU génère une série de versions de plus en plus petites d'une texture, de la taille d'origine jusqu'à 1x1 pixel, chaque niveau faisant la moitié du précédent. Cela rend les objets éloignés plus rapides et plus nets à afficher, mais coûte environ 33 % de VRAM en plus. Presque toutes les applications 3D utilisent les mipmaps, donc ce surcoût est essentiellement standard.

Le PNG et le JPG sont donc comme des sacs de rangement sous vide——compressés et petits pour le voyage, mais vous devez tout déplier à destination. Le téléchargement est plus rapide, mais l'économie de VRAM est nulle.

Que se passe-t-il quand la VRAM s'épuise

Vous n'aurez pas de jolie boîte de dialogue « mémoire insuffisante ». La réalité est pire :

• Mobile : écran blanc, ou le système ferme carrément l'onglet
• Casques VR : chutes de frame. En VR, une image perdue n'est pas « un peu de lag »——elle provoque des nausées
• Desktop : clignotement des textures, dégradation, ralentissement du rendu

Sur Reddit, un développeur a construit une galerie WebXR et a entassé 60 images stéréoscopiques sur un Quest. Au début, ça marchait, puis c'est devenu de plus en plus instable jusqu'au plantage. Il a passé des jours à déboguer son code avant de réaliser qu'il n'avait jamais sérieusement réfléchi à la VRAM——il n'avait fait qu'envoyer des JPG au GPU en continu.

Deux voies pour la compression

La compression des modèles 3D se divise en deux directions :

Compression des sommets——stocke les données géométriques (coordonnées des sommets, normales, UV) de manière plus compacte. Par exemple, remplacer des flottants 32 bits par des entiers 16 bits (c'est ce qu'on appelle la quantification). Solutions représentatives : Draco, MeshOpt, KHR_mesh_quantization.

Compression des textures——garde les textures compressées même dans la VRAM. Le GPU décode les pixels individuels à la volée lors de l'échantillonnage, presque sans coût de performance. Solution représentative : KTX2 + Basis Universal.

	Compression des sommets	Compression des textures
Ce qu'elle réduit	Données géométriques	Textures
Effet typique	50-90 % plus petit	50-70 % plus petit sur le disque, 75 % de VRAM en moins
Avec perte ?	Oui, perte de précision	Oui, perte de qualité
Idéal pour	Modèles denses en sommets	Presque tous les modèles PBR
Voir	Partie 2	Parties 3 et 4

Un malentendu courant : compresser les sommets avec Draco et c'est plié. Mais les textures représentent 80 % de la taille du modèle——divisez les sommets par deux et le tout ne rétrécira peut-être que de 10 %. Il faut travailler sur les deux fronts.

Aucune méthode ne gagne partout

C'est la thèse centrale de toute la série :

Des plateformes, des appareils et des usages différents appellent des stratégies de compression différentes.

Scénario	Goulet d'étranglement principal	Priorité
Vitrine web desktop	Vitesse de téléchargement	Taille du fichier
Navigateur mobile	VRAM	Compression des textures
Casque VR	VRAM + framerate	Compression des textures + simplification des sommets
WeChat Mini Program	Taille du paquet + compatibilité	Options légères (MeshOpt)
Grandes scènes	VRAM + draw calls	Compression complète + LOD

Chaque prochain article ne dira pas simplement « utilisez X et c'est fini ». Il expliquera : où X brille, quand il se retourne contre vous, et quand vous devriez plutôt utiliser Y.

Prochaines étapes

Cet article a cerné le problème. Le prochain passe à la pratique——à la rencontre des trois outils de la compression des sommets : quantification, MeshOpt et Draco.