Imaginez un cube tout simple, matériau PBR appliqué, un rendu qui devrait être propre. Sauf que le relief part dans le mauvais sens, la surface a l'air cuite au lieu de brillante, et vous ne savez même pas dans quel canal chercher. Ça m'est arrivé, et la cause tenait en une ligne : deux textures qui n'étaient pas dans le bon espace colorimétrique, appliquées comme si elles l'étaient.
Réponse directe : un matériau PBR moderne (modèle metallic-roughness de glTF 2.0) se lit à travers six canaux qui ne se comportent pas tous pareil. Base color et emissive stockent de la couleur perçue et se lisent en sRGB. Metallic, roughness, normal et occlusion stockent des données de calcul, pas de la couleur, et se lisent en espace linéaire, appelé Non-Color dans Blender. Confondre les deux familles casse le rendu sans message d'erreur.
Le problème que le SERP ne raconte jamais#
J'ai comparé une bonne dizaine de guides en ligne sur le sujet avant d'écrire celui-ci, et ils se ressemblent tous : une liste de quatre ou cinq canaux, une définition d'une ligne chacun, zéro mention de l'espace colorimétrique. C'est le genre de vocabulaire qu'on récite sans jamais expliquer pourquoi un normal map qui a l'air correct dans l'explorateur de fichiers produit un relief inversé une fois dans le moteur.
Le mécanisme, lui, est documenté noir sur blanc dans la spécification glTF 2.0 du Khronos Group, l'organisme qui standardise le format. Deux familles de canaux coexistent dans un même matériau, et elles ne racontent pas la même chose à la carte graphique.
Base color : la couleur qui n'en est pas toujours une#
Premier piège, et le plus répandu : traiter base color comme un synonyme moderne de « diffuse ». Ce n'est vrai qu'à moitié. La spécification glTF est explicite sur ce point : pour un matériau non métallique, base color représente bien la couleur diffuse réfléchie. Mais pour un métal, base color encode autre chose, la réflectance mesurée à incidence normale, notée F0 dans le jargon du rendu physique. Ce n'est plus une couleur diffuse, c'est une donnée spéculaire, et le modèle fixe même une valeur de F0 par défaut de 4 % pour tous les non-métaux, faute de pouvoir la spécifier autrement.
Concrètement, une même carte de couleur change de sens selon la valeur du canal metallic qui l'accompagne. Sur un personnage riggé en armure, la zone métallique de la texture ne « réfléchit pas une couleur », elle définit combien de lumière rebondit à angle droit. C'est une nuance que je trouve sous-expliquée partout, y compris dans certains tutoriels que j'ai suivis à mes débuts.
La texture baseColorTexture doit être encodée en sRGB sur 8 bits, puis décodée en valeurs linéaires avant tout calcul de rendu. C'est la même règle que pour l'emissive, l'autre canal qui stocke de la couleur perçue plutôt qu'une donnée physique.
Roughness et metalness, compressés dans le même fichier#
Détail d'optimisation qui surprend souvent les débutants : dans le modèle metallic-roughness de glTF, roughness et metalness ne sont pas deux textures séparées. Elles partagent une seule image, appelée metallicRoughnessTexture, où le canal vert porte la roughness et le canal bleu porte la metalness. Le canal rouge, lui, ne sert à rien dans cette texture précise.
Cette texture combinée doit être encodée en transfert linéaire, jamais en sRGB : ce sont des valeurs de calcul, pas des couleurs à afficher telles quelles. C'est exactement la règle que le manuel Blender appelle Non-Color : les images qui ne représentent pas des couleurs, comme les normal, bump ou stencil maps, ne doivent jamais subir de conversion colorimétrique, et leur espace doit être réglé sur Non-Color dans le logiciel.
Normal map : une direction, pas une couleur#
Pour situer ce canal dans un pipeline complet, du concept art à l'asset game-ready, notre guide de modélisation 3D pour le jeu vidéo détaille le bake des normal maps étape par étape. Le normal map est sans doute le canal le plus mal compris de tout le lexique, parce que visuellement, il ressemble à une image bleu-violet presque décorative. En réalité, chaque pixel encode une direction en trois dimensions dans l'espace tangent de la surface : le canal rouge porte la composante X, le canal vert porte Y, le canal bleu porte Z. La conversion précise, selon glTF, place le rouge entre 0 et 1 pour représenter X entre -1 et 1, le vert suit la même règle pour Y, et le bleu occupe la plage 0,5 à 1 pour représenter Z entre 0 et 1. Toute cette texture est stockée en transfert linéaire, jamais en sRGB.
C'est là qu'intervient la convention qui fait planter le plus de rendus en silence : le sens du canal vert. La documentation Unity est formelle sur son propre moteur, elle utilise des normal maps en convention Y+, dite format OpenGL. Or la spécification glTF fixe elle-même la composante Y du canal vert comme la direction « haut » en espace tangent. Un normal map exporté avec le canal vert inversé par rapport à ce que le moteur attend produit un relief visuellement retourné, des creux qui semblent des bosses et inversement, sans qu'aucun message d'erreur ne le signale.
Ce canal se prête bien à une compression à deux canaux indépendants de type BC5, qui interpole séparément le rouge et le vert sur 8 bits chacun, contrairement aux formats de compression couleur qui traitent RGB de façon corrélée. C'est une caractéristique du format de compression lui-même, documentée par Microsoft dans le guide Direct3D.
Occlusion et emissive, les deux extrêmes du canal unique#
L'occlusion ambiante tient dans un seul canal, le rouge, sans que les autres canaux de la texture n'interviennent : 0,0 signifie une zone totalement occultée, sans lumière indirecte, 1,0 signifie une zone pleinement exposée à la lumière indirecte. Comme roughness et metalness, c'est une donnée de calcul, elle se lit en Non-Color.
L'emissive fait l'inverse : elle stocke de la couleur perçue, la lumière que la surface émet elle-même, et se lit donc en sRGB exactement comme base color. Sur les six canaux du lexique, ce sont les deux seuls à partager cette règle. Pour voir comment ces mêmes textures se comportent différemment selon le moteur de rendu, notre comparatif Cycles, Eevee et Octane creuse la question.
specular-glossiness, l'ancien modèle qu'on croise encore#
Avant metallic-roughness, glTF proposait un autre modèle, specular-glossiness, avec une extension dédiée nommée KHR_materials_pbrSpecularGlossiness. Cette extension porte aujourd'hui le statut « Archived » dans le dépôt Khronos, remplacée par KHR_materials_specular. Ce n'est plus une alternative active, c'est un chapitre clos qu'on retrouve encore dans certains vieux assets ou pipelines hérités.
Pour qui doit convertir un vieux fichier, la relation entre les deux modèles se résume à une formule reprise sur un miroir du texte de l'ancienne extension : glossiness équivaut à 1 moins roughness. Une donnée pratique à connaître avant de rouvrir un projet ancien, mais qui ne remplace pas une conversion propre du reste des paramètres.
OpenPBR, le standard qui tente de mettre tout le monde d'accord#
Plus récent, OpenPBR Surface est une spécification portée par l'Academy Software Foundation, la fondation qui héberge des outils de production utilisés dans l'industrie du rendu. La version en vigueur au moment d'écrire est la 1.1.1, datée du 17 avril 2026. L'objectif affiché par la spécification est de fournir un modèle de matériau standardisé, décrit par sa structure physique plutôt que par une implémentation logicielle particulière, pour répondre à ce que le texte présente comme un besoin urgent des industries du rendu physiquement basé.
Est-ce que ça va vraiment unifier les workflows d'un studio à l'autre, remplacer les habitudes déjà prises autour de metallic-roughness ? Là, j'hésite franchement entre l'enthousiasme du standard bien pensé et le scepticisme de quelqu'un qui a déjà vu des specs prometteuses rester des specs. Du côté de Blender, le nœud n'existe pas dans la version publiée : les notes de la 5.2 LTS, sortie le 14 juillet 2026, n'en disent pas un mot, et la page des nœuds de shader de son manuel n'en référence aucun de ce nom. Le sujet est ouvert sur le tracker du projet, sans qu'aucune version le livre à ce jour. L'adoption d'un standard se juge sur des années, de toute façon, pas sur une version.
Le lexique des canaux, en un coup d'œil#
| Canal | Ce qu'il contient | Espace colorimétrique |
|---|---|---|
| Base color | Couleur diffuse réfléchie pour un non-métal, réflectance F0 pour un métal | sRGB |
| Metallic | Valeur binaire ou intermédiaire, empaquetée dans le canal bleu de metallicRoughnessTexture | Linéaire (Non-Color) |
| Roughness | Rugosité de surface, empaquetée dans le canal vert de metallicRoughnessTexture | Linéaire (Non-Color) |
| Normal | Direction XYZ en espace tangent, rouge = X, vert = Y, bleu = Z | Linéaire (Non-Color) |
| Occlusion | Occlusion ambiante portée par le seul canal rouge | Linéaire (Non-Color) |
| Emissive | Lumière propre émise par la surface | sRGB |
Si vous partez de zéro sur Blender, notre tutoriel pour débuter en 3D pose les bases avant d'attaquer ce lexique.
FAQ#
Base color et diffuse, c'est la même chose ?#
Non, pas exactement. Pour un matériau non métallique, base color correspond effectivement à la couleur diffuse réfléchie. Mais pour un métal, base color encode une réflectance F0, une donnée spéculaire, pas une couleur diffuse. Le terme « diffuse », hérité des modèles pré-PBR, ne recouvrait que le premier cas.
Pourquoi Blender demande de régler le normal map sur Non-Color ?#
Parce que le normal map ne représente pas des couleurs à afficher, mais des données de direction. Le manuel Blender est explicite : les images comme les normal, bump ou stencil maps ne doivent jamais subir de conversion colorimétrique, sous peine de fausser les valeurs qu'elles encodent.
Qu'est-ce que le modèle metallic-roughness de glTF ?#
C'est le modèle de matériau de référence de la spécification glTF 2.0, qui définit les paramètres PBR autour de deux propriétés principales, metallic et roughness, empaquetées ensemble dans une seule texture pour limiter le nombre de fichiers.
specular-glossiness est-il encore un modèle valide aujourd'hui ?#
Non. L'extension glTF qui le portait, KHR_materials_pbrSpecularGlossiness, est classée « Archived » par Khronos et remplacée par KHR_materials_specular. On le croise encore dans d'anciens projets, jamais comme choix pour un nouveau pipeline.
Roughness et metalness sont-elles deux textures distinctes ?#
Non, en général : dans le modèle glTF elles partagent un seul fichier, metallicRoughnessTexture : le canal vert porte la roughness, le canal bleu porte la metalness, et cette texture s'encode en transfert linéaire.
Qu'est-ce qu'OpenPBR Surface ?#
Une spécification de matériau portée par l'Academy Software Foundation, en version 1.1.1 datée du 17 avril 2026, qui vise à standardiser le modèle physique des matériaux plutôt qu'une implémentation logicielle donnée.
Sources#
- glTF 2.0 Specification, consulté le 7 septembre 2026
- KHR_materials_pbrSpecularGlossiness, statut Archived, consulté le 7 septembre 2026
- Blender 4.2 LTS Manual, Image Settings, consulté le 7 septembre 2026
- Unity Manual, Introduction to normal maps, consulté le 7 septembre 2026
- Unity Manual, Set a project's color space, consulté le 7 septembre 2026
- OpenPBR Surface specification, consulté le 7 septembre 2026
- Blender 5.2 LTS Release Notes, consulté le 7 septembre 2026
- Shader Nodes, Blender 5.2 LTS Manual, consulté le 7 septembre 2026
- Microsoft Learn, Direct3D 10 Block Compression, consulté le 7 septembre 2026
