1 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle Noyau-unemachinevirtuelle... 4

Transcription

1 i 1 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle Introduction Conceptsd OpenMASK Noyau-unemachinevirtuelle Objetdesimulationfréquentielet/ouréactif Applicatifconfigurable Sessiondistribuable Conclusion Services d OpenMASK pour la réalité virtuelle Initialisations Visualisationsinteractives Sonorisations Interactions Coopérations Conclusion OpenMASK : Plate-forme d intégration et de capitalisation de services Handball - tirs au but GVT-formationàlamaintenance Musée virtuel de la photographie contemporaine Collaborationshaptiquesdistribuées Conclusion Remerciements Référencesbibliographiques... 33

2 ii Le traité de la réalité virtuelle 3ème édition

3 1 OPENMASK : UNE PLATE-FORME LOGICIELLE OPEN SOURCE POUR LA RÉALITÉ VIRTUELLE Bruno Arnaldi, Alain Chauffaut, Stéphane Donikian et Thierry Duval

4 2 Le traité de la réalité virtuelle 3ème édition 1.1 INTRODUCTION La réalité virtuelle peut être définie comme un ensemble de techniques matérielles et logicielles destinées à permettre à un ou plusieurs utilisateurs d interagir de la façon la plus naturelle possible avec des données numériques ressenties par le biais de canaux sensoriels. Les applications des technologies de la réalité virtuelle sont nombreuses et prometteuses. Néanmoins, leur usage reste à ce jour encore relativement limité, pour plusieurs raisons. Il y a tout d abord la complexité d intégration de tous les composants logiciels et matériels nécessaires. En effet, pour une application donnée, il est nécessaire d assembler le savoir-faire, et donc les programmes informatiques, provenant de différentes spécialités, sans nuire à la performance globale. Ensuite, le coût d équipement, même si une démocratisation est actuellement engagée, reste très élevé, provoquant une limitation naturelle au déploiement de ces technologies. Enfin sur le plan qualitatif, les utilisateurs des technologies de réalité virtuelle demandent toujours plus de réalisme et d interactivité parce que les deux promesses de la réalité virtuelle sont celles d une grande richesse de retour sensoriel et d outils d interaction puissants. Cependant, afin d être utiles, ce retour sensoriel et cette interaction doivent être calculés dans un intervalle de temps contraint, ce qui n est pas toujours compatible avec le temps de calcul des simulations sous-jacentes. L usage à plus grande échelle des technologies de la réalité virtuelle doit aussi passer par la mise à disposition d outils logiciels prêts à l emploi, permettant une intégration et une expérimentation rapide et efficace des composants logiciels et matériels nécessaires à leur mise en œuvre. L ensemble des travaux de recherche menés dans l équipe Siames 1, sur les thèmes de l animation, la simulation et la réalité virtuelle étant fortement complémentaires, nous avons décidé dès 1994 de mettre en chantier le développement d une plate-forme d animation et de simulation modulaire. Cette plate-forme avait dès l origine plusieurs objectifs : factoriser les développements logiciels, permettant ainsi à chacun de se focaliser sur sa propre activité de recherche tout en bénéficiant des résultats des autres membres de l équipe ; pérenniser les développements logiciels, permettant ainsi à quelqu un, démarrant son activité de recherche dans l équipe, de pouvoir s appuyer sur les travaux de recherches antérieurs réalisés dans sa thématique de recherche ; fournir le même environnement logiciel pour le développement sur une station de travail et pour la simulation lourde sur une machine parallèle ou sur un réseau de machines hétérogènes ; gérer la visualisation graphique en temps réel et interactive. Ces travaux ont conduit à l émergence de la plate-forme OpenMASK 2. Littéralement, l acronyme OpenMASK signifie {Multi-threaded Modular} Animation and Simulation {Kernel Kit}, ce qui présente la dualité de cette plate-forme concernant sa capacité à permettre un développement modulaire dans un contexte multi-activités. Portée par nos thèmes de recherche sur la réalité virtuelle, OpenMASK est donc dédiée 1. Projet de recherche de l Irisa (UMR 6074, unité mixte de recherche INRIA, CNRS, Université de Rennes 1 et INSA de Rennes) 2.

5 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 3 au développement d applications de réalité virtuelles et offre d emblée une panoplie de services utiles à ces applications. Ce chapitre va donc décrire dans un premier temps les concepts et grandes fonctionnalités de l environnement OpenMASK. Ensuite, nous présentons les composants et services fondamentaux dédiés à la réalité virtuelle. Nous terminons par la présentation d applications, réalisées au sein de Siames ou bien en partenariat industriel, illustrant le rôle essentiel de plate-forme d intégration et de capitalisation tenu par OpenMASK. 1.2 CONCEPTS D OPENMASK Les développements autour d OpenMASK résultent, d une part, de la volonté au niveau du projet de recherche Siames de disposer d un environnement de démonstration unique, permettant de fédérer l ensemble des travaux de recherche de l équipe et, d autre part, de disposer d un cadre de développement modulaire, performant et extensible. L enjeu majeur de cet objectif est d offrir la capacité de factoriser les développements et de permettre la réutilisation de composants qui une fois spécifiés et réalisés peuvent être exploités sans connaître le détail de leur mise en œuvre. La volonté de placer la base de cet environnement logiciel en Open Source sur la forge Inria 3 repose sur la conviction qu un tel outil est aussi adapté à une communauté de chercheurs et d industriels qui, soit sous la forme d utilisateurs, soit sous la forme de contributeurs, veulent participer à l émergence de cette nouvelle forme de développement. Sur le fond, l approche conceptuelle de développement retenue dans OpenMASK consiste : à proposer un cadre modulaire de développement logiciel fondé sur la notion de composant permettant d atteindre les objectifs d extensibilité et de composition ; à autoriser, par encapsulation, l intégration de composants logiciels extérieurs (exemple : modules en Open Source pour la détection de collision ou le calcul dynamique de composants mécaniques) ; à proposer un framework de développement constitué d un environnement d exécution (run time) et d un environnement de développement; à proposer un cadre permettant d atteindre la performance quel que soit le contexte (multi-machine, multi-processeur, multi-os, cluster de PC), sans créer de dépendance sur le développement des modules ; à proposer une solution logicielle qui puisse fonctionner sur des gammes de plates-formes matérielles différentes, s adaptant du PC portable à la visualisation immersive sur grand écran cylindrique ou plan de travail virtuel. OpenMASK est basé sur une strucure modulaire en trois couches encadrée par un framework de développement (figure 1.1) : le noyau : comme son nom l indique, il représente le cœur du système. Il met en œuvre l ensemble des services de base nécessaires à l exécution coordonnée d un en- 3.

6 4 Le traité de la réalité virtuelle 3ème édition FIG. 1.1 : Schéma conceptuel d OpenMASK. semble de modules (cf. section 1.2.1) et ceci, quel que soit l environnement d exécution ; l objet de simulation : dans OpenMASK, l unité de modularité est appelée objet de simulation. Il peut servir à décrire aussi bien le comportement et le contrôle du mouvement d un objet virtuel que la gestion d un périphérique d interaction. Cet objet de simulation dispose d attributs publics (entrées, sorties, paramètres de contrôle), communique par flots de données ou événements et fonctionne de façon fréquentielle et/ou réactive (cf. section 1.2.2) ; l application : avec OpenMASK, concevoir un environnement virtuel revient à choisir (ou programmer) les objets de simulation et à les paramétrer pour les adapter au contexte (cf. section 1.2.3) ; le framework de développement : il est constitué d un ensemble de classes abstraites permettant un développement rapide et sûr de nouveaux objets de simulation, ainsi que l implémentation et le déploiement des applications OpenMASK NOYAU - UNE MACHINE VIRTUELLE Afin de rendre indépendant le développement des objets de simulation de l environnement d exécution (système d exploitation, système distribué, machine parallèle), ce noyau peut être vu comme une machine virtuelle d exécution. En d autres termes, vis à vis de l application de réalité virtuelle, il joue le rôle de middleware et se charge d adapter les relations qu un objet de simulation entretient avec le système d exploitation ou avec un autre objet de simulation selon l environnement d exécution. Une autre manière d appréhender le noyau d OpenMASK est de le considérer comme le gestionnaire d un bus logique sur lequel les objets de simulation viennent se connecter. Ces

