Etude du déplacement dans une scène de Réalité Virtuelle avec une Wii Balanceboard (Post-WIMP 19/20)
Sommaire
Equipe
L'équipe ayant participé à ce projet est composée de:
- Antoine Menut (MMIS)
- Romain Patalowski (MMIS)
- Emilien Rouger (MMIS)
- Manon Sutter (MMIS)
Problématique
Nous nous sommes intéressés au déplacement dans une scène 3D dans le cadre de la Réalité Virtuelle.
Pour pouvoir utiliser le casque de réalité virtuelle, des capteurs sont installés dans la pièce afin de repérer ce dernier. Le programme peut ainsi connaitre la position et la rotation relatives du casque par rapport à ces capteurs.
En général les logiciels de réalité virtuelle se servent de ces informations pour diriger la caméra de la scène virtuelle, dont le résultat est transmis dans le casque. Ainsi l'utilisateur est plus immergé dans la scène, la caméra suivant ses mouvements de tête.
Il apparait cependant une contrainte: le déplacement de l'utilisateur dans la scène virtuelle étant calqué sur le déplacement de l'utilisateur dans la pièce réelle, la pièce doit donc être de la même taille, ou plus grande que la scène virtuelle. On comprend ainsi rapidement qu'il faut un moyen complémentaire pour se déplacer plus loin dans la scène que ce que nous permet la place disponible dans la réalité. Ce moyen doit donc permettre à l'utilisateur de pouvoir rester relativement statique, tout en lui faisant parcourir de plus ou moins grandes distances dans la scène virtuelle.
Dispositifs existants (liste non exhaustive)
La téléportation
Cette solution est généralement mise en place uniquement à partir d'un pointeur, modélisé par la direction d'une des manettes tenues par l'utilisateur. Celui-ci peut alors rester totalement immobile, mais peut aussi garder l'avantage du tracking de son casque et se déplacer réellement et donc virtuellement.
Cette solution ne demande pas de matériel en plus de l'équipement de base. Aussi, elle permettrait de moins perturber le cerveau (pas de succession d'images mobiles), et donc de provoquer moins de nausée.
Cependant, nous pensions que cette solution faisait perdre un peu de l'immersion sur le déplacement longue distance.
Le 3dRudder
Le 3dRudder sert de joystick à l'utilisateur. Les translations selon deux axes se font en fonction de l'inclinaison du système (donc celle des pieds de l'utilisateur), la rotation est faite en fonction de la rotation du système.
Ce système ne peut être utilisé qu'assis. En effet, le dispositif étant très instable, il est difficile de s'y placer debout et de gérer les inclinaisons. Ce système perd alors lui aussi en réalisme.
Les cybershoes
Les cybershoes consistent en deux semelles à placer aux pieds de l'utilisateur. Le fait de glisser les pieds l'un après l'autre sur un tapis simule un pas dans la scène virtuelle.
Comme pour le système précédent l'utilisateur doit être assis sur une chaise, cette fois tournante pour qu'il puisse voir derrière lui, ainsi que faire demi-tour, la direction de marche étant celle du regard.
Il y a un gain au niveau du réalisme: cet artifice de marche permet la simulation d'un déplacement virtuel. Mais ici encore l'utilisateur est assis.
Le Kat VR
Le Kat VR est un tapis roulant multidimensionnel. L'utilisateur peut ainsi marcher dans toutes les directions, faire demi tour... La direction de marche étant controlée par une plaque dans le dos de l'utilisateur.
Ce système apparait comme étant celui qui immerge le plus l'utilisateur, qui reproduit le plus fidèlement les mouvements réels.
Cependant il reste très couteux et encombrant, toute personne voulant utiliser de la réalité virtuelle ne possèdera pas forcement ce système.
Notre solution
Le dispositif
Nous avons choisi la Wii BalanceBoard comme moyen de déplacement, notre but étant de savoir si c'est un dispotif viable pour le déplacement dans une scène 3D.
L'utilisation de la Wii BalanceBoard est très proche de celle du 3dRudder, mais nous avons décidé, pour plus d'immersion, que l'utilisateur se placerait debout sur la Balance et non pas assis.
Cependant, l'utilisateur n'a pas la possibilité de se retourner pour voir derrière lui, voire pour faire demi-tour. Notre étude va donc aussi se concentrer sur les différents moyens de rotations que nous pouvons mettre à disposition de l'utilisateur.
Différentes possibilités de rotation
Nous avons centré notre étude autour des interactions suivantes :
- Un mode où la rotation de la caméra est reliée aux capteurs latéraux de la WiiBoard. Concrètement, cela signifie que l'action de tourner est réalisée en se penchant vers la droite ou vers la gauche.
- Un mode où la balance permet de se déplacer dans les quatre directions principales (avant, arrière, gauche, droite), mais dans lequel le déplacement se fait dans la direction du regard. Ainsi, si l'on regarde 45° à gauche et que l'on avance, le déplacement se fera à 45° vers la gauche.
- Les deux modes précédents ne faisaient pas intervenir les contrôleurs du HTC Vive. Dans ce mode, ce sont des boutons latéraux sur les manettes qui permettent de faire une rotation "sèche" : 45° dans l'une ou l'autre des directions.
- Idem pour ce dernier mode, dans lequel les translations sont toujours gérées par la balance, mais dans lequel la rotation est gérée non plus par des boutons mais par un trackpad, ce qui permet d'envoyer non plus des informations binaires (bouton on/off) mais continues (position du doigt, effort presseur sur le bouton)
Technologies utilisées
Wii BalanceBoard
La Wii BalanceBoard possède des capteurs de pressions, placés sur chaque quart de la balance (marques rouges). Ils permettent au système de projeter le centre de gravité de l'utilisateur sur le plan de la balance. Elle se connecte au PC en bluetooth et les données de pression peuvent être récupérées avec l'application WiiBalanceWalker. Les actions de l'utilisateur sont alors envoyées à Unity sous la forme d'input clavier ou d'un joystick virtuel avec vJoy.
Nous avions tout d'abord trouvé un script C# permettant de récupérer les données de ces capteurs, pouvant donc être intégré à Unity (voir ci-dessous). Cependant, une fois sur Unity le script causait un plantage de l'application. Nous avons donc finalement opté pour ce logiciel "boite noire", qui a pour défaut, avec les inputs clavier, d'être très binaire et de ne pas permettre par exemple une augmentation de la vitesse de déplacement dans la scène virtuelle en fonction de l'inclinaison plus ou moins prononcée de l'utilisateur.
Unity
Unity est un moteur de jeu gérant le rendu. Très apprécié dans le secteur du jeu-vidéo, nous l'utilisons ici pour sa gratuité, sa compatibilité avec le HTC Vive, et sa capacité à pouvoir facilement manipuler du code sans avoir à se préoccuper de l'interface 3D. Il est facile d'ajouter des objets à la scène et d'y attacher des scripts pour modifier leur comportement. Son interface très pratique d'utilisation nous a permis de mettre en place différents tests et de pouvoir passer d'un test à l'autre directement grâce à l'interface ce qui rendait la série de test plus agréable pour l'utilisateur.
SteamVR
La récupération de l'ensemble des mouvements et des input générées par l'utilisateur s'est faite via l'interface SteamVR. SteamVR est un plugin Unity fournissant un ensemble de modules permettant de récupérer les informations de mouvement du casque et des contrôleurs. Il introduit notamment un objet de scène "CameraRig", représentant l'utilisateur dans la scène Unity. SteamVR introduit également son propre système de définition des actions : chaque bouton de la manette peut être mappé à une variable qui lui est propre, du booléen au triplet selon la nature des unités d'interaction (par exemple un booléen pour un bouton, mais un couple pour le touchpad). On peut alors directement récupérer ces données dans un script C# et les traiter. Dès lors, on peut effectuer diverses actions dans la scène, Unity mettant à disposition des variables d'environnement permettant de facilement manipuler les objets de la scène de travail.
C'est ce processus qui est derrière chaque input créée par l'utilisateur, et qui a permis de générer les différents mouvements étudiés.
Notre Etude
Implémentation des différents modes de rotation
La hiérarchie de caméras dans notre scène est composée comme suit:
- CameraRig, qui est la caméra basée sur les capteurs du casque
- Camera, qui est basée sur le casque lui-même
Nous voulions que les translations de la caméra ne se fasse pas forcément en fonction de la direction du casque. Camera Rig étant le parent du Camera sa position et ses rotations sont indépendantes du casque, mais elles influencent celles de Camera. Nous avons donc associé nos scripts de déplacement à CameraRig.
Cependant cette construction nous a posé des soucis au niveau de l'initialisation. En effet, au démarage, les axes de base de CameraRig n'était pas la même que celle du casque. La position de CameraRig était (0, 0, 0), son axe z était l'axe entre sa position et un des deux capteurs. Nous ne pouvions pas faire une rotation de CameraRig pour calquer son axe sur celui de Camera, puisque une rotation de la première cause une rotation de la deuxième. Nous avons donc stocké l'angle entre l'axe de CameraRig et celui de Camera et effectué les translations en fonction de cet angle. Exemple:
Pour une translation vers la droite: cameraRigTransform.Translate(new Vector3((float)Math.Cos(radAngle) * distance, 0, (float)Math.Sin(radAngle) * distance));
De même, pour les rotations, la position de CameraRig n'étant pas celle de Camera, faire une simple rotation de CameraRig faisait tourner Camera autour de celle-ci. Une fois encore nous ne pouvions pas changer la position de CameraRig sans changer celle de Camera. Notre solution à ce problème a été d'enregistrer la position de Camera, de faire une rotation de CameraRig. Cette rotation change la position de Camera, on calcule le vecteur de translation correspondant. Enfin, on translate la position de CameraRig de l'opposé de ce vecteur. Ainsi la position de Camera est restaurée.
Vector3 headPos = headTransform.position; cameraRigTransform.Rotate(0, 1, 0); cameraRigTransform.position += headPos - headTransform.position;
Les expériences
Description
Nous avons voulu comparer les différents modes de rotation au niveau du ressenti des utilisateurs mais aussi au niveau de l'efficacité de l'interaction à partir de la loi de Fitts.
Nous avons donc créé un script C# permettant de faire apparaître une cible rouge, de diamètre aléatoire, à une distance aléatoire de l'utilisateur, sur laquelle celui-ci devait se placer, faisant apparaître ainsi une nouvelle cible.
Les cibles n'apparaissent pas dans le dos de l'utilisateur (elles apparaissent entre -90° et 90° en fonction de la direction de ses pieds). Nous avons fait ce choix pour ne pas ajouter de la difficulté non mesurable.
Cette expérience était adaptable pour tous les modes de rotation, ceux-ci étant activables et désactivables à partir de booléens présents dans le script de contrôle de la caméra.
Critique de l'expérience
Comme énoncé prédédemment, les cibles ne devaient apparaître qu'à des endroits visibles plus ou moins directement par l'utilisateur. Or, pour le mode de rotation "Direction en fonction du regard", de nombreuses cibles se plaçaient dans son dos. Ce bug a possiblement biaisé l'étude.
Il aurait été intéressant de justement ajouter le demi-tour dans l'expérience, de faire apparaître sciemment des cibles dans le dos de l'utilisateur. Nous aurions alors gonflé artificiellement l'indice de difficulté des cibles, puisque que l'utilisateur est confronté à un temps de recherche additionnel. Nous aurions pu également mesurer et supprimer ce temps de perception.
Enfin, le décors de notre expérience n'était pas le plus adapté: il nous a en effet été rapporté qu'il était difficile de s'y repérer, la skybox étant partout la même, et la scène étant pratiquement vide.
Les résultats
Ressenti utilisateur
Les impressions des utilisateurs vis à vis des interactions présentées ont été les suivantes :
- La rotation par poids sur la WiiBoard a été plutôt bien reçue. Les plaintes se sont concentrées sur le problème de précision : en effet, le mouvement de rotation n'était pas progressif, si bien qu'il était compliqué de cibler un angle précis. Néanmoins, ce problème peut facilement être corrigé en implémentant une vitesse de mouvement progressive en fonction de la direction et de la force des efforts exercés par l'utilisateur.
- Dans le cas où le déplacement suit le regard, les utilisateurs ont plutôt apprécié ce mouvement. En revanche, le principal problème réside dans le fait que lorsqu'on regarde en arrière voire sur les côtés, l'action requise pour avancer (en l'occurrence ici se pencher en avant) devient bien trop compliquée. Cela provoque un inconfort chez l'utilisateur qui, en plus de devoir adopter des positions peu agréables, peine à maintenir un contrôle précis du mouvement dans ces conditions.
- Lorsque la rotation se fait sèchement (comme un cut en vidéo), nos sens sont déstabilisés. En effet, les changements brusques et complets d'environnement sont rares dans notre vie de tous les jours, et notre vision n'est pas adaptée à ce type de mouvements. En conséquence, nos utilisateurs se sont plaints globalement de pertes de repères
- Enfin, la rotation par trackpad a été la plus plébiscitée par les testeurs, qui ont particulièrement apprécié la maniabilité et le gain en contrôle conférés par le trackpad. Ce-dernier permet en effet de récupérer en temps réel la position exacte du pouce, et donc permet un mapping facile entre cette position et la vitesse de la rotation
Il a aussi été avancé que le côté binaire de l'activation de la balance (on/off) était assez frustrant. En effet, peu importe que l'utilisateur se penche beaucoup ou pas, sa vitesse est la même. Or beaucoup adaptaient leur inclinaison en fonction de la distance de la cible (pour aller plus vite), ce qui créait cette sensation de frustation.
La loi de Fitts
Pour chacun de ces mouvements, nous avons souhaité étudier quantitativement la réponse des sujets de test à chacune des interactions proposées. Pour cela, nous avons modélisé les données récupérées via une loi de Fitts, en tracant l'indice de difficulté en fonction du temps mis à atteindre les cibles : Temps = a + b*log2(1+DistanceCible/LargeurCible). Les résultats obtenus sont les suivants :
On observe que le déplacement en direction du regard obtient un indice de performance plus mauvais que les autres : une augmentation de 1 bit de l'indice de difficulté fait perdre 7.10 secondes à l'utilisateur. Cela s'explique par la difficulté qu'ont eu les sujets à tourner dès que les cibles s'échappaient de leur champ de vision. Ensuite viennent les rotation par WiiBoard et par trackpad, qui contre-intuitivement obtiennent approximativement le même indice de performance, bien que la seconde ait été fortement appréciée par notre panel. C'est même la rotation avec grip (rotation sèche, par à-coups), qui arrive devant en terme de performances.
Il est donc intéressant de noter que, d'après notre expérience, les performances ne seraient pas nécessairement corrélées au "plaisir d'usage" d'une interaction. Cette conclusion est cependant à remettre en perspective : il faudrait vérifier rigoureusement que ce résultat est bien lié à la nature des interactions étudiées, et non à des paramètres propres à notre étude, comme par exemple la non fluidité des différents mouvements, ou le manque de rigueur. Par exemple, on remarque que les données à temps 0 proviennent d'une mauvaise gestion de l'instanciation des cibles, qui parfois pouvaient apparaître juste en-dessous de l'utilisateur (celui-ci atteignait alors la cible instantanément). On observe aussi certaines durées très élevées, correspondant à des temps où l'utilisateur a éprouvé beaucoup de difficulté à atteindre sa cible (pour des raisons évoquées plus haut). Ces résultats extrêmes viennent perturber notamment la régression linéaire. Les données auraient pu être filtrées pour améliorer la qualité de l'analyse.
Malgré tout il faut prendre en compte que les coefficients de corrélation ne sont pas vraiment proche de 1, il aurait donc fallu que nous retraitions les données.
Conclusion
Notre étude a permis de mettre en avant plusieurs moyens de déplacement à longue distance dans un monde virtuel. La solution d'utiliser la WiiBoard s'est révélée très efficace pour l'utilisateur. Le principal enjeu a donc été de réussir à proposer des méthodes de rotation de la caméra, rendue impossible par le fait que l'utilisateur doive rester statique sur la WiiBoard et ne peut donc pas se retourner dans le monde réel. Pour cela, les différents moyens que nous avons proposés ont présenté chacun des points positifs comme la maniabilité du trackpad mais aussi parfois négatifs comme le côté trop brusque des rotations grâce au grip.
De manière générale, un point important d'amélioration possible serait le fait d'implémenter un déplacement progressif afin d'améliorer la maniabilité de la WiiBoard. Cela permettrait aussi de pouvoir proposer une vitesse de déplacement variable pour faciliter les déplacements de longue distance dans le monde virtuel.
De plus, notre étude s'est consacrée sur le déplacement dans le monde virtuel. Mais il faut garder en tête qu'en général, dans les logiciels de réalité virtuelle, l'utilisateur n'a pas pour seul objectif de se déplacer. Il va être amené à tenir des objets, aller les chercher et/ou les déplacer. Il serait intéressant de tester si la Wii BalanceBoard peut être utilisée dans le cas, par exemple, où l'utilisateur doit se baisser pour ramasser un objet. Dans ce cas, on peut imaginer que l'utilisateur engendrerait des mouvements non voulus en se penchant. Pour palier à se problème, il faudrait peut être mettre en place un système de désactivation du mouvement.
Finalement, les résultats obtenus ainsi que les retours utilisateurs ont été très encourageants, et en implémentant de légères modifications telles qu'un déplacement progressif en fonction de la position du centre de gravité de l'utilisateur sur la WiiBoard, on s'attend à obtenir une expérience efficace et agréable de déplacement couplée à une prise en main très intuitive pour l'utilisateur.
