La technologie OpenGL: un standard de fait

par Francis Lapique, SIC-Informatique individuelle

table des matières

  1. OpenGL Architecture Review Board
  2. La machine OpenGL
  3. OpenGL et IRIS GL
  4. OpenGL sous un aspect fonctionnel
  5. Deux modèles de couleur
  6. Plans auxiliaires
  7. Les différentes étapes de transformations des vertex
  8. OpenGL sous un aspect fonctionnel avancé
  9. Modes sélection et feedback
  10. Liste d'affichage
  11. La bibliothèque d'utilitaires GLU
  12. Ensemble d'utilitaires aux
  13. OpenGL et l'environnement X
  14. Un exemple concret [4 & 5]
  15. Comparaison OpenGL/PEX [6]
  16. références

Un constructeur de stations de travail doit constamment remettre en question son approche matérielle et logicielle pour répondre le mieux possible à la demande du marché. Ce marché réclame avec insistance un environnement logiciel qui ne soit pas marqué par telle ou telle empreinte constructeur. L'environnement logiciel OpenGL présenté dans cet article va dans cette direction.

OpenGL Architecture Review Board

OpenGL est une interface logicielle qui se propose de standardiser, dans le monde des applications graphiques, les différentes approches matérielles. Cette interface qui compte environ 120 commandes couvre la création, l'animation et le rendu d'objets 3D avec comme caractéristique principale d'être complètement indépendante du système de fenêtrage. Cette indépendance signifie que le noyau de cette interface ne contient aucune commande pour gérer des actions du genre OpenDisplay, SelectInput, NexEvent. L'ensemble de l'interface s'inscrit dans la philosophie client-serveur où une application dite cliente envoie des requêtes/commandes vers un serveur d'affichage local ou distant. L'indépendance de ces requêtes vis-à-vis du matériel permet d'intégrer clients et serveurs de marques différentes.

figure 1

Cette technologie développée par Silicon Graphics avec comme base d'expérience leur interface propriétaire IRIS GL est, aujourd'hui, sous le contrôle d'un consortium: OpenGL Architectural Review Board (ARB). Par contrôle on entend que toute évolution, modification d'OpenGL doit être approuvée par les membres du consortium. Quelques noms pris au hasard dans le dernier compte rendu de la réunion qui s'est tenue en février 94: Microsoft avec l'annonce du support d'OpenGL dans sa prochaine version Windows NT 3.5 (Daytona), IBM, Cray Research, DEC qui le diffuse déjà à travers le produit Open3D 2.0, Kubota Pacific, Evans & Sutherland, SGI qui le diffuse dans la révision 5.2 de son OS pour les machines Indy, Indigo et Indigo2, Intergraph, Portable Graphics qui avec 3Dlabs est spécialisé dans le transfert de cette technologie vers les mondes SUN et HP.

retour à la table des matières

La machine OpenGL

La figure 1 est un bloc diagramme d'opérations qui illustre le fonctionnement de la machine OpenGL. Les commandes sont traitées de gauche à droite. Certaines de ces commandes ont trait au dessin d'un objet et vont traverser le pipe-line jusqu'à la mémoire d'images ou frame buffer, sorte de grille de dimension 2, d'autres ont trait à l'aspect et vont changer telle ou telle variable d'état (couleur, matrice de transformation, texture etc.).

figure 2

En entrée, les commandes sont soit envoyées directement dans le pipe-line ou stockées dans une liste d'affichage ou display list pour un traitement différé. Les données géométriques peuvent se présenter sous la forme d'un ensemble de sommets ou vertex de type point, ligne, polygone ou de courbes et surfaces se présentant sous une forme paramétrique:

C(u) = [X(u)Y(u)Z(u)]
S(u,v) = [X(u,v)Y(u,v)Z(u,v)]

