Discussion :

[Sahengette]

Bonjour,
Je débute à fond dans la programmation 3D, et je cherche vraiment à utiliser OpenGL pour m'amuser entre autre, mais d'une façon propre.
En effet sur le net je ne trouve que des tutos qui traite des vieilles versions d'OGL, trés trés peu sur OGL 3.3 et supérieur, à part celui du SDZ, j'ai même cherché sur des sites anglais mais rien de complet ...

D'ailleurs j'ai plein de question :

Sur le tuto du sdz, on apprend à recoder de vieilles fonctions (gluLookAt) vraiment en copiant totalement le fonctionnement de la fonction glu, sans intêret surtout qu'on n'optimise rien. Je trouve ça vraiment pas claire ...

Aussi, l'architecture de OGL, je la trouve improbable : en effet elle est trés puissante mais je ne vois vraiment par où commencer ...
Quelle est la "bonne manière" de procéder ?

En effet quand on débute dans OGL 2.x, on est un minimum aidé par Glu et les fonctions gl non dépréciés, mais dans OGL 3.x je trouve ça ardu pour commencer (je ne remet pas en cause OGL !).

Pourriez vous me conseiller un tuto en ligne (anglais comme francais) sur de l'OpenGL moderne de qualité (parce que je trouve les tutos du SDZ douteux en général) qui montre les vrais nouveautés et la vraie nouvelle idéologie de OGL, un livre peut-être ?

J'attend vraiment beaucoup de ce topic, en effet je suis complétement largué en ce bas monde, je cherche la voie du salut, un guide éternel pour une béatitude complète, Dieu vous ?

[DonQuiche]

De bons tutos, complets, je n'en connais pas. Tu peux par contre trouver les livres sur OpenGL 3.x voire OpenGL ES 2.0 (ce dernier est grosso modo équivalent à OpenGL 2 moins tout ce qui a été rendu obsolète dans OpenGL3 et quelques fonctions trop lourdes pour des mobiles).

