FrameBufferObject en OpenGL

Pour lire ce tutoriel, il est nécessaire de connaître le fonctionnement d'OpenGL. Je ne reviendrai pas sur les bases d'un programme OpenGL affichant une scène ni sur l'architecture de cette bibliothèque reposant sur une machine à états. Le pipeline fixe étant devenu obsolète, je passerai volontairement quelques explications par rapport à cet ancien modèle. Sachant que les Frame Buffer Objects sont étroitement liés avec les textures OpenGL, il est donc nécessaire de savoir créer et utiliser des textures avec OpenGL. Finalement, il peut être utile de lire les articles sur les extensions OpenGL et sur les shaders GLSL.

Tout d'abord, regardons ce diagramme simplifié du pipeline graphique :

Nous voyons que le programme OpenGL commence le calcul de l'image en passant par le vertex shader, puis le fragment shader. Une fois le fragment shader exécuté, plusieurs canaux sont remplis :

• pour la couleur ;
• pour la profondeur ;
• pour le stencil buffer ;
• pour l'accumulation.

L'ensemble de ces canaux est appelé un FrameBuffer (littéralement un tampon d'image). Par défaut, le canal « couleur » est copié vers l'écran.

Dans les jeux vidéo, certaines techniques demandent à lire les pixels affichés à l'écran afin de les réutiliser comme source d'information (telle que la technique de calcul des ombres, appelées « shadow mapping ») ou d'appliquer des effets supplémentaires sur l'image (post process). Pour ce faire, il était nécessaire de demander à OpenGL de lire le tampon mémoire de sortie et de renvoyer les informations au programme OpenGL. Cette technique est coûteuse, car elle repose sur la vitesse de transfert GPU/CPU. Une autre technique mise en place à l'époque a été d'utiliser des pixel buffers (pbuffers) afin d'avoir un espace de stockage pour le rendu. Le problème de ce dernier est que les pbuffers étaient gérés par le système de fenêtrage, forçant l'utilisateur à créer différents contextes pour les différents formats de texture voulus. De plus, le changement entre la fenêtre principale et ce second buffer pouvait être lent.

Afin de répondre à une demande de plus en plus importante, le consortium autour d'OpenGL a décidé de faire une extension simple et optimisée permettant de faire du rendu hors écran.

L'extension GL_ARB_framebuffer_object, apporte de nouveaux éléments au sein d'OpenGL. Le premier, nommé « image attachable au renderbuffer » correspond à un objet pouvant être attaché à un framebuffer afin qu'il soit utilisé comme source et destination du framebuffer. L'information de remplissage est soit la couleur, la profondeur ou le stencil. Actuellement, il existe deux objets de ce type :

• les textures ;
• les renderbuffers.

Les buffers de profondeur et les stencil buffers possédaient des formats de pixels non représentables dans de simples textures. Afin de conserver ces buffers à la fin du rendu, les renderbuffers ont été intégrés. Il est possible de les utiliser lorsque nous n'avons pas besoin de texture dans la suite de notre rendu.

Ainsi, pour faire un rendu vers une texture, il suffit d'attacher cette texture à l'un des canaux et d'effectuer le rendu. Ensuite, comme toute autre texture, elle est utilisable dans le fragment shader.

Le second élément est le FrameBuffer Object. C'est un objet OpenGL permettant de gérer facilement les collections d'attachements. Grâce à cet objet, il est facile d'avoir plusieurs ensembles de textures de destination ou encore de changer simplement les textures attachées.

