Reprise du message précédent :
si tu es abonne a gdmag..
 
LeGreg

je le fus, mais plus la....tant piche

petit up pour savoir si y'a eu du neuf entre tps. Perso g du completement laisser tomber cette partie vu que j'avais autre chose sur le feu mais je compte bien m'y remettre bientot
 
le seul truc que j'ai vaguement vu c le mapping, en utilisant les PS1.4 il est possible de faire un texture splatting avec 4 textures + 1 detail en une passe. ca peut etre interessant, reste a savoir si 4 textures sont suffisantes

http://www.binstar.com/
 
(taÿlaÿchargaÿ la video)

'lut,
 
je viens de tomber sur ce post et ça tombe bien
 
je suis en train de créer un paysage à partir de données gTopo30.
la structure est lue tout est en place mais un bloc fait 28 millions de vertices...
 
à partir du moment où c'est à faire bouger (simu de vol) mais que je n'ai pas besoin de ces 28 millions de point à tout moment (rect de 6000x4800km), j'ai qques soucis car c'est la première fois que je joue avec ça...
 
existe-t-il un ou des sites présentant des algorithmes permettant de naviguer rapidement à travers une maille aussi grosse ?
 
j'ai bien quelqus trucs en cours de méditation mais sans expérience dans ce domaine, je passe plus de temps à débugguer qu'à expérimenter

heuh j'imagine que oui, meme si je n'ai pas de nom a te donner (a part climap, mais ca c pour les textures )
 
Avec l'arsenal stdart (quadtree) ca passe pas ? ou meme une bete grille ? J'imagine que la premiere chose a faire c'Est d'eviter de se trimbaler les 28M de vertex en RAM.
 
Je t'avouerais que la je vois pas trop vu que moi je me concentre plus sur une vue type "promeneur" (detail au sol important, horizon pas trop loin) que simulateur de vol....
 
Y'a un article qui traine sur le net et qui doit s'appeler "visualization of large landscape made easy", va faire un tour sur www.vterrain.org elle doit etre linké (je ne sais pas du tout ce que ca vaut, comme docu)
 
'muse toi bien !

un problème à la fois...

exactly...

bah je voudrais pouvoir regarder au grand maximum à 50nm
j'ai un avantage c'est que je ne dois gérer que la vue extérieure. pas de calcul savant autre car la position de la caméra est mise à jour via réseau (visualiseur externe)

j'y vais de ce pas.

merci monsieur

sinon y'a un truc qui pourrait être drôle.
 
ce serait d'utiliser un mix texture de bump+ texture procédurale.
 
genre tu produit une info de couleur en fontion de l'altitude+et de la pente (ptet passer par des textures).
+ tu bump la chose.
 
ou alors voir carrément perturber ce qui est obtenu de la texture de bump en fonction de la pente.
 
imaginons un désert:
 
des dunes douces, le vecteur normal du vertex est orienté vers le soleil avec un peu de variation, on bump la dune avec une texture simulant les ondulations de sable dû au vent, y'a peu de variations.
 
un pic rocheux, le vecteur normal est très à "l'horizontal", on bruite ce qui est échantillonné de la texture de bump.
 
j'sais pas si voyez l'idée
 
on pourrait utiliser une texture 1D donnant le ton global des couleurs en fonction de l'altitude.
une texture 2D de bump.
une texture 1D ou 2D de perturbation.
ptet une autre texture 1D faisant varier la perturbation en fonction de l'altitude.
 
et le calcul fait:
pixel=ton_global(altitude)*bump_pertubé(texture_bump,vecteur_normal,texture2d_perturbation,perturbation(altitude) )^soleil

on pourrait aussi faire:
 
on a le terrain, et on utilise une texture 2D basse résolution  avec un seul channel.
 
ce channel nous donne un indice flottant (après filtrage bilinéaire) qui sera utilisé comme le X d'une autre texture.
le Y de cette texture sera obtenu en fonction de l'altitude du vertex.
 
on aura donc une table nous donnant la variation de ton global en fonction de l'altitude, mais grace à une texture 2D de tout le terrain, on obtient la "classe" de la zone du vertex.
 
en gros dans la texture 2D tu mets la progression en X du ton du terrain en fonction de part exemple désert->zone tempérée->montagne.
 
une fois qu'a le ton local en fonction de la zone et de l'altitude, on peurt bumper ou mettre une texture de détail.
l'idéal serait aussi de perturber la texture de bump ou de détail en fonction d'autres paramètres

'tain...j'ai juste compris l'idée... l'est grand-temps que je lise plein d'article moi

I got it!
(il était devant mes mirettes et je viens seulement de le trouver )
http://www.gvu.gatech.edu/people/p [...] tion2001a/

bon ben apres avoir ete distrait par des compilos, des arbres et de l'antialiasing, me revoila sur le terrain.
 
En farfouillant sur gdev j'ai trouvé ce thread qui ma foi propose un LOD assez interessant ( http://www.gamedev.net/community/f [...] _id=149948, en plus par un francais, algorithme national de qualite, donc ).
 
