Author: JeGX

Geek Life, HackLAB / JeGX

De Lausanne à Paris

Comment
[French] Me voilà de retour en France pour une période indéterminée. En gros j’ai quitté ça:

pour ça:

Quelque chose me dit que ma vie parisienne ne sera pas très longue…

Mais ne désespérons pas… il y quand même de belles choses à Paris. Je vais donc en profiter pour ajouter une nouvelle catégorie à ce blog -: Paris -: et poster régulièrement des photos de différents endroits de Panam… Pour ce premier billet sur Paris voilà quelques photos sans ordre particulier:

Continue reading »

Tools de JeGX

FurMark Fume les Cartes Graphiques

Comment

Je suis tombé sur ce fil de discussion chez [H]ard|Forum où l’on peut lire ceci:

“That fur demo is known to get cards the hottest, it is also known for smoking cards as well (it was the last thing run for a number of people on the extremesystems forums).”

En gros ça dit que le FurMark est connnu pour faire le plus chauffer les cartes mais qu’il aussi connu pour les faire fumer et c’est souvent la dernière chose que certains utilisateurs aient vu! Je savais que le FurMark était bon pour faire chauffer les cartes mais je ne savais pas qu’il était aussi capable de les détruire. Je sens que cet été va être chaud pour certaines cartes graphiques…

OpenGL

OpenGL Geometry Instancing

10 Comments

This article has been updated with new demos and new GI technique. Read the complete article here: OpenGL Geometry Instancing: GeForce GTX 480 vs Radeon HD 5870.

[French] Voici une petite démo qui utilise les techniques d’instancing (instancing simple, pseudo-instancing et geometry instancing(ou GI)) pour effectuer le rendu d’un anneau composé de 10000 petites sphères.
La démo est livrée en 5 versions:

  • chaque sphère est composée de 1800 triangles (18 millions de triangles pour l’anneau entier)
  • chaque sphère est composée de 800 triangles (8 millions de triangles pour l’anneau entier)
  • chaque sphère est composée de 200 triangles (2 millions de triangles pour l’anneau entier)
  • chaque sphère est composée de 72 triangles (720000 triangles pour l’anneau entier)
  • chaque sphère est composée de 18 triangles (180000 triangles pour l’anneau entier)

J’ai ajouté au dernier moment un extra: une version avec 20000 instances de 5000 triangles chacune soit 100 millions de polygones (fichier Demo_Instancing_100MTriangles_20kInstances.exe).
[/French] [English] This demo uses instancing techniques (simple instancing, pseudo-instancing and geometry instancing(or GI)) to render a ring made of 10,000 small spheres. The demo is delivered in 5 versions:

  • each sphere is made of 1,800 triangles (18 millions triangles for the whole ring)
  • each sphere is made of 800 triangles (8 millions triangles for the whole ring)
  • each sphere is made of 200 triangles (2 millions triangles for the whole ring)
  • each sphere is made of 72 triangles (720,000 triangles for the whole ring)
  • each sphere is made of 18 triangles (180,000 triangles for the whole ring)

I added in the last moment a bonus: a 20,000 instances version, each instance made of 5,000 triangles. We get the monstruous count of 100 millions triangles (file Demo_Instancing_100MTriangles_20kInstances.exe).
[/English]





DOWNLOAD

