Mécanismes de GASP permettant une coopération synchrone en univers 3D

1. Mécanismes de GASP permettant une coopération synchrone en univers 3D Thierry Duval - IRISA Siames GT 4.2 Collecticiels du GDR I3 et de l’AFIHM Lyon - 14 juin 2001

2. Introduction • Cadre de travail : • Simulation et animation en environnements virtuels 3D partagés … • Problématique : • Comment partager des interactions sur les objets qui constituent ces mondes 3D ? • Quels paradigmes sont nécessaires pour obtenir cette coopération ? • Solution : GASP …

3. Plan de l’exposé • Pourquoi GASP ? • Le flot de données • La distribution au travers d’un réseau • L’envoi de messages • L’invocation de méthodes • Les perspectives

4. Pourquoi GASP ? • Permettre la construction de mondes virtuels : • dont les calculs peuvent être distribués • partageables par plusieurs utilisateurs • Sans avoir à se préoccuper : • de la programmation réseau • de la visualisation 3D • des interactions 3D • En fournissant un environnement complet : • pour la programmation des entités du monde 3D

5. GASP : vue d’ensemble • Approche orientée objet (C++) • Descriptions des entités : • une interface : l’objet de simulation • un comportement : l’objet de calcul • une fréquence à laquelle le comportement est activé • Un monde virtuel est décrit par les entités qui le composent initialement (un fichier de configuration)

6. GASP : l’objet de simulation • C’est l’interface publique d’une entité virtuelle • Définition des attributs (nommés et typés) : • sorties de l’entité, • entrées à connecter sur les sorties d’autres objets • paramètres de contrôle qui stockent l’état de l’objet et peuvent être accédés en lecture et écriture par d’autres objets S1:Suiveur S2:Suiveur positionSuivie position positionSuivie position

7. GASP : l’objet de calcul • Gère la création et la connexion des entrées de l’entité • Lit les entrée de l’entité • Calcule les paramètres de contrôle et les sorties de l’entité SC1:SuiveurCalcul SC2:SuiveurCalcul S1:Suiveur S2:Suiveur positionSuivie position positionSuivie position

8. 1er paradigme de communication :le flot de données • A chaque pas de temps, il est possible de lire sur une entrée la valeur de la sortie à laquelle elle est associée • Cette valeur peut être demandée pour une date quelconque (fréquences différentes) : • si cette valeur n’existe pas, il peut y avoir une approximation (interpolation, extrapolation, antepolation) • Le noyau assure la propagation des valeurs d’une sortie vers les entrées associées

9. Distribution du flot de données • Les objets peuvent être sur des processus différents • Les vrais objets sont des « Référentiels » • Un miroir (« proxy », « fantôme ») d’un objet est créé sur chaque processus où se trouve un objet abonne à une sortie de son référentiel • Le système propage les valeurs des sorties vers tous les miroirs

10. Distribution du flot de données SC1:SuiveurCalcul S1:Suiveur positionSuivie position Processus A Processus B SC2:SuiveurCalcul S2:Suiveur S1:Suiveur (Miroir) position positionSuivie position

11. Synchronisation de la distribution • Chaque processus possède un ordonnanceur • Algorithme paramétré par la latence : • simulation à la date T seulement si on a reçu des informations des autres ordonnanceurs datant au plus de : T - dT - latence • on envoie les données destinées aux autres contrôleurs • Peu de temps perdu à attendre les autres ... • Les propagations se font pendant le calcul ...

12. Simulation mono-processus S8:Suiveur S7:Suiveur S6:Suiveur S5:Suiveur S4:Suiveur V1:Visualisation S3:Suiveur S2:Suiveur S1:Suiveur Noeud 1

13. Délégation de la visualisation S8:Suiveur S7:Suiveur S6:Suiveur S5:Suiveur S4:Suiveur S3:Suiveur S2:Suiveur S1:Suiveur mS8:Suiveur Noeud 1 mS7:Suiveur mS6:Suiveur mS5:Suiveur mS4:Suiveur mS3:Suiveur V1:Visualisation mS2:Suiveur mS1:Suiveur Noeud 2

14. mS8:Suiveur mS7:Suiveur mS6:Suiveur mS5:Suiveur mS4:Suiveur mS3:Suiveur mS2:Suiveur mS1:Suiveur Distribution des calculs Noeud 2 S8:Suiveur S7:Suiveur S6:Suiveur S5:Suiveur mS4:Suiveur S4:Suiveur V1:Visualisation S3:Suiveur S2:Suiveur Noeud 3 S1:Suiveur Noeud 1

15. mS8:Suiveur mS8:Suiveur mS7:Suiveur mS7:Suiveur mS6:Suiveur mS6:Suiveur mS5:Suiveur mS5:Suiveur mS4:Suiveur mS4:Suiveur mS3:Suiveur mS3:Suiveur mS2:Suiveur mS2:Suiveur mS1:Suiveur mS1:Suiveur Simulation coopérative typique Noeud 2 S8:Suiveur S7:Suiveur S6:Suiveur V2:Visualisation S5:Suiveur mS4:Suiveur Noeud 4 S4:Suiveur S3:Suiveur S2:Suiveur S1:Suiveur Noeud 1 V1:Visualisation Noeud 3

16. 2ème paradigme de communication :l’envoi de message • Tous les objets de simulation sont stockés dans un arbre, dans chaque processus : • chaque objet peut ainsi être référencé à partir de son nom ou de ses caractéristiques • Il est possible d’envoyer un message de façon asynchrone à n’importe quel objet : • le message sera reçu au pas de temps suivant • en mode distribué, les messages transitent avec les données de mise à jour des sorties des miroirs

