Réalisation d'un moteur 3D en C++, partie VIII : les shaders

Initialement utilisés par Pixar pour effectuer le rendu des images de leurs films, les shaders ont en 2001 été introduits dans les API 3D temps réel (DirectX 8.0 et OpenGL 1.4), et très vite commencés à être supportés par les principaux constructeurs de cartes graphiques (nVidia, ATI).

Mais qu'est-ce qu'un shader au juste ?

Les shaders sont des programmes, écrits dans un langage pseudo-assembleur ou plus récemment pseudo-C, directement executable par la carte graphique. Cela permet ainsi de court-circuiter certaines parties du FFP (Fixed Function Pipeline -- les fonctions précablées dans le hardware), et d'offrir au développeur une énorme flexibilité.
Il existe deux types de shaders : les vertex shaders (ou encore vertex programs) et les pixel shaders (ou encore fragment programs, ou fragment shaders). Tous deux fonctionnent de la même manière, excepté qu'ils remplissent chacun un rôle différent.

Selon l'API et le langage utilisés, le vocabulaire utilisé pour désigner les shaders varie : vertex shader, pixel shader (DirectX), vertex program, fragment shader, ou encore fragment program (OpenGL). Dans un souci de clarté, nous n'utiliserons ici que le couple "vertex / pixel shader".

Le vertex shader vient remplacer les parties "transformation & éclairage" du pipeline de rendu, se plaçant donc au début de celui-ci, juste après le tesselateur de surface. Règle importante : un vertex shader ne pourra toujours traiter qu'un vertex à la fois. Ainsi il va recevoir en entrée tous les vertices (les uns après les autres) que vous aurez envoyé à la carte graphique, et devra renvoyer ceux-ci transformés et éclairés. Hormis ce minimum syndical à effectuer, vous êtes libre de faire subir à vos vertices à peu près tout et n'importe quoi. Et c'est là la grande force des shaders : il n'y a qu'à faire marcher son esprit créatif pour obtenir des effets toujours plus impressionnants.

Le pixel shader vient lui remplacer les parties "texturage, filtrage et mélange" du pipeline, ce qui va cette fois le placer à la fin du pipeline, juste avant l'étape finale de rendu. De la même manière que pour un vertex shader, un pixel shader ne pourra toujours traiter qu'un pixel à la fois. Son rôle sera de créer le pixel final qui sera écrit sur le color-buffer, à partir des informations sur celui-ci telles que les textures qu'il utilise, la couleur diffuse, la couleur spéculaire, et les coordonnées de textures. Tout comme pour les vertex shaders, il est tout à fait possible de faire subir à vos pixels n'importe quel autre traitement, et de créer ainsi des effets tout aussi chouettos.

Avant toute chose, les shaders sont des programmes. Ils se présentent donc soit sous forme de fichiers, soit directement sous forme de chaîne de caractères dans votre application C++ ; l'API 3D étant ensuite capable de se débrouiller avec le nom de fichier ou le pointeur vers la chaîne de caractère.

A leur apparition, il n'existait que des langages pseudo-assembleur pour écrire les shaders. La syntaxe était donc très simple : une liste d'instructions élémentaires (mov, add, mul, ...), une liste de registres (constantes, entrées, sorties, ...) et le tour est joué -- un peu comme pour l'assembleur x86 que vous connaissez déjà (ou pas).

Voici par exemple un pixel shader ASM 1.1 DirectX9 très simple, effectuant une transformation des pixels en niveaux de gris :

; On précise toujours quelle version est utilisée
ps.1.1

; Définition d'une constante dans le registre c0
def c0, 0.30, 0.59, 0.11, 1.0

; On indique que l'on va utiliser la texture de niveau 0, identifiée par t0
tex t0

; On effectue un produit scalaire entre t0 (la texture) et c0 (la constante définie plus haut)
; On place le résultat dans r0, registre temporaire
dp3 r0, t0, c0

