#0 

02-03-2009 09:08:27

Metallizer
Abonné
Lieu: Région Parisienne
Date d'inscription: 07-01-2007
Messages: 100
Site web

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.

Hors ligne


#1 

02-03-2009 18:02:19

Steph
Membre
Date d'inscription: 02-03-2009
Messages: 15

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

Hors ligne


#2 

04-03-2009 16:06:49

Metallizer
Abonné
Lieu: Région Parisienne
Date d'inscription: 07-01-2007
Messages: 100
Site web

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

Hors ligne


#3 

04-03-2009 20:01:01

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 902
Corrections: 2
Site web

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

Hors ligne


#4 

04-03-2009 22:04:20

Metallizer
Abonné
Lieu: Région Parisienne
Date d'inscription: 07-01-2007
Messages: 100
Site web

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.

Hors ligne


#5 

05-03-2009 02:27:21

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 902
Corrections: 2
Site web

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 hmm

dit le si tu en veut un ! smile

Hors ligne


#6 

05-03-2009 10:52:36

Metallizer
Abonné
Lieu: Région Parisienne
Date d'inscription: 07-01-2007
Messages: 100
Site web

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 big_smile

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.

Hors ligne


#7 

05-03-2009 12:52:53

Steph
Membre
Date d'inscription: 02-03-2009
Messages: 15

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...

Hors ligne


#8 

05-03-2009 13:30:31

Metallizer
Abonné
Lieu: Région Parisienne
Date d'inscription: 07-01-2007
Messages: 100
Site web

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)

Hors ligne


Options Liens officiels Caractéristiques Statistiques Communauté
Corrections
irrlicht
irrklang
irredit
irrxml
xhtml 1.0
css 2.1
Propulsé par FluxBB
Traduit par FluxBB.fr
Analysé par
872 membres
1423 sujets
11109 messages
Dernier membre inscrit: Glider
12 invités en ligne
Aucun membre connecté
RSS Feed

[ Générée en 0.030 sec., 10 requêtes exécutées ]