Les avantages de la bete sont une absence de crack entre deux niveau de details et le geomorph pour pas cher (toujours de bon gout). Lorsqu'un secteur approche du viewer il est splitté (en 4 fils, donc)
 
 
J'ai commencer a implanter ca mais y'a encore pas mal de boulot avant que j'obtienne un affichage (vu que c'est la premiere fois que j'utilise en grandeur nature notre bins pour les VS (entre autre), ca risque d'etre un peu folklo)
 
Voila l'idee generale du moteur tel que je l'envisage :
 
 
->> Geometrie
 
->Sur disque
Stockage du paysage a raison d'un octet par hauteur. Cet octet ne donne pas la hauteur precise mais plutot une idee de la hauteur (genre 5=200m d'altitude). Autrement dit apres relecture et affichage direct on aura un paysage bien carré (notez que 16 valeurs peuvent suffir, permettant de tomber a 4bits / vertex. Ca devrait suffir pour nos pb de stockage)
 
->Decoupage
Le terrain est découpé en secteur. Chaque secteur utilise 9x9 pixels du disque
 
->Chargement & lissage d'un secteur
Un secteur pompe sur le disque ces 9x9 pixels, puis reinterpole tout ca en en 33x33 pour un premier lissage. Lors du split d'un secteur, les 4 fils reutilisent un sous ensemble des 9x9 pixels, sous ensemble qui sera a nouveau repassé en 33x33.
 
->Noise
Pour ne pas avoir un paysage trop lisse, je pense recoller par dessus une couche de perlin noise (ou ptet deux). Niveau implementation exacte je me suis pas encore decidé mais ca ne devrait pas etre tres extravagant, surtout que j'ai deja les routines de perlin noise finemment optimisé a la main
 
 
->VB :
D'un secteur a l'autre bpc de donnée sont redondates. Les coordonnes X/Z par exemple. Ces données vont donc s'en aller dans un VB commun a tous les secteurs (notez que tous les secteurs ont la bonne idee de faire 33x33 vtx. Ca facilitera la gestion de VB).
Les positions XZ stockees seront comprises entre [0..1]. Le scaling par la taille du secteur ainsi que la translation kivabien seront faite dans un VS. L'avantage de cette normalisation est que l'on peut reutiliser directement la position XZ comme coordonne de textures, suffit juste d'appliquer un autre scaling pour le tiling (un peu plus tard) et de recopier ca dans les bons registres de sortie
Idem pour l'index buffer servant au rendu : partagé par tous.
 
Chaque secteur aura son VB propre contenant juste l'altitude + autre donnée propre (couleur par exemple), en double (pour le geomorphing)
 
 
 

->>Texturing
 
->par secteur
 
Je le verrais au PS 1.4. Avec ca on peut faire un texture splatting de 4 textures en une passe en encodant les coefficient alpha dans une unique texture ARGB.  
 
Si on se donne une (ou deux) texture pour le plat, une autre pour le moins plat et une derniere pour le carrement raide, alors on doit pouvoir obtenir qqchose de sympa. En faisant varier les facteur de scaling pour le tiling, on devrait limiter l'etirement de textures pour les falaises (eg, les textures pour le carrement raide seront par exemple tilé bpc plus severement que celle pour le plat).
En dernier dans le VS un simple calcul vertex->viewer nous donnera le facteur de transparence a appliquer a la texture detail et voila (ouf).
 
 
->inter secteur et LOD
Par inter-secteur, j'entend que vous avez deux secteurs mitoyens A et B, et que les textures de A ne correspondent pas a B (eg celle du plat de A c'est de l'herbe tandis que le plat de B c'est du caillou). Suis pas encore trop sur de mon coup, peut etre a la main sur le CPU.
 
eg :
 
A B
 
la texture de A sera blendé avec celle de B de facon a la jointure A->B se fasse de facon invisible (un gradient +- lineaire, quoi).
Faudra donc se taper un texture cache pour limiter la surconso de memoire
 
LOD au niveau de la texture, ca serait ptet bete de se calculer tout le splatting pour un secteur bien loin. La peut etre qu'en calculant la texture finale de ce secteur a la main en basse resolution (genre 32x32 ou 64x64) on obtiendrait des resultats pas trop degueu, mais la transition basse qualite->haute qualite risque de se voir...Sais pas encore trop. On peut imaginer remplacer la texture detail par la basse qualite Pour les secteurs a cheval sur les limites et faire la transition via lerp dans les PS (sais pas si je suis clair)
 
 
->>A part : Objets divers peuplant nos contrées
 
-Arbres
Au cas ou, pour les arbres y'a la doc "creation and rendering of realistic trees" qui est pas mal du tout, sinon vous pouvez regarder comment fait gScape (c'est assez simple mais j'aime pas trop, trop long pour pondre un arbre). Ptet que le melange PM pour le tronc/branche + le FSA (foliage simplification algorithme) pour les feuilles devrait donner un lod de bonne facture (avant de retomber sur le billboard), a essayer (je crains les tps de pre-calcul necessaire au deux par contre)
 
