Le mot clé precise en GLSL (introduit avec l’extension GL_ARB_gpu_shader5) permet de dire au compilteur GLSL de ne pas faire d’optimisation sur le calcul d’une variable. En virgule flottante, a*b*c peut être différent de a*c*b à cause des erreurs d’arrondi.

Dans MSI Kombustor, j’avais testé ce mot clé avec quelques variables car je cherchais à résoudre un bug dans la tessellation. Mais le bug n’était pas lié aux erreurs d’arrondi et autres optimisations faites par le compilateur. J’ai trouvé la solution plus tard. Le problème c’est que j’ai mal nettoyé mon code GLSL et j’ai oublié un keyword precise… A ce moment là, j’avais une Radeon HD 6870 dans ma machine de dev et cet oubli était passé inaperçu. Mais plusieurs jours après quand j’ai branché une GeForce GTX 460 dans ma machine, j’ai eu une mauvaise surprise. Le rendu de mon object avec tessellation et shadow mapping était passé en mode tacheté:

Dans Kombustor, il y a plusieurs tests 3D qui utilisent la tessellation sur les objets 3D avec du shadow mapping pour créer des ombres. Le shadow mapping utilise en gros deux passes: une passe ambiente pour initialiser le z-buffer et dessiner la scene avec l’eclairage ambient, et une seconde passe, dite passe d’illumination, pour colorier les pixels en fonction de la shadow map. La seconde passe etant rendue avec un glDepthFunc(GL_EQUAL) (et du blending) pour ne colorier que les pixels nécessaires.

Le rendu avec GL_EQUAL fonctionne bien si les vertices calculés dans la seconde passe ont exactement la même position finale que ceux calculés dans la première passe. Mais dans le cas de Kombustor, j’avais oublié une variable avec le mot clé precise dans un des shaders de tessellation (le TES, Tessellation Evaluation Shader) de la passe d’illumination. Sur les Radeons (HD 6800 et HD 6900) cela n’a posé aucun problème mais sur une GeForce, ça ne pardonne pas. La position des vertices calculés dans la passe d’illumination est très légèrement différente à cause du mot clé précise et du coup, certains pixels de la seconde passe, n’ayant plus exactement le même Z que ceux de la première passe, ont été eliminés par le test de profondeur ou depth-test. D’où l’apparition des tâches qui correspondent aux endroits où les pixels n’ont pas le bon Z.

J’ai passé quelques heures sur ce sale bug et après avoir compris que le mot clé précise était la source de tous mes ennuis, j’ai enfin retrouvé le bon rendu:

Le mot clé précise semble avoir plus d’influence sur les optimisations faites par le compilteur GLSL de NVIDIA que celui d’AMD. Le mot clé précise est-il pris en compte par le compilo GLSL d’AMD? Y’a-t-il des optimisations dans les calculs flottants avec les cartes Radeon (j’imagine que oui)?

Maintenant je comprends pour NVIDIA insiste souvent, dans les presentations OpenGL 4, sur l’importance du mot clé precise avec les GeForce.

Je viens de tester les sampler states disponibles avec OpenGL 3.3 dans Kombustor 2.2.x. Les samplers states servent tout simplement à définir l’état d’une unité de texture, indépendamment de l’objet texture qui y est appliqué. Les sampler states sont décrits dans cette spec OpenGL: GL_ARB_sampler_objects.

Chose intéressante, les sampler states OpenGL 3.3 permettent de coller à la logique de Direct3D 11 qui définit aussi cette abstraction hardware avec la structure D3D11_SAMPLER_DESC et les fonctions CreateSamplerState (device D3D11) et PSSetSamplers (contexte immediat). Avant OpenGL 3.3, l’état d’une unité de texture était lié à un objet texture (créé avec glGenTextures). Maintenant avec les sampler states, on s’approche du niveau hardware / GPU.

Voyons rapidement comment utiliser les sampler states.

1 – Création et initialisation du sampler:

1
2
3
4
5
6
7

