Rapport de stage Réalité virtuelle et objets...

Rapport de stage

Réalité virtuelle et objets 4D

Olivier THOMAS

Sous la direction de Sylvain Brandel

Laboratoire LSIIT, équipe IGG

Université Louis Pasteur, Strasbourg

Master 2 Recherche IFA

ULP

Session de Juin 2006

3

Je souhaite remercier Ludovic Sternberger et Sylvain Brandel pour leur patience et leur disponibilité. Je remercie également tous les membres de l’équipe IGG qui m’ont apporté leur soutien.

5

Table des matières

Introduction.................................................................................................................................... 7

1. Contexte...................................................................................................................................... 9

1.1 Réalité virtuelle..................................................................................................................... 9 Introduction..........................................................................................................................................................9 1.1.1 Solutions matérielles .................................................................................................................................11 1.1.2 Solutions logicielles ..................................................................................................................................21

1.2 Images de synthèse et animation ............................................................................................... 31

2. VRLib........................................................................................................................................ 33

2.1 Contexte ..................................................................................................................................... 33 2.1.1 Structure et fonctionnement ......................................................................................................................33 2.1.2 Motivations ...............................................................................................................................................34 2.1.3 Abstraction de l'architecture parallèle .......................................................................................................35 2.1.4 Gestion de la hiérarchie des composants...................................................................................................35

2.2 Apports personnels à la VRLib................................................................................................. 36 2.2.1 Images, textures, et polices de caractères..................................................................................................37 2.2.2 Séparation géométrie / comportement.......................................................................................................40

3. VRSTIGMA.............................................................................................................................. 45

3.1 Modélisation d’objets 4D pour l’animation .............................................................................. 45 3.1.1 Modélisation..............................................................................................................................................45 3.1.2 Les G-cartes ..............................................................................................................................................45 3.1.3 Animation par objets 4D ...........................................................................................................................49 3.1.4 STIGMA ...................................................................................................................................................51

3.2 VRSTIGMA............................................................................................................................... 52 3.2.1 Matériel .....................................................................................................................................................52 3.2.2 Logiciel .....................................................................................................................................................53 3.2.3 Interface de VRSTIGMA..........................................................................................................................53

Conclusion et perspectives ........................................................................................................... 61

Conclusion ....................................................................................................................................... 61

Perspectives ..................................................................................................................................... 61

Pistes ................................................................................................................................................ 62

Références .................................................................................................................................... 64

7

Introduction

Le sujet de ce stage de Master 2 Recherche porte sur la réalité virtuelle et les objets 4D. Il

comporte implicitement trois parties : d’une part le portage d’un modeleur d’objets 4D

(STIGMA) dans un environnement réalité virtuelle (VRSTIGMA), d’autre part l’évaluation des

apports de la réalité virtuelle à la modélisation d’objets 4D et enfin les apports de la modélisation

4D à la réalité virtuelle.

Nous étudierons tout d’abord le contexte lié à la problématique de la réalité virtuelle,

ainsi que les solutions traditionnelles dédiées à l’animation dans le domaine des images de

synthèse.

Puis je décrirais VRLib, une librairie dédiée à la conception d’interfaces en 3D, utilisées

dans les environnements immersifs. Cette librairie étant utilisée par VRSTIGMA, une partie de

mon travail s’est concentré sur la VRLib. Je donnerais donc des détails sur mes apports à cette

librairie.

Enfin, dans la dernière partie, j’introduirais les notions d’animation par objets 4D et de

modélisation topologique, sur lesquelles se base STIGMA, avant de finir par exposer

VRSTIGMA.

9

1. Contexte Avant de parler des applications du stage proprement dites, j’aimerais introduire dans

cette partie un certain nombre de notions. Je commencerai par évoquer la réalité virtuelle et ses

problématiques, tant matérielles que logicielles. Puis, je décrirai les solutions traditionnelles

dédiées à l’animation en images de synthèse.

1.1 Réalité virtuelle

“La réalité virtuelle est un domaine scientifique et technique exploitant l’informatique et des interfaces comportementales en vue de simuler dans un monde virtuel le comportement d’entités 3D, qui sont en interaction en temps réel entre elles et avec un ou des utilisateurs en immersion pseudo-naturelle par l’intermédiaire de canaux sensori-moteurs.” (tiré du Traité de la

Réalité Virtuelle [FAT03])

Introduction

Le but de la réalité virtuelle est d’immerger dans un environnement de façon

convaincante l'utilisateur d'un système de réalité virtuelle. Cette expérience convaincante est en

fait la combinaison de deux types d'immersions : l'immersion cognitive et l'immersion

sensorimotrice.

L'immersion cognitive caractérise la conviction intellectuelle d’être présent dans

l’environnement. Cette immersion n'est pas spécifique à la réalité virtuelle, dans la mesure où

cette elle est accessible par un effort d'imagination plus ou moins soutenu de l'utilisateur. C'est

l'immersion que nous ressentons lors de la lecture d'un bon roman, où par un effort

d'imagination, on visualise les personnages et leurs actions. On peut également citer les jeux

vidéos comme exemple d'immersion cognitive : la sensation d'immersion est apportée par un

effort de concentration de l'utilisateur. Ce dernier est focalisé sur la scène et n'a pas le temps de

systématiquement « sortir » de l'univers pour réfléchir à ses prochaines actions : l'immersion

cognitive repose dans ce cas sur l'action et/ou la réflexion. On remarquera que la qualité visuelle

du jeu n'a finalement que peu d'influence sur l'immersion cognitive, mettant sur un pied d'égalité

du point de vue de l'immersion cognitive Tetris ou Pong et les jeux les plus récents, beaucoup

plus évolué graphiquement (réaliste aurait-on envie de dire...) : le plus important pour renforcer

l'immersion cognitive est une interaction bien pensée avec le monde1.

L'immersion sensorimotrice est la sensation physique qu'a l'utilisateur d'être présent dans

l’environnement. Cette immersion repose sur notre capacité à tromper nos sens, et d'essayer de

rendre la scène la plus réelle et cohérente possible. Le cinéma est un exemple classique

d'immersion sensorimotrice (limitée) : l'écran géant et la salle noire occupent alors autant que

possible le champ de vision, tandis que le système sonore reproduit aussi fidèlement que possible

la spatialisation du son. Mais contrairement au cinéma, la réalité virtuelle fait reposer

l'immersion sensorimotrice essentiellement sur deux points : la vision stéréoscopique de la scène

1 Nous verrons plus tard que les problématiques de la réalité virtuelle et des jeux vidéos s’entrecroisent quelque fois, de part leur volonté de plonger un utilisateur dans un monde virtuel.

10

et la connaissance d'un certain nombre d'informations spatiales sur l'utilisateur.

La vision stéréoscopique nous permet d’évaluer la distance d’un objet grâce à un travail

d’analyse du cerveau lors de la fusion des images légèrement différentes provenant de nos deux

yeux. Il s’agit donc de trouver des moyens pour diriger ces images vers chaque œil

individuellement. La vue étant le sens le plus utilisé par l’être humain pour examiner son

environnement, c’est en général la vision stéréoscopique à laquelle pensent les gens quand on

parle de réalité virtuelle. C’est normal dans la mesure où c’est la différence la plus fondamentale

avec les écrans cathodiques domestiques. Mais la problématique de la réalité virtuelle ne se

résume pas qu’à une simple questions d’affichage.

La connaissance d’un certain nombres d’informations spatiales sur l’utilisateur et sur

des outils d’interaction adaptés à la réalité virtuelle (comme la souris et le clavier sont des outils

d’interaction adapté aux applications en environnement classique, type PC de bureau) améliore

aussi beaucoup les deux types d’immersion. Néanmoins, ces outils se doivent d'être inspirés du

monde réel, sinon ils n'améliorent que l'immersion cognitive. On notera l’apport à l’immersion

en général de conjuguer ces connaissances spatiales sur l’utilisateur avec la visualisation

stéréoscopique de la scène. On peut ainsi mettre à jour la représentation graphique de la scène en

fonction du point de vue de l’utilisateur : l'utilisateur de déplace, la scène bouge alors de façon

cohérente.

La réalité virtuelle se définit, non seulement par son rendu stéréoscopique de la scène,

mais également par un ensemble de mécanismes permettant d'agir sur la scène comme on le

ferait dans le monde réel, comme l’illustre la figure 1.1. On étudiera tout d'abord les solutions

matérielles pour la visualisation stéréoscopique et les outils d’interaction avec le monde virtuel,

pour ensuite se pencher sur le problème du confort en réalité virtuelle. Puis les solutions

logicielles à la problématique de la vision stéréoscopique et l’interaction en environnement

immersif seront évoquées dans la partie suivante. On notera que ce découplage des solutions

matérielles et logicielles permet une meilleure vision de la problématique de la réalité virtuelle,

même s’il peut sembler arbitraire, dans la mesure où certaines solutions logicielles sont

spécifiques à un matériel donné.

Moyens logiciels

Moyens matériels

Faire croire à l’existence

d’un monde en image de

synthèses

Permettre d’agir sur

l’environnement+

Moyens logiciels

Moyens matériels



synthèses


l’environnement

Moyens logiciels

Moyens matériels



synthèses


l’environnement+

Fig. 1.1 : Réalité virtuelle = immersion dans un environnement + interaction avec cet

environnement. Figure tirée du cours de Dominique Bechmann pour le M2R-IFA à l’ULP.

11

1.1.1 Solutions matérielles

La caractéristique qui vient immédiatement à l'esprit du grand public quand on parle de

réalité virtuelle est l'affichage stéréoscopique. Les premières expériences concluantes ont été

faites par Sir Charles Wheatstone en 1838 avec le stéréoscope, qui utilisait deux clichés et un

système de miroirs afin de diriger chaque cliché à l'œil auquel il était destiné. De nombreuses

variations sur ce principe ont vu le jour depuis jusqu'à l'apparition de machines suffisamment

puissantes pour pouvoir rendre de scènes 3D en temps réel et l'adaptation des oscilloscopes en

écrans comme nous les connaissons aujourd'hui (apparition du VectorScope). Ivan Sutherland

propose en 1966 l'utilisation d'un casque de réalité virtuelle, caractérisé par la proximité des

systèmes d'affichages avec les yeux, afin de « forcer » l'immersion : on ne voit rien d'autre que la

scène.

Mais la caractérisation de la réalité virtuelle ne se limite pas à la vision stéréoscopique :

elle se définit également par les outils d'interaction particuliers qui lui sont associés. En 1970,

Daniel Vickers rajoute au casque de Sutherland le suivi du mouvement et la stéréoscopie,

donnant naissance à la réalité virtuelle telle que nous la connaissons.

1.1.1.1 Affichage

De nombreuses études [MRWJ03] [LDP+02] portent sur l'influence de l'affichage sur

l'immersion sensorimotrice. On peut distinguer dans un premier temps deux types d’affichage

utilisés dans le cadre de la réalité virtuelle. On a d’abord les écrans qui émettent l’image, comme

les écrans cathodiques et LCD. On a ensuite les écrans sur lesquels on projette l’image : on peut

citer par exemple les écrans de cinéma, les vidéo projecteurs, les affichages « tête haute » des

avions de chasse ou de certaines voitures récentes (comme la Citroën C6). Mais dans les deux

cas, les systèmes de réalité virtuelle qui utilisent des écrans pour l’affichage sont sensibles à un

premier critère de qualité lié au matériel : la fréquence d’affichage. Une deuxième contrainte

pèse sur tous les systèmes qui utilisent des écrans : c’est la fréquence de rafraîchissement. Enfin,

nous verrons comment l’espace alloué à la visualisation de la scène améliore aussi l’immersion

sensorimotrice.

La fréquence d'affichage est le nombre d'images à la seconde que le système est capable

de produire. Cette fréquence correspond au temps nécessaire pour calculer une image de la scène

virtuelle, et dépend des algorithmes utilisés pour rendre la scène et du matériel utilisé. Que ce

soit en réalité virtuelle ou en environnement 2D classique, une fréquence d'affichage faible nuit

aux deux types d'immersions : l’affichage est saccadé et le confort d'utilisation s'en ressent, allant

même jusqu'à briser la perception du mouvement. La fréquence d'affichage minimale

généralement souhaitée est celle utilisée au cinéma : 24 images par secondes. Cette valeur a été

choisie entre autres parce qu’elle était supérieure à la persistance rétinienne. En effet, l'œil

échantillonne le monde environnant tous les 1/16 de secondes environ. Les nerfs transmettent ce

signal pendant ce 1/16 de seconde, et ce même après disparition d'un objet : c'est l'image

eidétique.

Malgré ces limitations de l'œil humain, une fréquence d'affichage élevée (> 50

images/secondes) améliore grandement la qualité de la perception de la scène : de nombreux

parcs de loisirs possèdent des attractions types « cinéma à grand spectacle » où les images

défilent encore plus vite (~100 images/secondes), rendant la scène presque réelle (en terme

d'immersion sensorimotrice) sans utiliser de vision stéréoscopique. Il est donc clair que dans le

12

cas d'un affichage stéréoscopique, il est intéressant de profiter de cette fréquence d'affichage très

élevée pour encore améliorer l'immersion. Il faut néanmoins se rendre compte que même si on a

une fréquence d'affichage élevée, on sera limité par les capacités du matériel (l'écran) en terme

de taux de rafraîchissement.

Le taux de rafraîchissement d'un écran est le nombre de mises à jour de la zone

d'affichage maximales que le canon à électrons peut faire en une seconde : cette valeur est

exprimée naturellement en Hertz, et est typiquement de 85 Hz sur les écrans cathodiques actuels.

Pour les mêmes raisons physiologiques que celles évoquées plus haut, il est important d'avoir

une fréquence de rafraîchissement aussi rapide que possible : l'image semble plus stable, ne

clignote pas et la fatigue oculaire est grandement réduite. Dans un cadre réalité virtuelle, cette

donnée est d'autant plus importante que, dans certains cas, la vision stéréoscopique implique la

génération de deux images par un même écran : on va diviser par deux la fréquence de

rafraîchissement effective.

La dernière contrainte matérielle liée à l'affichage est la taille du champ de vision. Dans

un système d'affichage classique, la gain en espace de vision (la longueur de la diagonale de

l'écran) est déjà très appréciable en terme de confort de travail. Mais dans un environnement

virtuel, ce n'est pas juste un problème de confort : la taille de l'espace de vision influence

directement l'immersion sensorimotrice car on visualise bien un espace (3 dimensions) et non pas

une fenêtre sur un espace comme avec un écran classique. Si cet espace est réduit, les objets

visualisés en réalité virtuelle risquent d’autant plus d'être coupés car ils sortent de la zone

d'affichage : autant cette limitation est par la force des choses acceptée avec un écran

domestique, autant elle nuit énormément à l'immersion sensorimotrice car cette coupure n'a rien

de naturel.

Comme évoqué plus haut, la réalité virtuelle se démarque très généralement des

environnement de travail « classique », de type PC de bureau par un affichage stéréoscopique,

afin d'améliorer la perception de la profondeur des objets dans la scène. En effet, notre cerveau

tire de la différence entre les images perçues par chacun des yeux des informations de distance. Il

faut néanmoins noter que le système de vision humain n'est pas très efficace dans cette tâche

d'évaluation des profondeurs à l'aide de la seule vision stéréoscopique (par rapport à certains

prédateurs, comme les loups). Il s'appuie aussi beaucoup sur des informations apportées par des

points de repères visuels et la perception du reste de l'espace. Ceci s'explique par le fait que

contrairement à sens anciens prédateurs, l'homme n'a pas besoin d'évaluer au centimètre près

l'éloignement de sa proie pour survivre : il compte plus sur son organe de traitement des images

(le cerveau). Malgré ces limitations, la vision stéréoscopique améliore grandement le réalisme de

la scène et arrive parfaitement à tromper la vue et le cerveau.

Je distinguerai deux types de solutions d’affichage : celles que l’utilisateur porte sur soi,

et celles qu’il pose à un endroit. Cette division est plus ou moins arbitraire, dans la mesure où

elle est mise en défaut par l’exemple d’un ordinateur portable muni d’un affichage

stéréoscopique : ce portable est trop gros pour être vraiment classé dans la catégorie des

systèmes d’affichage portables telle que je l’entends, et pourtant l’utilisateur peut le transporter !

J’organiserai donc dans les parties suivantes en désignant par le terme casque de réalité

virtuelle tous les équipements facilement transportables, et par le terme écrans géants les autres

solutions. En effet, pour réellement parler d’immersion, il faut pouvoir maximiser le champ de

13

vision de l’utilisateur sur la scène, ce qui explique que je ne parlerais pas des écrans habituels (17

ou 21 pouces), car bien qu’il permettent de faire de la réalité virtuelle au sens strict du terme

(vision stéréoscopique + outils d’interaction suivis), il faut bien avouer que leurs faibles surfaces

d’affichage nuit beaucoup à l’immersion.

Casques

L'idée des casques de réalité virtuelle est de placer deux écrans juste devant les yeux. La

séparation œil gauche / œil droit se fait alors naturellement, puisque l'œil gauche ne voit pas

l'écran droit. De plus, le champ visuel est très important, puisqu'il couvre tout l'œil : on ne voit

que les écrans, un peu comme les lunettes correctrices couvrent l'intégralité du champ de vision.

On peut rendre les écrans opaques, auquel cas on parle de réalité totalement virtuelle, ou

transparents, afin de préserver la perception du monde environnant tout en superposant des

informations ou une scène : on parle alors de réalité augmentée. La figure 1.2 illustre cette

combinaison du monde réel et d’informations générées par un système informatique. De

nombreuses expériences ont déjà été faites, notamment au Japon où de tels systèmes sont testés

par les secouristes qui interviennent sur le terrain (affichage des données médicales du patient),