[French] Il y a plusieurs techniques d’instancing qui sont utilisées et chaque technique est accessible avec une des touches F1 à F6.

  • F1: instancing simple avec camera frustum culling: il y a une seule source de géométrie (un mesh) et elle est rendu pour chaque instance. Le calcul de la matrice de transformation est fait sur le CPU ainsi que le test de clipping avec la camera. Le rendu OpenGL utilise la fonction glDrawElements().
  • F2: instancing simple SANS camera frustum culling: il y a une seule source de géométrie (un mesh) et elle est rendu pour chaque instance. Le calcul de la matrice de transformation est fait sur le CPU mais il n’y a plus de test de clipping avec la camera. Le rendu OpenGL utilise la fonction glDrawElements().
  • F3: pseudo-instancing lent: il y a une seule source de géométrie (un mesh) et elle est rendu pour chaque instance. Le calcul de la matrice de transformation est maintenant effectué sur le GPU. Le passage des paramètres pour chaque instance se fait avec des variables uniformes. Il n’y a pas de test de clipping avec la camera. Le rendu OpenGL utilise la fonction glDrawElements().
  • F4: pseudo-instancing rapide: il y a une seule source de géométrie (un mesh) et elle est rendu pour chaque instance. Le calcul de la matrice de transformation est maintenant effectué sur le GPU. Le passage des paramètres pour chaque instance se fait avec des attributs de vertex persistants (comme les coordonnées de textures ou la couleur). C’est cette technique qui
    a été mise en avant par NVIDIA avec son whitepaper: GLSL Pseudo-Instancing. Il n’y a pas de test de clipping avec la camera. Le rendu OpenGL utilise la fonction glDrawElements().
  • F5: Geometry Instancing: c’est le vrai instancing hardware. Il y a une seule source de géométrie (un mesh) et le rendu se fait par lots (ou batchs) de 400 instances par draw call. Le rendu complet de l’anneau ne nécessite que 25 draw-calls au lieu de 10000. Le calcul de la matrice de transformation est effectué sur le GPU. Le passage des paramètres pour chaque batch se fait avec des tableaux de variables uniformes. Il n’y a pas de test de clipping avec la camera. Le rendu OpenGL utilise la fonction glDrawElementsInstancedEXT(). Actuellement, seules les cartes NVIDIA GeForce 8 (et sup.) supportent cette fonction.
  • F6: Geometry Instancing avec attributs de vertex persistants: c’est le geometry instancing hardware couplé avec le passage des paramètres par les attributs de vertex persistants. Mais le nombre d’attributs de vertex persistants est très limité. Au maximum j’ai reussi à rendre 4 instances par draw-call. Mais étrangement, 2 instances par draw-call donne de meilleurs résultats. Dans ce cas, le rendu complet de l’anneau nécessite que 5000 draw-calls au lieu des 10000. Le calcul de la matrice de transformation est effectué sur le GPU. Il n’y a pas de test de clipping avec la camera. Le rendu OpenGL utilise la fonction glDrawElementsInstancedEXT(). Actuellement, seules les cartes NVIDIA GeForce 8 (et sup.) supportent cette fonction.
[/French] [English] Several instancing techniques are used and you can select them with F1 to F6 keys.

  • F1: simple instancing with camera frustum culling: there is one source for geometry (a mesh) and it’s rendered for each instance. The tranformation matrix calculation is done on the CPU as well as the camera frustum test. OpenGL rendering uses the glDrawElements() function.
  • F2: simple instancing without camera frustum culling: there is one source for geometry (a mesh) and it’s rendered for each instance. The tranformation matrix calculation is done on the CPU but there is no longer camera frustum test. OpenGL rendering uses the glDrawElements() function.
  • F3: slow pseudo-instancing: there is one source for geometry (a mesh) and it’s rendered for each instance. Now the tranformation matrix calculation is done on the GPU and per-instance data are passed via uniform variables. There is no camera frustum test. OpenGL rendering uses the glDrawElements() function.
  • F4: pseudo-instancing: there is one source for geometry (a mesh) and it’s rendered for each instance. The tranformation matrix calculation is done on the GPU and per-instance data are passed via persistent vertex attributes (like texture coordinates or color). This technique has been shown by NVIDIA in the following whitepaper: GLSL Pseudo-Instancing. There is no camera frustum test. OpenGL rendering uses the glDrawElements() function.
  • F5: geometry instancing: it’s the real hardware instancing. There is one source for geometry (a mesh) and rendering is done by batchs of 400 instances per draw-call. The whole rendering of the ring requires 25 draw-calls instead of 10,000. The tranformation matrix calculation is done on the GPU and per-batch data is passed via uniform arrays. There is no camera frustum test. OpenGL rendering uses the glDrawElementsInstancedEXT() function. Currently, only NVIDIA GeForce 8 (and higher) support this function.
  • F6: geometry instancing with persistant vertex attributes: it’s the hardware instancing coupled with the transmission of parameters is done via the persistent vertex attributes. But the number of persistent vertex attributes is very limited. The best I did is to render 4 instances per draw-call. But oddly, I got the best results with 2 instances per draw-call. In that case, the rendering of whole ring requires 5000 draw-calls. The tranformation matrix calculation is done on the GPU and per-batch data is passed via uniform arrays. There is no camera frustum test. OpenGL rendering uses the glDrawElementsInstancedEXT() function. Currently, only NVIDIA GeForce 8 (and higher) support this function.