7 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 5 branchements permettent à la fois l échange d information (communication inter module), la synchronisation temporelle des modules et le contrôle, au sens paramétrage, des modules (figure 1.2). La programmation d un module est réalisée grâce à une API C++ ouverte pour le développement d objets de simulation et pour l adaptation des noyaux d exécution. FIG. 1.2 : OpenMASK : bus logique ou machine virtuelle. Vus d un objet de simulation, les services offerts par le noyau représentent les services du bus logique (middleware) ou de la machine virtuelle. Ces services concernent essentiellement : la création dynamique des objets de simulation : ce point concerne la création (au démarrage ou en cours de simulation) et la destruction (en cours de simulation ou à la fin) des objets de simulation et intègre les aspects de distribution sur un réseau de machines ; le nommage : ce service gère l identification et l accès aux objets de simulation et aux attributs relatifs à ces modules (entrées, sorties et paramètres de contrôle) ; l activation des objets de simulation : chaque objet de simulation doit être activé, au sens de l exécution, de manière régulière (mode fréquentiel) et/ou occasionnelle (mode réactif : sur réception d événements). Chaque objet peut avoir sa propre fréquence car une application donnée peut nécessiter plusieurs fréquences de calculs différentes en simultané : par exemple 50 Hz pour la visualisation, 200 Hz pour la simulation mécanique et 500 Hz pour le retour haptique. Le noyau lui même aura un fonctionnement fréquentiel dont la fréquence est calculée en fonction des fréquences des objets de la simulation ; la communication entre les objets de simulation : l échange de données ou d informations de synchronisation entre les objets de simulation peut se faire de deux façons : par flot de données ou par événements en mode point à point ou multicast. Les données sont datées au moment de leur production, cette date pourra être exploitée lors de leur consommation ; la gestion du temps : l activation comme la communication nécessitent un contrôle du temps. Cette gestion est prise en charge par le noyau qui offre des services

8 6 Le traité de la réalité virtuelle 3ème édition avancés. Par exemple, lors des échanges par flots de données, il fournit un mécanisme d adaptation fréquentielle des données à l aide d interpolateurs et d extrapolateurs utilisant un historique des valeurs. La machine virtuelle OpenMASK est donc un noyau abstrait qui est implémenté par un ensemble de noyaux concrets. En effet, il existe un noyau concret par type de configuration utilisée : par système d exploitation : actuellement le noyau d OpenMASK est porté sur plusieurs systèmes d exploitation (Irix, Linux, Windows, Mac OS). Pour aider à la maintenance de ces différentes versions, elles sont créées à partir d un source unique grâce à un effort important de normalisation et de portabilité ; par distribution des calculs : le fonctionnement multi-processus et multi-machines d OpenMASK repose actuellement sur PVM 4. Cette solution autorise l hétérogénéïté des calculateurs et des systèmes d exploitation lors de cette distribution. La distribution pourrait aussi exploiter d autres bibliothèques comme MPI ou Corba. Une caractéristique fondamentale d OpenMASK réside dans la transparence de la distribution, du point de vue du concepteur des objets de simulation. En effet, pour ce concepteur, sur le plan du développement logiciel, OpenMASK est vu comme une machine virtuelle unique. Un objet de simulation, développé sur cette machine virtuelle et s appuyant sur les modes de communication et services fournis, fonctionnera de la même manière soit en mode mono-processus, soit en mode multi-processus sur une ou plusieurs machines. Néanmoins, l application distribuée est contrôlée par l utilisateur qui associe, dans un fichier de configuration de la simulation, chaque objet de simulation à un nœud du réseau. De manière transparente à cet utilisateur, le noyau d OpenMASK va mettre en œuvre un mécanisme de référentiel (objet de simulation original) et de miroir (copie, sans le code de calcul, dont les données d interface vont être synchronisées avec l original) pour permettre la communication de cet objet de simulation avec les autres, indépendamment de l endroit physique (nœud du réseau) où il s exécute OBJET DE SIMULATION FRÉQUENTIEL ET/OU RÉACTIF L objet de simulation est l unité modulaire de développement d OpenMASK (figure 1.3). C est au sein de l objet de simulation que tout le code décrivant l évolution de l objet et son interaction avec les autres objets est localisé. Une question se pose lors de la conception d une application de réalité virtuelle : quelle doit être la granularité de l objet de simulation? Dans la pratique, ce choix est à la charge du concepteur/programmeur. En effet, OpenMASK n impose aucune règle quant au niveau de détail ou de complexité d un objet de simulation. L expérience des utilisations actuelles d OpenMASK montre que la granularité d un objet de simulation varie d une application à l autre. Par exemple un véhicule peut être modélisé en un seul objet de simulation chargé d animer l ensemble des mécanismes, à qui sera associé un seul fichier géométrique décrivant tout le véhicule avec ses points d animation. Il est aussi possible de le modéliser en une arborescence d objets de simulations inter-dépendants, chacun chargé de l animation d un sous-mécanisme du véhicule et possédant son propre fichier géométrique. De plus ces deux types de modélisation peuvent cohabiter à l intérieur d une même simulation. 4. Parallel Virtual Machine

9 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 7 FIG. 1.3 : L objet de simulation. Pour comprendre la nature précise de l objet de simulation, il est nécessaire d examiner, d une part, la manière dont cet objet communique avec l extérieur (avec le noyau d OpenMASK ou un autre objet de simulation) et, d autre part, la manière dont cet objet est activé (i.e. exécuté). De ces deux éléments déterminants nous déduirons l interface de l objet de simulation. Enfin nous présenterons la structure du code de calcul inséré dans l objet de simulation Nous parlerons de comportement de l objet pour exprimer l exécution de tout ou partie de ce code La communication Le rôle d un objet de simulation est de fournir le résultat d un calcul. Celui ci peut être établi de façon autonome (par exemple la génération d une trajectoire) mais le plus souvent il l est en fonction de données qui lui seront transmises par d autres objets de simulation (par exemple le suivi spatial d un autre objet). Il va donc devoir communiquer avec son environnement composé d autres modules de simulation. Deux modes de communication ont été élaborés : un mode flot de données : certains objets de simulation sont par nature des producteurs réguliers de données (simulateur mécanique, dispositif physique d interaction fonctionnant par requête d échantillonage temporel,...). De manière duale, d autres sont des consommateurs réguliers de données (visualisation, module logiciel de traitement d un capteur synchrone,...). Dans ce cas, un lien de communication flot de données doit être établi entre ces objets de simulation. Ce flot s établira entre une sortie d un objet et une entrée d un autre ;

10 8 Le traité de la réalité virtuelle 3ème édition un mode événementiel : d autres objets de simulation sont sensibles à des données ou événements (exceptions, signaux de configuration,...) produits par nature de manière asynchrone par le noyau ou d autres objets de simulation. Un second mécanisme, fondé sur des événements valués ou non, a donc été introduit dans OpenMASK. Ces deux mécanismes de communication entre objets de simulation garantissent l intégrité et la validité des données échangées ainsi que la transparente de la distribution L activation d un objet de simulation Le comportement d un objet de simulation peut être déclenché de deux manières différentes : la première concerne une activation régulière de l objet de simulation selon une fréquence donnée. Ce type d activation est typiquement utilisé pour la synchronisation avec le visuel ou pour l activation de modules de simulation mécanique d objets ; la deuxième technique d activation est réalisée sous forme de réaction événementielle. Son usage caractéristique concerne le traitement de dépendances asynchrones entre objets de simulation ou la réaction à des événements qui se produisent dans un univers virtuel tels que des actions de l utilisateur. L activation de chaque objet de simulation respecte aussi une liste d états possibles de l objet et chaque transition d état implique l exécution des méthodes concernées du comportement de l objet (cf section ) Une interface d attributs L objet de simulation est bâti autour d un ensemble d attributs qui constitue son interface de communication et d un comportement codé dans des méthodes génériques. Les différents types d attributs disponibles pour construire l interface d un objet de simulation sont les suivants : des entrées : une entrée est utilisée pour acquérir en continu les valeurs d une sortie d un autre objet de simulation. Elle permet d établir un chemin de données entre une sortie d un autre objet et l objet de simulation propriétaire de l entrée. Une fois établi, ce chemin de donnée donne un accès permanent à la valeur de la sortie à laquelle l entrée est branchée ; des sorties : une sortie est utilisée pour rendre public en continu une donnée (une position dans l espace 3D par exemple) d un objet de simulation dont la valeur a toujours un sens. Il convient de voir la déclaration d une sortie comme une déclaration d interface. La déclaration d une sortie ne doit être faite que dans le