ou encore aux Etats-Unis pour assister les ingénieurs ou les mécaniciens lors de réparations, en

affichant par exemple le diagramme électrique d'un système. La réalité augmentée possède

encore de nombreux domaines d'applications, de la chirurgie aux applications militaires (casque

de « fantassin du futur » avec une vue superposée du champ de bataille ou de l’état de ses

blessures) en passant par l’automobile (affichage de la vitesse sur le pare-brise, par exemple).

Fig. 1.2 : Une illustration de la réalité augmentée : les vases sont des objets réels, mais des

informations générées par une machine viennent compléter ces objets.

On notera que la réalité augmentée n’est pas réservée aux casques de réalité virtuelle,

14

puisqu’un certain nombre d’applications de la réalité augmentée par avec des systèmes

d’affichages par projection existent. Un des clients traditionnels de ces applications de la réalité

augmentée est l’armée de l’air : ce sont les affichages « têtes hautes » évoqués plus haut. Ils

projettent directement sur une zone généralement transparente (ou directement sur la partie vitrée

du cockpit, afin de ne pas gêner la vision panoramique du pilote) des informations dont le pilote

a souvent besoin : on lui évite ainsi de devoir baisser les yeux vers ses instruments. Ces

techniques utilisent généralement des lasers pour projeter l’image, à la différence des vidéos

projecteurs, qui utilisent de la lumière naturelle (opposée au laser qui est une lumière artificielle,

monochromatique et cohérente, et donc se dispersant moins dans l’air).

Les casques de réalité virtuelle possèdent un certain nombre de défauts, plus ou moins

incontournables. Tout d'abord, les écrans étaient souvent de qualité médiocre, offrant une vision

de la scène « pixellisée » (on distingue les constituants élémentaires de l'écran). Ce défaut

disparaît avec l'amélioration des techniques et la possibilité d'intégrer des écrans avec une forte

densité de pixels à un coût raisonnable. Ensuite, il est nécessaire de fournir une correction

visuelle (lentilles), souvent intégrée aux lunettes, car l’œil humain ne peut pas faire de mise au

point aussi proche : on estime généralement la distance minimale de vision distincte à 25 cm

devant l'œil.

On notera que seul les casques permettent de moduler l’immersion. Il est possible de les

utiliser aussi bien dans un cadre réalité augmentée, auquel cas l’utilisateur voit le monde autour

de lui augmenté d’informations affichées par/sur les lunettes, que pour faire de la réalité

totalement virtuelle (où l’utilisateur et ne voit que le monde virtuel, mais plus le monde réel) en

opacifiant la surface d’affichage. Mais certaines personnes sont très sensibles à la perte

d'informations visuelles typique de la réalité totalement virtuelle, ce qui engendre chez elles des

troubles de l'équilibre, et donc le mal du virtuel (qui dans le cas des casques persistent même

avec des utilisateurs « habitués »). Ce problème du mal du virtuel est exposé plus en détail dans

la section 1.1.1.3 intitulée Réalité virtuelle et confort.

(a)

(b)

Fig. 1.3 : Un casque de réalité totalement virtuelle (a) et un casque dédié à la réalité augmentée comportant une surface d’affichage transparente (b)

15

Ecrans géants

L’intérêt de la projection sur écrans géants est d'utiliser une surface d'affichage aussi

grande que possible, sans pour autant entièrement priver l'utilisateur de points de repères réels et

ainsi limiter le mal du virtuel (si les autres critères de qualité en terme de fréquences d’affichage

et de rafraîchissement sont respectés). Le principe consiste à répartir la fréquence de

rafraîchissement de (ou des) écran(s) : l'écran affiche une image destinée à l'œil gauche et la

paire de lunettes portées par l'utilisateur obture un cache placé devant l'œil droit. A l'image

suivante, l'image est destinée à l'œil droit et on aveugle l'œil gauche. On continue l'alternance œil

gauche / œil droit pour obtenir la vision stéréoscopique. De plus, l'utilisateur portant de fait une

paire de lunettes obturatrices, il est facile de la munir d'un système de suivi permettant de

connaître la position de l'utilisateur et la direction de son regard, et ainsi améliorer l'immersion

sensorimotrice. On notera tout de même que le suivi du mouvement n’est pas réservé aux

systèmes d’affichages stéréoscopiques.

Les systèmes par projection sur écran(s) géant(s) se caractérisent par la disposition de ces

écrans. Pour maximiser le champ visuel, on peut les disposer le long d'un mur par exemple dans

le cas des murs immersifs (cf. figure 1.5), les organiser en cube (CAVE, figure 1.4) ou placer

deux écrans à la manière d'une table de flipper (voir la figure 1.6).

Fig. 1.4 : Solution immersive de type CAVE : la surface d’affichage entoure plus ou moins

complètement l’utilisateur.

16

Fig. 1.5 : Une solution semi immersive modulable : les murs immersifs. Il est possible d’adapter

facilement la disposition des surfaces d’affichage.

Fig. 1.6 : Un workbench (plan de travail) à deux écrans.

Les avantages des écrans géants sont liés de leur incapacité à faire de la réalité totalement

virtuelle : l’utilisateur voit aussi bien l’écran que le reste du monde réel autour de lui. On désigne

d’ailleurs souvent les solutions de type écrans géants (CAVE, murs immersif, workbench)

comme des environnements semi immersifs, en opposition aux casques de réalité totalement

virtuelle, que l’on considère généralement comme des environnement immersifs (les casques de

réalité augmentée étant à limite de ces deux désignations). Les solutions semi immersives ont

l’avantage de réduire les symptômes du mal du virtuel, excepté les problèmes de fatigue

17

oculaires liés à la fréquence de rafraîchissement de l’écran et d’obturation des lunettes.

Par rapport aux casques de réalité virtuelle, les écrans possèdent un défaut incontournable

du fait de leur éloignement aux yeux. La vision stéréoscopique fonctionne parfaitement (tant que

l’on reste conscient des limitations de l’œil humain), mais le problème survient quand

l’utilisateur cherche à « toucher » la scène, pour une raison ou pour une autre. Pendant qu’il

attrape un objet proche, l’utilisateur évaluera sa distance à cet objet comme plus proche de lui

que sa main. Il devrait donc voir au premier plan l’objet, et au second plan, plus loin, sa main.

Mais, comme il masque l’image envoyée par l’écran, il masquera également l’image de cet objet

avec sa main, alors que celui devrait être visible. C’est le problème de l’occlusion de la scène, et

ce problème ne peut être résolu qu’avec les casques dédiées à la réalité virtuelle, qui affichent les

images sur une surface toujours plus proches des nos yeux que n’importe quel objet de la scène,

et permettent une résolution au choix du problème de l’occlusion (en opacifiant plus ou moins la

surface d’affichage du casque, définissant un espèce de casque capable de faire de la réalité

augmentée aussi bien que de la réalité totalement virtuelle).

Fig. 1.7 : Le problème de l’occlusion du à la main dans les solutions semi immersives. La boule

est l’objet perçu par l’utilisateur, l’ellipse est l’image de cette boule affichée par l’écran.

1.1.1.2 Outils d'interaction

En plus de l'immersion sensorimotrice fournie par la vision stéréoscopique, un système

de réalité virtuel se caractérise également par ses solutions pour permettre à l'utilisateur

d'interagir sur le monde virtuel. On peut citer notamment le suivi des mouvements de l'utilisateur

et les périphériques d'interaction, que Gerber [Ger04] propose de classer en deux catégories : les

périphériques tenus et les périphériques portés.

a) Le suivi du mouvement

Le suivi des mouvements de l'utilisateur est, avec la vision stéréoscopique, le facteur clé

de l'immersion sensorimotrice. Il est assuré par différents moyens, le but étant de connaître aussi

18

précisément que possible la position et l'orientation de certaines parties du corps de l'utilisateur,

notamment la tête. Cette problématique rejoint celle de la capture de mouvements utilisée par

l'industrie du cinéma et du jeu vidéo. En plus des capteurs à inerties qui évaluent les déplacement

à l'aide de gyroscopes, on peut citer trois types de techniques : magnétiques, par ultrasons et

optiques.

L'utilisation de champs magnétiques pour déduire la position et l'orientation d'un

périphérique est la plus ancienne, et la moins onéreuse. Elle repose sur des mécanismes

relativement simples et peut être confiée à un matériel dédié. La distance par rapport à un point

de référence (le générateur de champ magnétique) est évaluée grâce à la perte de puissance du

champ en fonction de l'inverse du carré de la distance. Par rapport aux autres méthodes, celle ci

présente l'intérêt de ne pas être sensible à la présence de l’utilisateur entre le capteur et les

émetteurs, car les ondes électromagnétiques traversent le corps humain. Néanmoins cette

méthode a les inconvénients d'être peu précise et très sensible à un environnement chargé en

objets métalliques et champs magnétiques parasites, comme ceux émis par un écran cathodique.

Pour contourner ces problèmes, des solutions reposant sur les ultrasons ont été proposées.

Elles reposent soit sur l'évaluation du « temps de vol » d'un signal ultrasonore et une

triangulation, à la manière des sonars, soit une évaluation du décalage de phases entre le

transmetteur et le receveur. Cette technique présente l'avantage d'être un peu plus précise que les

capteurs magnétiques et est de plus insensible aux perturbations magnétiques. Elle a

l'inconvénient d'être sensible aux bruits (nous ne percevons pas les ultrasons, mais la plupart des

sons de la vie courante en comportent), ce qui oblige à mettre en place un filtrage sonore. De

plus, si un objet est placé entre le récepteur et le transmetteur, le signal est perdu : la méthode est

sensible au masquage des capteurs

Enfin, la dernière méthode de suivi de mouvement évoquée ici est le suivi optique. Un

certain nombre (aussi élevé que possible) de caméras filment la zone où se tient l'utilisateur2. Des

marqueurs visuels (des espèces de « sapins de noël » miniatures en plastique) d'une forme

permettant aux caméras d'identifier sans ambiguïté un marqueur donné et son orientation /

position. Par expérience, quatre caméras suffisent à obtenir une précision plus que satisfaisante :

le système arrive à mesurer les infimes tremblements qui agitent en permanence nos mains ! La

précision est donc le point fort du suivi optique, au détriment de la lourdeur en termes de calcul :

il faut dédier un PC (ou du matériel électronique dédié relativement puissant et cher) à l'analyse

des images obtenues pour extraire des informations de position et d'orientations. De plus, cette

technique ne fonctionne plus si les marqueurs sont invisibles (masqués) d'un trop grand nombre

de caméras.

b) Les périphériques tenus

Ces périphériques s’inspirent dans un premier temps des joysticks présents dans le

domaine du jeu vidéo (et de l’aéronautique) : un ensemble de boutons et de capteurs

d’inclinaisons peuvent être utilisés pour faire de la navigation (boutons

avant/arrière/gauche/droite ou détection de l’inclinaison) et de la désignation / manipulation

grâce au suivi des positions et orientations de ces outils. Plus formellement, on définit ces outils

comme des périphériques à 6 degrés de libertés, dont la position et l’orientation dans l’espace

2 En général dans le spectre de l’infrarouge, les environnements immersifs étant souvent plongé dans une relative obscurité, plus particulièrement les environnements semi immersif, comme les CAVE, murs immersifs ou les workbench, qui utilisent une rétroprojection de l’image sur une surface.

19

sont connues. Pour désigner ces outils de façon plus concise, j’utiliserais le terme de « flystick »

(Flying Joystick), qui malgré une connotation commerciale3, met en valeur à la fois sa parenté

avec les joysticks, et sa différence avec ceux-ci, dans la mesure où un flystick n’est fixé à aucun

support.

Un certain nombre d’outils dédiés peuvent être imaginés, comme des outils à retour de

force tenus comme un scalpel pour des applications dédiées à des chirurgiens, ou des plans de

coupe définis par une plaque de plexiglas suivie (pour découper virtuellement un corps humain,

par exemple).

Fig. 1.8 : un flystick muni de capteurs optiques de localisation

c) Les périphériques portés

Le premier type d’outil porté qui vient à l’esprit, même des néophytes, est le classique

gant de données. Il est enfilé comme un gant normal, possède 6 degrés de libertés et un certain

nombre de marqueurs : un marqueur de localisation (position et orientation), mais aussi, très

souvent, des capteurs de flexion de long des doigts pour pourvoir reconnaître des mouvements.

Certains gants sont sensibles au pincement (pinch gloves), ce qui peut avoir des applications

intéressantes : l’utilisation de gants et d’un clavier en réalité virtuelle est, au mieux,

inconfortable. Pourtant, le clavier reste un instrument privilégié pour saisir des données

« complexes ». On peut imaginer une plaque de plexiglas suivie, avec les touches d’un clavier

dessinées dessus. La position du gant par rapport à la plaque étant connue, et la pression du gant

sur la plaque étant détectée, on peut ainsi détecter l’appui sur une touche « virtuelle » (mais

dessinée sur la plaque) et proposer ainsi un substitut plus léger au clavier traditionnel : mais se

pose alors les problème de la taille des touche (trop petites, les fautes de frappe deviennent

difficiles à éviter, trop grandes, la plaque de plexiglas devient encombrante) et de la latence :

l'appui sur une touche est détecté par le système de suivi, qui est forcément moins rapide que la

gestion d’un vrai clavier.

On peut également imaginer des outils portés sur d’autre membre que la main, comme les

avants bras, pour faire de la détection des gestes limités non plus seulement aux mains. On peut

de plus munir ces outils de détecteurs de pincement ou, un écran tactile qui deviendrait une

extension à l’interface graphique du système, et permettrait une interaction limitée avec lui (un à

peu à la manière de la console portable DS du constructeur Nintendo). On pourrait par exemple

saisir très rapidement les réponses aux boites de dialogues modales (qui sont typiquement de la

forme « Etes-vous sur de … ? », un bouton Oui et un bouton Non). Les possibilités de

combinaisons de ces outils sont vastes, et amènent souvent à se poser la question du confort

d’utilisation d’un système de réalité virtuelle.

3 Constructeur ART.

20

Fig. 1.9 : Un modèle de gants de données sensibles au pincement.

1.1.1.3 Réalité virtuelle et confort

La réalité virtuelle a la particularité, par rapport à la visualisation sur un écran 2D, de

tromper la vision à l'aide d'un affichage stéréoscopique, pour recréer la perception de la

profondeur d'une scène. Or, notre perception de notre corps et de son placement dans le monde

est influencée par un certain nombre de capteurs :

- des organites placées dans nos oreilles qui nous donnent une évaluation de notre

orientation et des accélérations à la manière d'un niveau à bulle.

- les informations envoyés par nos muscles via les nerfs, surtout au niveau de la plante

des pieds et des muscles du dos.

- des informations envoyées au cerveau par nos yeux.

Chaque personne utilise de façon différente les informations reçues par ses capteurs, en

favorisant un type de données par rapport à un autre. Les personnes sans troubles de l'équilibre

sont généralement à l'aise si on les prive d'une source d’information à condition que ce ne soit

pas leur source préférée. Ceci implique que des personnes se basant surtout sur la vision risquent

d'être mal à l'aise d'un environnement réalité virtuelle, à cause des inadéquations éventuelles

entre les informations envoyées à leurs yeux et les informations (ou leur absence) reçues par les

autres organes de l'équilibre. Ils souffrent donc d'un mal du virtuel, tout à fait comparable au mal

de mer, de l'espace ou des transports où les informations visuelles et musculaires sont en conflits

(« Je sens le bateau bouger, mais dans ma cabine, je ne vois aucun mouvement »). Dans tous les

cas, un entraînement à ignorer les données contradictoires peut permettre, avec le temps, de

combattre ces différents maux (le fameux pied marin).

Pour en revenir au problème de la saisie de données en environnement virtuel, Ludovic

Sternberger, doctorant au LSIIT à Strasbourg, propose une solution intéressante et plus

ergonomique qu’un mini clavier porté au poignet (avec des mini touches donc) en utilisant les

clavier souples que l'on peut trouver dans le commerce. Le problème des claviers portés au

poignet, outre l’inconfort lié la petite taille des touches et au poids du clavier, est la position

inconfortable dans laquelle l’utilisateur doit se placer pour saisir ces données : les deux mains

levées. De plus, les environnements de réalité virtuelle plaçant souvent l'utilisateur dans une

position debout, la fatigue engendrée par cette pose (debout et les bras levés) rend pénible la

saisie de données en environnement immersif. Il serait vraiment dommage d’obliger l’utilisateur

à quitter le système de réalité virtuelle (pourquoi pas un système d’exploitation entier en réalité

virtuelle ?) pour éditer un fichier texte.

L’utilisation du clavier souple pour contourner ce problème serait de le couper en deux

(en le maintenant en état de fonctionner), le fixer sur des larges bandes de velcro, et enrouler

21

chaque demi clavier autour des cuisses de l’utilisateur : la disposition des touches reste la même

qu’un clavier classique, la position de frappe est confortable, avec les bras aux repos de long du

corps et le clavier juste sous les mains.

Enfin, la fatigue liée à la station debout peut être facilement évitée en laissant l’utilisateur

s’asseoir sur un tabouret de bar : ces tabourets ont la particularité d’être très hauts (plus d’1m),

permettant à l’utilisateur de s’asseoir et reposer ses jambes tout en étant dans une posture très

proche de la station debout, ce qui évite de devoir re-calibrer les instruments de suivi et permet à

l’utilisateur de quand même se lever et de se déplacer s’il le souhaite.

1.1.2 Solutions logicielles

Comme évoqué plus haut, pour décrire de façon exhaustive un système de réalité

virtuelle, il faut non seulement décrire les solutions matérielles pour l’affichage et l’interaction,

mais aussi la façon dont ce matériel est utilisé par le logiciel. Ce découpage se justifie par le fait

