Salut à tous,

Je suis actuellement en pleine phase de modélisation de niveaux pour mon jeux, je fais ça avec Blender et je me pose déjà quelques questions par rapport aux modèles 3D qui en résultent.

Au sujet des OctTrees, si j'ai bien compris, il s'agit de charger le mesh qui représente mon niveau dans un OctTreeSceneNode et cela devrait automatiquement gérer l'affichage des polygones en fonction de ce que voit la caméra.
Je trouve ça fabuleux mais je suis sceptique, est-ce si automatique ? Je trouve ça trop simple, juste un appel de fonction pour gérer cet aspect, ça me parait bizarre.

Du coup je me suis demandé beaucoup de fois si je procédais de la bonne manière en créant un seul gros mesh pour tout mon niveau ou si il valait mieux que j'en fasse plusieurs (avec un risque de "fissures" entre les meshs), et que je doive gérer l'affichage manuellement en chargeant ou pas une partie du niveau en fonction de la position du personnage.

Bref je n'ai pas trouvé beaucoup d'informations sur les OctTrees, peut-être parce que ce n'est pas sorcier, je fais appel à vos lumières pour avoir quelques détails et j'espère avoir des recommandations sur le meilleur moyen d'avoir de bonnes performances.

Merci d'avance.

C'est de bonne questions ça, me suis pas encore penché sur le problème, mais ça serait bien de savoir comment irrlicht gère les décors pour savoir comment optimisé en conséquence les objets et savoir s'il faudra aussi optimiser du code soit même...

Normalement un octree sert à partitionner l'espace pour détecter les objets. Donc on peu s'en servir pour masqué les objets hors camera ( je sais pas si irrlicht les utilise aussi pour ça ? ) ou encore pour localiser les objets et polygonnes pour les collisions, ce qui est le cas pour irrlicht.

D'ailleurs je me demande si les collisions d'irrlicht s'activent qu'une fois entrée dans le bounding box d'un objet, ou autrement... Car si c'est en permanence, le CPU vas en prendre un coup. Et si c'est par les  bounding box, raison de plus pour par faire les choses en un bloc

Puis il y a aussi le VBO pour accélérer le rendu des polygones en OpenGL, et je crois pas qu'Irrlicht les actives pas défaut non plus, faut y penser.

Sinon, pour masqué hors champs camera, il y a aussi le frustrum culling que Irrlicht doit forcement gérer automatiquement sur tous les objet je pense, mais apparemment il ne gère pas l'occlusion et prend tous se qui est devants la camera même s'il y à un mur à se qu'il me semble.

Quoi qu'il en soit, faire un décor en un bloque doit pas être une bonne idée, sinon l'optimisation doit en prendre un coup, plus d'autres problèmes qu'on peu avoir pour exploiter des éléments du décor par la suite.

sinon des infos plus généraliste sur les partitionnement de l'espace en 3D
http://glinfrench.apinc.org/article.php3?id_article=51
http://en.wikipedia.org/wiki/Octree
http://en.wikipedia.org/wiki/Kd-tree

Bon y'a pas grand monde pour apporter des précisions, cela dit y'a-t-il quelqu'un qui peut me confirmer si l'octree agit sur les triangles ou sur les objets ?

Merci d'avance

ah ma connaissance les octrees ne font que afficher les polygone visible a la cameras ...
par exemple le scene manager ne va pas afficher le node qui se trouve de l'autre coter d'un mure contrairement a un node normal ... enfin il me semble

Là en gros tu viens de dire polygones puis juste après node, c'est deux choses différentes... L'un composant l'autre.
Et je n'arrive vraiment pas à trouver de réponse claire à cette problématique parce que ça impacte sur toute la modélisation de niveaux.

jais oublier de préciser que si le node est a moitié visible seul les polygones visible sont afficher par le scène manager.
je devrais peut-être faire un schémas je ne suit pas très claire

dit le si tu en veut un !

Non pas besoin de schéma je pense, si tu es sûr que ce sont bien les polygones qui sont concernés par le sceneManager ça me va, ça m'arrange même

Donc pour bien récapituler, je peux modéliser un niveau complet en un seul mesh, donc un seul node (à moins qu'il existe d'autres techniques) et ajouter l'octree qui permettra donc de ne pas afficher les polygones hors champ de la caméra.

Si c'est ça c'est génial.

Le découpage des polygones hors frustrum de la camera fait en général partie du frustrum culling gérer d'origine par la plupart des moteurs, donc il doit fonctionner même sans les octree. C'est une optimisation classic du temps réel.

Pour les nodes, on peu toujours le vérifier avec un if(isVisible). Et aussi quand un node n'est plus visible, apparemment toute ses fonctions sont automatiquement désactivé, c'est bien pour le CPU, mais ça peu posé quelques soucis.

Quand on utilise l'octree, surtout pour les collisions, je pense qu'il utilise le bouding box, de toute façon on vas pas tester tous les polys de la scène en permanence, mais optimisé en général en fessant les détection d'abord par les bounding box pour faire le trie des box des objets visible ou pas, puis on découpe les polys qui dépasse. Hors, si on fait tout en un seul node, il n'y aura qu'un seul bounding box, outch !

Sinon j'ai fait un long couloir en octree, camera FPS avec full collision actif, et je regarde les FPS, je vais contre le mur du fond ou il n'y a plus de décor derrière, ça speed à max. Je me retourne ou je vois toute la deco, les FPS sont en chute libre. Je me cache derrière l'objet juste devants moi, avec le décors derrière, ça change quasiment rien. Donc ?

Sinon pour accélérer la deco en OpenGL faut activer le VBO, http://www.g-truc.net/article/vbo-fr.pdf Je pense pas qu'irrlicht le fait par défaut, faut donc faire une boucle qui scan les meshs de chaque node et les mettre dans le VBO.
Et si les nodes ne sont pas trop lourd en poly, faut débrider Irrlicht 1.5 en modifiant sa source et en le recompilant pour qu'il prenne en compte les petits objets dans le VBO.

A confirmer certaine chose, car les nouveautés du moteur ne sont pas très bien détailler, suis pas trop sur de leur fonctionnement en interne, car ça fait pas longtemps que j'utilise Irrlicht, et je voudrais pas dire trop de conneries...

Quand on utilise l'octree, surtout pour les collisions, je pense qu'il utilise le bouding box, de toute façon on vas pas tester tous les polys de la scène en permanence, mais optimisé en général en fessant les détection d'abord par les bounding box pour faire le trie des box des objets visible ou pas, puis on découpe les polys qui dépasse. Hors, si on fait tout en un seul node, il n'y aura qu'un seul bounding box, outch !

Pour moi le niveau qui est composé d'un seul mesh (donc node) n'entrerait pas dans la détection de collisions. Je pense faire une couche de capteurs. Plusieurs nodes qui représentent des parties du niveau et qui réagissent aux collisions, bien sûr, ces capteurs seraient invisibles, on appelle ça le masque de collision si je ne me trompe pas.

La logique serait donc de créer plusieurs nodes pour le masque de collision et donc les intégrer à l'octree pour que les tests de collision ne se fassent pas sur l'ensemble du niveau à chaque fois. Je peux même m'arranger pour que les différents nodes du masque de collision ne réagissent qu'avec les bounding boxes, faut voir ce que ça peut donner...

Dernière modification par Metallizer (05-03-2009 13:37:32)