Merci, je pouvais pas rever mieux comme explication

Bon je pete un cable la, c´est effectivement bien plus chiant que je ne l´aurais pensé.

Donc je me suis mis en quete d´une carte graphique. Et j´ai opté pour une GigaByte GeForce Fx 5700 Ultra.
J´ai lu pas mal de comparatif, et c´est une tre bonne carte d´apres ce que j´ai lu.
Maintenant me reste plus qu´a trouver le site (bien) pour l´acheter. LGV j´ai vu que tu etais en grande bretagne comme moi. Ayant deja eu un soucis avec un site anglais, j´ai pas trop envie de prendre le premier venu pour ma carte graphique. Connatrais tu un bon site serieux situer en grande bretagne ?

Bien bien... me revoilou, nouvelle carte geforcefx 6800 GT, et je connais le HLSL.
D´ailleur j´ADORE.. hihi ! Bon j´ai fini d´implementé le multitexturing sur une height map. Le multitexturing fonctionne un peux comme la height map, c´est une texture en RGB chaque couleur correspondant a une texture (herbe, neige, truc marron )
http://www.froggies-team.info/Games/FroggiesEngine/Gallerie/2.jpg

Ma question est en fait, sur la gestion des textures dans les jeux, parce que plus on s´approche plus elle sont precises.

La j´ai essayer en comparant la position de la camera avec la position d´un vertice de changer les coordonnées de texture pour que plus elle est loin moins elle est dupliqué.
Resultat : au debut mort de rire, de effets de fou, avec le sol mouvant ^^
et au final les conditions dans le vertex shader fesaient plus ramer qu´autre chose, pour un rendu... pas terrible.

Ce serais juste pour savoir comment est geré le multitexturing dans les jeux.

elles ne sont pas "plus precises", on utilise simplement un jeu de textures ou chacune a un role bien precis.

En general pour un blendmapping tu auras :
- un certain nombre de textures 24bits, les diffuse
- un certain nombre de textures 8bits pour controler le blending
- un certain nombre de textures 8bits pour l´intensite des specular
- un certain nombre de textures 8bits pour le puissance utilisee dans le calculs des speculaires
- un certain nombre de textures 24bits pour des normal maps
- un certain nombre de textures 24bits pour des detail map
- etc.

En general, on ne peut pas TOUT mettre pour cela tienne dans les 8 ou 16 slots qu´on a, et comme on veut faire le rendu en une seule passe, on ne prend que ce qui est le plus util dans notre cas ; ex. de combo courante : diffuse + blend + normals + details
En packant bien tes donnees, et en faisant qq concessions, tu peux faire du blendmapping entre 3 voire 4 jeux de textures.

Avec des textures TRES haute resolution, et des detail maps, tu dois obtenir un niveau de precision largement suffisant.
Si tu commences a vouloir faire un blendmapping adaptatif dans les shaders : 1) ca va se voir, a moins de faire 25 passes de rendu en blendant plein de niveaux de details.. 2) tu vas avoir plein de branchements dynamiques, et ca va etre horriblement lent, en plus d´etre moche.

Regarde le jeu SpellForce, c´est un bon exemple d´utilisation de detail maps.

J´ai revu et corrigé mes algo.
- en voulant faire du clipping, je me suis rendu compte que de ne pas en faire etait plus rapide.
Je m´explique, Je creer un vertex buffer contenant mes vertices, et j´a l´affiche en une fois en passant tout les vertice a la carte graphique.

Mais je ne peux pas modifier le vertex buffer sans ralentir l´appli (locker et delocker) meme si j´affiche 2 fois moins de triangles c´est toujour plus lent que d´afficher un vertex buffer en une fois.

Sinon, j´ai voulu tester avec une image haute resolution mais contenant plusieur texture, et de jouer sur les coordonnées de textures pour afficher la texture voulu. Mais j´ai pas trouver de solution pour dupliquer une texture.
Donc au final je suis revenu a ma solution de depart qui consistait a passer 4 texture a ma carte. La texture de blend, une texture de sol, une texture de neige, et une texture d´herbe.
Ma texture de blend est tres detaillé et me permet de controler un niveau de detail assez elevé.

