A video about the next LucasArt game (summer 2008). They talk about Havok, DMM (Digital Molecul Matter) and other cool stuff.
Monthly Archives: January 2008
Quick Review – Lumina – GLSL studio
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).
GLSL: ATI vs NVIDIA – Part…
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…
Catalyst 8.1 GLSL lighting bug fixed
The previous catalyst (7.11 / 7.12) had a nasty bug in dynamic lights management in GLSL.
I’ve just tested the latest Catalyst 8.1 WHQL with the Demoniak3D demo I coded for, and the bug has been fixed. In the release notes, there is no trace of this bug and its correction. Anyway, now this bug is fixed and this is the important thing.
GPU Caps Viewer en Chine
GPU Caps Viewer est en train de se balader un peu partout autour de la planète web, et je viens de le découvir en Chine où il a posé ses valises le temps de faire chauffer quelques GPUs chinois…
Le lien: www.greendown.cn
Attention aux yeux, ça clignote de partout!
A cumbersome bug in the Catalyst 7.12
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.
Les Catalyst 7.12 toujours à la sauce “Bug-Inside”
Les derniers pilotes Catalyst ont la version 7.12 (le numéro interne des Cat7.12 est le 8.442.0.0 – c’est pas un téléphone ok!). Mais exactement comme les 7.11, ces drivers ont un bug dans la gestion des lumières dynamiques en GLSL. Mais cette fois-ci, je me suis mis à la recherche du bug car il est un peu, voire très génant pour les demos Demoniak3D. J’ai donc pondu un petit script Demoniak3D qui met en évidence ce bug. Ce script montre un mesh plan éclairé par une lumière dynamique. Un appui sur la touche SPACE permet de changer de shader GLSL: on passe du shader bogué au shader corrigé et inversement.
– L’image suivante montre le plan éclairé avec le shader corrigé:
– L’image suivante montre le plan éclairé avec le shader bogué:
okay tout ceci est bien, mais d’oû vient le bug? Après avoir passé un peu de temps à tweaker les shaders, j’en suis arrivé à la conclusion que le bug se situe au niveau de la valeur contenue dans la variable uniforme built-in gl_LightSource[0].position. Au niveau du vertex shader, cette variable contient la position de la lumière exprimée l’espace de la caméra. C’est OpenGL qui effectue cette transformation, à notre niveau il suffit de spécifier la position de la lumière en coordonnées du monde. Au niveau du vertex shader, gl_LightSource[0].position nous permet de calculer la direction de la lumière utilisée plus tard dans le pixel shader:
lightDir = gl_LightSource[0].position.xyz - vVertex;
Avec la Radeon HD 3870 et les Catalyst 7.11 et 7.12, la valeur contenue dans gl_LightSource[0].position est fausse.
Donc le workaround que je propose en attendant que la driver team d’ATI corrige le bug, est de passer au vertex shader la position de la lumière exprimée dans les coordonnées du monde ainsi que la matrice de vue de la camera et de faire la transformation à la main:
vec3 lightPosEye = vec3(mv * vec4(-150.0, 50.0, 0.0, 1.0)); lightDir = lightPosEye - vVertex;
mv représente la matrice 4×4 de vue de la caméra et vec4(-150.0, 50.0, 0.0, 1.0) représente la position de la lumière en coordonnées du monde.
Au niveau pipeline fixe, les lumières dynamiques sont bien gérées comme le montre l’image suivante:
Au niveau de la démo Demoniak3D, le shader GLSL bogué est appelé OneDynLightShader et celui corrigé OneDynLightShader_Fixed. Le code source de la démo Demoniak3D se trouve dans le fichier OneDynLightTest.xml. Pour lancer la demo, dézippez l’archive dans un répertoire
et lancez DEMO_Catalyst_Bug.exe.
La démo est téléchargeable ici: Demoniak3D Catalyst 7.11/7.12 Bug
Ce bug affecte toutes les radeons MAIS sous Windows XP uniquement. On dirait qu’ATI nous force un peu la main pour passer sous Vista. Pas trop sympa… Ou alors ATI commence à implémenter OpenGL 3.0 dans les drivers XP. Car n’oublions pas qu’avec OpenGL 3.0, tout comme avec DX10, les fonctions fixes du pipelines 3D comme la gestion des lumières dynamiques sont supprimées.
Je voudrais remercier la communauté WorldPCSpecs pour les tests. Merci les gars!
GPU Caps Viewer Validation Facility
Petit changement de Thème
Voilà j’ai encore changé de thème pour ce blog. Et oui que voulez vous, avec la quantité astronomique de thèmes disponibles, je pourrais en changer tous les jours. Ceci dit, pour ceux qui sont interessés, ce thème est dispo ici: Paalam.
Juste pour info, l’image d’entête est issue d’une petite démo 3d qui sera releasée prochainement.