Discussion :

[pyros]

Honnêtement à première vue l'utilisation des fonctions dépréciées paraît simple quand même, vous ne trouvez pas ?

Tout à fait d'accord. Mais en informatique, simplicité rime rarement avec performance .
Ces fonctions ont été passé en déprécié parce que à cause (grâce à) leur simplicités, beaucoup de développeurs n'utilisaient qu'elles. Le problème est qu'elles prennent de la place sur les GPU, que les constructeurs de carte doivent continuer à les maintenir, etc... Bref, elles utilisent beaucoup de ressources aussi bien materielles (transistors sur les puces) qu'humaines (s'assurer de la compat avec les nouvelles cartes), autant de ressources qui pourraient être utilisées pour améliorer les techniques actuelles.

Elles ont été totalement supprimées dans OpenGL ES2 (OpenGL utilisé dans les smartophone, Iphone, Androïde, etc...) mais sur PC il y a tellement de logiciels qui les utilisent qu'elle ne sont pas prête de disparaitre.

Pour un débutant amateur qui souhaite juste s'amuser un peu, aucun problême pour les utiliser. Mais pour un débutant qui doit utiliser OpenGL à des fins professionnelles, il vaut mieux qu'il se forme aux nouvelles techniques (shaders, VBO) plutôt que prendre de mauvaises habitudes.

[LittleWhite]

Tout à fait d'accord. Mais en informatique, simplicité rime rarement avec performance .
Ces fonctions ont été passé en déprécié parce que à cause (grâce à) leur simplicités, beaucoup de développeurs n'utilisaient qu'elles. Le problème est qu'elles prennent de la place sur les GPU, que les constructeurs de carte doivent continuer à les maintenir, etc... Bref, elles utilisent beaucoup de ressources aussi bien materielles (transistors sur les puces) qu'humaines (s'assurer de la compat avec les nouvelles cartes), autant de ressources qui pourraient être utilisées pour améliorer les techniques actuelles.

Euh, vous êtes sur que ce n'est pas simplement le pilote qui gère cela. J'ai vu des intégrations du vieux pipeline fixe tout en shader pour que cela passe directement dans une carte OpenGL 2 compatible.

[pyros]

Vous avez raison:

Modern GPUs no longer support fixed function. Everything is done with shaders. In order to preserve compatibility, the GL driver generates a shader that simulates the fixed function. It is recommended that all new modern programs use shaders. New users need not learn fixed function related operations of GL such as glLight, glMaterial, glTexEnv and many others.

(cf ici).
Je pense qu'il y a eu une periode d'adaptation au début des shader et qu'aujourd'hui tous les GPU fonctionnent comme cela, mais au final les constructeurs perdent quand même du temps à gérer cette compat et ils aimeraient bien ne plus avoir à s'en occuper. C'est toujours très joyeux de devoir maintenir des vielles feature prehistoriques...

[Invité]

Quoiqu'il en soit je pense que je vais farfouiller dans les tutos de NeHe : son site a l'air pas mal... Dommage qu'il soit lui aussi en english.

Bonne journée Messieurs. Cordialement, Gizmo.

[dragonjoker59]

Ses tutoriels (une partie du moins, et celle qui t'intéresse, en plus) se trouve sur Développez.com :
ICI

[gbdivers]

La question de l'envoi des données au GPU (display list, vertex array, vbo, etc.) est abordé dans le tutoriel que LittleWhite t'a indiqué : http://gbelz.developpez.com/remi-ach...page=opengl#L3

[Invité]

Merci pour toutes ces réponses.
Et moi qui croyais tout savoir sur tout... Au moins maintenant je peux affirmer que je ne sais pas, mais ça au moins, je l'sais.

Bon week-end à vous. Cordialement, Gizmo.

[Invité]

Bonjour,

J'ai regardé les documents que vous m'avez donné + d'autres aussi sur le net.
Pouvez-vous me dire si c'est bien ça svp si ça ne gêne pas ?

Alors voilà je commence :

=> étant donné que les display lists ne permettent pas de modifier leur "intérieur", alors je suppose qu'elles sont fait pour créer des objets de décor dans un jeu vidéo : objets fixe : c.à.d qui ne changent jamais ?

=> et par conséquent les vertex array sont utilisés pour dessiner Donkey Kong par exemple ? Car les vertices de DK changeront sans cesse de position car il bouge ?

=> enfin pas mal de tutos montrent que l'on peut utiliser entre autres la fonction glVertex3f() à k'intérieur d'une display list.
Mais on peut aussi utiliser la méthode des Vertex Array à l'intérieur d'une display list ? Est-ce valable aussi ?

En vous remerciant d'avance. Je vous souhaite une bonne journée.
Cordialement, Gizmo.

[LittleWhite]

=> étant donné que les display lists ne permettent pas de modifier leur "intérieur", alors je suppose qu'elles sont fait pour créer des objets de décor dans un jeu vidéo : objets fixe : c.à.d qui ne changent jamais ?

Exactement

=> et par conséquent les vertex array sont utilisés pour dessiner Donkey Kong par exemple ? Car les vertices de DK changeront sans cesse de position car il bouge ?

Disons, pour le donkey kong en 3D, oui

=> enfin pas mal de tutos montrent que l'on peut utiliser entre autres la fonction glVertex3f() à l'intérieur d'une display list.
Mais on peut aussi utiliser la méthode des Vertex Array à l'intérieur d'une display list ? Est-ce valable aussi ?

Non, je ne crois pas, de toute façon, cela n'aurait pas de sens


Notez qu'il y a deux types de buffers (VBO). Un qui est statique, pour les éléments de décors fixes. Un qui est dynamique pour les personnages et autres.

[Invité]

D'accord merci beaucoup.

Quand vous dites qu'on utilise les vertex array pour DK en 3D : et pour la 2D c'est différent ?
Même si je ne pense pas me servir de 2D pour le moment la réponse m'intéresse quand même.

Et aussi une dernière question qui me trotte dans la tête : est-ce que l'on peut utiliser les display list pour par exemple faire une plate-forme à piques mouvante : qui monte et qui descend mais de manière périodique ?
Ca marche aussi avec les display list je suppose ?
(je sais que la question est pointue mais bon...)

[LittleWhite]

Quand vous dites qu'on utilise les vertex array pour DK en 3D : et pour la 2D c'est différent ?
Même si je ne pense pas me servir de 2D pour le moment la réponse m'intéresse quand même.

La 2D, c'est souvent juste des spritesheet (feuilles de sprites).

Et aussi une dernière question qui me trotte dans la tête : est-ce que l'on peut utiliser les display list pour par exemple faire une plate-forme à piques mouvante : qui monte et qui descend mais de manière périodique ?
Ca marche aussi avec les display list je suppose ?
(je sais que la question est pointue mais bon...)

Oui on peut.

[gbdivers]

Et aussi une dernière question qui me trotte dans la tête : est-ce que l'on peut utiliser les display list pour par exemple faire une plate-forme à piques mouvante : qui monte et qui descend mais de manière périodique ?
Ca marche aussi avec les display list je suppose ?
(je sais que la question est pointue mais bon...)

Oui on peut... mais est-ce que cela a un sens ?
La DL permet d'enregistrer une liste de commande pour ne pas avoir à la renvoyer plusieurs fois. A partir du moment où tu modifies ta DL à chaque update, l'intérêt des DL est nul (ou alors il faut jouer avec les matrices de transformation)

[LittleWhite]

Oui on peut... mais est-ce que cela a un sens ?
La DL permet d'enregistrer une liste de commande pour ne pas avoir à la renvoyer plusieurs fois. A partir du moment où tu modifies ta DL à chaque update, l'intérêt des DL est nul (ou alors il faut jouer avec les matrices de transformation)

Attendez, moi je ne l'ai pas compris dans ce sens.
Je veux dire, si on a un cube, enregistrer dans une liste d'affichage, on peut le déplacer facilement avec un glTranslate() sans perdre de performance, ni détruire l'avantage de la liste d'affichage.

Par contre, si il y a modification de la géométrie, alors oui, il y aura une nécessité de recréer la liste et donc, perte de performances.

[gbdivers]

glTransform applique une matrice de transformation donc on est d'accord

[Invité]

La 2D, c'est souvent juste des spritesheet (feuilles de sprites).

Personnellement je préfère le Coca-Cola : et en bouteille, pas dans une feuille.

Je ne cherche pas à créer de dispute.
Pardonnez-moi peut-être est-ce moi qui ai mal expliqué.

Donc je reprends pour ce qui était de la display list avec la plate-forme à piques mouvante (on peut aussi remplacer les piques par des fourmis tueuses si vous voulez ) :

=> le but final est de créer une plate-forme à piques mouvante qui bouge du haut vers le bas toutes les 2s et qui se relève aussi toutes les 2s.

=> en fait j'aurais aimé savoir si on peu programmer le mouvement de cette plate-forme à piques à l'intérieur même de la display list ?
Lui dire de bouger, du moment que c'est périodique ? (peut-être qu'après ça fait beaucoup en mémoire et donc ça craint un peu de faire comme ceci...)

Je sais ma question peut vous paraître un peu bizaroïde...
Pour ce problème peut-être que je devrais utiliser tout simplement un vertex array et puis terminé... Non ?

[screetch]

en general on utilise plus que des VBO
les VBO statiques peuvent aussi être animés; donkey kong en 3D a probablement un VBO statique, parce que ses vertex ne changent pas de frame a frame. Ensuite chaque vertex est simplement animé dans un "vertex shader"

les VBO dynamiques sont utilisés pour des choses différentes, qui peuvent apparaître ou disparaître;
par exemple, un systeme d'interface utilisateur ou on a des fenêtres qui s'affichent et se cachent (par exemple un inventaire)
ou bien le système de végétation; en effet, si on a de la végétation dans un jeu, il y a plusieurs facons de faire; la première est d'avoir un mesh et de le repliquer plusieurs fois (en fait pour avoir de la variation il faut plusieurs mesh); on affiche la vegetation comme des mesh statiques
mais on en a beaucoup beaucoup et donc ca coute cher;

option 2, on place la vegetation dans un VBO dynamique; pas de jaloux, tous les objets dedans; quand on sort d'une zone, on vide une partie du VBO et on en charge une autre, ainsi on rend toute la vegetation en un seul batch.

les display list on a oublié ca il y a un moment deja.

[Invité]

Bonjour,

Vous savez quoi ? Je ne me suis pas encore décidé pour le choix VA+DL/VBO.
Ce que je vais faire : je vais finir le programme en remplaçant les glVertex3d() par un tableau float tableau[machin chose]{truc muche bidule}; : de toute façon VA ou VBO ont un point commun : ce sont des tableaux.

Après je mettrai le programme à votre disposition : ça sera pour moi une façon de vous remercier de toutes les informations que vous m'avez données.

On fait comme ça ?

Si oui alors je vous souhaite à toutes et à tous une excelllente journée.
Cordialement, Gizmo.

[Invité]

Bonjour,

Alors voilà comme promis je vous livre le programme que j'ai programmé avec Qt et qui permet donc de convertir un fichier au format obj en instructions OpenGL.
Disponible seulement sur Windows (j'ai des difficultés à installer Linux et je m'excuse d'avance envers les Linuxien(ne)s). Si vous êtes sur Linux il suffit de recompiler avec Qt Creator.
Le voici donc.
Avec le source ici.

Description du programme :

=> vous charger un fichier *.obj
=> le fichier *.txt généré se situe dans le même dossier que obgl.exe

Ce que j'aimerais c'est que vous le testiez si possible.

Pour l'instant le programme ne gère que les vertices des fichiers *.obj.
La gestion du reste et des fichiers *.mtl est prévu à l'avenir, pour peu que ces derniers ne soient pas trop compliqués à programmer

Voilà merci encore pour toutes les infos que vous m'avez données.
Passez une bonne journée.

[LittleWhite]

Lorsque vous donnez un .exe, il y a souvent des dépendaces (sous la forme de .DLL). Donc, lorsque vous distribuez un programme, il faut faire une archive (.zip / .rar ou autre) avec le .exe et les .dll (et même les fichiers de ressources, lorsqu'il y en a).
J'ai pris un fichier .obj que j'utilisais pour un TP, ça a crasher votre programme

# cube.obj
#

g cube

v 0.0 0.0 0.0
v 0.0 0.0 1.0
v 0.0 1.0 0.0
v 0.0 1.0 1.0
v 1.0 0.0 0.0
v 1.0 0.0 1.0
v 1.0 1.0 0.0
v 1.0 1.0 1.0

vn 0.0 0.0 1.0
vn 0.0 0.0 -1.0
vn 0.0 1.0 0.0
vn 0.0 -1.0 0.0
vn 1.0 0.0 0.0
vn -1.0 0.0 0.0

f 1/0/2 7/0/2 5/0/2
f 1/0/2 3/0/2 7/0/2
f 1/0/6 4/0/6 3/0/6
f 1/0/6 2/0/6 4/0/6
f 3/0/3 8/0/3 7/0/3
f 3/0/3 4/0/3 8/0/3
f 5/0/5 7/0/5 8/0/5
f 5/0/5 8/0/5 6/0/5
f 1/0/4 5/0/4 6/0/4
f 1/0/4 6/0/4 2/0/4
f 2/0/1 6/0/1 8/0/1
f 2/0/1 8/0/1 4/0/1

Avec un autre fichier (bigguy.obj (ça se trouve sur internet)), le programme ne fait rien O_o

[Kannagi]

Les fichiers .mtl est très facile a lire et a programmer.
Pour le code source je pense que tous le monde ici sait lire le .obj vu sa simplicité.

Je n'ai pas compilé le programme mais je l'ai regardé ,j'aurai pensé que tu aurait programmé un objet ayant comme fonction , charger/afficher (et pas mélangé avec le fenêtrage).
Apres je n'ai vu aucune fonction opengl , j'imagine que le programme n'affiche rien ?