Mais etant limité a 4 textures pour le passage a une carte graphique en pixel shader 2.0, je ne joue que sur trois textures. (en une pass)

Et j´ai pas trouvé le moyen de pouvoir en gerer plus.

J´ai beaucoup regardé les screen du jeu, et les texture de la height map. J´ai pigé le principe que tu m´as expliqué mais pas tout (au niveau des textures qui fait quoi).
En tout cas merci bien ^^ LGV.

"en voulant faire du clipping, je me suis rendu compte que de ne pas en faire etait plus rapide"

les polygones les plus rapides a afficher sont ceux que l´on dessine pas.. Visiblement ton clipping a un GROS soucis, soit dans le concept, soit dans la technique.

"je ne peux pas modifier le vertex buffer sans ralentir l´appli"

normal, c´est pas fait pour.. Deja la question, c´est pourquoi tu veux clipper des polys que tu as foutu dans des vertex buffer ? .. Tu clippes tes objets, et ensuite seulement tu construis tes VB/IB et tu les remplis.

" j´ai voulu tester avec une image haute resolution mais contenant plusieur texture, et de jouer sur les coordonnées de textures"

c´est l´idee des "texture atlases" ou "texture banks" ; ca s´adapte bien a des choses comme des particules, des morceaux de GUI, etc. Mais pour du blendmapping, c´est pas vraiment l´ideal. Surtout que ca te ferait sampler la meme texture plusieurs fois par pixel, ce qui peut etre couteux.

"dupliquer une texture"

? pas bien compris :-?
Enfin pour utiliser plusieurs textures dans une meme passe de rendu, il suffit d´en informer le device via les texture stages.

"ma solution de depart qui consistait a passer 4 texture a ma carte"

ah ben tiens quand on parle :D

"Ma texture de blend est tres detaillé"

idealement, la texture de blend devrait etre la plus grand possible, mais comme pour tout il suffit de trouver le bon compromis. Les autres textures sont justes tilees sur le landscape (sampler en UV wrap), alors que le blend est plaque une seule fois (sampler en UV clamp).

"etant limité a 4 textures pour le passage a une carte graphique en pixel shader 2.0"

nope, 8. Et cela n´est pas liee a la version des VS/PS. A part une antiquite de plus de 4 ans, et encore, je ne vois pas comment ta carte ne pourrait en gerer que 4.. Ajd on monte a 16 d´ailleurs avec le dernier materiel.

" mais pas tout"

en l´etat actuel tu utilises une texture de blending et 3 diffuses. 24 bits + 3x24 bits => 96 bits, sur les 256 theoriques (8 textures RGBA) (ou alors disons 128 si tu as une vieille carte limitee a 4 textures). Il te reste 160 bits dans les "slots" textures que tu utiliser comme tu veux pour "ajouter" de l´information.
Avec un PS adapte, des normal maps, et du specular, tu peux faire du per-pixel lighting tres precis. Avec des details maps tu peux avoir des details tres fins quand la camera est proche du relief, etc. Ce ne sont que d´autres textures utilisees differement dans les calculs.

non non, c´est bon j´ai verifié par le suite, et je me suis dis, "mais quel con" quand j´ai vu que je pouvais monter a 16 texture. pour le moment je joue avec 5 texture, et en multipliant la couleur on peut obtenir des rendu tres interessant.

Sinon je t´explique au debut je contruisais ma map a partir de mon image pgm. et je stockais les vertices dans mon vertexbuffer. (a l´initialisation). Et je me sentait pas de reconstruire un vertex buffer a chaque frame.