-caillou
La c'est de l'idee maison, mais en utilisant des metaballes y'a pas moy de generer tout une varieté de rocher plus ou moins tordu, voir meme a trou ?
On place plus ou moins aleatoirement des metaballs positive (celle qui augmente la valeur au coins des marching cube), d'autre negatives (pour les trucs), on calcule la normale a chaque vtx, deplace le vertex a cette normale via un fin bruit pour pas avoir un aspect lisse et vogue la galere ! (ou ?). Un PM la dessus parce qu'on le vaut bien et vala !
 
 
bon j'en ai fini avec ce paté, l'implementation de la partie geometrique est en cours mais comme dit plus haut je pense pas en avoir termine avant qqjours.....
 
 
Idees / commentaires ?

je savais que j'allais attirer les foules

je lis mais la je vais me coucher..
 
LeGreg

debout
 
 
J'ai entamé la geometrie assez rapidement (le brol des VS marche en fait sans pb), a part un leger pb d'interpolation au niveau de la jointure entre deux secteur splitté ca roule sans pb. Par contre fodra rester sobre sur le niveau de detail, le nb de poly grimpant assez rapidement (1922 tris par secteur, soit 30752 pour un secteur apres deux subdivisions...)

T'hibernes ?

ouai j'hiberne,  
en vrai je suis surtout débordé de boulot ce qui fait que je n'ai plus le temps ni trop la tete a trainer sur ces forums.
 
Le probleme qui arrive assez souvent aux LOD dynamiques (DLOD) c'est le popping ou le fait que les détails apparaissent graduellement en fait. Je ne sais pas si tu te sens concerné par le probleme ou si ca n'apparait pas chez toi .
 
En fait avec les moteurs pourris d'il y a dix ans, on se fichait comme de la derniere peste du popping effect mais plus la qualité visuelle augmente plus un terrain qui se déforme visiblement pour faire apparaitre du détail va etre frustrant.
 
A part le LOD, le terrain il est statique? deformable en temps reel ?
 
Pour les arbres tu peux les acheter tout fait chez http://www.bionatics.com/
 
A moins que tu aies un artiste sous la main, je ne me vois pas trop creer un arbre ressemblant a quelque chose..
 
Est-ce que le terrain sera editable pour y placer des routes, des maisons, etc.. ?
 
LeGreg
ps: et les screenshots du WIP ?

Yop !
 
Bon j'en ai terminé avec la *premiere version* du LOD. Le popping n'est pas un probleme (geomorph inside, tous se fait de facon fine avec de joli transition), par contre :
 
->Soit j'ai des T-jonctions (deplacement de vtx seulement sur Y
->Soit je dois deplacer des vertex sur XYZ (eg merger le pixel avec un de ces voisins), pas de T-jonction mais ca risque de me poser des pb au niveau de l'eclairage (les normales qui gigotent je sais pas si le mieux.) Bref a voir plus tard
 
 
Pour l'instant le terrain est statique, et je pense qu'il va le rester, surtout a cause de question d'eclairage (a vrai dire pour le moment c'est le gros point pas specifié du moteur...). Editable il le sera pour sur, fodra juste que je trouve un moyen d'annihler le bruit aux endroits ou on souhaite qqchose de plat. Definir precisemment des secteurs est une solution et pour les parties qui n'en ont pas besoin (les 99% du paysage) on peut rester avec une version tres rustre sur disque
 
 
Les algos de generations d'arbres donnent plutot bien ( http://www.flipcode.com/cgi-bin/ms [...] iotd&id=-1 ) Ensuite c question de polygone en trop
 
Le WIP heuh ben pour le moment c du wireframe rouge.... pas tres sexy. En plus la je pense plus toucher un PC jusqu'a mi-aout donc ca va etre un peu black out (but i'll be back )
 
 

Les langages fainéant ont étés testés avec succès ( http://haskell.org/aboutHaskell.html ) sur ce type d'application, peut-etre que ca vaut le coup de s'y mettre.

rentrage de vacances....ma copine me segregant temporairement pour des raisons kilometriques, ca me laisse plenty of time pour coder
 
Premiere etape, creation d'une machine a perlin noise efficace. J'ai deja les bases pour ca de precedent projet, je veux juste la rendre plus flexible (eg modifier des parametre en cours de route)

Bon, petit soucis de lod reglé, repris vieille machine a bruit, deux trois modif.
 
La bete me sort du bruit genre :
 
http://chrisbk.site.voila.fr/wip/perlin.png
 
Certainement pas le plus bruit que l'on ait vu (interp lineaire), mais pour une 256x256 elle met a peu pres 9ms sur mon 1Ghz. A priori je suis peinard de ce coté la...
 

alors il en est ou ce projet ? ( plus gros déterrage, y a pas )

http://forum.hardware.fr/hfr/Progr [...] 0732_1.htm