Dans l'univers de la programmation graphique avec OpenGL, l'acheminement de données vers les shaders est une opération fondamentale. Alors que les attributs de sommet (vertex attributes) sont parfaitement adaptés aux propriétés par sommet (positions, normales, coordonnées de texture), et que les variables uniformes (uniforms) conviennent pour des valeurs uniques ou de petits tableaux partagés par tous les sommets, des défis surgissent lorsqu'il s'agit de gérer des ensembles de données substantiels et structurés qui doivent être accessibles globalement au sein d'un shader. Les tableaux uniformes classiques sont souvent sujets à des limitations de taille, et la création de multiples uniforms individuels pour divers types de données devient rapidement fastidieuse et inefficace. Cet article explore une technique puissante pour contourner ces contraintes : l'utilisation de textures 2D standards comme tampons de données flexibles. Cette approche tire parti des unités d'échantillonnage de texture hautement optimisées du GPU pour une récupération rapide des données, ce qui la rend particulièrement efficace pour les scénarios nécessitant un volume important de données non géométriques.

Considérons un scénario où une application gère une collection de M entités distinctes. Chaque entité possède N attributs numériques différents (par exemple, un identifiant d'objet, sa santé, son état actuel encodé en flottants, ou même les composantes d'une matrice de transformation). L'objectif est de stocker efficacement tous ces attributs dans une structure accessible par la GPU et de récupérer n'importe quel attribut spécifique de n'importe quelle entité directement depuis un shader GLSL.

Allocation et Configuration de la Texture (C++/OSG)

Une texture 2D, souvent perçue comme une image, peut être utilisée très efficacement comme un tableau bidimensionnel de points de données. Chaque "pixel" de cette texture représente alors une unité de donnée. La quantité et le type de données stockables par unité dépendent du format interne de la texture (pixelFormat) et de son type de données (type). Par exemple, un format GL_RGBA combiné avec GL_FLOAT permet à chaque pixel de stocker quatre valeurs flottantes. À l'inverse, GL_RED avec GL_UNSIGNED_BYTE stocke un seul entier non signé de 8 bits par pixel. Cette flexibilité permet d'encoder divers types de données, même des types complexes comme double ou long long, en les segmentant sur plusieurs canaux ou pixels.

Pour notre scénario avec M entités et N attributs par entité, nous pouvons dimensionner notre texture à M par N (ou N par M, selon la préférence d'indexation), en utilisant un format flottant à quatre canaux pour une polyvalence maximale. Voici comment configurer une telle texture en utilisant OSG :

osg::ref_ptr<osg::Texture2D> pDataBufferTexture = new osg::Texture2D();

// Empêcher le redimensionnement automatique de la texture aux puissances de deux.
// Ceci est crucial pour garantir une correspondance exacte des indices lors de la lecture.
pDataBufferTexture->setResizeNonPowerOfTwoHint(false);

// Définir le format interne (GPU) et les formats source (CPU) de la texture.
// GL_RGBA et GL_FLOAT permettent de stocker 4 valeurs flottantes par pixel.
pDataBufferTexture->setInternalFormat(GL_RGBA);
pDataBufferTexture->setSourceFormat(GL_RGBA);
pDataBufferTexture->setSourceType(GL_FLOAT);

// Indiquer que les données de la texture sont susceptibles de changer fréquemment.
// Cela optimise la gestion de la mémoire GPU par le pilote.
pDataBufferTexture->setDataVariance(osg::Object::DYNAMIC);

// Configurer les filtres de minification et de magnification pour une lecture
// "Nearest Neighbor" (plus proche voisin). C'est essentiel pour éviter
// toute interpolation lors de l'échantillonnage, assurant ainsi la récupération
// exacte des données brutes stockées.
pDataBufferTexture->setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::NEAREST);
pDataBufferTexture->setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::NEAREST);

// Allouer un nouvel objet osg::Image pour contenir les données brutes de la texture.
osg::ref_ptr<osg::Image> pTextureDataSource = new osg::Image();
pTextureDataSource->setInternalTextureFormat(GL_RGBA); // Assurer la cohérence du format interne de l'image.

// Définir les dimensions de l'image. 'numEntities' correspond aux lignes (hauteur),
// et 'numAttributesPerEntity' aux colonnes (largeur). Le '1' indique une profondeur de 1 (texture 2D).
int numEntities = 100;         // Exemple: M objets, correspondant à la hauteur de la texture
int numAttributesPerEntity = 4; // Exemple: N attributs par objet, correspondant à la largeur de la texture
pTextureDataSource->allocateImage(numAttributesPerEntity, numEntities, 1, GL_RGBA, GL_FLOAT);

// Lier l'image préparée à l'objet texture.
pDataBufferTexture->setImage(pTextureDataSource);