11 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 9 constructeur de l objet de simulation, le noyau supposant que l interface d un objet est constante après sa création. De plus, cette contrainte garantit que cette interface est totalement préservée par héritage. La liste de toutes les sorties d un objet de simulation est stockée dans une table des sorties qui est accessible par tous les autres objets afin de permettre la découverte dynamique des propriétés d un objet. Cette forme simple de réflexivité est importante pour intégrer dans une même application des objets conçus indépendamment des applications utilisatrices des paramètres de contrôle : un paramètre de contrôle est un attribut accessible en lecture et en écriture via des accesseurs ; des auditeurs d événements : la réaction prédéterminée d un objet de simulation à un certain nombre d événements fait partie de son interface. Elle doit donc être préservé à travers l héritage et être visible. Les auditeurs d événements sont des objets dédiés remplissant ce rôle. Ils encapsulent des fragments de code qui sont associés à certains événements et qui sont automatiquement appelés lorsque ces événements sont reçus par l objet. En tant qu éléments de l interface d un objet ils doivent donc être construits dans son constructeur Un comportement Le code d un objet de simulation est réparti entre différentes méthodes qui seront appelées automatiquement par le noyau au cours de la session. Selon les choix du programmeur, un objet peut avoir un mode de fonctionnement synchrone (fréquentiel) ou asynchrone (réactif) ou encore mixte. Deux méthodes définissent l initialisation et la terminaison d un objet en plus de son constructeur, qui doit servir uniquement à déclarer les attributs de l interface de l objet, et de son destructeur : init : elle sera appelée après que le noyau aura créé tous les objets dont l instanciation a été demandée à cette étape de la session. Elle va servir par exemple à faire des branchements de flots, garantissant ainsi que tous les partenaires nécessaires existent bien ; finish : elle est appelée lorsque l objet doit être stoppé ; Le fonctionnement régulier, fréquentiel, de l objet est assuré par la méthode : compute : elle est appelée à chaque activation de l objet en mode fréquentiel. Un objet dont la fréquence est à zéro n utilisera jamais cette méthode. Le fonctionnement réactif asynchrone de l objet est géré en priorité par les auditeurs d événements (cf. section ) mais éventuellement ensuite par une autre méthode : processevent : elle est appelée avant l appel à la méthode compute lorsque l objet a un fonctionnement fréquentiel, sinon la prise en compte suit la fréquence du noyau.

12 10 Le traité de la réalité virtuelle 3ème édition Chaque phase de traitement réactif peut être encadrée par une méthode de prétraitement et une méthode de post-traitement redéfinies par le programmeur de l objet de simulation APPLICATIF CONFIGURABLE Une application (ou un applicatif) est définie par la mise à disposition d un ensemble de classes d objets de simulation dans un exécutable. Une session est l exécution d un applicatif en précisant toutes les instanciations d objets de simulation nécessaires. La définition d un applicatif ou d une session est réalisée par un opérateur qui est à priori une personne différente des programmeurs. Une façon courante de lancer un applicatif OpenMASK est de lui associer un fichier de configuration de simulation décrivant tous les objets de simulation à créer au démarrage. Nous appellerons par la suite ce fichier fichier de simulation. Les objets de simulation d OpenMASK peuvent être créés soit : 1. statiquement : leur description est faite dans le fichier de simulation ; 2. dynamiquement: à l initiative du programmeur; 3. dynamiquement: par le noyau en fonction des besoins des autres objets. Par exemple dans le cas de l exécution distribuée, puisque des objets miroirs sont créés au besoin pour communiquer avec les objets de simulation de référence (cf section 1.2.4) SESSION DISTRIBUABLE Dans les phases de conception et de programmation, OpenMASK peut être vu commme une machine virtuelle unique sur laquelle s exécutent des objets de simulation. Dans la phase d exécution, on peut envisager une distribution des calculs sur plusieurs machines, soit pour augmenter la puissance de calcul disponible, soit encore pour répartir géographiquement les utilisateurs. Cela peut aussi se justifier par le souci de réduire la latence de contrôle d un périphérique spécialisé ou la latence de réponse d un composant OpenMASK à un utilisateur. La distribution d une session implique une répartition du noyau sur tous les processus concernés ainsi que la distribution des objets sur ces processus. Chaque objet est donc associé à un seul processus. Cette affectation peut être décidée soit directement par le programmeur ou bien par l opérateur via le fichier de simulation. La distribution s appuie sur le concept de référentiel/miroir (cf section1.2.1). Les principes ont été présentés dans [S. Donikian e.a., 1998, Duval e.a., 2000, Margery, 2001] et peuvent être résumés en deux points : 1. chaque fois qu un objet de simulation a besoin d accéder aux données publiques

13 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 11 (sorties ou paramètres de contrôle) d un objet simulé sur un autre processus, ce dernier objet devient le référentiel d une copie locale qui est créée et appelée miroir. Ce miroir est une instanciation du référentiel associé mais sans code de calcul, dont les données sont synchronisées, automatiquement par le noyau, à chaque pas de temps avec celles de son référentiel ; 2. la cohérence et la synchronisation de tous les processus sont réalisées à l aide d un algorithme original qui permet la parallélisation du calcul d un pas de simulation et le transfert sur le réseau des informations de mises à jour. Cet algorithme met en œuvre une cohérence relâchée contrainte grâce à un paramètre appelé latence, qui permet de borner le nombre de pas de simulation qu un processus peut faire sans avoir reçu des informations de mise à jour suffisamment récentes. Comme illustré figure 1.4, un objet B d un processus 2 peut brancher une de ses entrées sur une sortie d un objet A situé sur un autre processus 1. Le noyau d Open- MASK va alors créer un miroir de l objet A sur le processus 2, permettre à l objet B de brancher son entrée sur la sortie du miroir de A. L objet B pourra alors demander des valeurs à ce miroir comme s il s agissait d un référentiel, c est le noyau qui se chargera de faire en sorte que les meilleures valeurs possibles soient disponibles au niveau des sorties de ce miroir. Méthode de calcul set (value) Référentiel A Processus 1 Sortie : position propagation de la valeur par le noyau Miroir A Processus 2 Sortie : position obtention de la valeur de l entrée par branchement sur la sortie du miroir Entrée : position get (dt) Méthode de calcul Référentiel B FIG. 1.4 : Le noyau maintient la cohérence entre miroir et référentiel Les derniers travaux autour du thème de la distribution ont été présentés dans [El Zammar C., 2005], ils portent principalement sur la possibilité de faire migrer dynamiquement des objets de simulation d un processus à un autre. Ceci peut être intéressant pour faciliter l interaction en rapprochant un objet avec qui un utilisateur souhaite interagir en le faisant migrer sur le processus de cet utilisateur (dans le cas d une interaction mono-utilisateur avec cet objet) ou bien seulement sur un processus plus proche de l utilisateur (dans le cas d une interaction multi-utilisateurs distants avec cet objet). Les résultats de ces travaux de thèse seront intégrés à moyen terme dans le noyau standard d OpenMASK CONCLUSION L état actuel d OpenMASK, même si de nombreuses améliorations peuvent encore y être apportées, permet de développer de réelles applications traitant de problèmes

