Réalisation d'un moteur 3D en C++ - partie III : les vertex / index buffers

Les vertices (pluriel de vertex, ou encore sommet en français) sont la base du rendu 3D polygonal, on peut les imaginer comme de simples points 3D. Ce sont eux qui nous permettront de construire les primitives de base (points, lignes, triangles), qui à leur tour nous permettront de construire des modèles plus complexes (maison, arbre, ...) puis finalement notre scène 3D toute entière. Prenons l'exemple classique d'un cube en 3D. Celui-ci se compose de 6 faces carrées, soit en fait 12 triangles acollés deux à deux, puisque le carré ne fait pas partie de nos primitives de base. Ces 12 triangles peuvent à leur tour être décomposés en triplets de 3 sommets, soit 36 vertices. Ainsi, pour afficher notre cube 3D à l'écran, il suffira de stocker nos 36 vertices dans l'ordre approprié, puis de demander à notre API de les prendre par groupes de trois pour former et afficher nos triangles, et ainsi notre fameux cube.

On le devine aisément, pour afficher nos triangles la carte 3D aura besoin de notre tableau de vertices. Selon l'API utilisée, il existe différents moyens d'envoyer nos vertices au hardware.
Sous DirectX il n'en existe que deux : soit sous forme de vertex buffer, soit directement avec un pointeur sur un tableau classique, auquel cas c'est l'API qui se chargera de construire un vertex buffer interne à chaque envoi. Vous l'aurez deviné, il vaut donc mieux utiliser directement un vertex buffer sous peine de dégrader sérieusement les performances.
OpenGL est lui un peu plus varié : on peut envoyer nos vertices directement un à un (très peu efficace), sous forme de display lists (permet à l'API d'optimiser un peu), les stocker au préalable dans des vertex arrays (plus efficace), ou en utilisant des vertex buffer objects (ce qu'on appelle communément VBO). Cette dernière approche est celle qui se rapproche le plus de nos VB de chez DirectX, et est sans doute la plus performante également. Ce sont donc sur les VBO que notre implémentation OpenGL des vertex buffers va se baser.

Dans la suite de cet article, les abréviations VB et IB seront simplement des raccourcis pour "vertex buffer" et "index buffer".

Nous parlons sans cesse de vertex buffers depuis le début de cet article, mais qu'est-ce donc exactement ? Et bien rien d'autre que ce que leur nom indique : des zones mémoires contenant des sommets. Mais attention, les vertex buffers ne sont pas des zones mémoires comme les autres, et il faudra les manipuler d'une manière bien particulière. La principale raison à cela est que ce sera l'API 3D qui gèrera de manière efficace nos buffers, souvent directement en mémoire vidéo, c'est pourquoi nous ne pourrons pas faire n'importe quoi en les manipulant. Globalement, nous ne pourrons accéder à de tels buffers qu'en les ayant au préalable verrouillés, pour signaler à l'API que nous sommes en train de farfouiller dedans. Une fois que nous aurons fini nos manipulations il faudra les déverrouiller, et rendre ainsi la main à l'API. Bref vous l'aurez compris, la manipulation des vertex buffers est délicate. Si votre ordinateur reboot subitement lors de l'affichage de votre magnifique mouton 3D ou bien vous affiche un écran bleu, ne vous étonnez pas, c'est que vous avez mis le boxon en mémoire vidéo ! Bon mais rassurez-vous, la plupart du temps nous ne toucherons plus à nos buffers une fois remplis.

Mais revenons donc à nos mout... euh vertices. On a dit qu'on pouvait les voir comme de simples points 3D, ce qui est en fait incomplet. Les vertices doivent bien posséder une position, mais ils peuvent également stocker d'autres attributs de notre sommet : sa normale, sa couleur, ses coordonnées de texture, voire même n'importe quelles données persos. Ainsi il n'existera pas un unique type de vertex dans notre moteur, mais toute une multitude. Chaque objet possédant de la géometrie (en gros, tout ce qui s'affiche à l'écran) pourra avoir sa propre structure de vertices, selon les informations qu'il aura besoin de stocker. Par exemple nous n'allons pas stocker la normale d'un vertex pour un affichage 2D, ou encore des coordonnées de texture pour un objet non-texturé. Mais rassurez-vous, le vertex buffer ne se soucie pas de ce genre de considération. Tout ce qu'il aura à faire sera stocker nos vertices, peu importe ce qu'on leur mettra dedans. Pour renseigner l'API sur le contenu effectif de nos vertices, nous utiliserons un autre concept : les déclarations de vertices. Mais nous n'en sommes pas encore là, voyons à présent plutôt les copains des vertices : les indices.

Dans le rendu troidé, les indices (pluriel d'index, ou encore indice en français ...bon ok c'était facile là) vont souvent de paire avec les vertices. Pour illustrer leur utilité, reprenons l'exemple de notre cube. Celui-ci est composé de 12 triangles, soit 36 vertices donc. Mais si on fait le compte, seuls 8 sommets suffisent à définir un cube, chacun sera donc dupliqué un certain nombre de fois avec l'approche précédente. Pas génialement efficace n'est-ce pas ? Les indices sont là pour pallier à ce problème : ils permettent d'utiliser un même vertex dans plusieurs triangles sans dupliquer celui-ci dans le vertex buffer. Ainsi notre VB ne sera plus composé que de 8 vertices différents, et c'est maintenant notre index buffer qui comportera 36 éléments. Les indices n'étant rien de plus que des entiers (16 ou 32 bits), le gain est non-négligeable. Il faut toujours garder en tête que la mémoire vidéo est limitée, et que les transferts entre celle-ci et la mémoire centrale le sont aussi. A noter également que l'utilisation des indices permet de tirer partie du cache vertex de notre carte 3D, c'est-à-dire qu'un même vertex utilisé dans plusieurs triangles ne sera transformé qu'une seule fois, ce qui constitue encore une belle économie.
Le principe de fonctionnement des indices est très simple : plutôt que de prendre les vertices dans leur ordre d'apparition, la carte les prendra dans l'ordre dans lequel ils apparaissent dans l'index buffer. Par exemple si notre VB contient les vertices [V0, V1, V2, V3] et que notre IB contient les indices [0, 1, 2, 2, 1, 3], les 2 triangles résultant seront formés des vertices (V0, V1, V2) et (V2, V1, V3).

Au niveau du fonctionnement, on peut assimilier les index buffers aux vertex buffers. Leur gestion sera à peu de choses près identique, à savoir qu'il faudra les verrouiller / déverrouiller pour accéder à leurs éléments. Cette constatation est importante pour la suite, car cela va notamment nous permettre d'utiliser une seule et même classe pour nos VB et nos IB. Voyons dès à présent comment intégrer ces classes à notre moteur, et comment réaliser efficacement la spécialisation pour chaque API.

La première chose à faire pour tirer un code commun à toutes les API, est d'examiner le fonctionnement de celles-ci. Pour les buffers, la tâche sera heureusement aisée : nos VB/IB DirectX et nos VBO OpenGL se manipulent plus ou moins de la même manière, à savoir comme dit précédemment via verrouillage / déverrouillage. Cette petite constatation effectuée, nous pouvons mettre sur pied une classe de base abstraite pour les buffers de notre moteur:

class YES_EXPORT IBufferBase
{
public :

    // Constructeur prenant en paramètre la taille du buffer
    IBufferBase(unsigned long Count);

    // Destructeur virtuel - nous allons utiliser cette classe polymorphiquement
    virtual ~IBufferBase();

    // Verrouille le buffer
    virtual void* Lock(unsigned long Offset, unsigned long Size, unsigned long Flags) = 0;

    // Déverouille le buffer
    virtual void Unlock() = 0;

    // Données membres
    unsigned long m_Count; // Nombre d'éléments du buffer
};

La taille des buffers étant fixée à leur création et irrécupérable par la suite (ce sont des contraintes liées aux API 3D), il convient donc de passer cette taille au constructeur de nos IBufferBase et de la stocker en donnée membre. La fonction Lock va servir à verrouiller nos buffers, nous pourrons spécifier en paramètre à partir d'où et quelle taille verrouiller. Nous pourrons également passer des flags pour "personnaliser" le type de verrouillage, en gros ce ne sera que le reflet des différents flags disponibles dans les API 3D (read only, write only, ...). Enfin, Unlock servira à déverrouiller nos buffers.
Vous aurez peut-être remarqué ce void* renvoyé par Lock, et vous vous demandez ce qu'il signifie. Notre fonction de verrouillage va en fait retourner un pointeur vers la zone mémoire verrouillée, mais comme le type des éléments stockés est a priori inconnu (int ou short pour les indices, structures persos pour les sommets), on ne peut rien renvoyer de plus précis qu'un void*. Cependant rappelez-vous, nous faisons ici du C++ le plus propre possible, et les manipulations de void* sont à bannir à tout prix. Pourquoi ? Tout simplement parce qu'on peut écrire ou lire n'importe quoi avec du void*, et plus particulièrement autre chose que ce qui est réellement pointé, ce qui mène immanquablement à un plantage. Nous verrons plus tard comment nous en débarasser.

Maintenant que nous avons une classe de base pour nos buffers, il faut la dériver pour chaque API. A ce stade nous pouvons faire une nouvelle (et très interessante) constatation : que ce soit avec DirectX ou OpenGL, ce seront exactement les mêmes fonctions qui nous serviront à créer / détruire / verrouiller / déverrouiller nos buffers, VB ou IB. Pour DirectX seul le type du buffer change (IDirect3DVertexBuffer9 pour les VB et IDirect3DIndexBuffer9 pour les IB), pour OpenGL ce sera la même chose au détail près que ce sera cette fois sous forme de constante (GL_ARRAY_BUFFER_ARB pour les VB et GL_ELEMENT_ARRAY_BUFFER_ARB pour les IB), le type du buffer étant lui toujours un simple identifiant (unsigned int). N'oubliez pas qu'OpenGL n'est absolument pas orienté objet contrairement à son acolyte DirectX.

Tout ceci nous ménèra donc pour DirectX à une classe template prenant en paramètre le type de buffer :

template <class T>
class CDX9Buffer : public IBufferBase
{
public :

    // Constructeur prenant en paramètre la taille et le pointeur sur le buffer
    CDX9Buffer(unsigned long Count, T* Buffer);

    // Destructeur
    ~CDX9Buffer();

    // Renvoie un pointeur sur le buffer
    T* GetBuffer() const;

private :

    // Verrouille le buffer
    virtual void* Lock(unsigned long Offset, unsigned long Size, unsigned long Flags);

    // Déverouille le buffer
    virtual void Unlock();

    // Données membres
    T* m_Buffer; // Pointeur sur le buffer Dx9
};

Et pour OpenGL, à une classe également template mais prenant cette fois une constante entière comme paramètre :

template <int Type>
class COGLBuffer : public IBufferBase
{
public :

    // Constructeur prenant en paramètre la taille et le pointeur sur le buffer
    COGLBuffer(unsigned long Count, unsigned int Buffer);

    // Destructeur
    ~COGLBuffer();

    // Renvoie un pointeur sur le buffer
    unsigned int GetBuffer() const;

private :

    // Verrouille le buffer
    virtual void* Lock(unsigned long Offset, unsigned long Size, unsigned long Flags);

    // Déverouille le buffer
    virtual void Unlock();

    // Données membres
    unsigned int m_Buffer; // Identifiant du buffer OGL
};

Vous remarquerez que les fonctions Lock et Unlock sont cette fois définies privées, en effet nous n'aurons besoin d'y accéder qu'au niveau du moteur, c'est-à-dire via la classe de base IBufferBase. L'API quant à elle accédera directement au buffer interne, à savoir aux IDirect3D***Buffer9 pour DirectX et aux buffers identifiés par des unsigned int du côté d'OpenGL.

Pour plus de simplicité dans la compréhension et l'écriture du code futur, nous pouvons maintenant définir explicitement le type des deux classes que nous allons manipuler (vertex buffer et index buffer) :

// DirectX
typedef CDX9Buffer<IDirect3DVertexBuffer9> CDX9VertexBuffer;
typedef CDX9Buffer<IDirect3DIndexBuffer9>  CDX9IndexBuffer;

// OpenGL
typedef COGLBuffer<GL_ARRAY_BUFFER_ARB>         COGLVertexBuffer;
typedef COGLBuffer<GL_ELEMENT_ARRAY_BUFFER_ARB> COGLIndexBuffer;

Une petite précision qui n'a peut-être pas encore été faite : à chaque fois que nous devrons spécialiser une classe pour DirectX et pour OpenGL, nous mettrons toujours ces spécialisations dans la DLL associée à l'API, aux côtés du renderer. Ainsi CDX9Buffer sera dans DirectX9Renderer.dll, et COGLBuffer sera elle dans OpenGLRenderer.dll, puisque seul le renderer devra y avoir accès. Le moteur lui se contentera de manipuler les classes abstraites qui servent de base à ces spécialisations. Cela sera de même pour les shaders, les textures, les declarations de vertex, etc...

Arrivé à ce stade, nous avons une classe de base abstraite et ses dérivées pour chaque API. Nous avons donc a priori tout ce qu'il faut pour manipuler les buffers dans notre moteur. Cependant nous n'avons aucune information sur le type des éléments stockés dans nos buffers, ce qui est plutôt gênant. C'est-à-dire qu'on pourra donner à manger tout et n'importe quoi à un même buffer, avec bien entendu aucun moyen de connaître le type "vraiment" stocké. Pour pallier à ce problème, nous allons donc encapsuler notre classe IBufferBase dans une autre classe plus sympathique : CBuffer.
Celle-ci nous permettra de contrôler le type des éléments stockés dans le buffer via un paramètre template, et puisqu'on y est on pourra également en profiter pour lui donner une sémantique de valeur (ie. pouvoir copier et assigner ses instances en tout sécurité, et sans dupliquer la représentation interne bien sûr), en encapulant le pointeur brut dans un pointeur intelligent à base de comptage de références. La technique utilisée ici peut s'apparenter à l'idiome enveloppe-lettre, (ou encore pimpl idiom pour nos amis anglais). Pour résumer, cela consiste à encapsuler (et cacher) un pointeur vers une ressource dans une classe. Pour plus de précisions, je vous invite à consulter le GOTW correspondant. On ne le répètera jamais assez : le C++ c'est bon, mangez-en ! Si vous n'êtes pas convaincu de l'interêt de cette classe et de toutes ces manipulation, voici un petit récapitulatif :

• Nous allons pouvoir nous débarrasser de tous ces affreux void*, ainsi lorsque nous essayerons de mettre des VertexX dans un buffer de VertexY, c'est une erreur de compilation qui nous le signalera et non un reboot de la machine.
• En encapsulant notre pointeur brut, nous pourrons ajouter quelques tests pour être sûrs de ne jamais manipuler de pointeur nul.
• Via le comptage de référence nous pourrons nous débarrasser de la gestion du buffer pointé, celui-ci sera automatiquement détruit lorsque plus personne n'en aura besoin.
• Cette classe possédant une sémantique de valeur, toute classe contenant un buffer sera elle-même potentiellement copiable (en gros, nous n'aurons pas besoin de créer le constructeur par défaut, par copie, le destructeur et l'opérateur d'affectation juste pour gérer notre buffer). Même combat que pour les pointeurs intelligents que nous avons détaillés dans la toute première partie.

Cette petite parenthèse C++ienne effectuée, revenons à nos CBuffer. Pour être certain que seul un CBuffer pourra manipuler un IBufferBase, nous allons tout mettre protected dans ce dernier, et lui coller la classe CBuffer comme copine. Nous laisserons juste son destructeur public, histoire que le pointeur intelligent encapsulant notre buffer puisse y accéder lorsqu'il voudra le détruire.
Voici donc le détail de cette classe, qui possède en gros la même interface que IBufferBase :

template <class T>
class CBuffer
{
public :

    // Constructeur prenant un pointeur sur le buffer encapsulé
    CBuffer(IBufferBase* Buffer = NULL);

    // Verrouille le buffer
    T* Lock(unsigned long Offset = 0, unsigned long Size = 0, unsigned long Flags = 0) const;

    // Déverrouille le buffer
    void Unlock() const;

    // Remplit le buffer
    void Fill(const T* Data, std::size_t Count) const;

    // Détruit le buffer
    void Release();

    // Renvoie un pointeur sur le buffer
    const IBufferBase* GetBuffer() const;

    // Renvoie le nombre d'éléments du buffer
    unsigned long GetCount() const;

private :

    // Données membres
    CSmartPtr<IBufferBase> m_Buffer; // Buffer interne
};

// ...Et on n'oublie pas le copinage pour que tout cela fonctionne
class YES_EXPORT IBufferBase
{
protected :

    // ...
    
    template <class T> friend class CBuffer;
};

Le code résultant sera maintenant plus sympathique pour nous : nous allons pouvoir créer des CBuffer<TIndice>, CBuffer<TVertex> et autres, et n'y stocker que le type spécifié (notez bien les T* qui remplacent les void* de IBufferBase). Toute tentative d'y mettre autre chose conduira à une erreur de compilation, ce qui est tout de même beaucoup plus gérable qu'un gros plantage des familles ! En plus, grace au comptage de référence, nous pourrons manipuler des objets et non des pointeurs bruts, ce qui nous offrira tous les avantages des pointeurs intelligents, vus dans l'article précédent. Enfin je radote un peu là.
Puisque cette classe est là pour nous simplifier la vie, nous en profitons également pour lui ajouter quelques fonctions utiles : Release pour "libérer" le buffer (mais si d'autres CBuffer pointent sur la même représentation interne, celle-ci ne sera pas détruite), Fill pour remplir entièrement le buffer en un seul coup sans s'embarrasser du verrouillage, et GetCount pour récupérer la taille du buffer.

Pour conclure et clarifier les choses, voilà un petit schéma UML résumant notre hiérarchie de classes pour les buffers, et la manière dont elles seront utilisées dans le moteur :

Tout ceci est bien chouette, nous avons des interfaces bien codées et sympathiques à manipuler, mais elles souffrent cependant d'un gros problème : pour l'instant elles ne font rien ! Descendons donc d'un cran, allons cotoyer le bas niveau et voyons comment nous allons implémenter ces différentes fonctions pour chaque API. Commençons par le commencement : la création des buffers. Dans tout le code précédent, les mêmes classes étaient utilisées pour manipuler à la fois les vertex buffers et les index buffers. Cependant au niveau de l'API cela ne se passe pas comme ça, c'est pourquoi il nous faudra cette fois deux fonctions bien distinctes : une pour créer les vertex buffers, une autre pour créer les index buffers.

Nous aurons donc dans notre renderer deux nouvelles fonctions : CreateVB et CreateIB, qui vont toutes deux renvoyer un pointeur sur un IBufferBase. Et comme la vie est plus gaie avec les templates, nous allons également ajouter deux fonctions : CreateVertexBuffer et CreateIndexBuffer. Ce seront ces fonctions qui seront appelées par le moteur, elles appeleront bien sûr les deux fonctions précédentes pour créer le buffer "brut", encapsuleront le IBufferBase* renvoyé dans un CBuffer<T>, rempliront celui-ci si nécessaire, et calculeront au passage les paramètres qui peuvent être déduits automatiquement. Dur à suivre ? Ne vous inquiétez pas, avec le code source qui suit et l'exemple d'utilisation qui clot cette partie, vous ne devriez pas avoir de souci à assimiler tout ça.

Voici donc CreateVertexBuffer, son acolyte CreateIndexBuffer est identique à la différence près que nous appelons CreateIB au lieu de CreateVB :

template <class T>
inline CBuffer<T> IRenderer::CreateVertexBuffer(unsigned long Size, unsigned long Flags, const T* Data) const
{
    CBuffer<T> Buffer(CreateVB(Size, sizeof(T), Flags));
    if (Data)
        Buffer.Fill(Data, Size);

    return Buffer;
}

La paramètre Data servira à remplir notre buffer directement lors de sa création. Si son contenu n'est pas connu à ce moment, il suffira de ne pas spécifier ce paramètre (il vaut NULL par défaut). Attention cependant : c'est le seul moyen pour le compilateur de déduire le paramètre template T automatiquement, il faudra donc écrire celui-ci explicitement si l'on n'utilise pas le paramètre Data. Cette subtilité est illustrée dans le code d'exemple donné dans le chapitre 5.

Notez que ce sont les deux premières fonctions non virtuelles (et non statiques) de IRenderer. Nous aurons comme ceci quelques autres fonctions non virtuelles "pratiques", qui ne serviront qu'à englober de manière plus sympathique d'autres fonctions (elles virtuelles) du renderer.

Descendons encore un peu et voyons cette fois l'implémentation de CreateVB, tout d'abord pour DirectX9. On ne détaillera pas ici CreateIB, à part un ou deux paramètres c'est exactement la même chose. Vous trouverez de toute façon le code complet dans le zip qui accompagne cet article.

IBufferBase* CDX9Renderer::CreateVB(unsigned long Size, unsigned long Stride, unsigned long Flags) const
{
    // Création du buffer
    LPDIRECT3DVERTEXBUFFER9 VertexBuffer;
    if (FAILED(m_Device->CreateVertexBuffer(Size * Stride, CDX9Enum::BufferFlags(Flags),
                                            0, D3DPOOL_DEFAULT, &VertexBuffer, NULL)))
        throw CDX9Exception("CreateVertexBuffer", "CreateVB");

    return new CDX9VertexBuffer(Size, VertexBuffer);
}

La fonction IDirect3DDevice9::CreateVertexBuffer prend en paramètre :

• La taille totale du buffer (= taille des éléments x nombre d'éléments).
• Un flag décrivant l'utilisation que nous ferons de notre buffer, que nous transformons en flag Dx9 à l'aide de notre fameuse classe magique CDX9Enum.
• Un entier décrivant la structure des vertices stockés, que nous laisserons toujours à 0 car nous utiliserons plutôt les declarations de vertex pour cela.
• Un flag indiquant où placer en mémoire notre buffer.
• Un pointeur pour récupérer le buffer créé.
• Et finalement un "handle" que la documentation nous dit de toujours laisser à NULL.

Nous construisons ensuite un CDX9VertexBuffer à partir du buffer créé par Dx9, puis nous le renvoyons.

Voyons maintenant pour OpenGL :

IBufferBase* COGLRenderer::CreateVB(unsigned long Size, unsigned long Stride, unsigned long Flags) const
{
    // Création du buffer
    unsigned int VertexBuffer = 0;
    glGenBuffersARB(1, &VertexBuffer);

    // Remplissage
    glBindBufferARB(GL_ARRAY_BUFFER_ARB, VertexBuffer);
    glBufferDataARB(GL_ARRAY_BUFFER_ARB, Size * Stride, NULL, COGLEnum::BufferFlags(Flags));

    return new COGLVertexBuffer(Size, VertexBuffer);
}

Ici non plus pas de difficulté majeure : nous demandons à OpenGL de générer un buffer, nous récupérons son identifiant, puis nous initialisons son contenu à l'aide de glBufferDataARB en lui donnant à manger la taille totale, un pointeur nul puisqu'aucune donnée n'est spécifiée, puis toujours ce fameux flag, qui dit à OpenGL comment créer notre buffer.

Le but de ces articles n'étant pas de reprendre de A à Z les explications de base relatives aux API 3D, si cela vous pose des difficultés vous pourrez trouver de l'excellente documentation par exemple chez NeHe pour OpenGL, ou dans la doc du SDK pour DirectX.

Toujours au niveau du renderer, la seconde étape est l'utilisation de ces buffers. Il nous faudra une fonction SetVB et sa copine SetIB, qui nous servirons à spécifier les buffers à utiliser lors du rendu. Là encore nous allons encapsuler tout ça dans deux fonctions templates : SetVertexBuffer et SetIndexBuffer. La raison est la même que pour les fonctions de création : il faudra prendre en paramètre un CBuffer<T>, extraire son IBufferBase* et la taille des éléments stockés, et donner tout ceci à manger à SetVB et SetIB, qui seront elles spécifiques à l'API.

La fonction SetVertexBuffer prend 4 paramètres : le buffer bien sûr, mais aussi le "stream" et la fourchette de vertices à prendre en compte. En effet, lorsqu'on envoie un buffer à l'API on n'aura pas toujours besoin de tous ses élements. L'intervalle passé en paramètre indique donc explicitement quels vertices seront utilisés par la suite pour le rendu des triangles, ce qui permet notamment quelques optimisations de la part de l'API. Quant au paramètre stream, nous verrons plus tard à quoi il sert, lorsque nous étudierons les déclarations de vertex. SetIndexBuffer ne prend elle rien de plus qu'un buffer en paramètre, rien de magique.
Voici donc à quoi ressemblent ces fonctions :

template <class T>
inline void IRenderer::SetVertexBuffer(unsigned int Stream, const CBuffer<T>& Buffer,
                                       unsigned long MinVertex, unsigned long MaxVertex)
{
    SetVB(Stream, Buffer.GetBuffer(), sizeof(T), MinVertex, MaxVertex ? MaxVertex : Buffer.GetCount() - 1);
}

template <class T>
inline void IRenderer::SetIndexBuffer(const CBuffer<T>& Buffer)
{
    SetIB(Buffer.GetBuffer(), sizeof(T));
}

Ces fonctions ne font qu'extraire le buffer interne et la taille des éléments de nos VB / IB, puis appellent les fonctions "bas niveau" appropriées. Chose très importante : une fonction membre template ne peut pas être virtuelle (car ce n'est pas vraiment une fonction, mais plutôt un modèle qui génèrera une fonction pour chaque type T utilisé), le passage par cette fonction intermédiaire est donc obligatoire pour traiter nos CBuffer<T>. Autre détail : les paramètres MinVertex et MaxVertex ont comme valeur par défaut 0, auquel cas c'est la totalité du buffer qui sera prise en compte, ce qui se révèlera plus pratique par la suite.

Puis nous avons comme d'hab les fonctions spécifiques à l'API, en commençant par DirectX9 :

void CDX9Renderer::SetVB(unsigned int Stream, const IBufferBase* Buffer, unsigned long Stride,
                         unsigned long MinVertex, unsigned long MaxVertex)
{
    // Récupération du buffer Dx
    const CDX9VertexBuffer* VertexBuffer = static_cast<const CDX9VertexBuffer*>(Buffer);

    // Envoi à l'API
    m_Device->SetStreamSource(Stream, VertexBuffer ? VertexBuffer->GetBuffer() : NULL, 0, Stride);

    // Sauvegarde des MinVertex et VertexCount
    m_MinVertex   = MinVertex;
    m_VertexCount = MaxVertex - MinVertex + 1;
}

void CDX9Renderer::SetIB(const IBufferBase* Buffer, unsigned long Stride)
{
    // Récupération du buffer Dx
    const CDX9IndexBuffer* IndexBuffer = static_cast<const CDX9IndexBuffer*>(Buffer);

    // Envoi à l'API
    m_Device->SetIndices(IndexBuffer ? IndexBuffer->GetBuffer() : NULL);
}

Arrêtons nous quelques instants pour expliquer un peu plus en détail ces deux fonctions. La première chose à faire dans chacune de ces fonctions est de transformer notre pointeur sur la classe de base (IBufferBase), en pointeur sur la classe dérivée associée à l'API (CDX9VertexBuffer). En temps normal, il faut utiliser dynamic_cast pour réaliser une telle conversion, mais ici nous sommes sûrs que notre buffer pointe bien sur un CDX9VertexBuffer, on peut donc utiliser un simple static_cast sans risque, et en évitant la perte de performance induite par dynamic_cast. Une fois converti en CDX9VertexBuffer, nous pouvons accéder à son buffer interne (de type IDirect3DVertexBuffer9 ...ouf, enfin !) et nous pouvons donc envoyer celui-ci à notre API. Bien sûr tout ce qui est dit ici pour SetVertexBuffer est valable pour SetIndexBuffer, le fonctionnement est le même. Cela sera également la même chose du côté d'OpenGL d'ailleurs. La fonction SetVertexBuffer stocke également l'intervalle de vertices, car celui-ci ne sera utilisé que lors de l'appel à DrawIndexedPrimitive, pour effectuer le rendu des primitives. Il faut donc les garder en mémoire jusqu'à cet appel. Mais alors pourquoi les passer en argument à SetVertexBuffer et non à DrawPrimitives ? Tout simplement car c'est comme cela que ça fonctionne du côté d'OpenGL, nous avons donc choisi l'option qui permettait de gérer les deux API au mieux. A noter également que du côté du SetIB de DirectX, le stride (taille des indices en octets) est inutilisé, en effet il est spécifié lors de la création de l'index buffer. Ce n'est pas le cas pour OpenGL, c'est pourquoi il nous faut tout de même ce paramètre.

L'implémentation OpenGL est quant à elle plus ou moins identique (cast de la classe de base, récupération du buffer interne, puis envoi à l'API), mais on ne donnera son détail que plus tard, car celle-ci est un peu spéciale. Il faudra notamment y mettre des choses spécifiques aux déclarations de vertex, ce que nous verrons immédiatement après ce chapitre.

Troisième et dernière étape : l'implémentation pour chaque API de nos classes de buffers, à savoir CDX9Buffer et COGLBuffer. Du côté de DirectX9, on utilise les fonctions Lock et Unlock pour le verrouillage / déverrouillage, et Release pour libérer le buffer. Au niveau d'OpenGL c'est kif kif : glMapBufferARB et glUnmapBufferARB pour verrouiller / déverrouiller, et glDeleteBuffersARB pour libérer le buffer. Le code complet n'est pas donné ici car il se limite à l'appel de ces fonctions, mais vous pourrez comme d'hab trouver celui-ci dans le zip accompagnant l'article.