GLuint sampler_state = 0;
glGenSamplers(1, &sampler_state);
glSamplerParameteri(sampler_state, GL_TEXTURE_WRAP_S, GL_REPEAT);
glSamplerParameteri(sampler_state, GL_TEXTURE_WRAP_T, GL_REPEAT);
glSamplerParameteri(sampler_state, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glSamplerParameteri(sampler_state, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glSamplerParameterf(sampler_state, GL_TEXTURE_MAX_ANISOTROPY_EXT, 16.0f);

Je viens de créer un sampler state de filtrage linéaire avec X16 de filtrage anisotropique. Les paramètres sont les mêmes que ceux utilisés lors de la création d’une texture.

2 – Utilisation du sampler

1
2
3

GLuint texture_unit = 0;
glBindSampler(texture_unit, sampler_state);
...

Rien de plus simple: il suffit de dire sur quelle unité de texture doit on appliquer notre sampler. Une fois appliqué sur une unité de texture, les réglages du sampler sont prioritaires à ceux d’un objet de texture. Donc c’est super simple d’ajouter les sampler states dans votre code OpenGL. Pas besoin de modifier le code existant de création des textures.

Quand on ne veut plus utiliser un sampler sur une unité de texture, il suffit d’appeller le code suivant:

1

glBindSampler(texture_unit, 0);

3 – Destruction du sampler:

glDeleteSamplers(1, &sampler_state);

• OpenGL 1.1 – Texture objects
• OpenGL 1.2 – 3D textures, BGRA and packed pixel formats
• OpenGL 1.3 – Multitexturing, multisampling, texture compression
• OpenGL 1.4 – Depth textures
• OpenGL 1.5 – Vertex Buffer Object (VBO), Occlusion Queries
• OpenGL 2.0 – GLSL 1.1, MRT, Non Power of Two textures, Point Sprites, Two-sided stencil
• OpenGL 2.1 – GLSL 1.2, Pixel Buffer Object (PBO), sRGB Textures
• OpenGL 3.0 – GLSL 1.3, Texture Arrays, Conditional rendering, Frame Buffer Object (FBO)
• OpenGL 3.1 – GLSL 1.4, Instancing, Texture Buffer Object, Uniform Buffer Object, Primitive restart
• OpenGL 3.2 – GLSL 1.5, Geometry Shader, Multi-sampled textures
• OpenGL 3.3 – GLSL 3.30 Backports as much functionality possible from the OpenGL 4.0 specification
• OpenGL 4.0 – GLSL 4.00 Tessellation on GPU, shaders with 64-bit precision
• OpenGL 4.1 – GLSL 4.10 Developer-friendly debug outputs, compatibility with OpenGL ES 2.0

[source]

Small noise / random function in GLSL:

varying vec3 v;
float rand(vec2 n)
{
  return 0.5 + 0.5 *
     fract(sin(dot(n.xy, vec2(12.9898, 78.233)))* 43758.5453);
}
void main(void)
{
  float x = rand(v.xz);
  gl_FragColor = vec4(x, x, x, 1.0);
}

Noise function tested in GeeXLab (OpenGL 2):

uniform float x;
void main (void)
{
  if (x < 0.5)
    gl_FragDepth = x;
  else
    gl_FragDepth = gl_FragCoord.z;
}

En général gl_FragDepth varie de 0.0 à 1.0:
- 0.0 représente un pixel sur le near plane de la camera
- 1.0 représente un pixel sur le far plane de la camera

gl_FragDepth est disponible dans toutes les version de GLSL, y compris dans le GLSL d’OpenGL 4 et 4.1.

Voilà, c’est tout ce que j’ai à dire sur gl_FragDepth pour aujourd’hui! Si j’ai dit une bétise ou mieux si vous avez quelque chose à ajouter par rapport à gl_FragDepth, un petit commentaire (ou un tweet) fera l’affaire.

QutMol est un soft pour visualiser les molécules (format PDB) et utilise OpenGL pour le rendu 3D. Bon QutMol (drôle de nom au passage) n’a pas été updaté depuis presque 3 ans mais dans la liste des features il y a: Real Time Ambient Occlusion. C’est bon je lance le download…

Une grosse molécule avec de l’AO uniquement:

Et là une autre molécule avec toujours de l’AO mais aussi une détection de silhouette et même un petit halo (noir) pour la rendre plus classe la publication des molécules sur les sites web par exemple:

Tiens, je vais peut être en faire une news sur Geeks3D un des ces quatres

Vue les feedbacks réguliers (genre: le download n’est plus dispo!!!) que je reçois par rapport au petit article que j’ai pondu il y a 2 ans sur le geometry instancing en OpenGL, j’ai decidé de remettre le pack de demos à jour.

Et j’ai ajouté un nouveau mode basé sur les uniform buffers.

Les demos fonctionnent maintenant correctement sur ma GTX 480. Et bien sûr, je viens juste de tester sur une HD 5870 + Cat 10.6 et ça mer… euh crashe!

Et vue que j’ai pas envie de remplacer la GTX 480 par la HD 5870 sur ma machine de dev, je vais devoir debugger à distance…

Dès que c’est ok sur la radeon, je publie l’article complet sur Geeks3D.com.

Ce que j’adore avec Python, c’est la richesse des librairies tierces. Il y a pratiquement une librairie pour chaque besoin. Le mien était de pouvoir faire des render calls (ou draw call) dans les scripts Python de GeeXLab. GeeXLab possède des scripts de type Direct Rendering: il est possible dans ce type de script de faire des rendus d’objets et plus généralement de contrôler le renderer temps réel (oui la fameuse carte graphique). Du coup j’ai coder une librairie LUA/Python au doux nom de HYP_Renderer. Cette lib a les fonctions de base pour dialoguer avec la carte graphique via OpenGL. Mais pour être le plus complet possible, il faudrait implémenter une bonne partie des fonctions OpenGL, ce qui représente un certain travail.

Je me suis dit, tiens, c’est peut être le moment de tester PyOpenGL… PyOpenGL est tout simplement la version Python de l’API OpenGL. La syntaxe et le nom des fonctions, tout y est!

Alors hop, un petit download (en fait plusieurs car la toute dernière version de la lib, PyOpenGL-3.0.1a2.win32.exe, semble avoir quelques bugs, je me suis donc rabattu sur le fichier PyOpenGL-3.0.0c1.win32.exe), une petite install, et me voici prêt à tester PyOpenGL. Je me code vite fait (bah oui c’est GeeXLab…) une petite demo qui exploite les scripts direct rendering:

Le carré rouge, les deux sphères et les deux lignes au contraire sont dessinés par des render calls comme le montre le script ci dessous:

import HYP_Utils
import HYP_Camera
import HYP_Renderer
import HYP_Object
import HYP_Lighting
import HYP_Scene

#--- Lib PyOpenGL
from OpenGL.GL import *

#--- Les matrices de vue et de projection sont
#--- collés à la carte graphique.
HYP_Camera.ApplyToRenderer(gMainCameraId)

sceneWidth, sceneHeight = HYP_Scene.GetWindowSize()

#--- Yeah! Des petits appels OpenGL. Trop bon!
#--- Ces cinq lignes dessine le carré rouge...
glEnable(GL_SCISSOR_TEST)
glScissor(sceneWidth/2-100, sceneHeight/2-100, 200, 200);
glClearColor(1.0, 0.0, 0.0, 1.0)
glClear(GL_COLOR_BUFFER_BIT)
glDisable(GL_SCISSOR_TEST)

#--- Les lignes suivantes dessinent les deux spheres et les
#--- deux lignes
HYP_Lighting.ApplyToRenderer(gLight01Id)

HYP_Object.ApplyRasterizerStatesToRenderer(gMeshSphere)
HYP_Material.ApplyToRenderer(gSphereMat)

HYP_Renderer.GPUShaderBind(gPhongShader_GLId)
HYP_Object.SetPosition(gMeshSphere, -20.0, 0.0, 0.0);
HYP_Mesh.RenderSubset(gMeshSphere, 0);
HYP_Renderer.GPUShaderBind(0)

HYP_Renderer.GPUShaderBind(gNormalShader_GLId)
HYP_Object.SetPosition(gMeshSphere, 20.0, 0.0, 0.0);
HYP_Mesh.RenderSubset(gMeshSphere, 0);
HYP_Renderer.GPUShaderBind(0)

HYP_Camera.ApplyToRenderer(gMainCameraId)

HYP_Renderer.SetLightingState(0)
HYP_Renderer.SetLineThickness(2.0)
HYP_Renderer.DrawLine(-20.0, -20.0, 20.0,
	1.0, 0.0, 0.0, 1.0,
	20.0, 20.0, -20.0,
	0.0, 1.0, 0.0, 1.0)
HYP_Renderer.DrawLine(20.0, -20.0, 20.0,
	0.0, 0.0, 1.0, 1.0,
	-20.0, 20.0, -20.0,
	1.0, 1.0, 0.0, 1.0)
HYP_Renderer.SetLineThickness(1.0)

Pouvoir coder avec l’API OpenGL sans compilation est assez délirant! Grâce à PyOpenGL, GeeXLab devient une plateforme pour apprendre à programmer en OpenGL simplement.