// Note: L'initialisation des données (ex: memset à zéro) et
// l'appel à dirtyTextureObject() seront effectués après le remplissage des données.

Écriture des Données dans la Texture (C++/OSG)

Le remplissage de la texture implique d'écrire des valeurs numériques directement dans le tampon de l'osg::Image alloué. La méthode osg::Image::data(x, y) fournit un pointeur vers le début des données de pixels aux coordonnées (x, y) spécifiées. Puisque notre texture stocke quatre flottants par pixel (grâce à GL_RGBA et GL_FLOAT), nous pouvons accéder aux composants flottants individuels en décalant ce poinetur.

Supposons que nous voulions écrire une valeur pour le k-ième canal du j-ième attribut de la i-ième entité :

// Supposons que 'pDataBufferTexture' est déjà configuré et alloué.
// Supposons que 'numEntities' et 'numAttributesPerEntity' sont les dimensions de la texture.

osg::Image* currentImage = pDataBufferTexture->getImage();

// Exemple: Écrire une valeur dans le 2ème canal (index 1) du 3ème attribut (index 2) du 1er objet (index 0).
// Les indices x et y sont inversés par rapport à l'exemple précédent pour correspondre
// à la convention d'une image (largeur, hauteur) où x est la colonne (attribut) et y est la ligne (entité).
int entityRowIndex = 0;       // Index de l'entité (correspond à l'indice y dans image->data(x,y))
int attributeColIndex = 2;    // Index de l'attribut (correspond à l'indice x dans image->data(x,y))
int channelComponentIndex = 1;      // Index du canal (0 pour R, 1 pour G, 2 pour B, 3 pour A)
float valueToStore = 123.45f;

// Accéder au pointeur du pixel (attributeColIndex, entityRowIndex) et décaler pour le canal souhaité.
*((float*)(currentImage->data(attributeColIndex, entityRowIndex)) + channelComponentIndex) = valueToStore;

// Après avoir terminé toutes les écritures (ou une série d'écritures pour un "frame"),
// il est crucial d'informer OSG que la texture a été modifiée et doit être re-téléchargée vers la GPU.
// Si les données sont mises à jour très fréquemment, cet appel peut être optimisé ou groupé.
pDataBufferTexture->dirtyTextureObject();

Lecture des Données dans le Shader (GLSL)

Dans le shader GLSL, la texture agit comme une variable uniforme sampler2D. Pour récupérer correctement des points de données spécifiques, nous devons également passer les dimensions de la texture (largeur et hauteur) comme une autre uniforme de type vec2. La clé d'une récupération précise des données réside dans le calcul des coordonnées de texture (s, t), qui doivent atteindre exactement le centre du pixel désiré pour éviter toute interpolation par défaut (à moins qu'elle ne soit spécifiquement souhaitée pour d'autres effets).

// Variables uniformes pour la texture de données et ses dimensions.
uniform sampler2D   u_entityDataTexture;  // La texture contenant les données des entités
uniform vec2        u_textureDimensions;  // Les dimensions (largeur, hauteur) de la texture en pixels

// Exemple: Accéder aux données du 5ème objet (index 4) pour son 2ème attribut (index 1)
int targetEntityIndex = 4;
int targetAttributeIndex = 1;

// Calculer les coordonnées de texture (s, t) pour l'échantillonnage.
// L'ajout de 0.5f aux indices entiers est essentiel pour s'assurer que
// l'échantillonnage se fait exactement au centre du pixel. Cela est crucial
// avec un filtrage GL_NEAREST pour récupérer la valeur exacte du pixel
// et éviter des erreurs dues à l'échantillonnage des bords ou des interpolations indésirables.
float s_coord = (float(targetAttributeIndex) + 0.5f) / u_textureDimensions.x;
float t_coord = (float(targetEntityIndex) + 0.5f) / u_textureDimensions.y;

// Échantillonner la texture pour obtenir le vecteur de données (RGBA).
vec4 queriedValues = texture2D(u_entityDataTexture, vec2(s_coord, t_coord));

// Maintenant, 'queriedValues.r', 'queriedValues.g', 'queriedValues.b', 'queriedValues.a'
// contiennent les quatre valeurs flottantes stockées dans le pixel correspondant.
// Par exemple, pour récupérer le premier float :
// float firstComponentOfAttribute = queriedValues.r;

L'importance d'ajouter 0.5f aux coordonnées entières avant la normalisation (division par les dimensions de la texture) ne saurait être sous-estimée. Sans ce décalage, l'échantillonnage de la texture pourrait se produire au bord d'un pixel, conduisant à une récupération de données incohérente ou incorrecte, en particulier lorsque le filtrage GL_NEAREST est appliqué. C'est un piège courant observé dans divers contextes et il est critique pour garantir un accès précis et non interpolé aux données stockées dans les tampons de texture.