de types NURBS (Non-Uniform Rational B-Spline,) ou Bézier [1]. Un vertex, ce n'est pas uniquement une simple référence à une coordonnée homogène [2] de dimension 4 (x, y, z, w), c'est un objet plus complexe qui comprend des attributs d'orientation angulaire (vecteur normal), de couleur, de texture et d'arêtes. Les opérations géométriques qui vont suivre devront donc traiter ces vertex en tenant compte de tous ces aspects. Ces opérations consistent essentiellement à appliquer un certain nombre de transformations (découpage, clôture) pour respecter le point de vue demandé. Les étapes finales alimentent le frame buffer en analysant la contribution de chacun de ces vertex sur la base des critères de couleur, de visibilité et autres effets spéciaux (brouillard, transparence...).

figure 3

Si les données ne se présentent pas sous une forme vertex mais sous celle de pixels, c'est pour alimenter soit une matrice de texture soit le processus de rasterisation. OpenGL proprement dit n'offre aucun moyen de dialogue avec un système de fenêtrage. Ce dialogue sera pris en compte par une couche relais qui, pour le système X, se nomme GLX [3]. Techniquement elle se présente comme une extension de X qui va transmettre les commandes de rendu d'OpenGL, avec toutefois un détail important. Si, application et matériel graphique sont distants, on va, comme on le fait pour d'autres extensions X, exprimer les requêtes dans un flot X11. Dans le cas contraire on va, pour des raisons évidentes de performances, court-circuiter le serveur X via un Direct GL renderer (figure 2). Les systèmes graphiques sont souvent classés en deux groupes: procédural ou descriptif. Procédural signifie que c'est la construction et le rendu d'objets qui ont été ciblés. Dans le groupe descriptif on va plutôt trouver des produits qui ont comme objectif premier celui de faciliter la mise en scène d'objets au moyen d'interface de programmation de haut niveau. OpenGL est procédural et va de plus en plus être à la base de systèmes descriptifs. A titre d'exemple The Inventor, boîte à outils 3D orientée objet, fait partie de cette famille de produits descriptifs.

retour à la table des matières

OpenGL et IRIS GL

La dépendance de GL vis-à-vis du système de fenêtrage, plus le retrait et l'ajout de fonctionnalités font qu'une application GL devra être adaptée au dialecte OpenGL. Pour éviter les conflits de nom, le monde OpenGL est identifié par les premiers caractères gl pour les commandes (glClearColor()) et GL_ pour les constantes (GL_COLOR_BUFFER_BIT). L'accès à la culture OpenGL est facilité par un certain nombre de points d'entrée. La figure 3 en présente huit.

figure 4

retour à la table des matières

OpenGL sous un aspect fonctionnel

OpenGL est un ensemble de primitives simples. Les architectes d'OpenGL ont poussé cette simplicité jusque dans l'appellation des commandes en évitant des noms du genre RenderPolygonWithGratuitousArguments. La sophistication va venir de la combinaison de ces primitives et de leur utilisation dans des modes différents. C'est une démarche qui rappelle celle qui a conduit aux processeurs RISC. La figure 4 présente l'ensemble des primitives graphiques. Nous allons décrire leur mode d'emploi. Ce que l'on va manipuler c'est une liste de points de l'espace ou vertex dans un contexte donné. La commande glBegin marque le début de cette liste et précise le contexte de la primitive, glEnd sa fin. Les vertex proprement dits sont introduits par la commande glVertex*(). Le suffixe * précise la dimension et le type des données. Par exemple, la commande glVertex3f indique qu'il s'agit d'un vertex de dimension 3 et qu'il est de type flottant. L'aspect du vertex (couleur, matériel, normal, arête, texture) peut être modifié à tout moment entre glBegin et glEnd. La figure 5 illustre la génération d'un polygone.
glShadeModel(GL_SMOOTH);
glBegin(GL_POLYGON);
glColor3f(0.0,1.0,0.0);/* vert */
glVertex3f(0.0,1.0,0.0);
glVertex3f(0.7,1.0,0.0);
glColor3f(0.0,0.0,1.0);/* bleu */
glVertex3f(1.4,0.6,0.0);
glVertex3f(1.4,0.4,0.0);
glVertex3f(0.0,0.0,0.0);
glEnd();
figure 5

