Nous donnons d’abord des références vers des langages décrivant des techniques d’interaction dans des environnements virtuels, puis des moyens d’écrire ces langages.
Langages de description d’environnements virtuels et d’interactions. Plu-sieurs langages se sont succédés pour décrire des environnements virtuels. Nous nous attachons, en particulier, à leur capacité à décrire des interactions. L’intérêt de ces langages est de permettre des changements dans un environnement virtuel sans avoir à modifier des lignes de code source. Cela permet d’accélérer le développement d’environ-nements virtuels et d’ouvrir les portes du développement à un public moins spécialiste. L’un des premiers langages de description d’environnements virtuels, et probable-ment le plus connu, est vrml [VRM]. Ce langage repose sur un graphe de scène composé de nœuds. Chacun représente les différents éléments de la scène, qu’ils soient issus du monde réel (ex : une sphère, une lumière, etc.) ou conceptuels. Il est possible de géné-rer des événements automatiquement (ex : lorsqu’un utilisateur passe le curseur de la souris sur un objet particulier) par des « sensor nodes » qui seront « routés » vers un autre nœud. Il devient possible d’exécuter des scripts (généralement en Javascript ou en Java) et donc d’introduire des comportements complexes dans un environnement virtuel. Vrml a ensuite été remplacé par x3d [X3D] qui est écrit en xml [XML] pour être plus extensible et plus facile à manipuler par des programmes (création et édition). Contigra [DHM02] propose de mieux structurer x3d grâce à une approche de plus haut-niveau. Selon ses auteurs, x3d, comme vrml, ne permet pas l’utilisation d’outils-auteur de haut-niveau pour créer des composants réutilisables et les employer, notam-ment pour la définition explicite de composants pour des interfaces en 3D. Contigra propose de définir des composants 3D par un graphe de scène comportant plusieurs graphes de scène fils. Un graphe de scène peut définir la géométrie d’un composant 3D, les sons qu’il peut produire, son comportement, etc. Par ailleurs, un graphe peut être réutilisé par plusieurs composants différents.
Collada [COL] est un format pivot basé sur xml pour la création de contenus 3D. Son but n’est donc pas d’être distribué dans des applications finales aux utilisateurs27, comme un jeu vidéo par exemple. Ce format intervient lorsqu’il faut échanger des données entre différents logiciels participant à la chaîne de création de contenus. Par exemple, un logiciel d’ajout d’effets visuels est appliqué aux données produites par un logiciel de modélisation 3D. Sa large utilisation dans l’industrie du jeu vidéo est probablement due à son concepteur, Sony, qui a associé ce format aux développements logiciels sur ses consoles de jeu.
27
Pour des raisons de performances, les développeurs de logiciels privilégient souvent des formats de fichiers ad-hoc. Un tel choix est fréquent pour des jeux vidéos où il faut lire le plus rapidement possible un fichier pour faire apparaître un monde 3D aux joueurs.
Avec les plates-formes basées sur un flux de données, un ensemble de composants connectés (ex : des filtres ou des nœuds) est employé. InTml [FGH02] décrit les liens entre les nœuds, ainsi que diverses propriétés des nœuds (ex : nom, description textuelle, code associé, etc.). Il repose sur une extension du format x3d.
Environnements de programmation. Les premières plates-formes de réalité vir-tuelle était construites d’une façon monolithique et figée : l’application réalisée était en grande partie écrite pour le cas spécifique d’une simulation virtuelle. Puis, la descrip-tion d’environnements virtuels s’est déplacée vers des fichiers de configuradescrip-tion : d’abord pour décrire les périphériques matériels employés, puis pour décrire d’une façon de plus en plus abstraite les objets peuplant l’environnement virtuel ainsi que leurs relations.
Actuellement, un consensus semble se dégager autour d’une programmation majo-ritairement effectuée par des composants graphiques en 2D. L’utilisateur-développeur relie les entrées et les sorties des boîtes 2D par des lignes ou des flèches et programme ainsi grâce à une interface graphique. Une boîte 2D représente, généralement, des scripts ou du code à exécuter. Dragicevic et Fekete [DF04] ont proposé leur usage dans le contexte d’applications en 2D qui peuvent utiliser des périphériques autres que le cla-vier et la souris. Puis, Unit [OF04] a également exploité cette idée mais en proposant une interface aux éléments en 3D (cf. figure 1.21) et à destination de la construction d’environnements virtuels. Morgan [BLO+05] utilise une interface en 2D pour créer des interfaces pour la réalité augmentée. Comme autre utilisateur de ce type d’inter-face (cf. figure 1.22), citons enfin Virtools [Vir] qui est un logiciel commercial pour des environnements virtuels 3D.
1.5.1.3 Bilan intermédiaire
L’objectif d’abstraire le matériel a entraîné un travail important qui se divise en deux approches. Dans un premier cas, l’abstraction logicielle se réalise directement dans les plates-formes de réalité virtuelle. Dans un second cas, l’abstraction logicielle est faite en dehors des plates-formes de réalité virtuelle, c’est le cas de vrpn [VRP]. En elle-même, l’abstraction repose souvent sur une identification des fonctions qu’un périphérique met à disposition (ex : la lecture de positions) et sur la construction d’une hiérarchie orientée objets.
Pour décrire des environnements virtuels, vrml [VRM] puis x3d [X3D] ont été employés. Tous deux contiennent peu de moyens pour abstraire le matériel et des techniques d’interaction sous formes réutilisables. Ces manques ont été la source du développement de contigra [DHM02] et de InTML [FGH02]. Par ailleurs, le format collada est un format pivot répandu dans l’industrie du jeu vidéo pour la création de contenus.
Enfin, nous avons présenté les principes de la programmation visuelle par des bran-chements d’entrées et de sorties pour connecter des objets. Les objets, ou « boîtes » 2D dans ce cas, renferment des composants logiciels décrivant des comportements pour des outils d’interaction ou des objets interactifs. Un développeur programme en venant piocher parmi les objets existants ou en en créant des nouveaux.
Les fondements techniques 43
Fig. 1.21 – Ce graphe de flux de données dans Unit [OF04] spécifie le contrôle de six degrés de liberté par l’usage de deux souris. Les molettes des deux souris fournissent le troisième degré de liberté de chacune.
Fig. 1.22 – Illustration de l’interface de Virtools (version 3) [Vir]. Le développeur vient « piocher » des fonctionnalités grâce aux « building blocks » (cadre en haut à droite). Ces blocs peuvent être connectés entre eux, comme illustré par le cadre inférieur de la fenêtre.
Les fondements techniques 45
1.5.2 Architectures réseau
Les architectures logicielles employées pour la gestion du réseau dans les environne-ments virtuels peuvent se regrouper sous trois grandes catégories : centralisée, répliquée et hybride. Nous proposons dans cette section d’analyser les qualités et les défauts de chacune de ces catégories. Pour plus d’informations, le lecteur pourra se référer à l’état de l’art présenté en deux parties dans [DWM06a] et [DWM06b], ou encore à celui contenu dans [FDGA10].
Serveur Client Client Client Client Client Client Client / Serveur Client / Serveur Client / Serveur Client / Serveur Client / Serveur Client / Serveur (a) (b)
Fig. 1.23 – (a) Illustration d’un réseau centralisé où, de fait, une base de données dé-crivant l’environnement virtuel est partagée avec l’ensemble des utilisateurs. (b) Illus-tration d’un réseau distribué. Ces deux illusIllus-trations sont basées sur [GlKP94].