Discussion :

[zenux]

Bonjour,

J'ai un FBO avec une texture GL_DEPTH_ATTACHMENT. Quand je lis cette texture dans un shader GLSL (texture2D), je constate que la valeur est toujours comprise entre 0.0 (zNear) et 1.0 (zFar).
Pourtant si je prends un point 3D visible sur mon écran et que je le multiple par la projection matrix, j'obtiendrai toujours un résultat entre -1.0 (zNear) et 1.0 (zFar).

Qui fait la transformation des coordonnées [-1.0, 1.0] à [0.0, 1.0] pour stocker la depth value dans ma texture ? Est-ce qu'on a un contrôle sur cette partie ?
Quel est le calcul exécuté pour faire cette transformation ? Est-ce linéaire (depthValue * 0.5 + 0.5) ?

Merci d'avance.

[LittleWhite]

Bonjour,

Cette transformation n'est pas liée à la texture de profondeur, mais à tout tampons souhaitant être affiché à l'écran. La transformation est (indirectement ?) liée au glViewport(), car au final, on passera les coordonnées dans l'espace écran (pour être affichés sur l'écran ).

[zenux]

Merci pour cette reponse.

J ai enfin trouve que c est la fonction glDepthRange qui permet de definir cette transformation qui est lineaire. Et comme tu l as dit cela est bien fait au meme moment que le glViewPort.

[LeGreg]

Le stockage des valeurs dans le depth buffer n'est pas linéaire (selon la distance au centre de vue).

De plus le format est à priori "opaque" même si c'est souvent rapporté à un nombre entre 0 et 1.

Ce qui se passe : OpenGL (et les autres APIs comme DirectX) définissent un viewport qui a des dimensions précises dans l'espace en 3D et qui définit ce qui est visible à l'écran. Ce viewport est consistant avec les maths utilisés dans le Vertex shader/Vertex program.

Ensuite, la valeur d'un sommet (X,Y,Z,W) est converti dans l'espace écran et l'espace du depth buffer pour être comparé à la valeur du depth buffer déja stockée. En gros X,Y,Z,W deviennent X/W,Y/W,Z/W, 1/W. Cette transformation est intéressante parce que à cause de la projection conique les coordonnées ne sont pas linéaires sur l'espace de l'écran, mais les valeurs **/W le sont.

Quand on calcule Z/W, la notion de ZNear et ZFar disparaissent (Z et W sont tous les deux fonctions de ZNear et ZFar). Par contre on sait qu'on est à ZNear quand Z/W == 0. et ZFar quand Z/W == 1 (c'est parfois l'inverse suivant la convention du depth buffer).

Ces deux limites définissent le champ d'application du Depth buffer. Si les valeurs stockés dans le depth buffer sont des entiers (formats D16 et D24 ou D32), alors la totalité des valeurs entières sont utilisés avec 0 qui mappe la valeur Z/W == 0, et MAX_INT qui mappe la valeur Z/W == 1. Puis toutes les valeurs intermédiaires (linéaires en Z/W). On peut voir ça comme la version non normalisée de la valeur Z/W dans l'espace écran.
Il y a aussi des formats de depth buffer au format flottant sur les GPUs modernes (dans ce cas pas de dénormalisation, 0.0f mappe 0, et 1.0f mappe 1).

Si une valeur est linéaire en Z/W, alors elle n'est pas linéaire en Z (sauf si W est une constante bien entendu mais ce n'est pas le cas en projection conique classique). Ça a des implications sur la précision (si le depth buffer est un format entier toute la précision est concentrée autour du ZNear).

Autre implication importante est que si tu lis les valeurs du depth buffer dans un shader plus tard.. Tu dois faire la re-linéarisation a la main si ton algorithme est sensible au fait que ton info de profondeur soit linéaire. Ce n'est pas forcément compliqué, tu fais l'opération inverse à Z/W, en réintroduisant les termes de ta matrice de projection.