• rendering : convertir des données en une image visible à l'écran.
  pixel : point lumineux à l'écran.
  fragment : informations telles que la couleur, la profondeur… correspondant à un pixel. Devient pixel après blending, depth test, etc.
  buffer : tableau de fragments. Exemples de buffers : colors buffer, depth buffer, stencil buffer, accumulation buffer . Les informations contenues dans chaque fragment correspondent au type de buffer. Par exemple, pour un color buffer, chaque fragment contient une couleur, codée selon le système RGB (les intensités des canaux rouge, vert et bleu d'un pixel sont codées sur un octet chacune).

Buffer logique : un des canaux du frame buffer (couleurs, profondeur, stencil).

Frame buffer : un ensemble de buffers logiques et d'états définissant l'emplacement où le rendu OpenGL sera effectué.

Frame buffer object : objet représentant un frame buffer.

Render buffer : nouvel espace de stockage contenant un simple tableau 2D de pixels pouvant être utilisé comme cible de rendu.

Renderbuffer object : objet représentant un render buffer.

Attacher : le fait de lier un objet avec un autre. Dans le cas du frame buffer, le fait d'attacher un objet au frame buffer permettra à celui-ci de l'utiliser comme endroit où faire le rendu.

Passe(s) : nous parlons de passe, le fait d'effectuer une opération de dessin sur la carte graphique.

Rendu direct : le rendu direct est un rendu en une seule et unique passe. C'est le rendu que nous utilisons très couramment afin d'effectuer un affichage simple des objets.

Rendu différé : le rendu différé est un rendu constitué de plusieurs passes. Généralement, dans les premières passes, la scène est rendue dans des textures qui seront utilisées dans les passes suivantes.

Les frame buffer objects ont l'avantage de permettre de conserver et d'utiliser les informations calculées par le GPU dans la mémoire du GPU. En effet, avec les anciennes méthodes, il fallait faire des allers-retours entre le programme OpenGL et le GPU. Maintenant, les données restent sur le GPU, les programmes ne subissent plus des latences à cause du bus de données.

Pour certaines techniques de rendu, telles que le calcul des lumières, il est plus efficace de conserver toutes les informations de la scène (position dans le monde, couleurs, normales) dans des textures et des les réutiliser pour toutes les sources de lumière. De plus, si vous souhaitez effectuer des effets sur l'image finale, il vous suffit de dessiner la scène dans une texture et de lui appliquer l'effet à l'aide d'un shader.

Un FBO est un objet OpenGL qui correspond au buffer à remplir en sortie du pipeline graphique. Celui-ci possède plusieurs canaux de sortie dans lesquels le fragment shader écrira. Parmi ceux-ci, nous comptons :

• les canaux de couleurs (lorsque nous dessinons à l'écran, nous n'en utilisons qu'un seul, mais les FBO permettent d'en avoir plusieurs) ;
• le canal de profondeur ;
• le canal stencil.

Pour chaque canal, vous pouvez soit attacher une texture, soit un render buffer.

Voici un petit schéma récapitulatif du fonctionnement :

Lorsque le FBO est actif, le shader écrira dans les canaux. Pour les canaux attachés à des textures ou des render buffer, les informations iront directement dans ces objets.

2-B-1. Évolution des versions▲

2-B-2. Énumérations▲

2-B-3. Fonctions▲

Maintenant que nous avons pris connaissance des fonctions pour les FBO, nous pouvons commencer à les utiliser.

Le schéma suivant récapitule les différentes actions afin d'utiliser les FBO.

Il est aussi possible de changer de texture et de render buffer dans la boucle d'affichage. Pour cela, il suffit d'attacher la nouvelle ressource avec glFramebufferTexture ou glFramebufferRenderbuffer et de valider celle-ci avec glCheckFramebufferStatus.

Pour finaliser l'intégration des FBO, il est aussi nécessaire de faire quelques modifications dans le fragment shader, lui permettant ainsi de sauvegarder des informations dans les multiples textures attachées aux FBO.

2-D-1. En OpenGL 2▲

2-D-2. En OpenGL 3▲

layout(location=0) out vec4 positionOut;

Voici un petit exemple simple de l'utilisation des FBO avec OpenGL. Le programme est simplifié à son minimum. Pour les shaders, j'ai en partie utilisé le code de ce tutoriel. Pour le VBO, je me suis inspiré du tutoriel de raptor70.

Le programme effectue un premier rendu (ou première passe) d'un cube coloré dans une texture. Dans la passe suivante, le programme dessine un cube et utilise la texture créée lors de la première passe. De plus, le résultat de la première passe est affiché sur l'écran à l'aide de la fonction glBlitFramebuffer().

Il est nécessaire d'utiliser un render buffer afin que le cube de la première passe utilise le buffer de profondeur. Sans celui-ci vous aurez les artefacts visuels suivants :

Un flou simple est très aisé à mettre en place. Il suffit de faire un rendu de la scène dans une texture. Ensuite, pour chaque pixel nous calculons la moyenne des couleurs alentour. Pour ce faire, nous dessinons la texture générée directement sur l'écran, à l'aide d'un rectangle de la taille de la fenêtre. Ainsi, le pixel shader va être exécuté sur chaque pixel. Voici un exemple du calcul de la couleur moyenne effectué dans le pixel shader :

float blurValue = 0.0015; 
     
vec4 color = texture2D(fboTex, vec2(io_texCoord.s + blurValue, io_texCoord.t + blurValue)); 
color += texture2D(fboTex, vec2(io_texCoord.s - blurValue, io_texCoord.t + blurValue)); 
color += texture2D(fboTex, vec2(io_texCoord.s + blurValue, io_texCoord.t - blurValue)); 
color += texture2D(fboTex, vec2(io_texCoord.s - blurValue, io_texCoord.t - blurValue)); 
     
gl_FragColor = color / 4.0;

Vous pouvez trouver ici le programme d'exemple affichant un cube légèrement flou. On remarquera sur l'image ci-dessous que les bords du cube sont plus lisses.

Cet effet de flou peut être utilisé pour remplacer la technique d'antialiasing et cela pour un faible coût.

Le shadow mapping est une technique permettant de calculer les ombres pour les objets d'une scène.

La technique est décomposée en deux passes : le calcul des ombres, puis le rendu proprement dit. Pour le calcul des ombres, il faut placer la caméra à l'emplacement de la lumière, l'orienter avec la direction de la lumière, faire un rendu de la scène et ne garder que la profondeur (distance entre la lampe et le mesh, donc). Celle-ci est conservée dans l'espace homogène. Grâce aux FBO ce résultat est stocké dans une texture, appelée shadow map (littéralement : carte des ombres). Nous devons créer la shadow map pour chaque source, afin de connaître les ombres produites par chaque lumière.

Dans la seconde passe, la scène est rendue normalement, sauf que dans son pixel shader, on calculera si la distance entre le point actuel et la lampe est supérieure à la valeur retournée par la shadow map pour la même position. Si la valeur de la texture est inférieure, cela indique qu'il y a un objet entre la lampe et ce pixel, donc, qu'il doit être ombré.

Avec le pipeline fixe, nous étions limités à huit sources de lumière. Avec les shaders, le nombre de sources n'est plus limité, mais le calcul des lumières pour tous les pixels et toutes les lampes est lent. Heureusement, il est possible de faire beaucoup mieux.

Cette technique se décompose en deux passes.

Dans la première, il faut afficher la scène, comme nous le ferions habituellement. Par contre, nous faisons le rendu dans un FBO qui contiendra au minimum trois textures attachées. Lors de l'exécution du shader, la position du vertex, la normale et la couleur de l'objet seront sauvegardées dans les textures (une texture pour chaque donnée).

La seconde passe utilise les trois textures précédemment créées. Par contre, nous allons éviter de calculer l'influence de toutes les lampes pour tous les pixels. Pour ce faire, nous allons limiter l'exécution du pixel shader aux seuls endroits où la lampe influe sur les pixels. Cela est possible en dessinant des rectangles de la taille du rayon de la lumière (puissance de la lampe). Ainsi, le pixel shader, qui contiendra l'algorithme pour l'éclairage ne sera exécuté que pour les pixels réellement éclairés. De plus, pour le cas où deux lampes affectent les mêmes pixels, il suffit de régler le mode de fondu (blend mode) afin d'avoir une composition.