Ok now, let’s see some results with a NVIDIA GeForce 8800 GTX and an ATI Radeon HD 3870. Both cards have been tested with an AMD 64 3800+.
[/English]

18 millions triangles – 1800 tri/instance

NVIDIA GeForce 8800 GTX – Forceware 169.38 XP32

  • F1: 223MTris/sec – 13FPS
  • F2: 223MTris/sec – 13FPS
  • F3: 223MTris/sec – 13FPS
  • F4: 223MTris/sec – 13FPS
  • F5: 223MTris/sec – 13FPS
  • F6: 171MTris/sec – 10FPS

ATI Radeon HD 3870 – Catalyst 8.2 XP32

  • F1: 429MTris/sec – 25FPS
  • F2: 463MTris/sec – 27FPS
  • F3: 446MTris/sec – 26FPS
  • F4: 274MTris/sec – 16FPS
  • F5: mode not available
  • F6: mode not available

8 millions de triangles – 800 tri/instance

NVIDIA GeForce 8800 GTX – Forceware 169.38 XP32

  • F1: 190MTri/sec – 25FPS
  • F2: 190MTri/sec – 25FPS
  • F3: 205MTri/sec – 27FPS
  • F4: 213MTri/sec – 28FPS
  • F5: 205MTri/sec – 27FPS
  • F6: 152MTri/sec – 20FPS

ATI Radeon HD 3870 – Catalyst 8.2 XP32

  • F1: 251MTris/sec – 33FPS
  • F2: 236MTris/sec – 31FPS
  • F3: 297MTris/sec – 39FPS
  • F4: 251MTris/sec – 33FPS
  • F5: mode not available
  • F6: mode not available

2 millions de triangles – 200 tri/instance

NVIDIA GeForce 8800 GTX – Forceware 169.38 XP32

  • F1: 47MTri/sec – 25FPS
  • F2: 47MTri/sec – 25FPS
  • F3: 57MTri/sec – 30FPS
  • F4: 131MTri/sec – 69FPS
  • F5: 167MTri/sec – 88FPS
  • F6: 148MTri/sec – 78FPS

ATI Radeon HD 3870 – Catalyst 8.2 XP32

  • F1: 47MTris/sec – 25FPS
  • F2: 59MTris/sec – 31FPS
  • F3: 74MTris/sec – 39FPS
  • F4: 112MTris/sec – 59FPS
  • F5: mode not available
  • F6: mode not available

720,000 triangles – 72 tri/instance

NVIDIA GeForce 8800 GTX – Forceware 169.38 XP32

  • F1: 17MTri/sec – 25FPS
  • F2: 17MTri/sec – 25FPS
  • F3: 20MTri/sec – 30FPS
  • F4: 47MTri/sec – 69FPS
  • F5: 60MTri/sec – 88FPS
  • F6: 53MTri/sec – 78FPS

ATI Radeon HD 3870 – Catalyst 8.2 XP32

  • F1: 17MTris/sec – 25FPS
  • F2: 21MTris/sec – 31FPS
  • F3: 26MTris/sec – 39FPS
  • F4: 40MTris/sec – 59FPS
  • F5: mode not available
  • F6: mode not available

180000 triangles – 18 tri/instance

NVIDIA GeForce 8800 GTX – Forceware 169.38 XP32

  • F1: 4MTri/sec – 25FPS
  • F2: 4MTri/sec – 25FPS
  • F3: 5MTri/sec – 30FPS
  • F4: 11MTri/sec – 69FPS
  • F5: 15MTri/sec – 89FPS
  • F6: 13MTri/sec – 79FPS

ATI Radeon HD 3870 – Catalyst 8.2 XP32

  • F1: 4MTris/sec – 25FPS
  • F2: 5MTris/sec – 31FPS
  • F3: 6MTris/sec – 39FPS
  • F4: 10MTris/sec – 59FPS
  • F5: mode not available
  • F6: mode not available
[French] Analyse rapide des resultats:

  • nous comprenons maintenant pourquoi NVIDIA a appellé “Pseudo-Instancing” la technique utilisant les attributs persistants de vertex (key F4). La fonction glDrawElements() d’OpenGL est extremement rapide et optimisée et les attrubuts persistants de vertex nécessitent moins de traitement que les variables uniformes pour être passés au vertex shader. Les deux couplés ensemble donnent ce boost de performance.
  • le bénéfice du vrai hardware geometry instancing est principalement visible losqu’il y a peu de triangles par instance.
  • lorsqu’il y a beacoup de triangles par instance (1800), l’impémentation matérielle de glDrawElements() semble être plus efficace (près de deux fois!) sur le GPU RV670 que sur le G80.

