Discussion :

[bob25]

un probleme sur lequel d'autres debutants ont du se casser la tête c'est de choisir entre l'une de ces structures de données pour démarrer
elles font appel à des algo de partitionnement et affichage assez differents

les arbres (globalement plus rapides à traiter s'ils sont bien construits) étaient utilisés dans tous les vieux jeux mais l'augmentation du nombre de polygones semble avoir remis au gout du jour l'affichage basé sur les graphes avec des secteurs, des zones, des portails et des antiportails... les arbres étant gardés pour les collisions (et souvent sous-traités par le moteur physique) ou pour un affinage supplémentaire de l'affichage

le probleme du codeur qui débute: par quoi commencer?

vaut-il mieux commencer par bosser sur les arbres à l'ancienne, ou attaquer tout de suite les graphes?

[Laurent Gomila]

Déjà on ne peut pas répondre à cette question de manière générale, chaque structure étant une réponse à une situation bien précise.

Il faut aussi savoir quel est le but recherché ; s'il s'agit simplement d'organiser les entités dans ta scène alors utilise un scenegraph bête et méchant sous forme d'arbre.

Si tu veux éliminer des polygones du rendu (faire du culling) alors en gros tu peux opter pour un quadtree / octree pour des scènes extérieures, ou du BSP / portal pour des scènes intérieures.

Si tu veux gérer les collisions ce sera encore une autre histoire.

[bob25]

oui c'est pour faire du rendu (culling)
pour le moment j'utilise un bsp tree car c'est la dessus que j'ai trouvé le plus de doc je me dis que c'est par là qu'il faut commencer

mais j'ai lu quelques documents sur l'utilité des graphe type sector/zone, structure apparemment plus vieille mais moins rapide, et les raisons qui font qu'on s'en sert de plus en plus pour gerer les questions de culling (plus souples, plus génériques, mieux pour gerer beaucoup de poly, permet d'afficher des décors dynamiques, gestion mixte des interieurs et exterieurs...), je me demandais si c'est pas une bonne piste pour attaquer de la 3d disons plus moderne et plus generique

j'ai l'impression que ce n'est pas tellement plus complexe à coder

c'est legerement plus lent a rendre et parcourir mais je ne cherche pas la vitesse parfaite (ce n'est pas pour un jeu en fait mais pour un chat 3d),
et ça pourrait peu-être aider à dynamiser l'affichage: ajouter des portes occlusives, des ascensceur...

et l'autre probleme c'est que je sais pas bien quel type de maps les graphistes vont me fournir et si les structures de polygones sont un peu trop compliquées je vais avoir du mal à faire des arbres bsp propres ils vont être plein de trous

donc je me demandais si un graphe de secteurs et portails serait pas une solution tranchée mais plus sûre, (au prix d'un cout en performance certain)


c'est mon premier moteur 3d donc je ne sais pas trop
vos conseils sont donc les bienvenus
je n'ai jamais essayé les graph pour le moment, j'aimerais l'avis de ceux qui ont un peu bidouillé avec (et qui ont pu comparer avec les arbres)

[bob25]

je viens d'essayer de découper un graphe je me suis découragé au bout du premier polygone

je crois que je vais rester sur du bsp

[bob25]

je laisse quand même mon observation - ça peut servir pour ceux qui buteraient sur la question:

-les graphes dynamiques c'est plus puissant, mais c'est interessant surtout si on travaille à partir de données 3d directement modélisées en graphe

-les arbres c'est bien pour récupérer un peu n'importe quoi (c'est donc l'arbre qui est le plus generique contrairement a ce que je croyais avant de faire le test)


je sais pas si ma remarque va servir...