Discussion :

[f56bre]

Salut,

Je dois afficher une énorme map donc, évidement, pas question de tout charger en RAM. J'ai alors choisi de découper cette map en carrés (un mesh) dont la longeur est une puissance de 2. Ainsi je ne charge que les infos correspondantes au carré sur lequel se trouve le perso et les info des 8 autres autour. Ainsi suivant les déplacement du perso je charge et décharge à l'aide de threads de nouvelles infos correspondantes à de nouveaux cubes. Y a t'il plus efficace comme technique?
Est-il nécessaire de mettre en place une structure d'octree pour gérer les infos ainsi chargées? Si oui cette structure doit-elle englober toute la scène(même les parties non chargées), et être mise à jour à chaque nouveau chargement de scène, ou juste les 9 cubes chargés et être recréée à chaque fois que l'on recharge des nouveaux cubes?
Si j'utilise une telle technique je devrais donc (comme me l'a conseillé laurent) découper en patchs ma partie chargée, chaque patch contenant un VBO et un ID de texture(commun avec d'autres patchs). Quelle taille de patch seraient-elle idéale?

merci d'avance

[mat.M]

Vu comme c'est décrit là le programme risque de souffrir de sérieux ralentissements..surtout sur les petits configurations.
Quel est le but du projet ?

[f56bre]

le projet c'est de faire un moteur 3D. Je déduis de ton idée que ma stratégie est mauvaise. Mais perso, pour charger la map je ne vois pas trop d'autre solution (chargement transparent pour le joueur bien sur). As-tu mieux à proposer?

[mat.M]

le projet c'est de faire un moteur 3D. Je déduis de ton idée que ma stratégie est mauvaise. Mais perso, pour charger la map je ne vois pas trop d'autre solution (chargement transparent pour le joueur bien sur). As-tu mieux à proposer?

ah ok oui maintenant je comprends mieux merci
Oui on peut charger au fur et à mesure; par exemple les simulateurs de vol fonctionnent ainsi : ils chargent des fichiers d'élevation du relief ( DEM ) au fur et à mesure de la progression.
Oui on peut utiliser des octrees mais cela risque de compliquer la chose et considérablement le code source.
Faut voir si cela apporte en performances

Si quelqu' un a meilleure idée ...

[t.b.p.]

Pourquoi un octree si c'est une carte? Un quadtree est suffisant.

On en vient donc à une solution comme l'excellent http://www.tulrich.com/geekstuff/chunklod.html

Même si je pense qu'une approche plus brutale est dorénavant plus payante, au moins au niveau du rendu, il n'en reste pas moins que nombre des astuces déployées dans ChunkLOD sont applicables.

PS: si le but n'est pas le rendu par batch sur une carte 3D, d'autres structures plus efficaces (pour la traversée) que les quad/octree sur les cpu modernes s'imposent.

[f56bre]

Ok pour les quadtrees si je m'arrètais à l'affichage de la map mais ensuite je vais y poser des objets issus de fichier .obj ou .3ds ne suis-je pas obligé de passer par les octree. Sinon je ne sais pas ce qu'est le rendu par batch (peut-être un rendu par paquet?) mais je suis intéressé si d'autres techniques sont plus efficace avec les nouveaux CPU.

[mat.M]

Pour les objets statiques il ya peut-être plus simple que de passer par des arbres binaires complexes à mettre en oeuvre.
Il suffit de déterminer si les coordonnées de l'objet appartiennent à un certaine zone de vision ( "Viewport")
Il suffit de déterminer les coordonnées X et Y de l'objet par rapport à la caméra qui donne un rendu de la scène...
Par exemple Ms Flight-Simulator fonctionne comme cela : les scènes sont définies selon une certaine zone et sont chargées selon la position courante en longitude et latitude..

[t.b.p.]

La représentation idéale depend de la nature de tes données.
Géneralement le terrain (2D, ou carte) est vaste et clairsemé de trucs de dimensions bien plus restreintes (caverne, batiment, personnage, vehicule etc etc). De plus on peut rarement se permettre de decrire 8kmx8km au milimetre pres tout le temps. Donc on traite le terrain séparement.

Chunklod utilise un arbre (le quadtree) regroupant des bouts de terrains de taille plus raisonable en plusieurs versions de précision décroissante (+ les textures attenantes), ces bouts étant optimisés pour un rendu par batch (envoi d'un maximum de primitives pré-triées en un minimum d'appels sur une GPU). Il fait en sorte de n'afficher que le minimum nécessaire pour maintenir un niveau de détail apparent constant (pour la géometrie et les textures).

J'ai évoqué des structures plus efficaces mais dans le cadre d'un rendu effectué sans GPU, genre ray tracing (donc uniquement sur les cpu).

La ou chunklod s'ingéniait a pre-fabriquer des strip de terrains de moins en moins fins, parce que c'était ce qui était le plus efficace sur les cartes d'alors, il est maintenant envisageable d'etre plus brutal et d'envoyer le patch originel les cartes actuelles n'étant pas autant limitées en nombre de triangle traitable par seconde et le traitement des niveaux de details (LOD) entrainant un surcout.

Celà dit, à l'époque, je n'avais déjà aucun problème a me balader sur des terrains de plusieurs giga en temps réel. Donc...

[mat.M]

Chunklod utilise un arbre (le quadtree) regroupant des bouts de terrains de taille plus raisonable en plusieurs versions de précision décroissante ..

D'accord mais qu'est-ce que c'est ChunkLod ? Je suis allé jeter un coup d'oeil sur les pages données en lien et par manque de temps j'ai pas compris ce que c'était

[t.b.p.]

Données d'élevation (beaucoup) + textures (beaucoup), moulinette intense, affichage rapide.