Plateformes différentes, destins différents : un guide de sélection de compression

Les quatre articles précédents traitaient les outils de compression des sommets et des textures. Mais savoir utiliser les outils est une chose ; lequel utiliser et dans quel scénario en est une autre. Cet article y répond — et vise à ce que vous puissiez décider dès la fin de la lecture.

Après cet article, vous devriez pouvoir répondre : sur quelle plateforme tourne mon projet, le goulot du premier rendu est-il le téléchargement ou le VRAM, et quel schéma les textures et les sommets doivent-ils chacun utiliser.

Cap : piloté par le scénario, pas par l'outil

Tout l'article n'a qu'un principe central, celui que la série ne cesse de souligner :

Il n'y a pas de schéma de compression « le meilleur » — seulement le schéma « le plus adapté au scénario ».

Trois variables qui guident le choix :

1. Plateforme/appareil : PC de bureau, navigateur mobile, casque VR, Mini Program — capacités radicalement différentes
2. Usage : affichage unique (page produit e-commerce) ou immersion longue (jeu VR)
3. Goulot principal : téléchargement lent, VRAM insuffisant, ou décodage qui bloque le premier rendu

Réfléchissez d'abord au goulot, puis revenez choisir les outils. La matrice ci-dessous fige cette réflexion.

Matrice centrale de décision : plateforme × schéma recommandé

C'est le tableau le plus important de l'article. Par plateforme, il donne le schéma recommandé pour texture et sommet, avec les raisons.

Plateforme / scénario	Schéma texture	Schéma sommet	Goulot principal	Raison clé
Web bureau (PC)	KTX2 ou WebP	MeshOpt / quantification	Vitesse de téléchargement	VRAM abondant ; focus sur petits fichiers, chargement rapide
Web mobile (téléphone)	KTX2 (obligatoire)	MeshOpt	VRAM	Le VRAM du téléphone est juste ; les textures doivent être compressées par bloc
WebXR / casque VR	KTX2 (obligatoire)	MeshOpt + LOD	VRAM + framerate	L'explosion du VRAM crashe ; les pertes d'images provoquent des nausées
WeChat Mini Program	KTX2 / WebP	MeshOpt / quant. pure	Paquet + compatibilité	Taille de paquet limitée ; éviter les décodeurs lourds
Produit e-commerce	WebP (léger) / KTX2 (précis)	MeshOpt	Vitesse du premier rendu	Exige une ouverture instantanée ; échanger taille contre vitesse
Grandes scènes / jumeau numérique	KTX2 (obligatoire)	MeshOpt + Draco + LOD	VRAM + draw calls	Beaucoup de textures, gros modèles ; compresser sur tous les fronts

Quelques jugements à retenir :

• Chaque fois que le VRAM est le goulot, KTX2 est obligatoire (mobile, VR, grandes scènes)
• Quand le téléchargement est le goulot et le VRAM abondant, WebP suffit (bureau, e-commerce)
• Pour les environnements sensibles au paquet comme les Mini Programs, préférer MeshOpt à Draco — décodeur plus petit, meilleure compatibilité
• Ne considérer Draco que pour de très gros modèles ; pour l'immense majorité des modèles petit-moyen, MeshOpt est plus équilibré

Formats de texture comparés sur toutes les dimensions

Savoir « utiliser KTX2 » ne suffit pas. Pour les formats de texture, déployons toutes les dimensions :

Format	Taille du fichier	Utilisation VRAM	Vitesse d'upload	Compatibilité	Qualité	Utilisation
PNG	Grande	Grande (après décomp.)	Lent	Très large	Sans perte	Valeurs exactes/alpha nécessaires ou fallback legacy
JPG	Minuscule	Grande (après décomp.)	Lent	Très large	Avec perte	Color maps, priorité réseau
WebP	Très petite	Grande (après décomp.)	Lent	Assez large	Élevée	Web bureau, vitesse de téléchargement
AVIF	Encore plus petite	Grande (après décomp.)	Lent	Progressive	Élevée	Nouvelles plateformes, compression extrême
KTX2 (ETC1S)	Petite	Minuscule	Rapide	Transcodage requis	Moyenne (couleur ok)	Color maps, mobile/VR
KTX2 (UASTC)	Moyenne	Petite	Rapide	Transcodage requis	Élevée	Normal/data maps

Notez les trois premières lignes (PNG/JPG/WebP/AVIF) avec un VRAM « grand » — aussi petit sur le disque soit-il, dans le VRAM toutes se décompressent en pixels bruts. C'est la limite fondamentale des formats traditionnels.

Une stratégie mixte est courante : les color maps clés utilisent KTX2 pour sécuriser le VRAM ; les maps secondaires (par ex. un petit emissive) utilisent WebP pour la commodité. Pas besoin de tout passer en KTX2 ; répartissez selon le goulot.

Diagramme de décision : choisir pas à pas

La matrice est le résultat ; le diagramme montre comment y arriver.