Les commandes OpenGL s'adaptent aux types de données que le programmeur veut manipuler. Ainsi les commandes glVertex3i, glVertex3f, glVertex3d ont respectivement comme cible des données de type entier, flottant et double. Cette approche a deux avantages: être flexible et éviter des conversions de type qui peuvent devenir coûteuses. Le code de la figure 5 doit être vu comme une suite de demandes de changement d'état de la machine OpenGL. La commande glBegin s'interprète comme passer dans l'état affichage de la primitive. On dispose également d'un ensemble de commandes qui permet d'interroger la machine OpenGL. La commande glGetFloatv(GL_CURRENT_COLOR,&float_array) permet par exemple de retrouver la couleur.

retour à la table des matières

Deux modèles de couleur

Les deux modèles de couleur: RGBA et couleur indexée sont possibles. Les appels à glColor3f de la figure 5 s'inscrivent dans le modèle RGBA. Cette commande s'attend à trois valeurs flottantes comprises entre 0.0 et 1.0. Ces trois valeurs précisent les quantités de rouge, vert et bleu désirés. En prenant une terminologie X, RGBA correspond grossièrement au type TrueColor, l'autre modèle s'apparente au type PseudoColor. Le choix du modèle est irréversible. La lettre A désigne le paramètre alpha. C'est un paramètre d'opacité que l'on va affecter à chaque pixel. Il peut prendre des valeurs comprises entre 0.0 et 1.0. La valeur 1.0 désigne une couleur totalement opaque et 0.0 totalement transparente. C'est au moyen de la commande glColor4f, extension de glColor3f que l'on va préciser le paramètre alpha. Cette valeur peut être stockée dans un plan dit d'alpha-blending. Elle n'est jamais affichée directement. Les commandes glAlphaFunc et glBlendFunc contrôlent précisément l'effet que l'on veut donner. Ce mode RGBA autorise des effets de brouillard ou d'éclairage.

Si le matériel graphique compte un nombre de plans couleur réduit, on peut demander à OpenGL de travailler dans un mode dit de tramage. On active ou non ce mode de fonctionnement en utilisant respectivement les commandes glEnable(GL_DITHER) ou glDisable. Dans le mode indexé, on ajoute une indirection entre la valeur affectée au pixel et la couleur du pixel à l'écran. OpenGL n'a pas de commande spécifique pour s'allouer une table de couleurs. On le fera en faisant appel à la primitive XAllocColor, si on travaille dans un environnement X.

retour à la table des matières

Plans auxiliaires

Le frame buffer n'est pas le seul plan mémoire administré par OpenGL. Il y en a un certain nombre d'autres, dits plans mémoire auxiliaires que l'on va rapidement passer en revue. Le z-buffer est essentiel si vous cherchez un traitement simple donc efficace pour éliminer des objets ou des parties d'objet qui, pour le point de vue considéré sont invisibles. Au moment de la discrétisation (rasterisation) de l'image on va affecter à chaque pixel un nouvel attribut de profondeur Z. Sur la base de cette valeur, le pixel va être déclaré plus près ou plus loin de l'oeil. S'il est déclaré plus près, il fait partie de la mémoire d'image et la valeur  Z correspondante est stockée dans une zone auxiliaire dite z-buffer. Au départ, toutes les valeurs du z-buffer sont déclarées plus loin. Le plan pochoir (stencil) permet, comme son nom l'indique, d'afficher une certaine portion de l'écran. Par exemple, si vous développez un simulateur de conduite, vous ne voulez pas que la vue de votre tableau de bord soit affectée par celle qui va défiler dans votre pare-brise. En chargeant, dans le plan stencil, la forme du pare-brise, vous allez obtenir l'effet demandé. Tout comme le z-buffer il y a un tas d'autres exemples d'utilisation. Une autre zone dite accumulation buffer permet de superposer un ensemble d'images en mode RGBA pour réaliser des effets spéciaux tel que le flou bougé (figure 6), plusieurs sources de lumière, et l'anti-aliasage. La méthode d'antialiasage consiste à représenter une forme sous un aspect le plus lisse possible en minimisant l'effet marches d'escalier dû à la discrétisation de l'écran.

