Les extensions

Formation

En Semi-présenciel Paris

Prix sur demande

Appeler le centre

Avez-vous besoin d'un coach de formation?

Cela vous aidera à comparer et à choisir le meilleur cours pour vous

Description

  • Typologie

    Formation

  • Méthodologie

    En semi-présentiel

  • Lieu

    Paris

Grâce à cette formation vous pourrez acquérir les connaissances nécessaires qui vous permettrons d’ajouter des compétences à votre profil et obtenir de solides aptitude qui vous offriront de nombreuses opportunités professionnelles.

Les sites et dates disponibles

Lieu

Date de début

Paris ((75) Paris)
Voir plan
7 Cité Paradis, 75010

Date de début

Consulter

Questions / Réponses

Posez une question et d'autres utilisateurs vous répondront

Qui voulez-vous pour répondre à votre question?

Nous ne publierons que votre nom et votre question

Le programme

Introduction du cours

Bienvenue sur ce tutoriel.

Peut-être n'avez-vous jamais entendu parler des extensions d'OpenGL ? Et bien il est grand temps que vous fassiez leur découverte, car croyez-moi, elles sont indispensables si vous voulez aller plus loin avec OpenGL.

Il nous faudra tout d'abord voir qui sont ces extensions, ce nom peut-être barbare ne doit pas vous faire peur ;) Puis nous apprendrons à les utiliser avec un exemple de code tout simple.

En avant moussaillons ! :pirate:

C'est quoi les extensions ?

Entrons sans plus attendre dans le vif du sujet :)

Vous ne savez pas ce que c'est, pourtant vous lisez ce tutoriel et tenez à les découvrir. Eh bien soit.

Présentation du système d'extensions d'OpenGL

Comme chacun le sait, OpenGL est une API écrite en langage C proposant de multiples fonctionnalités pour effectuer un rendu 3D simplement.

Toutefois, certaines fonctionnalités ne sont pas accessibles directement via OpenGL, il va nous falloir passer par un tiers : les extensions.
Une extension est, comme son nom l'indique, une extension, un petit quelque chose en plus. Cependant, il ne s'agit pas d'une fonctionnalité gadget dont on pourrait se passer, mais bien d'une fonction native indispensable pour la réalisation de certaines choses. Ces choses, qui ne seront pas traitées ici, sont entre autres les VBOs, les shaders, le multi-texturing, les occlusion queries, et j'en passe.

Les extensions permettent donc de gérer certaines fonctionnalités comme celles citées ci-dessus. Vous allez, via les extensions, utiliser ce que vous ne pouviez pas utiliser directement avec votre implémentation d'OpenGL.

Pourquoi doit-on passer par les extensions ? Ça a l'air bien compliqué...

Ça, c'est la question qui tue ^^

Nous allons nous représenter cela historiquement. À l'origine, OpenGL était en version 1.1, les fonctionnalités supportées alors sont peu nombreuses, OpenGL se résume à la projection d'un triangle à l'écran, bref, rien de très tremblant. Aujourd'hui, OpenGL est en version 2.1, les fonctionnalités supportées sont beaucoup plus nombreuses, l'API a subit de multiples intégrations de fonctionnalités avancées (shaders entre autres, ...) ; chouette, tout le monde est content.

Cependant, certaines implémentations, notamment sous Windows, sont toujours en version 1.1. Par implémentation, je veux parler des fichiers de développement : .h, .lib ou .a. Effectivement, certains OS ne proposent pas encore d'implémentation plus récente que la 1.1, ainsi il est impossible de pouvoir utiliser les nouveautés des versions supérieures d'OpenGL.

Afin de bénéficier sur ces OS des améliorations apportées à OpenGL depuis sa version 1.1, nous allons devoir utiliser les extensions.

La standardisation d'OpenGL

Les améliorations apportées à OpenGL depuis sa version 1.1 sont nombreuses et proviennent de plusieurs sources. Ces sources sont principalement les constructeurs de carte graphique. En effet, lorsqu'ils intègrent de nouvelles fonctionnalités à leurs cartes, les constructeurs doivent également, dans le cas d'OpenGL, créer une extension qui permettera de les exploiter.

Ce sont donc des constructeurs de carte graphique dont proviennent principalement les extensions, mais étant donné qu'il existe plusieurs entreprises de construction de carte graphique, une extension proposée par l'une ne sera pas forcément compatible avec l'autre, il faut donc qu'OpenGL soit standardisé afin que nous, petits programmeurs, puissions faire du code source portable :)

La standardisation d'OpenGL était assurée jusqu'à maintenant (fin 2006/début 2007) par l'ARB, qui était en fait constituée entre autres des "principaux représentants" des constructeurs de carte graphique. Aujourd'hui, la standardisation a été reléguée à The Khronos Group (Khronos Group).

Support or not support ?

