#0 

14-06-2012 13:29:57

Akabane87
Membre
Date d'inscription: 28-05-2012
Messages: 24

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

Aprs plusieurs jours de recherches sur la gnration procdurale de terrain et aprs avoir lu plusieurs centaines d'articles la dessus, j'en suis arriv la question primordiale suivante :
Dans la mesure ou je souhaite gnrer des patches de terrain d'un lod donn (= un buffer de vertices), est-il plus rapide de gnrer une fois pour toute la demande le buffer de vertices ct CPU avec leur position finale (hauteur gnre par des fonctions de bruit) et juste l'envoyer au gpu chaque frame (ou du coup la premire fois seulement si j'utilise des hardware mapping hints), ou bien de gnrer chaque frame directement depuis le gpu (avec un geometry shader) la position finale des mes vertices de chaque patch partir d'un seul et mme buffer (au final 16 buffers pour les franges de connections des patches de lod diffrents) et donc recalculer chaque frame pour chaque vertex sa hauteur partir de la fonction de bruit excute 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 considration 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 mmoris avec les hauteurs au moment de sa gnration).

Qu'en pensez vous ?

Dernire modification par Akabane87 (14-06-2012 13:32:54)

Hors ligne


#1 

14-06-2012 21:43:22

johnplayer
Habitu
Date d'inscription: 30-09-2007
Messages: 431

Je pense qu'il faut faire des tests avec des terrains de trs grande taille. Mais je serais pour laisser la charge au GPU car le CPU dj beaucoup faire. Maintenant, quel est le matriel ncessaire pour utiliser un gomtry 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 grer les collisions ou d'autres choses, faut voir comment tu t'y prendras si tu utilises les shaders.

Dernire modification par johnplayer (14-06-2012 21:45:14)


core i7 4970K @ 4GHz - 32GB ddr3 19200(2400MHz) - ssd samsung 840 evo 250GB - GTX1080Ti (4K) - Cooler master storm stryker blanc.
"L'alcool, c'est comme Activia, c'est actif à l'intérieur et ça se voit à l'extérieur."

Hors ligne


#2 

15-06-2012 13:59:46

Akabane87
Membre
Date d'inscription: 28-05-2012
Messages: 24

Pour le matriel 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 gomtrie qui n'aura pas chang qui me drange. Aprs 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 gomtrie chaque frame mais cette mthode ne m'enchante pas vraiment visuellement : on change les pop du changement de lod contre un effet de "fonte" qui peut tre bien dgueulasse dans certains cas (peut tre moins avec du normal mapping m'enfin...)
Tout a pour dire que je penche quand mme plus pour la bon vieux LOD non continu avec gnration de la gomtrie lors de l'instanciation sur le CPU et du coup en bonus la possibilit de faire des collisions sur la gomtrie 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 ct 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...).

Hors ligne


Options Liens officiels Caractristiques Statistiques Communaut
Corrections
irrlicht
irrklang
irredit
irrxml
xhtml 1.0
css 2.1
Propuls par FluxBB
Traduit par FluxBB.fr
Analys par
872 membres
1423 sujets
11109 messages
Dernier membre inscrit: Glider
3 invits en ligne
Aucun membre connect
RSS Feed

[ Gnre en 0.040 sec., 12 requtes excutes ]