[News] OpenGL Samples Pack 4.2.0.2

**r0ots** · 18/05/2011, 10h22

OpenGL Samples Pack 4.2.0.2
10 nouveaux exemples pour OpenGL 4.2

Sortie de OpenGL Samples Pack 4.2.0.2, qui présente le derniers ajouts d'OpenGL 4.2 et contient 10 exemples de code. L'auteur a également fait une review des nouvelles fonctionnalités dans ce document (en anglais).

Téléchargez OpenGL Samples Pack 4.2.0.2

Source

OpenGL Samples Pack 4.1.6.0
100 exemples OpenGL 2.1 à 4.1 pour promouvoir les nouvelles fonctionnalités d'OpenGL

Ce pack d'exemples permet de promouvoir les nouvelles fonctionnalités d'OpenGL et permet aux développeurs d'avoir une source d'information complémentaire à la spécification officielle.

Bien que les exemples soient le plus simple possible, ce pack d'exemples n'est pas destiné aux débutants. Il est adressé aux développeurs déjà familiers avec OpenGL qui souhaitent se mettre à jour ou qui souhaitent découvrir comment est implémentée telle ou telle fonctionnalité.

Cette version n'est pas majeure, mais permettra surtout de faire découvrir cette excellente source d'information à certains d'entre nous.

Ces exemples utilisent FreeGLUT pour créer une fenêtre et un contexte OpenGL, GLEW pour charger les extensions, GLM comme librairie mathématique et GLI pour charger les images.

Téléchargez OpenGL Samples Pack 4.1.6.0

Source : Le site du projet

**gbdivers** · 18/05/2011, 12h35

Idée intéressante... mais :

- pas réussit à le compiler (ne trouve pas FreeGlutConfig.cmake alors que j'ai déjà installé FreeGlut et qu'il fonctionne)
- pas de screenshots (dommage pour des démos OpenGL)
- pas de fichier d'explication pour l'installation/compilation
- OS compatible non précisé
- pas de binaires proposés au téléchargement

**vintz72** · 18/05/2011, 13h49

Ca ne risque pas trop d'être compatible Mac Os X : Apple n'a - toujours - pas daigné implémenté les version 3.x et suivantes dans son OS (pourtant le meilleur du monde selon eux...)
Gageons que cela évoluera avec Lion !

**gbdivers** · 18/05/2011, 14h21

Envoyé par vintz72

Ca ne risque pas trop d'être compatible Mac Os X : Apple n'a - toujours - pas daigné implémenté les version 3.x et suivantes dans son OS (pourtant le meilleur du monde selon eux...)
Gageons que cela évoluera avec Lion !

Hum... NVIDIA fournit les derniers drivers pour MacOS (http://developer.nvidia.com/cuda-toolkit-40#MacOS). Par contre, je n'ai pas trouvé une version MacOS de CATALYST chez AMD. Et il n'est pas utile d'être négatif ("daigné", ironie)

**pyros** · 18/05/2011, 14h33

D'accord avec gbdivers. Compil sans problème chez moi mais aucune explication sur la feature implémenté, aucun commentaire dans le code.

**vingt sens** · 18/05/2011, 17h08

idem que gdriver: problème à la compilation et pas d'indication sur la méthode d'installation.

je suis sur kubuntu, je ne connais pas 'cmake' mais j'ai supposé qu'il fallait enttré 'cmake CMakeList.txt', il fait quelque chose et me sort 'ERROR: FREEGLUT not found' or il est bien installé.

j'ai ensuite recherché le fichier FindFREEGLUT.cmake -> il existe bien (external/freeglut.../util) mais avec un problème minuscule/majuscule. Correction faites, cmake fonctionne, j'obtiens un Makefile et je fait make. ici, j'ai un problème à cause de __stdcall (une convention Microsoft). j'ai pas le temps de regarder plus loin.

des screenshots auraient permis de se faire une idée des capacités des démos sans téléchargé ni compiler quoi que ce soit (et être bloqué par des problèmes de configuration). Ainsi connaitre immédiatement les apports que pourraient apporté de telles techniques. un document qui indique le but de chaque exemple et des commentaires placé aux bon endroits permettraient d'intéressé plus de monde.

Dommage.

**r0ots** · 18/05/2011, 17h11

Effectivement on peut voir sur les tickets ouverts du projet sourceforge que la personne en charge recherche des personnes pour s'occuper de la partie Mac et Linux.
On peut donc supposer que ces exemples ne sont compatible que Windows en l'état.

**gbdivers** · 18/05/2011, 23h02

Désolé r0ots d'avoir été aussi "direct". Mais si je suis aussi critique, c'est parce que c'est intéressant comme projet. Mais c'est frustrant aussi du coup.

C'est une réalité dans la programmation (et bien d'autres domaines) : il ne suffit pas de donner du code génial, il faut aussi faire attention à ce qui va autour (la documentation, des exemples, des screenshots, des instructions de compilation, etc.) Ce n'est pas des activités annexes, ça prend du temps, mais ça évite que le projet soit rejeté avant même d'avoir pu être testé.