; On multiplie le résultat précédent par la couleur diffuse, stockée dans le registre d0
; On place le résultat dans r0, qui est aussi le registre de sortie
mul r0, r0, d0

Avec l'arrivée de versions de shaders plus élaborées, plus riches en instructions, ainsi que de programmes toujours plus complexes, est apparue la nécessité de développer des langages de plus haut niveau pour les shaders. Ainsi sont apparus le HLSL (High Level Shading Language) chez DirectX, le GLSL (openGL Shading Language) chez OpenGL, et le Cg (C for Graphics) chez nVidia.
Tous ces langages possèdent une syntaxe proche du C, permettant de gérer les nouveautés des shaders (boucles, conditions, variables de types entiers, booléens, ...) beaucoup plus naturellement et facilement.

Je vous le disais en introduction, le principal défaut des shaders est la diversité des langages et technologies permettant de les utiliser, et les incompatibilités que cela entraîne. Cela concerne surtout OpenGL : contrairement à DirectX qui n'est développé que par Microsoft et peut se permettre une mise à jour tous les deux mois, la standardisation d'OpenGL est contrôlée par l'ARB, un commité composé des plus grands constructeurs de hardware. Les nouvelles fonctionnalités mettent donc souvent beaucoup de temps à être étudiées, votées, approuvées puis finalement intégrées. Ainsi le support des shaders (enfin, chez l'ARB on préfère le terme program) ne s'est fait que très tardivement, surtout pour les fragment programs. Comme les constructeurs n'attendent généralement pas sur l'ARB pour implémenter les nouvelles fonctionnalités, on se retrouve ainsi avec une multitude d'extensions, bien sûr différentes pour chacun d'eux tant au niveau du langage que de l'utilisation au niveau de l'API.
Ce phénomène tend à disparaître avec la normalisation des versions / langages de shaders, mais cela concerne encore à l'heure actuelle une large tranche de hardware que l'on ne peut pas encore considérer obsolète.

Voici donc un éventail, en théorie complet, des différents langages et extensions utilisés selon les APIs et les constructeurs.

2-3-1. DirectX▲

float4 main(float4 Diffuse : COLOR0,
            float2 TexCoord0 : TEXCOORD0,
            uniform sampler2D Tex0) : COLOR0
{
    return tex2D(Tex0, TexCoord0) * Diffuse;
}

2-3-2. OpenGL▲

!!TS1.0
texture_2d();

!!RC1.0
{
  rgb
  {
    col0 = tex0.rgb * col0.rgb;
  }
  alpha
  {
    col0 = tex0.a * col0.a;
  }
}
out.rgb = unsigned(col0.rgb);
out.a = unsigned(col0.a);

!!FP1.0

TEX R0, f[TEX0].xyxx, TEX0, 2D;
MULR o[COLR], R0, f[COL0];

END

!!ARBvp1.0

ATTRIB v24 = vertex.texcoord[0];
ATTRIB v19 = vertex.color;
ATTRIB v18 = vertex.normal;
ATTRIB v16 = vertex.position;

PARAM c0[4] = { program.local[0..3] };

MOV result.color.front.primary, v19;
MOV result.texcoord[0], v24;

DP4 result.position.x, c0[0], v16;
DP4 result.position.y, c0[1], v16;
DP4 result.position.z, c0[2], v16;
DP4 result.position.w, c0[3], v16;

END

varying vec3 lightDir, normal;

void main()
{
    normal = normalize(gl_NormalMatrix * gl_Normal);
    lightDir = normalize(vec3(gl_LightSource[0].position));

    gl_TexCoord[0] = gl_MultiTexCoord0;
    gl_Position = ftransform();
}

Cg étant une API développée par nVidia, tout ce qu'il faut pour démarrer avec se trouve sur leur site développeur. Afin de pouvoir développer avec Cg il faut télécharger et installer le SDK Cg. Celui-ci contient tout ce qu'il faut : fichiers bibliothèques, en-têtes, fichiers DLLs, documentations, exemples de code pour chaque API, et exemples de shaders.

