Discussion :

[Harooold]

Bonjour à tous,

J'essaie de me remettre un peu à l'OpenGL, dépoussierer mon petit moteur multi fonction et me réconcilier avec mes soirées geeks devant mon ordi à programmer
J'ai levé la patte depuis la fin de mes études à savoir mi mars 2009, du coup bien avant les versions 3.x d'OpenGL.

Ayant suivi un peu de loin les évolution de notre API préferée je me doutais que mon ptit moteur allait devoir subir un relooking. Mais ils semblerait que les évolutions aient été plus méchantes que ce que j'aurais cru et passer à un moteur pur OpenGL 3.2, donc sans les extensions de compatibilité que je tiens à éviter, ben il va falloir tout refaire !

Alors je me suis muni de SDL qui permet facilement d'avoir un contexte 3.2, d'un exemple d'application de base et je me suis lancé. Après avoir réussi à afficher mon triangle multicolore j'ai commencé à mettre des glPush/PopMatrix mais réalisé après coup qu'étant donné que les variables built-in ne sont plus d'actualités, et bien la gestion des matrices par opengl non plus !

Là j'avoue avoir tiré un peu la tronche... Est il maintenant obligatoire au dév de faire lui même sa propre gestion des piles de matrices ?.
C'était bien pratique qu'opengl s'en charge pour nous et là ... j'avoue avoir la flème ! Pour ceux ayant déjà un peu avancer avec la 3.2 vous avez géré ça comment ?
Cela va rendre très ardue l'apprentissage d'opengl pour des jeunes padawans, je trouve ça dommage.

Qui dit gestion des matrices à la main, dit gestion du volume de vision manuel également ?
A vrai dire, ça ne me gène pas vraiment de devoir tout faire à la main, ça permet d'avoir un contrôle total sur ce qu'il se passe. Serait ce la fin des heures de débugages pour une histoire de matrice en colomne ou ligne dabord ?
Je vais commencer à réflechir à une gestion des transformations / orientations 100% quaternions si je trouve un moyen de m'en servir efficacement avec GLSL... quitte à avoir les mains libres, autant innover.

Tout ça pour dire que j'ai l'impression que la version 3.2 empute OpenGL de méchanismes qui étaient bien pratiques et facilitaient la vie aux développeurs !
Ce sont mes premières impressions, j'espere que j'aurais de meilleurs surprises avec la suite, rassurez moi !

Cordialement,
Harold

[LittleWhite]

Bonjour,

Moi aussi je peux dire que les dernières nouveautés d'OpenGL me déconcerte ( surtout que je suis nul en math ). Mais je crois qu'il existe des bibiolthèque pour la gestion des matrices.
Ce qui peut aider, je pense.

Sinon, il va falloir se taper les calculs des lumières, tout ça, tout ça. Du coup, je suis entièrement d'accord, que pour avoir un cube simple, on prend bien une journée ( j'ai pas encore fait ( j'ai pas de machine OpenGL 3.2 de toute façon ) ). Mais après on a les mains libres.
Alors, il est vrai que je ne suis pas totalement pour ces changements d'OpenGL ( mais j'ai pas le droit de parole dans le consortium ), mais je suis pas totalement contre pour autant.

Par contre, du coup, il manque des ressources sur le net ( qui reste trop souvent au OpenGL 1.4 ).
Bonne chance à ce qui veulent s'y mettre.

[AuraHxC]

Il existe la merveilleuse librairie GLM : http://glm.g-truc.net/
Tu trouve tout => matrice, vecteur, etc... tu as des méthodes pour générer des matrice de projection ,rotation, etc... facilement.
Et le plus merveilleux c'est que ça suit les spécifications de la GLSL donc exactement la même syntaxe.

Exemple : mat4, vec4, etc... pour déclarer une matrice 4x4, un vecteur de 4 de dimension 4.

[shenron666]

Salut,

Je suis actuellement en train de lire le livre Beginning OpenGL Game Programming, 2nd Ed qui a été réalisé entre autres par des personnes du fameux site nehe que tout développeur OpenGL doit connaitre.

Dans le bouquin, il est question de OpenGL 3.x et à propos des matrices ils disent effectivement que de nombreuses fonctions de gestion matricielles sont obsolètes. Si ce n'était que les piles (stacks), ça irait encore, mais maintenant il faut replonger dans les cours de math

Aussi les auteurs de nehe ont développé une bibliothèque que je ne connaissait pas pour gérer les matrices sous OpenGL 3.x : kazmath.

De mon côté, j'utilise mathgl-pp qui marche plutôt bien et qui est en C++

[AuraHxC]

Si il fait du GLSL, je trouve que GLM reste le must car cela donne une cohérence avec le code GLSL et le code API OpenGL vu que la syntaxe est la même. Et dans cette librairie, il existe une multitude de fonction super intéressante qui facilite la vie. Ce n'est que mon avis bien sur

[Happy]

Alors là, on oublie le classique conseil : commence par OpenGL, il est plus sympa à apprendre, t'arrive vite à un résultat, non ?

Je n'ai pas trop suivi l'évolution au concret, mais il était question d'enlever glBegin() et tous ces trucs sympa qui au début servent à apprendre et même par après : à débug. Qu'est-il de ça ? glBegin n'est plus là ?