figure 6

L'animation d'une scène passe la plupart du temps par une technique dite de double mémorisation ou double-buffering. L'idée consiste à travailler en parallèle sur deux plans d'images: un avant plan visible et un arrière plan invisible. Pendant que l'on affiche l'image de l'avant plan, on calcule le rendu dans l'arrière plan. La commande glDrawBuffer permet de sélectionner le plan mémoire avec lequel vous voulez travailler. Si vous remplacez les plans avant-arrière par gauche-droit, vous pouvez travailler en mode stéréo. Ce mode demandant un matériel assez spécifique, OpenGL ne sait pas, a priori, travailler en mode stéréo.

retour à la table des matières

Les différentes étapes de transformations des vertex

figure 7

Le passage du système de coordonnées objet ­celui des primitives­ à celui de l'écran va se faire à travers un certain nombre de transformations. Les différentes étapes de ces transformations sont illustrées à la figure 7. Au cours de la première étape, on va positionner le modèle dans le champ de vision de l'observateur. La deuxième étape est une étape dite de découpage où un certain nombre de plans de coupe va être appliqué. La troisième étape est une étape de transformation de normalisation des coordonnées (division des coordonnées par w). La quatrième marque le passage dans le système de référence de l'écran. Le programmeur OpenGL a la responsabilité des deux premières matrices de transformation. Ce sont des matrices 4x4. On peut décider de travailler avec l'une ou l'autre matrice en passant la commande glMatrixMode avec les arguments GL_MODELVIEW ou GL_PROJECTION. Cette commande définit la matrice courante. Cette matrice courante peut être initialisée en matrice identité en passant la commande glLoadIdentity. On peut lui appliquer d'autres transformations comme glRotatef, glTranslatef et glScalef si on désire effectuer respectivement des rotations, translations et déformations. On peut également la modifier soit par chargement d'une matrice spécifique, c'est l'objectif de la commande glLoadMatrixf, soit par multiplication au moyen de glMultMatrix.

Par défaut l'étape finale va utiliser tout l'écran. La commande glViewport vous permet d'intervenir en précisant la région rectangulaire concernée.

retour à la table des matières

OpenGL sous un aspect fonctionnel avancé

OpenGL est un outil de travail qui va au-delà de la simple représentation et animation de primitives 3D. Vous disposez d'un certain nombre de fonctions avancées pour suggérer le monde réel. La simulation de ce monde réel passe par un ensemble de techniques comme celles qui consistent à exposer un objet à une ou plusieurs sources lumineuses ou à lui appliquer de la texture. La texture c'est une image 1D ou 2D que vous plaquez sur les primitives pour leur donner par exemple un aspect matière (figures 8a & b). C'est une technique indispensable si vous travaillez dans le monde des simulateurs (avion, corps humain). L'animation d'une scène comptant texture, éclairage , antialiasage, effets atmosphériques (déplacement dans une zone de brouillard) sont aujourd'hui pris en charge par du matériel. L'animation et l'enregistrement en temps réel d'une telle scène sont techniquement abordables.

figure 8-a

figure 8-b

retour à la table des matières

Modes sélection et feedback

Une application graphique est une succession de phases passives marquées par le rendu de scènes et de phases actives caractérisées par des interactions avec ces scènes. OpenGL offre deux manières d'être actif: le mode dit selection et celui dit feedback. En mode selection vous identifiez, pour une région de l'écran donné, les objets affichés. En mode feedback vous capturez les instructions de dessin. Une utilisation classique de ce dernier mode est, par exemple, la redirection de l'affichage vers un traceur.