Conclusion

Au vu des résultats, le hardware geometry instancing n’est pas la kill-feature que j’attendais. Je trouve cela très curieux car la différence entre 10000 render-calls avec glDrawElements et 25 render-calls avec glDrawElementsInstancedEXT n’est pas très importante. On dirait que la gestion de l’instancing (variable gl_InstanceID dans le vertex shader) fait perdre beaucoup de temps. Je trouve aussi dommage qu’ATI n’ait pas encore pris le temps d’implémenter le geomtry instancing dans les pilotes Catalyst. Je serais très curieux de tester le GI hardware avec un RV670.
[/French] [English] Quick results analysis:

  • we now understand why NVIDIA has called the technique using persistent vertex attributes “Pseudo-Instancing” (key F4). OpenGL glDrawElements() function is extremly fastand persistent vertex attributes require less overhead than uniforms to be passed to vertex shader. Both coupled together give this performance boost.
  • benefit of real hardware geometry instancing is mostly visible with few triangles per instance.
  • when there are many triangles per instance (1,800), the hardware implementation of glDrawElements() seems to be more efficient (twice!) on RV670 GPU than on G80.

Conclusion

From the results, hardware geometry instancing isn’t the kill-feature I expected. I find that very weird since the différence between 10000 render-calls with glDrawElements and 25 render-calls with glDrawElementsInstancedEXT is not verx important. Seems the instancing management (gl_InstanceID variable in the vertex shader) is a GPU-cycle eater!What a pity ATI hasn’t implemented yet geometry instancing in the Catalyst drivers. I’d be very curious to test hardware GI with a RV670.
[/English]

Tests et Reviews

Quick Review – GLC_Player: Viewer de Fichiers OBJ

3 Comments

Version testée: 1.02

GLC_Player est un viewer de fichier OBJ {Alias|Wavefront}, le format standard ascii de description des modèles 3D. Ce format est très simple dans sa structure et n’impose aucune contrainte quand à l’organisation des données. C’est finalement là que réside la grande difficulté à parser ce type de fichier. Je dois dire que GLC_Player remplit correctement son role de loader de fichiers OBJ.

GLC_Player propose une navigation de camera de type Virtual Trackball ce qui est très pratique pour manipuler l’objet et le regarder sous tous les angles. GLC_Player est livré avec quelques objets mais pour le lab infame il n’est pas question de prendre des objets qui sont tous certifiés GLC_Player loadable!

Je me suis donc rendu sur cette page et j’ai téléchargé le modèle de la Ferrari F40 Ce modèle est livré au format MAX. Ca tombe bien comme ça je peux le convertir en OBJ avec l’exporter OBJ de MAX.

Pour le test j’ai aussi utilisé HyperView3D afin de comparer les chargements.

– Ferrari F40 et GLC_Player:

– Ferrari F40 et HyperView3D:

Les tâches blanches bizarres sur le capot viennent des normales exportées par MAX qui ne sont pas correctes à ces endroits. Ce petit détail mis à part, on voit que GLC_Player a eu un petit problème pour charger les textures (logo Ferrari sur le capot) et ne semble pas prendre en compte la transparence des matériaux (pare-brise et phares).

L’autre détail qui peut poser des problèmes pour une analyse plus fine des modèles 3D est la gestion des meshes. GLC_Player charge le fichier OBJ en un seul gros mesh alors que le modèle comporte 36 meshes distincts.

Conclusion: Pour rapidement visualiser des fichiers OBJ, je dirais que GLC_Player est parfait. Son coté multi-plateforme le rend disponible sous Windows et sous Linux. Il fait desormais partie de ma graphics toolbox à coté d’HyperView3D. Mais si vous avez besoin d’analyser un modèle 3D pour s’en servir dans une application 3d temps réel (Demoniak3D?) GLC_Player n’est pas pour le moment adapté.

Tested Version: 1.02

GLC_Player is an OBJ {Alias|Wavefront} object viewer. OBJ is the ascii standard file format to describe 3d objects. This format is very simple and do not force to follow a strict file structure. But this liberty has a price: the parsing is, in some case, quite difficult. And I must confess that GLC_Player does the job rather well.