14 12 Le traité de la réalité virtuelle 3ème édition dimensionnants. La stratégie de développement Open Source est de ce point de vue un excellent vecteur pour susciter des modifications/améliorations de la part de la communauté. 1.3 SERVICES D OPENMASK POUR LA RÉALITÉ VIRTUELLE OpenMASK est par définition une plateforme générique, dans le sens où elle permet le développement et l exécution de simulations de toutes natures. Cependant les travaux de recherche de l équipe Siames portant sur la réalité virtuelle, OpenMASK dispose d ores et déjà d un certain nombre de services opérationnels indispensables pour la réalisation d applications de réalité virtuelle. Ceux ci sont notamment une classe d objet de simulation dédiée à la visualisation 3D et des classes d objets de simulation permettant la mise en œuvre d expérimentations interactives multi-utilisateurs. Le noyau d OpenMASK étant naturellement distribué, le fait d intégrer un ou plusieurs services de visualisation et des mécanismes d interaction offre naturellement la capacité de produire des applications coopératives distribuées. Au fil des ans, les services de la plate-forme seront amenés à s enrichir grâce aux contributions et développements présentant un intérêt pour la communauté travaillant sur le thème de la réalité virtuelle INITIALISATIONS Le fichier de simulation est une représentation externe de l état initial d une session OpenMASK. Il comprend donc tous les objets de simulations qui seront créés au début de la simulation avec tous leurs paramètres initiaux. On y trouve aussi les processus impliqués dans la session et la localisation des objets sur ces processus. Nous disposons de plusieurs interpréteurs de fichier de simulation. Ils utilisent soit un format spécifique à OpenMASK, soit un format XML. L outil utilisant le format XML nous permet de sérialiser l ensemble des objets de simulation d une session dans un fichier à la syntaxe XML. L avantage est de disposer des deux fonctions symétriques de chargement et de sauvegarde des objets de simulation. Il peut bien sûr être utilisé pour le chargement initial depuis un fichier de simulation au format XML VISUALISATIONS INTERACTIVES OpenMASK-3DVis fût la première contribution logicielle fournie avec OpenMASK. C est un ensemble d objets de simulation, réutilisables et évolutifs, pour la visualisation, la navigation et la désignation dans des environnements virtuels animés. Dans la version 3.2, OpenMASK-3DVis est basé soit sur la bibliothèque Performer de SGI, soit sur la bibliothèque OpenSG 5 du Fraunhofer Institute. Il est actuellement disponible en Open Source avec Performer sous Irix et Linux, et avec OpenSG sous Linux et Windows. Un portage sur MacOS est en cours avec OpenSG. OpenSG correspond mieux à la politique de diffusion que nous envisageons puisqu il est lui aussi Open Source. 5.

15 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 13 OpenMASK-3DVis travaille en partenariat avec d autres objets de la simulation. Ses fonctionalités sont le chargement, la visualisation et l animation d une scène 3D. OpenMASK-3DVis propose un paradigme de désignation dans la scène et transmet les actions du clavier et de la souris au reste de la simulation. Nous proposons enfin un mécanisme simple et robuste d extension des fonctionnalités d animations du visualiseur générique Visualiseurs génériques et partenaires Dans une application de réalité virtuelle simple, le programme de visualisation est souvent le cœur du développement autour duquel se greffent les fonctions d animations et d immersion. Au contraire, dans OpenMASK, ce programme de visualisation n est qu un objet de simulation spécialisé, appelé visualiseur, avec lequel communiquent certains objets partenaires. Tous les objets d une simulation ne sont pas obligatoirement les partenaires du visualiseur. En effet certains objets traitent de fonctions totalement indépendantes de la visualisation comme par exemple la génération d une trajectoire. Pour devenir visualisable un objet de simulation doit devenir partenaire du visualiseur en héritant d une classe générique fournissant l API de communication avec le visualiseur. L objet de simulation va alors pouvoir déclarer lesquelles de ses sorties servent à l animation de sa géométrie associée : le visualiseur aura la charge de maintenir le lien entre ces sorties et les points d animation de la géométrie. Le visualiseur est l instanciation d une classe générique. Il peut y avoir plusieurs instanciations au sein d une même application. Ainsi nous avons présenté une démonstration de revue de projet automobile, collaborative et distribuée, via le réseau hautdébit VTHD 6, entre les centres Inria de Rennes et Grenoble. Dans ce cas, il y avait deux instances de notre visualiseur, l une contrôlant la salle immersive de Rennes et l autre le Plan de Travail Virtuel de Grenoble. Deux groupes d utilisateurs distants pouvaient voir et manipuler le même modèle de voiture - une Renault Scénic. Par simple modification des paramètres associés, chaque instance du visualiseur est adaptée aux trois canaux graphiques de la salle immersive ou aux deux canaux du Plan de Travail Virtuel. De la même façon, l opérateur peut choisir une vision en relief (stéréovision active) ou plate. Si il ne choisit pas une projection plein écran, notamment sur une station de travail, il peut définir une ou plusieurs fenêtres avec des points de vues différents sur la scène Scène 3D animée Dans les applications de réalité virtuelle ciblées par OpenMASK, en général, la scène ne peut pas être décrite a priori dans un fichier unique. Elle est plutôt le fruit de la composition de tous les participants visualisables de la simulation. Cette participation peut largement évoluer au cour d un session avec des départs et des arrivées. Du point de vue du visualiseur la scène animée est composée d acteurs évoluant dans un repère global et observés par des caméras. Un acteur est la représentation 6.

16 14 Le traité de la réalité virtuelle 3ème édition géométrique, interne au visualiseur, d un objet partenaire. Chargement de la scène 3D : le graphe de scène est construit automatiquement par le ou les visualiseurs de la session. Chaque visualiseur récupère chez chacun de ses partenaires le sous-graphe de scène définissant sa modélisation 3D. En cours de simulation le graphe peut dynamiquement être modifié par l ajout ou la suppression de sous-graphes liés à la création ou la destruction de partenaires en cours de session. La classe de partenariat ne précise pas la façon de fournir le sous-graphe. Nous proposons une première spécialisation qui permet de le transmettre via le nom d un fichier géométrique. Ce type de partenaire permet donc de décrire sa modélisation géométrique via tous les formats de fichiers externes dont le chargement est supporté par la bibliothèque utilisée par le visualiseur : Performer ou OpenSG. Nous proposons aussi dans ce kit un partenaire spécialisé pour placer et orienter simplement des éléments statiques de décor dans la scène 3D. De nouveaux types de partenaires peuvent être programmés par le mécanisme d extension proposé ( ). Visualisation de la scène 3D : la visualisation est entièrement pilotée par la simulation ou par l opérateur via des fenêtres et des points de vue. La gestion d un point de vue s appuie sur le concept de caméra. L opérateur ou un objet de la simulation, par l envoi d événements, peut contrôler à tout moment les paramètres d une caméra qui peut être posée sur le décor statique ou sur un objet mobile, ce qui ouvre vers tous les effets de mouvements de caméra envisageables. Nous proposons dans notre kit une classe Cameraman qui, associée au service d interaction de base, permet à l opérateur de déplacer une caméra dans toute la scène avec le clavier et la souris. Animation de la scène 3D : nous avons vu que le lien entre une sortie et un point d animation est installé automatiquement par le visualiseur lorsque le partenaire a déclaré cette sortie animable. Cette déclaration précise le gestionnaire d animation à instancier. Toutes les fonctions d animation sont programmées dans ces gestionnaires. Le principe est donc que chaque point d animation dans le graphe de scène est nommé, typé et associé à une sortie appropriée du partenaire. A chaque pas de simulation, la valeur de cette sortie fait évoluer le point d animation. Nous fournissons actuellement des gestionnaires permettant la mise à jour de degrés de liberté mécaniques (position, orientation, angles d Euler, quaternions,...), de couleurs, de commutation de modélisations (choix conditionnel entre des sous-graphes de scène). Nous avons également développé des gestionnaires d animation de surfaces déformables. Ces surfaces sont gérées par un petit nombre de points de contrôle que le partenaire doit simplement bouger pour les déformer. Sur le même principe nous proposons aussi des gestionnaires d animation permettant d agir directement sur les sommets d un maillage Interactions basiques via la scène 3D Le propre de la réalité virtuelle est d intervenir dans la simulation en agissant directement sur les objets de la scène 3D. Pour cela, il faut notamment pouvoir désigner un acteur ou une partie d acteur. Le visualiseur propose deux types de services de dé-