qu’une solution logicielle adaptée à un matériel donné pourra généralement être adaptée à un

autre type de matériel, moyennant des modifications du code souvent minimes. Il est donc

judicieux de bien se rendre compte des similitudes et différences entre deux types de matériels

différents afin de pouvoir adapter les méthodes classiques de génie logiciel (utilisation de design

patterns et de classes d’abstractions du matériel, par exemple) afin de minimiser le travail

d’écriture et de maintenance d’un logiciel dédié à un système de réalité virtuelle.

1.1.2.1 Taxonomie des tâches en RV

Tous les systèmes interactifs (en environnement réalité virtuelle ou non) nécessitent de

laisser l'utilisateur se déplacer et interagir avec le monde. Dominique Gerber donne dans sa thèse

[Ger04] un classement et une analyse des tâches effectuées en réalité virtuelle en se basant sur la

taxonomie proposée par Hand [Han97] et formalisée ensuite par Bowman et [Bow99]. On trouve

tout d’abord trois types d’actions naturelles : se déplacer, désigner un objet et le manipuler.

Enfin, un quatrième type de tâche, plus spécifique à l’informatique, est le contrôle du système.

a) Navigation

La navigation dans la scène virtuelle peut être traitée de façons différentes suivant le

cahier des charges associé avec l’application destinée à fonctionner en environnement virtuelle.

L’objectif est de laisser l’utilisateur se placer à un endroit donné afin qu’il puisse examiner la

scène suivant l’angle qui lui convient.

Une première méthode triviale consiste à nommer des points de vue et les afficher dans

un menu. L’utilisateur sélectionne le point de vue désiré dans le menu, et la scène est mise à jour.

Cette technique ne marche bien que dans le cadre d’une scène statique, aux nombres de lieus

limité (pour limiter la taille du menu) et où l’on peut nommer les points de vue de façon explicite

(« vue sur la tour Eiffel » plutôt que « vue n° 1 »). Mais elle ne permet pas à l’utilisateur de

choisir un point de vue arbitraire, et n’est pas naturelle : en effet l’utilisateur est « téléporté »

d’un endroit à l’autre, ce qui, en dehors de l’univers de Star Trek, n’est pas un concept courant.

En plus des systèmes qui détectent les mouvements des jambes lors d’une « marche sur

place », on peut citer la technique de la « marche redirigée » qui consiste à placer l’utilisateur

dans un grand espace (un CAVE de très grande dimension par exemple), suivre son déplacement

et tromper le cerveau en tournant la scène de façon imperceptible lorsqu’on détecte que

l’utilisateur risque de « rentrer » dans un mur, comme indiqué sur la figure 1.10. Cette technique

22

se base donc sur des mécanismes tout à fait naturels et est, du point de vue ergonomie, la

meilleure. Malheureusement, la solution de la marche redirigée demande un matériel

relativement lourd et des locaux de taille adaptée.

Fig. 1.10 : Principe de la marche redirigée. Figure d’après [Ger04].

Typiquement, les premières applications en réalité virtuelle se focalisaient

essentiellement sur la visualisation stéréoscopique d’un objet. Il a donc toujours été important de

fournir à l’utilisateur des moyens pour se déplacer autour de l’objet : il est possible d’utiliser

pour cela le suivi des mouvements de la tête. Dans ce cas, l’utilisateur n’aura qu’a se déplacer

physiquement (marcher ou pencher la tête) autour de l’objet pour changer son angle de vue. Il ne

faut néanmoins pas perdre de vue que dans la plupart des solutions matérielles (Workbench ou

CAVEs de dimensions réduites, par exemple) ses mouvements ne pourront avoir des amplitudes

supérieures à quelques mètres, sans compter, dans le cas du CAVE, une certaine réticence

naturelle à se déplacer dans une petite salle où l’on a du mal à voir où sont exactement les murs.

C’est pourquoi il est nécessaire de s’intéresser à d’autres solutions.

Une autre solution logicielle consiste à utiliser les boutons généralement disponibles sur

les outils d’interaction, et de leur associer des déplacements, à la manière d’une manette de

console ou d’un joystick. On peut copier le principe des manettes des consoles de jeu en

associant 4 boutons aux translations (avant, arrière, gauche, droite) et 4 autres boutons à

l’orientation du regard (haut, bas, gauche, droite). Une bien meilleure solution du point de vue de

l’ergonomie consiste à utiliser la direction du regard pour déterminer l’orientation, et ainsi se

passer d’une manipulation désagréable du point de vue avec des boutons numériques : les

premiers First Person Shooter adaptés sur les consoles de jeux « ancienne génération »

proposaient cette solution, et le manque de confort et de précision caractéristique d'une vue

contrôlée avec des boutons numériques a donné naissance à un style de FPS lents, où l'utilisateur

contrôle un personnage lent et peu agile (HALO est l'exemple typique). Toujours dans les

applications proposées par des consoles de jeu, on peut citer la prochaine console de jeu vidéo de

23

Nintendo (la Wii), qui utilise une manette suivie à l'aide de marqueurs lumineux : à partir d'une

image ce ces capteurs, la console est capable de déduire la position et l'orientation précise de la

manette. Toute une série d'applications intéressantes en terme d'interaction découle de ce choix

matériel : on peut citer un jeu de golf où l'utilisateur utilise la manette comme un club, un jeu

d'action où la manette peut simuler un arc, une épée, un club de golf, etc.

Une autre technique répandue est « l’attache dans le vide » (Grab the air) : un unique

bouton de l’outil d’interaction est dédié à la navigation. Un appui sur le bouton enregistre sa

position, et chaque déplacement de l’outil provoque un déplacement de la scène tant que le

bouton est tenu enfoncé. On peut ainsi avancer par incréments dans la scène.

Enfin, d’autres techniques plus ou moins exotiques et intéressantes existent : on peut citer

le Two-Handed Flying où la vitesse de déplacement est déterminée par l’écartement des bras, et

la direction par l’angle bissecteur formé par le bras.

b) Désignation

La désignation est le moyen qui permet à l’utilisateur de sélectionner un objet du monde,

avant d’éventuellement le manipuler : c’est donc la base de tout système interactif, qu’il soit en

réalité virtuelle ou non.

Désignation « naïve » par préhension et les « GoGo variantes »

La solution qui vient immédiatement à l’esprit (en plus d’une désignation triviale

indirecte par nommage des objets et sélection dans un menu) est l’utilisation de gants de données

par faire de la désignation par préhension : celle-ci consiste à utiliser la main de l’utilisateur, ou

une représentation de celle-ci dans le monde virtuel, pour désigner un objet.

Cette solution implique de reconnaître un geste de sélection, typiquement le resserrement

de la main en poing. Cette technique simple et intuitive possède un certain nombre de défauts :

tout d’abord le fait de fermer le poing fait bouger la main, ce qui risque de mener à une

désignation erronée si trop d’objets de petite taille sont proches lors de la désignation et/ou que

les mouvements de l’utilisateur ne sont pas filtrés. Enfin, il est impossible de sélectionner des

objets placés à plus « d’un bras » de distance par rapport à l’utilisateur.

Une solution est de proposer une main « extensible », s’inspirant de l’Inspecteur Gadget

et de son bras extensible. C’est le principe de la métaphore GoGo [PBWI96] et de ses variantes.

La métaphore introduit la notion de main virtuelle, dissociée de la main réelle. Dans un premier

temps, la position de cette main s’exprime en fonction de la position de l’épaule et de la main de

l’utilisateur. On applique à cette distance une fonction linéaire qui agrandit le bras virtuel. Des

variations (Fast GoGo, Stretched GoGo) introduisent une fonction non linéaire pour adapter la

précision du mouvement à la distance (en fonction de « zones » par exemple, cf. figure 1.11).

Dans la pratique, ces métaphores sont souvent assez difficiles à utiliser [BH97] pour des

utilisateurs novices, et il est surprenant qu’aucune proposition d’utiliser l’accélération fournie par

l’utilisateur à l’outil d’interaction comme fonction d’agrandissement n’ait été faite. Cette

solution aurait pourtant l’avantage de se baser sur un concept connu (l’inertie) et a déjà été testée

et validée de façon très satisfaisante dans de nombreux jeux vidéos de type First Person Shooter : elle permet de fournir à l’utilisateur une manipulation très fine (resp. très rapide) de son

point de vue si il bouge lentement (resp. rapidement) la souris.

Je n’ai pas pu tester cette idée de « GoGo pondéré par l’accélération » de façon concrète,

mais elle me semble être une très bonne piste pour un système de réalité virtuelle reposant

uniquement sur la préhension comme métaphore de désignation.

24

Fig. 1.11 : La métaphore GoGo et la matérialisation visuelle de la fonction d’agrandissement sous forme d’une jauge. Figure tirée du cours de Dominique Bechmann pour le M2R-IFA à

l’ULP.

Désignation par « encadrement » dans un plan

Le but de ces méthodes (Head Crusher, Framing Hands), portant le nom générique de

Image Plane Interaction Techniques, est de baser la sélection sur l’image (2D) perçue par

l’utilisateur plutôt que faire cette sélection en « vraie » 3D. L’utilisateur « encadre » les objets

qu’il souhaite sélectionner, en faisant par exemple un mouvement de pince à l’aide du pouce et

de l’index autour de l’objet à sélectionner ou en encadrant l’objet d’intérêt entre ses mains,

comme le font les cinéastes. Ces méthodes ont l’avantage de ne pas masquer l’objet perçu par

l’utilisateur pendant la désignation dans un système de réalité virtuelle type écrans géants,

contrairement à la désignation par préhension. Une variante de cette méthode a été testée par des

collègues de M1 (Paul Huchelmann, Thomas Jund, Ahlem Ghannouchi et Lionel Ketterer) sur

VRSS (Virtual Reality Sound Shaker, TER encadré par Matthieu Haefele de l’ULP Strasbourg)

une application en réalité virtuelle qui associe des sons et leurs déformation à des objets

manipulés et déformés par des gants de données. Ils souhaitaient définir une métaphore

permettant de réduire un objet (i.e. le masquer de façon temporaire) à l'aide des gants de

données. L’utilisateur place ses mains autour de l’objet d’intérêt et « écrase » l’objet. L’objet

d’intérêt n’est ainsi pas masqué lors de la première phase de la sélection, et cette technique

permet de contourner la faible précision en terme de flexion des gants, et de profiter de la grande

précision de localisation des gants, grâce au suivi optique. Cette technique fonctionne bien dans

la mesure où tous les objets manipulables de VRSS étaient à portée de bras, et relativement gros

et faciles à désigner.

25

Fig. 1.12 : un exemple de désignation par encadrement.

Désignation par pointage

La désignation par pointage consiste à montrer le ou les objets d’intérêt à distance. Ces

techniques sont appréciées car elle contournent les défauts de la désignation par préhension et ses

variantes, et n’obligent pas de posséder un matériel de suivi aussi précis que les métaphores par

encadrement.

Une première solution intuitive et très largement utilisée est le rayon laser virtuel. Cette

technique consiste à lancer un rayon dans la scène, en le faisant partir soit d’un outil tenu,

comme un flystick (définissant une espèce de pistolet laser), soit des yeux de l’utilisateur ou

encore d’un doigt de l’utilisateur et de calculer l’intersection avec le premier objet « touché » par

le laser. Cette technique est appréciée car elle permet une sélection relativement précise (si le

matériel de suivi est performant) d’objets distants ou pas, et est supporté de façon matérielle par

toutes les cartes graphiques modernes. Le calcul de l’intersection peut être déporté du CPU vers

le GPU très performant de ces cartes graphiques de la manière suivante : on définit un point de

vue du laser comme on le fait pour le point de vue de l’utilisateur, à ceci près que le point de vue

du laser est beaucoup plus réduit (dans sa version naïve 1x1 pixel et une projection orthogonale).

Ce rendu est fait dans une zone mémoire dédiée à la sélection dans la carte graphique, et

ressemble beaucoup à un rendu destiné à être affiché. A la fin du rendu, on peut récupérer des

identifiants dans cette zone mémoire, assortis de leur distance à l’utilisateur : ce sont les objet

que voit le laser. Ce mécanisme est extrêmement rapide, puisqu’il repose sur des circuits dédiés

de la carte graphique. La métaphore du rayon laser permet de sélectionner des objets éloignés

facilement, mais possède un certain nombre de défauts. Premièrement, nos mains sont en

permanence agitées de tremblements infimes, et ceux-ci sont amplifiés par la distance à laquelle

se trouve l’objet à désigner. On peut alors filtrer les mouvements de l’utilisateur, mais au risque

de rendre la métaphore paradoxalement moins précise pour des objets très (mais pas trop)

éloignés. Ensuite, trivialement, la métaphore du laser ne permet pas de sélectionner un objet

caché. Ludovic Sternberger propose un rayon laser à mémoire [Ste03] : l’utilisateur tourne sa

main pour courber le rayon et peut ainsi éviter les obstacles. Enfin, il est assez difficile de

sélectionner un objet qui apparaît très petit, que ce soit à cause de son éloignement ou à cause de

sa taille effective.

Des variantes associent un cône de sélection plutôt qu'une ligne droite au rayon laser (cf.

figure 1.13) pour faciliter la sélection d'objets distants et petits, avec le risque de sélectionner

d'autres objets à coté de l'objet d'intérêt.

26

(a) (b)

Fig. 1.13 : en (a) la version naïve du rayon laser et en (b) un laser muni d’un cône de sélection

c) Manipulation

On peut voir le problème de la manipulation comme une espèce d'extension du problème

de la désignation. Par manipulation, on entend modification de l'environnement, ce qui,

concrètement, consiste à déplacer et tourner des objets. On peut distinguer plusieurs sortes de

manipulations, selon le repère dans lequel elles se placent, et les traitements effectués.

Manipulation locales

Une manipulation est dite locale lorsqu'elle a les mêmes comportements qu'une

manipulation effectué à portée de main. Ces manipulations sont qualifiées de centrées objets

(Object Centered).

Plus concrètement, il s'agit de presque totalement séparer les translations et les rotations :

lorsque l'on fait tourner l'objet, il tourne sur lui-même. De façon plus formelle, on associe un

repère local à un objet, centré généralement sur le barycentre de l'objet pour avoir une rotation

« propre ». Les translations se font de façon identique dans le repère utilisateur et objet, alors que

les rotations se font par rapport au repère objet.

Manipulation distantes

Une manipulation est dite distante si elle est appliquée à partir d'un centre autre que le

centre de l'objet manipulé. Ce type de manipulation est généralement appelé centré sur

l'utilisateur (User Centered).

Ce type de manipulation ressemble à celle que l'on peut en faire en tenant un objet à bout

de bras, et que l'on tourne le bras : le centre de la rotation n'est plus l'objet, mais l'utilisateur. Ce

type de manipulation est souvent (mais pas obligatoirement) associé à des désignation distantes

par pointage, justement à cause du parallèle avec la vraie vie, évoqué plus haut, que l'on peut

faire : le laser virtuel est une sorte d'extension du bras, et il vient « embrocher » l'objet, ce qui

donne bien l'impression de tenir l'objet à bout de bras.

27

Fig. 1.14 : Manipulations locales (centrées objet) et manipulations distantes (centrées

utilisateur). Figure d’après [Ger04].

Manipulations contraintes

Une manipulation est dite contrainte lorsque seule une partie des mouvements de

l'utilisateur sont transmis à l'objet manipulé.

Jusqu'à maintenant, les manipulations locales et distantes étaient libres : on pouvait leur

appliquer toutes les transformations. Or, de nombreux objets de la vie courante ont des

mouvements contraints : par exemple, une porte ne tourne qu'autour de ses gonds, une roue ne

tourne qu'autour de son axe.

On peut donc appliquer ce principe aux deux type de manipulations vues précédemment :

on peut vouloir contraindre le déplacement d'un objet dans un plan ou lui appliquer des

transformations dont les paramètres ont des valeurs contrôlées, comme une translation

d'exactement 2 unités ou une rotation d'exactement 12.5 degrés, etc. Il suffit pour cela d'ignorer

les mouvements indésirables qui ne respectent pas la contrainte. Par exemple, pour contraindre le

mouvement dans un plan, on peut ne lire que 2 valeurs du vecteur de translation.

On peut appliquer des contraintes plus complexes, satisfaisant des critères physiques par

exemple. On peut imaginer une application en réalité virtuelle dédiée à la chimie, où l'utilisateur

place des atomes afin de construire et visualiser une protéine ou une molécule. Les atomes

exercent les uns sur les autres des contraintes (d'ordre magnétique ou d'énergie, par exemple) que

l'on peut injecter dans le modèle en empêchant l'utilisateur de placer un atome si les forces de

l'atome ajouté changent trop la forme ou la fonction de la protéine. L'apport de la réalité virtuelle

dans ce cadre est très intéressant, car il permet de transformer un concept abstrait et distant (la

résolution d'une formule mathématique) en une représentation concrète et tangible de ce concept

abstrait.

28

Métaphore Type de sélection Désignation Manipulation Limitations

Liste énumérée

- Indirecte - Nommage des

objets

Taille de la liste

Préhension naïve Locale (< 50 cm) Préhension Centrée objet Objets éloignées

Préhension GoGo Distante Préhension Centrée objet Objets très éloignés

Encadrement Distante Désignation - Précision du

matériel de suivi

Rayon laser

Distante Désignation Centrée

utilisateur

Scènes denses

Objets très petits

Mouvements

parasites de la main

Tab. 1.1 : Comparaison des différents familles de métaphores : à chaque métaphore un usage spécifique.

d) Contrôle du système

Comme n'importe quelle autre application, une application en réalité virtuelle doit fournir

des moyens de contrôle à l'utilisateur. On pense naïvement à l'interface graphique, mais une

application peut également être contrôlée à la console.

