Bonjour,

Je poste ceci suite à mon topic sur une scène en caméra spectateur: ce topic, en espérant être dans la bonne section (ici il n'est pas vraiment question de C++).

A l'inverse des scènes habituelles où on utilise la CameraFPS pour un terrain donné, ici je me place dans une situation (mauvaise d'un point de vue perfs) où la caméra est tellement éloignée qu'elle voit tout le terrain légèrement du dessus.

Du coup, je me demandais si, de manière générale, utiliser un moteur de terrain pour rendre ce genre de scène avait un sens.

Je voulais dès lors peser le pour et le contre du choix d'implémentation par le moteur de terrain classique, à l'inverse d'un gros mesh qui gèrerait le terrain.

Je vais déjà donner mon point de vue, et j'espère que certains d'entre vous en auront à ajouter

* Moteur terrain *

Pros:
- plusieurs moteurs développés (notamment par les membres de ce forum) dont beaucoup de sources de code et d'idées
- façon "intuitive" de rendre un terrain
- petite taille de média requis (heightmap + textures < gros mesh texturé)

Contras:
- rendu plus "grossier" dû au nombre limité de points de définition (limitation de la heightmap)
- mapping texture<->terrain moins fin (aplatissement de la texture pour le passage 3d->2d lors du rendu dans le soft de création du terrain, puis re-passage 2d->3d pour le rendu final, d'où encore perte d'information)
- nécessité d'ajouter eau, arbres, etc. et de gérer leur géométrie

* Mesh *

Pros:
- plus fin au niveau du relief
- plus fin au niveau de la texturisation (plusieurs textures utilisées avec couches alpha pour chaque partie du terrain)
- toute la scène est présente (arbres, etc.)

Contras:
- volumineux
- certains softs de terrain ne peuvent pas le sortir sous forme de mesh
- énormément de primitives (pour info le terrain utilisé pour la lave et rendu en mesh contient +de 500000 primitives, irrlicht n'a jamais voulu le charger)

Voilà quelques points, certains sont peut-être de faux arguments. Il est aussi fort probable que la distance de la caméra soit la cause du manque de détail, puisqu'il me semble qu'on rend plus grossiers les triangles qui sont éloignés de la vue.

Pour ma part je continue à préférer le moteur terrain classique, j'ai d'ailleurs essayé le irrDreamTerrain de tmyke qui est vraiment très impressionnant en CameraFPS (en spectateur dans ma scène je l'ai essayé aussi mais il ne me semble pas voir de différence avec le rendu terrain classique, en même temps ce n'est pas le but de ton moteur tmyke non?)

Pour info j'ai essayé en modifiant le LOD du terrainSceneNode d'IrrLicht à 2 sur ma scène et les bords sont plus arrondis, c'est beaucoup mieux.

Livre à vous de donner votre avis sur ce sujet qui se veut être une réflexion.

Bonne journée à tous,
valholl

Vite fait, a chaud voici mon premier commentaire:

Le terrain sous forme de Mesh à souvent ma préférence pour ce qui est des projets comme le votre.

En effet, ce type d'approche amène à des scenes toute faite, comprenant tous les éléments du décorts
sans rajout à faire. Donc mieux détaillé, plus fin, certains aspect sont directement traité avant les
phase d'import (comme le lightmapping), et donc ce genre de procédé se révèle souvent visuellement
bien meilleurs que les 'terrains engines'.

Par contre, cette technique n'a pas que des avantages. Tu les site d'ailleurs en partie.

Cela fait des scenes lourdes à importer, cela représente du temps de modélisation plus important (dans ce
cas, pas de terrain editor...), et surtout, le plus important, cela impose un moteur de rendu adapté.

En effet, les moteur de terrain sont optimisé, grace à certaines techniques bien connu, et on arrive à de
très grandes surface sans plomber le frame rate pour autant.
Avec de grande scene sous forme de mesh, il faut pondre un moteur de rendu bien ficelé pour n'afficher que
se qui est nescessaire. Les techniques, là aussi, sont connues mais à l'inverse, pas souvent imlplentées
en natif dans la plupart des moteurs. Il faut donc en passer par un codage maison pour arriver à des résultat
acceptable, surtout sur des conf basse-moyenne.

Merci tmyke pour ton commentaire.

Je pense que je me suis mal exprimé; en fait, je ne parlais pas du projet en particulier, mais plutôt d'un essai que je fais à côté et qui n'est pas (encore) lié au projet mmorpg.

Ce que j'appelle une caméra "spectateur", ce n'est pas une caméra à la première ou à la troisième personne, c'est vraiment quelque chose qui embrasse une scène dans sa globalité plutôt qu'en prenant le point de vue d'un acteur qui évolue sur ce terrain (d'où le mot "spectateur", ou "omniprésent").

Je suis d'accord avec ce que tu dis sur les moteurs de terrain spécialisés ou encore sur les moteurs de meshs qui effectuent des calculs uniquement pour ce qui est visible.  Mais mon point n'est pas vraiment ici; ce que je voulais analyser, c'était plutôt quel choix faire pour afficher un terrain avec cette vue "omniprésente/spectateur".  A partir du moment où tout est révélé à l'observateur (la caméra), on ne peut plus vraiment parler de sélection de l'affichage ou de portions de scène, puisque tout est visible.