GLC_Player offers a Virtual Trackball camera, which is very handy to handle the object and examine it under all possible angles. GLC_Player is delivered with some samples of OBJ files but for the infamous lab it’s out the question to use GLC_Player loadable certified objects!

So I jumped on that page and I downloaded the Ferrari F40 model. This model is provided in MAX format. This format is conveniant for my tests because I can convert it using MAX OB exporter.

For the test I also used HyperView3D in order to compare the way both tools load OBJ files.

– Ferrari F40 and GLC_Player:

– Ferrari F40 and HyperView3D:

The strange tasks in the hood come from the normals exported by MAX that are not correct at these places. Let’s forget this detail. We can see that GLC_Player has had a little problem to load some textures (the Ferrari logo on the hood) and does not take into account transparent materials (windshield and headlights).

The other thing that can prevent a detailed analyze of the 3d models is the way the meshes are managed. GLC_Player loads the OBJ file into a big and unique mesh even though the model has 36 distinct meshes.

Conclusion: if you need a tool to quickly view OBJ files, GLC_Player is that tool. What’s more GLC_Player is available for Windows and Linux. From now on, it lies in my graphics toolbox next to HyperView3D. But if you need a more accurate analysis of a 3d model in order to exploit it in a real time 3d application (Demoniak3D?) GLC_Player is not adapted yet.

Tests et Reviews

Quick Review – KeyBreeze

4 Comments

Si vous êtes un mordu du clavier comme moi, alors voilà un utilitaire vraiment pratique pour améliorer votre productivité. KeyBreeze est une ligne de commande flottante qui permet de lancer presque tout et n’importe quoi. Une fois configuré, c’est vraiment un outil extrêmement précieux pour le geek que vous êtes.

Homepage: www.keybreeze.com

Voici la description officielle issue du site de l’auteur:
“Keybreeze is a command-line program launcher for Windows. Launch programs and websites by pressing a hotkey on your keyboard and typing keywords. You can search the internet, shut down your computer, access a dictionary, record macros, and access other shortcuts from your keyboard.”

Ca fait maintenant quelques jours que je m’en sers et je l’ai adopté. KeyBreeze se lance en appuyant sur une hotkey. Par défaut c’est le point-virgule [;]. J’ai choisi la hotkey suivante: [Ctrl]+[Backspace] que je trouve beaucoup plus pratique. En tant que développeur C/C++ je me vois assez mal appuyer à chaque fois deux fois sur le point virgule pour termminer une instruction.

– Recherche sur Google d’oZone3D.Net: [Ctrl]+[Backspace] + s ozone3d.net + [ENTER]

– Lancement de la calculatrice de Windows: [Ctrl]+[Backspace] + cal + [ENTER] = environ 2 secondes…
– Lancement de la base de registre: [Ctrl]+[Backspace] + reg + [ENTER]

La FAQ vous propose un tableau avec la liste des keywords prédéfinis.

If you are a keyboard addict like me, then here is an utility really handy to boost your productivity. KeyBreeze is a floating command line that makes it possible to launch almost everything. Once configured, it’s a precious tool for the geek your are.

Homepage: www.keybreeze.com

Official description leeched from the author’s website:
“Keybreeze is a command-line program launcher for Windows. Launch programs and websites by pressing a hotkey on your keyboard and typing keywords. You can search the internet, shut down your computer, access a dictionary, record macros, and access other shortcuts from your keyboard.”

I use it for several days and I adopted it. You start KeyBreeze by pressing a hotkey. By default it’s the semi-colon [;]. I chose the following hotkey: [Ctrl]+[Backspace] which I find more practical. Being a C/C++ developer, it’s out of the question to press twice the semi-colon to finish an instruction.

Examples of use:

– Search for oZone3D.Net with google: [Ctrl]+[Backspace] + s ozone3d.net + [ENTER]

– Start Windows calculator: [Ctrl]+[Backspace] + cal + [ENTER] = about 2 seconds…
– Open Windows registry editor: [Ctrl]+[Backspace] + reg + [ENTER]

The FAQ presents you a more detailed table with all pre-built keywords.

Programming

Multithreading et Lecture du Clavier

Comment