Une définition [Ger04] du contrôle du système serait donc l'ensemble des techniques qui

permettent à l'utilisateur de modifier les états internes de l'application, voire même les moyens de

l'application pour modifier l'application. On peut citer l'envoi d'une commande à l'application

(« Quelle est la dérivée de f... »), le changement d'une valeur (« avec f(x) = sin x ») ou tout

changement d'état de l'automate déterministe représentant l'application.

En ce qui concerne les interfaces graphiques, elles reposent sur le concept de Widget

(Window Object, composant graphique [CSH+92a]) qui sont les atomes de l'interface. Ce sont

des objets qui associent une représentation graphique à un comportement

Dans le cadre de la réalité virtuelle, on découper le contrôle d'application en deux sous-

parties : les interfaces 2D ½ et les interfaces 3D.

Les interfaces 2D 1/2

Elles sont directement inspirées des interfaces 2D utilisées sur les machines de bureau

(WIMP : Windows, Icons, Menus and Pointer [SIKH82]) et portées telles quelles en 3D. On

dispose ainsi d’un grand nombre de widgets, au fonctionnement connu par tous les utilisateurs

d’ordinateurs.

Les interfaces 3D

Elles sont pensées dès le début pour la réalité virtuelle, et tâchent de profiter de la liberté

supplémentaire fournie par la 3D et des apports de la proprioception pour enrichir les widgets.

On peut les citer les métaphores suivantes comme exemple de métaphores pensées pour la 3D.

Le menu TULIP, proposé par Bowman et Wingrave [BW01], ce menu s'utilise surtout

dans un cadre réalité totalement virtuelle (i.e avec casque) à cause du problème de l'occlusion de

l'image par la main de l'utilisateur dans un cadre semi immersif. En effet, l'idée est d'afficher

autour des doigts (virtuels) de l'utilisateur les éléments d'un menu. L'utilisateur, portant des gants

29

de données, pince le doigt correspondant à l’élément souhaité avec son pouce. Ce menu a

l'avantage d'utiliser l'agilité des doigts et la proprioception : la sélection peut se faire en aveugle

si on sait déjà sur quel doigt est l’élément souhaité du menu.

Fig. 1.15 : Le menu Tulip. Figure d’après [BW01]

Le Command and Control Cube, proposé par Grosjean et al. [GC01], cette métaphore

propose d'utiliser un cube sub-divisé en 3x3x3 sous-cubes. A chacun de ces cubes (excepté celui

du centre qui est réservé à la sortie du menu) on associe un élément du menu. L'utilisateur

déplace sa main dans le sous-cube souhaité pour activer l'élément associé du menu. Cette

métaphore a l'avantage d'être utilisable quelque soit les solutions matérielles d'affichage. De plus,

elle tire pleinement partie de la proprioception puisqu'un utilisateur expérimenté (i.e. connaissant

le menu : « l'élément que je veux est à cet endroit précis ») peut déclencher l'activation d'un

élément du menu sans le regarder. En ce sens, on peut voir le CCube comme un menu par

reconnaissance de geste muni d'un retour visuel. Enfin on notera que le CCube n’affiche qu’un

étage à la fois (l’un des trois étages du CCube où se trouve la main de l’utilisateur) afin d’alléger

l’encombrement visuel.

Fig. 1.16 : À gauche, la division du CCube en 3x3x3 cubes. À droite, un des trois étages du

CCube. Figures d’après [GC01]

Les menus circulaires et leurs variantes, parmi lesquelles on peut par exemple citer le

RingMenu [Ger04]. L'idée est de reprendre le concept des menus 2D et d'utiliser la 3ème

dimension en disposant les éléments du menu en arc de cercle devant l'utilisateur afin de

minimiser l’espace nécessaire à leur affichage. Ces menus ont l'avantage d'être naturels pour des

utilisateurs novices ou non, d'être adaptables aux différentes solutions d'affichages et outils

d'interaction. De plus, c’est le seul des menus évoqués sans limites théoriques en nombre de

sous-menus. Mais il faut se rendre compte qu'on est concrètement limité par la taille de l'arc de

cercle associé à un item : trop petit, la sélection devient impossible, limitant de fait la nombre

d'items du menu à 8 ou 9 (ce qui est également la limite ergonomique d'un menu : plus d'items et

30

l'utilisateur ne pourra mémoriser efficacement les items de menu, l'obligeant à le reparcourir à

chaque fois.)

Fig. 1.17 : le RingMenu. Figure d’après [Ger04]

1.1.2.2 Librairies RV

Les librairies de réalité virtuelle font partie des solutions logicielles à la problématique de

la réalité virtuelle. Leur but est de fournir une certaine abstraction du matériel au concepteur

d'une application en réalité virtuelle. Cette abstraction du matériel se fait généralement aussi bien

sur l'affichage stéréoscopique (écrans géants, ou casques) que sur les périphériques d'interaction.

On notera que la gestion de l'affichage stéréoscopique concerne aussi l'abstraction de la

description de la scène 3D : l'utilisateur construit une scène 3D comme il le fait d'habitude sur un

poste mono-processeur avec un écran 2D, et les librairies se chargent de calculer les différents

points de vue de la scène et d'en distribuer le rendu. Cette notion de point de vue sous tend à la

fois l'organisation physique des écrans (workbench, CAVE) mais aussi, pour chaque écran, la

vision stéréoscopique (i.e. deux scènes légèrement décalées par écran).

Il existe un grand nombre de ces librairies, dont beaucoup sont dédiées à un matériel

précis. Je distinguerais deux types de librairies : celles dont le seul but est d'abstraire une partie

du matériel, on peut citer CAVE ou VRJuggler (et son extension ClusterJuggler), et celles dont

le but est d'abstraire le reste de la conception du système, en particulier VRLib, qui est décrite

dans ce rapport.

CAVELib

CAVELib est une librairie bas niveau destinée à la réalité virtuelle, utilisant OpenGL et

fournissant des fonctions pour gérer le rendu distribué, la vision stéréoscopique et le suivi. Elle a

initialement été conçue pour les systèmes d'affichage projectifs, de type workbench ou CAVE,

mais un support pour les casques a été ajouté. Elle se base sur un paradigme maitre-esclave(s)

pour le rendu distribué. Cette librairie est très répandue dans le milieu de la réalité virtuelle,

malgré ses défauts :

- Portabilité : IRIX, Solaris, Windows et Linux.

- Support limité de l'équilibrage de charge (load balancing), entre à cause de l'obligation de

connecter tous les périphériques d'entrée à la machine maître.

- Faible abstraction du matériel : par exemple, obligation pour l'utilisateur d'utiliser de la

mémoire partagée, même dans le cas d'un rendu mono-threadé.

- Peu extensible : pas prévue pour être une solution à long terme, besoin de mettre à jour le code

de son application à chaque nouvelle version de CAVELib

- Payant ! (commercialisé par VRCO).

VRJuggler

Développée au Virtual Reality Applications Center de l'université de l'état de l'Iowa,

VRJuggler est né l'analyse des défauts de ses concurrents [JBH01]. Comme CAVELib, et bien

31

d'autres, son rôle est de fournir une abstraction du matériel de rendu, des primitives réseau et des

périphériques d'interaction. Sa particularité est le soin apporté à sa structure : son organisation à

partir d'un noyau aussi petit et indépendant du matériel que possible (et donc plus facile à porter

sur différents environnements) et l'abstraction complète du matériel rendent VRJuggler très

flexible. Ceci permet le développement d'une application de réalité virtuelle sur une machine de

bureau classique, puis de tester cette application dans le système de réalité virtuelle sans changer

le code. De plus, un support commercial est fourni aux utilisateurs de VRJuggler dans des

environnements professionnels par la société Infiscape. Ses caractéristiques sont les suivantes :

- Portabilité : IRIX, Linux, Windows, FreeBSD, Solaris, et Mac OS X déjà supportés. Ecrans

géants et casques supportés de façon native, possibilité d'abstraire d'autres périphériques

facilement.

- Equilibrage de charge : offre une surveillance et un affichage des performances du cluster

(latence, temps d'exécution, etc) et possibilité de reconfigurer la distribution du rendu et les

abstractions des périphériques à la volée pendant l'exécution. On offre ainsi à l'utilisateur la

possibilité d'équilibrer à la main l'équilibrage de la charge. Possibilité de brancher des

périphériques d’entrée sur une n’importe quelle machine du cluster.

- Très extensible grâce à l'abstraction du matériel et l'utilisation d'un micro-noyau.

- Gratuit : licence LGPL

1.2 Images de synthèse et animation L'animation traditionnelle en images de synthèse s'inspire des mécanismes utilisés en

animation papier. Un certain nombre d'images clés sont dessinées et les animateurs dessinent les

étapes intermédiaires de l'animation (inbetweening ou tweening). Cette étape de dessin des

images intermédiaires est en fait une interpolation de la position et de l'orientation des éléments

de l'image entre deux points clés (keyframes). Dans le cadre de l'animation papier, cette

interpolation peut être guidée par une machine, en offrant au dessinateur une base sur laquelle

« caler » son animation.

De façon similaire, le mécanisme d'interpolation peut être appliqué aux différents

éléments d'une scène 3D : habituellement, on interpole les positions et les orientations des objets

entre deux points clés, mais rien n'interdit d'interpoler des attributs non géométriques comme les

propriétés optiques de l'objet (couleur, réflexion, etc.). Une application classique est d'interpoler

les positions des sommets de l'objet afin de passer d'un objet donné à un autre objet, soit en

fixant le nombre de sommets, soit en proposant un mécanisme de création ou de décimation de

sommets adapté à l'interpolation. La figure 1.18 montre l’interpolation simple d’une trajectoire à

partir de deux points clés.

32

Fig. 1.18 : Interpolation de la trajectoire d’un cube (gris pâle) partir de deux points clés (gris

foncés)

Cette interpolation peut être linéaire dans les cas d'école, mais on préfère en général une

méthode qui produit des animations moins hachées. Classiquement, on utilise une interpolation

basée sur l’utilisation de courbes paramétriques : la trajectoire de l'objet est alors visualisé

comme une courbe dans l'espace XYZ. D’après mon expérience de la modélisation 3D, une

famille de courbes est très souvent utilisée : la famille des Splines. Elle regroupe les courbes de

Bézier et la famille des B-Splines (B-Splines uniformes, constantes, linéaires, uniformes

quadratique, cubiques, uniformes cubiques, etc.). L’idée des Splines est de décrire une courbe à

partir d’un certain nombre de points de contrôle et, éventuellement, des options de la courbe aux

points de contrôle : tangence, continuité, tension, biais, inertie, etc. L’intérêt est de résumer la

courbe par ses points de contrôle (qui correspondent en fait aux positions des objets aux

moments clés) et des propriétés inspirées par des objets concrets (les cordes par exemples),

beaucoup plus parlants que des équations. On classe aussi souvent ces méthodes en fonction de

leur comportement vis-à-vis des points de contrôle : soient elles approximent les positions des

points de contrôle (elles passent « à coté » des points de contrôle), soient elles les interpolent

(elles passent « par » les points de contrôle). Dans le cadre de l’animation, on aura tendance à

préférer les modèles de Splines qui interpolent, car leurs comportements sont en général plus

prévisibles, et donc plus naturelles pour l’animateur, que les Splines à approximation.

Cette méthode présente l'indéniable avantage d'être intuitive et très facile à appréhender,

même pour un utilisateur novice. En effet, nous faisons très naturellement de l'interpolation de

position et d'orientation dans la vie courante : nous avons toujours une vision parcellaire du

monde qui nous entoure, mais notre cerveau maintient à jour des informations sur les positions

des objets qui nous entourent. Cette capacité nous permet, par exemple, d'évaluer la vitesse d'un

véhicule ou la position d'un véhicule en train de nous doubler entre 2 coups d'œil dans les

rétroviseurs.

Néanmoins la technique d'animation par points clés (keyframing) présente tout de même

l'inconvénient d'être lourde à mettre en place en terme de charge de travail. Dans le cas d'une

trajectoire complexe (avec beaucoup de changements brutaux de trajectoire), le nombre d'images

clés à définir peut rapidement devenir très important. De plus, il est nécessaire d'avoir une

certaine expérience pour pouvoir placer judicieusement ces points clés (naïvement : à chaque

changement brutal de trajectoire) et garantir la cohérence visuelle de l'animation.

33

2. VRLib La VRLib (pour Virtual Reality Library) est une libraire dédiée à la conception

d’interfaces en réalité virtuelle. Dans une première partie, j’exposerai comment est organisée la

librairie, et à quelles problématiques elle répond. Puis dans une deuxième partie j'exposerai mes

apports à la VRLib lors de ce stage.

2.1 Contexte Cette librairie a été écrite par Ludovic Sternberger et Arnaud Fabre, du LSIIT

(Strasbourg) dans le cadre de leurs travaux de thèses. Le but premier de la VRLib est de fournir

au concepteur une API haut niveau pour la création d’interfaces graphiques 3D, en

environnement virtuel ou non, grâce, entre autres, au mode « simulation » de VRJuggler qui

permet l’exécution d’une application sur un poste de travail classique. Elle contient tout un

ensemble de widgets prêts à être utilisés pour le développement d’une interface. Mais nous

verrons que ce n’est pas son seul objectif. Elle s'utilise en conjonction avec d'autres librairies de

réalité virtuelle, car le rôle de la VRLib n'est pas d'abstraire les primitives systèmes et le système

d'affichage, même si elle propose, comme nous le verrons, de compléter cette abstraction du

matériel.

2.1.1 Structure et fonctionnement

La VRLib est découpée en 3 sous parties. Ce découpage est très important, car nous

verrons que les dépendances entre ces parties sont soigneusement établies, afin d'augmenter la

modularité de la librairie. Enfin, la VRLib repose autant que possible sur la bibliothèque de

fonctions standards du C++ (STL, pour Standard Template Library) et OpenGL afin d'assurer

une portabilité maximale : par exemple, les primitives systèmes, comme l'ouverture d'un fichier,

sont abstraites via la STL.

On trouve tout d'abord ITLib, dont le but est de fournir une base mathématique à

l'utilisateur. Elle propose les implémentations d'objets classiques en informatique géométrique,

comme des vecteurs, des matrices, des quaternions ou encore des NURBS (courbes

paramétriques). Cette partie de la librairie est totalement indépendante du reste : elle ne dépend

que de la STL et OpenGL. Cette indépendance vis-à-vis du reste de la libraire permet d'utiliser

uniquement cette sous-partie sans avoir à modifier le code. De plus, elle sert de lien entre

OpenGL et l'utilisateur : on peut par exemple envoyer une matrice directement à OpenGL, car le

format de la matrice est standard (4x4 et disposition en colonnes).

On a ensuite MMLib, qui est la partie multimédia de la libraire. Elle est responsable, par

exemple, du chargement d'images, d'objets 3D ou de polices de caractère. Elle ne dépend que de

la STL, OpenGL et ITLib, pour les raisons de modularité du code évoquée ci-dessus.

Enfin, on trouve le noyau de la librairie proprement dite : VRLib. Cette partie est la plus

conséquente, et propose, entre autres, une bibliothèque de widgets 2D ½, un mécanisme de

transmission de message qui définit le comportement des widgets, des abstractions des outils

d'interactions ou la définition d'une application minimale. Elle ne dépend que de MM, de IT, de

la STL et d'OpenGL.

34

Fig. 2.1 : Dépendances au sein de la VRLib.

2.1.2 Motivations

Les buts de la VRLib sont multiples : d'une part compléter l'abstraction matérielle

fournies par les autres librairies, et d’autre part fournir un certain nombre d'outils typiques de la

réalité virtuelle, dont une bibliothèque de widgets 2D ½ prêts à être utilisés dans une application

en réalité virtuelle. Je précise ici que l’intérêt d’abstraire le matériel a comme conséquence, entre

autres, de pouvoir développer et tester une application en réalité virtuelle sur une station de

travail classique, et pouvoir ensuite passer sur un système de réalité virtuelle sans modifier le

code de son application. L’intérêt est double : d’une part, il est généralement plus confortable de

développer sur une station de travail et, d’autre part, les systèmes de réalité virtuelle sont

généralement partagés entre plusieurs équipes, ou au moins plusieurs utilisateurs. Il convient

donc d’utiliser au mieux le temps alloué à l’utilisation d’un tel système.

Un des rôles de la VRLib est de proposer à l’utilisateur souhaitant créer une interface

graphique une totale abstraction du matériel. En effet de nombreux systèmes de réalité virtuelle

utilisent un cluster de PC afin d’accélérer l’exécution. On se rend compte ici que l’on a fort

parallélisme de données (architecture Single Instruction Multiple Data streams) : on applique le

même code (le rendu de la scène OpenGL) sur des données différentes (les 2 points de vue

différents pour chaque écran). Il est dont très intéressant de paralléliser le rendu des deux scènes

OpenGL sur des machines différentes. Je signale qu’apparaissent aujourd’hui des cartes

graphiques « doubles » (SLI) qui permettraient de ne paralléliser le rendu que sur les processeurs

graphiques, et associer à chaque écran une unique machine muni de deux contextes graphiques,

ce qui permettraient de limiter les ralentissements de l'exécution liés aux temps de

communication via le réseau.

Un autre but de la VRLib est d'offrir à l'équipe IGG une plateforme d'outils « clés en

main », regroupant plusieurs thématiques de l'équipe. C'est résolument le cas en ce qui concerne

les travaux en contrôle de système et en réalité virtuelle, dans la mesure où la VRLib, en plus

d’être parfaitement fonctionnelle et utilisable en tant qu’API, est le laboratoire idéal

d'expérimentation de nouvelles métaphores d'interaction : elle fournit, entre autres, une totale

abstraction du matériel d'affichage et d'interaction, de l’architecture du système (parallèle ou

monoprocesseur), ainsi que des mécanismes de transmission de messages pour décrire le

comportement. Concrètement, la conception d'un nouveau widget ou d'une nouvelle métaphore

est grandement simplifiée, et devient accessible à des personnes plus spécialisés en ergonomie

qu’en développement. De plus, le développement de VRSTIGMA a permis de regrouper dans la

VRLib plusieurs domaines de recherche historiques de l’équipe, comme la modélisation à base

35

topologique ou les modèles de déformations (noyau de G-carte et modèle de déformation

DOGME utilisés par VRSTIGMA). Enfin, un certain nombre d'outils plus généraux ont été

implantés, dont un outil de calibration des données émises par les périphériques d'interaction.

2.1.3 Abstraction de l'architecture parallèle

Dans le cas d’un code parallélisé sur des machines différentes, VRJuggler s’occupe du

calcul de la scène stéréoscopique et de l’envoi des scènes « décalées » aux différentes machines

via le réseau. Mais malgré cette première abstraction du matériel fournie par VRJuggler, qui

génère la scène stéréoscopique à partir d’une scène OpenGL « normale » (non stéréo),

l’utilisateur utilisant VRJuggler sans la VRLib va devoir être conscient de la parallèlisation de

son code.

En effet, certaines données vont être spécifiques à une machine en particulier. Plus

particulièrement, certaines données d'OpenGL (on peut citer le numéro unique qui identifie une

texture dans la mémoire de la carte graphique) vont être spécifiques à un contexte graphique

