Discussion :

[f56bre]

Salut

Je commence l'implémentation d'un moteur graphique utilisant les octree comme méthode de partitionnement. Pour ma map j'ai une heightmap et une texture et pour mes objets des fichiers .obj et .3ds( avec leurs textures eventuellement ). Je souhaite utiliser l'efficacité des vertex arrays voire des VBO pour accelerer le rendu cependant j'ai du mal à me faire une idée de la marche à suivre.

Pour le moment mon raisonnement est le suivant : Je charge ma map dans un classe map, puis les objets dans des classes objets. Ensuite je passe tous les vertex à la moulinette octree (je me pose d'ailleur une question à savoir si je stocke dans mes noeuds d'octree toutes les données ou simplement des pointeurs vers les données des classes map et objets?). Je finis par une elimination des faces cachées avec un calcul du frustum. J'ai donc dans chaque octree(visible) des vertex venant d'objets et/ou de la map. Ma question est donc : comment savoir quelle texture utiliser pour chaque face puisque tout est mélangé et si on le arrive à le savoir comment passer de texture en texture sans ralentir le rendu?
De même comment créer des vertex array (ou VBO) efficaces?
En-effet cela me parait byzarre de créer des buffers pour chaque noeuds de l'octree. De même si j'en crée un avec tout ce qui a survécu au frustum-culling ça voudras dire qu'il sera recalculé à chaque déplacement(est-ce jouable?).

Je prend sans doute le problème dans le mauvais sens alors pouvez-vous m'éclairer?

merci d'avance

[Laurent Gomila]

Il ne faut pas tout mélanger dans ton octree. Stocke non pas des sommets directement, mais plutôt des pointeurs vers tes objets ; ça n'a aucun sens d'éparpiller la géometrie d'un même objet comme ça (il faut que ça reste consistent au niveau textures / materiaux / shaders / ...).

Pour le terrain tu peux le découper en patchs et stocker des patchs dans ton octree, par exemple.

Et ainsi tu n'auras pas à créer ou mettre à jour des VB puisque tu ne manipules dans ton octree que des entités (qui auront leur propre géometrie et sauront d'elles-mêmes comment se dessiner).

[f56bre]

Merci pour ta réponse ça ma parrait plus clair ainsi sauf pour le concept des entitées que savent se dessiner d'elles-mêmes. J'ai mes infos sur l'entité mais celles-ci peuvent-être emputées lors des tests de fustum (pour un objet à cheval sur 2 noeuds, dont l'un est hors champs, je n'aurais que la moitiè à dessiner). Alors quand intervient la création du VB? si je le fais avant il y aura 2 fois trops de données stockées et si je le fait après c'est que je le fais à chaque fois(hors tu me dis que ce n'est pas la peine).

J'ai également une autre question au sujet des textures : y a t'il plus efficace que de charger toutes les textures (glGenTexture(...)) puis les binder?

[Laurent Gomila]

J'ai mes infos sur l'entité mais celles-ci peuvent-être emputées lors des tests de fustum

Comme je te l'ai dit il faut oublier la gestion au niveau des polygones, gère plutôt au niveau entités. Ca n'a aucun sens de vouloir découper une entité pour éliminer quelques polygones de plus (sauf si ton entité est un niveau entier ou quelque chose de très gros, évidemment).

J'ai également une autre question au sujet des textures : y a t'il plus efficace que de charger toutes les textures (glGenTexture(...)) puis les binder?

Au niveau OpenGL non (de toute façon il n'y a pas 50 façons de faire), après il faut voir au niveau de ton appli s'il y a besoin d'un gestionnaire de textures.

[f56bre]

ok merci de ta rapidité et de la précision de tes réponses