L'infographie 3D collaborative (Post-Wimp 17/18)

  Troisième Année 

Page pour le projet Post-Wimp 2017/2018 : L'infographie 3D collaborative

Introduction

Contexte (humain)

Nous avons pu constater des problèmes lors des du travail collaboratif autour des données visualisées (souvent du 3D projeté en 2D) sous forme de diagramme en bâtons principalement. En effet notre outil d'interaction face à cette vue 3D projetée en 2D est la souris. La souris n’ayant que 2 degrés de libertés, il est très difficile de positionner l’élément dans la position désirée et il est difficile d’évaluer si les barres de l’histogramme 3D ont la même taille en perspective.

Notre solution : visualiser cette infographie 3D avec des lunettes de réalité augmentée et interagir avec l’histogramme à l’aide d’une wiimote, dont un pointeur de couleur qui indique la position sur l’histogramme. Les lunettes de réalité augmentée à notre disposition étant de qualité limitée, nous avons choisi pour notre projet d’utiliser un oculus rift (cet équipement ne permet donc malheureusement pas de voir ses collègues). D’autre part, les wiimotes à notre disposition (avec un accéléromètre et la sensor bar) ne nous permettaient pas d’accéder au yaw (déplacement gauche droite cf photo). Nous avons donc acheté une wii MotionPlus pour avoir accès à tous les degrés de liberté.

Objectifs (humain)

Notre projet à pour but d’améliorer les interactions et la précision des analyses de données au sein d’une équipe. Le but de ce projet est de montrer que l’interaction post-wimp utilisée est justifiée.

Description de la solution envisagée (point de vue humain)

La solution possède plusieurs composantes :

- La visualisation d’un histogramme en 3D avec l’oculus rift, un menu est présent afin de changer de fichier de données, changer les couleurs, etc.

- Un pointeur coloré de la wiimote sur la scène pour permettre à l’utilisateur de montrer un endroit en particulier à ses collègues.

- L’interaction avec l’histogramme grâce à la wiimote (yaw pour tourner l’histogramme)

Nous tenons à préciser que nous avons développé la version 0 (sans les options auxquelles nous avions pensé au début) car il nous semblait plus intéressant dans le cadre de ce cours de se pencher sur l’aspect Post-Wimp et plus particulièrement sur l’efficacité de notre solution.

Etat des lieux de ce qui a été réalisé et problèmes rencontrés (technique)

Mettre en place le matériel

Nous avons eu des problèmes lors de la mise en place du matériel par exemple pour la wiimote (l’api n’est pas une api officielle, elle a été faite par un utilisateur), c’était donc assez compliqué à utiliser. La documentation n’était pas très précise. De plus, on ne peut pas récupérer les données directement, il faut faire un choix, qui n’est pas du tout évident. Finalement, suite à cette mise en place, nous nous sommes rendus compte du fait que l’accélérateur et la sensor bar dans la wiimote ne prenait pas en compte la rotation “yaw”. La solution pour pallier cela a été d’acheter une wii MotionPlus (composant amovible contenant un accélérateur complet).

Sensibilité de la wiimote

Le curseur de la wiimote était trop sensible (tremblement même sans faire de mouvement) ce qui rendait difficile l’interactivité. De plus pour faire la rotation “yaw’, il y avait toujours une composante verticale qui n’était pas voulu.

API requête via Bluetooth

Nous avons eu des difficultés pour accéder aux données de la wiimote, en effet nous ne récupérions aucune donnée en faisant une simple affectation. Et la documentation pour l’API Bluetooth est vraiment minime. Le problème étant que la connection Bluetooth est lente, nous avons donc fait une boucle while (tant qu’aucune donnée n’est reçue).

Génération de l'histogramme

Il y avait un problème pour créer l'histogramme. Si vous vouliez le dimensionner, il ne fonctionnait pas tout à fait, les objets étaient placés incorrectement avec la mise à l'échelle. Ceci est dû aux points d'ancrage d'Unity et pourrait être corrigé en donnant aux objets un GameObject parent et en les plaçant au milieu et en redimensionnant le GameObject parent à la place.

Programmation au sein d'un logiciel

Il faut tout d’abord se former au logiciel pour pouvoir commencer le projet, et la collaboration au début n’était pas facile au début (quels fichiers partager, etc.). De plus les différentes versions de Unity nous ont posé des problèmes de compatibilité au départ.

Evaluation de l'interaction créée

Dans l’optique de ce qui a été présenté en cours, nous avons voulu tester quantitativement notre interaction. Pour permettre de l'évaluer, nous avons décidé de la comparer à des systèmes de wimp déjà existants (clavier par exemple). Dans cette continuité, il aurait été intéressant de la comparer à d’autres systèmes post-wimp (manette de xbox, etc.).

Première expérience