Les dernières versions de Cg (1.3 et 1.4) comportent un bug empêchant la compilation des vertex shaders 1.1 sous DirectX9 (profil CG_PROFILE_VS_1_1). Ainsi si vous comptez supporter ce profil, il vaudra mieux installer une version antérieure de Cg (la version utilisée ici est la 1.2). Ce bug aurait semble-t-il déjà été signalé à nVidia, peut-être sera-t-il donc corrigé dans la prochaine version.

Si vous ne souhaitez que compiler ou executer la démo fournie avec ce tutoriel, pas besoin d'installer le SDK Cg : tout ce qu'il vous faut est fourni dans les bibliothèques externes (zip).

Enfin, vous trouverez sur le site CgShaders de nombreuses ressources utiles, notamment un forum actif et des tonnes d'exemples de shaders.

Cg peut s'utiliser de deux manières.

La première permet d'utiliser la partie haut niveau de Cg et ne nécessite donc que le runtime de base de Cg (cg.lib / cg.dll). Vous pourrez compiler un programme, récupérer son code ASM, ses paramètres, ... mais toute la partie bas niveau, propre à chaque API, ne sera pas fournie. En d'autres termes, il faudra développer nous-mêmes la gestion de tous les types de shaders cités plus haut, et fournir à Cg celui qui va bien selon le profil choisi. Autant dire que ça ne sert à rien ici. Cela peut par contre être utile dans des moteurs implémentant déjà toute la partie bas niveau (par exemple Ogre), et souhaitant pouvoir utiliser Cg indépendamment de l'API 3D.

La seconde permet elle d'encapsuler absolument toute la partie relative aux APIs 3D et nécessite donc les runtimes correspondants : cgD3D9 et cgGL. C'est là que Cg nous intéresse, car c'est lui qui va s'occuper de trouver le meilleur profil de shader selon les capacités de notre carte graphique, et le gérer de manière transparente pour nous. En clair nous n'aurons à aucun moment besoin d'appeler une fonction spécifique à DirectX ou OpenGL pour gérer nos shaders, et nous n'aurons jamais à nous soucier de la version de shader ou des extensions OpenGL à utiliser selon le hardware. Plutôt cool.

A noter que le SDK contient un compilateur Cg en ligne de commande (cgc.exe), qui se révèlera bien utile lors du développement de vos shaders. Notamment pour détecter les erreurs de syntaxe de ceux-ci et les corriger sans avoir à lancer votre application, ou encore générer le code ASM correspondant à vos shaders, soit pour tenter de les optimiser, soit pour les utiliser dans une appli qui ne supporte pas Cg.

Le langage Cg, proche du C, est en fait une copie conforme du langage HLSL de chez DirectX ; nVidia a travaillé conjointement à Microsoft sur cette partie. Un bon point déjà, puisque vous pourrez d'ores et déjà utiliser vos connaissances et vos shaders HLSL directement en Cg.

Nous n'aborderons pas ici les détails du langage, ceci étant parfaitement fait dans les nombreux documents et exemples du SDK de Cg, ainsi que dans divers tutoriels sur le net.

Voici par exemple l'équivalent Cg du pixel shader ASM vu précédemment, effectuant une mise en niveaux de gris :

float4 main(float4 Diffuse : COLOR0,      // Couleur diffuse
            float2 TexCoord0 : TEXCOORD0, // Coordonnées de texture 0
            uniform sampler2D Tex0)       // Texture 0
: COLOR0
{
    // Définition des coefficients pour la mise en niveaux de gris
    float3 Coeff = float3(0.30, 0.59, 0.11);

    // On renvoie le produit scalaire entre les coefficients et
    // le pixel (texture modulée par la couleur diffuse)
    return dot(tex2D(Tex0, TexCoord0) * Diffuse.rgb, Coeff);
}

