Discussion :

[_gan_]

Bonjour, bonjour, je suis venu ici pour une question assez pointue et probablement mille fois posée mais a laquelle je n'ai pas pu trouver de reponse correcte, tout les posts etants vieux et pas bien a jour avec les dernieres version d'ogl qui ont changé pas mal de choses.

Dans une scene typique (disons cs_assault en cocultant le fait que les bsp ne sont pas z-testé) sinon on ne va pas s'en sortir), on rencontre rarement plus d'une dizaine d'objets de meme type ce qui limite fortement l'interet de batcher autrement qu'en separant les objet par type de z buffering et de blending (un changement complet du pipeline restant uber-lourd). Les cartes recentes (opengl 3+) beneficient de plus d'obtimisations consequentes pour limiter les testes de profondeur inutiles et donc les pertes de fillrate et de framerate dues a une scene dessinée dans un ordre arbitraire . Voici donc la question : est il encore utile de trier ses batchs par materiaux pour minimiser les state changes plutot que par Z pour avoir le hierachical-z (la question ne se pose pas pour les cas extremes genre zerg-swarm qui necessitent un traitement specifique) Si oui, peut on faire les deux efficacement en meme temps ?


merci d'avance pour vos eclaircissements/conseils =D

[bafman]

toujours, toujours, toujours
(vraiment toujours)
essayer de limiter le nombre de batch !!!

En fait, les développeurs de moteurs modernes passent un temps fou à essayer de réduire le nombre de batch d'affichage.

regarde du coté des atlas de textures par exemple pour voir comment, en regroupant des textures, on peut réduire ce nombre de batch.

L'optimisation du z order n'aura qu'une influence limitée sur les performances.

[_gan_]

Merci d'une reponce aussi rapide et claire !

Ce que je fais pour le moment est mettre les batchs dans une multimap en utilisant comme clef un uint64 représentant la signature du material (en gros je compacte tout sur 64 bits en mettant les changements d’état les plus lourds dans les bits de poids les plus forts) puis j’itère sur ma map ce qui me donne les matériaux dans un ordre a peu pres coherent (le problème de batcher de façon parfaite étant np je me contente d'une approximation)

je pense aussi atlasser les textures au chargement des matériaux (pourquoi pas un seul atlas pour tout façon virtual texture même (ou un atlas par mode de filtrage pour éviter les problèmes)).

Est ce suffisant ou dois je prévoir un truc plus efficace pour grouper mes matériaux (les technique décrite revient a faire exactement :

bool operator<(Batch b) {

if(translutent != b.transluent) return !transluent;
if(blendMode != b.blendMode) return (int)blendMode < (int)b.blendMode;
...

}

en plus rapide (1 seule comparaison à faire), ce qui reste vachement limité)

[bafman]

a priori, c'est ce qu'il faut faire. après, tout dépend de ce que tu souhaite afficher