Où tourne votre projet ?
│
├─ Web bureau (VRAM abondant)
│   └─ Premier rendu lent ?
│       ├─ Oui → WebP (ou AVIF) + MeshOpt  [vitesse de téléchargement]
│       └─ Non, mais beaucoup de modèles → KTX2 + MeshOpt [marge pour l'avenir]
│
├─ Web mobile / VR / grandes scènes (VRAM juste)
│   └─ Les textures obligatoirement en KTX2 (couleur ETC1S, données UASTC)
│       └─ Sommets super-denses ?
│           ├─ Oui → + Draco [ratio max, tolère un décodage lent]
│           └─ Non → + MeshOpt [équilibré]
│
└─ Mini Program / runtime restreint
    └─ Sensible au paquet ?
        ├─ Oui → quantification pure ou MeshOpt + WebP [décodeur nul/petit]
        └─ Ça va → MeshOpt + KTX2 [combinaison standard]

Compression des sommets vs textures : où investir

Question fréquente : budget limité, optimiser quel bout en premier ? Regardez la composition du modèle :

Trait du modèle	Focus d'investissement	Raison
Personnage/produit PBR (beaucoup de maps)	Compression des textures	Les textures sont 80 %+ ; ROI des sommets faible
Modèle CAD/scan (sommets super-denses, peu de maps)	Compression des sommets	Les sommets sont la majeure partie
Personnage animé (squelette + skinning)	Investir dans les deux, mais sommets au-delà de Draco en priorité	Les données d'animation pèsent aussi ; Draco est faible en animation
Bâtiment/scène (grand, maps moyens)	Texture + LOD	Les textures économisent le VRAM ; le LOD économise des draw calls

Un classement de rendement grossier : texture KTX2 > sommet MeshOpt/quantification > simplification de géométrie (LOD) > sommet Draco. Faites d'abord les plus rentables.

Stratégie mixte : maps clés en KTX2, maps secondaires en WebP

Tous les maps ne méritent pas d'être compressés en KTX2. Un matériau PBR typique a 5-6 maps ; tout passer en KTX2 est beaucoup d'ingénierie et parfois superflu.

Répartition pratique :

• KTX2 obligatoire : albedo (grand, couleur), normal (sensible à la précision), roughness/metallic (affectent l'éclairage)
• WebP/JPG possible : emissive (généralement petit), AO (fréquence moyenne-basse), détail de normale (s'il y en a)

Critère : le map est-il grand, est-ce un détail haute fréquence, est-il échantillonné souvent ? Les trois → KTX2 ; aucun → un format traditionnel est plus simple.

Sélection automatisée : gltf-transform le fait en un coup

La commande optimize de gltf-transform est la balle d'argent pour la plupart des scénarios — elle détecte les types de texture, compresse les textures selon la stratégie recommandée et traite optionnellement les sommets.

# Installer
npm install -g @gltf-transform/cli

# Optimisation standard : texture KTX2 + sommet MeshOpt + déduplication
gltf-transform optimize model.glb model-optimized.glb \
  --texture-compress basisu \
  --meshopt

Référence des paramètres :

Paramètre	Effet	Défaut
--texture-compress basisu	Compresser les textures en KTX2 (auto ETC1S/UASTC)	Off
--meshopt	Activer la compression MeshOpt des sommets	Off
--simplify	Simplification de géométrie (réduit les sommets, avec perte)	Off
--weld	Fusionner les sommets dupliqués	On
--prune	Supprimer nœuds/matériaux inutilisés	On

Une combinaison de « compression forte » adaptée au mobile :

gltf-transform optimize model.glb model-mobile.glb \
  --texture-compress basisu \
  --meshopt \
  --simplify --simplify-ratio 0.5 \
  --prune --weld

Une combinaison « douce » pour le bureau (préserver le détail, ne compresser que textures et sommets) :

gltf-transform optimize model.glb model-desktop.glb \
  --texture-compress webp \
  --meshopt

Emballer en script réutilisable

Encapsulez ce qui précède en un script qui produit une version par plateforme :

// compress.mjs — produit différentes versions compressées par cible
import { optimize } from "@gltf-transform/functions";
import { NodeIO } from "@gltf-transform/core";
import { KHRONOS_EXTENSIONS } from "@gltf-transform/extensions";

const io = new NodeIO().registerExtensions(KHRONOS_EXTENSIONS);

const targets = {
  // Mobile : KTX2 + MeshOpt + simplification
  mobile: { texture: "basisu", meshopt: true, simplify: 0.5 },
  // VR : KTX2 + MeshOpt, pas de simplification (vision rapprochée en VR)
  vr: { texture: "basisu", meshopt: true, simplify: null },
  // Bureau : WebP + MeshOpt, doux
  desktop: { texture: "webp", meshopt: true, simplify: null },
};

const input = process.argv[2];
const doc = await io.read(input);

for (const [name, cfg] of Object.entries(targets)) {
  const out = doc.clone(); // copie indépendante par cible
  await optimize(out, {
    textureCompression: cfg.texture,
    meshCompression: cfg.meshopt ? "meshopt" : null,
    simplify: cfg.simplify != null ? { ratio: cfg.simplify } : null,
  });
  await io.write(`model-${name}.glb`, out);
  console.log(`✓ model-${name}.glb`);
}

node compress.mjs model.glb
# Produit model-mobile.glb / model-vr.glb / model-desktop.glb

À l'exécution, chargez la version correspondante par appareil (distinguer via UA ou détection de capacité WebGL) pour la meilleure expérience de premier rendu. Le prochain article relie tout cela dans le walkthrough de bout en bout.

Aide-mémoire en une ligne

• Le VRAM est le goulot → KTX2, pas le choix
• Le téléchargement est le goulot, VRAM abondant → WebP/AVIF aussi
• Sensible à la taille du décodeur → MeshOpt > quantification pure > Draco
• Très gros modèles → ne considérer Draco qu'alors
• Incertain → lancez gltf-transform optimize en un coup ; ajustez si erreur

Étape suivante

Le cadre de sélection est en place. Le dernier article clôt : à partir d'un modèle réel, parcourir tout le flux d'export Blender, de compression des textures, de compression des sommets et de chargement moteur, avec un script d'automatisation complet et une fiche mémo de la série.