17 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 15 signation aux autres objets de simulation : désignation 2D : à partir d un point dans les coordonnées de la fenêtre de visualisation, le visualiseur rend une liste de noms d acteurs (ou parties d acteur) qui se trouvent sous ce point ; désignation 3D : le visualiseur rend la liste de noms d acteurs (ou parties d acteur) répondant à plusieurs catégories de critères spatiaux comme par exemple être transpercé par le segment orienté reliant deux points. Ce type de service est facilement extensible ou personnalisable. Le visualiseur propose aussi un service de transmission des événements claviersouris captés dans une fenêtre de visualisation lorsqu elle détient le focus Extensions des fonctions d animation Les types de partenaires et les modes d animation que nous fournissons constituent la base du visualiseur interactif, mais ils restent fortement inspirés par nos applications de validation. Aussi, nous proposons un mécanisme simple d extension des possibilités du visualiseur, par spécialisation de classes abstraites. Il suffit de définir un nouveau type de partenaire et de programmer le gestionnaire associé, ou de définir de nouveaux modes d animation et de programmer l effet souhaité dans les gestionnaires associés. Ces extensions ne nécessitent pas une recompilation du visualiseur. Elles sont apportées par le contributeur via une bibliothèque dynamique qui est intégrée à la contruction de l applicatif les utilisant SONORISATIONS Pour améliorer les restitutions sensorielles, OpenMASK propose un service de sonorisation de scène virtuelle. La sonorisation prend en compte des sources sonores (mobiles ou non) au sein d une scène ainsi que la position de l auditeur pour fournir une restitution sonore spatialisée. Une mise en œuvre basique s appuie sur la bibliothèque libre et gratuite OpenAL 7. Une autre mise en œuvre plus élaborée, que nous décrivons ici, utilise les capacités du logiciel, commercial, de création et de restitution sonore Max/MSP 8 développé par l IRCAM 9. Il est commercialisé par Cycling Max/MSP est la combinaison du logiciel MAX pour le contrôle temps réel d applications musicales et multimédia interactives et de MSP, une bibliothèque d objets pour l analyse, la synthèse et le traitement du signal audio en temps réel. Max/MSP est la référence mondiale pour la création d installations sonores interactives

18 16 Le traité de la réalité virtuelle 3ème édition OpenMASK et Max/MSP communiquent via OSC (OpenSound Control). A l origine OSC était un protocole dédié à la communication entre ordinateurs, synthétiseurs de son, et n importe quel autre dispositif multimédia. Aujourd hui ce protocole est optimisé pour les technologies modernes de gestion des réseaux, et est utilisé dans de nombreux domaines applicatifs. Max/MSP va créer et traiter des sons à partir de commandes envoyées par Open- MASK. Un son est associé à un fichier qui sera lu et mémorisé par Max/MSP. L application peut réutiliser un même son plusieurs fois dans des positions différentes ou avec des paramétrages différents. Chaque son souhaité se traduit par une chaîne de traitement d un signal qui part vers les cinq sorties sonores de notre salle de projection. Cependant toutes ces chaînes passent par un point central qui prend en compte des paramètres globaux à la scène et qui gère entre autres le caisson des basses. Le traitement traduit donc les message reçus : identification, volume, position, effets, etc... L architecture retenue dans OpenMASK est indépendante de Max/MSP. Elle s appuie sur la description de la scène sonore par un ensemble d objets de simulation et sur un objet (gestionnaire du son) dédié à la communication avec le système de restitution sonore. Ce gestionnaire permet de s adapter aux moyens logiciels et matériels dont on dispose. Le programmeur d une application sonorisée dispose d un certain nombre de classes d objets de simulation dédiées à la simulation d une scène sonore : les sons : la classe de son fournit des moyens pour piloter la lecture d une source sonore, pour la positionner et pour régler son volume. Lorsque le système de restitution le permet (comme MAX/MSP) on peut appliquer des effets aux sons et les piloter en temps réel. Un objet son ne crée pas explitement un son mais dispose d une banque de sons via les fichiers sonores disponibles et le gestionnaire de sons ; la scène : la scène regroupe tous les sons. On peut facilement changer de scène sonore au cours d une application, par exemple dans le cas typique d espaces sonores modélisant les différentes pièces d une maison : à chaque pièce correspond une scène particulière. Mais on peut aussi structurer sa scène en sous-scènes et gérer des coefficients d atténuation entre les pièces ; l auditeur : l auditeur permet quant à lui de positionner géométriquement le point d écoute dans la scène ; le gestionnaire de sons : le gestionnaire est le point de sortie des informations à destination du système de restitution. Il est associé à une scène et un auditeur uniques. Il gère la liste des fichiers son disponibles. Son interface avec les objets Open- MASK est indépendante du sytème de restitution ciblé. Une application collaborative distribuée pourra instancier plusieurs gestionnaires pour les différentes salles ou postes de collaboration INTERACTIONS Dans une scène de réalité virtuelle, l interaction met en jeu d un côté les opérateurs via différents périphériques et de l autre les objets de la scène virtuelle. La prise en compte d un grand nombre des périphériques de la réalité virtuelle s est faite dans OpenMASK soit par la programmation de pilotes dédiés, soit par l encapsulation de

19 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 17 la bibliothèque VRPN. Une façon de rendre les objets d une scène OpenMASK sensibles à l action de périphériques, donc de les rendre interactifs, est d utiliser le kit d interactivité développé par notre équipe Intégration des périphériques : VRPN Le Réseau Périphérique de Réalité Virtuelle (VRPN) est un logciel libre et gratuit mis à disposition par l Université de Caroline du Nord 11. VRPN est un ensemble de classes et un ensemble de serveurs qui sont conçus pour mettre en œuvre une interface réseau transparente entre les programmes d application et l ensemble des dispositifs physiques utilisés dans une application de Réalité Virtuelle. L idée est de confier à un PC ou tout autre centre serveur le contrôle des périphériques (capteur de position 3D, dispositif de bouton, dispositif haptique, entrées analogiques, etc). VRPN fournit alors à l application un service client avec tout serveur utilisant la classe de service appropriée à son type de dispositif. VRPN fournit des informations abstraites pour unifier des périphériques de même nature, par exemple des capteurs de positions. OpenMASK propose une bibliothèque d objets de simulation pour intégrer aisément l utilisation de VRPN dans une simulation OpenMASK. Cette bibliothèque est composée : d une classe abstraite encapsulant un client VRPN ; d exemples de spécialisation pour spacemouse et pour gants de données numériques. Une plus value est ajoutée par la définition d une métaphore d utilisation de la spacemouse ou du gant 5DT ; d un exemple de spécialisation pour l interprétation des événements envoyés par un client VRPN d OpenMASK. Cet objet, qui affiche les événements reçus dans un shell, peut servir d aide à la mise au point d une application ; d exemples de classes de simulation communiquant avec un client VRPN comme des navigateurs dans une scène 3D Kit d interactivité Un kit d interactivité [Duval T. e.a., 2004] est fourni avec OpenMASK. Ce kit est une bibliothèque de classes C++ qui propose des mécanismes pour, d une part, automatiser la transformation d un objet de simulation en un objet interactif et, d autre part, créer les outils d interaction (interacteurs) qui contrôleront ces objets interactifs. Ceci n est possible que si les objets de simulation respectent bien certaines règles de codage. La méthode s appuie sur l interface publique d un objet de simulation : ses entrées, paramètres de contrôle et sorties. Elle propose une approche générique de l interaction qui consiste à utiliser un protocole d interaction grâce à deux classes d outils : des adaptateurs génériques à réutiliser pour rendre interactif un objet de simulation : ils vont lui permettre d une part de communiquer avec des interacteurs, et d autre part de surcharger tout ou partie de son comportement ; 11.

