OpenGL contient déjà quelques concepts «Object».
Par exemple, tout ce qui a un identifiant peut être considéré comme un objet (il y a aussi des choses spécifiquement nommées «Objets»). Buffers, Textures, Vertex Buffer Objects, Vertex Array Objects, Frame Buffer Objects et ainsi de suite. Avec un peu de travail, vous pouvez envelopper les cours autour d'eux. Il vous donne également un moyen facile de revenir aux anciennes fonctions OpenGL obsolètes si votre contexte ne prend pas en charge les extensions. Par exemple, un VertexBufferObject pourrait retomber sur l'utilisation de glBegin (), glVertex3f (), etc.
Il y a quelques façons dont vous pourriez avoir besoin de vous éloigner des concepts OpenGL traditionnels, par exemple vous voulez probablement stocker des métadonnées sur les tampons dans les objets tampons. Par exemple, si le tampon stocke des sommets. Quel est le format des sommets (c'est-à-dire la position, les normales, les texcoords, etc.). Quelles primitives il utilise (GL_TRIANGLES, GL_TRIANGLESTRIP, etc ...), les informations de taille (combien de flottants sont stockés, combien de triangles ils représentent, etc ...). Juste pour le rendre facile à brancher dans les commandes draw arrays.
Je vous recommande de regarder OGLplus . Il s'agit de liaisons C ++ pour OpenGL.
Aussi glxx , c'est seulement pour le chargement d'extension.
En plus d'encapsuler l'API OpenGL, vous devriez envisager de créer un niveau légèrement supérieur au-dessus.
Par exemple, une classe de gestionnaire de matériel qui est responsable de tous vos shaders, de les charger et de les utiliser. Il serait également responsable de leur transférer des propriétés. De cette façon, vous pouvez simplement appeler: materials.usePhong (); material.setTexture (someexture); material.setColor (). Cela permet une plus grande flexibilité car vous pouvez utiliser des choses plus récentes comme des objets de tampon uniforme partagés pour n'avoir qu'un seul grand tampon contenant toutes les propriétés que vos shaders utilisent dans 1 bloc, mais si cela ne vous prend pas en charge, vous pouvez revenir au téléchargement vers chaque programme de shader. Vous pouvez avoir 1 grand shader monolithique et permuter entre différents modèles de shader en utilisant des routines uniformes si cela est pris en charge ou vous pouvez revenir à l'utilisation d'un tas de différents petits shaders.
Vous pouvez également consulter les dépenses à partir des spécifications GLSL pour écrire votre code de shader. Par exemple, le #include serait incroyablement utile et très facile à implémenter dans votre code de chargement de shader (il y a aussi une extension ARB pour cela). Vous pouvez également générer votre code à la volée en fonction des extensions prises en charge, par exemple utiliser un objet uniforme partagé ou recourir à des uniformes normaux.
Enfin, vous voudrez une API de pipeline de rendu de niveau supérieur qui fait des choses comme les graphiques de scène, les effets spéciaux (flou, lueur), les choses qui nécessitent plusieurs passes de rendu comme les ombres, l'éclairage et autres. Et en plus de cela, une API de jeu qui n'a rien à voir avec l'API graphique mais qui traite uniquement des objets d'un monde.