retour à la table des matières

Liste d'affichage

Vous pouvez regrouper un ensemble de primitives dans une liste d'affichage ou display list. La commande glNewList marque le début de la liste et glEndList sa fin:

glNewList(1,GL_COMPILE);
glVertex3f(v1);
glEndList();
glNewList(2,GL_COMPILE);
glVertex3f(v2);
glEndList();
glNewList(3,GL_COMPILE);
glVertex3f(v3);
glEndList();

Le premier paramètre de la commande glNewList() identifie la liste, le deuxième, le mode d'utilisation. Si votre application est distribuée sur le réseau, la liste d'affichage est un bon moyen pour réduire le trafic client-serveur, car elle réside sur le serveur. Comme corollaire toute commande renvoyant une valeur ne pourra être incluse dans une liste. La commande glCallList demande l'exécution d'une liste. On peut inclure dans une liste l'exécution d'autres listes. On parle alors de liste d'affichage hiérarchique:

glNewList(4,GL_COMPILE);
glBegin(GL_POLYGON);
glCallList(1);
glCallList(2);
glCallList(3);
glEnd();
glEndList;

retour à la table des matières

La bibliothèque d'utilitaires GLU

Le coeur d'OpenGL est constitué d'un ensemble de commandes qui ont comme trait commun celui d'être liées au rendu. OpenGL a pensé à standardiser un ensemble d'outils qui ne sont pas directement liés au rendu. Cette boîte à outils se nomme GLU pour OpenGL Utility Library. Ces utilitaires, identifiés par le préfixe glu, couvrent les domaines suivants:

a) technique dite de mipmapping (Mip vient du latin multim im parvo): prenez un objet sur lequel vous avez appliqué de la texture. Si vous l'éloignez ou le rapprochez de l'oeil, la texture devra suivre les changements d'échelle. Ces changements sont pris en compte par OpenGL qui va appliquer la bonne taille de texture. L'utilitaire gluScaleImage vous permet, en partant d'une texture originale, de préparer un ensemble de sous-images qui seront appliquées à bon escient;

b) transformation de coordonnées: l'utilitaire gluPerspective calcule la matrice de transformation et l'applique à la matrice courante (figure 9):

figure 9

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(fovy,aspect,zNear,zFar);
c) manipulation de polygones non-convexes ou de polygones présentant des trous: pour vous ramener à un ensemble de polygones simples, GLU propose un certain nombre d'utilitaires comme gluNewTess() pour réaliser ce traitement.

d) ensemble d'utilitaires pour afficher des surfaces simples: sphères, cylindres et disques.

e) approximation de courbes et surfaces complexes par NURBS (Non-Uniform Relational B-Spline): GLU vous offre une panoplie d'utilitaires pour créer et manipuler des courbes et surfaces sous leurs formes NURBS. Cette ouverture sur les NURBS, fait qu'OpenGL est un bon candidat pour s'interfacer avec des systèmes CAD ou solveurs.

f) gluErrorString un utilitaire qui décrit sous forme texte la nature du problème.

retour à la table des matières

Ensemble d'utilitaires aux

Dans le guide de référence OpengGL Programming Guide les codes exemples font appel à un ensemble d'utilitaires qui sont identifiés par le préfixe aux. Cet ensemble a comme seul but celui de vous simplifier la vie dans les deux cas suivants:

La figure 10 illustre l'utilisation de cet ensemble dans un programme qui dessine un simple carré (figure 11).

#include 
#include 
#include ³aux.h²