(context specific). Une des caractéristiques de la VRLib est la philosophie adoptée par ses

auteurs qui permet la totale abstraction de l’architecture vis-à-vis du code. Il s’agit typiquement

d’attendre la première passe d’affichage pour charger les données spécifiques à un contexte

graphique (i.e. une des machines esclaves chargées du rendu de la scène).

Ainsi, la VRLib utilise pour protéger les données spécifiques à un contexte une structure

de carte associative à n entrées, chargée d'associer une donnée à chacun des n contextes : ce sont

des objets appelés ContextData. Le but est d’associer une certaine donnée à chaque thread et/ou

contexte graphique, de façon cachée pour l’utilisateur, sans qu’il ait à se soucier du thread ou du

contexte. Dans ce sens, la VRLib complète parfaitement l'abstraction du matériel en partie

fournie par VRJuggler, en déchargeant entièrement l'utilisateur des problèmes dus aux contextes

multiples.

Un exemple concret est la classe d'objets utilisée pour charger une texture à partir d'une

image. Cette classe contient un tableau de pixels (l'image) et, entre autres, l'identifiant de textures

généré par OpenGL, protégé par un ContextData. L'utilisateur ne se soucie d'aucune des

contraintes matérielles : il spécifie le nom de l'image qu'il souhaite charger, et la VRLib s'occupe

du reste : enregistrer le nom du fichier, attendre la première passe de dessin, faire générer par

OpenGL pour chaque contexte l'identifiant de la texture, et ranger cet identifiant dans la carte

associative ContextData à l'endroit adéquat.

Cette habitude de charger les données liées aux contextes graphiques lors de la première

passe d’affichage définit réellement une partie de la « philosophie » de la VRLib, et permet une

totale transparence pour un utilisateur novice, ou ne souhaitant pas avoir un code dépendant de

l’architecture sur laquelle il développe son application.

2.1.4 Gestion de la hiérarchie des composants

Toute interface graphique peut se voir comme un arbre : les widgets possèdent une

hiérarchie. On utilise habituellement un composant « vide » particulier comme racine de l’arbre

(et on le nomme souvent root). Ainsi la fenêtre principale d’une application a généralement le

widget root comme père, et possède un certain nombre de fils.

36

Fig. 2.2 : Une interface et la hiérarchie de widgets associée.

En plus de fournir un ensemble de widgets prêts à l'utilisation, la VRLib de fournit à

l’utilisateur une gestion transparente de la hiérarchie de widgets : il crée ses widgets en leur

assignant un père à la construction. L’utilisateur n’a ensuite plus à se soucier de l’affichage de

cette hiérarchie : la VRLib appelle la fonction d’affichage du widget racine, qui est toujours

présent, et ce widget racine appelle récursivement les méthodes d’affichage de chacun de ses

widgets fils : on a en fait un parcours de l'arbre des widgets en largeur d'abord4. L’utilisateur peut

supprimer ou ajouter de widgets, la VRLib maintient l’arbre à jour, évitant ainsi à l’utilisateur de

devoir se préoccuper de l’affichage de son arbre de widgets. De plus, la VRLib permet à

l’utilisateur de cacher un widget sans pour autant le supprimer de la hiérarchie.

La VRLib également permet la définition d'un certain nombre d'états typiques des

composants d'une interface graphique : un composant peut être, entres autres :

• visible ou invisible : ce champ permet de masquer temporairement un composant sans

avoir à mettre à jour l'arbre

• activé ou désactivé : le composant est visible, mais inactif. On le dessine souvent en

"grisé" pour souligner son état inactif.

• sensible aux messages de la VRLib ou non : ces messages sont générés lors du

déplacement, de l'activation, la disparition, etc. d'un objet.

2.2 Apports personnels à la VRLib Dans la mesure où j’allais l'utiliser dans le cadre de mon stage pour décrire l'interface de

l’application concrète de mon stage, j'ai participé à l'élaboration de cette librairie, et mes apports

à la VRLib sont les suivants :

• participation à la réflexion sur l'architecture : plus particulièrement la séparation

géométrie / comportement des widgets.

• participation au développement des briques de base (noyau) : on peut citer les utilitaires

pour charger des images, des objets 3D ou la participation au développement des widgets

4 Sauf dans le cas particuliers d'objets transparents : l'algorithme historique de rendu temps réel (Z-Buffer sans extensions) oblige à rendre les faces transparentes en dernier afin de préserver la cohérence de la transparence.

Root

Parent

Child Child

Dialog Window

Palette

37

eux mêmes.

• participation aux tests et utilisation de la VRLib : il s'agissait d'évaluer les qualités et

défauts de la libraire en permanence afin de les corriger. Ce travail s'appuyait sur les

retours d'autres utilisateurs de la VRLib, et sur mon expérience de la programmation

J’évoquerai dans cette partie mes différents apports à la VRLib, en suivant la progression

qui m'a amené, à partir du développement de briques de base, à effectuer un travail de

réflexion. J'évoquerai d'abord le travail que j'ai fourni sur les images et qui m'a amené à

proposer une solution adaptée à la VRLib pour l'affichage d'un texte dans une scène 3D. Puis,

je parlerai de la structure de données destinée à la représentation et l'affichage d'objets 3D et

comment l'apport de cette fonctionnalité était guidé par la volonté de séparer la description de

l'apparence d'un widget de la description de son comportement.

2.2.1 Images, textures, et polices de caractères

Avant d'entrer dans le vif du sujet, j'aimerais expliquer la solution utilisée couramment

pour afficher un texte dans une scène 3D. Le problème se pose typiquement dans le cas des

widgets : une fenêtre possède par exemple un titre, que l'on affiche sur la barre de titre. Or cette

barre est un objet 3D, que l'on peut déplacer : on aimerait donc pouvoir plaquer ce texte sur la

barre, et donc le décrire comme les autres objet 3D. En fait, ce texte est très généralement

contenu dans un plan plongé dans l'espace 3D.

La solution classique est d'associer à chaque lettre un quadrilatère, et de plaquer une

texture correspondant à la lettre. Cette texture correspondant à une lettre est appelée un glyphe.

Pour afficher un texte, il suffit de coller côte à côte autant de glyphes que nécessaire.

La VRLib supportait dans un premier temps le chargement de certains types de fichiers

images. J’ai donc travaillé à l’amélioration de ces chargeurs d’images, afin de les rendre plus

robustes et généraux. De plus, j’ai travaillé à l’amélioration de l’affichage des textes dans

l’espace 3D de visualisation. Dans chacun des cas, j’évoquerais l’état de la VRLib avant et après

le travail fourni.

2.2.1.1 Images

Avant mon arrivée, la VRLib gérait une version minimale du chargement des fichiers

images. Cette solution était suffisante pour afficher du texte sous forme de glyphes, mais nous

verrons dans la partie polices de caractère que cette solution possédait un certain nombre de

défauts.

J’ai donc complété les fonctionnalités des chargeurs d’images de la VRLib. Au départ ces

chargeurs ne fonctionnait que dans un mode qui allouait 32 bits pour chaque pixel (8 pour le

rouge, 8 pour le vert, 8 pour le bleu et une valeur de transparence sur les 8 derniers bits : mode

couleurs réelles). Or ces formats autorise la création d’une palette de couleurs, qui contient un

nombre volontairement réduit (256) de couleurs. Les pixels indexent ensuite une couleur dans la

table. Cette solution permet de grandement réduire la taille mémoire de certaines images,

puisque la taille passe de n * 32 bits (avec n = nombre de pixels) pour une image en mode

couleurs réelles à m * 32 + n * 8 bits (avec m = nombre de couleurs, m < 256) pour une image en

mode indexé. Ce mode indexé peut être très intéressant dans le cas de données scientifiques de

très grande taille générées par un capteur muni d’une sensibilité réduite.

38

Le choix d’améliorer les chargeurs d’images aux formats TGA et BMP se justifie par le

fait que ces deux formats soient extrêmement répandus et versatiles. Par exemple, j’ai choisi de

ne pas implanter le format GIF malgré son omniprésence, dans la mesure où il ne gère que les

images indexées : il n’aurait rien apporté de plus par rapport aux fichiers TGA en mode indexé.

Dans le même ordre d'idée, j'ai écarté le format JPG, car sa compression avec pertes des données

par ondelettes risquait de provoquer des artefacts visuels : ceux-ci sont acceptés dans le cadre

d’une simple visualisation de l’image (la compression utilisant les faiblesse du système visuel

humain), mais deviennent inacceptables si l’on cherche à utiliser ces données pour décrire des

glyphes.

TGA BMP

Profondeur d’image De 1 à 32 bits par pixel. 1, 4, 8, 16 ou 24 bits par pixel

Mode couleurs réelles Oui Oui

Mode couleurs indexées Oui (256) Oui (256)

Transparence Natif, sur 8 bits Révision Windows XP, 8 bits

Compression Sans perte RLE Sans perte RLE

Tab. 2.1 : Comparatif des formats d’image TGA et BMP. Les deux sont très proches en terme de fonctionnalité, mais le BMP est généralement associé au système d’exploitation Windows.

2.2.1.2 Textures

Le but du travail sur les formats d’images était de fournir à l'utilisateur un moyen

transparent et robuste de charger une image dans une texture, en utilisant les solutions de la

VRLib pour abstraire l’architecture (en plus de VRJuggler, qui abstrait le matériel) et les

données spécifiques à un contexte. Cette texture est utilisable dans de nombreux cas, mais nous

nous intéresserons à leur utilisation en tant que glyphes par les polices de caractères.

2.2.1.3 Polices de caractères

Comme évoqué précédement, les polices de caractère étaient dans un premier temps

chargées à partir d'un fichier image contenant les glyphes. Mais cette solution posait un problème

: les glyphes étaient découpés de la même façon pour toutes les lettres. On obtenait une police de

caractères monospace, où chaque lettre a la même largeur, que ce soit un 'i' ou un 'm'. Ceci posait

un problème en terme de compacité du texte obtenu. La figure 2.3 permet de comparer une

police monospace à une police à taille de caractère variable.

39

Fig. 2.3 : En haut, un exemple de texte originalement affiché par la VRLib. En bas, le texte

affiché par la nouvelle version de la VRLib. On notera le gain de place apporté par des glyphes de taille variable.

Il s'agissait de disposer d'un moyen pour altérer individuellement la taille de chaque

glyphe. Une première solution consistait à analyse l'image, et déterminer quelle zone d'un glyphe

était effectivement couverte par celui-ci. Mais cette solution donnait des résultats peu satisfaisant

d'un point de vue typographique et visuel, et, de surcroît, au prix d'une phase de chargement plus

lourde (analyse de l'image + découpage en glyphes).

Pour résoudre le problème des tailles de glyphes fixes, nous avons abandonné l’idée

d’utiliser une simple image pour décrire les polices de caractères. J’ai dans un premier temps

examiné la possibilité d’utiliser les glyphes internes du système d’exploitation. L’idée était

d’utiliser les utilitaires fournis par la libraire GLUT (Graphics Library Utility Toolkit) qui

rajoute un certain nombre de fonctionnalités à OpenGL. Les textes affichés grâce à cette solution

présentent les fonctionnalités requises sur la taille des glyphes, mais ne peuvent être transformés

comme le sont les autres objets OpenGL (translations, rotations). Ils étaient donc inutilisables en

l’état, puisqu’on ne pouvait les plaquer sur nos widgets convenablement.

J’ai donc testé la solution suivante : on affiche un texte à l’écran en utilisant les glyphes

du système, en blanc sur fond noir, afin de retrouver les niveaux de transparence. Puis on

transfère l’image à l’écran dans une texture, et on plaque cette texture (contenant le texte) sur un

widget. Je me suis malheureusement heurté à un problème technique : cette phase de rendu dans

une texture pose problème car il faut effacer la scène courante (pour avoir un fond noir) et re-

rendre le texte dans la texture à chaque modification du texte, qui est une opération très courante

quand on conçoit une interface. Rien ne doit empêcher le concepteur de modifier le texte à

chaque rendu de l’interface (pour afficher le nombre d’images calculées depuis un temps t par

exemple). Or, avec cette solution, si on modifie à chaque image le texte, on efface à chaque

rendu l’image générée pour rendre le texte : concrètement, on ne verra qu’une image à fond noir

avec un texte, et plus nos widgets. Il est possible de contourner ce problème en ayant une phase

de rendu de tous les textes de l’interface, puis le rendu de l’interface elle-même, mais cette

solution me déplaisait beaucoup sur le fond pour son manque d’élégance et cadrait mal avec la

philosophie d’abstraction des contraintes matérielles de la VRLib.

Une autre possibilité aurait été d’utiliser les extensions d’OpenGL qui permettent un

40

rendu vers une zone mémoire autre que celle lue par l’écran (c’est bien de là que proviennent les

problèmes), mais cette solution aurait rendu la VRLib dépendante d’un matériel trop spécifique,

car ces extensions sont encore récentes et pas forcément supportées sur toutes les cartes

graphiques.

Je me suis donc dirigé vers l'écriture d'un outil qui lit un « vrai » fichier de police de

caractère (format TrueType, un des formats les plus répandus) contenant non seulement les

données graphiques des glyphe, mais aussi des informations sur leurs organisations

typographiques (espacement, alignement vertical, etc.). Cet outil génère ensuite un fichier binaire

décrivant en détail les glyphes : l’image associée à un glyhe munie de ces informations

typographiques. L'autre avantage de cette méthode est la possibilité de générer des fichiers

polices de caractères avec des glyphes de taille arbitraire : en effet, le format TrueType enregistre

les glyphes sous formes vectorielles (i.e. ils sont définis de façon continue), alors qu'avec

l'ancienne solution, il était délicat d'obtenir des glyphes de grande taille et de bonne qualité, leur

représentation étant dès le départ discrète (une image).

En plus de la génération d’un fichier de glyphes à partir d’une police au format

TrueType, j'ai apporté un certain nombre d'améliorations à l'affichage des glyphes. Un glyphe

contient en fait une information de transparence plus qu'une image : si une zone du glyphe est

noire, elle est totalement transparente, si une zone est blanche, elle est totalement visible. Cette

solution permet d'attribuer des couleurs aux glyphes à la volée grâce au mécanisme de mélange

des couleurs d'OpenGL : l'utilisateur spécifie une couleur, et OpenGL génère des dégradés à

partir de cette couleur et de la transparence des pixels des glyphes. Les versions initiales ne

permettaient que la spécification d'une couleur, invariable en fonction de l'éclairage. La nouvelle

version permet toujours cette fonctionnalité (qui peut être utile), mais aussi d'associer un

matériau (i.e. une couleur calculée en fonction de certains paramètres optiques : les composantes

ambiantes, diffuses et spéculaire) aux glyphes.

En résumé, le travail que j’ai fourni sur les polices de caractères a grandement amélioré

l’affichage de texte dans la VRLib, tout en permettant l’utilisation, après conversion en un fichier

de glyphes, de n’importe quelle police (au format TrueType) et de taille arbitraire : il est possible

de contrôler précisément la résolution de nos glyphes, et limiter ainsi l’apparition d’artefacts

visuels dus à une forte pixellisation d’un glyphe.

2.2.2 Séparation géométrie / comportement

Une problématique très intéressante soulevée par Ludovic Sterberger était la séparation

totale de la géométrie (son apparence) d’un widget et de son comportement. Par exemple, tous

les menus ont le même genre de comportement : ils servent à explorer un arbre d’options en

affichant un certain nombre d’options ou en déroulant un autre menu. Par contre, ils diffèrent

fortement par leurs apparences : menus WIMP, combo boxes, menus 2D ½, etc. Pour un

concepteur d’interfaces, cette problématique est importante, car il n’aurait à concevoir qu’un seul

comportement pour toutes ces classes de menus, limitant ainsi le travail à fournir et les chances

d’avoir un comportement incohérent du à une erreur de programmation. De plus, répondre à la

problématique de la séparation géométrie / comportement des widgets permettrait à un utilisateur

non informaticien de concevoir l'apparence du widget, laissant le soin à un informaticien

d'implanter le comportement du widget.

Cette problématique de la séparation géométrie / comportement m’a beaucoup intéressé,

41

et j’ai proposé à Ludovic Sternberger une solution partielle à ce problème : plutôt que de décrire

l’apparence de nos widgets 3D dans le code source de la VRLib, et obliger un concepteur à

modifier la source pour modifier l’apparence d’un widget, pourquoi ne pas utiliser les objets 3D

générés par un modeleur ? Nous nous sommes rapidement rendus compte que cette proposition

impliquait d’autres problèmes qu’il fallait résoudre, et qui seront évoqués dans la section 2.2.2.3

sur les points d’ancrage.

Tout d’abord, je devais concevoir une structure de données efficace et compatible avec

les modeleurs pour représenter et afficher des maillages (objets 3D dans le sens usuel) dans la

VRLib. Puis, j’ai implanté le chargement de maillages dans cette structure à partir de formats 3D

répandus. Enfin, j’ai proposé l’utilisation de points d’ancrage pour permettre à un concepteur de

spécifier à la VRLib où placer les widgets fils ou les zones de texte d’un widget conçu avec un

modeleur 3D.

2.2.2.1 Représenter des objets 3D

Le but était pour moi de concevoir une structure de données compatible à la fois avec

OpenGL et les formats exportés par les modeleurs, et ceci avec une contrainte en terme de

performances. J’ai mis à l’œuvre mes connaissances des modeleurs 3D pour faire ressortir les

éléments communs et les différences entre les différents formats, pour identifier les

fonctionnalités dont aurait besoin ma structure :

• Sommets du maillage déclarés dans un tableau et polygones décrits par indexage de ces

sommets : permet la compatibilité avec une structure plate, qui décrirais les sommets des

polygones explicitement comme un triplet, comme l’illustre la figure 2.4.

• Possibilité d'assigner un matériau différent sur chaque face : permet la compatibilité

maximale : si un format ne supporte pas cette fonctionnalité, on peut quand même lire un

objet de ce format (l’inverse ne serait pas vrai)

• Possibilité de définir des sous-objet de l'objet principal, améliorant ainsi la lisibilité de

l'objet lors de sa modélisation et le nommage des sous-objets, pour disposer d’un moyen

de sélectionner une zone particulière du widget (i.e. un moyen simple de savoir sur quel

sous-objet l'utilisateur vient de cliquer). On verra plus tard que cette fonctionnalité est

vitale.

• Performance : possibilité d’utiliser les méthodes d’affichage performantes disponible sur

la carte graphique. On distingue le rendu direct, qui envoie à la carte graphique les

primitives de dessin de l’objet à chaque affichage de celui, et les rendus optimisés qui se

basent sur un unique envoi de ces primitives. Dans les deux cas, celles-ci sont stockées

dans une zone mémoire avant d’être traitées pour l’affichage : donc tant que l’objet ne

change pas de géométrie, on n’a pas besoin de renvoyer ces primitives à la carte, on peut

l’afficher en accédant directement à cette zone mémoire. l’utilisation de la mémoire de la

carte graphiques contenant les primitives.

42

m_objects

0

n

m_polygons

i

0

m

k

0

p1

p2

p3

l

m_verticesm_objects

0

n

m_polygons

i

0

m

k

0

p1

p2

p3

l

m_vertices

Fig. 2.4 : Description des indirections dans la classe mm ::Mesh (maillage). Cette classe

contient un tableau de sous objets. Chaque sous objet contient entre autres une liste de triangles. Chaque triangle index 3 sommets déclarés dans un tableau. Chaque sous objet possède sa

propre liste de sommets.

On notera ne gère en l’état que des maillages triangulaires, ce qui n’est pas très gênant

dans la mesure où la plupart des modeleurs offrent la possibilité de trianguler un maillage

polygonal : cette limite est due à la garantie de planarité d’un triangle. En effet, la plupart des

modèles d’illumination utilisés pour le rendu présument qu’ils ne manipulant que des polygones

parfaitement plans pour des raisons d’optimisation, et produisent des incohérence visuelles si

tous les polygones du maillage ne sont pas parfaitement plan : l’utilisation de maillage triangulé

peut donc se voir comme une garantie de cohérence visuelle.

2.2.2.2 Importer des objets 3D de modeleurs

Une fois le problème de la représentation d'un objet 3D résolu, il était clairement

nécessaire « d'ouvrir » cette représentation sur le monde. Il s'agissait d'écrire un chargeur d'objets

3D décrits dans les formats les plus courants : le 3DS et l'OBJ. Le choix de ces formats a été

justifié par le fait que l’immense majorité des modeleurs ou applications 3D peuvent exporter

leurs objets dans ces deux formats, et ce choix permettait d'éviter « l'enfer des formats d'objets

3D » et les convertisseurs associés. Il aurait été possible de développer d'autres formats (on peut

penser au VRML, très utilisé dans le cas d'un objet visualisé par une application distante de la

machine où est stocké l'objet), mais l'apport en fonctionnalité supplémentaire aurait été minime.

• 3DS : ce format binaire proposé Autodesk en 1989 en même que son logiciel de

modélisation et rendu 3D Studio, sous DOS. Le logiciel a évolué depuis, après avoir

changé de propriétaire (AutoDesk) et de système d'exploitation (Windows), pour devenir

3D Studio MAX. Les tarifs de 3D Studio le destine à des professionnels, ce qui n'a pas

empêché le format 3DS de se démocratiser et d'être bien maîtrisé, généralisant ainsi le

format grâce à de nombreux convertisseurs d'objets 3D : ce format a été conçu pour être

souple et assurer une compatibilité ascendante. Enfin, il ne gère que les maillages

triangulaires.

43

• ASE : ce format correspond à une version texte du 3DS. Il est apprécié justement parce

qu'il est facile à lire, malgré le défaut des formats de ficher en mode texte qui est leur

rapport données décrites / taille du fichier assez peu intéressant.

• OBJ : ce format est issu des spécifications de SGI, et est probablement un des formats les

plus connus. Il est en mode texte, et propose une représentation aussi compacte et lisible

que possible des données géométriques, et supporte la plupart des fonctionnalités des ses

concurrents (définition éventuellement explicite des normales, des coordonnées de

texturage, description des faces pour indexage de points, etc.)

Une fois ces pré-requis remplis, il devient possible d'écrire la géométrie d’un widget avec

la plupart des modeleurs d’objets 3D disponibles. Le mécanisme de nommage de sous-objets

permet d'attribuer des zones de sélection : par exemple un widget de type fenêtre contiendra un

sous-objet représentant une barre de titre sur laquelle on peut cliquer pour déplacer la fenêtre, un

bouton pour fermer cette fenêtre, etc.

2.2.2.3 Notion de point d'ancrage

Une fois le problème de la description complète d’un widget dans un modeleur 3D, il se

pose alors la question du placement des zones de textes : en effet, la géométrie des widgets

devenant arbitraire, la VRLib ne peut plus savoir où placer le tire de la fenêtre, par exemple. De

plus, rien n’empêche la géométrie du widget d’évoluer dans le temps, dans le cadre de widgets

animés notamment. Dans le vocabulaire de la VRLib, il s'agit de déterminer un point d'ancrage.

La solution que j'ai proposée repose sur les mécanismes de nommage de sous objets proposés par

tous les modeleurs dignes de ce ne nom. La solution consiste à nommer de façon précise un sous-

objet représentant le point d’ancrage, permet ainsi à la VRLib de différencier un point d’ancrage

d’un sous-objet « normal ».

Ce sous-objet est en fait un simple triangle. Sa normale définit une direction : c'est la

normale souhaitée du plan portant le texte. Il s'agit alors de calculer une matrice de

transformation à appliquer à la zone de texte (représentée comme une suite de quadrilatères

texturés avec des lettres). Cette matrice se calcule en se rendant compte qu'on cherche une

transformation qui fait passer le repère local de la zone de texte (x1, y1, z1) au repère défini par

(x2, y2, z2). On construit dans un premier un quaternion (une méthode robuste d'expression d'une

rotation) à partir de z1 et de la normale z2 du triangle. On convertit ensuite ce quaternion en une

matrice exprimant la rotation, et on modifie cette matrice pour lui rajouter la translation qui

amène de l'origine du repère local du widget au barycentre du triangle : ceci nous permet

d'exprimer notre point d'ancrage à l'aide d'une matrice de transformation 4x4.

Cette méthode est une solution partielle au problème de la séparation géométrie /

comportement des widgets, mais elle donne des résultats satisfaisants. Je l’ai choisi car elle

permettait de conserver un maximum de l'orientation normale d'un texte (plus ou moins face à

l'utilisateur) tout en définissant la rotation de façon robuste. Les quaternions évitent le classique

problème du gimbal lock (blocage de cardan, qui a visiblement beaucoup gêné la NASA à une

époque [Sur61]) lié à l'expression d'une rotation à l'aide des angles d'Euler, qui définissent une

rotation comme la composition des 3 rotations autour des axes x, y et z. Ce blocage des contrôles

de la rotation intervient car, après avoir appliqué une première rotation, on a également fait

pivoter tout le repère. Les rotations suivantes peuvent littéralement être bloquées si cette

première rotation est de grande amplitude.

44

Il est donc maintenant possible de décrire la géométrie (au sens large : apparence

visuelle, mais aussi de ses zones de texte, ou avec une méthode similaire en tous points, du

placement de ses fils) d’un widget dans son intégralité à l’aide d’un modeleur 3D. De plus, cette

solution permet de changer à la volée la géométrie (apparence + zones de texte + placement de

ses fils) d’un widget. Ce changement peut être du au chargement d’un autre maillage

représentant le widget, soit à l’application d’un modèle de déformation (pour obtenir une

animation par exemple) : il suffit alors de déformer les triangles représentant les points d’ancrage

comme si ils faisaient partie du maillage représentant l’apparence du widget.

Fig. 2.5 : Démonstration d’un widget défini par un objet 3D. Les deux sphères représentent la

géométrie d’une fenêtre, comme celle à droite. Le triangle plus sombre de la grosse sphère et le repère associé définissent le point d’ancrage du texte, qui a été légèrement surélevé pour des raisons de lisibilité. On distingue des boutons de la fenêtre originale qui n’ont pas de points

d’ancrage définis.

45

3. VRSTIGMA VRSTIGMA est l'application concrète de ce stage. Il s'agit d'implanter en environnement

immersif un modeleur topologique d'objets 4D dédié à l'animation, en se basant sur le travail de

Sylvain Brandel sur ce thème [Bra00]. Je parlerais dans une première partie d’animation par

objets 4D, en évoquant tout d’abord le modèle de données utilisées pour représenter les objets et

leur utilisation pour produire des animations, pour ensuite parler du travail de Sylvain Brandel

sur un modeleur d’objets 4D.

Dans la partie suivante, je parlerais de VRSTIGMA, en évoquant le matériel et le logiciel

utilisés lors du stage, avant d'établir un classement des tâches exécutées dans VRSTIGMA. Je

détaillerais également l'interface de VRSTIGMA, pour mettre en évidence les aspects classiques

de la problématique du développement d'applications en réalité virtuelle.

3.1 Modélisation d’objets 4D pour l’animation Nous verrons dans un premier à quelle problématique répond la modélisation, avant

d’évoquer le modèle particulier que j’ai utilisé dans le cadre de ce stage.

3.1.1 Modélisation

Le but de la modélisation est de fournir une représentation d'une classe aussi large que

possible (idéalement) d'objets.

En visualisation « ludique » (le seul but est d'afficher un objet), le modèle classiquement

choisi est d'approximer la surface de l'objet par un ensemble discret de triangles. Cette solution

est traditionnellement choisie pour sa simplicité et son adéquation avec le matériel dédié à

l'affichage, qui est généralement optimisé pour traiter des triangles.

Mais dans un cadre visualisation / modélisation / simulation scientifique, ce modèle est

très insuffisant. D'une part, tel quel, il ne conserve pas de relations d'adjacence, i.e. à partir d'un

triangle donné, on ne peut connaître ses voisins en une unique opération en temps constant. Ce

problème peut-être résolu en rajoutant pour chaque triangle des pointeurs vers ses voisins, en

différenciant éventuelle quel type d'adjacence est modélisée par pointeur : adjacence par les faces

ou par les sommets

Mais même ainsi, ce modèle est beaucoup trop réducteur : pourquoi approximer des

surfaces d'objets avec des triangles forcément ? Pourquoi pas avec des courbes paramétriques ou

des courbes de Bézier, qui ont l’avantage (pour les gens faisant de la simulation par exemple)

d'être continues?

En fait la notion la plus abstraite (et donc la plus « vraie ») est que l'on cherche en fait à

modéliser les relations entre certains constituants de l'objet : dans le cas classique, les points. En

effet la définition d'une surface par un maillage triangulaire (ou polygonal, le principe est le

même) décrit en fait les relations entre les sommets. Deux sommets sont mis en relation par une

relation d'incidence « arête », et plusieurs arêtes sont mises en relation par la relation d'incidence

« face ». On modélise en fait la topologie de l'objet.

3.1.2 Les G-cartes

Dans cette partie, nous parlerons du modèle des cartes généralisées, ou G-cartes. Elles

46

sont une extension des cartes combinatoires [Jac70] et permettent l'expression des relations

topologique entres les différents éléments de l'objet. La particularité des G-cartes est de

modéliser toutes les variétés (des objets géométriques respectant certaines conditions,

notamment sur les auto-intersections, ou l'interdiction d'avoir des arrêtes « pendantes ») de

dimensions quelconques. Je donnerais dans une première partie quelques définitions tirées de

[Lie94], puis je décrirais comment passer de la représentation de la topologie d'un objet à une

représentation géométrique de cet objet.

Avant de donner une définition des G-cartes, j’aimerai les introduire de façon plus

informelle. La figure 3.1 montre un objet composé d’une pyramide posée sur un cube. La figure

3.2.a représente la relation entre ces deux volumes disjoints par un trait épais. De même, la figure

3.2.b montre les relations entre les faces de l’objet, la figure 3.2.c montre les relations entre les

arêtes, et enfin la figure 3.2.d expose les relations entre les sommets. Ces sommets, appelés

brins, constituent l’unique élément de base de la définition des G-cartes.

Fig. 3.1 : Objet « cube et pyramide ».

a)

b)

c)

d)