finalement j´ai une tout autre methode, et qui marche super bien. je subdivise une height map en plusieurs. et j´effectue mon clipping sur ces height map.
http://www.froggies-team.info/gallerie.php?id=14&image=Games/FroggiesEngine/Gallerie/2.jpg

Ce qui me permet de faire des niveau plus que gigantesque sans afficher plus de poly. j´ai testé avec 64 height map qui n´en forment au final qu´une grande. comme sur le screen j´ai en moyenne 3 height map d´affiché ~40 000 Poly.

http://www.froggies-team.info/gallerie.php?id=14&image=Games/FroggiesEngine/Gallerie/1.jpg

pour la texture de blend, je fais peut etre une confusion avec la detail texture. Je creer une tres grande texture sous toshop en RGB et j´analyse l´image dans le shader chaque couleur correspondant a une texture particuliere.
- noir herbe
- jaune feuille
- rouge neige
- vert roche
- bleu pierre taillé

il me reste encore 2 canneaux de texture.. pour les ombre je pense faire une comparaison entre le vecteur "lumiere" et la normal du vertice.
c´est juste un dot() c´est fait super rapidement.

Enfin la je suis heureux, j´ai corriger les bug. au niveau des jointures entre les map et d´autre truc genant.

l´avantage de mon system est que pour chaque map j´ai un shader associé, pour l´instant ils ont tous le meme. Mais ca me permet de varier les paysages, et les texture facilement.

"je subdivise une height map en plusieurs [..]"

tu peux aller plus loin :
- mettre tes patches de landscape dans un quadtree contraint => culling TRES rapide et tout aussi efficace
- faire des LOD de tes patches de landscape (un morceau en 64x64, le meme en 32x32, le meme en 16x16, etc.) ; au runtime, selon un critere (betement, distance a la camera : simpliste mais pas des plus efficaces ; on preferera un critere sur l´aire de la projection du patch), tu connectes des patches de LOD differents (gaffe aux jointures..)

=> nombre de polys treees bas (qq milliers), et quasiment constant, pour une excellente qualite.
(un vieux truc que j´ai code y´a 2 ans, dans cette optique : http://netabarons.chez.tiscali.fr/downloads/landscape.ace )
En poussant un point, on tombe dans le geomipmorphing, qui consiste a faire exactement la meme chose, en morphant dynamiquement les patches pour passer d´un LOD a l´autre (histoire d´eviter le "popping" de la geometrie)

Le temps gagne,tu peux le passer dans un shader plus complexe, et ce sera encore plus rapide que sans LOD.

pour info, avec 40000 polys pour un landscape "vide", ca bouffe deja plus de 10% de ce que fait un jeu actuel treeees fourni au niveau graphique.
Comme toujours, c´est bien :D mais on peut faire mieux ;) je ne peux que t´encourage a pousser vers les LODs et les VB dynamiques, tu auras tot ou tard le pb de performances, de toute facon.

" je me sentait pas de reconstruire un vertex buffer a chaque frame"

c´est pourtant la bonne facon de proceder ; construire un vertex buffer ne coute "rien" ; par contre il faut optimiser la collection des vertices pour le remplir.
pour de l´herbe ou des choses comme ca, on genere sans soucis a chaque frame des VB/IB enormes de plusieurs dizaines milliers de vertices.

" j´analyse l´image dans le shader"

j´ai peur de mal comprendre... Ferais-tu du branchement conditionnel ? genre "si mon pixel est bleu, faire un lookup dans telle texture, etc." ? Si c´est le cas, c´est un perf-killer ENORME !
le code doit etre sequentiel autant que possible ; et la, tu risques en plus d´avoir des pbs avec la compression (si tu me dis ne pas utiliser de compression, je dirais qu´alors tu as des pbs de cache ). Bref, il faufrait me preciser, mais j´ai dans l´idee que cette partie est conceptuellement a affiner.

"c´est juste un dot() c´est fait super rapidement."

