Gestion dynamique de la lumière avec OpenGL - Partie 4 : éclairage par pixel simple

Pour bien comprendre le fonctionnement de l'éclairage par pixel, je reviens rapidement sur le calcul de l'éclairage déjà vu dans le premier tutoriel sur l'éclairage par vertex.
Comme nous l'avons vu, l'éclairage d'une surface se calcule en fonction de :

• son éloignement par rapport à la lumière, c'est ce qu'on appelle l'atténuation. Nous avons vu comment calculer l'atténuation grâce au light mapping dynamique, je ne reviendrai donc pas dessus dans ce tutoriel ;
• son orientation par rapport à la lumière. Ainsi, si la surface tourne le dos à la lumière, elle n'est pas éclairée, alors que si elle est orientée en face de la lumière, elle reçoit l'ensemble de la lumière. C'est cette gestion de l'orientation de la surface qui nous intéresse plus particulièrement dans ce tutoriel.

Pour gérer l'orientation de la face par rapport à la lumière, nous avons vu dans le premier tutoriel que nous avons besoin de deux informations : le vecteur perpendiculaire à la surface aussi appelé la normale à la surface et le vecteur dirigé vers la lumière. Une fois ces deux vecteurs récupérés, il nous suffit d'effectuer le produit scalaire entre les deux vecteurs pour avoir le coefficient de luminosité perçu par la surface. C'est le fameux NdotL, avec N représentant la normale à la surface, L le vecteur vers la lumière, et dot le produit scalaire.

Jusqu'à présent, nous avions utilisé la normale des vertex pour effectuer ce calcul, mais à partir de maintenant, nous allons utiliser une normal map dont je vais présenter le principe.

Pour notre calcul, il nous faut récupérer la normale à la surface. Lorsqu'on utilise une normale par vertex, le résultat des calculs est interpolé entre les sommets du polygone, ce qui donne de mauvais résultats lorsque le polygone est trop étendu. En fait, on se retrouve dans des situations où le résultat correspond à un cas où la normale est interpolée comme sur le schéma suivant.

On voit clairement que le résultat de l'interpolation n'est pas valide pour le calcul de la luminosité : la normale interpolée n'est plus normalisée, on va donc avoir des problèmes d'échelle dans le résultat final (on parle de scaling problems). En effet, si la normale est de longueur 0.8, la luminosité finale sera réduite de 20 % par rapport à ce qu'elle aurait dû être.

C'est pour résoudre ce problème qu'on utilise une texture qui va stocker les normales de la surface, ainsi, on réduit les problèmes liés à l'interpolation des normales (ils ne sont pas complètement supprimés étant donné qu'une texture de trop faible résolution sera elle-même interpolée quand on s'en approche).

Une normal map est en fait une texture standard dont les composantes RBG ne sont plus interprétées comme des couleurs, mais comme des vecteurs 3D représentant la normale d'une surface. On peut donc facilement donner l'impression qu'un polygone n'est plus plat en modifiant l'orientation des normales dans la normal map. Les calculs d'éclairage vont s'effectuer sur ces normales perturbées, donnant ainsi une impression de volume virtuel.

Contrairement à ce qu'on pourrait croire, une normal map peut parfaitement se regarder à l'œil et est parfaitement compréhensible une fois qu'on sait ce qu'elle représente. Voici par exemple l'exemple de la local map utilisée dans ce tutoriel :

J'en vois dans le fond qui se demandent bien pourquoi j'utilise le terme de local map au lieu de parler de normal map comme je l'ai fait jusqu'à présent. Tout cela s'explique par le fait qu'il existe deux catégories de normal maps : les global maps et les local maps.

Les global maps sont des normal maps qui stockent des vecteurs orientés dans toutes les directions. Le gros avantage des global maps est qu'elles peuvent être utilisées directement sans avoir à passer par le calcul de l'espace local des vertex. Ceci permet donc de calculer l'éclairage plus vite étant donné que nous n'avons pas tous les calculs de projections, que nous verrons par la suite, à effectuer. Par contre, le gros problème des global maps est qu'elles ne sont pas réutilisables. C'est-à-dire qu'une global map ne peut être utilisée que pour un objet donné. Imaginez une scène ou les graphistes sont obligés de faire une global map propre à chaque polygone… Ce serait totalement impossible à gérer. En fait les global maps sont très peu utilisées, on en trouve parfois lorsqu'il faut afficher des terrains. Étant donné que le terrain a peu de chances d'être modifié, on calcule une global map au lancement, et ainsi, on gagne en temps d'exécution lors de l'affichage.

