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

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

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

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

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

GASP : l’objet de simulation n C’est l’interface publique d’une entité virtuelle n 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 position S1:Suiveur positionSuivieposition S2:Suiveur positionSuivie

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

1 er paradigme de communication : le flot de données n A chaque pas de temps, il est possible de lire sur une entrée la valeur de la sortie à laquelle elle est associée n 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) n Le noyau assure la propagation des valeurs d’une sortie vers les entrées associées

Distribution du flot de données n Les objets peuvent être sur des processus différents n Les vrais objets sont des « Référentiels » n 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 n Le système propage les valeurs des sorties vers tous les miroirs

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

Synchronisation de la distribution n Chaque processus possède un ordonnanceur n 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 n Peu de temps perdu à attendre les autres... n Les propagations se font pendant le calcul...

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

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

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

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

2 ème paradigme de communication : l’envoi de message n 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 n 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

Distribution de l’envoi de message n L’objet destinataire (sur le processus courant) est un référentiel : êpas de problème, il traite le message n 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...

3 ème paradigme de communication : invocation de méthode sur objet dupliqué n 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é) n L’objet dupliqué a une représentation sur chaque processus : êil est possible d’invoquer directement des méthodes sur un objet dupliqué

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

Objets dupliqués et flot de données n 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 n Pas de problème pour les consultations classiques en flot de données

Objets dupliqués et messages n Les envois de messages se font vers toutes les instances de l’objet dupliqué : êvia un service de « multicast » offert par le noyau n 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é

Objets dupliqués et méthodes n Pas de problèmes dans le cas d’invocations de méthodes de consultation de l’état de l’objet (méthodes « const ») n 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

Objets dupliqués et méthodes n 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

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

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

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

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

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

Conclusion n 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

Perspectives n 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 n Augmenter les capacités dynamiques : êpermettre un ajout dynamique de processus êaugmenter la fiabilité, la tolérance aux fautes

Références n 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 n 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 n 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.