Les extensions ne doivent pas être vue comme une méthode destinée à embêter le développeur inutilement, mais plutôt comme une astuce afin de permettre à chacun d'exploiter au maximum les fonctionnalités supportées par sa carte graphique sans attendre la mise à jour des fichiers de développement (qui se fait attendre chez certains OS).

Toutefois, votre carte graphique ne supporte peut-être pas toutes les extensions que vous lui demanderez de manger. Il est possible de voir lesquelles elle supporte et lesquelles elle ne supporte pas, il nous faudra d'ailleurs impérativement passer par cette étape de vérification afin d'être sûrs de ne pas faire planter notre programme, car l'utilisation d'une extension non supportée conduit à un comportement indéfini (on trouvera le plus souvent des erreurs de segmentation).

L'étape de la gestion du support est donc primordiale.

Et en pratique, comment on gère ça ?

Nous avons deux possibilités :

  • Demander l'extension via la SDL :
    Comme vous l'avez vu avec Kayl, la SDL offre un contexte OpenGL. Et grâce à cela elle permet aussi de manipuler les extensions d'OpenGL. Nous verrons que cette méthode est manuelle car elle demande un minimum de code.

  • Ne rien faire via GLEW :
    Vous avez bien lu, vous n'aurez rien à faire. En tout cas beaucoup moins qu'avec la SDL, la bibliothèque GLEW nous mâchera en fait tout le travail que nous faisions avant avec la SDL :soleil: . Lorsqu'on l'utilise pour manier les extensions d'OpenGL, on peut dire qu'on emploi une méthode de feignasses automatique car le code que nous devions écrire auparavant avec la SDL disparaîtra.

Hé mais alors pourquoi nous embêter à utiliser la SDL ?!

Il est bon que vous connaissiez toutes les méthodes, parfois on préférera l'une ou l'autre selon nos besoins.

Comment ça fonctionne ?Un peu de théorie

Bon, passons aux choses sérieuses : nous voulons bénéficier d'une extension d'OpenGL parce qu'on la trouve super cool.

Oui, mais ça ressemble à quoi une extension ? C'est une boîte carrée qui contient plein de joujoux ? Presque :p

Une extension regroupe généralement des fonctions ainsi que des constantes symboliques qui nous permetteront d'exploiter la fonctionnalité que l'extension représente. Supposons que la gestion des couleurs des sommets soit une extension, alors l'extension serait composée des fonctions glColor*(), ces fonctions ne seraient pas disponibles dans gl.h et leur adresse mémoire serait inconnue.
Pour finir, une extension a un nom. C'est très important de retenir cela, c'est grâce à ces noms que nous allons voir si une extension est supportée ou non par la carte graphique.

Vous devez retenir que : une extension est caractérisée par un nom qui englobe quelques fonctions et quelques constantes (parfois, seulement l'un ou l'autre).

Avant d'utiliser une extension, il est nécessaire de la charger, c'est-à-dire de récupérer les adresses mémoire des fonctions qui composent l'extension, connaître les prototypes de ces fonctions et aussi connaître les valeurs des constantes qu'elle utilise.

Quoi ? Charger une fonction ?

Je vous conseille fortement la lecture de l'excellent tutoriel de mleg sur les pointeurs de fonctions afin de vous éclaircir sur ce point.
En effet, la lecture de ce tutoriel est préférable si vous voulez comprendre ce que vous ferez.

Et qu'est-ce qu'on fera ?

Vous chargerez des fonctions dynamiquement :)
En effet, charger une extension revient à rechercher les adresses mémoire des fonctions qui la composent, ces adresses existent réellement si votre carte graphique supporte l'extension demandée et que votre pilote graphique est à jour.
Normalement les adresses de fonctions sont fournies par votre implémentation d'OpenGL, mais si elle est trop ancienne, il vous faudra aller chercher ces adresses vous-même.

Ne vous inquiétez pas, ce n'est pas aussi dur que ça pourrait en avoir l'air ;)

Charger une extension