Les local maps, au contraire des global maps, ne contiennent que des normales orientées sur l'axe des Z positifs. Ainsi, une local map ne représente pas la surface d'un objet, mais une surface générique pouvant être utilisée sur plusieurs objets différents. Le fait qu'elles ne soient orientées que dans une seule direction oblige à des calculs relativement complexes à comprendre au départ, mais, en contrepartie, on peut réutiliser les local maps à volonté. Le nom de local map vient du fait que pour pouvoir utiliser une local map, il faut effectuer les calculs d'espaces locaux des vertex, que nous verrons par la suite. On peut facilement différencier une local map d'une global map en regardant la couleur générale de la texture. Une global map sera potentiellement de toutes les couleurs alors qu'une local map est généralement bleue étant donné que les vecteurs pointent vers les Z positifs (donc la composante bleu du vecteur est souvent proche de 1).

Étant donné que nous ne nous préoccupons que des local maps, j'utiliserai indifféremment le terme normal map et local map pour designer la local map par la suite.

Maintenant que nous avons vu le principe de la normal map, il nous reste une étape à voir : comment faire pour pouvoir calculer le produit scalaire pour chaque pixel ? C'est ce que nous allons voir dans la partie qui vient.

OpenGL ne propose pas de fonction standard pour modifier le calcul au niveau des pixels : pour ça, il faut encore une fois passer par des extensions. Ici, nous allons utiliser l'extension env_dot3 qui va nous permettre de calculer le produit scalaire entre la normale de la surface et le vecteur vers la lumière.

Contrairement aux extensions utilisées dans les tutoriels précédents, l'extension env_dot3 n'utilise pas de fonction particulière à charger, elle apporte juste des paramètres en plus à passer aux fonctions standard OpenGL. Comme ce n'est pas une utilisation commune d'une extension, je vais présenter rapidement son fonctionnement afin d'avoir une meilleure compréhension des calculs effectués par la carte graphique.

Voici donc comment faire pour configurer une unité de texture pour qu'elle réalise le calcul de DOT3 bump mapping :

glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, normalMapId);
glTexEnvf(GL_TEXTURE_ENV,GL_TEXTURE_ENV_MODE,GL_COMBINE_ARB);
glTexEnvf(GL_TEXTURE_ENV,GL_RGB_SCALE_ARB,1); 
glTexEnvf(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_DOT3_RGB_ARB);
glTexEnvf(GL_TEXTURE_ENV,GL_SOURCE0_RGB_ARB,GL_PREVIOUS_ARB);
glTexEnvf(GL_TEXTURE_ENV,GL_SOURCE1_RGB_ARB,GL_TEXTURE);
glTexEnvf(GL_TEXTURE_ENV,GL_OPERAND0_RGB_ARB,GL_SRC_COLOR);
glTexEnvf(GL_TEXTURE_ENV,GL_OPERAND1_RGB_ARB,GL_SRC_COLOR);

Voilà, c'est tout ce qu'il y a à faire. En fait, on signale à OpenGL qu'on souhaite que la carte graphique effectue le produit scalaire entre l'unité de texture courante et la couleur précédente dans le pipeline. Il nous suffit donc de passer le vecteur vers la lumière dans la couleur précédente (par exemple via un appel à glColor comme nous allons le faire dans ce tutoriel ou via une cube map comme nous le ferons dans le prochain tutoriel), et la carte graphique va se charger pour nous du calcul.

La gestion de l'espace local est très certainement la partie la plus complexe à comprendre (et à expliquer ;-) ) du bump mapping. En effet, elle fait appel à des notions d'algèbre linéaire qui ne sont pas triviales à comprendre dans un premier temps. Je vais essayer de l'expliquer, mais si jamais vous ne comprenez pas, n'hésitez pas à allez chercher d'autres sources de documentation sur Internet. En effet, il faut parfois plusieurs explications différentes pour bien appréhender ce concept.

Le problème avec les normal maps, c'est que si on tourne l'objet sur lequel la texture est plaquée, les normales, elles, ne sont pas tournées, on se retrouve donc avec un objet qui n'est plus sur le plan XY (plan sur lequel sont générées les normal maps qui pointent donc vers les Z positifs), mais avec des normales qui sont restées sur le plan XY. Pour mieux montrer les problèmes, quelques schémas sont sûrement plus efficaces que des lignes de textes :

