oula, j’avais pas suivi l’affaire … ben félicitation et bon courage pour la suite.
Les questions sur le rendu et l’optimisation m’intéressent et j’ai des remarques à faire.
vers 2002 (environ), pour optimiser sur OpenGL avec les drivers de l’époque, il y avait la bidouille suivante (ce qui suit ne s’applique pas forcément au driver actuel de morphos ou aux drivers PC d’aujourd’hui selon leurs implémentations, donc à tester)
Les GPU ont des caches pour les vertex, mais ces caches sont opérationnels que pour un petit nombre de vertex (qui varie et qu’on peut avoir avec un glGet en 1.x si je me souviens bien (après vérif: c’était peut etre en EXT)).
en GL1.2/1.4 dans les années 90, un glNewList(GL_COMPILE) était déjà sencé pouvoir déclarer une base de vertex “en GPU”. Mais depuis quelques années, c’est les VBO qui sont plutôt conseillé pour ça.
Parenthèse: Oublions pas que OpenGL est un “serveur graphique”, et qu’originellement c’est architecturé comme un plugin de serveur X (2d). sous un glx, on est sencé pouvoir faire tourner un rendu GL sur une machine distante, avec la partie CPU qui tourne chez soit et la partie GL sur le distant. Tout ça pour dire: la logique de mettre les vertex en cache (sur le distant) à toujours été là dans GL, fin de la parenthèse.
Tout ça pour dire: pas mal de demo PC de la période “2000” faisaient juste tourner des cubes, avec juste des translation/rotations de matrices entre le dessin des cubes (cf neandertaler, et des tas d’autres): en fait c’est pas parce qu’ils trouvaient les cubes jolis, c’est parce que comme ça ils pouvaient effectivement afficher plus de polygones, plus rapidement: les vertex du cube était gardé en cache.
(aussi lire le papier de carmack de quake 2 sur le rendu des courbes et sa techno de LOD avec vertex partagé. )
Aussi: les 6 triangles des cotés visible d’un cube (ou tout un cube) peuvent être desinées avec un seul GL_TRIANGLE_STRIP (ou un GL_TRIANGLE_FAN si on a besoin que des trois faces visibles).
Le fait qu’un seul appel de dessin, dessine le plus de triangle possible, est sensé optimiser les tests qui sont fait pour le culling écran/clipplane ,car ( si c’est l’algo que je pense là derrière dans le driver) le premier test discriminant des drivers GL teste rapidement la primitive lourde, et peut “passer” et ne pas faire les tests par triangles.
Autre technique plus ou moins applicable: pour les cubes qui sont suffisament petits et éloigné devant pour que la perspective joue moins sur les cubes: par frame, pré-rendre les différents cubes possible sur de petites textures en FBO (64×64) avec l’angle de rotation camera, et pas de perspective, puis hop, rendre un billboard (quad) par cube pour faire le fond. En théorie: moins de poly, plus de pixels traités, mais plus rapide quand même (enfin, “de mon temps”, c’était ça, quoiqu’un dessin de cube est rapide, donc pas sûr).
… ah oui, aussi: activer le MIMAP filtering (genre GL_TEXTURE_MIN_FILTER GL_NEAREST_MIPMAP_NEAREST): ça sert pas qu’à faire joli, ça accélére aussi: les polys du fond affichent “petit” des textures plus grosse, et les bus GPU aiment pas. Avec le MIPMAP, les polys du fond lisent moins de mémoire vidéo pour les textures (ils choisissent la version adaptée), ça peut accélérer bien (ou autre idée: rendre par slice en Z et faire son mipmap à soit en utilisant la texture adaptée. (-mais bon les textures minecraft ont l’air pas trés grosse.)
bah hop.