modele lambertien => c´est rapide... mais c´est tout c´est ce que fait par defaut le lighting du "fixed function pipeline" (sans composante speculaire)
L´eclairage joue ENORMEMENT dans la qualite du terrain ; sans aller dans les shadow map (au debut.. ca viendra ;) ), je te recommande fortement : du phong, des normal maps, et du specular. Tu verras que cela n´a RIEN A VOIR.

bon courage pour la suite :D

(oui je suis chiant a toujours dire qu´on peut faire mieux, mais pour une fois que qqun produit qqch de concret, j´en profite ;) )

encore un point :

" pour chaque map j´ai un shader associé"

ce qui veut dire rendre plusieurs primitives. As-tu du nombres de vertices par primitives ? en dessous de qq milliers, c´est un perf-killer, et il faudra unifier les vertices/shaders pour batcher un maximum. Si tu as une nVidia, utilise leur nvPerfHUD pour analyser ta geometrie.

Merci bien. pour tout ces renseignement, mais comme pour chacun de tes post je n´en comprends que la moitier maintenant, et l´autre moitier quand je l´aurais fais ^^ lol
en fait je fonctionne de cette maniere.
ma heightMap
http://www.froggies-team.info/images/Divers/heightMap.jpg
et une texture que j´appel textureMap
http://www.froggies-team.info/images/Divers/textureMap.jpg
et je fais un lerp en fonction des composante RGB et des mes textures.

Pour les LOD je me sens pas. si j´ai pas le meme nombre de vertices j´arriverais pas a joindre deux map

Par contre je vais me pencher sur la creation de VB dynamique, si tu dis que c´est rapide.

Pour le perf-killer, il est plus rapide a afficher mon multitexturing en shader qu´a appliquer un texture de maniere normal.
Pour le rendu des lumiere je me pencherais bien dessus quand je serais satisfait du nombres de vertices a l´ecran. Je ne fais aucune condition dans les shader.

dans ta petite demo je comprends pas le fonctionnement des tri. enfin plutot ce qu´ils representent concretement.

chaque map 50x50 ~ 2500 vertices. en moyenne 7500 vertices pour la map. D´un autre coté trois primitives ne vont pas me tuer les performance.

Vu que je l´ai deja programmé j´integrerais le phong d´ici peu, ensuite bumper le sol... c´est gourmand en ressource et ca me fait calculer toute les tangente de la carte. (c´est pas la mort, mais je l´ai pas encore fait)

" je n´en comprends que la moitier maintenant"

ah.. ben dis moi ce qui te gene, je peux toujours detailler certaines choses..

"Pour les LOD je me sens pas"

allons allons, il faut bien un peu de difficulte pour que cela soit amusant :D

"la creation de VB dynamique, si tu dis que c´est rapide"

ca ne coute "rien" de creer un nouveau VB ; mais si tu ne fais pas de LOD, ta geometrie reste statique.. tu peux remplir ton VB une seule fois, et par contre remplir l´IB a chaque frame en fonction du culling ( > toute la geometrie, statique, est dans le VB, mais via l´IB tu ne rend que les morceaux que tu veux)

"Je ne fais aucune condition dans les shader"

impec !

" je comprends pas le fonctionnement des tri. enfin plutot ce qu´ils representent"

les "tris" ? .. euh, le nombre de triangles affiches ?

"D´un autre coté trois primitives ne vont pas me tuer les performance."

vu la taille de tes VB c´est raisonnables ; le nombre de "draw primitive" devient un pb quand on a plusieurs dizaines, voire centaines, de petits VB (moins 1000 vertices)

"ensuite bumper le sol... c´est gourmand en ressource"

=> normal map !! ! ... bcp plus interessant au niveau visuel, et aucune difficulte supplementaire compare a un bump classique.

On viens d´integrer les skinned mesh.
http://www.froggies-team.info/Games/FroggiesEngine/Gallerie/3.jpg

Pour le terrain, j´ai mis un clipping pour l´affichage des vertices. M´ai par rapport a l´optimisation par map, je gagne pratiquement rien, (2000-3000 point).
Et je perds en FPS un peux en FPS (les parcourt de tableau).