Fig. 3.2 : Volumes (a), faces (b), arêtes (c) et sommets (d) de figure 3.1 disjoints.

3.1.2.1 Définition formelle des G-cartes

Nous verrons dans cette partie un certain nombre de définitions sur les G-cartes. Nous

verrons comment elles sont exprimées formellement, comment il est possible de récupérer

facilement les composantes connexes d’une G-carte, et comment la notion de connexité est

utilisée pour définir les cellules (sommets, arêtes, faces, volumes, etc.) d’une G-carte. Puis nous

verrons comment il est possible de lier la topologie d’un objet à sa géométrie grâce au

plongement. Toutes ces définitions sont tirées de [Lie94].

47

Définition 1

Une G-carte de dimension n, ou n-G-carte est un (n+2)-uplet G = (B, α0, ..., αn) tel que :

• B est un ensemble fini non vide dont les éléments sont appelés les brins ;

• α0, ..., αn sont des involutions sur les éléments de B (i.e. ∀b ∈ B, ∀i, 0 ≤ i ≤ n, (αi ◦ αi)(b)

= b) telles que :

• ∀i ∈{0, ..., n-1} est une involution sans point fixe : ∀b ∈ B, αi (b) ≠ b;

• ∀i ∈{0, ..., n-2 }, j ∈ {i + 2, ..., n}, αj ◦ αi est une involution.

Définition 2

Soit une n-G-carte G = (B, α0, ..., αn). Un brin b ∈ B est dit cousu si αn(b) ≠ b, et libre

sinon. G est dite fermée si αn est une involution sans points fixes, et ouverte sinon.

On notera que les G-cartes ne modélisent que les variétés, mais de dimension

quelconque. Un des aspects les plus séduisants de ce modèle est l'homogénéité de la

représentation des dimensions : d'un point de vue algorithmique, le traitement de variétés de

dimensions 2 est le même que pour les variétés de dimensions quelconques.

3.1.2.2 Cellules des G-cartes

Comme évoqué plus haut les G-cartes représentent les relations topologiques entre les

différents types d'éléments (cellules) de la carte. Mais de nombreux algorithmes (notamment

pour visualiser un G-carte) exigent une décomposition en cellules de la G-carte : dans le cas de la

visualisation, on veut pouvoir récupérer un ensemble de sommets, faces et éventuellement

volumes, à partir de la G-carte. La récupération des cellules d'une G-carte s'appuie sur la

définition des composantes connexes au sein de la G-carte.

Définition 3

Soit une n-G-carte G = (B, α0, ..., αn), un brin quelconque b ∈ B, et P un ensemble de

permutations de B. Nous appelons orbite de b par rapport à P l'ensemble {b' ∈ B | ∃p1 ∈ P, ∃p2 ∈

P, …, ∃pk ∈ P, avec b' = {pk ◦...◦ p2 ◦ p1)(b)}, et nous notons cette orbite < P >(b).

Définition 4

La composante connexe G' = (B', α'0, ..., α'n) incidente à un brin b est définie par :

• B' = < α0, ..., αn >(b)

• α'i est la restriction de α0 à B' pour tout i ∈ {0, ..., n}. Si B' = B alors G est dite connexe.

Définition 5

Soit une n-G-carte G = (B, α0, ..., αn).

Les cartes des cellules de G sont les (n+1) (n-1)-G-cartes G0, ..., Gn définies par Gi = (B,

α0, ..., αi-1, αi+1, ..., αn). Une composante connexe de Gi est appelée cellule de dimension i de G.

Une 0-cellule est appelée sommet, une 1-cellule est appelée arête, une 2-cellule face et une 3-

cellule volume.

Les cartes des cellules simples de G sont les (n+1) G-cartes G0, ..., Gn de dimensions

respectives 0,..., n définies par G' = (B, α0, ..., αi-1). Une composante connexe de G'i est appelée

