Synchronisation moteur physique et moteur graphique

Version imprimable

11/04/2010, 17h21
Soack

Synchronisation moteur physique et moteur graphique
Bonjour,

Je suis actuellement en train de m'amuser à faire une simultion d'un système masse/ressort en 2D. Bon c'est vraiment pour m'amuser, j'ai trouvé un projet venant d'une école et ça m'a donné envie de le réaliser. Comme j'ai le soucis du détails, j'avais pensé à faire une sorte de découpe en deux modules: un module Graphique et un module Physique.

Donc pour le moment je suis partit sur deux moteurs basiques: GraphicEngine et PhysicEngine. Bon quand je dis basique, c'est que l'interface sera vraiment orientée pour l'application, par exemple pour PhysicEngine j'aurait: PhysicEngine.AddSpring et PhysicEngine.AddParticle.

Donc pour le moment, j'ai imagine qu'une Particule et un Ressort auront chacun deux éléments:
- PhysicItem
- GraphicItem

Et en gros dans ma boucle principale j'aurai:
1. Debut_MainLoop
i. Mettre à jour le moteur physique.
ii. Synchroniser la position des éléments avec leurs éléments physique.
iii. Mettre à jour moteur graphique.
2. Fin_MainLoop

En gros mon soucis c'est l'étape (ii). Comment, de façon élégante, assurer cette fonctionnalité ? Sur IRC on m'a conseillé un système d'abonnement, en gros par exemple dans ma classe Particle, et dans son constructeur, j'aurais:
Code:

1 2 3 Particle::Particle() { mPhysicItem.RegisterGraphicItem(mGraphicItem); }
Donc trois questions:
- Est-ce une bonne approche que de faire dépendre GraphicItem de PhysicItem ? (et vice-versa)
- Est-ce qu'il est mieux de faire une classe PhysicItemListener et donc de faire hériter GraphicItem de cette dernière ?
- Est-ce que vous avez une autre approche plus intéressante ?

Merci d'avance à ceux qui prendront la peine de me répondre! :)

C'est que très recement que j'ai commencé a faire du c++ donc ma réponse (tu trouveras) sera surement orientée C.

Personnellemment j'aurais créé une

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
class studied_system
{
       private :
              vector<object> My_Objects;
       public :
              //constructeur et destructeurs et autre fonction
              void actualise_forces_on_objects();
              void get_new_emplacement(double time);
              void show_objects();
}
 
 
 
 
class object
{
       private :
              struct emplacement pos;
              vector<Forces> force;
       public :
              //constructeur et destructeurs et autre fonction
              void get_new_emplacement(double time);
              void change_force(vector<Forces> new_forces);
}
 
void boucle(studied_system system, double precision, double rafraichissement)
{
         while(1)
         {
               system.actualise_forces_on_objects();
               system.get_new_emplacement(precision);
               if(time_last_call>rafraichissement)
                      system.show_objects();
 
         }
}

Voila, ce que je te proposerais..

11/04/2010, 18h26
bruno_pages

Bonjour,

il faudrait en savoir plus pour choisir entre la mécanique observateur/observé (éventuellement en l'adaptant) et une méthode plus 'directe' (cas de le proposition de NoIdea)

la couche graphique utilisée peut diriger le choix, par exemple si c'est Qt alors vous avez les slots/signaux qui sont une évolution de observateur/observé

déjà ne pas penser qu'une méthode 'directe' est forcément 'sale' et implique une connexion forte entre la partie graphique et la partie physique/calcul, le passage par des interfaces évite cela, et ce qui compte c'est d'éviter que la 'connaissance' soit réciproque.

avant d'aller plus loin il faudrait savoir au moins:
qu'elle couche graphique ?
a qu'elle vitesse voulez vous faire les mises à jour du graphique (saccadé, en continue) ?
les parties graphique et physique tournent-t-elles dans un même thread ?
11/04/2010, 18h50
Soack

Merci pour vos réponses, à mon tour de répondre aux votre.

* qu'elle couche graphique ?
> Pour le moment j'utilise la SFML avec un pixel par particule.

* a qu'elle vitesse voulez vous faire les mises à jour du graphique (saccadé, en continue) ?
> En fait suivant l'énoncé du projet, j'ai un fichier de configuration qui me donne le DeltaTemps minimum à attendre entre chaque rafraichissement. Il faut quand même que ça soit fluide.

* les parties graphique et physique tournent-t-elles dans un même thread ?
> Oui oui, tout dans le même thread.

La solution proposée par NoIdea n'est pas mal. En gros, je n'aurai pas vraiment besoin de m'encombrer d'un GraphicEngine et d'un PhysicEngine non ? Je peux tout faire dans ma boucle principale ?
J'étais partis sur cette approche, et j'ai eu peur qu'elle soit trop crade ...
11/04/2010, 21h35
bruno_pages

je pensais qu'il n'y allait avoir qu'un ressort avec une masse au bout

si vous avez beaucoup d'objet/particules à afficher alors cela change tout, surtout pas d'abonnement car cela va être très cher, mise à jour directe donc ... mais pas forcément salement comme j'ai précédemment répondu ;)

pour info, s'il y avait eu deux threads alors ce qui aurait provoqué le rafraichissement aurait été par exemple un envoi de message dans une mailbox