4.4.4 Probl` eme avec l’index du gant Cybergrasp
Le gant Cybergrasp utilis´e pour ce projet comporte un d´efaut qui peut fausser la sensation ´eprouv´ee par les utilisateurs. Le fil exer¸cant la force sur l’index semble souffrir d’un l´eger frottement, provoquant des `a-coups relativement d´erangeants pour l’utilisateur.
4.4.5 Probl` emes de linking des librairies
Le nombre de librairies devant cohabiter dans le syst`eme est relativement ´elev´e.
De nombreux probl`emes delinking ont donc ´et´e rencontr´es durant le d´eveloppement.
La plupart de ces erreurs ont cependant pu ˆetre contourn´ees par le choix tr`es fin de l’ordre des lignes d’importations des fichiers.h.
4.5 Lancement du syst` eme
Pour d´emarrer le syst`eme, il est tout d’abord n´ecessaire d’instancier la classe Grasp_Simulator, repr´esentant le coeur du syst`eme, et la classeGrasp_InteractorQT, repr´esentant l’interface graphique. Ensuite, il faut instancier la classe g´en´erale QT QApplicationet afficher la fenˆetre principale du syst`eme. Puis, la p´eriode de som-meil des threads est r´egl´ee `a 1ms, la priorit´e de l’application maximis´ee et le thread principal peut ˆetre ex´ecut´e.
Pour permettre `a l’interfaceQT de g´erer les ´ev´enements syst`eme, il est n´ecessaire d’ex´ecuter la boucle principale QT. Cette routine est bloquante, elle doit donc ˆetre appel´ee `a la fin du programme.
Pour terminer, lorsque l’application est quitt´ee, la p´eriode de non-activit´e des threads est remise `a sa valeur par d´efaut.
#include <grasp_InteractorQT.h>
#include <grasp_Simulator.h>
void main( int argc, char* argv[] ) { Grasp_Simulator simulatorThread;
Grasp_InteractorQT qtWindow(&simulatorThread);
QApplication qtApp( argc, argv );
qtApp.setMainWidget(&qtWindow);
qtWindow.show();
timeBeginPeriod(1);
simulatorThread.setPriority(ZThread::High);
simulatorThread.start();
qtApp.exec();
timeEndPeriod(1);
}
Chapitre 5 R´ esultats
Dans ce chapitre, nous allons pr´esenter les mesures de performances, effectu´ees sur le syst`eme dans plusieurs configurations. Afin de tester la sensation ´eprouv´ee par des utilisateurs, nous avons effectu´e un test de perception entre des objets r´eels et virtuels. Les r´esultats obtenus sont pr´esent´es dans la seconde partie de ce chapitre.
5.1 Performances du syst` eme
Le syst`eme est suffisamment rapide pour permettre des interactions entre une main virtuelle et une sc`ene contenant des objets d´eformables simples. Cependant, si la librairie de d´eformation est puissante, elle n´ecessite une capacit´e de calcul relati-vement importante. Lorsque la sc`ene devient complexe, la lenteur des mises `a jours devient probl´ematique et le syst`eme perd en r´ealisme.
Pour am´eliorer la rapidit´e du syst`eme, nous avons optimis´e l’application pour fonctionner sur des ordinateurs bi-processeurs qui permettent, en raison du nombre dethreads utilis´es, un gain r´eel de performance. Cependant, pour effectuer des ma-nipulations sur des objets plus complexes, il serait n´ecessaire d’utiliser des machines tr`es puissantes, de meilleurs compilateurs ou d’optimiser les algorithmes du pro-gramme et de la librairie Biomodel.
Les performances de l’application ont ´et´e mesur´ees sur un ordinateur bi-Xeon 1700Mhz. Le programme a ´et´e compil´e sous Microsoft Visual C++ 6.0. Les quatre simulations suivantes ont ´et´e test´ees :
a) b) c) d)
a) Une membrane de 16 mol´ecules d´eformables retenues par un demi cadre de 9 mol´ecules fixes.
5.1 Performances du syst`eme R´esultats
b) Un cube contenant 27 mol´ecules d´eformables ainsi qu’une plateforme de 121 mol´ecules fixes.
c) Un cube contenant 8 mol´ecules d´eformables ainsi qu’une membrane de 49 mol´ e-cules d´eformables retenues par un cadre de 28 mol´ecules fixes.
d) Un parall´el´epip`ede de 75 mol´ecules d´eformables ainsi qu’une plateforme de 225 mol´ecules fixes.
Le tableau suivant montre les fr´equences de rafraˆıchissement (en Hz) des prin-cipaux threads mesur´ees pour les quatre simulations tests.
Test a) Test b) Test c) Test d)
Thread principale du syst`eme 35 19 15 7
Thread de mise `a jour de la sc`ene 131 90 79 38 Thread de mise `a jour de la force 403 424 430 440 Ces diff´erentes mesures montrent que les fr´equences de mises `a jour d’une sc`ene et du thread principal sont tr`es d´ependantes de la complexit´e de la sc`ene. En ce qui concerne la sc`ene, cela peut s’expliquer facilement. En revanche, pour le thread principal, cette constatation peut paraˆıtre ´etonnante. En fait, bien que la mise `a jour de la sc`ene soit ind´ependante et peut ˆetre ex´ecut´ee parall`element, ces deux threads ont tout de mˆeme besoin de se synchroniser `a certains moments pour obtenir des in-formations ext´erieures. Lors de sc`enes complexes, le thread principal devra attendre plus souvent que la mise `a jour de la sc`ene soit termin´ee. Il sera par cons´equent ra-lenti. Cependant, cette remarque ne remet pas en cause la s´eparation dethreads, car sans celle-ci la fr´equence de la sc`ene serait ´egale ou inf´erieure `a la fr´equence actuelle du thread principal, ce qui rendrait la simulation inutilisable en temps r´eel.
La fr´equence du thread de mise `a jour de la force est pratiquement stable entre les sc`enes test´ees. Il est, en effet, moins d´ependant des autres threads. Cependant, on remarque que sa fr´equence a, au contraire, tendance `a diminuer lorsque la sc`ene est moins complexe. Ceci est sˆurement dˆu au plus grand nombre de basculements entre desthreads diff´erents.
Dans la pratique, pour que l’application fonctionne de mani`ere acceptable et que la sensation de l’utilisateur soit suffisamment r´ealiste pour des interactions simples, il est n´ecessaire que lethread principal ne descende pas beaucoup sous les 20Hz.
En ce qui concerne l’affichage visuel 3D, il ne p´enalise pas les performances globales du syst`eme. En effet, les objets affich´es sont relativement simples et le temps de mis `a jour de l’affichage reste n´egligeable par rapport aux autres tˆaches effectu´ees par le syst`eme.