• Aucun résultat trouvé

Limites du modèle d’abstraction actuel

Dans le document en fr (Page 115-118)

Si l’ensemble des travaux présentés dans cette thèse nous permet de valider la faisabilité et la pertinence du modèle proposé pour le support de la collaboration en RA/RV, ce modèle reste toutefois incomplet. Si l’on souhaite adresser l’ensemble des cas d’usage de la collaboration avec les supports de RA/RV. Il faudrait pour cela à minima étendre le

1. L’implémentation de WebRTC a été récemment réalisée dans nos navigateurs UMI3D à l’aide de l’extension de Unity 3D dédiée à ce protocole.

6.2. Limites du modèle d’abstraction actuel

modèle d’abstraction du protocole UMI3D pour traiter les problèmes ci-dessous.

6.2.1

Réalité Augmentée et Mixte

Pour commencer, si rien n’empêche aujourd’hui d’utiliser UMI3D pour interagir avec un média 3D en Réalité Augmentée ou en Réalité Mixte, la problématique de la pose 6-D du support reste ouverte. En effet, l’une des fonctionnalité de base en RA et RM est le positionnement, relatif au support de l’environnement réel ou d’objets réels. Nous regroupons les différentes manières d’établir la pose du support en trois catégories :

— Le positionnement, dans le référentiel du support, d’objets physiques par des mar- queurs (QR Codes, images) ou leur modèle 3D. Il existe pour ce faire de nombreuses solutions ouvertes comme ARToolKit [48] ou SolAR [78], et propriétaires comme Vuforia [68], VisionLib [90] ou Wikitude [95].

— Le suivi des mouvements du support par des algorithmes de SLAM (Cartographie et localisation simultanées). Cette technique permet notamment, lorsqu’un objet virtuel est déposé en RA dans un environnement réel, de fixer la position apparente de cet objet dans l’environnement réel grâce au calcul image à image du mouve- ment du support. Ces algorithmes ont par ailleurs été étendus à la relocalisation simultanée de plusieurs utilisateurs par l’algorithme de CoSlam [97] et ses variantes [59, 76, 46].

— Le positionnement du support par rapport à des ancres géospatiales. Il s’agit ici de positionner des artéfacts virtuels et le support dans un repère défini par ses coor- données dans le référentiel terrestre (latitude, longitude, altitude). Cette technique est propre à des travaux récents sur l’interaction spatialisée (Spatial Computing) visant à l’émergence d’un Cloud (nuage) dédié à la RA2. On peut ici citer les tra-

vaux de 6D.ai [1] qui propose une relocalisation géospatiale en six degrés de liberté grâce à un nuage de point centralisé de l’environnement réel, ou encore les travaux de la communauté Open AR Cloud pour définir les verrous technologiques restant pour l’implémenttion d’un AR Cloud multi-support [44].

Si certains standards ont été proposés par le passé, notamment pour la description de positions géospatiales (GML [24]) et/ou la description d’objets réels (ARML [56]), ils restent mal (voir pas) supportés par les outils de développements professionnels dédiés à la RA. De même, il n’y a aujourd’hui pas d’évidence concernant l’architecture et les algorithmes à utiliser pour la relocalisation simultanée de plusieurs supports de RA.

2. Le terme AR Cloud, proposé en 2017 par Inbar dans [42] est la dénomination utilisée pour désigner une technologie permettant le partage de la position d’ancres virtuelles dans le monde réel.

Chapitre 6 – Conclusion : Implications et Limites Actuelles de UMI3D

6.2.2

Description des zones navigables

La navigation dans les médias UMI3D est actuellement entièrement gérée par les navigateurs. Seul la définition par le média d’un ’mode’ de navigation (marche, vol, orbite) a été jusqu’ici testé, sans nous convaincre. En effet, ne s’agissant que d’une indication sur la manière dont l"’utilisateur était sensé ce déplacer, aucune contrainte n’était réellement imposée aux navigateurs. Cette approche ne permettait ainsi pas de décrire la manière dont l’utilisateur doit être capable de se déplacer dans un média 3D (zones navigables, zones interdites, points de téléportation, ascenseurs, véhicules, ...). Une des approches que nous souhaitons explorer à l’avenir est l’établissement d’un champ tri-dimensionnel dynamique de potentiel décrivant le coût de déplacement d’un point à un autre. Cette approche est notamment utilisée en robotique pour le déplacement autonome de véhicules [49].

6.2.3

Interaction directes entre un avatar et un média 3D

L’envoi par les navigateurs UMI3D d’informations sur le déplacement de l’utilisateur devrait, en plus de permettre une représentation des utilisateurs comme présenté dans le chapitre 4, fournir un moyen d’aborder efficacement l’interaction physique entre le corps de l’utilisateur et le media 3D. L’avatar de l’utilisateur étant en effet définis par le média 3D, celui-ci peut par exemple générer une réaction aux collisions entre l’avatar et les autres objets 3D le composant. Cette possible simulation physique ne nous semble toutefois pas suffisante. Nous étudions en effet actuellement la possibilité de lier certaines briques d’interaction avec un objet de sorte à guider/contrôler sa manipulation directe, par exemple par les mains de l’utilisateur. Nous envisageons par ailleurs la proposition d’une extension du protocole UMI3D de sorte à permettre une description générique de la physique du média 3D pour la génération de retours haptiques (ou pseudo-haptiques) par les supports en ayant la capacité. Cette description permettrait par exemple à un support disposant de périphériques à retour d’effort de simuler dynamiquement une interaction physique réaliste entre le média 3D et l’utilisateur. Le retour haptique pourrait alors être calculé localement au vu de la fréquence élevée demandée par le calcul de retours haptiques (typiquement 1000 Hz). À l’inverse, la mise à jour paramètres physiques des objets (poids, vitesse, élasticité) pourrait être rafraichis par le média (30 à 90 Hz).

6.2.4

Interprétation des performances utilisateur

Les outils et résultats préliminaires présentés dans le chapitre 5 nous permettent d’af- firmer qu’il est possible de mener des études utilisateur objectives de l’interaction avec UMI3D. Il faut pour cela coupler des données collectées en temps-réel par le média et par le navigateur UMI3D de l’utilisateur. Les données ainsi consolidées permettent alors

Dans le document en fr (Page 115-118)