Nom et coordonnées

Titre

Le suivi du visage pour améliorer l’accessibilité et l’interaction dans le métavers avec Satellite

Brève description du travail réalisé

Pendant le Google Summer of Code, j’ai étendu Satellite, le fork de Mozilla Hubs réalisé par la SAT, afin qu’il puisse utiliser Google MediaPipe comme « contrôleur » de rechange : les personnes peuvent ainsi se servir de leur visage, et notamment de l’ouverture et de la fermeture des yeux et de la bouche, pour déclencher des actions dans l’environnement 3D. Il m’a fallu plonger dans le code de Hubs et apprendre à bien utiliser MediaPipe, deux choses avec lesquelles je n’avais aucune expérience préalable.

J’ai aussi développé, à l’intérieur de Hubs, un système simple de réassignation des commandes propre au contrôleur MediaPipe, pour qu’il soit facile de rattacher un geste du visage à n’importe quelle action de Hubs — une possibilité absente du code de Hubs. C’est la partie la plus « difficile » du projet, et j’y reviens plus en détail dans la section « Ce qu’il reste à faire ».

D’autres travaux, sans lien direct avec l’intégration de Hubs et de MediaPipe mais tout de même importants pour notre objectif d’accessibilité, ont également été menés. Il s’agit notamment d’une catégorie Satellite dédiée dans les préférences de Hubs, qui permet de réassigner les actions associées aux gestes du visage (comme mentionné plus haut), d’ajuster les valeurs de sensibilité et d’activer ou de désactiver l’affichage du panneau de webcam MediaPipe et des outils de débogage associés (par exemple l’utilisation d’émojis pour montrer la position des yeux de la personne et indiquer s’ils sont ouverts ou fermés).

Le code qui a été fusionné

L’essentiel du travail lié à mon projet GSoC se trouve dans la deuxième demande de fusion ci-dessous :

Le code qui n’a pas été fusionné

En plus du code que j’ai écrit dans mon fork de Satellite et qui a été fusionné, j’ai produit d’autre code. D’abord du code exploratoire sur MediaPipe, que voici :

J’ai également écrit un Dockerfile, publié sur mon compte GitHub personnel, pour répondre au ticket #5471 du dépôt Mozilla Hubs, afin que les autres personnes touchées par le même bogue puissent s’en sortir. Le dépôt se trouve ici :

Ce qu’il reste à faire

Même si je considère le projet comme une belle réussite qui, je l’espère, servira de fondation à d’autres développeurs (ou à de futurs participants au GSoC !), quelques points essentiels devraient être réglés avant que ce projet devienne utile au grand public comme outil d’accessibilité ou comme mode d’entrée alternatif dans Hubs :

Améliorer la précision et la constance du suivi du visage

FaceMesh de MediaPipe fournit au développeur un maillage de points de repère du visage, à utiliser à sa guise. L’approche que j’ai retenue pour « traduire » ce maillage en actions dans Hubs est simple et facile à comprendre pour de nouveaux développeurs, mais elle manque de la précision et de la fiabilité nécessaires pour être utile aux utilisateurs finaux. Elle est en particulier assez sujette aux erreurs lorsque l’orientation de la webcam n’est pas parfaite : par exemple, quand la personne tourne le visage pour déplacer la caméra dans Hubs, les yeux risquent d’être masqués, ce qui peut déclencher par accident des actions liées aux yeux et devenir frustrant. Une implémentation plus robuste de cette logique, située dans mediapipe-controller.js, est nécessaire.

Améliorer ou concevoir un système de réassignation dynamique des commandes dans Hubs

Hubs n’offre aucune API sur laquelle les développeurs de contrôleurs personnalisés pourraient facilement se brancher. Comme le projet portait sur des améliorations d’accessibilité, je voulais permettre de réassigner des gestes du visage (comme ouvrir et fermer la bouche) à d’autres actions dans l’environnement 3D. J’ai donc dû bricoler mon propre sous-système de réassignation des commandes pour y arriver.

Malheureusement, cela a entraîné plusieurs bogues étranges : par exemple, Mozilla Hubs (ou AFRAME ?) fige le navigateur si deux gestes du visage sont assignés ou réassignés à la même action. Il s’agit évidemment d’une limitation sévère, qui montre bien la nécessité de refondre le système de commandes de Mozilla Hubs pour prendre en charge cela d’emblée — un chantier qui exige une compréhension du code de Hubs plus approfondie que la mienne.

Améliorations diverses du confort d’utilisation

Il y a plusieurs améliorations de confort d’utilisation qui me semblent importantes, mais que je n’ai pas eu le temps de réaliser : elles constitueraient des tâches faciles pour initier un nouveau développeur au projet. Par exemple :

  • Activer ou désactiver le contrôleur MediaPipe au moyen d’un paramètre d’URL HTML, comme dans le travail initial de @paperManu sur l’intégration de LivePose à Satellite/Hubs
  • Ajouter une option dans les préférences pour modifier la vitesse de déplacement de la caméra dans Hubs avec le contrôleur MediaPipe (elle est actuellement fixe et non modifiable)
  • Prendre en charge d’autres actions, comme celles associées au Pen de Hubs
  • Permettre de redimensionner le panneau de débogage MediaPipe (sa résolution est actuellement fixe)