20 18 Le traité de la réalité virtuelle 3ème édition des interacteurs génériques à réutiliser pour réaliser l interface entre un pilote de périphérique et un objet interactif : ici encore ils vont permettre au pilote de communiquer avec les objets interactifs. Nous obtenons ainsi une grande indépendance entre les objets interactifs des univers virtuels 3D et les outils qui permettront de les manipuler. Par exemple le déplacement d un objet doit pouvoir être indépendant de la nature de l outil d interaction utilisé pour exprimer ce déplacement : à partir du moment où un objet de simulation est déclaré déplaçable, il doit pouvoir être déplacé à l aide d outils virtuels aussi variés qu un rayon virtuel, une main virtuelle, un curseur 3D, ou encore tout simplement à l aide d un pointeur 2D classique. De nombreuses possibilités d interactions s offrent alors : il est possible de réutiliser les objets à manipuler et les supports d outils pour les encapsuler respectivement dans de nouveaux adaptateurs et de nouveaux interacteurs qui définissent de nouveaux protocoles de dialogue pour l interaction ; il est aussi possible de créer de nouveaux adaptateurs par héritage pour changer le comportement associé aux objets adaptés tout en gardant la connaissance du protocole d interaction ; symétriquement, on peut créer de nouveaux interacteurs par héritage pour changer le comportement associé aux outils d interaction, en gardant le même protocole de dialogue mais en changeant le mode de contrôle des objets manipulés. Parmi les adaptateurs permettant de rendre interactifs des objets de simulation, notons la présence d adaptateurs permettant d exprimer des contraintes cinématiques et de les faire respecter lors des interactions tout en les visualisant de façon à permettre aux utilisateurs de mieux comprendre les limitations des interactions dûes à ces contraintes, comme illustré figure 1.5. Ces adaptateurs ont été développés dans le contexte de PerfRV 12 [Arnaldi e.a., 2003] COOPÉRATIONS Partage d univers virtuels La version distribuée d OpenMASK (disponible en Open Source), permet de mettre en œuvre des applications coopératives locales ou distantes, en autorisant plusieurs participants à interagir au sein d un même environnement 3D, avec les éléments de cet univers (figure 1.6). En effet, OpenMASK permet de définir un environnement virtuel sous la forme d un ensemble d objets de simulation en interaction, en particulier des visualiseurs 3D (cf. section ). Cette coopération va donc être obtenue très naturellement, en instanciant plusieurs visualisations interactives et en les répartissant sur des machines différentes. Il devient ainsi possible de partager des univers virtuels 3D entre différents utilisateurs travaillant sur des machines distinctes reliées par un réseau

21 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 19 FIG. 1.5 : Visualisation des contraintes cinématiques à respecter durant une interaction FIG. 1.6 : Travail coopératif sur deux portables en réseau local.

22 20 Le traité de la réalité virtuelle 3ème édition Contrairement à des univers massivement coopératifs comme ceux d "Avatars" [B. Damer e.a., 2000], dans lesquels beaucoup de personnes peuvent se rencontrer mais ne peuvent pas produire grand chose dans l univers virtuel, OpenMASK vise plutôt des univers partagés par un petit nombre de personnes qui vont pouvoir coopérer finement sur des objets dans le but de produire un résultat tangible. Ces objets partagés, de haute technicité, peuvent être issus de milieux industriels variés (aéronautique, automobile, énergétique) et peuvent nous imposer des contraintes métiers exigeantes pour les interactions Perception des autres et de leurs actions Pour une interaction efficace, les participants doivent avoir une perception explicite des possibilités d interactions offertes, d une part, par les objets de l univers [M. Kallmann e.a., 1999] et, d autre part, par les outils d interaction mis à leur disposition. Enfin, comme les participants d une session coopérative de travail peuvent être situés sur des sites distants, ils doivent avoir la possibilité de percevoir de façon explicite, en plus de leurs propres actions, celles des autres utilisateurs [M. Fraser e.a., 1999, J. Hindmarsh e.a., 1998] pour rendre la coopération plus efficace et plus facile à comprendre. Cette explicitation des actions des autres nous semble particulièrement importante comme le montrent de nombreux travaux du domaine [M. Fraser e.a., 2000, C. Gutwin e.a., 1999, C. Gutwin e.a., 1998]. Comme OpenMASK permet de partager une session de travail en environnement virtuel sur différentes machines, au travers d un réseau, il a été décidé d associer à chaque point de vue interactif d une visualisation (donc à chaque utilisateur potentiel) une représentation de cet utilisateur sous la forme d un avatar qui se déplace dans l univers partagé, c est un premier niveau de perception de la coopération, comme illustré figure 1.7. Dans cet exemple, on perçoit également les outils d interaction de l autre utilisateur (ici des rayons virtuels situés devant son avatar). FIG. 1.7 : Visualisation des autres utilisateurs et des interactions de chacun Ceci ne suffit pas toujours à faire clairement percevoir aux autres utilisateurs de l univers les actions de cet utilisateur, et ce plus particulièrement lorqu il utilise un interacteur sans représentation 3D dans l univers (comme le clavier et la souris), c est pourquoi nous offrons des mises en évidences supplémentaires pour les interactions coopératives, qui représentent d une façon différente les interactions locales (celles associées à un interacteur lié à la visualisation locale) et les interactions distantes (celles

23 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 21 liées aux interacteurs associés aux autres visualisations, sur les autres machines). Ceci se traduit par des mises en évidence des objets en utilisant des couleurs différentes selon les utilisateurs (locaux ou distants) comme illustré figure 1.7. Pour des interactions coopératives synchrones, nous avons également développé des adaptateurs permettant à plusieurs utilisateurs d agir simultanément sur un même objet, en adaptant la mise en évidence des interactions sur ces objets. La couleur utilisée pour la mise en évidence des interactions peut alors être un mélange des couleurs associées à chaque interacteur Perception de la répartition des objets Lors de dégradations des performances du réseau (latence fluctuante, reroutages du réseau, coupure longue du réseau), chaque utilisateur peut avoir sa propre vision de l univers 3D partagé, différente de celles des autres utilisateurs à cause de ces dégradations. En effet, il y a presque toujours un écart entre les caractéristiques d un référentiel et les caractéristiques reflétées par ses miroirs sur les autres processus d une simulation distribuée. Dans le cas où la latence du réseau est très faible, cet écart est quasiment imperceptible par un utilisateur et ne nuit pas au travail collaboratif. Par contre, en cas de désynchronisation des processus, quand le réseau ne permet pas une transmission très rapide des données entre référentiels et miroirs, l écart peut être significatif et provoquer une réelle gène pour la collaboration. Nous avons donc décidé de chercher à rendre les utilisateurs conscients de ces problèmes réseaux afin qu ils puissent modifier leur comportement pour tenir compte de ces problèmes et ainsi parvenir à mieux interagir dans ces situations difficiles. La solution que nous apportons consiste tout d abord à gérer, sur demande de l utilisateur, un marquage des miroirs, c est-à-dire visualiser d une façon différente les miroirs utilisés par un site donné, afin d être informé que ces objets ne sont peut-être pas à jour à cause des dégradations des services offerts par le réseau. Nous offrons également la possibilité de créer des échos des derniers états connus des miroirs associés aux référentiels présents sur le processus de l utilisateur. On peut alors avoir un écart sensible entre un écho et son référentiel associé. Ces deux mécanismes illustrés figure 1.8 sont détaillés dans [El Zammar C., 2005]. Dans le cas d une latence fluctuante ou de l apparition de micro-coupures, cela permet aussi à un utilisateur désireux d interagir avec un objet distant de demander la migration de cet objet vers son processus. Cet utilisateur pourra ainsi interagir avec cet objet dans de meilleures conditions tout en attendant un rétablissement du réseau. Pour cela, nous avons dû ajouter une fonctionnalité au niveau du noyau distribué d OpenMASK : la capacité, pour un processus donné, d obtenir la liste de ses objets référentiels et la liste de ses objets miroirs. Nous y avons aussi ajouté la notion d objet local, de façon à pouvoir ajouter localement à un processus des objets dédiés à la mise en évidence.

24 22 Le traité de la réalité virtuelle 3ème édition FIG. 1.8 : Marquage des miroirs Placement d échos CONCLUSION Tous les services présentés dans cette section sont opérationnels et disponibles sur le site de téléchargement d OpenMASK 13, sauf le module de sonorisation basé sur Max/MSP qui nécessite une licence d exploitation de ce produit. 1.4 OPENMASK : PLATE-FORME D INTÉGRATION ET DE CAPITALISA- TION DE SERVICES OpenMASK est actuellement utilisé dans différents cadres applicatifs liés à la simulation interactive de systèmes complexes. Ces applications sont développées soit au sein de l équipe Siames soit en synergie avec des partenaires industriels ou institutionnels. Toutes ces applications s appuient non seulement sur les services proposés par OpenMASK mais nécessitent aussi l utilisation de ressources externes. Certaines utilisent l analyse et la synthèse de la parole via des logiciels commerciaux, d autres veulent intégrer des périphériques de réalité virtuelle ayant leur propre station de contrôle. Toutes expriment donc un besoin d ouverture et de communication vers l extérieur, au delà du service de simulation qui est la fonctionnalité intrinsèque d OpenMASK. Dans ces applications, on peut aussi percevoir des services qui ont une portée et un intérêt beaucoup plus large que le cadre de l application où ils sont développés. A l issue de tous ces développements, on peut constater que non seulement, OpenMASK n a pas été un frein dans la satisfaction de tous ces besoins, mais qu il s est plutôt révélé comme une plate-forme apte à l intégration et à la capitalisation de services à partir de contributions internes ou externes. Dans cette section, via la présentation de quelques exemples concrets d applications, nous souhaitons montrer les capacités d OpenMASK à : réaliser des applications industrielles (GVT, PerfRV) ; intégrer des outils matériels ou logiciels existants (Virtuose, Spidar, Phantom, VRPN, OSC, ODE, VCollide,...); inter-opérer avec d autres outils ou plate-formes y compris celles possédant leur 13.