Je me permets de remettre le lien vers mon autre topic.  Le challenge ici est double: non seulement il faut afficher le terrain dans sa globalité (en fait, pour être exact, je devrais dire "quasi globalité", car la perspective et le relief enlèveront toujours l'un ou l'autre élément), mais en plus, il faut pouvoir voir évoluer divers acteurs sur ce terrain (des engins mobiles ou statiques, des éléments comme la lave dans mon exemple, etc.).

Et j'en reviens ainsi à ma question première: sachant qu'ici on ne peut pas tricher et optimiser sur ce qu'on ne voit pas, comment dès lors optimiser ce que l'on voit, et via quelle solution ?

Pour en revenir à ton commentaire, je dois dire que pour ce qui est d'une vue en FPS ou quand on suit le personnage, je partage en grosse partie ton point de vue.

tmyke :

Cela fait des scenes lourdes à importer, cela représente du temps de modélisation plus important (dans ce
cas, pas de terrain editor...), et surtout, le plus important, cela impose un moteur de rendu adapté.

Il existe des terrain editors qui permettent de faire une scène complète (T.Ed par exemple supporte les "props", ce sont des meshes qu'on ajoute au terrain, et on peut exporter en mesh - ou séparément le terrain en heightmap - et les props avec une description de leur position).  Mais mis à part ce point, je suis d'accord avec toi, et il est clair (et mathématique) que plus les données sont précises, meilleur sera le résultat dans le cas d'un terrain et c'est pourquoi rien ne vaut la fidélité d'un mesh qui décrit tout vertex par vertex, à la différence d'un terrain qui n'est en somme "qu'approximé" en usant de données elles-mêmes approximatives (la heightmap, qui ne peut pas retenir chaque petite subtilité du sol).

J'espère avoir compris ton post dans le bon sens, en souhaitant avoir moi-même été plus explicite dans mon idée.

Bonne soirée,
valholl

effectivement, je vois mieux ton interogation, désolé de na pas avoir capté dès le départ.

Ce que tu cherche à faire n'est pas simple.

Malgré tout il existe des solutions. Un bon système de LOD par exemple. Car même si tu vois ta scene dans
sa globalité, quoiqu'il arrive tu seras toujours plus près de certains éléments, et donc forcement plus loin
des autres. Donc, pour gagner en optimisation, il ne faut pas hésiter à dégrader le rendu des éléments les
plus éloignés.
En suite, même si tu vois une grande partie de ta scene, il n'en est pas moins vrai aussi que pas mal de faces
seront cachés, par d'autres faces. Il existe par exemple la technique bien connu maintenant
de l'occlusion culling qui évitera donc un couteux rendu de faces non visible.
Il y a encore un savant travail de modélisation, ou il faut toujours un juste milieu qualité des textures/nombre de face.

Bref, pour appliquer toutes ces techniques, l'emploi de système de mesh me semble plus souple.

Pas de problème, et je te remercie pour ta nouvelle réponse.

Je comprends ton point de vue sur le fait qu'un mesh est préférable car il permet de faire de manière plus ou moins automatique toutes sortes d'opérations qui vont mener à améliorer le rendu.  Mon souci principal étant l'intersection avec l'eau (la lave en fait), je pourrais l'inclure dans la scène d'origine et ainsi éviter de la rajouter par après.

Le problème que j'ai avec ça c'est la taille du mesh: mon terrain (lava world) exporté par World Machine 2 contient + de 500000 faces et irrlicht ne supporte vraiment pas ça (et on le comprend).  J'ai tenté le modifier Decimate de Blender dessus et le terrain est parti en vrille (avec des pics géants en haut et en bas, atroce), je suspecte un problème d'export de la part de World Machine.

En bref, je suis parti pour tester les 2 options... mais je dois dire que l'occlusion culling dont tu parles me plait, donc je pense que je vais essayer de ce côté-là (je ne sais pas encore comment, c'est ça qui est fun )

Pour le LOD, le risque c'est la perte de précision au niveau de la lave (voir les snapshots sur le topic original) qui va conduire à des bords trop tranchés.  Donc même si c'est loin, ça doit rester précis (en tout cas au niveau de la lave, y'aurait-il moyen de faire un LOD localisé ?)

J'ai aussi essayé ton moteur (irrDreamTerrain) sur la scène de lave, mais les résultats en termes de FPS étaient grosso modo identiques au terrain node d'irrlicht (en tout cas sur ma vieille 7600GS), peut-être seraient-ils meilleurs sur une carte récente ?

Merci en tout cas et bonne fin de soirée,
valholl

Faudrait surtout utiliser les Impostors, une des botte secrète pour les rendus sur de longue distances comme dans Crysis ou Far Cry.

Cela sera peut être dispos dans Irrlicht 1.6, croisons les doigts.

http://www.youtube.com/watch?v=cHAfqwagk7I

Merci Steph pour ton post, je vais me renseigner sur cette techno.  En attendant, je vais voir quelle solution intermédiaire pourrait convenir, mais c'est clairement une chose à laquelle il faut penser pour l'avenir car cela servira à beaucoup de monde.

valholl