Avant de voir le chargement en lui-même (qui se résume d'ailleurs à une ligne de code :-° ) vous devez tout d'abord posséder l'en-tête glext.h nécessaire au bon fonctionnement des extensions. Vous pourrez trouver la dernière version de ce fichier sur le site de Silicon Graphics à cette adresse.
Vous devrez placer ce fichier dans le répertoire include/GL/ de votre compilateur.

Notez qu'il est fort probable que vous ayez impérativement besoin de télécharger la dernière version du fichier glext.h même si vous le possédez déjà. Par précaution, je vous conseille de le mettre à jour dès maintenant.

Ce fichier contient toutes les constantes ainsi que tous les types des fonctions disponibles pour OpenGL 2.1.

Les types des fonctions ?

Oui. Afin de charger une fonction, il va falloir stocker son adresse dans un pointeur de fonction d'un certain type. Ces types sont définis dans glext.h via des typedef.

Fonctionnement

Nous y voilà : comment charger une fonction ?

Nous allons en fait nous y prendre de la même façon que dans le tutoriel de mleg sur les pointeurs de fonctions :

  • créer une variable de stockage de notre fonction du type approprié ;

  • lui attribuer l'adresse de la fonction qu'elle devra représenter. Nous verrons comment procéder à cela dans la partie suivante ;

  • utiliser notre pointeur à notre guise dans notre programme OpenGL. Nous devrons prendre garde à rendre ce pointeur accessible par tous les fichiers de notre projet, ça sera donc une variable globale. Nous verrons cela plus bas lors de l'exemple de code.

Le type de notre pointeur, comme je l'ai dit plus haut, est défini dans glext.h. Le problème me direz-vous, c'est que chaque fonction a un prototype différent, donc il y a... un type pour chaque fonction o_O Diantre ! ça fait beaucoup ! :D Rassurez-vous, les noms donnés à ces types sont logiques et clairs, je vais justement vous les présenter.

Présentation de la syntaxe des types de fonctions

Les noms des types des fonctions que l'on peut charger ont une logique similaire à celle des noms de fonctions OpenGL simples.
Voici plusieurs règles :

  • chaque nom est écrit 100% en majuscules ;

  • chaque nom est préfixé par PFN ;

  • chaque nom est suffixé par PROC ;

  • le nom du type est strictement égal au nom de la fonction auquel il correspond.

En fait si vous savez tout cela par coeur, alors il n'y a rien à savoir de plus. Nous verrons un exemple plus bas.

Présentation de la syntaxe des noms des extensions

Il y en a également une pour les noms des extensions.
Voici par exemple un nom d'extension :

GL_ARB_multitexture

Premièrement, on remarque le préfixe GL_ bien connu des utilisateurs d'OpenGL, ensuite vient un autre préfixe (qui du coup n'en est plus vraiment un :-° ) : ARB. Ce second préfixe est intéressant, il représente en quelque sorte par qui l'extension est certifiée. Il existe également NV (pour nVidia), ATI (pour ATI), EXT (EXTension), SGIS (Silicon Graphics Inc., sans être totalement sûr), et quelques autres. À priori, mais ce n'est pas toujours le cas, une extension NV n'est pas supportée par ATI et vice-versa.
Pour finir, multitexture décrit la fonctionnalité de l'extension, ici il s'agit donc de l'extension permettant de réaliser du multi-texturing.

Présentation de la syntaxe des fonctions

Oui, les fonctions aussi ont une syntaxe ;) Cependant rassurez-vous, vous la connaissez normalement déjà, Kayl a traité ce point dans son tutoriel.

Alors pourquoi tu te la ramène avec un gros titre ? :-°

Pour vous prévenir que les fonctions d'extensions sont suffixées par le second préfixe du nom de l'extension auquel elles appartiennent.

Hein ?!

Les fonctions appartenant à GL_ARB_multitexture par exemple contiendrons toutes ARB à la fin de leur nom, comme ceci :

glMultiTexCoord2fARB(...); Utilisation de la SDL : méthode manuelle

Bien, nous allons commencer à coder sans plus attendre.
J'espère que vous avez bien retenu tout ce que je vous ai dit dans la précédente partie. :p Faites chauffer vos cervelles !

Souvenez-vous de la première partie, je vous avais dit qu'il existait plusieurs méthodes pour charger une/plusieurs extension(s). Nous allons étudier ici la méthode manuelle, celle qui utilise la SDL. Nous chargerons une simple extension qui servira d'exemple, mais sachez que le chargement d'une extension, ou plus précisément des fonctions qui la composent, fonctionne de la même façon pour toutes les extensions.

Quelle extension allons-nous charger ?

GL_ARB_vertex_buffer_object par exemple :)

C'est quoi cette extension ??

Hélas, cela sort du cadre de ce tutoriel, je peux juste vous dire que c'est une extension qui peut s'utiliser dans un petit code source, d'où mon choix pour celle-ci.

1 - Vérifier le support de l'extension

Il est possible, via l'appel d'une fonction OpenGL, de connaître toutes les extensions supportées par votre matériel. Souvenez-vous également qu'une extension est représentée par son nom, en demandant à OpenGL de nous fournir la liste des extensions supportées, il va en fait nous renvoyer une énorme chaîne de caractères qui contiendra tous les noms des extensions supportées séparés par des espaces.
Afin d'obtenir cette liste, il nous faut invoquer glGetString() avec comme paramètre GL_EXTENSIONS :

const unsigned char *exts = glGetString(GL_EXTENSIONS);

Notez bien que la fonction renvoie un const unsigned char* (const GLubyte* pour les intimes)

Nous voici à présent armés d'une énorme chaîne de caractères. Vous pouvez essayer de l'afficher si vous avez envie, voyez ce que j'obtiens personnellement :

Appeler le centre

Avez-vous besoin d'un coach de formation?

Cela vous aidera à comparer et à choisir le meilleur cours pour vous

Les extensions

Prix sur demande