int main(int argc, char** argv)
{
 auxInitDisplayMode (AUX_SINGLE | AUX_RGB);
 auxInitPosition (0, 0, 500, 500);
 auxInitWindow (argv[0]);

 glClearColor (0.0, 0.0, 0.0, 0.0);
 glClear(GL_COLOR_BUFFER_BIT);
 glColor3f(1.0, 1.0, 1.0);
 glMatrixMode (GL_PROJECTION);
 glLoadIdentity ();
 glOrtho(-1.0,1.0,-1.0,1.0,-1.0,1.0);
 glBegin(GL_POLYGON);
 glVertex2f(-0.5, -0.5);
 glVertex2f(-0.5, 0.5);
 glVertex2f(0.5, 0.5);
 glVertex2f(0.5, -0.5);
 glEnd();
 glFlush();
 sleep (10);
}

figure 10

figure 11

retour à la table des matières

OpenGL et l'environnement X

GLX est l'extension OpenGL officielle pour le système X. C'est une couche qui a un pied dans le monde OpenGL et l'autre dans le monde X. Elle spécifie un ensemble de fonctions identifiées par le préfixe glX et une extension du protocole X.

GLX permet de faire du rendu d'images dans des windows et pixmaps au sens X du terme.

Dans l'univers X, il existe différentes stratégies (pseudocolor, direct color) pour convertir la valeur d'un pixel en couleur à l'écran. Elles sont regroupées dans ce que l'on appelle des visual classes. Cette notion de visual a dû être étendue car OpenGL compte un certain nombre d'exigences. Ces exigences font que toute implémentation de GLX devra comprendre au moins un visual RGBA et au moins un visual de couleurs indexées. Pour ces deux modes on exige un plan stencil d'au moins 1 bit et un z-buffer d'au moins 12 bits. En mode RGBA le plan dit accumulation est obligatoire, la partie alpha n'est pas réclamée. L'offre pouvant aller bien au-delà de ces exigences minimales les fonctions glxGetConfig et glxChooseVisual facilitent le choix du visual approprié. Ce choix une fois fait, la commande XCreateWindow de la Xlib peut être passée.

Pour travailler sur des pixmaps vous devez, dans un premier temps, utiliser la commande XCreatePixmap de la Xlib, puis faire un appel à glxCreateGLXPixmap avec un visual donné. Cette dernière commande vous renvoie un pointeur sur un type GLXPixmap que vous allez utiliser pour dessiner.

Si vous voulez faire du rendu avec un accès direct au matériel, vous devez faire une déclaration de render-context. La commande glXCreateContext permet la création de ce genre de contexte . L'assemblage de tous ces bouts de tuyau se fait au moyen de la commande glXMakeCurrent. Le chemin que va emprunter OpenGL est alors connu et le rendu peut commencer. Une application OpenGL peut compter plusieurs tuyaux de rendus. Mais à un instant donné l'association thread-tuyau est unique. Les flux GLX et X sont distincts. Si vous mélangez dans une même application des rendus X et OpenGL dans la même fenêtre vous pouvez les synchroniser au moyen des commandes glXWaitGL et glXWaitX. Si vous travaillez en mode double-buffer vous avez la commande glXSwapBuffers. La commande glXUseXFont vous permet de travailler avec des fontes X.

retour à la table des matières

Un exemple concret [4 & 5]

Le code source de cet exemple est sur un serveur www du SIC en tant qu' annexe A de ce document. C'est une illustration pratique de mise en oeuvre des commandes GLX qui viennent d'être décrites. Cette application affiche un cube 3D (figure 12), que vous pouvez faire tourner autour des 3 axes X Y et Z au moyen de la souris. Le code main compte 9 étapes:

  1. comme tout programme X, XOpenDisplay établit la connexion avec le serveur X;
  2. le serveur X a-t'il l'extension GLX ?
  3. sélection d'un visual approprié avant la création de la fenêtre. Dans cet exemple on fait une demande RGBA et TrueColor;
  4. création d'un contexte rendu OpenGL;
  5. création de la fenêtre avec le visual sélectionné. Le fait de ne pas prendre le visual de défaut rend les choses un peu plus compliquées du point de vue de la programmation;
  6. réalisation de la liaison fenêtre contexte, appel à glXMakeCurrent;
  7. demande d'affichage, XMapWindow;
  8. une série de commandes OpenGL pour spécifier différents états: z-buffer, couleur noir, chois de l'angle de vue;
  9. attente et aiguillage des événements: changement d'axe de rotation si un événement vient de la souris, réaffichage après un événement expose, changement de géométrie de la fenêtre.