25 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 23 propre boucle d exécution (ARéVi, Max/MSP, EyesWeb) ; capitaliser l émergence de nouveaux services (sonorisation, Humanoïde virtuel, retour d effort) HANDBALL - TIRS AU BUT En liaison avec le laboratoire de bio-mécanique de l Université de Rennes 2, nous développons une application d évaluation et d entrainement de gardiens de but de handball [Bideau e.a., 2004, Bideau e.a., 2003]. FIG. 1.9 : Gardien de Handball en salle immersive Dans notre salle immersive, nous installons un but de handball dans lequel prend place un véritable gardien avec des lunettes pour la stéréovision active et des marqueurs pour le suivi de ses gestes. En face de lui, sur l écran de projection en relief, se succèdent des tireurs virtuels. Le comportement de ces tireurs et la trajectoire du ballon sont gérés par OpenMASK. Le comportement et les tirs sont parfaitements calibrés pour pouvoir procéder à des mesures et répéter l expérience avec plusieurs gardiens. Les mouvements du gardien sont capturés en temps réel, transposés dans l espace virtuel de l application, et traduisent immédiatement la touche du gardien par rapport au ballon. Cette application s appuie sur un thème de recherche majeur dans l équipe Siames : l humanoïde virtuel. Il fait l objet d un chapitre spécifique dans le traité de la réalité virtuelle (Voir chapitre du traité sur les Humanoïdes). La modélisation et l animation de chaque humanoïde nécessite plusieurs objets de simulation traitant de la locomotion,

26 24 Le traité de la réalité virtuelle 3ème édition du comportement autonome, de la scénarisation individuelle ou collective. En amont d OpenMASK et indépendamment d OpenMASK un travail de préparation de ces humanoïdes s est révélé nécessaire : l acquisition de mouvements réels, l adaptation à la morphologie ciblée, l intégration de contraintes sur les mouvements, etc. De ce fait en plus d OpenMASK, nous développns aussi des outils de haut niveau générant du code pour OpenMASK. L outil amont actuellement le plus abouti en terme d intégration de fonctionalités et d ergonomie de l interface d utilisation est MKM 14 : Manageable Kinematics Motions. Basé sur de la cinématique, MKM synchronise, mélange et adapte des mouvements automatiquement [Ménardais e.a., 2004b, Ménardais e.a., 2004a]. Un humanoïde virtuel et ses mouvements produits par MKM peuvent facilement être exportés puis utilisés dans une applicaton OpenMASK (cf figure 1.10) grâce à une classe de simulation encapsulant le moteur d animation temps-réel d humanoïdes [Kulpa e.a., 2005] généré par MKM. Cette classe sait éventuellement produire des effets de skinning grâce à des informations complémentaires introduites, en amont, par le logiciel Avatar Studio. FIG : Application de Handball MKM peut exploiter des données de mouvement réels acquises par un système de capture de mouvements de type Vicon 15. Le système Vicon se retrouve aussi à l autre bout de la chaîne car il sert à capturer en temps réel les mouvements du gardien au cours d une session d entrainement OpenMASK. L application des tirs au but illustre à la fois l intégration d un équipement particulier : le Vicon, l intégration de code généré automatiquement (ici par MKM), et la mise à disposition de services de gestion d humanoïdes virtuels

27 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle GVT - FORMATION À LA MAINTENANCE Issu d une collaboration Recherche/Industrie (IRISA, CERV 16, GIAT Industries 17 ), le projet GVT (GIAT Virtual Training) constitue une plate-forme générique et modulaire pour le développement de sessions de formations utilisant la réalité virtuelle. Le contexte est celui de la formation à la maintenance industrielle exploitant la réalité virtuelle : sous la tutelle d un formateur, un ou plusieurs formés doivent acquérir un savoir faire sur des procédures complexes de maintenance. Une application GVT est multi utilisateurs : dans une session de formation typique, plusieurs apprenants utiliseront chacun leur ordinateur sous la surveillance d un formateur qui dispose également de son propre poste de travail (figure 1.11). GVT s articule en trois éléments essentiels : un moteur pédagogique d assistance au formateur qui réalise des réponses pédagogiques pour les élèves, un moteur de scénarios en charge de fournir les prochaines actions à réaliser de la part d un formé pour effectuer la procédure de maintenance et, un environnement interactif régi par un moteur d interactions qui est le cœur du système. Plutôt que de partir sur un développement vierge et entièrement nouveau, l approche initiale de GVT a été de réfléchir à l utilisation de supports que constituent les plate-formes de développement en général, et aux capacités de réutilisation de l existant. GVT a choisi de s appuyer sur deux plate-formes de réalité virtuelle déjà opérationnelles : ARéVi : c est la plate-forme de Réalité Virtuelle développée par le laboratoire de l ENIB à Brest. Elle est le support des développements portant sur les modules pédagogiques, qui constituent un nœud fondamental pour l outil de formation de GVT. OpenMASK : elle est ici au cœur de la réalisation de l environnement virtuel interactif, pour la distribution en réseau de la scène virtuelle, et pour la mise en œuvre de la scénarisation. Le cas de la distribution de la scène virtuelle sur un réseau est un nœud incontournable pour les évolutions de GVT qui portent sur des formations coopératives entre des formés. Comme OpenMASK, GVT a privilégié l interopérabilité et, par un code unique, la portabilité. Les formés répartis sur le réseau peuvent avoir des postes d apprentissage très variés, sans que cela n ait d influence ni sur le déroulement des formations ni leur mise en place. Avec la même application il est possible d utiliser GVT sur un ordinateur personnel ou dans un environnement immersif. Sur un ordinateur personnel, avec un simple couple clavier/souris, GVT informe le formé par un système de fenêtres à valider, et ce dernier réalise les interactions grâce à la souris : sélection d objet, calcul du menu contextuel, et sélection de l action à réaliser. Le clavier lui permet d effectuer les déplacements et les demandes d aides. Dans un environnement immersif, avec de nombreux moyens d interaction : gant de données, reconnaissance vocale, salle de projection immersive stéréoscopique, etc,

28 26 Le traité de la réalité virtuelle 3ème édition GVT communique par un système de synthèse vocale prenant en entrée directement les informations envoyées sous forme de fenêtres dans le cas précédent. GVT utilise un serveur vocal recevant les phrases à énoncer : Elan Speech 18 qui fonctionne sur une machine windows dédiée en réseau avec GVT. Pour interagir, le formé peut utiliser la reconnaissance vocale qui lui permet, entre autre, de se déplacer. Un système de tête traquée à base de capteurs magnétiques, dans le cadre d une projection stéréoscopique, lui permet également de petits déplacements locaux, dont le rôle est de faire ressentir au mieux le volume des objets et leur agencement. Le gant de données (image 1.11) permet de piloter un rayon virtuel pour la sélection des divers objets et actions dans la scène virtuelle. Tous ces périphériques permettent de dialoguer avec des interfaces standard de GVT. Cette application n est absolument pas liée à des supports physiques d exécution et d interaction, toutes les combinaisons sont donc permises. FIG : Formé en immersion et poste du formateur Le formateur de chaque session dispose de moyens de supervision d un ensemble de formés répartis sur un réseau. Il n agit pas dans les scènes 3D par une matérialisation de celles-ci, mais par une IHM 2D qui en réalise une abstraction et qui en offre les principaux contrôles. Il peut de cette manière vérifier l état d avancement de chaque formé par rapport à la procédure, et les écarts qu il a réalisé. Il peut aussi lui désigner les objets de la scène, lui envoyer des informations multimédia diverses, dialoguer avec lui, exécuter automatiquement des portions du scénario, ou encore déclencher des actions dans la scène qui auront pour vocation d aider ou de perturber le formé. L application GVT illustre l inter-opérabilité d OpenMASK avec la plate-forme ARéVi, la ré-utilisation de services d interaction existants évoluant de manière autonomes, l intégration d un outil externe de reconnaissance vocale et la maturité industrielle d OpenMASK