Juste un point a eclaircir.
La difference entre bump mapping et normal mapping.
J´ai deja programmer du bump en Cg, et on deduit la normal avec l´image, pour l´afficher en fonction de la position de la lumiere.

La il faut juste que je revois l´interpolation entre quatre point, pour retourner la valeur de hauteur de la heightmap. le mesh a tendance a avoir les pied sous terre parfois.

" j´ai mis un clipping pour l´affichage des vertices. M´ai par rapport a l´optimisation par map, je gagne pratiquement rien"

si tes morceaux de landscape sont assez "fins" (= representent une petite portion de l´ecran), le clipping par morceaux est suffisant : on se contrfous que qq vertices en dehors du frustum soit quand meme transmis. Si par la suite tes morceaux de terrain augmentent en terme d´echelle, il sera p-e interessant de re-considerer un clipping plus fin.

"La difference entre bump mapping et normal mapping."

dans l´absolu, le bumpmapping va modifier localement les normales de ta surface, alors que le normal mapping contient la normale en elle-meme. Apres, c´est tres fin et depend des personnes ;)
dans l´un ou l´autre des cas, mon conseil est d´utiliser un texture en greyscale pour le relief (= une heightmap quoi), et de calculer la bump/normal mal a la main. Pourquoi ? 1) c´est plus facil pour les artistes (meme si les filtres nVidia pour photoshop par ex. sont pratiques) 2) parce qu´avec ca tu peux facilement faire du parallax mapping (ou offset bump mapping, selon les appelations) 3) parce que sur une archi recente tu pourras tenter le displacement mapping a partir de la height map (en utilisant le vertex texture fetch, ou le truc equivalent sur les dernieres ATI)
Bref, meme si ca te sert pas pour l´instant, tu pourras evoluer facilement sans tout repenser en terme de code.

Bon, en y reflechissant plus je suis moyennement content.
Je vais revoir a utiliser le clipping par vertice ce qui me pose probleme c´est qu´en testant les point un par un pour savoir si ils sont dans le frustum je n´ai pas les triangles fini aux limites de l´ecran (les dents de scie qui se voient).
Enfin ca me permettra de faire du LOD, plus facilement aussi.
Sinon pour faire du brouillard en shader c´est gourmand ou pas...

Ah j´ai eu un petit soucis avec les textures le splatting. j´ai mis comme paramettre magfilter=LINEAR pour la texture de detail. si je ne le mes pas a LINEAR j´ai des gros paté carré comme texture. Mais a l´extreminer de chaque map il fait une interpolation pour repeter la texture ce que je ne veux pas, parce que quand j´arrive au bout d´une map il commence a repeter le debut de la texture ce qui creer de grosses demarcation au niveau de jointure.

pour le moment ma solution a ete de decaler les coordonnée de texture pour que ca ne se vois plus, mais c´est un peut... barbare, c´est pareil pour la skybox, en le mettant a LINEAR on distingue un filet blanc entre les quad. en si on ne le met pas a LINEAR, on vois les gros pixels de la skybox

Sinon, est-ce une bonne idée de rajouter pour le clipping un test pour savoir si c´est une face visible ou non.
dot product entre le vecteur de la camera et la normal d´une face.

"clipping par vertice"

travaille avec des morceaux de landscape plus petits, et garde ton clipping par morceau ; si tu testes chaque vertices 1) ca va prendre un temps fou 2) tu vas t´amuser pour recontruire la geometrie clippee
Si tu as des morceaux de landscape sous forme implicite (i.e. oh j´ai ici un beau plateau qui est un gros plan bien plat), tu peux le faire a coup d´equations, mais sinon c´est s´embeter pour peu de chose.
Alternativement, pour certaines choses tu peux proceder differement : par ex. pour une surface d´eau, tu peux travailler sur le contour ; tu clippes le contour, et tu tesselates la partie clippee. Pour un landscape, ce n´est par contre pas la bonne approche.
=> plein de petits patches de landscape dans un quadtree, et tu as une solution optimale : culling rapide, precis, et LOD implicite.