figure 12

retour à la table des matières

Comparaison OpenGL/PEX [6]

PEX est une extension développée par le consortium X pour ajouter des fonctionnalités 3D au protocole X. La communauté PEX attend avec impatience la révision 6.0 qui devrait donner un second souffle à la version actuelle 5.1 qui apparaît un peu à bout de course. Ce qui rend la comparaison PEX OpenGL délicate c'est la divergence des préoccupations des architectes de ces deux produits. Du côté PEX on a pensé protocole en cherchant un système qui s'apparente plutôt à une pelure d'oignon. Cette architecture met souvent le client dans une situation difficile. Il n'est pas rare de se trouver dans une situation où le client PEX se lance dans un rendu que le serveur ne pourra honorer. Du côté OpenGL on a pensé avant tout interface de programmation. Les protocoles de communication vers X, NT sont des annexes. Mises à part les fonctions de rendu de base comme l'éclairage, z-buffer, PEX et OpenGL ont des appréciations complètement différentes sur le superflu et l'indispensable. Les fonctionnalités avancées de texture, d'alpha blending, de stencil, d'accumulation, double buffer évoquées plus haut, sont des extensions non standard ou absentes de PEX. PEX compte des fonctionnalités avancées dans le domaine du traitement de textes qu'OpenGL n'a pas. Pour la représentation des courbes et surfaces , PEX a choisi une technique B-spline, tandis qu'OpenGL a choisi celle des NURBS.

PEX et OpenGl offrent tous les deux des mécanismes pour accumuler des primitives graphiques. Dans PEX (si c'est une extension de niveau PHIGS) ce mécanisme se fait à travers les structures. On peut créer, éditer et construire des arbres. L'affichage de telle ou telle partie de l'objet se ramène à traverser telle ou telle partie de l'arbre.

On ne trouve pas d'équivalent strict dans le monde OpenGL. On peut accumuler des commandes dans des display list, une display list peut en appeler une autre, mais elle n'est pas directement éditable. L'édition se fera de façon indirecte en modifiant une liste appelée.

Vous pouvez vérifier la qualité du label OpenGL en le soumettant à une suite de tests ce qui n'est pas, à la date d'aujourd'hui, le cas pour PEX. La grande majorité des applications graphiques, dans le domaine de la CAO, de la simulation, de la visualisation scientifique et médicale est écrite sur la base de la bibliothèque propriétaire IRIS GL. Nul doute que la dynamique de conversion de ce vaste domaine d'applications vers OpenGL est plus importante que celle autour de PEX. La raison majeure est simple: si vous adoptez la technologie PEX vous limitez votre application au marché du système de fenêtres X, si vous adoptez la technologie OpenGL cette limitation tombe et votre application reste ouverte vers d'autres et futurs standards de fenêtres.

retour à la table des matières

références

[1] Gerald Farin, Curves and Surfaces for Computer Aided Geometric Design, Academic Press, 1990

[2] Foley, van Dam, Feiner, Hughes, Computer Graphics, 2nd ed, Addison-Wesley p 204-208, 1990

[3] Phil Karlton, OpenGL Graphics with the X Window System, version 1.0, october 1993

[4] Mark J. Kilgard, OpenGL and X: An introduction, The X Journal, January/February 1994

[5] Mark J. Kilgard, Using OpenGL with Xlib, The X Journal, January-February 1994, page 46-65.

[6] Allen Akin, Analysis of PEX 5.1 and OpenGL 1.0, Silicon Graphics August 3, 1992


article paru dans le Flash informatique no 6 du 21 juin 1994