Je viens d´avoir une idée de technique pour la création d´un moteur de rendu d´environnents extérieurs, que je ne compte pas implémenter pour l´instant car j´ai déjà du pain sur la planche , et j´aimerais savoir ce quelle vaut vis à vis des techniques utilisées dans les jeux commerciaux.
Aussi, quelqu´un pourrait il m´expliquer brièvements les concepts mis en oeuvre dans la création d´un moteur de rendu extérieurs ?

y´a d´EXCELLENTS articles sur Gamasutra dans la section " features".

Le moteur extérieur va beaucoup dépendre de ce que tu souhaites vouloir lui faire faire :/ Par ex. si tu veux pouvoir faire un grotte, une simple heightmap ne suffira pas ( y´a plusieurs vertices qui se projetent verticelement au meme endroit)
mais la grosse idée indissociable, c´est " niveau de détail adaptatif". Pour ça, y´a plusieurs méthodes, patchs de bezier avec tesselisation adaptative à la volée lors du rendu, geomipmapping, etc. Niveau structure de donnée, un quadtree ou un octree fait généralement l´affaire. Je p-e qq liens sous le coude, je m´étais interessé à la question il y a peu, faut que je fouille dans mes archives ( pour info, l´implémentation d´un geomipmapping à 4 niveaux sur quadtree m´a prit en gros 10 jours, c´est donc largement réalisable ; mais c´est pas non plus une technique tres dure que j´ai utilisé...)

Tienn ca à l´air de techniques différentes de la mienne.
Je l´appelerai " propagation polygonnale".

les idées de base sont les suivantes :

-patchs de bezier :
des blocs de vertices de 4x4, ce sont des points de controle definissant une surface implicite. On peut alors générer autants de point qu´on veut sur la surface par une " simple" formule, de manière à raffiner le rendu. Du coup, par exemple, les patchs proches de la caméra => subdivision niveau 3, les patchs plus lointains, niveau 2, et les patchs tres loin, niveau 1 ( niveau 1 => vertices = points de controles ; niveau 2 = on insère un vertices entre chaque point de controle, niveau 3, on insère 4 vertices, etc.). Le GROS soucis, c´est d´assurer la continuité entre les patches voisins de niveau différents...

-geomipmapping :
on travaille des patchs de 2^n*2^n quads(moi j´avais pris du 8x8, soit 9x9 vertices), on génère les patches " simplifiés" ( de 8x8, on crée le 4x4 en virant des vertices, puis le 2x2, et finalement le patch " plat" de 1 seul quad). Ensuite, selon la distance et la déformation liée à la projection de la caméra, on détermine pour chaque patch son LOD à afficher. Là encore, soucis pour préserver la continuité entre niveaux différents ( faut faire des bandes de transitions plus ou moins à la main).

Dans les deux cas, bezier et geomipmap, on fout les patches dans un quad/oc-tree pour clipper rapidement.

Si tu veux un exemple de la deuxième technique :
http://netabarons.chez.tiscali.fr/downloads/landscape.ace

( je fais ma pub ; ) LOOOL)

Sympa l´exemple : on voit bien l´affinage des subdivisions.

Ma méthode consisterai à représenter une map sous forme d´une succession de polygone ( triangles ou carré ) contigus, représentés chacun pas une classe contenant nottament comme membres de données :
- Une table de 4 vertice pour les 4 sommets ( altitude et emplacement )
- Un table d´entités attachées ( exemple : arbres, décors, . .. )
- Une texture
- Une table de pointeurs vers les 4 carrés ( dans le cas des triangles, 3 seulement ) adjacents.

Pour le rendu : on démarre de la position du joueur ( le carré sur lequel il se trouve ) et on progresse, de carrés en carrés, selon si ceux ci sont visibles ou non, jusqu´à ce qu´on ai atteint une certaine distance de vue maximale ( brouillard pour éviter un rupture ) .
Ce n´est en fait qu´un arrangement en 2 dimensions.
Sachant que selon la distance du c polygone à la caméra, on affiche plus ou moins de détails : particules, herbes, models détaillés ou moins etc...

L´algorithme est très simple et facile à mettre en oeuvre. La seule difficulté résidant dans le propagation polygonal, bien que simple à mettre ouevre.

Faudra que j´essaie.

je vois qq inconvénients au niveau de l´organisation des données : ce qui coute cher au niveau d´une carte graphique, c´est de changer les ressources utilisées ; la grosse difficulté avec ton organisation sera de construire le flux de données à envoyer à la carte, et de le faire rapidement. Ensuite, une texture par quad, ça me parait ENORME ; de plus il faut trier les polygones par texture pour ne pas bouffer les ressources en demandant de changer entre chaque quad : c´est ce que je crains avec l´idée de " propagation".
le *pire* perk killer serait de faire :

Case::render()
{
si ( visible)
changeTexture();
dessine(LOD);
pour tous les voisins
render(voisin)
}

il faut tout batcher : les vertices, les ressources, etc.

Enfin, le mieux c´est d´essayer ; ) bon code ! !

Oui j´ai sortis la méthode bourrin
Mais je suppose qu´en optimisant, en triant nottament les faces avant de les afficher, pour les grouper par textures, ca pourrait aller un peu plus vite.
Mais ce n´était qu´une simple curiosité, je suis déjà occupé