La programmation multithreading est un monde à part et il faut bien en être conscient. Dans une des demos sur laquelle je bosse en ce moment, il y a deux threads: le thread principal qui s’occupe de la gestion des messages de la fenêtre via la classique pompe à message GetMessage() et le thread de rendu pour le rendu 3D de la scène. Dans le thread de rendu, l’application a besoin de récupérer l’état des touches du clavier (pour controler la caméra) avec GetKeyboardState(). Mais la chose à savoir est que l’état du clavier et ses messages sont postés dans le thread principal qui gère la fenêtre et du coup le thread de rendu ne reçoit aucun message et donc ne peut pas lire le clavier avec et KeyboardState(). Une solution pour résoudre ce problème est de partager l’état du clavier entre les deux threads à l’aide de la fonction win32 AttachThreadInput():

// === Main.cpp ===
// Main Thread
DWORD main_thread_id = GetCurrentThreadId();


// === Render.cpp ===
// Render Thread
DWORD render_thread_id = GetCurrentThreadId();

AttachThreadInput( render_thread_id, main_thread_id, TRUE );

Maintenant le thread de rendu peut lire l’état du clavier.

Tests et Reviews

Quick Review – Génération d’Arbres avec Dryad

Comment
[French] Dryad est un générateur d’arbres. C’est une application OpenGL et il est disponible pour Windows et MacOS X. Dryad permet de sélectionner un arbre à partir d’un espace d’arbres (sur le coté droit de l’application) en utilisant une interpolation entre les différents arbres se trouvant autour de la souris. Attention car Dryad est très gourmand en mémoire et 2Go de ram sont vivement conseillés.

Une fois le type d’arbre sélectionné, un clique sur l’icone des engrenages qui affiche les paramètres de l’arbre. Il est possible de tout paramétrer: le tronc, les feuilles, les branches.

Sur l’image suivante, j’ai diminué le nombre de feuilles et légèrement incurvé les branches du haut.

Mes réglages aboutissent à ce résultat final:

Dryad exporte votre création sous la forme d’un fichier OBJ. Celui de l’image précédente fait environ 62Mo, ouch! Le fichier OBJ est correctement généré et est accompagné de son fichier de materiaux. En modifiant à nouveau les paramètres, j’obtient un fichier OBJ de 2Mo qui contient environ 24000 faces. Ok chargeons-le maintenant dans HyperView3D:

Le problème est que les coordonnées z et y sont inversées. Mais HyperView3D possède une petite fonction pour remédier à ce problème: la permutation des coordonnées Y et Z des vertices. Vu que c’est un problème que l’on rencontre de temps en temps, cette petite fonctionnalité est utile.

Pour ceux qui veulent s’amuser avec ce modèle OBJ, le voilà: Dryad_Tree.zip.

Conclusion: Dryad est un petit utilitaire pratique pour la génération d’arbres mais nécessite une machine puissante. L’export en OBJ permet d’exploiter ses créations dans toutes les applications 3D qui prennent en charge ce format (comme Demoniak3D par exemple!).

Dryad is a tree gnenrator. It’s an OpenGL application and is available for Windows and MacOS X. Dryad allows to select a tree from a space called “the space of all trees” (in the right side of the app). The tree is created by interpolation between all trees that lie near the mouse. Pay attention because Dryad is very memory-consuming and 2 Gb of ram is recommended.

Once you have select your tree, a click on the gearing icon displays the tree parameters. You can customize everything: trunk, leaves, branches.

On the following image, I reduced the number of leaves and slightly incurved the upper branches.

My adjustments end up to :

Dryad exports your creation in an OBJ file. The one of the previous image is a huge 62Mb OBJ file, ouch! The OBJ file is properly generated and comes with its materials file. 62Mb is too big, and after a few adjustments, I get a 2Mb OBJ file with approximately 24000 faces. Okay now let’s load it in HyperView3D:

Now the problem now is that Y and Z coordinates are reversed. But HyperView3D has a little function to solve this problem: the swap of Y and Z coordinates. Because we encouter this problem time to time, this little function is useful…

For those who want to play with that OBJ file, you can grab it here: Dryad_Tree.zip.

Conclusion: Dryad is a handy utility for trees generation but requires a powerful computer. The OBJ export makes it possible to exploit the trees in all 3D applications that can load this standard format (like Demoniak3D for instance!).

Tests et Reviews, Utilitaires

Quick Review – Daphne 1.32

Comment