Comme vous le voyez, le langage est déjà nettement plus flexible, explicite et concis.

Dernier point de ce court chapitre sur le langage : les paramètres. Comme nous allons voir par la suite comment intéragir sur ceux-ci dans notre code, il est important de voir en premier lieu ce qu'ils sont, et comment ils fonctionnent.

Si vous vous rappelez bien, nous avons vu précédemment que les shaders fonctionnaient avec un certain nombre de registres :

• Les registres d'entrée, qui sont automatiquement remplis avec les données à traiter (vertex ou pixel).
• Les registres de sortie, que vous devez remplir avec le résultat de vos shaders.
• Les registres temporaires servant aux calculs intermédiaires.
• Et enfin... les registres de constantes.

Les registres de constantes sont importants car ce sont eux qui permettent l'interaction entre le shader et l'application. En effet, si ces registres ne sont pas modifiables dans un shader, ils le sont en revanche dans l'application via des fonctions de l'API 3D (ou de Cg dans notre cas). Cela permet d'envoyer certaines variables et d'influer sur le comportement des shaders. L'exemple le plus typique est l'envoi de la matrice de transformation (modèle - vue - projection) aux vertex shaders, car ceux-ci devront quoiqu'il arrive effectuer la transformation des vertices par cette matrice. On peut également imaginer envoyer la position de la lumière courante, la direction de la caméra, le temps actuel, une couleur, ... Bref, tout ce qui peut servir au shader.