Cela dit, si tu as compris comment utiliser un shader et que tu connais l'ancien OpenGL, il n'y a rien de très sorcier. Tu dois écrire un ou plusieurs shaders qui vont transformer tes sommets. Tu peux en écrire un qui prendra une, deux ou trois matrices en argument, un autre qui ne prendra qu'un point en argument, un autre qui prendra simplement trois facteurs d'échelle, etc. Il n'y a pas une bonne façon générique de faire, tout dépend de ton programme, de la nature des transformations à effectuer, de la fréquence à laquelle elles changent, de techniques d'équilibre de la charge CPU et GPU (par exemple, faire mettre en cache par le CPU des résultats de calculs qui changent rarement pour les passer prêts à l'emploi au GPU), etc. De toute façon tout ça ne relève que de l'optimisation.

Maintenant, si tu veux reproduire le comportement OGL1, c'est simple :
* Ecris un vertex shader qui prend deux matrices en argument et multiplie successivement les sommets par ces deux matrices pour obtenir la position à l'écran.
* Tu écris des primitives créant la matrice projection et une pile de matrices ViewModel. A chaque dessin tu passes en argument au shader ta matrice projection et le sommet de ta pile VM.

Mais supposons que tu dessines des modèles qui sont toujours à la même position sur l'écran (cockpit dans un jeu spatial à la première personne, la tête ne peut pas tourner) : dans ce cas autant appliquer les transformations côté CPU la première fois et utiliser un vertex shader vide. Ou si seule la caméra bouge et que les objets restent immobiles dans le monde (maisons identiques mais orientées différemment), on pourrait transformer une fois pour toute les sommets côté CPU pour les placer dans les coordonnées monde et ne passer qu'une matrice de projection au shader. Ou peut-être pas puisque cela augmenterait la conso mémoire (chaque clone devant maintenant avoir sa propre géométrie prétransformée), tout dépend donc des charges générées dans les deux cas et des goulets d'étranglement de ton appli. Enfin, si tu fais du dessin 2D avec des primitives qui ne font translater, on écrira un shader qui ne prendra qu'un vecteur 2D en argument et pas de matrices.

Il n'y a pas une seule façon de faire, il y a de nombreux problèmes possibles et pour chacun des réponses plus ou moins astucieuses. Bref ! C'est de la programmation !
Rappelle-toi simplement que ce n'est que de l'optimisation et que "premature optimization is the root of all evil". Enfin, pas toujours.

[bru-no]

[...]

Ben oui c'est ardu...

Il n'y a pas de changement véritable d'esprit entre les versions d'opengl, plutôt de méthodes.

Personnellement je te conseille, malgré ce que tu en penses, d'apprendre avec les tutoriels SDL. Ces tutoriaux ne sont pas là pour te transformer en super gourou de la 3d, mais pour te donner des bases. L'optique c'est pas de te sortir un code super optimisé pour afficher un simple cube texturé, c'est de te faire comprendre les mécanismes nécessaires au fonctionnement d'Opengl. Une fois à l'aise avec l'API (y a du travail quand même), tu feras tes optimisations.

Cette version permet déjà de faire beaucoup de choses. Si je ne dis pas de bêtises, Doom 3 (ok c'est pas le jeu le plus récent) a été développé avec 2.x.

Après il faut du temps, beaucoup de temps, et de la patience...

[DonQuiche]

Pour ma part je pense que c'est une bonne idée de travailler en OpenGL 2.0... Mais sans jamais utiliser tout ce qui a été rendu obsolète dans la 3.0 ! Autrement dit d'utiliser un pur pipeline programmable, de l'OpenGL 3.0 sans les additions de la 3.0.

Tout simplement parce que le pipeline programmable c'est l'avenir (le présent en fait) et que c'est déjà bien supporté par le parc actuel. Et que, aujourd'hui, en faisant ça on peut écrire un code qui tourne presque sans modifications sur des mobiles (OpenGL ES 2.0 c'est à peu près ça) et qui peut être assez facilement porté vers Dx9 (qui lui-même très bien supporté au niveau hardware par le parc existant). Et aussi parce que certaines des fonctions rendues obsolètes pourraient à l'avenir ne pas être supportées, ou être mal supportées, par les drivers.

Enfin, le pipeline fixe est plus compliqué à apprendre et à utiliser, son API est plus volumineuse et je ne vois donc pas en quoi ce serait un bon préalable. Pas de comparaison foireuse svp, l'asm est certes plus compliqué à apprendre mais il n'a pas été marqué obsolète, lui.

[bru-no]

Pour ma part je pense que c'est une bonne idée de travailler en OpenGL 2.0... Mais sans jamais utiliser tout ce qui a été rendu obsolète dans la 3.0 ! Autrement dit d'utiliser un pur pipeline programmable, de l'OpenGL 3.0 sans les additions de la 3.0.

C'est l'idée que je voulais faire passer. On ne saurait mieux dire !

[Sahengette]

C'est l'idée que je voulais faire passer. On ne saurait mieux dire !

Et c'est quoi ces fonctionnalitées supplémentaires, que propose OpenGL 3.3

[Sahengette]

Je commence un peu à comprendre, la force du pipeline programmable, c'est de optimiser son programmer comme on veut, il n'y a pas de "solution passe-partout", j'ai juste à faire mumuse avec différents shaders, en fonction du programme, en testant les perfs etc ...
Je me trompe ?

[DonQuiche]

Je commence un peu à comprendre, la force du pipeline programmable, c'est de optimiser son programmer comme on veut, il n'y a pas de "solution passe-partout", j'ai juste à faire mumuse avec différents shaders, en fonction du programme, en testant les perfs etc ...
Je me trompe ?

Tu as tout juste.
Note que tester les perfs c'est tout de même délicat : ça varie d'une carte graphique à l'autre, d'une version des drivers à une autre et ça dépend du contexte : dans un programme dont le goulet d'étranglement est le CPU, les bonnes méthodes sont celles qui allègeront la tâche de ce dernier. Mais elles seront mauvaises dans d'autres cas. Il faut surtout voir les choses en termes de goulets d'étranglement (bottlenecks) même si, typiquement, c'est le CPU dans un programme optimisé (mais parfois parce qu'on lui a filé des tâches qui ont permis de faire en sorte que le reste ne soit plus un bottleneck et donc de rendre le programme plus rapide).

Et c'est quoi ces fonctionnalitées supplémentaires, que propose OpenGL 3.3

Pour ça l'article US de Wikipedia est pratique parce qu'il liste toutes les versions et leurs changements, cela permet de retrouver en vitesse de quand datent telles et telles innovations et en déduire un support approximatif par tes utilisateurs.

[bru-no]

Un outils qui pourra sans doute t'aider pendant le développement : gDEBugger

Les shaders vont te permettre de gérer l'affichage. Par exemple pour le fragment shader les points de l'image sont traités un par un avant d'être affiché. Imagine que tu fasses un jeu dans lequel y a des flashback en noir et blanc : il suffit que tu fasses un shader qui pour chaque pixel va faire la moyenne des valeurs r,g,b, et envoyer la valeur en sortie. Bon je simplifie énormément, mais c'est l'idée. Tu as accès à ce qui va être affiché et tu peux le modifier à ta convenance.

Sur geeks3d, tu as une shader library, ça peut te donner une idée de ce que l'on peut faire aussi.

[Sahengette]

Merci beaucoup, c'est vraiment sympa tout ça !

Pour ma part je pense que c'est une bonne idée de travailler en OpenGL 2.0... Mais sans jamais utiliser tout ce qui a été rendu obsolète dans la 3.0 ! Autrement dit d'utiliser un pur pipeline programmable, de l'OpenGL 3.0 sans les additions de la 3.0.

J'ai (encore) une question, pourquoi est ce que je devrez essayer de ne pas utiliser les nouveautés de OGL 3.3 ?

[DonQuiche]

Pour deux raisons. La première tient au support. Non seulement parce que, comme je l'ai dit, si tu apprends à faire du pur pipeline programmable en OGL2, tu sais également programmer avec Dx9 et OpenGL ES 2.0. Autrement dit tu dois couvrir 50% du marché mobile+PC+Mac. 50% seulement pour une norme datant de 2004 ?! Oui ! Parce que plein d'utilisateurs ont des drivers pourris qui font qu'ils ne profitent pas de l'accélération et que Intel se fout royalement d'OpenGL (ex avec OGL2 : norme publiée en 2004, chipsets compatibles sortis en 2006 mais aucun driver avant mi-2009 ! Donc les utilisateurs qui ont acheté leur machine avant et n'ont jamais mis à jour leurs drivers ne profitent pas de OGL2). DirectX est clairement mieux loti (support Dx9 dès la sortie des chipsets)

Ça c'était pour OGL2 qui date de 2004. OpenGL 3.0 date quant à lui de 2008 et les premiers chipsets Intel compatibles sont sortis en 2011. J'ignore s'ils ont des drivers compatibles en revanche. Quant à OGL 3.3, la norme date de 2010 seulement. Autant dire que moins de 5% du parc PC doit être compatible. Quant au mobile, OpenGL ES 2.0 est la plus haute norme à ce jour et pas dispo sur tous les mobiles (pour iPhone, à partir de 2009).

Après, tout dépend. Si tu développes aujourd'hui un jeu PC devant sortir dans deux ans et destiné à un public de gamers ayant en moyenne des machines supérieures, tu peux optimiser pour OGL 3.0 et simplement assurer un support décent pour OGL 2.0. Mais pour la plupart des développements, on restera plutôt sur du 2.0/2.1 en assurant un support décent pour 1.1. Dans tous les cas, savoir se limiter au 2.0 sera obligatoire pendant de nombreuses années encore, ne serait-ce que pour une compatibilité a minima.


L'autre raison est purement pédagogique : connaître les "vieux" algorithmes (enfin, ceux utilisés aujourd'hui dans tous les jeux) plutôt que les nouveaux (ceux présents en option dans quelques jeux pour justifier l'achat de deux CG à 300€ chaque) peut se révéler utile. Ne serait-ce que parce qu'ils permettent de libérer de la puissance pour la dédier à autre chose. Ou encore parce que les astuces qu'ils utilisent ont souvent tendance à être recyclées ou transposées à de nouveaux problèmes. Les connaître te permettra d'avoir davantage d'outils pour élaborer tes solutions.