cellule simple de dimension i de G. Une 0-cellule est appelée sommet simple, une 1-cellule est

48

appelée arête simple, une 2-cellule face simple et une 3-cellule volume simple.

Dit de façon plus informelle, pour retrouver les n-cellules d'une G-carte, on supprime la

relation αn. La figure 3.3.a montre la 2-G-carte obtenue après suppression des α0 de la 3-G-carte

représentant l’objet de la figure 3.1. Chaque composante connexe de cette 2-G-carte représente

un sommet de l'objet. Dans le même ordre d'idée, la suppression des α1 permet de retrouver les

arêtes, la suppression des α2 donne les faces et la suppression des α3 donne les volumes de la

carte.

a)

b)

c)

d)

Fig 3.3 : Sommets (a), arêtes (b), faces (c) et volumes (d) de l’objet de la figure 3.1 représenté comme une G-carte.

En pratique, on ne supprime pas les relations de la carte, on se contenter de les ignorer

lors du parcours de la G-carte, que l'on peut comme un graphe portant les brins de la G-cartes sur

ses sommets et les involutions sur ses arêtes. Une composante connexe de la G-carte est une

composante connexe de ce graphe.

3.1.2.3 Notion de plongement

Le plongement est l'opération qui permet à partir de la topologie d'un objet de récupérer

sa géométrie : un n-plongement associe aux n-cellules des valeurs dans un espace donné.

Les objets 3D tels qu'on les imagine couramment sont des surfaces plongées dans un

espace de dimension 3 : ce sont les objets que l'on utilise classiquement dans les images de

synthèse et les jeux vidéos. Dans ce cas, on fait un 0-plongment dans un espace de dimension 3 :

on associe à chaque sommet trois valeurs, en général notées x,y et z. Les arêtes sont plongées par

interpolation linéaire. Enfin, classiquement, le plongement d’une face est réduit au plongement

des différentes arêtes la constituant.

Mais on peut imaginer définir le plongement d’une arête non pas comme un simple

segment, mais une courbe paramétrée ou une courbe de Bézier (ou toute autre variante). On peut

imaginer définir le plongement surfacique en associant aux faces des carreaux de Bézier par

exemple. C'est là que l'expression « modèle topologique » prend tout son sens : formellement

une pomme et un verre ont la même topologie, et peuvent représentés par un même modèle (de

façon violente, un tétraèdre). La seule différence se trouvera dans le plongement de l'objet : on

associera aux cellules des 2 objets des plongements différents, voire les mêmes plongements (des

courbes / surfaces de Bézier), mais munis de paramètres différents.

49

Fig. 3.4 : Une G-carte représentant une face à 4 arêtes, et la géométrie obtenue en associant un

carreau de Bézier à la face.

Cette souplesse du modèle, conjuguée à la séparation topologie / géométrie, ouvre des

perspectives intéressantes dans le domaine de la visualisation : les évolutions récentes du

matériel graphique permet en effet l'implantation matérielle de modèles et d'algorithmes dédiés

au rendu beaucoup plus que la méthode employée jusqu'a aujourd'hui (l’algorithme de rendu Z-

Buffer). Ces possibilités sont évoquées dans les perspectives de ce travail.

3.1.3 Animation par objets 4D

Comme évoqué plus haut, la méthode traditionnelle pour faire de l'animation assistée par

ordinateur est le mécanisme d'interpolation entre des points clés. Mais cette technique peut

devenir très lourde et coûteuse en temps et en charge de travail dans le cas d'animations pourvues

de trajectoires complexes ou très nombreuses. Ainsi, un certain nombres de travaux sur

l’utilisation d’objets 4D pour produire une animation 3D ont été proposés : on peut citer les

travaux de Nicolas Dubreuil [Dub95] sur l’animation par déformation à temps constant, Fabrice

Aubert pour l’animation par déformation à temps non constant [Aub99] ou encore les travaux de

Sylvain Brandel [Bra00] sur la conception du modeleur 4D dédié à l’animation.

L’animation 4D se base sur la notion de coupe d'un objet par un hyperplan pour arriver à

ses fins. En effet, une animation d'objets de dimensions n peut être exprimée comme un objet de

dimension n+1 muni d'un hyperplan de coupe (de dimension n). Ce plan de coupe se déplace le

long d'une trajectoire.

plongement

50

(a) (b) (c)

Fig. 3.5.a : La coupe par un hyperplan pour faire de l’animation

L'idée est de proposer la construction d'objets 4D par différentes méthodes : en utilisant

des primitives 4D (hypercube, hypertétraèdre) ou par construction d'objets 4D à partir d'objets de

dimension < 4. C'est le rôle d'un certain nombre d'opérations, tel que l'opération d'extrusion ou

de construction par révolution. Les animations sont donc formellement définies comme les

coupes par un hyperplan des objets ainsi construits.

Fig. 3.6 : animations 2D obtenues par calcul des intersections successives d’objets 3D avec un

plan se déplaçant orthogonalement à un vecteur représentant le temps.

51

Fig. 3.7 : Une représentation d’un objet 4D (obtenu révolution d’une sphère) et la séquence de

coupes par un hyperplan associée. L’animation ainsi obtenue est de dimension 3.

De façon théorique, le modèle marche très bien, mais se heurte aux limitations de notre

cerveau, et sa quasi-incapacité à percevoir des objets de dimension > 3. Par un effort

d'imagination, on peut essayer de se représenter la quatrième dimension dans des cas particuliers

comme un déplacement ou une homothétie (c'est d'ailleurs le sens donné à la représentation

classique de l'hypercube) en fonction du temps. Mais cette représentation est, au mieux,

incomplète voire même fausse dans le cas général : il faut systématiquement projeter l'objet dans

des dimensions humaines (en général dans l'espace ou dans un plan) pour pouvoir le visualiser.

3.1.4 STIGMA

STIGMA, pour Space-Time Interpolation for the Geometric Modeling of Animations, est

le modeleur d'objets 4D conçu et développé par Sylvain Brandel durant son travail de thèse

[Bra00]. L'objectif de ce modeleur était double : d’une part fournir des outils de construction

d’objets 4D, et d’autre part proposer des techniques de visualisation de ces objets 4D.

Le principal problème des objets 4D étant leur visualisation, une approche classique et de

travailler sur des objets 3D et de procéder ensuite par analogie pour essayer de prévoir ce qui se

passera à la dimension supérieure. Les modeleurs 3D classiques proposent généralement 3 vues

des objets, qui sont les 3 projections sur les plans orthotropes (XY, XZ et YZ) en plus d’une vue

3D en projection parallèle ou perspective. Pour visualiser les objets 4D, STIGMA propose 4

vues, qui sont les 4 projections sur les espaces orthotropes (XYZ, XYT, XZT et YZT), ainsi

qu’une projection parallèle ou perspective des objets 4D entiers. Il est également possible de

visualiser une projection 2D des objets 4D, ainsi que la séquence d’animation résultante.

Finalement, l’animation peut être déroulée et contrôlée par un simple curseur décrivant la

position de l’hyper plan d’intersection avec l’objet 4D.

STIGMA comporte de nombreuses opérations de construction d’objets 4D, des primitives

52

3D et 4D, par exemple cube, hypercube, tore et hypertore, ainsi que des opérateurs de

changement de dimension. Augmenter la dimension peut être effectué par l'extrusion ou

l’épaississement, une opération permettant d’ajouter une dimension, en construisant un objet 3D

ou 4D contrôlé par un graphe, dont l'objectif est de contrôler précisément les modifications

topologiques au cours d'une animation. L’opérateur de diminution de dimension sert à extraire

l’animation d’un objet espace-temps : une animation 3D provient d’un objet 4D, une animation

2D d’un objet 3D.

La première version de STIGMA a été écrite en utilisant une librairie de G-cartes

développée par Yves Bertrand pour le modeleur à base topologique Topofil. Cette version de

STIGMA a été développée en langage C, sur station de travail graphique SGI O2 avec le système

d’exploitation Irix, en utilisant le contrôle d’application Motif, s’appuyant directement sur X11.

STIGMA a été entièrement réécrit par Jonathan Riehl, élève ingénieur de l’Université

Technologique de Belfort – Montbéliard, avec des outils et plateformes modernes : langage C++,

contrôle d’application Qt (une API de conception d'interfaces graphiques, i.e. VRLib, mais en

2D), nouveau noyau de G-cartes développé au SIC à Poitiers. Ce travail a permis d’obtenir un

logiciel fonctionnant indifféremment sous Windows et Linux, et m'a servi de base à

VRSTIGMA.

3.2 VRSTIGMA VRSTIGMA est la version en environnement immersif de STIGMA. En l'état,

VRSTIGMA supporte toutes les créations de primitives 3D et 4D (pas de manipulation bas

niveau des coordonnées d'un sommet par exemple) et l'affichage d'une animation calculée par

intersection d'une G-carte et d'un hyperplan. VRSTIGMA ne supporte pas les opérations

d'extrusion, mais les choix d'implantations permettent de rajouter rapidement ces opérations si on

le souhaite. Mais le but de ce stage était d'évaluer l'apport de la réalité virtuelle à l'animation par

objets 4D.

Pour des raisons similaires, l'opération de sauvegarde d'une G-carte dans un fichier xml

n'est pas supportée pour le moment, mais le chargement d'une G-carte l'est. Ceci est du à une

dépendance malheureuse entre le chargement des fichiers xml et la librairie graphique utilisée

par la deuxième version de STIGMA. Concrètement, cette version utilise le parseur de fichiers

xml de Qt. Mais il était hors de question d'introduire une dépendance à Qt dans VRSTIGMA :

j'ai donc réécrit le chargement d'un fichier xml décrivant une G-carte à l’aide du parseur de

fichiers xml xerces, afin de pouvoir importer dans VRSTIGMA les G-cartes exportées depuis la

deuxième version de STIGMA et visualiser en environnement immersif les animations associées

à ces G-cartes.

3.2.1 Matériel

La matériel utilisé lors du développent de VRSTIGMA était le suivant

- Cluster de 3 PC : un « contrôleur » et deux « afficheurs » chargés du rendu (contextes

graphiques)

- un workbench Consul du constructeur Barco pour l’affichage

- Suivi optique assuré par 4 caméras.

53

3.2.2 Logiciel

D’un point de vue logiciel, VRSTIGMA repose sur des composants déjà évoqués, et qui

s’organisent comme indiqué sur la figure 3.8.

Fig. 3.8 : L’organisation logicielle de VRSTIGMA.

3.2.3 Interface de VRSTIGMA

Nous allons examiner les différentes solutions utilisées dans VRSTIGMA pour accomplir

les différentes tâches nécessaires à la création et la visualisation d'une animation générée à partir

d'un objet 4D.

Ces tâches se résument principalement à des interactions avec l’interface, qui rentrent

dans les catégories de la désignation, de la manipulation et du contrôle du système. On peut citer

comme exemples de tâches reposant sur l’interface :

• La création d’objets 3D ou 4D

• Les opérations de base d’une application : réinitialisation de la scène, ouverture et

sauvegarde de fichiers, sortie de l’application, etc.

• La modification de paramètres de visualisation, comme la projection désirée pour

visualiser l’objet 4D comme un objet 3D, le calcul de la coupe de la scène par un hyper

plan, ou le mode de rendu de l’objet.

• La modification de l’hyperplan de coupe, qui permet l’affichage de l’animation, et qui est

confiée à un widget de type curseur (slider). On trouve également le déplacement des

objets modélisés, qui entre a priori dans la catégorie Manipulation. Mais on peut aussi le

voir comme une forme de navigation dans la scène (déplacer l’utilisateur est équivalent à

déplacer les objets). Je classerai donc cette action plus dans la catégorie Navigation

puisqu’elle permet réellement de se promener dans et autour de l’objet.

a) Navigation

Par mouvements de l’utilisateur : sa tête est suivie. Cette forme de navigation est limitée

en amplitude, et est appliqué à toute la scène (G-cartes et interface). Elle permet également de

tourner autour de la scène, et apporte un grand confort à la visualisation.

Par « attache dans le vide » (grab the air) : un bouton sur périphérique matériel de type

flystick est pressé et tenu enfoncé. Sa position au moment de l’appui sur le bouton est enregistrée

et chaque mouvement fait avec le flystick est appliqué aux G-cartes (la scène sans l’interface)

avec un facteur d’homothétie suffisant pour éviter de devoir faire des mouvements de trop

VRSTIGMA

VRLib

Système d’exploitation

VRJuggler STIGMA

OpenGL

54

grande amplitude. D'un point de vue formel, cette manipulation des G-cartes par attache dans le

vide est à la frontière entre la navigation et la manipulation des G-cartes. Une fois le bouton

relâché, le périphérique retrouve sa fonction première d’outil de désignation

b) Désignation

Dans VRSTIGMA, la désignation se fait à l’aide d’une métaphore de rayon laser virtuel

appliquée à un flystick. Cette métaphore a été préférée à des sélections via des gants de données

pour différentes raisons. Premièrement la désignation par préhension se prête moyennement aux

environnements réalité virtuelle type écrans géants à cause du problème déjà évoquée de

l'occlusion de la scène. De plus, un modeleur est l'exemple typique où l'on aimerait pouvoir

facilement sélectionner un objet distant, ce qui implique d'utiliser une métaphore de type GoGo

en conjonction avec les gants. Or Bowman [BH97] évoque la préférence (faible, certes) des

utilisateurs novices pour des méthodes de désignation par lancer de rayon.

Ainsi, la désignation et la manipulation d'objets dans VRSTIGMA reposent sur la

métaphore du rayon laser. Cette solution a été retenue pour sa précision, sa capacité à

sélectionner des objet éloignés et à ne pas masquer le champ de vision de l’utilisateur, son coté

naturel et surtout la fatigue moindre occasionnée : assez naturellement, on garde le flystick près

du corps pour faire de la désignation (comme les cowboys qui tirent au pistolet « à la hanche »

lors des duels dans les westerns), cette solution limite la fatigue et ne gêne pas la vision de la

scène. Alors qu’une sélection par préhension oblige l’utilisateur à lever la main dans la direction

de l’objet à sélectionner, masquant une plus grand partie de la scène et, surtout, mettant

l’utilisateur dans une position inconfortable si l’objet à sélectionner est trop haut, car il oblige

l’utilisateur à lever les bras, ce qui fatigue très rapidement les épaules. Cet obstacle peut

néanmoins être contourné en plaçant tous les éléments souvent manipulés par préhension

(typiquement l’interface) à hauteur de hanche et à l’avant de la scène, ce qui n'était

malheureusement pas possible sur le workbench utilisé lors de ce stage, dans la mesure où

l’écran du bas était en panne.

55

(a)

(b)

(c)

Fig. 3.9 : En (a) une interface reposant sur la préhension et des objets placés trop hauts entraînant une fatigue de l’épaule. En (b) une interface bien conçue reposant sur la préhension : l’utilisateur n’a pas à lever les bras. En (c) une désignation par laser : fatigue moindre quelque soit la position de l’interface, mais mouvements parasites de la main amplifiés par la distance et

problème de la taille de l’interface.

Enfin, il est évidemment possible de mélanger les outils d’interaction, et de tenir dans une

main un flystick (ou un gant capable de lancer un rayon laser) et faire de la désignation sur les

objets (et moins sur l’interface), tandis que l’autre main porte un gant et sert à faire du contrôle

d’application, en associant ce gant avec un CCube ou un RingMenu, gardant ainsi le meilleur des

deux mondes (précision de sélection ET contrôle d’application ergonomique).

c) Manipulation

La manipulation d’effectue à l’aide d’un rayon laser : elle est centrée utilisateur pour

l’interface (écrite avec la VRLib). Les objets de la scène peuvent être déplacés à l'aide de

l'attache dans le vide évoquée plus haut. La manipulation centrée utilisateur pour l’interface a

l’avantage de garder les widgets plus ou moins orientée vers l’utilisateur. La critique souvent

formulée à l’égard des manipulations centrées utilisateur est leur difficulté à faire tourner l’objet

sur lui-même. Cette particularité est souhaitable, à moins que l’arrière de la fenêtre comporte elle

56

aussi des widgets, ce qui ne semble pas être une très bonne solution, puisqu’une partie de

l’interface serait alors cachée à l’utilisateur, transformant la tâche de sélection en un jeu

d’exploration (« est-ce que par hasard l’option que je cherche depuis si longtemps ne serait pas

derrière la fenêtre ? »). Néanmoins, nous verrons dans les perspectives qu'un widget dans la

manipulation est centrée objet et possédant des parties cachées peut présenter un intérêt.

d) Contrôle du système

Dans VRSTIGMA, le contrôle d’application est confié à la VRLib, qui propose

l’implantation de toute la famille des widgets 2D classiques (fenêtres, menus, boutons) en

environnement RV : c’est ce qu’on appelle des interfaces 2D ½. Les interfaces 2D ½ ont

l’avantage d’êtres connues et maîtrisées par tous les utilisateurs de PC classiques. De plus,

certains widgets 2D comme les menus se prêtent relativement bien à un environnement

immersifs pour leurs capacités à regrouper beaucoup d’informations en un espace réduit. Il faut

simplement ne pas oublier les règles d’ergonomie, comme éviter de mettre plus de 10 sous

élements dans un menu, sinon ils deviennent très inconfortables : on oublie l’organisation

menus/sous-menus si elle est trop lourde, obligeant l’utilisateur à explorer toute l’arborescence à

chaque fois qu’il veut sélectionner un élément du menu.

Néanmoins, des wigdets 3D comme le RingMenu et le CCube ont clairement démontré

que la plus grande force des interfaces 2D ½ est leur familiarité : un utilisateur totalement novice

en informatique préférera une interface 3D adaptée à la RV à une interface 2D ½ , pas forcément