"petit soucis avec les textures le splatting"

pour la skybox, travaille avec des textures HAUTE resolution, certaines tilees, d´autres non. Si tu veux un fond etoile par ex. utilises une texture moins precise (i.e. 512x512) tilee en 4x4 sur le dome. Si par contre tu veux une autre layer avec des choses tres precises (i.e. constellations avec formes reconnaissables), monte direct en 2048x2048, voire 4096x4096. Attention quand meme a l´utilisation memoire totale..
Morrowind est un bon exemple : nombreux layers haut resolution, mappes differement.
Sinon, il faut bien effectivement filtrer tes textures ; ton autre soucis de jointure viens du mode d´adressage. Quand tu definis un sampler, il peut utiliser les UV de manieres differentes : tile (aka wrap/repeat , ce que tu as), clamp (UVs bornes entre 0 et 1), et mirror. Dans ton cas les textures que tu ne veux pas repeter doivent simplement etre en mode "clamp" ; et pour etre consistant, tes UVs doivent etre entre 0 et 1 (sans quoi tu vas voir apparaitre des etirement aux bords de la texture).

Et sache que quand on met plusieurs textures ensembles dans un meme bitmap, et qu´on joue sur les UVs pour choisir telle ou telle partie de l´image, on "hack" souvent les UVs pour eviter ces debordements (ie. si on a 2 images juxtaposees horizontalement, le milieu devrait etre 0.5 en U, mais on utilisera plutot 0.49 et 0.51).
Dans le cas de texture atlases, c´est normal de proceder ainsi.

"du brouillard en shader c´est gourmand ou pas"

non pas du tout ; il suffit d´ecrire une valeur de "fog" en sorti du PS, et... c´est tout ! Si apres tu fait des calculs complexes pour determiner cette valeur, c´est ton probleme, mais du cote "rendu" ca ne coute "rien".

"est-ce une bonne idée de rajouter pour le clipping un test pour savoir si c´est une face visible ou non"

pas vraiment ; c´est a la fois "trop fin" et "pas assez fin" comme niveau de clipping.

trop fin, parce que ca te fais travailler au niveau des faces et des vertices => bcp de calculs simples pour virer qq faces. De plus avec du backface culling en CCW ou CW selon ton cas, cette geometrie ne sera pas rendue. => tu risques de passer plus de temps a tester tes faces, que cela n´en prendra au hardware a discarder qq valeurs inutiles dans le VB.
pas assez fin, parce que si tu te lances la dedans il faudrait allez voir du cote de l´occlusion, pour avoir un mechanisme generalise. La ca devient bcp plus complique ; je reserve ca pour un autre thread si le coeur t´en dis ;)

bref, tu peux tenter, c´est facile et rapide a mettre en oeuvre, mais je ne m´attendrais pas, sauf cas particulier (i.e. tesselation tres fine, bcp de relief important) a uns veritable amelioration.

Yo.
J´ai une petite question, toujours sur les heightmap, je suis pas satisfait.

Comment avoir une visibilité elevé, un bon niveau de detail de texture et que ca ne rame pas du tout.

Sinon j´ai rajouté 3 niveau de LOD pour les map, et comme prevu le probleme ce sont les jointure entre les map n´ayant pas de meme nombre de vertices.

pour mon spatting de texture pour ma map, je vais voir a remplacer les lerp par une multiplcation toute simple, parce que pour le moment j´en effectuais 5 de suite (un par texture) et ca rame sur la 5200 de Ruffi (evidement avec la 6800 le frame rate est bloqué a 60fps je voyait pas)

Quite a tout reprendre, le multi-heightmap est-ce une bonne solution. Parce que plus la height map est petite, plus j´en affiches.

merci.