Nous sommes face à une scène contenant un dé vert dont les faces sont numérotées de 1 à 6 (voir photo ci-dessous). L’expérience consiste donc à positionner le dé (dans un premier temps avec le clavier) de façon à ce que la face qui se situe face à nous affiche le chiffre indiqué en noir à l’écran en haut à gauche. Le test se fait en 2 parties : une fois avec les flèches du clavier, et avec la wiimote. Pour chaque partie, il y a 20 chiffres à replacer. Nous avons effectué ces tests avec différentes valeurs de sensibilité : il faudra une accélération plus ou moins grande pour entraîner la rotation. Enfin, nous avons demandé à l'utilisateur de nous donner sa sensibilité préférée parmi les 3 testées. Voici un screenshot de la scène de test pour se faire une idée :

Voici une courbe récapitulant les résultats :

Après avoir effectué les tests, nous avons plusieurs remarques : -comme on s'y attendait, les flèches du clavier sont plus efficaces que notre implémentation. Mais un clavier implique de rester devant un ordinateur, et notre solution voulait permettre la mobilité et le travail collaboratif, et nécessitait donc un petit objet portable à la place d'un clavier. - Pour ce qui est de la sensibilité, il est assez difficile de trouver la sensibilité optimale : si la sensibilité est trop faible, il sera très long d'atteindre le point voulu (et donc l'angle de vue voulu pour notre diagramme). Au contraire, si la sensibilité est trop forte, le retour après une rotation entraînera très souvent une rotation dans l'autre sens, ce qui freine considérablement le travail. On peut noter que ce problème est également présent dans certains jeux de la wii où il faut effectuer des rotations. On peut toutefois noter que la sensibilité intermédiaire a été largement préférée par les utilisateurs.

A partir de l'analyse de ces tests, plusieurs pistes d'amélioration nous sont apparues :

- Nous pourrions définir un intervalle de temps minimal pour effectuer une rotation dans l'autre sens. Mais ce seuil serait difficile à définir, car on peut éventuellement vouloir un enchaînement des mouvements assez rapide. De plus, ce seuil serait nécessairement dépendant de l'utilisateur, car nous n'avons pas tous la même réactivité. Des tests pourraient permettre de déterminer si après un calibrage individuel du seuil, l'intervalle de temps minimal permettrait réellement d'éliminer les parasites sans empêcher certaines rotations volontaires.

- Une deuxième idée serait d'appuyer sur une touche (par exemple la touche A) au moment où l'on veut effectuer une rotation. Cette solution est légèrement moins ergonomique dans le sens où il faut en même temps effectuer une rotation et appuyer sur un bouton, mais elle évite toute confusion entre un mouvement voulu ou non.

Deuxième expérience

La deuxième expérience se fait avec la souris, il s’agit d’un “drag & drop” d’un cube positionné aléatoirement sur une croix rouge (cf photo ci-dessous). Nous mesurons de la même manière les résultats. Nous avons demandé des détails qualitatifs sur la perception du mouvement.

Au niveau de l'expérience utilisateur, on peut noter que la manipulation du curseur n'est pas très intuitive puisqu'elle prend seulement en compte la position relative (translations et rotations au cours du temps) et pas la position absolue de la manette. Il est donc très souvent nécessaire de se "replacer" car le curseur dérive. Pour avoir une position absolue, il aurait fallu utiliser une barre de capture de mouvement qui nous aurait fourni une position absolue. Néanmoins, la capture avec une barre de capture de mouvement nous limite à être en face de l'écran. Dans la mesure où notre projet visait à visualiser les infographies dans une salle de réunion par exemple, cela n'est pas optimal. Malheureusement, nous n'avons pas pu avoir accès à ce matériel. Après quelques retours qualitatifs, on remarque que l'essentiel du chemin est parcouru de manière relativement intuitive, mais l'atteinte de la cible lorsqu'on est proche est très compliquée (encore une fois l'information relative n'aide pas). On peut donc conclure que la wii avec ce matériel n'est pas faite pour un travail de précision, mais pour atteindre une position approximative, elle est assez efficace. Comme notre utilisation ne nécessite pas une position extrêmement précise, nous avons été plus permissifs dans la définition d'"atteindre" la cible dans notre expérience. Nous remarquons que les résultats des expériences sont corrélés au réglage et que pour chacun des participants, les réglages étaient différents. D'autre part, les résultats dépendent de si nous avons déjà utilisé la wii ou non, car les tâches à effectuer ici sont très différentes de celles auxquelles on a pu jouer sur la wii.

Troisième expérience

Comparer la vitesse nécessaire pour trouver une information entre un histogramme 3D et un certain nombre d'histogrammes 2D, qui forment la 3e dimension.

Des informations utiles créées pour l’histogramme 3D (représentant les précipitations mensuelles moyennes pour 3 villes d’Europe : Grenoble, Séville et Dublin).

Ce graphique a été créé à partir des données 2D ci-dessous :

Conclusion

Dans ce projet, nous avons mis l'accent sur l'analyse de notre solution Post-Wimp dans le sens où le développement de features pour notre projet (environnement, couleurs) n'était pas le but de ce cours. Il nous intéressait plus d'adopter une approche de chercheur, comme vu en cours et de tester notre solution sur un échantillon de population. Dans cette optique là, nous remarquons que notre solution obtient de bons résultats pour une solution free-space (comparaison aux outils 2D les plus performants : souris, clavier).