adaptée et qu’il ne connaît pas.

Ainsi, un widget dédié à une tâche particulière en RV a été développé pour VRSTIGMA.

Dans un premier temps, nous verrons à quel problématique doit répondre ce widget dédié et nous

analyserons le cahier des charges de ce widget. Puis, je décrirai ce widget et son fonctionnement.

Conception d’un widget dédié

Analyse des besoins

Dans un modeleur classique, l'écran est divisé en « vues » (viewports). Typiquement, on

trouve 4 vues : une vue perspective où l'utilisateur peut tourner autour de l'objet et l'examiner en

détail pour se faire une idée de l'impact de modifications sur l'objet, et 3 vues généralement

utilisées pour la modélisation (par exemple, les insertions ou déplacements de points) : chacune

de ses vues correspond à une projection sur un plan (dans un modeleur 3D, classiquement, on

trouve la projection sur le plan XY, celle sur YZ et enfin celle sur XZ). Ces vues permettent une

manipulation plus fine et précise des cellules de l'objet que dans une vue perspective. STIGMA

étant un modeleur sur écran classique, on retrouve bien ces 4 vues. La particularité de STIGMA

étant de modéliser des objets 4D, on se rend bien compte que la seule différence réside dans la

définition des plans. Ce sont des hyperplans (i.e. des objets de dimension n-1), et dans le cadre

de la 4D, ces hyperplans sont de dimensions 3. La vue « perspective » correspond à une

projection de l'objet 4D dans l'espace XYZ, et les autres vues correspondent aux projections dans

les espaces XYT, XZT et YZT.

Il était donc tentant d'appliquer ce modèle tel quel à VRSTIGMA : cette fois on travaille

sur un écran 3D, et l'espace va être divisé non plus par des droites comme sur un écran 2D, mais

par des objets de dimension supérieure : des plans. Mais après réflexion, cette idée a été écartée,

car cette division de l'espace de travail 3D n'est pas très agréable, et même en utilisant des plans

translucides pour diviser l'espace de travail, cette solution nuit énormément à la lisibilité de la

57

scène. Pourtant, il était hors de question d'abandonner cette possibilité de visualiser dans les

autres vues les changements apportés sur l'objet dans une vue donnée.

Un widget dédié : viewportWidget

L'idée fondamentale est donc de conserver une miniature de chaque vue dans un widget

dédié à cette tâche. La projection de l’objet 4D dans une des vues est calculée, puis l’objet ainsi

obtenu est centré et mis à l’échelle afin d’être dessiné dans un cube en fil de fer. On associe en

fait ce cube à la boite englobante (i.e. le plus petit espace contenant tout l’objet) de la G-carte

que l’on représente dans la miniature, comme l’illustre la figure 3.10.

Ainsi, on garde cette possibilité de visualiser de façon interactive les changements

apportés à l'objet dans les différentes vues, sans trop remplir l'espace de travail. Enfin, il a été

nécessaire d'adapter ce widget aux contraintes matérielles. En effet, le workbench utilisé lors du

stage possède deux écrans : la présence de deux écrans permet, entre autres, d'agrandir l'espace

de travail. Or, l'écran du bas est en panne depuis un certain temps : il était donc impossible

d'utiliser ce viewportWidget comme je le voulais, en le disposant sur l'écran du bas, plus proche

de l'utilisateur et donc plus lisible et moins fatiguant à atteindre. J'ai donc décidé d'attacher ce

widget à la fenêtre principale de VRSTIGMA : le viewportWidget a alors cette fenêtre comme

père, et subit toutes les transformations géométriques (en particulier les déplacement, mais aussi

les rotations) appliquée à la fenêtre. Cette solution m'a permis de placer le viewportWidget dans

l'espace de travail de façon optimale en fonction de l'espace dont je disposais : la fenêtre

principale est supposée être toujours visible, car elle regroupe des opérations importantes de

l’application et il me semblait utile de profiter de cette propriété. Concrètement, le

viewportWidget est disposé au dessus de la barre de titre de la fenêtre principale, afin de ne pas

gêner son déplacement.

(a) (b)

Fig. 3.10 : en (a) la solution idéale de placement des viewportWidgets (cubes gris) sur un workbench à deux écrans et en (b) la solution intermédiaire : greffer les widgets à la fenêtre

principale

58

Le bilan de l’apport de ce widget dédié est le suivant : dans un premier temps, on profite

de la réalité virtuelle pour concrétiser la notion de projection. En effet, un utilisateur novice peut

comprendre le concept de la projection de façon intuitive et immédiate : il se rend compte par

lui-même que projeter un objet de dimension n dans un espace de dimension m, avec m<n,

revient à simplement visualiser l’objet en « oubliant » un certaine nombre (n-m) de dimensions

(dans le cas d’un projection parallèle). Outre l’apport pédagogique, un utilisateur confirmé dans

la modélisation appréciera de pouvoir visualiser les différentes projections d’un objet, et les

effets des manipulations de l’objet dans les différentes projections.

Division judicieuse de l’interface

En plus de ces widgets dédiés, VRSTIGMA est construit d’une façon classique, dans le

sens ou elles repose sur de nombreux widgets 2D ½ : comme illustré la figure 3.12, l’application

contient une fenêtre principale et des boutons, qui contiennent les opérations de bases, comme

réinitialiser la scène, charger ou sauver un objet, un menu pour accéder aux paramètres des vues

(viewports) ou quitter l’application. Elle contient également une fenêtre avec un menu contenant

toutes les primitives et une fenêtre dédiée à l’animation, contenant juste un curseur pour faire

varier le temps : c’est sûrement la fenêtre la plus caractéristique de VRSTIGMA (cf. figure 3.13).

L’intérêt est de proposer une division suffisante de l’interface, offrant une certaine

souplesse et une modularité permettant à l’utilisateur d’optimiser de façon ponctuelle son champ

de vision en déplaçant les éléments de l’interface qui le gêne dans sa perception de la scène. Il

faut néanmoins veiller à garder cette division de l’espace raisonnable et ne pas multiplier de

façon inutile le nombre de fenêtres, ce qui réduirait à néant l’effort de modularité : en effet si

après une action sur l’objet, l’interface bloque la vue, il est dommage de devoir sélectionner puis

déplacer un nombre trop important de fenêtres (qui de plus boucheraient la vue de par leur

nombre) pour se sentir à nouveau à l’aise. On retrouve la problématique classique du choix d’une

granularité adaptée. Il est intéressant de noter qu’une interface « oppressante » est déjà

désagréable en 2D, où on contrôle pourtant au pixel près la position et la taille d’un widget),

mais ce phénomène d’oppression est encore accru en réalité virtuelle, en particulier à cause de la

faible résolution (nombre de pixels / taille de l'écran) des systèmes de projection associé au

phénomène de lissage des pixels, du à la rétroprojection de l’image sur un écran translucide.

59

Fig. 3.12 : Les deux fenêtres de VRSTIGMA

Fig. 3.13 : VRSTIGMA résumé en une image : visualisation d’un animation 2D générée à partir

d’un tore et d’un plan de coupe.

61

Conclusion et perspectives

Conclusion En conclusion, je dirais que ce stage m’a permis de familiariser de façon concrète avec

les problématiques de la réalité virtuelle évoquées en cours de Master 2 Recherche. De plus le

travail bibliographique m’a permis d’affûter mes connaissances dans des domaines distincts,

comme la modélisation topologique avec les G-cartes, la modélisation et la visualisation d’objets

de dimension > 3 ou la réalité virtuelle.

Pour répondre à la problématique du stage, je dirais que la réalité virtuelle apporte un réel

plus à l'animation 4D. Cette amélioration tient, dans un premier temps, à la vision stéréoscopique

des G-cartes utilisées pour la production d'une animation. Le suivi des mouvements de

l'utilisateur apporte également un réel confort : pour visualiser la G-carte (ou l'animation

associée) il suffit à l'utilisateur de se déplacer, sans avoir à utiliser un widget particulier. Ce point

améliore grandement l'accessibilité de STIGMA pour un utilisateur novice dans le domaine de la

modélisation. De plus comme nous l'avons vu, la conception de widgets dédiés peut, si cette

conception est guidée par des besoins bien définis, améliorer de façon impressionnante

l'ergonomie d'une application en réalité virtuelle.

Perspectives De plus, l'utilisation d'objets 4D pour décrire des widgets animés ouvre des perspectives

intéressantes. En effet, les G-cartes possèdent un opérateur défini comme un produit cartésien

[DBB+98] [Mos98] : on peut multiplier un objet de dimension n par un objet de dimension m

pour obtenir un objet de dimension n+m. On peut appliquer cette définition à un widget : on

multiplie le widget (qui est dimension 3) avec une courbe (de dimension 1). On obtient ainsi un

objet 4D représentant le déplacement du wigdet le long de la courbe. Cette propriété est très

intéressante dans le cadre de la réalité virtuelle, dans la mesure où cette courbe peut être saisie de

façon simple et intuitive au flystick. Dans l'absolu, il serait possible d'en faire autant avec les

techniques d'animation par points clés, mais les G-cartes offrent un cadre bien plus formel et

mieux maîtrisé (i.e. spécifié et prouvé).

Fig. 4.1 : Définition d’une animation 3D par un objet 4D obtenu par produit d’un widget

(dimension 3) et d’une courbe (dimension 1).

Enfin, une autre perspective serait l’implantation de l’intégralité des fonctionnalités de

STIGMA dans VRSTIGMA, plus particulièrement les opérateurs permettant de faire gagner des

Animation

62

dimensions à un objet (extrusion, révolution, etc.), afin de faire de VRSTIGMA un modeleur 4D

complet.

Pistes Toujours dans les perspectives, la métaphore Gogo pondérée par l'accélération me semble

une piste intéressante, notamment par son côté intuitif : elle se base sur des notions physiques

connues de tous les utilisateurs, comme l’inertie, comparé aux systèmes GoGo qui l'obligent à

surveiller une jauge. Il serait intéressant d'évaluer l'apport de limiter cet apport de l'accélération

au déplacement à la seule profondeur, ou sur toutes les dimensions.

Enfin une autre piste intéressante m’a été suggérée par Ludovic Sternberger lors de

discussions sur la nécessité de différencier la dimension d’une métaphore (un interrupteur peut se

voir comme une métaphore 1D, tous les widgets 2D sont des métaphores dans un plan, etc.) et la

dimension de la représentation visuelle de cette métaphore (un interrupteur est un objet 3D). Il

serait dans ce cadre intéressant d’étudier de façon approfondie (statistiques, ergonomie, temps

moyen pour accomplir une tâche donnée) un widget 3D un peu particulier. Ce serait un cube

possédant sur chacune de ses faces une fenêtre au sens 2D du terme. Par un mouvement fait dans

une direction donnée, par exemple une « claque » sur un bord du widget, on le fait tourner dans

cette direction, révélant une autre face. On pourrait ainsi regrouper dans un même widget jusqu’à

6 fenêtres (fenêtre au sens WIMP, i.e. 2D). Il faut simplement un moyen de dire à l'utilisateur

quelles sont les noms des 5 fenêtres masquées en les nommant (« fenêtre principale », « création

d'objets », ...) et en les désignant à l'aide d'une flèche et du nom de la fenêtre.

Fig. 4.2 : Un autre exemple de widget 3D pouvant tirer parti de la proprioception.

Enfin, les G-cartes et leur capacité à modéliser des objets de dimension quelconques

conjuguée à l'évolution du matériel graphique moderne, en particulier la possibilité de faire

exécuter du code écrit par l'utilisateur (shader) suggère une perspective très intéressante pour la

Fenêtre principale

Création d’objets Aide

Option

Nouveau

Ouvrir

Sauver

Quitter

Animation Modélisation

63

visualisation de G-carte. L'utilisation d'un shader par rapport à l'algorithme historique de

visualisation en temps réel (le Z-Buffer) permet (entre autres) d'utiliser une structure de données

plus évoluée qu'un simple ensemble discret de polygones. Il semble possible de faire manipuler

directement par la carte graphique une G-carte, plutôt que manipuler un maillage polygonal

construit par le processeur central à partir de la G-carte (i.e. obtenir un support matériel des G-

cartes par les cartes graphiques). Une fois l’objet modélisé de façon matérielle comme une G-

carte, il est nécessaire de pouvoir également implanter le plongement dans la carte afin de

visualiser l‘objet. On notera que même sans shader, les cartes graphiques supportent de façon

matérielle la description et l’affichage des Splines. Mais il est possible de définir d’autres types

de plongements en utilisant les shaders, qui aujourd’hui ressemblent à une version limitée du C.

On disposerait ainsi d’une méthode générale et unifiée dédiée à l’affichage de G-cartes, avec

cependant une limite conceptuelle liée aux limitations des shaders, notamment la nécessité

d’utiliser des structures de données relativement simples (ou de pouvoir découper une structure

complexe en sous structure simples) ou le nombre d’instructions et de variable très limitées (de

l’ordre d’une centaine). La limite sur les structures de données concerne surtout le plongement et

moins la modélisation, car nous avons vu que les G-cartes sont un modèle topologique et

modélisent en fait des relations entre des cellules de l’objet : ces relations peuvent être

implantées par des pointeurs et ces derniers sont supportés plus ou moins directement par les

shaders. Les contraintes techniques sur cette solution sont fortes, mais celle-ci permettrait une

définition homogène d’un certain nombre d’objets intéressants en informatique graphique,

comme les objets décrits à partir de courbes, ou les méthodes simulant la géométrie d’un objet à

partir d’une carte de perturbations des normales.

(a) (b) (c)

Fig. 4.3 : En (a) une géométrie simple, en (b) une carte de perturbations des normales et en (c) la géométrie supplémentaire simulée par perturbation du comportement de l’objet. Les deux

objets possèdent le même nombre de polygones.

64

Références

[BH97] Bowman, D. A. and Hodges, L. F. (1997). An evaluation of techniques for grabbing and

manipulating remote objects in immersive virtual environments. In 1997 Symposium on

Interactive 3D Graphics, pages 35--38

[Bow99] Doug A. Bowmann. Interaction Techniques For Common Tasks In Immersive Virtual Environments - Design, Evaluation and Application. PhD thesis, Georgia Institute of

Technology, 1999.

[Bra00] S.Brandel. Conception et implantation d’un modeleur 4-D pour l’animation. Thèse de

doctorat, Université Louis Pasteur, Strasbourg, 2000.

[BW01] Doug A. Bowmann and C. A. Wingrave. Design and evaluation of menu systems for

immersive virtual environnements. In IEEE Virtual Reality, 2001.

[CSH+92a] D. Brookshire Conner, Scott S. Snibb, Kenneth P. Herndon, Daniel C. Robbins,

Robert C. Zeleznik, and Andries van Dam. Three-Dimensional widgets. In Proceedings of the 1992 Symposium on Interactive 3D graphics, Special Issue of Computer Graphics, Vol. 26,

pages 183-188, 1992.

[DBB+98] N. Dubreuil, D. Bechmann, Y. Bertrand, S. Brandel, and P. Lienhardt. Geometric

operations for 4D modelling. In 3D Modeling of Natural Objects : A challenge for the 2000’s,

Vandoeuvre-lès-Nancy, France, June 4-5, 1998.

[FAT03] P. Fuchs, B. Arnaldi et J. Tisseau. Le traité de la réalité virtuelle, volume 1, chap. La réalité virtuelle et ses applications. Paris, Presses de l’Ecole des Mines, 2003. ISBN 2-911762-

47-9.

[GC01] Jérome Grosjean and Sabinne Coquillard. Commande & control cube : a shortcut

paradigm for virtual environnements. In Eurographics Workshop on Virtual Environnements,

2001.

[Ger04] D. Gerber. Interaction 3D sur un plan de travail virtuel : Application aux déformations de forme libre. Thèse de doctorat, Université Louis Pasteur, Strasbourg, 2004.

[Jac70] A. Jacques. Constellation et graphes topologiques. In Combinatorial Theory and

Applications, pages 657-673, Budapest, Hungary, 1970.

[JBH01] Christopher Just, Allen Bierbaum, Patrick Hartling, Kevin Meinert, Carolina Cruz-

Neira, and Albert Baker

Published at IEEE VR 2001, Yokohama, Japan, March 2001

65

[LDP+02] James Jen-Weei Lin, Henry B. L. Duh, Donald E. Parker, Habib Abi-Rached, and

Thomas A. Furness. Effects of field of view on presence, enjoyment, memory and simulator

sickness in a virtual environment. In Proceedings of IEEE Virutal Reality Annual International Symposium, pages 164-172, 2002

[Lie94] P. Lienhardt. N-dimensional generalized combinatorial maps and cellular quasi-

manifolds. International Journal of Computational Geometry and Applications, 14 :373-389,

1994.

[Mos98] F. Mossmann. Définitions d’opérations de modélisation spatio-temporelle. Rapport de

DEA, Université Louis Pasteur, Strasbourg, 1998.

[MRWJ03] Michael Meehan, Sharif Razzaque, Mary C. Whitton, and Frederick P. Brooks Jr.

Effects of latency on presence in stressful virtual environments. In Proceedings of IEEE Virutal Reality Annual International Symposium, 2003.

[Sur61] On the use of quaternions to describe the angular orientation of space vehicles, Surber

T.E.,J. Aerospace Sci. 28, 1961

[SIKH82] D. C. Smith, C. Irby, R. Kimball, and E. Harslem. The star user interface : an

overview. In Proceedings of AFIPS 1982 National Conference, pages 515-528, 1982.

[Ste03] Ludovic Sternberger. Étude des métaphores d’interaction 3D sur le Workbench. Mémoire de DEA, Université Louis Pasteur, 2003.

Rapport de stage Réalité virtuelle et objets...

Documents

Transcript of Rapport de stage Réalité virtuelle et objets...