Daphne est un petit utilitaire de gestion de processus dans la même lignée que ProcessExplorer. Il affiche la liste détaillée de tous les processus avec toutes les infos (pid, path, threads, priority, …). L’option qui me plait dans ce tool est la possibilité de killer un processus de manière barbare, c’est à dire instantanément et non avec un temps d’attente de plusieurs secondes comme avec le task manager de Windows. Il est aussi possible de lister tous les threads appartenant à un processus et de les terminer individuellement. Très utile pour la mise au point d’applications multithreadées.

Une autre option disponible mais que je n’ai pas testée est de donner à Daphne le privilège “Debug programs”. Cela permettra à Daphne d’afficher encore plus d’informations sur les processus/threads du système. J’ai reproduit ci-dessous le contenu de la page Adding user rights on Windows XP:

In order to see full process list on Windows XP or over, you may
have to add "Debug programs" privilege to your user account.
   1. Run the "Local security setting" administrator by 
      typing "secpol.msc" in the Run... option of yout start menu.
   2. Expand the tree by clicking the "Local policies" item.
   3. Select the "User Rights Assignment" item.
   4. Double-click the "Debug programs" option in the right panel.
   5. Click "Add user or group..." button.
   6. Insert the user name and click "Check names" button.
   7. Click the OK button and close all opened windows.
   8. You have to restart your session.
OpenGL

ForceWare 163.75 et Occlusion Query

Comment

Je viens de passer deux heures de debug pour rien à cause d’un bug dans les Forceware 163.75. Une de mes routines qui utilise les fonctions de l’extension GL_ARB_occlusion_query plantait dès que le nombre de demandes devenait un peu grand (genre plus de 10000 demandes). Je me disais qu’il devait surement s’agir d’un buffer trop plein quelque part ou bien trop de demandes en attente (le debugger plantait dans la lib opengl de NVIDIA). Alors j’ai un peu bricolé et je me suis aperçu que glGetError() permettait à mon code de fonctionner ce qui laisse penser à un problème de latence / parallélisme au niveau des instructions OpenGL dans le pilote forceware.

Puis soudainement, en voyant arriver sur mon lecteur RSS la disponibilité du nouveau pilote ForceWare 169.38, je me suis dis: allez je ferme mes cinquantes fenêtres (je ne sais pas pour vous mais chez moi chaque instance de Visual Studio 2005 met 3 plombes pour se fermer en comparaison de Visual C++ 6.0 qui se fermait quasi immédiatement)
et hop j’installe ce nouveau driver. Yes! Mes routines d’occlusion query se sont remises à marcher parfaitement. Donc je me suis pris la tête pour rien sur un bug des ForceWare 163.75 ou mieux sur un bug qui est plus présent dans les ForceWare 169.38. Conclusion: mettez à jour vos drivers!

Tests et Reviews, Utilitaires

Quick Review – GPU-Z 0.1.6

1 Comment

A new version of GPU-Z is out. That’s cool. W1zzard has added a new tab with some info (redundant at least for the two first) : gpu clock speed, temperature and fan speed. But I think there is a problem in the reading of the gpu temperature sensor. Here are the results with my 8800 GTX:

1 – GPU-Z: 52 °C

2 – GPU Caps Viewer: 58 °C

3 – RivaTuner: 58 °C

Ok let’s wait for the next version…

OpenGL, Tests et Reviews

Quick Review – Lumina – GLSL studio

Comment

Je viens de m’amuser un peu avec Lumina. C’est un petit environnement de mise au point de shader GLSL. Le projet demarre et il y a encore pas mal de petites coquilles (essayez de charger plusieurs projets les uns à la suite des autres ou plus simplement chargez le projet de test deferred3.lum: l’interface graphique aime moyennement!) qui trainent mais le concept est bon. En regardant de plus prêt, cela ressemble fortement à une interface graphique posé sur un soft comme Demoniak3D. Il y a des scripts (écrits dans un language basé sur ECMA)pour mettre en place les éléments de la scene 3d et les controler. Il y a aussi les scripts GLSL (vertex, pixel et geometry). Si on analyse un fichier de projet on découvre une structure similaire à une démo Demoniak3D: un script XML, des nodes <script>, <shader>, etc.

Maintenant que le tour du proprio est fait, voilà mon premier projet de test ultra simple: afficher un torus jaune qui tourne le tout utilisant un vertex et un pixel shader pour le rendu. J’ai pu coder ce projet rapidement avec une analyse rapide des fichiers de projets *.lum.