Ici, on a le cas idéal : la surface est bien orientée sur le plan XY, les normales (en rouge) de la normal map pointent donc dans la bonne direction, le calcul va bien s'effectuer.

Ici, le schéma montre ce que l'on souhaiterait avoir : la surface n'est pas alignée sur le plan XY, mais les normales de la normal map ont bien été tournées, le calcul va donc bien s'effectuer. Mais malheureusement, comme je l'expliquais au-dessus, ce n'est pas ce qu'il se passe réellement. On se trouve en fait avec le cas suivant :

Ici, la surface a bien été tournée, mais les normales de la normal map ne subissent pas de transformation (ce qui se passe effectivement au niveau de la carte graphique qui n'a pas de notions d'orientation des surfaces), on se retrouve donc avec un calcul faux (ici, le calcul va donner un produit scalaire supérieur à 0, donc éclairé, alors que la surface ne devrait pas l'être, car elle tourne le dos à la lumière. Étant donné qu'on ne peut pas modifier les normales de la normal map, le seul moyen d'obtenir un calcul juste est de modifier le seul vecteur modifiable : le vecteur vers la lumière, ce qui nous donne le résultat suivant :

Ici, on a modifié le vecteur vers la lumière pour obtenir un calcul valide. En fait, sur ce schéma, l'angle entre le vecteur vers la lumière et la normale de la surface est le même que sur le deuxième schéma (aux erreurs de dessin près ;-) ). On a donc un calcul valide qui donne le même résultat que si nous avions tourné la normale de la surface comme dans le cas du deuxième schéma.

Il nous faut donc calculer ce vecteur vers la lumière (qui n'est du coup plus vraiment orienté vers la lumière ;-) ) pour prendre en compte les surfaces transformées. Si toutes nos surfaces étaient générées sur le plan XY puis tournées pour atteindre leur place finale, le calcul ne poserait pas de problème, il suffirait de faire subir la rotation inverse à notre vecteur vers la lumière pour obtenir ce que l'on souhaite. Mais malheureusement, ce n'est pas le cas. Nous n'avons généralement que trois vertex pour définir un triangle et pas de rotation ou autre à notre disposition. Il nous faut donc calculer quelque chose qui permet d'obtenir le résultat souhaité : l'espace local.

L'espace local (aussi appelé espace tangent) est un espace tridimensionnel formé de trois vecteurs et d'une position dans l'espace. Les trois vecteurs permettent d'orienter l'espace local dans l'espace global, et la position correspond à l'origine de l'espace local dans l'espace global. Oui, dit comme ça, c'est incompréhensible ;-). En fait il faut voir cet espace de la même manière que les axes standards X, Y et Z qui forment eux aussi un espace local positionné en {0,0,0}.

Bon j'ai dit que notre espace local était formé de trois vecteurs, il est temps d'en parler plus en détail. Les trois vecteurs qui forment notre espace local sont appelés Tangente, Binormale et Normale (on voit souvent le diminutif TBN utilisé pour parler de l'espace local). On connaît déjà la normale qui n'est autre que la normale du vertex. Les deux autres vecteurs sont perpendiculaires à la normale, mais surtout, ils sont proportionnels aux coordonnées de texture du polygone. En effet, il faut que notre espace prenne en compte le fait que les coordonnées de textures puissent être tournées/étirées/inversées.

Encore une fois, un petit schéma permet d'avoir les idées plus claires.

Nous avons vu ce qu'est un espace local, mais il faut encore savoir à quoi il peut bien nous servir. En fait c'est lui qui va nous permettre de calculer le vecteur vers la lumière modifiée pour qu'il soit valide. Pour cela, il suffit de projeter le vecteur vers la lumière dans l'espace local. C'est ici qu'intervient l'algèbre linéaire : pour projeter un vecteur dans un espace 3D formé de trois vecteurs, il suffit, pour chaque composante du vecteur cible, de calculer le produit scalaire entre le vecteur à transformer et le bon vecteur de l'espace local (en fait il faut les prendre dans l'ordre Tangente pour la composante X, Binormale pour la composante Y et Normale pour la composante Z). Le calcul de la projection d'un vecteur correspond donc à ça :
VecteurDestination.x = vecteurSource . Tangente
VecteurDestination.y = vecteurSource . Binormale
VecteurDestination.z = vecteurSource . Normale

Maintenant que nous savons ce qu'est un espace local et à quoi il sert, nous allons pouvoir voir comment le calculer. Mais avant, je vais parler des problèmes que peut entraîner tout ceci au niveau du chargement des modèles.

Le fait de prendre les tangentes et binormales en compte nous oblige à modifier notre classe de modèle. En effet, il nous faut ajouter un tableau de vecteurs pour les tangentes et un autre tableau pour les binormales. Tout ceci se fait facilement en ajoutant au fichier Model.h ceci :

/**
 * le tableau de binormales (il y a autant de binormales que de normales)
 */
Vecteur * binormals;
/** 
 * le tableau de tangentes (il y a autant de tangentes que de normales);
 */
Vecteur * tangents;

Que l'on n’oubliera pas de supprimer dans le destructeur bien entendu.

Mais le principal problème vient du remplissage de ces tableaux. Idéalement, pour connaître la taille des tableaux, il suffit de prendre la taille du tableau de normales. En effet, si le format de modèles gère bien les normales partagées, nous aurons donc un espace local par normale partagée. Malheureusement, dans notre cas, les normales ne sont pas bien partagées. Lors de l'export en .obj, si deux normales ont les mêmes valeurs, alors l'exporteur n'en conserve qu'une seule et change les indices des faces en conséquence. Ceci pose problème, car on peut très bien avoir des normales orientées dans le même sens, mais liées à des faces ayant des coordonnées de textures différentes. Ceci entraîne de graves incohérences dans les calculs par la suite.

Dorénavant, nous n'utiliserons plus les normales contenues dans le fichier, mais nous les calculerons à la main au chargement. Le problème que pose cette méthode est que les normales seront toutes adoucies, y compris celles qui sont sur des faces avec une orientation très différente (comme sur un cube par exemple). Ceci aura des conséquences sur la qualité de l'éclairage, certaines faces pouvant tourner le dos à la lumière tout en étant toujours éclairées. J'ai choisi de ne pas régler ce problème, car il entraîne une trop forte complication du code pour un débutant, et surtout, il peut être réglé en choisissant un format de modèle qui nous assure d'une bonne gestion des normales partagées.

Maintenant nous pouvons voir le nouveau code de chargement des modèles :

bool Model::load(const std::string & filePath)
{
    // on crée un lecteur de .obj
    OBJReader reader(filePath);
    // on charge le model
    if (reader.load())
    {
        // le model est bien chargé
        // on alloue le tableau de vertex
        vertex = new Vecteur[reader.getVertex().size()];
        nbVertex = 0;
        // on copie les informations des vertex
        for (std::vector<OBJReader::OBJVector>::iterator it =
        reader.getVertex().begin();    it != reader.getVertex().end(); ++it)
        {
            vertex[nbVertex].x = (*it).x;
            vertex[nbVertex].y = (*it).y;
            vertex[nbVertex].z = (*it).z;
            nbVertex++;
        }
        // on alloue le tableau de normales
        // les tableaux de binormales et tangentes font la
        // même taille que le tableau de normales
        normals = new Vecteur[nbVertex];
        binormals = new Vecteur[nbVertex];
        tangents = new Vecteur[nbVertex];
        // on les initialise au vecteur null
        for (int i = 0; i < nbVertex; i++)
        {
            normals[i].x = normals[i].y = normals[i].z =
            binormals[i].x = binormals[i].y = binormals[i].z = 
            tangents[i].x = tangents[i].y = tangents[i].z = 0.0f;
        }
        // on alloue le tableau de coordonnées de textures
        texCoords = new TexCoord[reader.getTexture().size()];
        nbTexCoord = 0;
        // on copie les informations de coordonnées de texture
        for (std::vector<OBJReader::OBJtexCoord>::iterator it =
        reader.getTexture().begin();it != reader.getTexture().end(); ++it)
        {
            texCoords[nbTexCoord].u = (*it).u;
            texCoords[nbTexCoord].v = (*it).v;
            nbTexCoord++;
        }
        // on alloue le tableau des faces
        faces = new Face[reader.getFace().size()];
        nbFaces = 0;
        // on copie les informations des faces
        for (std::vector<OBJReader::OBJface>::iterator it = reader.getFace().begin();
        it != reader.getFace().end(); ++it)
        {
            faces[nbFaces].vertexIndex[0] = (*it).vertex[0];
            faces[nbFaces].vertexIndex[1] = (*it).vertex[1];
            faces[nbFaces].vertexIndex[2] = (*it).vertex[2];
            faces[nbFaces].normalIndex[0] = (*it).normal[0];
            faces[nbFaces].normalIndex[1] = (*it).normal[1];
            faces[nbFaces].normalIndex[2] = (*it).normal[2];
            faces[nbFaces].texCoordIndex[0] = (*it).texture[0];
            faces[nbFaces].texCoordIndex[1] = (*it).texture[1];
            faces[nbFaces].texCoordIndex[2] = (*it).texture[2];
            nbFaces++;
        }
 
        // maintenant que nous avons toutes les informations sur les faces,
        // on peut calculer l'espace local
        for (int i = 0; i < nbFaces; i++)
        {
            computeLocalSpace(faces[i]);
        }
        // il ne faut pas oublier de renormaliser les tangentes et binormales
        for (int i = 0; i < nbVertex; i++)
        {
            binormals[i].normalise();
            tangents[i].normalise();
            normals[i].normalise();
        }
        return true;
    }
    else
    {
        return false;
    }
}

La méthode computeLocalSpace() correspond à la méthode de calcul de l'espace local que nous allons voir maintenant.

Le calcul de l'espace local pour une face est finalement assez simple une fois qu'on a compris ce qu'est réellement l'espace local. Il suffit de calculer deux vecteurs qui suivent les bords du polygone et sont proportionnels aux coordonnées de textures. Une fois qu'on a effectué ce calcul pour la face, il ne nous reste plus qu'à additionner le résultat aux tangentes, binormales et normales des vertex du polygone. Je tiens à signaler qu'il existe plusieurs algorithmes pour calculer cet espace local, il est donc possible que vous en trouviez des différents sur le NET.

Le calcul de l'espace local pour une face donne le code suivant :

void Model::computeLocalSpace(Face &face)
{
    // on calcule 2 vecteurs formant les bords du triangle
    // le vecteur side0 est celui allant du vertex 0 au vertex 1
    Vecteur side0 = vertex[face.vertexIndex[1]] - vertex[face.vertexIndex[0]];
    // le vecteur side1 est celui allant du vertex 0 au vertex 2
    Vecteur side1 = vertex[face.vertexIndex[2]] - vertex[face.vertexIndex[0]];
 
    // ici on calcule la normale à la face
    Vecteur normal = side0.cross(side1);
    normal.normalise();
 
    // maintenant on calcule les coefficients des tangentes
    // ces coefficients sont calculés en fonction des 
    // coordonnées de textures du polygone
    float deltaT0 = texCoords[face.texCoordIndex[1]].v -
                    texCoords[face.texCoordIndex[0]].v;
    float deltaT1 = texCoords[face.texCoordIndex[2]].v -
                    texCoords[face.texCoordIndex[0]].v;
    // on effectue la même chose pour la binormale
    float deltaB0 = texCoords[face.texCoordIndex[1]].u -
                    texCoords[face.texCoordIndex[0]].u;
    float deltaB1 = texCoords[face.texCoordIndex[2]].u -
                    texCoords[face.texCoordIndex[0]].u;
    // le facteur permettant de rendre les tangentes et binormales
    // proportionnelles aux coordonnées de textures.
    // nous aurons donc des vecteurs dont la norme dépend des coordonnées 
    // de textures.
    float scale = 1/ ((deltaB0 * deltaT1) - (deltaB1 * deltaT0));
 
    // on calcule la tangente temporaire
    Vecteur tmpTangente = ((side0*deltaT1) - (side1*deltaT0))*scale;
    tmpTangente.normalise();
 
    // on calcule la binormale temporaire
    Vecteur tmpBinormal = ((side0*(-deltaB1)) + (side1*deltaB0))*scale;
    tmpBinormal.normalise();
 
    // nous avons donc maintenant les tangentes, binormales et normales de la face.
    // on les additionne à celles déjà présentes dans les tableaux
    tangents[face.vertexIndex[0]] += tmpTangente;
    tangents[face.vertexIndex[1]] += tmpTangente;
    tangents[face.vertexIndex[2]] += tmpTangente;
 
    binormals[face.vertexIndex[0]] += tmpBinormal;
    binormals[face.vertexIndex[1]] += tmpBinormal;
    binormals[face.vertexIndex[2]] += tmpBinormal;
 
    normals[face.vertexIndex[0]] += normal;
    normals[face.vertexIndex[1]] += normal;
    normals[face.vertexIndex[2]] += normal;
 
    // il ne faudra pas oublier de renormaliser les vecteurs par la suite.
}