Game Connection 2013 – Europe : Techniques OpenGL ES avancées dans la série des GTA

Le pilote graphique gère la mémoire de façon basique. Il ne sait pas quel est le meilleur moment pour libérer la mémoire et peut donc appeler le ramasse-miettes à un moment pénalisant. De plus, la mémoire devient de plus en plus fragmentée, provoquant de plus en plus de saccades. La solution est de n'effectuer qu'une seule allocation pour tous les tampons. De plus, il est conseillé de construire ses tampons de façon à utiliser au mieux le cache. Finalement, le second avantage est que le rassemblement des tampons vous permettra d'éviter des changements d'état. En étant flexible sur les attributs de sommets, il vous sera possible de stocker différents formats dans un même tampon.

Ne faites jamais de glBufferSubData() l'implémentation de cette fonction est horrible.

La compilation des shaders est effectuée à la volée durant l'exécution. Afin d'éviter des ralentissements dus à cette compilation, il est nécessaire d'exécuter (avec zéro triangle) chaque shader durant le chargement de l'application. De plus, il est nécessaire de le faire avec tous les formats de cible de rendu utilisés ainsi que les états de transparence afin que l'exécution du shader ne soit pas optimisée et que toutes les portions de code soient parcourues.

Vous pouvez éviter les glDeleteTextures() en gérant vous-même une liste FIFO de textures libres. Ainsi, lorsque vous avez besoin d'envoyer une texture sur la carte graphique, vous pouvez réutiliser un emplacement libéré auparavant et ainsi éviter une gestion de la mémoire par le pilote. Lors de votre recherche pour un emplacement libre, vous devez vérifier la taille des textures. Finalement, ne mettez pas à jour une texture qui a été affichée quelques images auparavant.

Le pilote graphique possède une queue de commandes qui se remplit au fur et à mesure des appels aux fonctions de dessin. Pour les mobiles, celle-ci peut se remplir après environ 300 appels (nombre qui peut être plus petit avec les moteurs de rendu en tuiles). Une fois que la queue est pleine, le pilote vide entièrement la queue avant de redonner la main au programme appelant.

Pour contourner cela, il est nécessaire de gérer soi-même le threading des appels OpenGL. La majorité de ces appels ne nécessite pas de connaître les valeurs de retour. Tout le monde pense que le pilote ne bloque pas sur les appels de la bibliothèque OpenGL. En écrivant un système de queue basé sur le principe du producteur/consommateur où chaque appel OpenGL posséderait une surcharge permettant de soumettre la commande à la queue qui sera traitée par un thread exclusif.

Il est nécessaire de faire un petit travail supplémentaire pour les textures et les tampons. De plus, il est possible de faire facilement des opérations atomiques avec __sync_fetch_and_sub afin d'éviter les verrous.

Les consoles ont leurs propres algorithmes pour le rendu des couleurs. Afin d'avoir une palette, vous pouvez créer une texture 3D de dimension 16 x 16 x 16 pour représenter toutes les couleurs visibles. Ensuite, vous pouvez demander à vos artistes de personnaliser cette palette.

Il n'est pour autant pas facile d'utiliser une telle texture sur les mobiles. L'utilisation d'une texture 3D n'est pas directement supportée et si vous souhaitez le faire, cela nécessite d'utiliser des opérations mathématiques coûteuses. Une utilisation directe est aussi coûteuse à cause du placement de la texture en cache.

Pour éviter tout cela, utilisez une simple régression linéaire sur les 256 couleurs pour déterminer une approximation du dégradé et interceptez chaque couleur d'une dimension par rapport aux dimensions des autres couleurs. Ainsi, vous pourrez déterminer la contribution de chacune.

Ces opérations sont rapides et assez précises. Comme ce sont de simples matrices, l'interpolation linéaire entre elles est simple. Toutefois, sachant que les courbes de couleurs ne sont que de simples lignes, la balance et les ajustements de contraste sont limités. Vous pouvez le coder comme suit :

precision mediump float; 
uniform sampler2D Diffuse; 
varying mediump vec2 Out_Tex0; 
uniform mediump vec4 RedGrade; 
uniform mediump vec4 GreenGrade; 
uniform mediump vec4 BlueGrade; 
void main(){ 
    vec4 color = texture2D(Diffuse, Out_Tex0); 
    gl_FragColor.x = dot(color, RedGrade); 
    gl_FragColor.y = dot(color, GreenGrade); 
    gl_FragColor.z = dot(color, BlueGrade); 
};

Vous pouvez créer plusieurs approximations et les ajouter par composante.

Voici les différentes passes utilisées chez War Drum Studios pour obtenir les ombres :

Pour le tampon d'ombre, il est conseillé d'utiliser un fond noir et une transparence additive avec du blanc. La phase de combinaison utilise la différence entre les lumières ambiantes et les lumières directionnelles comme couleur pour l'ombre.

Cette méthode fonctionne avec les techniques d'ombrage basées sur le « decal », le « stencil » et les « shadow maps » et cela, pour toutes les plateformes et donne de meilleures ombres. Toutefois, la résolution de l'image d'ombrage peut provoquer un petit délai dans le pilote graphique.

V-C-1. Revue des différentes techniques▲

V-C-2. Sphere mapping et un peu plus▲

V-C-3. Implémentation▲

ReflPos = normalize(WorldPos.xyz - CameraPos.xyz); 
ReflUV = normalize(ReflPos.xy) * (ReflPos.z * 0.5 + 0.5);