Discussion :

[typedef]

Bonjour,

Je suis en train de faire un moteur de rendu et simulation 3D. J'ai commencé par implémenter un moteur graphique. Le coeur du moteur est composé d'une arborescence de Noeuds (relation parent/enfants). Chaque noeud est positionné dans l'espace, sais dessiner un mesh qui lui est propre etc.

Ainsi par exemple pour une voiture j'aurais l'objet voiture qui possède 4 enfants qui sont des objets roue, et un autre enfant qui est un objet Pilote.

La ou ça se complique, c'est lorsque j'ai besoin de modéliser un comportement avancé qui n'a pas d'impact graphique.

Pour modéliser ce comportement j'aurais besoin de séparer la couche métier de mes classe Noeuds de leur couche graphique. En effet le plus souvent ma couche métier n'aura pas la même hiérarchie que ma couche graphique.

par exemple, pour la partie graphique de la classe Pilote, afin que celui ci soit bien positionné par rapport a la voiture et bouge avec etc, ca semble logique que celui ci soit enfant de la voiture.
par contre, au niveau comportement, ca serai bien pratique que son parent ne soit pas la voiture, qui n'a évidement pas a controler le comportement du pilote, mais plutôt QG d'ecurie.

J'en suis donc arrivé a la conclusion, qu'il me faut deux arborescence. une de noeuds 'graphique', avec logique de hiérarchie d'affichage, et une de noeuds 'model' (au sens modèle comportemental) avec une logique de hiérarchie métier.