Cg étant un langage pseudo-C, ces paramètres sont assimilables à des variables. A ce titre elles possèdent donc un nom (beaucoup plus pratique qu'un indice de registre), et peuvent être reçues en paramètre des fonctions ou encore déclarées globalement. Le runtime Cg nous permet de modifier ces variables très facilement, nous verrons comment dans le chapitre suivant.

Commençons donc par le début, à savoir le loader. Comme d'habitude il faudra le faire dériver de ILoader<IShaderBase>, puisque ce sont des IShaderBase qui seront chargés et renvoyés au reste du moteur.

class CShadersLoader : public ILoader<IShaderBase>
{
    ...
};

C'est ce loader qui va manipuler la partie "haut-niveau" de Cg : initialisations, libérations, et chargement d'un programme Cg à partir d'un fichier. Le reste sera relégué aux renderers, et aux runtimes Cg correspondants (cgD3D9 et cgGL).

CShadersLoader::CShadersLoader(TShaderType Type) :
m_Type(Type)
{
    // Enregistrement du callback d'erreur
    cgSetErrorCallback(&OnError);

    // Création du context
    m_Context = cgCreateContext();
}

La première chose à faire avant d'utiliser Cg, est de créer un contexte. Le contexte peut être unique ou non, l'important étant que c'est à partir de lui que nous allons pouvoir effectuer toutes nos opérations futures avec Cg.
Cg nous permet également d'enregistrer une fonction callback, qui sera appelée à chaque erreur détectée par Cg ; pratique pour éviter de tester chaque retour de fonction.
Voici notre fonction de gestion d'erreur :

void CShadersLoader::OnError()
{
    throw CException(cgGetErrorString(cgGetError()));
}

Elle récupère l'erreur survenue (cgGetError), sa description sous forme de chaîne (cgGetErrorString) puis la remonte sous forme d'exception.

CShadersLoader::~CShadersLoader()
{
    // Destruction du context
    if (m_Context)
        cgDestroyContext(m_Context);
}

A la destruction du loader il faudra cette fois détruire le contexte, via la fonction cgDestroyContext.

IShaderBase* CShadersLoader::LoadFromFile(const std::string& Filename)
{
    // Récupération du profil et des options de compilation
    CGprofile    Profile = Renderer.GetShaderProfile(m_Type);
    const char** Options = const_cast<const char**>(Renderer.GetShaderOptions(m_Type));

    // Chargement et compilation du shader
    CGprogram Program;
    try
    {
        Program = cgCreateProgramFromFile(m_Context,
                                          CG_SOURCE,
                                          Filename.c_str(),
                                          Profile,
                                          "main",
                                          Options);
    }
    catch (CException& E)
    {
        throw CLoadingFailed(Filename, E.what() +
                                       std::string("\n") +
                                       cgGetLastListing(m_Context));
    }

    return Renderer.CreateShader(Program, m_Type);
}

Vient finalement la plus grosse partie du loader : la fonction LoadFromFile. Dans un premier temps, on déclare une variable de type CGprogram, qui représente le shader Cg que nous allons charger. Cette tâche est effectuée par la fonction cgCreateProgramFromFile, qui prend en paramètre notre contexte, un flag indiquant que nous allons lui donner à manger du code source écrit en Cg, le nom du fichier, le profil (ie. la version de shader bas niveau à utiliser), le point d'entrée du shader (qui sera ici toujours "main"), et finalement les options de chargement.
Le profil utilisé et les options correspondantes sont spécifiques à chaque API et sont donc stockées au niveau du renderer, mais nous verrons cela plus tard.

MediaManager.RegisterLoader(new CShadersLoader(SHADER_VERTEX), "vcg");
MediaManager.RegisterLoader(new CShadersLoader(SHADER_PIXEL),  "pcg");

Il ne reste donc plus qu'à enregistrer auprès du gestionnaire de médias notre loader, ou plutôt nos loaders : un pour les vertex shaders, et un pour les pixel shaders. En effet même si Cg ne fait aucune différence entre les deux types de shaders, l'API 3D le fait et nous devrons donc veiller à ne pas perdre cette différenciation.

Et voilou, dorénavant nos shaders pourront être chargés automatiquement, reste plus qu'à les coder !

A ce niveau il ne reste en fait plus grand chose à faire pour avoir des shaders fonctionnels. La classe de base, IShaderBase, aura très peu de travail : principalement stocker le programme Cg (de type CGprogram comme nous l'avons vu précédemment), stocker son type (vertex shader ou pixel shader -- c'est important car Cg ne fait pas la distinction), et fournir un accès en écriture aux paramètres du shader. Et bien sûr, en toute bonne ressource qu'elle est, elle devra hériter de IResource afin de bénéficier de son compteur de référence et de sa gestion sympathique via le ResourceManager.

class YES_EXPORT IShaderBase : public IResource
{
public :

    // Construit le shader à partir d'un programme Cg
    IShaderBase(CGprogram Program, TShaderType Type);

    // Destructeur
    virtual ~IShaderBase();

    // Renvoie le type du shader
    TShaderType GetType() const;

    // Change un paramètre (scalaire ou vecteur) du shader
    virtual void SetParameter(const std::string& Name, const float* Value) = 0;

    // Change un paramètre (matrice) du shader
    virtual void SetParameter(const std::string& Name, const CMatrix4& Value) = 0;

protected :

    // Renvoie le CGparameter associé à un identifiant
    CGparameter GetParameter(const std::string& Name) const;

    // Données membres
    CGprogram   m_Program; ///< Programme Cg associé au shader
    TShaderType m_Type;    ///< Type du shader (vertex / pixel)
};

Voyons à présent le détail de ces fonctions, très simple puisque cela ne consiste grosso modo qu'à reléguer le sale boulot au runtime Cg.

IShaderBase::IShaderBase(CGprogram Program, TShaderType Type) :
m_Program(Program),
m_Type   (Type)
{

}

Rien de magique dans le constructeur : on stocke les paramètres reçus.

IShaderBase::~IShaderBase()
{
    // Destruction du programme
    if (m_Program)
        cgDestroyProgram(m_Program);
}

Le destructeur lui ne devra pas oublier de détruire le programme via la fonction cgDestroyProgram.

CGparameter IShaderBase::GetParameter(const std::string& Name) const
{
    return cgGetNamedParameter(m_Program, Name.c_str());
}

Enfin, nous avons la fonction GetParameter qui ne sert qu'à récupérer un paramètre (sous forme de CGparameter) donné par son nom. Cette fonction est en accès protégé, elle ne servira qu'aux classes dérivées.

Un petit mot sur les fonctions SetParameter pour conclure ce chapitre. Tout d'abord il faut en distinguer deux versions : la première prenant un pointeur sur floats (obligatoirement 4), la seconde prenant une matrice. Cette séparation est nécessaire, car un quadruplet de floats occupe un registre shader, alors qu'une matrice, composée de 16 floats, doit en occuper 4.
Il est important de noter que nous aurions pu utiliser le runtime "haut-niveau" de Cg pour implémenter ces fonctions et ainsi nous passer de classes dérivées (puisque ce sont les seuls traitement nécessitant les runtimes Dx et OGL) : il existe en effet les fonctions cgSetParameter et cgSetMatrixParameter. Malheureusement elles ne fonctionnent pour le moment qu'avec le runtime OpenGL, pour gérer l'envoi de paramètre avec DirectX il faudra obligatoirement passer par la version du runtime DirectX (cgD3D9SetUniform et cgD3D9SetUniformMatrix -- voir plus loin). Sur ce coup là, faudra engueuler nVidia.

Comme nous venons de le voir, la seule tâche nécessitant d'être spécialisée est l'envoi de paramètres. Enfin pas tout à fait : il faut également dire au runtime cgD3D9 ou cgGL de prendre en charge comme un grand notre shader.

Cela se fait par la fonction cgGLLoadProgram pour OpenGL

COGLShader::COGLShader(CGprogram Program, TShaderType Type) :
IShaderBase(Program, Type)
{
    cgGLLoadProgram(m_Program);
}

Et par la fonction cgD3D9LoadProgram pour DirectX

CDX9Shader::CDX9Shader(CGprogram Program, TShaderType Type) :
IShaderBase(Program, Type)
{
    cgD3D9LoadProgram(m_Program, true, 0);
}

La version DirectX prend deux paramètres supplémentaires : le premier indiquant si l'on souhaite utiliser la fonctionnalité parameter shadowing, le second permettant de passer des options au compilateur de shader DirectX (par exemple D3DXASM_DEBUG -- voir la doc du SDK Dx pour la liste des flags valides). Le parameter shadowing permet d'avoir une gestion des paramètres identique à celle d'OpenGL, à savoir qu'un changement de paramètre n'est pas immédiat : ils sont stockés en interne et ne sont envoyés que lors de l'envoi du shader à l'API. Sans parameter shadowing, Cg enverrait directement les paramètres du shader à DirectX à chaque appel de SetParameter.

Viennent maintenant les fonctions SetParameter justement, qui ne sont là encore que des appels aux fonctions correspondantes de l'API Cg :

void CDX9Shader::SetParameter(const std::string& Name, const float* Value)
{
    cgD3D9SetUniform(GetParameter(Name), Value);
}

void CDX9Shader::SetParameter(const std::string& Name, const CMatrix4& Value)
{
    cgD3D9SetUniformMatrix(GetParameter(Name), reinterpret_cast<const D3DXMATRIX*>(&Value.Transpose()));
}

void COGLShader::SetParameter(const std::string& Name, const float* Value)
{
    cgGLSetParameter4fv(GetParameter(Name), Value);
}

void COGLShader::SetParameter(const std::string& Name, const CMatrix4& Value)
{
    cgGLSetMatrixParameterfc(GetParameter(Name), Value);
}

Ce sera tout pour nos spécialisations de IShaderBase, reste maintenant à agrémenter nos renderers des fonctions vitales : création des shaders, et changement de ceux-ci.

Comme nous l'avons vu dans le chapitre concernant le loader, il faut stocker dans nos renderers le meilleur profil de chaque type de shader ainsi que les options de chargement correspondantes.

class YES_EXPORT IRenderer
{
    ...

    CGprofile   m_VSProfile;    ///< Profil utilisé pour créer les vertex shaders
    CGprofile   m_PSProfile;    ///< Profil utilisé pour créer les pixel shaders
    const char* m_VSOptions[2]; ///< Options utilisées pour créer les vertex shaders
    const char* m_PSOptions[2]; ///< Options utilisées pour créer les pixel shaders
};

Une fois encore, leur récupération (que l'on peut placer dans la fonction membre Setup du renderer) ne pose aucun problème :

void CDX9Renderer::Setup(HWND Hwnd)
{
    ...

    // Paramètrage du runtime Cg D3D
    cgD3D9SetDevice(m_Device);
    m_VSProfile    = cgD3D9GetLatestVertexProfile();
    m_PSProfile    = cgD3D9GetLatestPixelProfile();
    m_VSOptions[0] = cgD3D9GetOptimalOptions(m_VSProfile);
    m_VSOptions[1] = NULL;
    m_PSOptions[0] = cgD3D9GetOptimalOptions(m_PSProfile);
    m_PSOptions[1] = NULL;
}

Le runtime cgD3D9 ayant besoin du device pour se débrouiller, il ne faut pas oublier de lui fournir via la fonction cgD3D9SetDevice. Il ne faudra pas non plus oublier de le retirer avant de détruire le device (sinon gare à la fuite mémoire), en appelant cgD3D9SetDevice avec NULL comme paramètre.

void COGLRenderer::Setup(HWND Hwnd)
{
    ...

    // Paramètrage du runtime Cg OGL
    m_VSProfile = cgGLGetLatestProfile(CG_GL_VERTEX);
    m_PSProfile = cgGLGetLatestProfile(CG_GL_FRAGMENT);
    cgGLSetOptimalOptions(m_VSProfile);
    cgGLSetOptimalOptions(m_PSProfile);
    m_VSOptions[0] = NULL;
    m_PSOptions[0] = NULL;
}

Côté OpenGL aucune initialisation particulière à faire pour le runtime cgGL, on peut même s'économiser le stockage des paramètres puisque Cg s'en occupe via la fonction cgGLSetOptimalOptions ; ceux-ci seront ensuite automatiquement pris en compte lors de l'appel à cgCreateProgramFromFile.

Ceci étant fait, il reste à implémenter la fonction de création de shaders (CreateShader), ainsi que celle de changement (SetVertexShader / SetPixelShader).
CreateShader est limité à son minimum syndical, à savoir renvoyer une instance de la classe de shader associée au renderer :

IShaderBase* CDX9Renderer::CreateShader(CGprogram Program, TShaderType Type) const
{
    return new CDX9Shader(Program, Type);
}

IShaderBase* COGLRenderer::CreateShader(CGprogram Program, TShaderType Type) const
{
    return new COGLShader(Program, Type);
}

Les fonctions de changement de shader (SetVertexShader et SetPixelShader) sont elles aussi très simples. On y ajoute toute de même un test, afin de s'assurer que le type de shader reçu en paramètre colle bien avec ce que l'on veut ; n'oubliez pas que Cg ne fait pas cette distinction.

void CDX9Renderer::SetVertexShader(const IShaderBase* Shader)
{
    const CDX9Shader* DxShader = static_cast<const CDX9Shader*>(Shader);

    if (DxShader)
    {
        if (DxShader->GetType() != SHADER_VERTEX)
            throw CException("Type de shader incorrect : pixel shader reçu dans SetVertexShader");

        cgD3D9BindProgram(DxShader->GetProgram());
    }
    else
    {
        m_Device->SetVertexShader(NULL);
    }
}

Remarque : il n'y a apparemment aucun moyen de ne spécifier aucun shader directement via l'API cgD3D9 (avec cgD3D9BindProgram(NULL) par exemple), ainsi nous sommes obligés d'utiliser D3D directement avec m_Device->SetVertexShader(NULL).

void COGLRenderer::SetVertexShader(const IShaderBase* Shader)
{
    const COGLShader* OGLShader = static_cast<const COGLShader*>(Shader);

    if (OGLShader)
    {
        if (OGLShader->GetType() != SHADER_VERTEX)
            throw CException("Type de shader incorrect : pixel shader reçu dans SetVertexShader");

        cgGLBindProgram(OGLShader->GetProgram());
        cgGLEnableProfile(m_VSProfile);
    }
    else
    {
        cgGLDisableProfile(m_VSProfile);
        cgGLUnbindProgram(m_VSProfile);
    }
}

Rien de particulier pour la version OpenGL, si ce n'est qu'il ne faut pas oublier qu'il y a deux fonctions à appeler.

Quant à la fonction SetPixelShader, elle est identique à sa petite soeur SetVertexShader, on pourra donc se passer de l'étude de son code.

Dernier maillon de notre gestion sans faille (tout du moins on espère s'en approcher) des shaders, la classe CShader. Elle ne sert qu'à encapsuler de manière plus sympathique nos pointeurs sur IShaderBase, afin de fournir une sémantique de valeur à tout ce tintouin et occasionnellement quelques fonctionnalités supplémentaires. Vous l'aurez compris, ce sera cette classe qui sera finalement manipulée par nous et par l'utilisateur.

class YES_EXPORT CShader
{
public :

    // Charge le shader à partir d'un fichier
    void LoadFromFile(const std::string& Filename);

    // Décharge le shader
    void Unload();

    // Récupère un pointeur sur le shader interne
    const IShaderBase* GetShader() const;

    // Change un paramètre du shader (float)
    void SetParameter(const std::string& Name, float Value);

    // Change un paramètre du shader (vector 2)
    void SetParameter(const std::string& Name, const TVector2F& Value);

    // Change un paramètre du shader (vector 3)
    void SetParameter(const std::string& Name, const TVector3F& Value);

    // Change un paramètre du shader (vector 4)
    void SetParameter(const std::string& Name, const TVector4F& Value);

    // Change un paramètre du shader (matrice)
    void SetParameter(const std::string& Name, const CMatrix4& Value);

    // Change un paramètre du shader (couleur)
    void SetParameter(const std::string& Name, const CColor& Value);

private :

    // Données membres
    CSmartPtr<IShaderBase, CResourceCOM> m_Shader; ///< Pointeur sur le shader
};

Comme vous le voyez, nous avons une toute tripotée de fonctions SetParameter, chacune prenant un paramètre de type différent. Ces fonctions ne font rien d'autre que de transformer le paramètre reçu en float* et le renvoyer à m_Shader, mais elles seront bien pratiques puisqu'elles nous éviteront de se précoccuper du type de ce que l'on envoie en paramètre. Pour rappel, dans un shader un paramètre peut représenter n'importe quoi : une couleur, une matrice, un vecteur, une valeur, ... Ces fonctions ne sont donc pas anodines.

Reste la fonction LoadFromFile, qui encapsule les appels au MediaManager et au ResourceManager de manière totalement automatique :

void CShader::LoadFromFile(const std::string& Filename)
{
    // On regarde si le shader n'a pas déjà été chargée
    m_Shader = CResourceManager::Instance().Get<IShaderBase>(Filename);

    // Si il ne l'est pas, on le charge
    if (!m_Shader)
    {
        // Création du shader
        m_Shader = CMediaManager::Instance().LoadMediaFromFile<IShaderBase>(Filename);

        // Ajout aux ressources
        CResourceManager::Instance().Add(Filename, m_Shader);
    }
}