17. Distribution de l’envoi de message • L’objet destinataire (sur le processus courant) est un référentiel : • pas de problème, il traite le message • L’objet destinataire est un miroir : • il transmet le message au processus qui héberge son référentiel associe • il y a création dynamique d’un miroir si nécessaire • la réception se fera au pas de temps suivant : • avec au moins 2dT+ latence de retard ...

18. 3ème paradigme de communication :invocation de méthode sur objet dupliqué • Objet dupliqué : • une instance d’un tel objet est créée sur chaque processus où c’est nécessaire (objet de simulation et calcul associé) • L’objet dupliqué a une représentation sur chaque processus : • il est possible d’invoquer directement des méthodes sur un objet dupliqué

19. Cohérence des objets dupliqués • Elle est à assurer : • pour les connexions en flot de données • pour les envois de messages • pour les invocations de méthodes • En supposant que le comportement de tels objets est bien déterministe ...

20. Objets dupliqués et flot de données • Chaque instance d ’un même objet dupliqué : • a ses entrées correctement connectées • a le même comportement que les autres • fournit les mêmes sorties que les autres • Pas de problème pour les consultations classiques en flot de données

21. Objets dupliqués et messages • Les envois de messages se font vers toutes les instances de l’objet dupliqué : • via un service de « multicast » offert par le noyau • Les messages seront donc tous traités de la même façon sur tous les processus : • cela garantit un état cohérent pour chaque instance d’un objet dupliqué

22. Objets dupliqués et méthodes • Pas de problèmes dans le cas d’invocations de méthodes de consultation de l’état de l’objet (méthodes « const ») • Aucune garantie si invocation d’une méthode non « const » « sauvage » : • les méthodes « invocables » sont celles qui modifient l’état de l’objet uniquement via ses paramètres de contrôle

23. Objets dupliqués et méthodes • Invocation de méthodes non « const » « correctes » : • les paramètres de contrôle des objets dupliqués sont des spécialisations des paramètres de contrôle de base • chaque modification d’un tel paramètre de contrôle dupliqué est enregistrée afin d’être propagée aux autres instances de l’objet dupliqué • toutes les instances d’un objet dupliqué « intègrent » alors les changements d’un paramètre de contrôle de la même façon

24. Interactions dans GASP • Une entité peut être contrôlée par une autre : • par envoi de messages • par connexions en flot de données • L’entité de contrôle peut être un dispositif d’interaction (pilote de bas niveau ou interacteur complexe) • Interacteur et objet interactif peuvent être situés sur des processus différents : • transparence pour le programmeur

25. Evénement SC1:SuiveurCalcul SC2:SuiveurCalcul SC8:SuiveurCalcul Demande de prise de commande Demande d’interaction positionSuivie position F1:Suiveur ... InteracteurCalcul positionSouris positionSuivie position Interacteur F7:Suiveur positionSuivie position F8:Suiveur

26. SC1:SuiveurCalcul SC2:SuiveurCalcul SCC8: SuiveurControlableCalcul SC8:SuiveurCalcul Acceptation de prise de commande Acceptation d’interaction positionSuivie position F1:Suiveur ... InteracteurCalcul positionSouris positionSuivie position Interacteur F7:Suiveur positionSuivie position F8:Suiveur position

27. Coopération dans GASP • Plusieurs interacteurs, situés sur des processus différents, manipulés par des personnes différentes, peuvent être utilisés simultanément • Pour contrôler des objets différents : • un utilisateur par objet • Pour contrôler un même objet : • plusieurs utilisateurs par objets • intégration réalisée par l’objet

28. Divers points techniques • GASP : • est écrit en C++ • utilise PVM pour la coopération • utilise Performer pour la visualisation 3D • fonctionne actuellement sur IRIX (SGI) et LINUX • Portage open-source à partir de fin 2001

29. Conclusion • Les différents paradigmes de communication entre entités offerts par GASP : • sont parfois contraignants … • sont coûteux en terme de bande passante • permettent une distribution des entités : • parfois très utile pour les pilotes de périphériques • autorisent des coopérations synchrones entre plusieurs utilisateurs : • validation sur sites distants via le réseau VTHD

30. Perspectives • Limiter l’usage de la bande passante : • introduire du « dead reckoning » • ne propager sur le réseau que ce qui est « visible » (« utilisable ») par un autre processus • Augmenter les capacités dynamiques : • permettre un ajout dynamique de processus • augmenter la fiabilité, la tolérance aux fautes

31. Références • T. Duval, D. Margery : ``Using GASP for Collaborative Interactions within 3D Virtual Worlds'', Second International Conference on Virtual Worlds (VW'2000), Lecture Notes in Computer Science, Artifial Intelligence series (Springer LNCS/AI), Paris, France, juillet 2000. • T. Duval, D. Margery : ``Buiding Objects and Interactors for Collaborative Interactions with GASP'', Third International Conference on Collaborative Virtual Environments (CVE'2000), ACM, San Francisco, USA, septembre 2000. • T. Duval, J. Regincós, A. Chauffaut, D. Margery, B. Arnaldi : ``Interactions collectives locales en immersion dans des univers virtuels 3D avec GASP'', ERGO-IHM 2000 (Ergonomie et Interaction Homme - Machine), Biarritz, octobre 2000.