spectras> non, ca c'est bon que pour les faces blendees en additif, ou tu te contrefous de l'ordre Z, y a pas d'alpha qui entre en jeu, la je parlais des faces _alpha_ blendees, ou la couleur finale est donnee avec couleur_d'origine * A + couleur_frame_buffer * B, ou l'alpha de la source ou du frame buffer entre en compte dans A ou dans B.
comme tu peux avoir certaines parties totalement opaques et certaines parties totalement transparentes sur la surface, t'es oblige de les afficher d'arriere en avant, surtout que
la couleur finale est completement dependante de l'ordre dans lequel tu les affiche.
par contre les faces alpha testees elles ont pas besoin de tri, elles peuvent etre affichees comme les faces normales avec les zwrites actives sans pbl...

Si t'as pas trop d'objets avec transparence ou que tu fais que des transformations simples, tu perds pas grand chose en vitesse

bah de tte facons tu perds rien en vitesse, t'en gagne dans le cas des faces additives, vu que t'as pas de tri a faire comme si le zbuffer etait active (le tri a de ttes facons un overhead insignifiant si tu utilise la coherence d'une frame a l'autre, en gardant l'ordre de tri de la frame d'avant, il y aura tres peu de faces a retrier d'une frame a l'autre, un coup de radix sort les premieres frame, pis merge sort pour celles d'apres, ou meme un truc encore plus balau, je sais pas comment ca s'appelle, qui a normalement des perfs minables, qui fait des passes dans le tableau a trier tant qu'il est pas trie, et qui swap deux elements des qu'il en trouve qui ont besoin d'etre swappes, et t'as un cout de tri insignifiant).
et dans le cas des faces alpha blendees, t'as pas de pertes de perfs non plus, vu que tu les affiches d'avant en arriere, ton zbuffer te sert a rien et cull aucun fragment de toutes facons.