Chapitre 2. Le relevé numérique
3.3. Hybridation réel / virtuel
3.3.8. Les composantes applicatives d’un système de réalité augmentée
Dans les sections précédentes, nous nous sommes concentrés sur les technologies d’affichage pour la réalité augmentée, ainsi que sur les approches permettant le recalage des données virtuelles. Il est évident que ces deux éléments ne suffisent pas seuls à constituer une application de réalité augmentée. En partant des « building blocks » de Bimber et Raskar (2005), nous proposons de schématiser de façon suivante la constitution générale d’un système de réalité augmentée (Figure 82).
Figure 82 : Composants d’un système de réalité augmentée. Illustration : auteur.
- 1er niveau : Il s’agit de la couche le plus bas niveau. Elle correspond aux éléments fondamentaux du système de réalité augmentée, nécessaires à son fonctionnement. Elle comprend trois éléments principaux, tant matériels que logiciels : le dispositif d’affichage, le suivi et le recalage, ainsi que le contrôleur de rendu graphique.
- 2nd niveau : Cette couche intermédiaire est principalement implémentée sous forme logicielle. Elle comprend principalement les contenus, la façon de les présenter et gère la façon dont l’utilisateur interagit avec.
- 3e niveau : Cette couche correspond au système de réalité augmentée en lui-même, en tant qu’entité complètement tournée vers un usage spécifique – en ce qui nous concernera pour la suite de ce travail, le relevé d’art pariétal. Ce niveau fait donc intervenir le contexte d’utilisation. - 4e niveau : Dans la mesure où le système est destiné à un utilisateur final, son acceptabilité soulève un verrou humain qui dépend de ses habitudes de travail, de son expérience, de ses compétences techniques, etc. Ce niveau constitue donc la couche le plus haut niveau, et fait intervenir différentes disciplines, notamment les sciences cognitives et l’ergonomie.
Dans le cadre de notre travail, nous intervenons principalement sur les couches supérieures, le développement de dispositifs d’affichage et d’algorithmes de suivi n’étant pas de notre ressort. En particulier, nous nous concentrerons en priorité sur les couches 2 et 3 pour proposer une preuve de concept, la 4e couche n’étant possiblement sollicitée qu’à terme pour l’évaluation de nos propositions.
Nous devons donc, à la lumière de l’état de l’art, faire des choix concernant les éléments de la couche inférieure. Concernant le suivi et le recalage, le développement de solutions de réalité augmentée est considérablement facilité par la disponibilité de bibliothèques logicielles, SDK, et solutions logicielles intégrées.
106
De nombreuses méthodes de Visual SLAM sont disponibles sous forme de bibliothèques open-source, écrites en C/C++. Leur utilisation est intéressante dans les cas nécessitant un contrôle total sur tous les composants applicatifs. Cependant, elles se concentrent uniquement sur le suivi, et ne proposent pas de composants d’interfaces graphiques ou d’accès aux données. À l’opposée, les moteurs temps-réel comme Unity ou Unreal Engine, se présentent comme des solutions logicielles intégrées comprenant l’ensemble des éléments nécessaires à la création et au déploiement d’une application (système, graphisme, son, etc.). Ils sont dotés d’éditeurs 3D et permettent de compiler le même contenu sur différentes plateformes, ce qui simplifie le travail de développement. Des frameworks dédiés à la réalité augmentée (par exemple Vuforia ou Wikitude) élargissent leurs fonctionnalités en offrant des outils clé
en main spécifiques, notamment pour le suivi ou le recalage.
Les SDK de réalité augmentée, par exemple Apple ARKit, Google ARCore, ou Microsoft MRTK, offrent différents outils de suivi et de recalage, de compréhension de l’environnement (détection de plans ou estimation de la lumière), et de rendu. Ces solutions permettent de profiter de briques technologiques tout en conservant un certain contrôle sur l’ensemble de l’application. En outre, elles ciblent des terminaux spécifiques, ce qui leur permet d’optimiser les méthodes de suivi proposées en fonction des capteurs disponibles. En termes de développement, les langages et environnements de développement proposés dépendent des SDK et des terminaux auxquels ils se destinent.
Si ces trois solutions sont intéressantes dans les cas de développement d’applications natives ou entièrement conçues depuis le même cadre logiciel, leur utilisation est délicate dans notre contexte, d’une part parce qu’elles sont globalement inadaptées à des utilisations web, d’autre part parce nous cherchons à étendre les fonctionnalités d’une plateforme préexistante.
Le WebVR est une API proposée en 2016par les équipes de Mozilla-VR et Google Chrome pour prendre en charge les fonctionnalités des dispositifs de réalité virtuelle dans les navigateurs web (Casey, 2016). Elle permet ainsi d’étendre les capacités du web et de proposer des contenus VR lorsque l’utilisateur dispose d’un système d’affichage compatible. Dans la lignée de ce travail, en 2017, Mozilla propose le WebXR, une expérimentation visant à explorer les possibilités d’extension du WebVR pour y inclure les capacités des dispositifs de réalité mixte34. Repris par le Immersive Web Community Group du W3C,
ce travail a mené à une ébauche d’API publiée en février 2019 (W3C®, 2019), remplaçant le WebVR devenu obsolète. À partir des SDK existant pour chaque plateforme, elle formalise les différentes façons dont les technologies XR exposent les données issues de leurs capteurs et synthétise les concepts communs, tels que les ancres et les poses de caméra. Enrichis de cette façon unifiée de communiquer avec les dispositifs d’affichage et de l’API WebGL pour le rendu 3D, les navigateurs web peuvent donc proposer des outils permettant le développement d’applications web polyvalentes et multiplateformes. Ce fonctionnement présente différents avantages. D’une part Aïoli est une plateforme web, ces outils nous permettent donc de nous inscrire dans sa continuité sans réécrire les éléments existants ni modifier son architecture logicielle. D’autre part, le fait qu’il unifie les capacités des dispositifs permet de profiter des méthodes de suivi et de recalage propres aux différentes technologies, et de bénéficier de leurs améliorations progressives au cours des mises à jour des SDK sous-jacents, puisque les navigateurs agissent comme intermédiaire entre la 1ère couche et la 2nde (Figure 82). Cependant, il présente aussi des
limites notables. Il ne s’agit pas encore d’une API stable, et elle évolue très rapidement. Les navigateurs
Relevé numérique d’art pariétal : définition d’une approche innovante combinant propriétés géométriques, visuelles et sémantiques au sein d’un environnement de réalité mixte
107
courants ne prennent pas encore en charge ces fonctionnalités, mais des navigateurs expérimentaux sont développés35 par Mozilla et Google pour iOS et Android (Mozilla, 2017 ; Google-AR, 2017b ; 2017a).