Continue reading
Tag Archives: 3D
Depth of Field (DoF): Quelques tests
Vertex Displacement Mapping in GLSL Now Available on Radeon!
As I said in this news, the release of Catalyst 8.10 BETA comes with a nice bugfix: vertex texture fetching is now operational on Radeon (at least on my Radeon HD 4850). From 2 or 3 months, Catalyst makes it possible to fetch texture from inside a vertex shader. You can see with GPU Caps Viewer how many texture units are exposed in a vertex shader for your Radeon:
But so far, vertex texture fetching in GLSL didn’t work due to a bug in the driver. But now this is an old story, since VTF works well. For more details about vertex displacement mapping, you can read this rather old (2 years!) tutorial: Vertex Displacement Mapping using GLSL.
This very cool news makes me want to create a new benchmark based on VTF!
I’ve only tested the XP version of Catalyst 8.10. If someone has tested the Vista version, feel free to post a comment…
Next step for ATI driver team: enable geometry texture fetching: allows texture fetching inside a geometry shader…
See you soon!
Quick Review – GLC_Player: Viewer de Fichiers OBJ
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.
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.
The Technology of a 3D Engine @ Beyond3D – Part 1
“This series of articles is meant for anyone willing to write, or learn about the process of writing, a modern, streaming, 3D engine, taking advantage of current programmable hardware.”
Read the article HERE
Nos amis de Beyond3D viennent de lancer une nouvelle serie d’articles, cette fois ci sur l’architecture d’un moteur 3D moderne et qui sait exploiter nos cartes graphiques toujours plus puissantes. Après quelques pages de banalités (pages 1, 2 et 3), la quatrième et dernière page (quoi déjà?) nous parle plus en détail des différrentes API de rendu 3D (Direct3D et OpenGL) et l’auteur nous dit que son moteur (le FlExtEngine) utilise une couche d’abstraction pour le renderer 3D. C’est une solution dece type qui est utilisé dans le moteur oZone3D qui propulse Demoniak3D ou GPU Caps Viewer.
Donc la lecture de cet article et surtout des suivants vous permettra d’en apprendre un peu plus sur les coulisses de Demoniak3D. J’essaierai de faire un petit feedback lors de la sortie des autres articles.