Toute l'intelligence est faite par l'arborescence Model, (ou le parent du pilote est bien QG ecurie). Chaque model pointe sur son noeud graphique (s'il en a un), et sais modifier les paramètres du noeud graphique comme bon lui semble (couleur, position etc). Le parent du noeud graphique gère lui, l'affichage logique de ses enfants.

Tout ca étant dit, ca pose d'énormes problèmes de synchronisation/gestion et autres, entre les deux arbres.
Le cas simple ou le pilote change d'écurie: l'instance de la classe modelPilote change de parent c'est simple. par contre qui s'occupe de dire au noeud graphicPilote associé que son parent n'est plus la même graphicVoiture ? Ca ne peut pas être modelPilote qui elle n'a rien a faire du parent graphique de son noeud graphicPilote, et qui ne sais da'illeurs probablement pas quel graphicVoiture sera le nouveau parent.

La plus part du temps dans les gros moteurs graphique open source, on n'a justement que la partie graphique qui est géré. on a souvent une arborescence de noeuds etc, mais tout est purement graphique.



- Savez vous quel pattern ou ensemble de pattern peuvent être utilisés pour réaliser ce que j'essaye de faire ?

- De manière générale comment est fait la séparation entre la modélisation comportementale et l'affichage dans les gros moteur de jeu ou de simu ?

- et au final est ce vraiment nécessaire comme séparation, n'y a t il pas d'autres solutions radicalement différentes ou plus pratique ?

Dsl pour les explications un peu longues, mais je n'ai pas reussi a faire plus court .

[unmanos]

Bonjour,

En general dans les moteurs il est indispensable de separer la partie graphique (affcihage) de la partie logique (comportements, collisions, ...).

En terme graphique, le systeme de noeud hierarchiques est tres puissant et pratique, mais pour gerer le comportement des objet c'est une autre histoire.

De mon point de vue (c'est un avis personnel), il faut donc avoir une gestion purement logique des objets, une sorte de "world manager" qui gere la logique, les collisions, eventuellement la physique. Chaque objet de ce monde (auquel il est possible de rattacher des comportements) sait construire un noeud graphique qui sera donc insere dans la partie purement graphique du moteur.

En pseudo code ca pourrait donner une chose comme ca:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
gfx::DisplayData LogicalObject::GetDisplayData()
{
    gfx::DisplayData dd;
    dd.PushWorldTransform(...);
    dd.AppendMesh(meshDisplayDataNode);
    dd.PopWorldTransform(...);
    return(dd);
}

Sachant bien sur que tout l'interet d'avoir un systeme de noeuds cote graphique (scene graph) permet de ne pas reconstruire a chaque frame le noeud graphique d'un objet (d'ailleurs c'est souvent assez lourd en perf, il faut absolument "cacher"). De plus l'interet du systeme comme celui ci est qu'un objet, dans sa partie logique a un controle total sur sa partie graphique tout en gardant l'avantage du scene graph. L'objet par example peut decider de liberer la memoire graphique correspondant a son noeud si il se trouve en dehors du fustrum de la camera ou si le noeud graphique n'a pas ete utilise depuis un certain temps (si en plus derriere il y a un bon systeme de gestion de datas, les texture inutilisees pourront automatiquement etre liberees). Ca permet de gerer un grand monde sans avoir tout le scene graph pour tous les objets en memoire. D'une maniere generale dans un jeu, le plus lourd en terme de memoire c'est les datas graphiques d'un objet (noeuds, texture, mesh), pas vraiment l'objet logique en lui meme, donc il me parrait judicieux de bien les separer.

[typedef]

Ta réponse me rassure un peu, je ne part pas complètement dans le mur.

Par contre un tel system me pose des problèmes de synchro.
le refresh de mes scene node est basé sur deux méthodes du type update et draw, appelés en cascade dans l'arbre. Dans mes model uniquement update est présente.
L'engine appel donc l'update du scene node root, puis le draw, et ensuite l'update du model root.
Et certains cas ou le scène node est déjà updaté mais pas encore son model me pose des soucis, mais je vais essayer d'améliorer mon design, je dois laisser encore trop de contrôle aux scene node.


Dans ton pseudo code, je vois que tu push et pop la matrice de transformation au scene node. Dans mon cas pour l'instant, c'est le scene node qui gere les transformations, le model node ne servant qu'a stocker et manager les datas vraiment décorélé de l'affichage.

En fait c'est quasiment uniquement ce a quoi servent mes scene node, gérer les transformations et le mesh de vertices/indices. penses tu que c'est une erreur et que les transformation doivent être géré par le model ?

Car pour le coup si je passe leur gestion dans le model, il ne restera vraiment plus grand chose dans le scene node.

[Mikmacer]

Salut! Pour le cas ou ta node n'Est pas updaté, mais otn modèle oui, il y a une solution simple à ça. Tu crées deux états de hiéarchies, une avec les anciennes informations de transformations, et une avec les nouvelles informations. La partie logique de jeu ne peut seulement accèder qu'aux anciennes informations, et lorsque toutes les nodes sont updaté, tu change l'ancien état par le nouvel état.

Aussi, pour ta question, personellement je pense que les transformations doivent être géré par la node graphique et non le modele.

Pour la partie "modele", je me demande si c'est vraiment nécéssaire de créer une hiéarchie prédéfinie à l'aide de nodes à la manière des nodes graphiques. Une hiéarchie de node, c'est lourd, et j'en vois pas nécéssairemenr "de gros avantages avantages qui servent à tout les coups" comparé à une simple liste d'entités logiques à ce niveau. Personellement, pour mon moteur, j'ai simplement un objet entité logique qui peut être liée à la root node des nodes graphiques qu'il a a gérer. Comme ça, lorsque j'enregistre la scène dans un fichier XML, je n'ai qu'à définir le type de l'entitée logique reliée à la root node d'une sous-hiéarchie graphique, et je n'ai jamais rencontré de gros problèmes avec cette manière.

[unmanos]

le refresh de mes scene node est basé sur deux méthodes du type update et draw, appelés en cascade dans l'arbre. Dans mes model uniquement update est présente.
L'engine appel donc l'update du scene node root, puis le draw, et ensuite l'update du model root.
Et certains cas ou le scène node est déjà updaté mais pas encore son model me pose des soucis, mais je vais essayer d'améliorer mon design, je dois laisser encore trop de contrôle aux scene node.

A mons avis, ce sont les objets logique qui savent ce qui dois etre mis a jour ou pas dans leur scene node. Dans le cas d'un arbre, il est evident qu'un update n'est pas necessaire. C'est meme dommage de faire l'appel de fonction... Alors que dans le cas d'un NPC par example, il peut s'y passer beaucoup de chose. Apeller l'update/draw sur tous les objets est a proscrire si tu souhaite pouvoir gerer beaucoup d'objet. Pour l'update il vaut mieux monter un systeme ou chaque objet peut decider de sa frequence d'update, pour le draw il faut un arbre qui permette de connaitre les objets visible sans avoir a tous les parcourir (style octree ou mieux, bvt).

Dans ton pseudo code, je vois que tu push et pop la matrice de transformation au scene node.

Dans mon cas pour l'instant, c'est le scene node qui gere les transformations, le model node ne servant qu'a stocker et manager les datas vraiment décorélé de l'affichage.

En fait a chaque push ou pop ca cree un noeud dans le scene graph qu'il est possible de modifier ulterieurement.

Je vois pas trop la difference entre scene node et model node. De mon point de vue il n'y a que des nodes, certains changent l'etat du driver (matrices, shaders, etats, ...) et d'autres affichent des choses.

En fait c'est quasiment uniquement ce a quoi servent mes scene node, gérer les transformations et le mesh de vertices/indices. penses tu que c'est une erreur et que les transformation doivent être géré par le model ?

A mon avis la separation de la partie graphique et de la partie logique doit etre completement separe. Ca rend le design plus simple et ca permet de reutiliser le systeme d'affichage 3D avec un autre "world manager" et vice versa.

Car pour le coup si je passe leur gestion dans le model, il ne restera vraiment plus grand chose dans le scene node.

Il restera toute la partie graphique... ce qui est le role d'un scene graph non? Et ca fait une sacree lib, la seule du moteur qui depend d'un third party (open gl / directx / ...). Presque la seule partie a modifier le jour ou tu dois porter ton moteur sur une autre plateforme.