29 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle MUSÉE VIRTUEL DE LA PHOTOGRAPHIE CONTEMPORAINE Dans le cadre d une co-tutelle d encadrement avec l Université de Rennes 2, un étudiant des beaux-arts réalise, au sein de l équipe Siames, un musée virtuel de la photographie contemporaine. Le thème du musée porte sur les droits de la femme et les droits de l enfant. Les photographies sont associées par paires : une image en couleur représente une situation agréable d une société idéale proposée par les publicités ; l autre en noir et blanc représente une face cachée de la société réelle, une situation véridique mais dissimulée. Dans le musée, chaque image couleur masque son image noir et blanc opposée. L ambiance du musée est enrichie par une création sonore adaptée aux photographies et réagissant aux actions de l utilisateur. Plongé dans ce musée, un utilisateur peut se déplacer pour examiner les photographies et interagir avec elles en effaçant l image couleur pour voir celle en noir et blanc. Au départ, l utilisateur se trouve face à une image. Par des mouvements de corps et de bras, capturés par une caméra, l utilisateur peut : se déplacer à droite ou à gauche vers une autre image ; s avancer vers l image ou reculer ; effacer des parties de l image. FIG : L utilisateur dans le musée et le panneau de contrôle d EyesWeb Cette application OpenMASK est simple en termes de simulation ou d animation visuelle : c est essentiellement de la navigation. Elle illustre cependant l extensibilité de notre visualiseur de scène 3D par l adjonction d un nouveau gestionnaire d animation : la modification d une texture d image. Toutes les composantes sonores et musicales intégrées au musée ont été composées par des étudiants en musicologie de l Université de Rennes 2, d après les recommandations suivantes : se fier à leur sensibilité par rapport aux photos et insister sur le phénomène d immersion. Pour l approche sonore, les tableaux sont rassemblés en groupes de deux, trois ou quatre cohérents vis-à-vis de l aspect esthétique du musée. Pour chaque groupe, trois sons d ambiance sont positionnés autour de l auditeur. En plus de ce fond sonore, un son différent pour chaque tableau vient agrémenter légèrement l espace. Enfin, lorsque l utilisateur efface un tableau, découvrant ainsi la deuxième couche, différents effets sont appliqués petit à petit sur le son propre au tableau en question. Par

30 28 Le traité de la réalité virtuelle 3ème édition exemple, l effet de modulation en anneaux permet de passer d un son agréable et frais à une approche plus sombre voire pessimiste du tableau, tout en en découvrant visuellement la face réelle du monde. Le sentiment d immersion va être accentué par le système de diffusion organisé selon le principe suivant : la basse est diffusée au milieu du musée sur l arrière de l auditeur ; les fréquences médiums / aiguës sont diffusées de part et d autre du spectateur formant un espace frontal mobile ; la présence sonore est définie en fonction de la proximité du spectateur par rapport au couple de photos. Le musée virtuel utilise plusieurs outils externes à OpenMASK : EyesWeb 19 pour l interaction de l utilisateur par gestes reconnus à l aide d une caméra numérique grand public ; Max/MSP pour les réactions musicales ; OSC, comme protocole, pour la communication avec ces deux outils. L analyse d EyesWeb est envoyée à OpenMASK qui en déduit l animation de la scène 3D et les points de vue adaptés. Selon le comportement de l utilisateur, Open- MASK envoie à Max/MSP des directives pour la sonorisation de la salle immersive. FIG : Architecture logicielle du musée Open Sound Control (OSC) sert de protocole d encodage des échanges entre les trois plate-formes s exécutant, dans cette application, sous trois systèmes différents : linux, Windows et MacOS. EyesWeb et Max/MSP implémentent à leur manière ce protocole. L application OpenMASK utilise deux classes de simulation génériques fournissant une encapsulation d un récepteur ou d un émetteur OSC

31 OpenMASK : une plate-forme logicielle Open Source pour la réalité virtuelle 29 La plate-forme EyesWeb a été conçue initialement pour la création d applications multimédias intégrant la danse et la musique. Nous l utilisons sur un PC pour un sousensemble de ses fonctionalités gérant la capture et analyse de gestes humains. L interprétation de ces gestes par EyesWeb permet d en déduire des ordres de navigation dans la scène 3D. OpenMASK reçoit les messages via un objet de simulation OSC et met à jour la scène. Lors de l effacement d un tableau, EyesWeb est aussi chargé de calculer le pourcentage de la surface effacée. Cette information envoyée à OpenMASK permet de moduler les sons de la scène. Max/MSP est le suppport actuel du service de sonorisation d OpenMASK (cf section 1.3.3). Nous l utilisons sur station Apple PowerMac. Les séquences musicales sont contrôlées par l application OpenMASK en fonction de la position de l utilisateur dans la scène et de ses actions sur les tableaux.le contrôle se traduit par des directives envoyées à Max/MSP. L application du musée illustre bien l inter-opérabilité avec les plate-formes Eyes- Web et Max/MSP, l intégration du service de communication OSC et l extension du visualiseur pour la modification de textures COLLABORATIONS HAPTIQUES DISTRIBUÉES Le traitement du retour d effort est un domaine en plein essort pour les applications de réalité virtuelle. En effet, de plus en plus de dispositifs haptiques sont actuellement disponibles sur le marché et de nombreuses sociétés de l industrie manufacturière expérimentent de tels dispositifs dans des applications de prototypage virtuel telles que le montage ou le démontage virtuel. L équipe Siames a abordé ce domaine dans le cadre du projet PERF-RV avec l étude du montage virtuel dans le contexte automobile en partenariat avec Renault (figure 1.14). Cela a ensuite été étendu aux application haptiques collaboratives et distribuées par une démonstration se déroulant entre les centres Inria de Rennes et Grenoble via le réseau expérimental à très haut débit VTHD++. FIG : Visualisation immersive et retour d effort.

32 30 Le traité de la réalité virtuelle 3ème édition Nous proposons une architecture générique permettant la mise en œuvre du retour d effort dans OpenMASK. Cette architecture générique exploite les caractéristiques de modularité et de distribution d OpenMASK [Meyer e.a., 2002] : Quatre types d objets de simulation constituent la base de cette architecture : une classe pour le périphérique haptique ; une classe pour le modèle physique ; une classe pour le modèle de contact et de collision ; une classe pour le couplage virtuel. OpenMASK sert alors de bus logiciel entre ces différents composants (figure Bien sûr, OpenMASK fournit aussi le visualiseur de la scène 3D et d autres services d interaction. FIG : Architecture générique d une simulation physique avec retour d effort Compte tenu de la diversité des natures d objets à simuler dans une application réaliste, plusieurs types de simulateurs peuvent être nécessaires. La classe de simulation pour les modèles physiques nous a permis l encapsulation de simulateurs différents et en même temps capables de coopérer. Par exemple le démonstrateur d un robot à deux bras manipulant une pièce fait intervenir trois simulateurs en simultané (cf figure 1.16) : le simulateur Dynamo [Barenbrug, 2000] ; le simulateur SMR [Andrade, 2000] ; le simulateur et détecteur de collision Contact [Redon, 2002]. La principale difficulté résidait dans la coopération entre les trois simulateurs. Cela a été résolu et maîtrisé par la généralisation et l utilisation du principe du couplage virtuel [Meyer, 2003]. Plusieurs phériphériques haptiques ont été intégrés grâce à cette architecture générique : le bras Virtuose 6D 20 à 6 degrés de liberté de chez Haption ; le bras Phantom Premium 1.5/6DOF 21 de chez Sensable Technologies ;