Si par exemple on passe à OpenGL 3+ pur, est-ce que l'appli tournera toujours sur des anciennes cartes graphiques ?

Ça vaut le coup d'upgrade son moteur à GL3+ pur ? (Donc en enlevant glBegin() et cetera.) Oui j'utilise glBegin pour l'interface utilisateur qui se résume qu'à quelques triangles en 2D au dessus de la scène 3D.

J'attends avec impatience vos avis

[Soack]

Alors là, on oublie le classique conseil : commence par OpenGL, il est plus sympa à apprendre, t'arrive vite à un résultat, non ?

Je ne connais pas DirectX donc je ne peux pas vraiment juger. Mais je pense que niveau difficulté, OpenGL et DirectX se valent. Par contre, maintenant DirectX est sans doute plus abordable car les ressources (tuto) sur OpenGL deviennent à 80% dépréciés.

Je n'ai pas trop suivi l'évolution au concret, mais il était question d'enlever glBegin() et tous ces trucs sympa qui au début servent à apprendre et même par après : à débug. Qu'est-il de ça ? glBegin n'est plus là ?

Le but est surtout de forcer le programmeur à ne plus utiliser les fonctionnalités du pipeline fixe. Pour preuve, dans les shaders il n'y a même plus de variable built-in, il faut nous même passer les matrices, les attributs de sommets. C'est de toute façon plus puissant, car on définit nous même ce que sont les attributs de nos sommets. Je peux par exemple décider qu'un sommet c'est un ensemble: {position, normale, couleur, tangente}
Bon, ok on pouvait déjà le faire avant, mais cette fois c'est clairement le programmeur qui décide de ce qu'est un sommet.

Si par exemple on passe à OpenGL 3+ pur, est-ce que l'appli tournera toujours sur des anciennes cartes graphiques ?

Si tu passes à de l'OpenGL 3.2 pur, ça ne tournera pas sur des anciennes cartes graphiques. Par exemple les cartes graphiques qui ne supportent pas les shaders par exemple. Mais bon, il faut savoir évoluer, on ne peut pas toujours supporter les anciens matériels.
Après, si tu veux continuer à utiliser glBegin, et à utiliser le pipeline fixe (donc pas du OpenGL 3.2), tu peux ré-activer le tout via une extension.

Ça vaut le coup d'upgrade son moteur à GL3+ pur ? (Donc en enlevant glBegin() et cetera.) Oui j'utilise glBegin pour l'interface utilisateur qui se résume qu'à quelques triangles en 2D au dessus de la scène 3D.

Bien sur que ça vaut le cout. Quand OpenGL 3.0 est sorti, la majorité des gens ont criés au scandale parceque OpenGL utilisait encore le pipeline fixe. Le fait de forcer le programmeur à ne plus l'utiliser est donc ce que tout le monde attendait.

D'ailleurs si ça motive quelqu'un, pourquoi ne pas ouvrir un thread pour discuter de la rédaction d'un eventuel tutoriel sur OpenGL 3.2 ? La majorité des tuto sur OpenGL sont devenu dépréciés comme je le disais. Bien sur, quelqu'un pourrait le faire seul, mais je pense que si on veut faire quelque chose de bien, il faudrait couvrir beaucoup plus que ce qu'on peut trouver actuellement sur le net.

Je vois beaucoup de tutoriel OpenGL où on enseigne "Pour faire une rotation, tu utilises glRotated(). Oui, ok. Avant c'était valide, mais maintenant il faut donner au programmeur débutant des connaissances minimales sur l'algébre linéaire! Il y a tellement de chose à voir maintenant. (Bien sur, le programmeur peut toujours utiliser des lib mathématiques, mais bon, c'est moins marrant.)

Pour cette proposition, je vous laisse répondre. J'avais déjà proposé à Raptor, et ma proposition tient toujours.

[Happy]

Merci pour cette excellente réponse.

Ben si l'application GL 3.2+ pur ne tournera pas sur des anciennes cartes graphiques sans shaders c'est pas un problème. Si quelqu'un a une cg qui ne supporte pas les shaders, il sait qu'il veut pas jouer avec.

Quant à un bon tutoriel OpenGL 3.2 en français ce serait merveilleux. Par exemple moi je débarque, je veux mettre à jour mon application pour supporter le nouveau OpenGL, est-ce qu'on a un bon tutoriel en français ?

Je suis pour. Dommage que je ne pourrai pas aider sauf pour la correction de l'orthographe peut être.

[ash.ice.loky]

Je ne connais pas DirectX donc je ne peux pas vraiment juger. Mais je pense que niveau difficulté, OpenGL et DirectX se valent. Par contre, maintenant DirectX est sans doute plus abordable car les ressources (tuto) sur OpenGL deviennent à 80% dépréciés.

Et encore, on est plus proche des 95 que des 80.

Aujourd'hui le débat D3DvsOGL serait bien différent. Les 2 API existe pour d'autres langages, certain sont relativement bien portable. Les 2 APIs ont bien évolué pour au final se rapprocher. Ce qui faisait la force d'OGL, ca compatibilité est aujourd'hui son point faible. Pas possible de trouver de bons tutos sur le sujet.