Le projet est téléchargeable ici: lumina_jegx_test_01.zip

Globalement c’est sympa mais l’interêt de l’interface graphique est discutable. Dans ce type de soft (Lumina ou Demoniak3D) soit l’interface graphique est de haut niveau et simple à utiliser soit vaut mieux s’en passer. Je vais quand même étudier plus en détail le fonctionnement de Lumina ne serait-ce que pour améliorer Demoniak3D et son successeur…

Dans le même esprit que lumina il y a aussi FX Composer (NVIDIA) et RenderMonkey (ATI).

OpenGL

GLSL: ATI vs NVIDIA – Part…

1 Comment

While I was releasing the Julia’s Fractal demo, I tested it on NVIDIA and ATI (as usual before releasing a demo). And as usual, a new difference appeared in the way the GLSL is supported on ATI and on NVIDIA. On NVIDIA the following is line is ok but produces an error on ATI (Catalyst 8.1):

gl_FragColor = texture1D(tex, (float)(i == max_i ? 0 : i) / 100);

To be ATI Radeon-compliant, this instruction must be split in two:

if( i == max_i )
{
	gl_FragColor = texture1D(tex, 0.0);			
}
else
{
	gl_FragColor = texture1D(tex, i/100.0);			
}

I can’t immagine a world with more than two major graphics cards manufacturers. But if such a world exists, I stop 3d programming… Fortunately, NVIDIA accepts ATI GLSL syntax so there is only one code at the end. Conlusion: always check your GLSL shaders on ATI and NVIDIA before releasing a demo…

OpenGL, Programming

A cumbersome bug in the Catalyst 7.12

1 Comment

The latest Catalyst version is the 7.12 (the Cat7.12 internal number is 8.442.0.0). But exactly like the Cat7.11, these drivers have a bug in the management of dynamic lights in GLSL. But this time, I searhed for the source of bug because this bug is a little bit cumbersome in Demoniak3D demos. And we can’t use a previous version since Cat7.11+ are required to drive the radeon 3k (HD 3870/3850). Then I’ve coded a small Demoniak3D script that shows the bug. This script displays a mesh plane lit by a single dynamic light. The key SPACE allows to switch the GLSL shader: from the bug-ridden to the fixed and inversely.

– The following image shows the plane enlightened with the fixed shader:

– The following image shows the plane lit with the bug-ridden shader:

Okay that’s cool, but where does the bug come from ? After a little time spent on shaders tweaking, my conclusion is that the bug is localized in the value of the built-in uniform variable gl_LightSource[0].position. In the vertex shader, this variable should contain the light position in camera space. It’s OpenGL that does this transformation, and we, poor developers, just need to specify somwhere in the C++ app the light position in world coordinates. In the vertex shader, gl_LightSource[0].position helps us to get the light direction used later in the pixel shader:

	lightDir = gl_LightSource[0].position.xyz - vVertex;

With the Catalyst 7.11 and 7.12, the value stored in gl_LightSource[0].position is wrong. Then, one workaround, until the ATI driver team fix the bug, is to manually compute the light pos in camera space by passing to the vertex shader the camera view matrix and the light pos in world coord:

	vec3 lightPosEye = vec3(mv * vec4(-150.0, 50.0, 0.0, 1.0));
	lightDir = lightPosEye - vVertex;

mv is the 4×4 view matrix and vec4(-150.0, 50.0, 0.0, 1.0) is the hard coded light pos in world coord.

In the fixed pipeline, dynamic lights are well handled as shown in the next image:

In the Demoniak3D demo, the bug-ridden GLSL shader is called OneDynLightShader and the fixed one OneDynLightShader_Fixed. The demo source code is localized in the OneDynLightTest.xml file. To start the demo, unzip the archive in a directory and launch
DEMO_Catalyst_Bug.exe.

The demo is downloadable here: Demoniak3D Catalyst 7.11/7.12 Bug

This bug seems to affect all radeons BUT under Windows XP only. Seems as if ATI is forcing people to switch to Vista. Not cool… Or maybe ATI begins to implement OpenGL 3.0 in the Win XP drivers. Do not forget that with OpenGL 3.0 as with DX10, the fixed functions of the 3D pipeline like the management of dynamic lights will be removed.