Bon, ca fait un bout de temps que je me demande comment faire un moteur qui gere des paysages :
 
-> de tres grande taille
-> editable (genre la je veux une bosse, la pas. Je parle pas de deformation temps réel, enfin, pas pour le moment ) . ca vire les trucs 100% generé, genre fractale
-> qui ne bouffe pas 3Go de dur.
-> qui rame pas
 
(vivi, je sais, ca fait beaucoup)
 
 
Mesh :
 
Bon, jusque la j'avais opté pour la tactique "décrire assez précisement le terrain sur dur".  le terrain etait découpé en secteur de 9x9 points (alignés régulierement), et je lissais le tout a coup de catmull-rom au chargement (je repassais en 33x33). Pour diminuer la taille j'ai essayer deux trois trucs, de la quantization a la conversion en short (je cherchais le min-max des altitudes, et j'allouais l'espace 0-65536 pour cet interval. Marchait pas trop mal). Bon, c'est bien rigolo, mais c'est pas toptop
 
Maintenant je médite a autre chose, plutot que de lisser betement, est ce que ca pourrait pas etre intelligent (voir meme fin) de rajouter en plus par dessus une couche de bruit (genre le perlin noise, qui a le bon gout d'ajouter des details haute/basse frequence. De plus, il s'accorde pas trop mal avec le level of detail). Ca nous permet de rajouter deux trois details "locaux" (petit trous, bosses) et de casser un peu la monotonie des paysages, au prix d'un peu de calcul en plus.
 
 
Textures :
 
 
ben la, c'est encore un probleme. J'ai deja essayé les couches de texture mixées en fonction de l'altitude (pas trop mal, mais risque de répétition, difficile d'obtenir un effet précis), les textures mélangé entre elle sans respect pour rien du tout (genre la ce secteur ce sera du rock et sur ce secteur la de l'herbe). limite mauvais. En dernier lieu, j'ai fait un generateur de texture qui utilisait des layers. Pour chaque layer on donnait une couleur, une altitude min/max, un slope min/max, un degré de variation de couleur. Apres avoir emplié plusieur de ces layers on arrivait a des resultats pas trop trop mal. Avantage : non répétitivité des textures (le perlin noise etait utilisé a mort. on voyait bien que c t les meme layers d'utilisés, mais les "motifs" changeaient), niveau de detail au niveau de la texture (plus le secteur etait loin plus je baclais le calcul). Defaut : pas mal de réglage pour avoir un effet interessant, manque de détail. (posterais un shot si ca interesse du monde), faire de fines transitions entre deux secteurs utilisant des layers differents risquait d'etre délicat (tellement que je me suis arreté avant)
 
Maintenant, braves gens, y en a t'il parmis vous qui se sont deja amusé a ce genre de sport?  avec quel resultats ? Quel algo pour le niveau de détail ? Mon gros pb, avec le level of detail, c'est la jointure entre deux secteurs utilisant un niveau différent. ca se voit, et c'est tres laid, et j'aipas encore trouver de méthode simple pour virer ce phénomène a la mords moi le noeud
 
 
 
[vu d'esprit limite irréaliste]

un jour j'aurais ca a l'ecran
[/vu d'esprit limite irréaliste]
 
 
(la question que je me pose devant ce genre de photo, c'est "qu'est ce qui fait que je sais que ce sais que c'est un "grand" paysage, je veux dire, que ce qui est loin EST vraiment loin ? y'a le fog (aerial perspective, pour les puristes, me semble ), mais quoi d'autre ? je pensais aux objets pour donner une idée de l'echelle, mais la y'en a presque pas et pourant on voit tres bien que c plus des montagnes que des collines.... m'enerve de pas arriver a comprendre )

Je bosse moi aussi sur un moteur de ce type, par contre, je pars sur une autre problématique puisque dans mon cas, je veux tout générer en temps réel (relief, textures ...)
 
 
Perso, j'utilise pour l'instant un simple LOD de type ROAM, basé sur un quadtree.
J'ai déja pas mal bossé avec les nruits de perlin et je pense pouvoir générer un terrain assez varié avec des multifractales. Pour les textures, je me suis pas encore trop posé la question mais j'ai quelques vagues idées  ...

et on peut savoir c koi tes idees, pour les textures ?

vive les cosses

Godbout a écrit a écrit : vive les cosses

 
merci de ta contribution

Tu me remercieras quand nous serons sur la petite route de la photo, a moto, avec des pansements un peu partout

par exemple, utiliser un bruit de perlin pour délimiter des grandes zones, comme celles dont tu parles : étendue verte, zone rocailleuse, desert... puis mixer des textures en fonctions de l'altitude ou des variations d'altidudes. En utilisant les variations d'altitudes et pas les altitudes elles-mêmes, ont doit pouvoir éviter d'avoir des strates de textures, particulièrement visibles.

interressant...
 
sinon l'approche mentionnée par matrox avec le displacement mapping pourrait t'interresser...
 
tu as un terrain bas-triangle, et tu crées (par voie hardware) des triangles dont les vertexs sont générés à partir d une texture...
 
comme la texture passe par un filtrage trilinéaire, tu as un LOD géométrique gratis....

enfin pour avoir un rendu niquel, je pense qu'il fo utiliser algo comme le catmull-rom au niveau cpu pour générer la surface courbe à partir des infos de terrains (et dynamiquement au fur et à mesure que l'on progresse dans le monde), perturber le terrain au niveau géométrique avec le displacement mapping avec une texture de détail, et faire un système dynamique d'herbe un peu à la crytek....

oui oui, j'ai pensé à ça aussi.
Mon problème, c'est que je veux que ce soit en temps réel, donc je ne peut pas vraiment faire trop bosser mon cpu. Il aura deja pas mal de taf pour générer du terrain (en multifractal) et des textures. Ajouter par dessus un lissage par du catmul rom, ça me semble un peu trop (mais ça mérite d'etre essayé !).
 
Pour le displacement mapping, ce serait mortel mais je crois que, justement, ça ne marche que sur matrox pour l'instant ...

 
ouaip c ca mon gen a texture(les variations d'altitude, c'est le slope chez moi ). Sauf que j'ai pas de bitmap de base. Avec pas mal de reglage on arrivait a des trucs correct, genre :
 

 
y'a une tex de detail pour aider un peu, et les layers pouvaient etre plus ou moins opaque a cette texture (utile pour de la neige, par ex)
 
Tiens, petite incartade, l'eclairage tu compte le gerer comment ? J'avais fait l'horizon biduling, ca marchait pas trop trop mal et permettait du dynamique, au prix d'un preprocessing (pas sur que tu puisse te l'offrir avec un terrain 100%dynamique...)

 
ah ca....Mais c'est tellement peu répandu pourle moment que c pas encore super viable....et je me demande comment gerer les collisions, avec ca ?

Pour éviter d'utiliser le CPU pour générer le terrain, il est possible de reprendre l'approche des jeux 2D. On a disons 256 terrains prédéfinis, dessinés de telle façon qu'ils peuvent se relier entre eux. Ensuite un tableau à 2 dimensions d'octets sert de map pour dire à quelle position afficher quel terrain.
 
Si l'on prend des terrains 256x256 avec 16bits de précision et une map 256x256, et que l'on considère qu'il y a 40m d'écart entre 2 points, on obtient un univers de 256 * 256* 40 = 2621,440km de côté. Pas mal non?

en fait, j'ai une idée en tête pour ne pas faire du vrai 100%M temps réel pour la générationdu relief.
Je pense calculer les différentes octaves des bruits de perlin au lancement du soft et de les paramétrer pour qu'ils soient répétitifs (ils collent qd on les mets bout à bout, quoi).
Ensuite,lorsque je veux calculer l'altitude d'un vertex, je n'ai plus qu'à faire la somme pondérée des différentes octaves.  
 
Pour l'éclairage, je vais commencer par le truc de base, avec des normales vraiment calculées et voir ce que ça donne. je pense faire des shadow maps pour les ombres par la suite.

 
 
Le pb, avec cette technique, c'est justement de faire des morceaux qui se recollent. Ca devient vite une limitation quand à la diversité des parcelles possibles.

 
vi apparement Delta Force 2 utilisait une techinique similaire...

Avec Terragen je te fais un joli paysage d'Ecosse quand tu veux

W3C Compliant a écrit a écrit : Avec Terragen je te fais un joli paysage d'Ecosse quand tu veux

 
pour le real time tu repasseras

c'est clair
 
 
mais en fait, terragen utilise aussi les bruits de perlin et les multifractales ... C'est ce qui me fait dire que c'est une piste solide.

vient de lire sur une mailing list une idée qu'elle est pas conne. Pour limiter le couts des mises a jour de vb (lors de modif tps reel, streaming ou que sais-je), il est possible de découper ses vertex en plusieurs bouts (les vertex stream de dx8), un contenant la position en XZ et un autre en Y. De ce fait on ne touche que celui qui contient Y. (par contre passer par des VS, pour ca)
 
On peut meme noter, si jamais on utilise des secteurs carré parralleles au axes, qu'il suffit d'un seul vb XZ (suffira ensuite d'appliquer une bonne vieille matrice sur le truc pour le remettre a sa position correcte), d'ou un gain de RAM.  
 

 
tout a fait, d'ailleurs je me suis pas mal inspiré de son systeme de texture pour le mien (videmment, on peut pas comparer les qualités sorties )

 
 
pour l'instant, je bosse avec opengl

d'ailleurs, je me pose une question : j'ai utilisé un moteur pour lequel une classe encapsulait les vertexbuffer de directX. J'ai eu pas mal de pb parce j'étais obligé d'avoir le bon nombre de vertex dans le tableau de vertex. Je ne pouvait pas par exemple passer plus de vertex que ceux réellement utilisés. J'aimerais bien savoir si c'est une limitation de directx ou du moteur que j'avais.

chrisbk a écrit a écrit :     pour le real time tu repasseras

 
Bah avec un proc' puissant

meme un proc puissant ne sait pas traityer autant de facettes en temps réel  
 
il faut encore attendre qq années  

Sinon pour la photo d'Ecosse, n'oubliez pas que c une photo : autrement dit les lois optiques font que la profondeur est sensible à travers la zone de netteté (focale). C ce qui manque souvent, ce flou dû à la distance, et pour cause, dans une animation, où par définition tout élément est susceptible d'être porté à l'attention de celui qui regarde. Donc c plus dur à rendre en animé...
 
Sinon autre chose, certaines textures naturelles sont aisément reconnaissables : en l'occurrence, l'herbe rase est vraiment très uniforme tout en conservant assez de détails, ce qui donne l'idée de distance. Si c'était une colline, le niveau d'organisation visible serait bcp plus grand, jusqu'à ce qu'on distingue chaque fleur de pissenlit ou chaque rocher caché. Le problème c la transition trop brute entre détails jolis/pas détails tout lisse qui est souvent à chier dans les jeux genre FlightSim, ou à base de VoxelSpace, ou même dans Terragen.
 
Sinon en photo t'aurais des problèmes de luminosité apparente (à distinguer de l'effet de flou focal, ou du fog), qui là est très bien rendu dans Terragen

 
si cela s'applique a la photo en general je ne pense
pas que cela s'applique a une photo de paysage
en particulier ou en general la mise au point est a l'infini.
Evidemment on peut mettre des elements flous au premier plan
mais ca n'est pas le cas dans cette photo d'ecosse.
 
Ce que l'on voit par contre c'est:
1- perte de couleurs a l'horizon (les peintres avaient compris ca et se fichaient de rendre correctement la perspective)  
2- un element reconnaissable pour donner a l'oeil humain un element d'echelle (ici une route et un vehicule). Ce qui peut manquer dans des paysages generes.
3- la texture est importante mais pour les elements proche. l'anisotropic filtering devrait aider a garder les textures proches "precises". Pour ce qui est des elements lointain, la teinte compte ainsi que la forme plus que la texture. On peut meme se contenter de faire des formes esquissees en fond.
 
Qu'est-ce qui est interessant de noter:
Les ombres ont peu d'importance ici parce qu'a cause des nuages elles sont quasiment gommees. On n'est donc pas oblige d'avoir un modele d'ombrage detaille.
Le ciel prend une place importante. Et ca peut etre difficile a rendre sur un ordinateur parce que la plage de teintes et de luminosite est plus limitee. On ne voit donc qu'une "impression de ciel" sur ecran plutot qu'un vrai ciel. L'interaction des montagnes avec les nuages est par contre vraiment interessante et c'est ce qui donne au paysage son cote brumeux particulier .
 
Juste une remarque: faire du photorealisme
est on ne peut plus simple, il suffirait de faire de l'image based rendering ou plaquer une texture proche de cette photo sur un mesh 3D et l'illusion serait presque parfaite. Mais on veut evidemment depasser ca et "simuler" plutot que "copier" .
 
voila un exemple de rendu avec geometrie et texture detaillee:

 
A+
LeGreg

c'est toi qui a codé ça ?

hum, j'ai du mal a voir ton idee..... a la creation d'un vb on lui donne une taille precise, et on ne peut pas ensuite ecrire plus dans un vb que ce tu as donné comme taille (la taille optimale d'un vb etant sujet a discution ). Par contre tu peux evidemment ne dessiner qu'un sous ensemble du vb

patience, le depth of field arrive. Je me demande meme si b&w n'en avait pas ? (y'avait un article sur gamasutra, a ce propos). Et quand on aura (si jamais on aura) un acces rapide et propre au zb, la ca sera bpc + facilement faisable

Pour le ciel et la perte de constraste :
 
http://www.cs.utah.edu/vissim/papers/sunsky/
 
 

 
ca rend plutot pas mal (encore que ca doit pas etre du real time, la, mais doit bien avoir des idées a repiquer)

chrisbk a écrit a écrit : Pour le ciel et la perte de constraste :   http://www.cs.utah.edu/vissim/papers/sunsky/     http://www.cs.utah.edu/vissim/imag [...] y/sexy.jpg   ca rend plutot pas mal (encore que ca doit pas etre du real time, la, mais doit bien avoir des idées a repiquer)

 
en fait c'est surtout au niveau du parmétrage du fog que ça se joue....

 
Euh je n'ai fait qu'une partie:
les arbres et objets billboardes, les textures detailles, les ombres, le blend entre la geometrie detaillee (par une texture de bruit) et la geometrie bas niveau (issuee de donnees reelles). Et j'ai passe le code du draw triangle aux draw element et aux display lists.
J'ai fait beaucoup moins que ce que j'aurais pu  
(cause grand touriste a l'epoque ) mais bon..
 
LeGreg

 
Nope n'espere pas trop pour l'acces au Z-Buffer
tous les constructeurs de Hardware vont essayer de te
decourager de faire ca: le Z-Buffer est de plus en plus abstrait avec la compression et les buffers hierarchiques qui permettent une rejection basee sur le z assez rapide, de plus toute tentative de "locker le zbuffer" (s'il est verrouillable donc tu as deja renonce a toute acceleration) aboutit a un stall du GPU qui doit flusher tous ses pipeline (cela interdit de travailler en parallele sauf si tu as un moyen de verrouiller le z-buffer de l'image precedente..).
 
De plus *dois-je le rappeler*, certains hardware fonctionnent sans z-buffer (c'est une caps de DirectX).
 
J'avais vu un trick a une demo d'ATI qui consistait a ecrire dans une texture des informations de Z encodees dans la couleur (grace au pixel shaders). Evidemment le resultat doit etre decode avec le bon pixel shader. L'avantage c'est que tu peux attendre la frame suivente avant d'utiliser le resultat pour un traitement hors de la carte.
 
Black and white n'a pas d'effet de Depth blurring
a ma connaissance (je joue dessus en ce moment).
 
Ce qu'ils font dans Direct X
c'est qu'ils rendent la vue originale dans une texture avec un blur factor calcule dans un vertex shader qu'ils placent dans la couche alpha de la texture. (blur factor dependant de la profondeur)
 
Ensuite ils combinent quatre versions legerement decalees de cette vue grace aux pixel shaders, le rapport entre la vue origibale et les vues decalees dependant du facteur stocke dans l'alpha de la texture.  
 
C'est pour ca que j'appelle ca du depth blurring et non pas un depth of field. L'avantage de cette technique c'est que l'on transforme une seule fois le monde.
 
LeGreg

chrisbk a écrit a écrit : Pour le ciel et la perte de constraste : http://www.cs.utah.edu/vissim/papers/sunsky/ ca rend plutot pas mal (encore que ca doit pas etre du real time, la, mais doit bien avoir des idées a repiquer)

 
non ce n'est pas du temps reel, le but de ces chercheurs
etaient d'arriver a une representation correcte des conditions atmospheriques et d'arriver a transformer des considerations physiques en donnees de couleurs (c'est a dire representable sur un ecran en temps raisonnable)..
 
Le moyen d'y arriver c'est evidemment de simplifier un certain nombre d'equations a la main.
 
Pour le temps reel reste le bon vieux fog meme pas volumetrique
 
LeGreg

legreg a écrit a écrit :     non ce n'est pas du temps reel, le but de ces chercheurs etaient d'arriver a une representation correcte des conditions atmospheriques et d'arriver a transformer des considerations physiques en donnees de couleurs (c'est a dire representable sur un ecran en temps raisonnable)..   Le moyen d'y arriver c'est evidemment de simplifier un certain nombre d'equations a la main.   Pour le temps reel reste le bon vieux fog meme pas volumetrique   LeGreg

 
pour la perte de contraste non, pour la couleur du ciel, en preca la couleur a +eurs moment de la journée au load time et avec une bonne vieille interp linéaire entre, ca peut le faire. Par contre y'avait deux trois trucs dans la doc que j'avais pas cpris...

J'ai pas teste (la j'suis sur ma geForce2 du boulot)
 
ftp://ftp.gdmag.com/pub/src/aug02.zip
 
LeGreg

j'lai vu (il est dans les ex de rendermonkey de ati), ca rend pas trop mal, voir meme bien. (sauf le soleil qui a tendance a etre un peu envahissant, mais bon )
 
edit : y'a un article associé  ?

si tu es abonne a gdmag..
 
LeGreg