Bonjour tout le monde, c'est encore moi avec mes questions de perf ^^.

Après plusieurs jours de recherches sur la génération procédurale de terrain et après avoir lu plusieurs centaines d'articles la dessus, j'en suis arrivé à la question primordiale suivante :
Dans la mesure ou je souhaite générer des patches de terrain d'un lod donné (= un buffer de vertices), est-il plus rapide de générer une fois pour toute à la demande le buffer de vertices côté CPU avec leur position finale (hauteur générée par des fonctions de bruit) et juste l'envoyer au gpu à chaque frame (ou du coup la première fois seulement si j'utilise des hardware mapping hints), ou bien de générer à chaque frame directement depuis le gpu (avec un geometry shader) la position finale des mes vertices de chaque patch à partir d'un seul et même buffer (au final 16 buffers pour les franges de connections des patches de lod différents) et donc recalculer à chaque frame pour chaque vertex sa hauteur à partir de la fonction de bruit exécutée dans le shader ?

Je suis bien conscient que le gpu peut potentiellement calculer mon bruit 100x plus vite que le cpu, mais il faut également prendre en considération le fait que ce calcul sera fait à chaque frame sur le gpu alors qu'il peut n'être fait qu'une fois sur le cpu au chargement dynamique de ma patch au moment ou j'en ai besoin (vertex buffer mémorisé avec les hauteurs au moment de sa génération).

Qu'en pensez vous ?

Dernière modification par Akabane87 (14-06-2012 13:32:54)

Je pense qu'il faut faire des tests avec des terrains de très grande taille. Mais je serais pour laisser la charge au GPU car le CPU à déjà beaucoup à faire. Maintenant, quel est le matériel nécessaire pour utiliser un géométry shader? Car il faut voir aussi le public que vise avec ton jeu. Et si tu veux mettre le paquet niveau visuel, peut-être utiliser le CPU pour équilibrer la charge.

Edit : Au fait, si tu dois gérer les collisions ou d'autres choses, faut voir comment tu t'y prendras si tu utilises les shaders.

Dernière modification par johnplayer (14-06-2012 21:45:14)

Pour le matériel en fait c'est pas bien lourd en fait ; il suffit d'avoir de geometry shader 2.0. C'est plus le fait de devoir recalculer sur plusieurs frame de la géométrie qui n'aura pas changé qui me dérange. Après il y a toujours la solution de faire du LOD continu et dans ce cas je n'aurais pas d'autre choix que de recalculer la géométrie à chaque frame mais cette méthode ne m'enchante pas vraiment visuellement : on échange les pop du changement de lod contre un effet de "fonte" qui peut être bien dégueulasse dans certains cas (peut être moins avec du normal mapping m'enfin...)
Tout ça pour dire que je penche quand même plus pour la bon vieux LOD non continu avec génération de la géométrie lors de l'instanciation sur le CPU et du coup en bonus la possibilité de faire des collisions sur la géométrie comme tu le faisais justement remarquer.

J'ai commencé tout mes test sur la solution CPU et ça marche relativement bien pour le moment. J'ai juste besoin de trouver le bon compris entre maillage suffisamment fin et FPS pas trop degueu (surtout qu'il faut que j'absorbe la latence due à chaque instanciation d'un nouveau lod (j'ai choisi de le faire dynamiquement pour ne pas avoir la mauvaise surprise d'un chargement d'une demi heure si je veux pas directement borner mon niveau max de LOD (je suis autour de 15 pour le moment mais j'aimerais monter à au moins 20)).
J'ai par contre rien essayé côté GPU parce que la solution m'emballe pas vraiment et aussi parce que je n'y connais pas grand chose en programmation de shader (comprendre ce que ça fait ok mais en coder from scratch c autre chose...).