OpenGL est l'interface de programmation standardisée de référence pour le rendu 3D, développée par le groupe Khronos, un consortium d'industriels ayant des intérêts dans le domaine (Intel, AMD, Apple…). Basée sur le langage C, elle a l'avantage d'être portable sur de nombreuses plate-formes, y compris sur du matériel mobile via sa mouture « ES ». Elle est en concurrence avec l'interface propriétaire de Microsoft, Direct3D, qui est au fil des ans devenue la référence dans le domaine du jeu vidéo sur ordinateur personnel.
À l'occasion de la Game Developpers Conference 2009, le groupe Khronos a donc publié les spécifications d'OpenGL 3.1, qui représente une étape importante de son développement, abandonnant finalement les reliques du passé. OpenGL 3.1, alliée à la naissante interface de calcul à hautes performances sur cartes graphiques OpenCL, se pose donc enfin comme une alternative tout à fait moderne à Direct3D. Cette version s'accompagne d'évolutions touchant GLSL, le langage d'écriture de Shader associé.
Une mise en perspective de cette nouvelle version dans l'histoire d'OpenGL est disponible dans la seconde partie de la dépêche. Cette partie de la dépêche va tenter de décrire objectivement ce que j'ai pu glaner de l'évolution du rendu 3D grand-public, d'OpenGL et de sa concurrence. Elle est en grande partie tirée de cet intéressant article et adopte uniquement le point de vue « divertissement » par opposition au rendu 3D professionnel.
Un peu d'histoire
Historiquement, OpenGL découle d'IRIS GL, bibliothèque propriétaire écrite par SGI pour ses stations de travail 3D haut de gamme. Au début des années 90, Silicon Graphics, pour assoir sa domination sur le domaine, décide de standardiser l'interface d'IRIS GL et de la pousser comme lingua franca de la programmation 3D. OpenGL était née. Parallèlement, SGI créée l'OpenGL Architecture Review Board, un comité d'entreprise chargé de faire évoluer OpenGL.
Parallèlement, le jeu sur ordinateur personnel explose. En 1995, les premières cartes 2D/3D grand public sont disponibles, et Microsoft publie la première version de Direct3D, futur concurrente d'OpenGL. La bibliothèque est à l'époque très mal reçue par plusieurs développeurs de renom, comme John Carmack. Au cours des années suivantes, Microsoft ne se décourage pas et continue à faire évoluer son offre, devenue peu à peu populaire pour l'écriture de jeux sous Windows, et se rapproche progressivement des fabricants de matériel.
Jusqu'aux années 2000, les cartes graphiques sont principalement des circuits dédiés à l'accélération de certaines fonctions précises, comme par exemple la gestion de la luminosité ou du brouillard. Cet état de fait est bien sûr reflété aussi bien par OpenGL que Direct3D qui disposent de fonctions dédiées à la gestion de ces tâches. Chaque interface de programmation permet à un auteur de pilote d'exposer aux développeurs certaines fonctionnalités spécifiques au matériel sous-jacent : extensions pour OpenGL, bits de capacité pour Direct3D.
Les choses changent au début des années 2000, les cartes graphiques évoluent profondément en devenant en partie programmables, à la manière d'un processeur conventionnel (mais dans une moindre mesure). En 2001, pour la première fois, Direct3D innove et bifurque de la voie tracée par SGI en introduisant le support pour les pixel et vertex shaders, ces programmes qui vont donc s'exécuter sur la carte graphique pour permettre certains effets précédemment impossibles. SGI et l'OpenGL ARB semblent pris au dépourvu et soumis à des conflits internes. Un an plus tard, Direct3D 9.0 introduit HLSL, un langage de programmation de haut niveau inspiré du C et dédié à l'écriture de shaders, et les fonctionnalités qui formeront le standard de facto du développement 3D contemporain.
Toutefois, sous l'impulsion principale de 3DRealms, l'OpenGL ARB s'ébroue et finit par introduire OpenGL 2.0 en 2004 puis 2.1 en 2005, qui offriront les mêmes possibilités que Direct3D 9.0, y compris son langage de shading (GLSL, évoqué en introduction). Parallèlement à cela, la possibilité de programmation des cartes graphiques augmente énormément, et la circuiterie dédiée aux tâches fixe diminue en proportion (tout en restant non-négligeable). Les possibilités des shaders se complexifient avec les versions mineures de Direct3D 9.
En 2006, Microsoft bouleverse sa bibliothèque en introduisant Direct3D 10.0, profondément incompatible avec les versions précédentes. En plus d'autres évolutions, les fonctions gérant les parties fixes du Pipeline 3D disparaissent, tout comme le système permettant à chaque carte d'offrir ses possibilités spécifiques : désormais, à génération de Direct3D fixée, les cartes sont fonctionnellement équivalentes. Les pilotes correspondants ne fonctionneront que sous Windows Vista et ultérieur.
L'impopularité de Windows Vista ouvre donc une brèche dans laquelle OpenGL peut s'engouffrer ; l'OpenGL ARB en a transféré la responsabilité au groupe Khronos précédemment cité, qui s'était montré très efficace dans sa gestion d'OpenGL ES. Khronos promet donc une transparence accrue et une modernisation drastique, semblable à celle entreprise par Microsoft en ce qui concerne la suppression des fonctions fixes du pipeline, qui ne correspondent plus à la réalité des cartes graphiques contemporaines et sont émulées par les pilotes. Mais fin 2007, Khronos reste muet, puis explique avoir rencontré certains contre-temps ; les développeurs s'en émeuvent, y compris sur LinuxFr. À l'été 2008, Khronos publie enfin les spécifications d'OpenGL 3.0 ; il est cependant clair que la plupart des aspects novateurs ont été supprimés, et qu'OpenGL 3.0 apporte peu aux extensions disponibles pour OpenGL 2.1. Les fonctions dédiées au pipeline fixe sont toujours présentes, bien que dépréciées ; John Carmack blâme le lobbying des auteurs de logiciels de conception assistée par ordinateur, effrayés à la perspective de devoir réécrire une partie de leurs codes sources.
Aujourd'hui et demain
Même si de très rares reliques du passé subsistent, OpenGL 3.1 supprime finalement les fonctions dépréciées dans OpenGL 3.0, et rejoint enfin l'état de l'art. Ces dernières sont toutefois disponibles dans une extension que les auteurs de pilotes sont libres d'implanter ou non.
La possibilité de programmation toujours croissante des cartes graphiques pose la question de leur évolution à moyen et long terme. Plus uniquement réservés au graphisme, ces processeurs massivement parallèles offrent désormais un rapport performances/prix inégalé pour les problèmes relevant du parallélisme de données. Intel, AMD/ATI et NVidia semblent tous tabler sur un rapprochement entre processeur central et cartes graphiques, au moins au niveau du rôle à jouer.
En particulier, NVidia propose depuis plusieurs années « C pour CUDA », un langage propriétaire inspiré du C et dédié à la programmation généraliste sur carte graphique. C'est sur cette base implicite qu'Apple et d'autres membres du groupe Khronos ont conçu OpenCL, un standard poursuivant le même but et à la syntaxe rappelant celle d'OpenGL. L'interopérabilité OpenCL - OpenGL est prévue, et OpenGL 3.1 introduit une fonctionnalité prévue à cet effet, le CopyBuffer. Évidemment, Microsoft prévoit avec Direct3D 11 d'introduire un équivalent propriétaire, sobrement nommé compute shader.
À très long terme, on peut se poser la question de la pertinence d'une couche d'abstraction de haut niveau vis-à-vis de cartes graphiques pleinement programmables, par rapport à l'écriture de code natif pour les cartes graphiques. Cette vision, poussée par Intel et son Larrabee, futur hybride de processeur x86 et carte graphique, semble exciter certains membres de la communauté académique mais est porteuse d'autant de promesses (diversité, renaissance d'approches alternatives…) que de dangers (fragmentation, instabilité…).
Et en ce qui concerne Linux et le logiciel libre ?
NVidia a annoncé le support de la spécification d'OpenGL 3.1 dans ses pilotes propriétaires en bêta le jour même de sa publication. AMD/ATI promet faire de même dans un très court laps de temps.
Si on revient au logiciel libre, la situation est assez complexe mais prometteuse. À l'heure actuelle, aucun pilote n'offre de support supérieur à la version 2.1 d'OpenGL ; toutefois, d'énormes travaux ont eu lieu au cours de l'année écoulée.
Trois briques sont responsables de la gestion matérielle de l'OpenGL sous Linux : le noyau lui-même, la bibliothèque Mesa et Xorg. Chaque couche a évolué pour offrir aux pilotes performances et simplicité accrues. L'intégration dans Mesa de Gallium3D, un nouvelle couche dédiée à l'écriture de pilotes graphiques, devrait parachever le tout. Zack Rusin, développeur chez Tungsten Graphics, révélait il y a quelque jours sur son blog que des travaux sur la gestion d'OpenCL dans Gallium 3D étaient en cours ; OpenGL 3.1 risque toutefois de se faire désirer assez longtemps.
Conclusion
Le domaine du graphisme 3D est en ébullition comme jamais. Le libre et les standards ont probablement un rôle à jouer. Avec l'avènement des consoles et le relatif essor des systèmes d'exploitation alternatifs (dont Mac OS X), la demande pour une interface de programmation standardisée devrait renaître. Espérons également que l'essor des cartes graphiques comme (co)processeurs généralistes ne laisse pas le libre sur le carreau.
Aller plus loin
- L'annonce de Khronos (4 clics)
- La spécification d'OpenGL 3.1 (PDF) (46 clics)
- La spécification de GLSL 1.40 (PDF) (13 clics)
- OpenGL sur Wikipédia (54 clics)
# Ca, c'est fait...
Posté par windu.2b . Évalué à 8.
_ Par là, mec.
_ Yeah, men !
Et sinon, merci pour le résumé de l'histoire d'OpenGL/Direct3D : ça fait toujours pas de mal de remettre les choses dans l'ordre et de voir le chemin parcouru :-)
[^] # Re: Ca, c'est fait...
Posté par thedude . Évalué à 2.
[^] # Re: Ca, c'est fait...
Posté par Houbaa . Évalué à 2.
[^] # Re: Ca, c'est fait...
Posté par thedude . Évalué à -2.
Mais c'est pas la peine de raconter un Monceaux de Clichy que tout le monde connait Pasteur...
J'en ricanne d'aisance.
Elle est pas belle la vie? Moi j'rentre comme ca...
(rendons aux romains ce qui est a cesar: http://fr.wikipedia.org/wiki/Java_(groupe) )
# Merci pour ces éclaircissements
Posté par Dup (site web personnel) . Évalué à 10.
Si seulement cela pouvait motiver les majors du jeux vidéo à développer en OpenGL cela leur permettrait d'adapter leur jeux sous linux/bsd à moindre cout.
Heureusement Carmack est fidèle à OpenGL et si son futur moteur est couronné de succès on pourra voir de nombreux jeux utiliser OpenGL.
[^] # Re: Merci pour ces éclaircissements
Posté par Okki (site web personnel, Mastodon) . Évalué à 10.
[^] # Re: Merci pour ces éclaircissements
Posté par O'neam Anne . Évalué à 4.
Dans le cas de Warcraft III, il faut lui passer un argument pour lui dire d'utiliser OpenGL et pas DirectX.
Dans la version Windows, bien entendu, pas dans la version MacOSX.
Oui, un tas de studios portent leurs jeux sous MacOSX, mais pas pour Linux...
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Merci pour ces éclaircissements
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: Merci pour ces éclaircissements
Posté par Dup (site web personnel) . Évalué à 5.
Et de plus un jeu développé en OpenGL facilite son fonctionnement sous wine, car le directX ca reste aléatoire, des fois ça marche des fois pas ^^
[^] # Re: Merci pour ces éclaircissements
Posté par liberforce (site web personnel) . Évalué à 10.
[^] # Re: Merci pour ces éclaircissements
Posté par tanguy_k (site web personnel) . Évalué à 5.
D'après ce que j'ai pu lire a droite et a gauche, peu sont les développeurs a coder directement en DirectX ou OpenGL. Les développeurs utilisent désormais des moteurs 3D tout fait (voir OGRE, Crystal Space...) qui leur permettent de porter leurs jeux sur les différentes consoles. Il y a donc une couche d'abstraction ce qui permet de choisir ensuite entre OpenGL ou DirectX comme backend.
Au passage, quelqu'un connait les bibliothèques utilisées par la Wii et la PS3 ? (a n'en pas douter la XBox 360 utilise un ersatz de DirectX)
[^] # Re: Merci pour ces éclaircissements
Posté par Sébastien B. . Évalué à 5.
[^] # Re: Merci pour ces éclaircissements
Posté par Prae . Évalué à 5.
[^] # Re: Merci pour ces éclaircissements
Posté par Xavier MOGHRABI (site web personnel) . Évalué à 3.
Selon Wikipedia :
"PSGL is a 3D computer graphics API based on OpenGL ES for the Sony PlayStation 3. A previous version of PSGL was available for the Sony PlayStation 2 but was largely unused."
[^] # Re: Merci pour ces éclaircissements
Posté par Larry Cow . Évalué à 2.
Pourquoi un ersatz? Vu la bête, j'aurais plutôt dit qu'elle utilisait une version survitaminée de DirectX (et que, si on va par là, c'est plutôt la version PC/Windows qui ferait office d'ersatz).
[^] # Re: Merci pour ces éclaircissements
Posté par Okki (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Merci pour ces éclaircissements
Posté par auve . Évalué à 8.
Oui, cela dit :
1/ Encore faut-il que le moteur supporte les deux APIs ; c'est malheureusement loin d'être le cas de la plupart des ténors actuels, en négligeant les moteurs d'ID Software. Par exemple, tant l'Unreal Engine 3 que le CryEngine supportent uniquement la trinité PC (D3D 9/10), XBox 360 (D3D 9.0c«++») et PS3 (libGCM).
2/ Pire, il faut bien que les développeurs et artistes écrivent des shaders ; et là, ils ont le choix entre HLSL et GLSL, tous deux spécifiques à une API, ou Cg, un langage propriétaire à NVidia compilant au choix vers l'un des deux précédents ou d'être utilisé sur la PS3. Je ne sais pas du tout quel est le plus répandu, je suppose que Cg doit être assez apprécié pour sa portabilité. En bref, l'abstraction qu'apporte le moteur 3D est un peu brisée par le choix du langage de shading, si on veut se restreindre aux technologies libres.
[Il est vrai que certains moteurs apportent leur propre cadre (parfois sous forme graphique) pour l'écriture de shaders.]
[^] # Re: Merci pour ces éclaircissements
Posté par bubar🦥 (site web personnel) . Évalué à 10.
Non seulement cet article est passionant, mais en plus il vient à point nommé pour nous rappeler qu' il y a environ 2 ans (un peu moins je crois) Microsoft avait annoncé l' abandon d' OpenGL (en fait le passage à un mode émulé, ce qui tuais les performances) pour forcer de nombreux editeurs à proposer leur produits en directX only. (Dassault par exemple, pour citer un Français célèbre, mais de nombreux autres... allez un "petit" AutoDesk aussi ;) )
Ce fut encore une tentative 'monopolistique' qui avait fait trembler pas mal de monde...
Les éditeurs ne suivent pas la politique de Microsoft et semblent pour une majorité continuer de travailler avec OpenGL, autant voir plus qu' avec directX, mais pas exclusivement avec ce dernier. (ce qui leur assurent certainement un avenir indépendant, par conservation d' un choix.)
Le 'renouveau' d' OpenGL fait vraiment plaisir, même si Linux n' en bénéficie que peu pour le moment.
[^] # Re: Merci pour ces éclaircissements
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Mais pour en bénéficier sur un O.S plus qu' Open, libre, il faut passer par un driver privateur.
Y a quant même un paradoxe, non ?
[^] # Re: Merci pour ces éclaircissements
Posté par auve . Évalué à 5.
Ne nous emballons pas non plus ; à l'heure actuelle c'est tout de même le dialogue constant développeurs Direct3D <-> Microsoft <-> constructeurs qui mène les évolutions futures des cartes (exemple récent : la tessellation). Le seul point où OpenGL me semble vraiment en avance concerne les liens avec OpenCL, mais à ma connaissance ce n'est encore implanté nulle part ; ça devrait débarquer chez Apple vers l'été prochain... Mais Direct3D 11 et son compute shader concurrent risquent de paraître dans ces eaux là également.
[^] # Re: Merci pour ces éclaircissements
Posté par vida18 . Évalué à 1.
Sinon, on dit "OpenGL" mais est-ce que c'est sous une licence libre ?
[^] # Re: Merci pour ces éclaircissements
Posté par auve . Évalué à 5.
Difficile de donner une date précise ; beaucoup de choses changent et comme indiqué le travail de fond sur Xorg/Mesa devrait permettre de disposer enfin d'une infrastructure moderne. Le rendu graphique avec du matériel moderne est extrêmement complexe, et les pilotes sont vitaux pour obtenir de bonnes performances. En particulier, le compilateur de shader est une bestiole compliquée qui reprend des techniques bien connues de compilation pour architectures VLIW ; voir par exemple cette présentation : http://www.cgo.org/cgo2008/presentations/CGO-rubin.pdf
Sinon, on dit "OpenGL" mais est-ce que c'est sous une licence libre ?
Le standard est librement disponible et implantable, mais pour avoir le droit de s'appeler officiellement « OpenGL », il me semble qu'il faut passer non-seulement passer la batterie de tests de Khronos/l'ARB mais également payer. Pour ces raisons, Mesa n'est pas officiellement « OpenGL-approved ».
[^] # Re: Merci pour ces éclaircissements
Posté par pasBill pasGates . Évalué à 8.
Ce fut encore une tentative 'monopolistique' qui avait fait trembler pas mal de monde...
C'est totalement faux.
Le renderer OpenGL software dans Vista etait une couche par dessus Direct3D, mais les drivers opengl livres avec les cartes eux etaient direct sur le HW et il n'y a aucune difference avec XP de ce cote la.
A peu pres n'importe qui qui veut vraiment de l'OpenGL a les drivers opengl pour sa carte et ne touchera jamais le renderer software.
Ceux qui n'ont pas de drivers OpenGL pour leurs cartes mais des drivers Direct3D pouvaient quand a eux tirer parti de l'acceleration materielle a travers Direct3D.
Resultat, c'est une AMELIORATION pour OpenGL.
Dingue quand meme comme on arrive a prendre une amelioration de support OpenGL et la tourner en FUD.
[^] # Re: Merci pour ces éclaircissements
Posté par windu.2b . Évalué à 9.
De la part d'un employé de MS, on doit prendre ça comme un compliment du maître envers l'élève ? :-p
[^] # Re: Merci pour ces éclaircissements
Posté par benoar . Évalué à 9.
Là où était le FUD c'est que tout le monde a décrié la mise à mort d'OpenGL, alors qu'il fallait "juste" que les constructeurs adaptent leur driver. Là où je rejoindrais ceux qui s'inquiétaient, c'est qu'on aurait pu voir les constructeurs refuser de réimplémenter leur driver OpenGL pour Vista, sachant qu'il est peu utilisé, et là ça aurait vraiment fait mal pour OpenGL.
Enfin bon, je dis ça, mais je sais pas vraiment quel est l'état des drivers des deux grands constructeurs sous cet OS /o\ ...
[^] # Re: Merci pour ces éclaircissements
Posté par TImaniac (site web personnel) . Évalué à 2.
Non plus : le fameux driver qui fait la traduction en DirectX (OpenGL 1.4 max) ne provoque pas de perte de performance, au contraire, puisque du coup il y a accélération matérielle, même si le fournisseur de carte graphique ne fourni pas de pilotes dédié. C'est une avancée vu qu'avant le pilote par défaut de Microsoft avait un rendu purement logiciel.
Sinon y'a toujours le support de l'ancienne interface Windows XP. Le seul problème est que ca désactive l'interface 3D du bureau (en live). La compatibilité avec les applications existantes est donc assurée.
Et y'a aussi l'autre méthode qui consistait à faire des drivers dédiés, ce qu'on fait NVidia et ATI.
[^] # Re: Merci pour ces éclaircissements
Posté par benoar . Évalué à 2.
Comparer un émulateur semi-accéléré à du rendu soft, forcément que ça va être à l'avantage du premier. Là, c'était en comparaison avec ce qu'on pouvait avoir avant sous XP (driver natif qui marchait déjà) : il y a clairement régression.
[^] # Re: Merci pour ces éclaircissements
Posté par TImaniac (site web personnel) . Évalué à 3.
T'as le choix entre :
- utiliser le driver natif accéléré (par traduction)
- utiliser le driver XP qui désactive Aero au moment où tourne l'appli : c'est pas rhédibitoire puisque automatique, les fenêtres ne sont plus transparentes et le redeviennent dès que tu fermes l'appli. Se voit même pas dans une application fullscreen (forcement)
- utiliser le driver Vista fourni par le constructeur
En gros :
- soit t'as une carte 3D NVidia ATI ou Intel avec driver Vista : auncune régression
- soit ta carte est ancienne : pilote XP, désactivation temporaire de aero
- soit t'as pas de pilotes XP, et t'as l'accélération que t'avais pas sous XP qui utilisait un rendu software.
Faut vraiment être tordu pour voir une régression dans ces 3 possibilités qui sont accélérées.
[^] # Re: Merci pour ces éclaircissements
Posté par Octabrain . Évalué à 1.
Non, c'est fini ça : http://www.nofrag.com/2007/mar/07/24739/
[^] # Re: Merci pour ces éclaircissements
Posté par Sébastien B. . Évalué à 0.
[^] # Re: Merci pour ces éclaircissements
Posté par Octabrain . Évalué à 1.
[^] # Re: Merci pour ces éclaircissements
Posté par TImaniac (site web personnel) . Évalué à 2.
http://en.wikipedia.org/wiki/Id_Tech_5
[^] # Re: Merci pour ces éclaircissements
Posté par Octabrain . Évalué à 1.
[^] # Re: Merci pour ces éclaircissements
Posté par Sébastien B. . Évalué à 1.
[^] # Re: Merci pour ces éclaircissements
Posté par Octabrain . Évalué à 0.
Je ne suis pas en train de nier en bloc qu'il aie pu dire qu'il voulait retourner à OpenGL, mais je ne trouve aucune trace de ça pour l'instant.
# Enfin !
Posté par Meku (site web personnel) . Évalué à 6.
Il y a quelques jours j'ai voulu connaître ce qu'étaient les techniques et méthodes « d'aujourd'hui » dans OpenGL. En lisant la spec d'OpenGL 3.0, j'étais un peu déçu de la voir encore encombrée de vieilleries décrites avec précision, puis de les voir marquées « obsolète ». Ça surchargeait le document, rendait certaines choses encore plus confuses (mêmes fonctions ayant des comportement différents selon le mode d'utilisation...), et pouvait même induire en erreur (i.e., nous amener à utiliser des méthodes obsolètes parce qu'on a raté la ligne importante...). Ça n'aidait pas à y voir clair sur ce point, et un débutant lisant une doc comportant des éléments obsolètes et contre-performant va perdre du temps...
Du coup, ça devrait faire maigrir un coup le guide de programmation aussi (le « red book »).
Reste à voir pour les implémentation libres (dans mesa/gallium...). J'ai peur que ce ne soit pas encore à l'ordre du jour.
[^] # Re: Enfin !
Posté par beagf (site web personnel) . Évalué à 10.
- pédagogiques : elles permetait d'aprendre facilement l'OpenGL de manière explicte, le code suivant par exemple était simple à comprendre et à utiliser :
glBegin(GL_TRANGLES);glVertex3f(0.0, 0.0, 0.0);
glVertex3f(1.0, 0.0, 0.0);
glVertex3f(1.0, 1.0, 0.0);
glEnd();
Cela permettait d'entrer en douceur dans le monde d'OpenGL, de faire facilement des essais et de debuger avec beaucoup moins de soucis. Plus tard tu apprend à utiliser les array et tout ce qui va avec.
- prototypage : Ces méthodes permetait d'obtenir très rapidement et sans ce prendre la tête et visualisation 3D de n'importe quoi. Par exemple en ce moment je bosse sur un petit moteur physique pour un petit jeu et ce genre de méthodes me permet de visualiser graphiquement tous les paramètres du moteurs sans avoir à passer par des lignes de code complexes qui ne seront dévellopée que plus tard quand le moteur sera suffisament bon et que je passerais à l'aspect graphique du jeu.
En attendant un rendu super basique avec ces méthodes est largement suffisant et extrèmement simple à coder.
Donc, oui c'est une bonne chose qu'elles aient disparu de la spec, mais j'espère que l'on verra apparaitre une lib du style de glu ou de glut qui implémentera une API très simple et basique au dessus de la spec.
Enfin en attendant, il est fort probable que toutes ces méthodes restent disponible avec l'extention de compatibilité pendant au moins quelques temps. On verra plus tard.
[^] # Re: Enfin !
Posté par Meku (site web personnel) . Évalué à 5.
Sinon, il y avait quand même certains éléments vraiment obsolètes (plus nécessaires), par exemple les Vertex Arrays complètement remplacés par les VBOs. De même pour les display lists : tant qu'à vouloir un rendu plus rapide, autant passer par les VBO plutôt que de garder le mode de rendu immédiat combiné avec les display lists. Il me semble aussi que les textures 1D ont disparu. Qui s'en servait ? Était-ce utile de rajouter des fonctions et constantes pour ça, alors qu'on peut très bien utiliser une texture 2D d'un pixel de hauteur, si besoin.
# Direct3D, pas DirectX
Posté par Quzqo . Évalué à 5.
° Elle arrive fort tard par rapport à la sortie de DirectX 10.x alors qu'il aurait été de bon ton de "profiter" du flou des API introduit avec Vista et la version 10
° En termes de jeux, on ne peut pas limiter l'intérêt d'une API au rendu 2D/3D. Là où DirectX apporte un support multimédia complet (3D, video, son, réseau et périphériques) aux développeurs, OpenGL est limité à la 2D/3D. L'abstraction est donc "globalement" bien moins intéressante.
° Bénéficier aujourd'hui d'une 3D performante signifie utiliser des pilotes propriétaires (oublions les chipset Intel...) et ces pilotes, outre leurs limitations (proprio), sont peu supportés (voir entre autres les derniers articles concernant ATI et le point de vue des mainteneurs sur les forums Phoronix) et surtout peu performants en OpenGL. Curieux tout de même qu'il y ait des outils de benchs à foison en DirectX et si peu pour OpenGL (mais les piètres performances ne sont sans doute pas la seule raison).
Au final, je ne sais pas ce qu'il en est pour la 3D professionnelle et OpenGL mais côté jeux et plus généralement multimédia, OpenGL a encore bien des obstacles à franchir avant d'occuper une place de choix sur nos Desktop.
Le seul avantage que j'y vois (ne connaissant pas ses attraits purement techniques) est son caractère multiplateforme.
Et pour ce qui est des interfaces de programmation disponibles sur les CG, cela reste encore limité par le caractère fortement parallélisable et, intrinsèquement, à forte itération (sans renouvellement intensif des données traitées) du fait des goulots d'étranglement matériels *
Cela reste donc aujourd'hui plus marketing qu'utile pour le grand public à mon avis.
* mais je me trompe peut être sur ce point
[^] # Re: Direct3D, pas DirectX
Posté par Anonyme . Évalué à 2.
Vu la proportion de Mac cela peut être un argument plus que valable, non?
[^] # Re: Direct3D, pas DirectX
Posté par Adrien . Évalué à 3.
Il semble que pour la simulation scientifique et industrielle OpenGL soit très largement utilisé…
[^] # Re: Direct3D, pas DirectX
Posté par zakMcKraken . Évalué à 2.
- OpenGL 3.0 a mis plus de 2 ans à se faire.
- OpenGL 3.1 n'est toujours pas à la hauteur (face à Direct3D).
[^] # Re: Direct3D, pas DirectX
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Catia tourne chez Dassault sous Linux mais pas moyen d'avoir cette version...
Bref, parfois les leades n'aident pas...
# Et concretement cela change quoi ?
Posté par Guillaum (site web personnel) . Évalué à 3.
OpenGL 3.1 repond-t-il aux attentes ? Je lis dans certains commentaires qu'il n'est toujours pas aux niveau de Direct 3D, quelqu'un as-t-il des arguments, des explications ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.