J'ai essayé sous windows mais comme je n'ai jamais utilisé cmake dessus, je n'ai pas réussit. Je verrai pour compiler sous linux mais je ne suis pas un spécialiste de cmake donc j'aurais du mal à adapter. Et je ne vais pas passer 3 heures dessus sans savoir ce que ça m'apportera.

Il faudrait au moins faire des screenshots de chaque application (ce n'est pas très long)

**LittleWhite** · 19/05/2011, 02h14

Pour le __stdcall, il est assez étonnant d'en voir. Bien sur, mon système aussi eu des problèmes dessus (GNU/Linux).

Et une fois qu'il est enlevé, on se prend un joli:

/usr/bin/ld: cannot find -lfreeglut_static
collect2: ld returned 1 exit status

Pour le __stdcall, j'étais étonné d'en entendre parler, sachant que les dernier fichier d'entêtes donnés par Khronos (depuis une année maintenant) était vraiment multiplateforme (notamment, sur la spécification des types) -> http://www.khronos.org/registry/egl/.../khrplatform.h

Ok, il fallait chercher le truc ... mais cela aide de connaitre.

Sinon, j'espère voir ce pack de sample fonctionner car il est théoriquement super intéressant.

**r0ots** · 19/05/2011, 09h47

C'est rien gbdivers, surtout que ce n'est que ce n'est pas mon travail, mais juste une source d'information que j'essai de partager.

Effectivement c'est assez frustrant de devoir fouiller dans le code pour savoir ce que fait tel ou tel exemple. Et le plus embêtant selon moi c'est que la personne en charge du projet ne lira surement pas les critiques constructives que l'on peut voir ici.

Pensez-vous présomptueux le fait de contacter la personne pour lui faire lire les remarques écrites ici?

**LittleWhite** · 19/05/2011, 09h59

Envoyé par r0ots

Pensez-vous présomptueux le fait de contacter la personne pour lui faire lire les remarques écrites ici?

Absolument pas.
Il faut lui signaler les remarques. En théorie, le créateur aime son projet et voudra le rendre plus beau encore

Donc il acceptera les remarques et fera en sorte de modifier le programme.
Mais il y a aussi des cas, où l'on peut tomber sur un gars qui dit: "Moi GNU/Linux, j'en ai rien à faire, y a presque personne qui utilise ce système ... et le portage me pose trop de problème".
Enfin bref ... il y a de tout, mais le jeux en vaut le coup

Sinon, à la place du courriel, c'est une série de bugs que l'on peut rajouter dans la page de projet (qui doit contenir un bugtracker).

EDIT: Si par courriel, vous pouvez même lui montrer cette page (même s'il n'est pas francophone), dire que vous avez parler de son projet et tout cela. Il sera au moins content que l'on parle de son projet.

**vingt sens** · 19/05/2011, 10h42

EDIT: Si par courriel, vous pouvez même lui montrer cette page (même s'il n'est pas francophone), dire que vous avez parler de son projet et tout cela. Il sera au moins content que l'on parle de son projet.

Je pense qu'il est francophone: le nom de son site contient le mot 'truc' et les premiers posts sont en français.

**gbdivers** · 19/05/2011, 17h28

Bon, j'ai réussit à compiler le projet...

Voila la procédure que j'ai suivi :
- installer manuellement glew 1.6.0 (sur ubuntu, la version dans les paquets est la 1.5.x)
- dans ./CMakeLists.cmake, commenter les lignes 40 et 41 (pour ne pas utiliser les versions de freeglut et glew fournit, qui sont compilé sous windows) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#addExternalPackageGTC("GLEW" "glew-1.6.0")
#addExternalPackageGTC("FREEGLUT" "freeglut-2.6.0")

- dans ./samples/CMakeLists.cmake, ajouter les 2 lignes suivantes à la ligne 13 (pour linker glut et glew dans chaque binaire) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
target_link_libraries(${SAMPLE_NAME} GLEW)
target_link_libraries(${SAMPLE_NAME} glut)

- dans ./common/glf/glf.hpp, ajouter la ligne suivante à la ligne 18 (pour définir la fonction getProcAddress) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#	define glfGetProcAddress glutGetProcAddress

- dans ./common/glf/glf.inl, supprimer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

__stdcall

- copier le dossier ./data dans ./build/data

Ensuite, dans . tapez

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
cmake .
make

Et ça compile !

Par contre, l’exécution pose des problèmes :
- 2 cores tournant à plus de 60%
- que opengl 2.x et 3.0 qui fonctionnent, j'ai une erreur de segmentation pour opengl > 3.0 (NVIDIA GTX 460 + drivers 470.41.06 donc normalement je devrais avoir opengl 4.1 pris en charge)

**Groove** · 19/05/2011, 23h06

Il y a un bug entre les drivers de NVIDIA et GLEW qui empeche GLEW de recupérer les adresses functions OpenGL

Un workaround est de remplacer:
glutInitContextProfile(GLUT_CORE_PROFILE);
Par:
glutInitContextProfile(GLUT_COMPATIBILITY_PROFILE);

L'origine du prochain c'est que NVIDIA ne supporte pas le core profile d'OpenGL, seulement le compatibility profile a la difference de tous les autres IVH pour des raisons commercialles.

Plusieurs patchs ont été proposé sur GLEW sans pour autant avoir été accepté.

La seule solution robuste et cross-platform serait donc de se passer de GLEW et de tout charger a la main ou avec une autre bibliotheque...

**gbdivers** · 20/05/2011, 09h52

Envoyé par Groove

Il y a un bug entre les drivers de NVIDIA et GLEW qui empeche GLEW de recupérer les adresses functions OpenGL

Un workaround est de remplacer:
glutInitContextProfile(GLUT_CORE_PROFILE);
Par:
glutInitContextProfile(GLUT_COMPATIBILITY_PROFILE);

L'origine du prochain c'est que NVIDIA ne supporte pas le core profile d'OpenGL, seulement le compatibility profile a la difference de tous les autres IVH pour des raisons commercialles.

Plusieurs patchs ont été proposé sur GLEW sans pour autant avoir été accepté.

La seule solution robuste et cross-platform serait donc de se passer de GLEW et de tout charger a la main ou avec une autre bibliotheque...

Je n'utilisais pas GLEW et ça va continuer suite à ton message

Je vais voir pour corriger cela dans le code

**gbdivers** · 20/05/2011, 13h03

Bon, en fait le problème venait du fait que dans glf.inl, le code pour charger les fonctions était protégé par un ifdef :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#ifdef WIN32 // ligne 53
		glewInit();
		glGetError();
 
		// Load OpenGL 3.0 functions
		glBindBufferBase = (PFNGLBINDBUFFERBASEPROC)glfGetProcAddress("glBindBufferBase");
...
		glBufferAddressRangeNV = (PFNGLBUFFERADDRESSRANGENVPROC)glfGetProcAddress("glBufferAddressRangeNV");
#endif //WIN32 // ligne 304

Donc en commentant ces 2 lignes (53 et 304), les fonctions sont correctement chargées et disponibles

Maintenant, la plupart des démos fonctionne, même les version 410. Par contre, j'ai des erreur sur certaine démo (peut être des fonctionnalités non prises en charge, j'ai vu que certain programme on l'air spécifique à amd ou nvidia).

De plus, beaucoup de programme présente juste un carré orange ou l'image d'un canard... pas très fun, surtout quand on ne sait pas très bien la fonctionnalité qui est présentée.

Bref, peut être intéressant quand on connait une fonctionnalité et que l'on souhaite avoir un exemple d'implémentation mais pas pour découvrir les nouvelles fonctionnalités

Quelqu'un a envoyé un mail au développeur ?

**r0ots** · 20/05/2011, 13h52

Oui je lui ai envoyé un mail. Et d'ailleurs je me demande si Groove (3 posts plus haut) ne serait pas cette personne, vu sa signature.

**Groove** · 20/05/2011, 17h51

Envoyé par gbdivers

De plus, beaucoup de programme présente juste un carré orange ou l'image d'un canard... pas très fun, surtout quand on ne sait pas très bien la fonctionnalité qui est présentée.

Oui, ces samples s'adressent avant tout a ceux qui connaissent deja OpenGL, qui lisent les nouvelles specifications et aboutissent a "oki, et en pratique ca donne quoi?" Ces samples sont la pratique et represente la base de l'utilisation d'OpenGL et non des techniques de rendus. Ce n'est donc pas un tutorial et ils ne s'adressent pas non plus au plus grand nombre. Ces samples offrent un commentaire avec du code aux specifications qui sont encore beaucoup moins accessible et pour de nombreuses fonctionnalités, il n'y a absolument aucune autre literature mais j'espere qu'ils permettent a d'autres developpeurs d'ecrire de bons tutoriaux. Dans l'imediat, ils servent a corrigé les implementations d'OpenGL et a clarifier les futures specifications ce qui n'est deja pas si mal.

Un bon tutorial que je recommande: http://www.arcsynthesis.org/gltut/
Tres précis car redigé par l'un des membres de la communauté des plus talentueux dans le domaine.

Sinon merci pour infos pour le build Linux, j'ai effectué quelques changements.

**gbdivers** · 21/05/2011, 13h05

Sinon merci pour infos pour le build Linux, j'ai effectué quelques changements.

Cool.

En tout cas, très bon boulot.

Je dois avouer que je ne suis pas encore à ce niveau. J'en suis encore à découvrir les techniques de rendu et pas à l'optimisation de l'implémentation (et donc je ne suis pas encore les nouvelles spécifications ; je n'ai pas encore testé OpenGL 4.x pour le moment)

**gbdivers** · 24/08/2011, 23h25

OpenGL Samples Pack 4.2.0.2
10 nouveaux exemples pour OpenGL 4.2

Sortie de OpenGL Samples Pack 4.2.0.2, qui présente le derniers ajouts d'OpenGL 4.2 et contient 10 exemples de code. L'auteur a également fait une review des nouvelles fonctionnalités dans ce document (en anglais).

Téléchargez OpenGL Samples Pack 4.2.0.2

Source

[News] OpenGL Samples Pack 4.2.0.2

OpenGL

Discussions similaires

Partager

Partager