Réalité virtuelle appliquée au headtracking et au

handtracking

Deshayes Romuald

Remerciements

Je tiens à remercier : Mon directeur de projet, Mr Tom MENS, pour son suivi tout au long de l'année,ainsi que ses conseils et relectures. Grâce à lui, j'ai également eu l'occasion de par-ticiper à une activité de vulgarisation scientique annuelle nommée Printemps desSciences. Lors de cette participation, j'ai eu l'opportunité d'y présenter mon projetaux visiteurs. Cette expérience fut pour moi très enrichissante, aussi bien du pointde vue humain que didactique.

Mon co-directeur, Mr Michaël HOSTE, qui s'est montré d'une grande attentionvis-à-vis de ce projet, et qui m'a apporté de nombreux conseils tout à long de laréalisation de mon projet.

Mon rapporteur, Mr Hadrien MELOT, pour ses relectures, ses corrections ainsi queses conseils.

Toutes les personnes qui ont contribué à ce projet, notamment par l'apport decorrections lors de leur relecture attentive de ce rapport.

1

Prérequis du lecteur

Pour faciliter la lecture de ce document, le lecteur devra posséder certains prérequis : Pour comprendre les sections traitant de l'implémentation, des connaissances enprogrammation (Orienté-objet) sont nécessaires. De plus, une bonne connaissancedu langage OpenGL facilitera leur compréhension

Les concepts théoriques sous-jacents à notre problème demandent des connaissancesde trigonométrie de base et de physique de base (un niveau secondaire est susant).

2

Table des matières

1 Introduction 61.1 Headtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Handtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Vue en trois dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4 Etat de l'art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.1 Johnny Chung Lee . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.4.2 Chris Harrison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4.3 TrackIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4.4 Playstation Eye . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4.5 Projet Natal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Approche du problème 152.1 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Lunettes infrarouges . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.1.1 Avantages et inconvénients . . . . . . . . . . . . . . . . . . 152.1.1.2 Montage et fonctionnement . . . . . . . . . . . . . . . . . 16

2.1.2 Gant infrarouge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.3 Wiimote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.3.1 Qu'est ce qu'une Wiimote ? . . . . . . . . . . . . . . . . . 212.1.3.2 Spécications techniques . . . . . . . . . . . . . . . . . . . 21

2.1.4 Utilisation d'une Webcam . . . . . . . . . . . . . . . . . . . . . . . 232.1.5 Headtracking grâce à la stéréoscopie . . . . . . . . . . . . . . . . . 252.1.6 Amélioration des lunettes . . . . . . . . . . . . . . . . . . . . . . . 26

2.1.6.1 Utilisation de trois sources infrarouges . . . . . . . . . . . 262.1.6.2 Polarisation . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.6.3 Obturation . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2 Choix informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.1 Besoins du langage . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.2 Choix du langage et argumentation . . . . . . . . . . . . . . . . . . 31

2.2.2.1 Ecacité de la librairie . . . . . . . . . . . . . . . . . . . . 322.2.2.2 Rapidité du langage . . . . . . . . . . . . . . . . . . . . . 322.2.2.3 Portabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2.2.4 Orienté Objet . . . . . . . . . . . . . . . . . . . . . . . . . 332.2.2.5 API 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2.2.6 Perfectionnement du langage . . . . . . . . . . . . . . . . 34

3

2.2.3 Idées alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3 Concepts théoriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.3.1 Concernant le headtracking . . . . . . . . . . . . . . . . . . . . . . 362.3.2 Concernant le handtracking . . . . . . . . . . . . . . . . . . . . . . 422.3.3 Concernant l'eet fenêtre . . . . . . . . . . . . . . . . . . . . . . . . 422.3.4 Rappels de mécanique . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 Implémentation du module 463.1 Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2 Utilisation de la librairie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3 Module headtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.3.1 HeadtrackedCamera . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3.2 Camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.3.3 CameraHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.4 WiimoteHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.3.4.1 WiimoteHeadAndHand . . . . . . . . . . . . . . . . . . . 523.3.4.2 WiimoteHand . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.4.3 Utilité du WiimoteHandler . . . . . . . . . . . . . . . . . 52

3.3.5 3DMath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4 Fonctionnalités étendues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.4.1 Gestion des angles . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.2 Gestion des tremblements . . . . . . . . . . . . . . . . . . . . . . . 54

3.4.2.1 ShakeDetector . . . . . . . . . . . . . . . . . . . . . . . . 543.4.2.2 Interpolation des précédents évènements . . . . . . . . . . 55

3.4.3 Gestion de plusieurs Wiimotes . . . . . . . . . . . . . . . . . . . . . 563.4.4 3D stéréoscopique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.4.5 WindowedView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.5 Module Handtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.5.1 HandTracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.5.2 HandHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.5.3 HandMovementsDetector . . . . . . . . . . . . . . . . . . . . . . . . 61

4 Applications 634.1 Jeu de Pong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.1.1 Trajectoire de la balle . . . . . . . . . . . . . . . . . . . . . . . . . 634.1.2 Gestion des collisions . . . . . . . . . . . . . . . . . . . . . . . . . . 634.1.3 Règles du jeu et Calcul du score . . . . . . . . . . . . . . . . . . . . 64

4.1.3.1 Règles du jeu . . . . . . . . . . . . . . . . . . . . . . . . . 654.1.3.2 Calcul du score . . . . . . . . . . . . . . . . . . . . . . . . 65

4.1.4 Intelligence articielle . . . . . . . . . . . . . . . . . . . . . . . . . . 664.1.5 Handtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.1.6 Déroulement d'une partie . . . . . . . . . . . . . . . . . . . . . . . 67

4.2 Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.3 Eet fenêtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.4 Formes 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.5 Explorateur de Fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.6 Visualisateur de photos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4

4.7 Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.7.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . 724.7.2 Communication avec les applications . . . . . . . . . . . . . . . . . 724.7.3 Intégration des scènes . . . . . . . . . . . . . . . . . . . . . . . . . 73

5 Utilisation du module 745.1 Réaliser une application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.1.1 Installation des librairies . . . . . . . . . . . . . . . . . . . . . . . . 745.1.2 Headtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.1.2.1 Utiliser la Camera du module . . . . . . . . . . . . . . . . 755.1.2.2 Détection des angles . . . . . . . . . . . . . . . . . . . . . 765.1.2.3 Lier la caméra au module . . . . . . . . . . . . . . . . . . 76

5.1.3 Handtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2 Interface utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2.1 Lancement de l'application . . . . . . . . . . . . . . . . . . . . . . . 785.2.2 Région Ouest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2.2.1 Onglet Mesures . . . . . . . . . . . . . . . . . . . . . . . . 795.2.2.2 Onglet Wiimote . . . . . . . . . . . . . . . . . . . . . . . 81

5.2.3 Région Est . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2.3.1 Onglet Paramètres . . . . . . . . . . . . . . . . . . . . . . 835.2.3.2 Onglet Contrôles . . . . . . . . . . . . . . . . . . . . . . . 90

5.2.4 Région Nord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.2.5 Région Sud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.2.6 Région Centrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6 Conclusion 94

Bibliographie 95

5

Chapitre 1

Introduction

Le monde dans lequel nous évoluons est de plus en plus informatisé. Si bien qu'au-jourd'hui tout le monde possède un ordinateur à la maison. Depuis plus de cinquante ans,l'informatique n'a cessé d'évoluer, de l'arrivée de la première interface utilisateur, il y aplusieurs dizaines d'années, à l'apparition des premiers ordinateurs de salon. Cependant,une chose est restée gée durant toutes ces décennies, comme si personne n'avait jamaisvoulu qu'elle évolue. Il s'agit de la façon d'intéragir avec notre ordinateur.

Certes les claviers ont évolué, leur frappe est devenue plus agréable, les touches mieuxplacées, etc. Avec l'arrivée des ordinateurs de salon, nous avons même vu débarquer destélécommandes permettant de piloter l'ordinateur. Mais au fond, cela n'a pas beaucoupchangé. Depuis cinquante ans, utiliser un ordinateur signie appuyer sur des boutons, etregarder son écran signie regarder une image xe et monotone.

Qui n'a jamais revé de changer la façon d'utiliser sa machine, pour qu'elle devienneréactive au moindre de vos mouvements ou adapte l'image achée en fonction de votreposition par rapport à l'écran ? Autant d'idées qui semblaient folles il y a encore quelquesannées. Mais aujourd'hui, avec la puissance de calcul grandissante des machines, et lesprouesses technologiques du multimédia, la ction devient une réalité. Il est aujourd'huipossible de transformer son ordinateur en une véritable station réactive aux mouvements,grâce à l'arrivée de technologies innovantes.

Parmi ces technologies, le headtracking permet d'adapter une image achée à l'écranen fonction de la position que l'utilisateur prend par rapport à ce dernier.

Dans ce document, nous expliquerons comment mettre en place une solution de head-tracking ecace et portable. Nous présenterons les diérentes contributions ayant déjà étéapportées par les communautés scientiques et industrielles au problème de headtracking.Lors de cet état de l'art, nous introduirons les méthodes utilisées pour mettre en placele système de headtracking. Nous consacrerons la suite de ce document à la descriptionde notre contribution personnelle au problème de headtracking. Cette description traiterade l'approche utilisée pour mettre au point notre propre solution de headtracking. Nousdiscuterons notamment des aspects techniques concernant le matériel utilisé, ainsi quedes aspects théoriques et informatiques concernant la détection de la position de la têteen temps réel. Enn, nous présenterons l'application développée, sous la forme d'un guidede l'utilisateur souhaitant utiliser l'application graphique développée et d'un guide dudéveloppeur désireux de créer une application de headtracking utilisant notre application.

6

1.1 Headtracking

An de permettre au lecteur une bonne compréhension du sujet traité dans ce docu-ment, il nous est nécessaire de dénir le terme de headtracking.

Le headtracking est un concept appliqué dans le cadre de la réalité virtuellequi permet de détecter la position de la tête d'une personne dans l'espace.Cette position réelle pourra ensuite être analysée et travaillée de façon à êtreintégrée dans un espace virtuel au sein d'un monde en 3 dimensions. De cettefaçon, chaque mouvement de la tête de l'utilisateur entraînera une modicationen temps réel de l'achage virtuel, comme si l'utilisateur regardait à traversune fênêtre. Le but recherché par cette application est de rendre l'utilisationd'un écran plus intéractive, en donnant l'impression que celui-ci n'existe plus.

Ce concept possède de nombreuses applications. Dans le monde du jeu vidéo, il seraitpar exemple possible d'utiliser les mouvements de la tête comme un contrôleur. Dans unjeu de moto, nous pourrions imaginer que le fait de pencher la tête vers la gauche/droiteferait basculer la moto du même côté.Les applications ne se limitent pas au monde du jeu vidéo. Si nous nous plaçons dans uncontexte industriel, cette application peut être utilisée par un architecte pour visualiserdes plans en trois dimensions. Le fait de se déplacer autour de l'écran permettrait aucréateur de visualiser son projet sous un angle diérent, dépendant directement de saposition par rapport à l'écran.Dans un contexte plus général, la position de la tête d'un utilisateur en face de son écranpeut être utilisée pour visualiser des images en trois dimensions. La modication de l'anglede vue permettrait de visualiser des objets qui sont cachés par des sujets étant situés aupremier plan de l'image.Une autre idée intéressante serait de naviguer dans une interface grâce aux mouvementsde la tête, qui déclencheraient des commandes en fonction du type de mouvement eectué.Cette dernière possibilité sort du cadre de headtracking au sens strict du terme (car nousn'allons pas nécessairement réadapter l'image en fonction des mouvements de la tête, maisplutôt nous servir de ses mouvements pour contrôler une interface), mais reste toutefoisune application intéressante.

1.2 Handtracking

Dans la suite de cette étude, nous serons amenés à parler de handtracking. Ce conceptn'est pas très diérent de celui que nous avons expliqué à la section 1.1. La principalediérence, comme son nom nous le laisse deviner, est qu'au lieu de détecter la positiondu visage, nous allons être intéressés dans la détection des mains.Parmi les applications possibles, citons la possibilité de déplacer une raquette de tennis,dans un jeu vidéo. Une vision bien plus vaste de cette notion est de piloter une interfaceavec les mains. Un mouvement rapide de gauche à droite de la main permettrait parexemple de changer la chaîne de la télévision, alors qu'un mouvement vers le haut auraitpour eet d'augmenter le volume.

L'étude du handtracking est un sujet que nous n'aborderons que brièvement dans cedocument. Toutefois, ce concept est tout autant digne d'intérêt que son paronyme (cfsection 1.1).

7

1.3 Vue en trois dimensions

Avant de commencer, il est nécessaire d'introduire une dernière notion importante. Ils'agit de la vision en trois dimensions. Formellement, les êtres humains ont la capacitéde percevoir les objets qui les entourent avec un certain relief. La position des deux yeuxchez l'être humain est telle que tout ce qui se trouve devant lui est vu à la fois par l'oeilgauche et l'oeil droit. La faible distance (environ 6,5 cm) qui sépare nos yeux impliqueque deux images légèrement diérentes sont traitées par notre cerveau. C'est l'associationde ces deux images qui est à l'origine du relief que nous sommes capable de discerner.

Informatiquement parlant, la vision en trois dimensions ne s'obtient pas de la mêmefaçon que dans la réalité. Pour perçevoir du relief à travers un écran, car c'est ce à quoinous souhaitons arriver, il est nécessaire de donner au cerveau l'illusion qu'il peut voir entrois dimensions. Pour ce faire, un écran doit générer de façon simultanée deux images.Chacune de ces images doit ensuite être restituée à l'un de nos yeux.Pour arriver à ce résultat, plusieurs procédés existent. Les trois principaux sont l'ana-glyphe, la polarisation et l'obturation. Nous expliciterons en détail de quelle façon desimages en trois dimensions peuvent être obtenues grâce à ces technologies à la section2.1.1.

1.4 Etat de l'art

Le concept de headtracking n'est pas nouveau ; en eet, un certain nombre de re-cherches en la matière ont déjà été eectuées. Toutefois, ces diérentes recherches n'ontpas toutes utilisé les mêmes concepts. La technologie de headtracking peut-être vue d'unemultitude de façons diérentes. Dans cette section, nous dégagerons quelques unes desdiérentes méthodes qui ont déjà été présentées.

1.4.1 Johnny Chung Lee

La première méthode présentée est celle de Johnny Chung Lee, un jeune chercheur del'Université Carnegie Mellon. L'intérêt de sa méthode [15] repose sur le fait qu'il utilise dumatériel répandu et bon marché pour mener à bien son expérience. Les seuls outils utiliséssont une télécommande de la célèbre console de jeu Wii (la Wiimote 1), ainsi qu'une pairede lunettes munie de leds infrarouges, les leds étant placées de chaque coté des lunettes, surles branches de celles-ci et émettant dans la direction regardée par leur porteur. Pour quela position de son visage soit détectée, l'utilisateur doit simplement porter ces lunettes.Les deux infrarouges émis seront alors perçus par la caméra infrarouge située dans laWiimote. Il ne reste plus qu'à eectuer une série de calculs en fonction de ces points etl'ordinateur connaît à présent la position relative de l'utilisateur par rapport à la camérainfrarouge.

Les mouvements permis par l'application de Johnny Lee sont les déplacements :

1. Latéraux

2. Verticaux (de haut en bas)

1. Nous parlerons plus en détails de la Wiimote à la section 2.1.3

8

Figure 1.1: Application développée par Johnny Lee

3. D'avant en arrière.

L'application utilise deux leds infrarouges pour détecter la position du visage. Le calculde la distance entre la Wiimote et l'écran est eectué en se basant sur la distance entreces deux leds. Par conséquent, si l'utilisateur pivote la tête vers la gauche ou la droite,la distance entre les sources infrarouges diminue. En eet, lors de leur projection sur lecapteur, nous passons de trois dimensions à deux dimensions, et c'est l'information deprofondeur qui est perdue. Cette diminution de distance va provoquer une erreur dansle calcul de la distance entre la caméra et l'utilisateur, qui semblera plus éloigné qu'enréalité sur le rendu de la scène.

De façon générale, l'utilisation du headtracking peut tout à fait se passer de l'utilisationdu mouvement pivot de la tête, qui entraîne une certaine gêne à l'utilisation.

Pour montrer l'eet apporté par le headtracking, J. Lee a développé en C# (un lan-gage de programmation orienté objet) et avec la librairie Direct3D une petite applicationgraphique. Cette application ache une série de petites cibles dans un espace en troisdimensions. Ces cibles sont contenues à l'intérieur d'une grille (cf gure 1.1). Ce procédétransforme l'écran en environnement virtuel, lequel réagit en temps réel aux mouvementseectués par la tête de l'utilisateur. Au nal, l'écran apparaît comme une fenêtre et donneune forte impression de profondeur à la scène.

1.4.2 Chris Harrison

Chris Harrison [11] est un jeune chercheur issu de la même université que J. Lee.Plutôt que d'utiliser la Wiimote pour détecter des infrarouges, il a préféré utiliser unesimple webcam pour détecter la position de la tête d'un utilisateur. De cette façon, sonapplication cible un public beaucoup plus vaste. Il a développé l'application en utilisantOpenCV [17], qui est une librairie d'algorithmes pour traiter la vision en temps réel.

Grâce à cette librairie, il a pu construire une solution de headtracking en temps réel,dont les performances sont qualiées de étonnamment bonnes par son auteur. En ef-fet, sa solution permet de détecter et modier la position virtuelle du personnage à 25fps(Frame Per Second), une vitesse susante pour une interaction en temps réel. Malheureu-sement, ce traitement visuel nécessite toute la puissance d'une machine récente équipée

9

de plusieurs coeurs pour fonctionner de manière optimale. En eet, la vidéo 2 de démons-tration réalisée par le jeune chercheur américain montre une certaine faiblesse au niveaude la uidité de l'application.

Le succès et la simplicité de la méthode de C. Harrisson ont poussé une série dedéveloppeurs à créer leur propre application de headtracking en utilisant une webcam.De nombreuses videos sont disponibles sur internet, en utilisant par exemple les mots-clésheadtracking webcam sur Youtube [12].

1.4.3 TrackIR

TrackIR [22] est la première et plus ancienne version développée par Microsoft. Cettesolution est à ce jour une des plus développées en matière de headtracking, mais c'estaussi une des plus onéreuse. Elle se compose de deux parties : comme le montre la gure1.2,la première partie est un petit boîtier à placer au-dessus de l'écran (comme une simplewebcam) contenant une caméra infrarouge ainsi qu'une série de leds infrarouges émettantdans la direction de l'utilisateur. La seconde partie est une petite tige en plastique conte-nant trois réecteurs à infrarouges à placer sur l'utilisateur. Ces réécteurs sont capablesde capter la lumière infrarouge émise par la caméra et de la renvoyer à la façon d'un cata-dioptre. Les trois points ainsi captés peuvent donc être récupérés via la caméra infrarougeet utilisés pour calculer la position du joueur par rapport à la caméra. L'application de ceprocédé touche uniquement le monde du jeu vidéo. C'est d'ailleurs dans cette optique queTrack IR a développé sa propre solution de headtracking. A ce jour, plus d'une centainede jeux vidéos sont compatibles avec ce matériel. La plupart d'entre eux sont des jeux desimulation, touchant des domaines tels que la course automobile ou à moto ainsi que lasimulation ou les combats aériens.

À ce jour, la caméra possède un capteur de 300.000 pixels (640x480), avec un taux derafraîchissement à 120Hz (cela signie que l'image peut être réadaptée jusqu'à 120 foispar seconde) et un angle de vue de 52°C. La caméra est capable de détecter 6 types demouvements diérents :

1. déplacement gauche-droite,

2. déplacement haut-bas,

3. déplacement avant-arrière,

4. hochement de tête vertical

5. hochement de tête horizontal

6. hochement de tête latéral

Pour chaque type de mouvement, on parle de degré de liberté. Chacune de ces actionspeut donc être interpretée et reproduite par un personnage virtuel dans un jeu video.

La solution de Microsoft est déjà commercialisée depuis 2001. À l'époque, seuls deuxdegrés de liberté étaient présents et le capteur ne possédait que 60.000 pixels (300x200),avec un angle de vision de 33°C.

2. voir http ://www.youtube.com/watch ?v=1ZMZK3heklY&feature=player_embedded

10

Figure 1.2: Dispositif de capture de Track IR

Figure 1.3: Le nouveau Playstation Eye [5]

1.4.4 Playstation Eye

Le Playstation Eye [9] (voir gure 1.3) est la nouvelle génération de caméra destinéeà remplacer l'ancienne Eye Toy [21] de Sony. Avec un capteur plus puissant et un tauxde rafraîchissement plus important, la nouvelle caméra peut à présent mieux se prêterà des activités en temps réel telles que le headtracking. Du côté de Sony, rien d'ociel !Cependant, un jeune programmeur de la marque japonaise a déjà montré les possibilitésde la petite caméra lors de la GDC (Game Developers Conference) de 2009 [10].Il s'agitde Thomas Miller. Tout comme Chris Harrison, Thomas Miller n'a utilisé que la simplecaméra, ainsi que des algorithmes de détection de visage pour détecter la position dela tête de l'utilisateur. Le code source de son application a été publié an de donner lapossibilité aux développeurs Sony de se lancer dans des applications de headtracking.

Bien que rien ne soit encore ociellement lancé, cette démonstration laisse entrevoirde nombreuses possibilités de réalité virtuelle chez Sony [28].

11

Figure 1.4: Le contrôleur utilisé par le projet natal

1.4.5 Projet Natal

La dernière technologie dont nous parlerons se nomme Projet Natal. D'un point devue technique, c'est de loin la plus avancée qui soit. Les possibilités oertes par ce nouveaucontrôleur sont énormes.

Le projet natal est un ensemble de technologies qui permettent de jouer avec la consolede jeu Xbox 360 sans utiliser de manette. A la place, le joueur doit utiliser son corps pourinteragir avec les jeux vidéos. Par exemple pour conduire une voiture dans un jeu decourse, les mains du joueur doivent être placées en avant pour tenir un volant imaginaire.Il sut alors de braquer pour faire tourner la voiture.

Pour arriver à ce résultat, il est nécessaire de posséder un capteur qui est chargéde détecter les mouvements du joueur. Comme nous le montre la gure 1.4, il s'agitd'une petite barre horizontale d'une vingtaine de centimètres. Celle-ci contient tout unconcentré de technologies. Le capteur est équipé d'une caméra RGB, d'un détecteur deprofondeur, d'une série de microphones et d'un processeur dédié, capable de traiter toutesles informations reçues par les diérents capteurs. La partie headtracking est assurée par ledétecteur de profondeur qui est en réalité un projecteur infrarouge combiné à un récepteurpermettant de détecter la position de l'utilisateur (voir [18]).

Au travers de cette interface, il est alors possible d'interagir directement dans uneapplication multimédia (telle qu'un jeu video par exemple) sans avoir recours à aucuncontrôleur physique sur l'utilisateur. Aucune led infrarouge ni paire de lunettes ne sontdonc nécessaires. Le contrôle d'un personnage, la navigation dans un menu, dans un jeuvideo, etc, autant de choses qui pourront être entièrement contrôlées par le déplacementde l'utilisateur, de son visage, et/ou via des commandes vocales.

Projet Natal permet d'utiliser l'entièreté du corps pour contrôler un personnage ouinteragir avec la console, avec une latence à l'utilisation d'une dizaine de millisecondespour reconnaître un mouvement. Cette latence est susamment faible pour permettred'interagir en temps réel et de façon uide avec la console de jeu. De plus, comme ledispositif de capture possède son propre processeur, les ressources de la console restent enmajeure partie disponibles pour gérer l'achage des jeux.

Lorsqu'on parle du projet natal, il s'agit donc d'une interface complète pour utiliserla Xbox 360. La partie headtracking n'est donc qu'une des multiples facettes du nouveaucontrôleur.

12

1.5 Contributions

Le but de ce travail est de créer une solution de headtracking, foncionnant à l'aidede la Wiimote et de leds infrarouges posées sur des lunettes à anaglyphes, les rechercheseectuées par le chercheur Johnny Lee (cf section 1.4.1) ayant servi de base pour laréalisation de notre application.

Ce travail consiste en une généralisation et une extension des recherches apportéespar Johnny Lee, qui avaient pour but de montrer à la communauté des développeurs lapossibilité d'utiliser la Wiimote comme un dispositif de détection pouvant servir de baseà des applications de réalité virtuelle.

D'un point de vue généralisation, un module réutilisable a été développé, sous laforme d'une librairie en Java. Ce module contient toutes les fonctionnalités nécessaires àla réalisation d'une application de headtracking . Principalement, il se charge du calculde la position de l'utilisateur par rapport au dispositif de capture, qui est par défaut uneWiimote, mais qui peut être remplacée par d'autres dispositifs, à condition que ceux-cipossèdent une interface permettant de récupérer les coordonnées de deux points situésprès de yeux de l'utilisateur.Une fois la position calculée, elle peut être intégrée dans n'importe quelle type de scènevirtuelle en trois dimensions. Plusieurs scènes intégrant le module de headtracking ontété développées, de cette façon nous disposons de plusieurs exemples d'applications quiutilisent le module.

En termes d'extension, plusieurs fonctionnalités ont été ajoutées an de proposer unesérie d'outils pouvant être utilisés de façon complémentaire au headtracking. Ces fonc-tionnalités sont :

Ajout d'un degré de liberté supplémentaire permettant à l'application de détecterle roulis de la tête. Le fait de pencher la tête vers la gauche ou la droite entraîneune adaptation de l'image en temps réel donnant ainsi l'impression d'être sur unemoto enchaînant des virages serrés.

Gestion des tremblements : lorsque l'utilisateur s'éloigne du dispositif de capture,le calcul de la distance devient plus compliqué. Comme nous l'avons précédemmentexpliqué à la section 1.4.1, le calcul de la distance utilisateur/caméra se base surla distance perçue sur le capteur entre les deux leds infrarouges présentes sur leslunettes portées par l'utilisateur. A une distance supérieure à environ deux mètres,la distance en pixels entre les deux sources devient très faible, et une variation d'unseul pixel sur le capteur est perçu comme un mouvement de plus de dix centimètres.Les légers mouvements de notre visage ont alors tendance à faire trembler l'imagesur la scène virtuelle. Pour limiter ce phénomène, nous avons ajouté la possibilitéde limiter ces tremblements grâce à un lissage des mouvements sur la profondeur.Plus de détails seront apportés à la section 3.4.2.

Gestion des angles : an de mieux contrôler le headtracking, un outil de détectiondes angles a été mis en place. Il permet d'avertir l'utilisateur qu'il est sur le point dequitter le champ de vision du dispositif de capture. Pour ce faire, lorsque l'utilisateurs'approche du bord du capteur, le coté de l'écran correspondant au bord du capteurapproché devient rouge. A mesure que les sources infrarouges se rapprochent du

13

bord du capteur, le rouge devient de plus en plus vif. Cet outil permet à l'utilisateurd'éviter de quitter le champ de vision de la caméra lorsqu'il utilise le module deheadtracking

Vision stéréoscopique : la technique de stéréoscopie consiste à acher deux imageslégèrement décalées d'une même scène, où chaque image a été passée à un ltre decouleur (typiquement rouge et bleu). Pour que chaque oeil puisse voir l'image quilui est destinée, les lunettes seront équipées de ltres de couleur. C'est ce que nousappelons communément des lunettes à anaglyphes.En plus de l'immersion apportée par le headtracking, il est possible de visionner laplupart des scènes avec un eet de relief, grâce à l'utilisation de lunettes à anaglypheset la génération en temps réel d'images stéréoscopiques. L'impression de réalité estalors encore plus importante.

l'angle de vision de la Wiimote étant assez faible (environ 45 degrés), il serait assez inté-ressant de pouvoir placer deux Wiimotes a côté l'une de l'autre an d'élargir le champ devision. Celui-ci peut être étendu horizontalement, ou encore verticalement, en fonction desbesoins de l'application. De cette façon l'utilisateur disposerait d'une plus grande libertéde mouvements pour interagir avec une application. Cette dernière fonctionnalité n'estpas encore intégrée au module, mais son ajout constitue une extension intéressante auprojet.

Pour la réalisation de ce travail, nous utilisons une Wiimote car elle possède uneinterface de capture très intéressante : elle est équipée d'une caméra infrarouge d'unequalité plus que susante pour nous permettre de détecter des sources infrarouges àplusieurs mètres de distance et ce, avec une grande réactivité. En eet, le capteur possèdeun taux de rafraîchissement susant pour recalculer la position d'un visage 100 fois parseconde, c'est-à-dire bien plus rapidement que la vitesse de l'oeil humain (L'oeil humainest capable de distinguer environ 25 images par seconde). De plus, la qualité du capteurpermet de détecter la position de la tête avec une grande précision. En eet, puisque lecapteur de la Wiimote est destiné à ne capter que les sources infrarouges, il est possiblede lui assigner une résolution de plus de 700.000 pixels (1024x768 exactement) à 100Hz 3.

Puisque la Wiimote possède une caméra infrarouge, de simples leds infrarouges serontparfaitement utilisables. L'avantage de leds est qu'elles sont très discrètes, peu gourmandesen électricité et peu onéreuses. Il sut donc d'équiper une simple paire de lunettes avecdeux leds infrarouges pour pouvoir détecter la position d'un utilisateur dans l'espace.

3. Chaque point infrarouge peut être stocké sur 2 x 10bits (0-1023). Acher 4 points à 100Hz requiertdonc un taux de transfert de moins de 8Kbps pour la position des points. Les détails techniques concernantles Wiimote sont disponible au point 2.1.3. Le bluetooth peut transférer jusqu'a 720Kbps.

14

Chapitre 2

Approche du problème

2.1 Choix technologiques

Pour mettre en place un système de headtracking ecace, il est nécessaire d'utiliser dumatériel de détection, permettant de situer la tête de l'utilisateur dans l'espace. Commedétaillé à la section 1.4, plusieurs solutions existent pour permettre la mise en oeuvre duheadtracking.

Dans cette section, nous détaillerons le matériel physique qui a été utilisé pour la réa-lisation de notre application. Ces détails seront utiles au lecteur, an de permettre unebonne compréhension de la façon dont les concepts théoriques pourront être appliqués surles outils dont nous disposons.

Nous proterons également de cette section pour discuter des détails techniques concer-nant d'autres solutions existantes. Ces solutions concernent aussi bien la mise en placed'un système de headtracking diérent que l'ajout de fonctionnalités supplémentaires.Nous verrons par exemple comment il est possible d'utiliser une webcam ou une camérastéréoscopique pour détecter la position de la tête dans l'espace, ou encore, commentdétecter les rotations de la tête en utilisant plus de deux sources infrarouges.

2.1.1 Lunettes infrarouges

Dans cette section, nous expliquerons l'utilité des lunettes infrarouges dans notre sys-tème de headtracking. Nous y détaillerons également leur mise en place et verrons com-ment il est possible de les utiliser pour détecter la position de la tête.

2.1.1.1 Avantages et inconvénients

Le fonctionnement de notre solution est principalement basé sur un équipement : leslunettes. Elles sont le point de repère de la caméra, et permettront de localiser avec préci-sion le visage de celui qui les porte. Utiliser des lunettes pour notre modèle de headtrackingpeut sembler un inconvénient, cependant, leur présence est aussi intéressante :

L'utilisation de lunettes peut être vue comme un inconvénient, car contrairementà certaines méthodes présentées dans la section 1.4, il est nécessaire d'être équipéde lunettes pour obtenir une solution ecace de headtracking. Rappelons-nous du

15

projet traité au point 1.4.5, où aucune paire de lunettes n'est nécessaire. Cepen-dant, une telle solution à un coût : une caméra RGB, un capteur infrarouge, unesérie de micros et un processeur dédié au traitement des informations en temps réel.Cependant, l'utilisation de lunettes ne nuit pas au caractère académique de ce pro-jet. Ajoutons qu'une solution alternative utilisant d'autres dispositifs de détectionpourrait être adaptée sur l'application développée, sans pour autant entraîner demodications dans celle-ci.

La présence de lunettes infrarouges est intéressante, car elle nous permet de traiteruniquement les infrarouges, entraînant alors un poids très réduit de l'information àvéhiculer. Alors qu'une image complète en RGB peut peser plusieurs mégaoctects,l'information contenant uniquement les sources infrarouge ne pèse que quelquesoctets. En eet, seules les coordonnées de chaque point sur le capteur infrarougedoivent être stockées et envoyées à l'application, alors qu'une solution classique de-mande d'envoyer tous les points perçus par le capteur à l'application.En ne traitant que les sources infrarouges, le procédé est également beaucoup plusrapide et nous pouvons traiter une centaine d'images chaque seconde, sans utiliserun processeur dédié pour le traitement de l'information. Cela apporte donc un gainde performances mais aussi un coût minimal.Notons que l'utilisation de sources infrarouges requiert la présence d'un ltre infra-rouge qu'il faut placer devant le capteur de la caméra servant de dispositif de capture.

En second lieu, la présence de lunettes nous sera protable pour l'ajout de la sté-réoscopie. En eet, il est nécessaire de porter des lunettes anaglyphes 1 pour proterde l'application en 3D stéréoscopique.

2.1.1.2 Montage et fonctionnement

Nos lunettes sont le point de repère de la caméra, qui se base sur la position dansl'espace de ces dernières pour déterminer la position de l'utilisateur.

Détaillons la composition de notre paire de lunettes : Pour la réalisation du montage, n'importe quelle paire de lunettes convient. Nouspouvons par exemple utiliser des lunettes de soleil auxquelles les verres ont étéretirés, ou encore une paire de lunettes classique. Finalement, tout ce dont nousavons besoin est une monture où nous pourrons xer les leds infrarouges ainsi queles ltres de couleurs.

Il faut ensuite se munir de deux leds infrarouges, an d'en xer une sur chaquebranche de la paire de lunettes (comme sur la gure 2.1), de façon à ce qu'ellesémettent dans la direction regardée par leur porteur. Nous pouvons par exempleutiliser deux leds de type LD242-3. Ce type de led est représenté sur la gure 2.2.Pour l'alimenter, une tension inférieure à 1.5V doit lui être appliquée à 100mA 2.Nous avons donc utilisé une simple pile LR6 rechargeable (les piles crayon utiliséesdans tous les types d'appareils électriques, leur tension est de 1.5V pour les batteriesnon-rechargeables et 1.2V pour les rechargeables) pour alimenter nos deux leds. Pour

1. Les lunettes anaglyphes possédent un ltre rouge pour l'oeil gauche et cyan (vert et bleu) pourl'oeil droit.

2. Pour plus de renseignement consulter les datasheet. Vous pouvez consulter les datasheet via lemoteur de recherche http://www.alldatasheet.com/. REFERENCES

16

Figure 2.2: Une led de type ld242-3

que la tension délivrée soit la même sur chaque led, nous avons eectué le montageen parallèle.

Figure 2.1: Lunettes équipées de leds infrarouges. Source:http://www.nguyot.fr/img//divers/combowii.png

Pour améliorer la facilité d'utilisation des lunettes, nous pouvons équiper ces der-nieres d'un interrupteur pour activer/désactiver les leds.

À partir de lunettes à anaglyphes 3 (gure 2.3), nous pouvons découper les ltresrouge et cyan, an de les xer sur notre paire de lunette munie de leds infrarouges.

Nous obtenons nalement une paire de lunettes infrarouges équipées de ltres rouge/cyan.Ces lunettes sont notre portail vers la réalité virtuelle, que nous pourrons utiliser pourvisualiser des scènes réactives à nos mouvements, et ce, en trois dimensions.

2.1.2 Gant infrarouge

Plutôt que de se restreindre à l'utilisation du headtracking au sens strict, nous pouvonsproter de la technologie que nous possédons pour élargir les possibilités de nos applica-tions. Nous pouvons créer un gant infrarouge qui nous permettra d'interagir avec la main

3. Un anaglpyhe est une image crée à l'aide de deux ltres de couleurs diérentes pour être vue enrelief. Ce procédé utilise le décallage entre nos deux yeux pour créer des images qui seront perçues enrelief par un utilisateur équipé de lunettes à anaglyphes. [Wikipedia]

17

Figure 2.3: Lunettes 3D, équipées d'un ltre rouge pour l'oeil gauche et cyan pour l'oeildroit. Source : http://www.pandorabox.fr/headers/lunettes3d2.jpg

dans nos applications, en plus de la tête. Le terme de gant infrarouge signie simplementque nous équipons un gant de leds infrarouges, ajoutant ainsi la possibilité à la camérade détecter la position de la main de l'utilisateur.

L'intérêt de ce gant est qu'il nous permet d'ajouter un degré de liberté supplémentairedans nos applications de réalité virtuelle. Il est facile d'imaginer tout ce que la main peutcontrôler. Dans un jeu de ping-pong par exemple, la tête peut gérer le déplacement dela caméra et la main s'occupe de déplacer la palette de ping-pong. Dans un explorateurde chier, tout l'intérêt est de pouvoir piloter l'interface avec ses mains. Sélectionner undossier, acher une image, la déplacer, l'agrandir, la faire pivoter, autant de possibilitésenvisageables en ajoutant l'utilisation de la main.

Lorsque nous utiliserons le gant infrarouge et les lunettes, il nous faudra être capablede les dinstinguer. Pour ce faire, plusieurs solutions sont envisageables.

Une première approche dans la distinction entre la main et le visage consiste à utiliserun nombre de leds diérent pour la main. Nous pouvons par exemple utiliser une seuleled pour détecter la position de la main. Avec une unique led, il n'est alors plus possiblede détecter la dimension de profondeur, car un minimum de deux leds sont nécessairespour calculer cette information. Cependant, en fonction du type d'application désirée, iln'est pas toujours utile d'avoir une information sur la profondeur de la main.

Exemple 1 Dans une application où nous souhaitons visualiser des photographies, lesmouvements de la main sont utilisés pour passer d'une photo à l'autre, ou encore pouragrandir ces dernières. L'information de profondeur n'est alors pas utile, car ce qui nousintéresse concerne les mouvements latéraux perçus sur le capteur.

Exemple 2 Dans un jeu de pong simple, nous pouvons nous restreindre à positionner lamain à la même profondeur que le visage. Les seuls mouvements possibles de la raquettesont alors de gauche à droite et de haut en bas. Bien que cette approche soit restrictive,elle apporte tout de même deux degrés de liberté supplémentaires par rapport au seulheadtracking.

La limitation induite par la Wiimote ne nous permet pas de détecter aisément plus

18

de 4 sources simultanément. Nous ne pouvons donc pas utiliser plus de 2 sources pourdétecter la position de la main. Toutefois, l'utilisation d'un autre type de caméra nouspermettrait d'utiliser plus de sources comme point de repère pour détecter la main.

Une autre solution pour détecter la position de la main, en plus de celle du visage, seraitd'utiliser deux Wiimotes. L'utilisation de deux caméras, placées côte à côte, permettraitd'inverser tout le processus de détection de profondeur, en se basant non plus sur ladistance entre deux leds pour calculer la profondeur, mais en utilisant plutôt la distanceen pixels d'une seule source infrarouge sur les deux capteurs. Puisque les deux camérassont côte à côte, la distance qui les sépare implique que l'image perçue par l'une seralégèrement décalée par rapport à l'image perçue par l'autre caméra. Nous pouvons utiliserce décalage pour calculer la distance à laquelle se trouve une source infrarouge.

Grâce à ce nouveau procédé, une seule led est susante pour détecter la profondeur.Nous pouvons alors utiliser deux leds pour détecter la position du visage et une seule ledpour la position de la main.

Si nous souhaitons utliser le même nombre de leds pour détecter le visage et la main, unautre artice est nécessaire pour permettre de les distinguer. Nous pouvons par exempleutiliser la distance réelle entre les leds comme information codante pour discerner la maindu visage. Lorsque le headtracking est utilisé en complément des mains, l'utilisateur se po-sitionne couramment à une distance d'au moins un mètre cinquante par rapport à l'écran.Si nous utilisons une distance physique deux fois plus petite entre les leds servant à dé-tecter la main par rapport à celles utilisées pour le visage, il n'est pas dicile discernerces dernières, tant qu'elles ne sont pas confondues. Si toutefois les mains de l'utilisateurse trouvent beaucoup plus en avant, la distance perçue sur le capteur entre les leds pour-rait devenir supérieure à celle entre les leds servant de point de repère pour calculer laposition du visage. Pour éviter ce problème, nous pourrions utiliser une distance physiqueplus grande entre les leds de la main. Toutefois, cela impliquerait que l'information deprofondeur concernant la main pourrait être détectée avec une plus grande précision quecelle concernant le visage.

Utiliser une distance supérieure entre les leds permet de détecter l'information deprofondeur avec une meilleure précision. Illustrons ceci par un exemple : si à une distancede deux mètres, deux leds situées à une distance réelle de 20 centimètres sont séparées parune distance de 50 pixels sur le capteur, alors deux leds situées à une distance réelle de 10centimètres ne seront séparées que par 25 pixels sur le capteur. Cela signie que lorsquel'utilisateur s'éloignera encore plus de la caméra, une diérence de 1 pixel correspond àune variation de 2% dans le premier cas et 4% dans le second cas. Nous pouvons alorsdire que plus la distance réelle entre les leds est grande, plus la précision avec laquellenous pourrons calculer la profondeur sera bonne.

D'un autre coté, utiliser une distance trop importante entre les leds pourrait devenirinconfortable pour l'utilisateur, qui ne souhaite pas être contraint à utiliser un dispositifde 40 centimètres de large pour détecter avec précision la position de sa tête. De plus,utiliser une plus grande distance entre les leds augmente également la distance minimaleà laquelle le headtracking peut être eectué. Avec une distance de 40 centimètres entreles leds, un capteur ayant un angle de vue de 45 degrés ne sera pas capable de distinguer

19

celles-ci à une distance inférieure à 1m.

Le cas des leds confondue devra être traité avec plus de soin, si nous voulons éviterles incohérences. Une méthode naïve pour calculer la position des mains et de la têteest décrite ci-dessous. Cette méthode devrait également être appliquée pour les méthodesprécédemment exposées :

Si les mains et la tête ne sont pas confondues alors :

pos_tete := calc_pos_tete()

pos_main := calc_pos_main()

Sinon :

(x,y) := calculer la position latérale et verticale

du centre de gravité des points confondus

z := la précédente valeur de la profondeur de pos_tete

pos_tete := (x,y,z)

pos_main := pos_tete

1. Les méthodes calc_pos_tete() et calc_pos_main() se chargent respectivement decalculer la position de la tête et de la main dans l'espace. Ces méthodes renvoientun triplet contenant la position sur les axes x,y et z, correspondant respectivementaux mouvements latéraux, verticaux et en profondeur.

2. Si les points concernant la tête et la main sont confondus, alors on positionne lamain et la tête au même endroit dans l'espace. Cette heuristique n'est pas parfaite,dans le sens où de légers mouvements de la main près de la tête ne pourront pasêtre perçus. De plus, l'information de profondeur ne pourra pas être remise à jourtant que la main et la tête seront confondues. Si nous voulons de meilleurs résultats,il est alors nécessaire d'implémenter un algorithme plus performant qui se base surla détection et la reconnaissance de motifs. Le but est alors de distinguer le motifcorrespondant au visage de celui représentant la main.

Utiliser pour seule information codante la distance entre les leds pour distinguer la maindu visage n'est pas un procédé susamment robuste. Il sera donc nécessaire d'ajouterd'autres méthodes pour éviter que la machine ne se trompe. Nous pouvons par exemplesupposer que entre deux évènements infrarouges, le mouvement eectué n'a qu'une faibleamplitude (nous pouvons supposer que c'est le cas, car nous pouvons traiter jusqu'à 100évènements par seconde). En gardant en mémoire la position de chaque point lors del'évènement précédent, nous pouvons comparer les anciens points et les nouveaux points,et supposer que le point le plus proche d'un ancien point représente la même chose quecet ancien point. Si nécessaire, nous pourrons aussi utiliser une convention pour améliorerle tracking des points. Par exemple, nous pouvons demander à l'utilisateur que, lors dulancement du programme, sa main ne soit pas située beaucoup plus en avant/arrière parrapport à sa tête, de sorte que l'ordinateur puisse distinguer la main de la tête via ladistance entre les points. Une fois cette déduction faite, le programme pourra suivre lespoints d'un évènement à l'autre.

En pratique, la proximité entre deux évènements n'est pas toujours assurée. Lors denos tests, il est arrivé que le nombre d'évènements par seconde chute à une valeur inférieureà 30. Lors de mouvements rapides, le qualité du tracking est alors fortement dégradée, etil est alors dicile pour l'algorithme de suivre ecacement les sources infrarouges.

20

Figure 2.4: une Wiimote

2.1.3 Wiimote

Comme nous l'avons déjà mentionné plusieurs fois, le périphérique de capture utilisépour la réalisation de notre projet est une Wiimote. Dans cette section, nous expliqueronsce qu'est une Wiimote et nous discuterons des spécications techniques de ce contrôleur.

2.1.3.1 Qu'est ce qu'une Wiimote ?

la Wiimote ou Wii Remote est le nom donné au contrôleur de la console de jeu Nin-tendo Wii. Il s'agit d'une petite télécommande de forme rectangulaire contenant une sériede capteurs tels que des accéléromètres, et une caméra monochrome équipée d'un ltre in-frarouge. Ces détecteurs permettent de situer la Wiimote dans l'espace, et de retranscrireses mouvements à l'écran. Cette nouvelle manette apporte une dimension plus immersiveau jeu vidéo selon son constructeur. Nous pouvons voir sur la gure 2.4 une Wiimote. Elleest composée d'une série de boutons en plus de ses capteurs, pour permettre l'interactionavec son utilisateur.

Pour notre projet, nous n'utilisons que la caméra infrarouge située sur la partie hautede la télécommande (le rectangle noir sur l'image du haut de la gure 2.4 ). En eet, laWiimote sera déposée sous ou sur l'écran où la scène en 3 dimensions sera projetée. Iln'est donc pas utile d'utiliser les diérents boutons du contrôleur.

2.1.3.2 Spécications techniques

D'un point de vue technique, la Wiimote [25] dispose : de plusieurs accéléromètres pour détecter sa position (debout, penchée vers le bas,etc),

d'un capteur infrarouge pour se repérer par rapport à la Sensor bar ( la Sensor barest une petite barre d'une vingtaine de centimètres de long, qui contient à chaqueextrémité une série de leds infrarouges. Elle est utilisée comme point de repère pour

21

la Wiimote. Les sources infrarouges sont vues par la caméra de la Wiimote, qui peutalors se repérer sur base de la position des points sur le capteur.),

de plusieurs boutons (A,B, èches directionnelles, +, -, 1, 2, Home, gachette, power)pour l'interaction avec le joueur,

d'un haut-parleur pour émettre des sons, d'un vibreur, d'une interface bluetooth pour communiquer sans l avec la console ou le PC.

Parmi toutes ces spécications, nous n'utilisons que le capteur infrarouge et l'interfacebluetooth.

Le capteur infrarouge (IR) se compose d'une caméra monochrome (en niveau de gris)ayant un angle de vue horizontal de 42° et un angle de vue vertical de 33°, regardantà travers un ltre infrarouge. Cette caméra est équipée d'un petit processeur capablede détecter jusqu'à 4 sources mobiles. Ce petit processeur ne permet pas de capturerl'image complète vue par la caméra, les seules informations disponibles concernent les 4sources lumineuses pouvant être détectées. De cette façon, l'information renvoyée par lacaméra ne pèse que quelques octets à chaque image. Il existe 3 modes implémentés (parNintendo) pour représenter les sources infrarouges (les informations qui suivent ne sontpas nécessaires à la compréhension du problème et sont présentes comme complémentd'informations).

1. Le mode basique est le plus léger, il ne nécéssite que 10 octets pour stocker lescoordonnées des 4 sources infrarouges pouvant être détectées. Chaque coordonnée(X1,Y1,X2,Y2) peut être codée sur 10 bits (0-1023) et chaque paire de point estemballée dans un paquet de 5 octets comme le montre la gure 2.5. Sur cette gure,est représenté un paquet contenant les informations de deux sources infrarougesP1=(X1,Y1) et P2=(X2,Y2). Parmi les 5 octets de ce paquet, le premier octetreprésente les 8 bits de poids le moins signicatif de la coordonnée X1 du point P1.Le second octet représente les 8 bits de poids le moins signicatif de la coordonnéeY1 du point P1. Le troisième octet contient 4 informations : les 2 bits de poids le plussignicatif contiennent les 2 premiers bits de Y1, les 2 bits qui suivent contiennentles 2 premiers bits de X1, les 4 derniers bits contiennent les 2 bits de poids signicatifde Y2 et X2. Les 4e et 5e octets contiennent les 8 bits de poids le moins signicatifde X2 et Y2.

2. Le mode étendu permet d'obtenir en plus des coordonnées de chaque point uneinformation sur l'intensité de chaque source lumineuse codée sur 4 bits (0-15), chaquepoint est alors emballé dans un paquet de 3 octets, comme nous le montre la gure2.6. Une taille totale de 12 octets est alors nécessaire pour stocker les 4 points.

3. Le mode complet est le plus lourd des trois, mais aussi le plus complet. Il nécessiteune information de 36 octets pour stocker les 4 sources lumineuses.Chaque point possède, en plus des 3 octets du mode étendu, 6 octets supplémentaires(cf gure 2.7). Parmi ceux-ci, un octet permet d'obtenir une valeur plus précise del'intensité du point IR.

22

Figure 2.5: représentation des points en mode basique

Figure 2.6: représentation des points en mode étendu

Figure 2.7: représentation des points en mode complet

Grâce à la librairie que nous utilisons (WiiuseJ), nous ne devons pas nous occuper degérer l'interface bluetooth. Elle gère toute l'interface de communication entre la Wiimoteet le PC. Nous pouvons donc voir cette interface comme une couche à abstraire.

2.1.4 Utilisation d'une Webcam

Plutôt que d'utiliser une Wiimote et des sources infrarouges pour détecter la positionde la tête, il est possible d'utiliser une simple webcam (cf gure 2.8 ) pour détecter laposition de la tête dans l'espace. La diculté consiste alors à détecter où se trouve la têtesur l'image perçue par la webcam. Pour ce faire, plusieurs solutions sont possibles :

23

Figure 2.8: Une Webcam [24] (à gauche) et une caméra stéréoscopique [20] (à droite)

1. Utiliser des points de repères comme avec la wiimote pour faciliter la détection. Parexemple en positionnant deux points uo près du visage, il est possible de faciliter larecherche du visage, qui se limiterait alors à chercher ces points de repère. Une foisla position de ces deux points sur le capteur trouvée, il ne reste plus qu'à envoyerl'information au module de headtracking qui se chargera d'eectuer les calculs poursituer la tête dans l'espace à partir des coordonnées des deux points de repère. Unalgorithme naïf pour la recherche des deux points est de parcourir chaque pixeldu capteur, à la recherche de deux points ayant une couleur assez proche de cellerecherchée. La comparaison de couleurs s'eectuera en RGB avec un certain seuil.Notons que la taille du point uo a très peu de chance de ne faire qu'un seul pixel,il est alors nécessaire de calculer quand nous nous trouvons deux fois sur le mêmepoint uo. Par exemple, le pixel juste à droite du premier pixel uo trouvé à de forteschances d'être lui aussi coloré de la même façon. Il faut donc un mécanisme qui soitcapable de détecter cette situation, tout en permettant de trouver le deuxième pointuo.

2. Une autre solution consiste à utiliser une librairie annexe permettant de détecter laposition du visage. De nombreuses recherches ont été menées dans le domaine dela détection de visage à la caméra, il serait par conséquent dommage de ne pas enproter. A cette n, nous pouvons citer OpenCV, dont nous avons déjà discuté àla section 1.4.2. Cette seconde solution est plus intéressante car elle nous permet dene pas avoir à réinventer la roue.

De façon générale, quelle que soit l'approche utilisée, l'utilisation d'une webcam pourdétecter la position de la tête est très couteuse en temps CPU. L'algorithme utilisé doitêtre capable de détecter la position de la tête sur une image possédant 300K pixels (dansle cas d'une résolution VGA, de 640x480 pixels). Seule une machine très puissante estcapable de détecter le visage et d'en déduire sa position dans l'espace en moins de 35millisecondes, temps maximal autorisé si nous souhaitons une application temps réel.

24

2.1.5 Headtracking grâce à la stéréoscopie

Une autre solution pour détecter la position de la tête en temps réel a déjà été discu-tée à la section 2.1.2. Il s'agit d'utiliser le principe de stéréoscopie an de détecter dansl'espace la position d'une personne.

Une caméra stéréoscopique (cf gure 2.8) est un dispositif possédant deux interfacesde capture vidéo, utilisé pour générer des images stéréoscopiques. Plus précisément, ils'agit d'une caméra qui possède deux objectifs, distants de quelques centimètres, et poin-tant dans la même direction. Les images perçues par chacun de ces objectifs sont alorslégèrement décalées l'une par rapport à l'autre, permettant de générer des vidéos stéréo-scopiques. Les images perçues par chacune des caméras pourront être traitées avec desltres de couleurs, polarisés ou via une autre méthode qui permettra par la suite de lesprojeter en générant un eet de relief moyennant le port de lunettes adéquates.

L'idée sous-jacente à la création d'un système de headtracking en utilisant une camérastéréoscopique est de se servir du décalage entre les deux images pour calculer la distanceà laquelle se trouve le sujet. Au lieu d'utiliser deux leds infrarouges et une seule caméra,le processus inverse est appliqué : deux caméras lment une même scène avec un légerdécalage entre les deux objectifs. Lorsqu'un sujet s'éloigne de la caméra, la distance enpixels perçue sur le capteur, entre les deux sujets présents sur chaque objectif, diminue.Nous pouvons dès lors utiliser cette information pour calculer la profondeur à laquelle estsitué le sujet à détecter.

Toutefois, d'un point de vue performance, l'utilisation de deux caméras pour détecteren temps réel la position d'un utilisateur demande encore plus de ressources que l'uti-lisation d'une webcam. Une solution alternative est d'utiliser deux wiimotes situées àquelques centimètres de distance pour remplacer une caméra stéréoscopique. De cette fa-çon, nous pouvons combiner l'ecacité de la stéréoscopie à la rapidité de traitement liéeà l'utilisation de leds infrarouges.

Nous pouvons alors penser que l'utilisation d'une seule led infrarouge comme pointde repère nous sura à détecter la position du sujet dans l'espace. C'est en eet lecas, puisque ce sont les deux caméras infrarouges qui exploiteront la distance qui lessépare pour calculer la profondeur à laquelle se situe l'utilisateur. Notons cependant quel'utilisation d'une seule led ne nous permettra plus de distinguer les mouvements de roulisde la tête. Il serait donc certainement plus intéressant de continuer à utiliser deux ledsinfrarouges pour situer la position de la tête. De plus, avec deux caméras et deux ledsinfrarouges, nous serions également capables de détecter les rotations de la tête. En eet,si un utilisateur eectue une rotation de la tête, alors les leds sur le capteur vont serapprocher, tandis que la distance entre les deux images sur chacun des deux capteurs nebouge pas. L'utilisation de deux leds infrarouges et de deux wiimotes nous permet doncde créer une solution de headtracking aussi ecace que celle développée par Track IR (cfsection 1.4.3) en terme de nombre de degrés de liberté. Cette approche pourrait être vuecomme une amélioration possible de notre application.

25

Figure 2.9: Utilisation de trois leds

2.1.6 Amélioration des lunettes

Dans cette section, nous verrons que pour une détection complète en trois dimensionsde tous les mouvements, deux leds ne susent pas. Nous passerons également en revuedeux autres techniques plus ecaces que l'anaglyphe pour perçevoir des images en troisdimensions.

2.1.6.1 Utilisation de trois sources infrarouges

Pour la réalisation de notre projet, nous avons choisi d'utiliser deux leds infrarougescomme point de repère pour situer la position de la tête. Ce choix a été le sujet d'une longueréexion, à l'issue de laquelle nous avons décidé de n'utiliser que deux leds. Rapelonsbrièvement les diérences qui existent entre utiliser deux ou trois sources infrarouges :

1. L'utilisation de deux leds ne permet pas de détecter tous les types de mouvements.Plus spéciquement, les rotations de la tête ne peuvent pas être décelés. Si l'utilisa-teur tourne la tête vers la droite ou la gauche, la projection des leds sur le capteurse rapproche et le calcul de la distance est faussé, car si la distance entre les ledsdiminue sur le capteur, cela est perçu comme un éloignement de l'utilisateur.

2. Choisir d'utiliser trois leds comme point de repère permet en revanche de rendrela détection des rotations de la tête possible. En eet, si nous disposons les ledsde sorte qu'elles ne soient pas alignées, alors lorsque l'utilisateur tourne la tête, lecomportement des leds perçu sur le capteur est diérent d'un simple éloignement.Supposons par exemple que les trois sources infrarouges sont placées selon un triangleéquilatéral, représenté à la gure 2.9 (triangle de gauche). De cette façon, lorsquel'utilisateur pivote la tête, la projection sur le capteur du triangle sera perçue commele triangle de droite de la gure 2.9. De cette façon, nous voyons qu'il est tout à faitpossible de diérencier la rotation de la tête de l'éloignement du sujet.

26

Figure 2.10: Emetteurs de Track IR [23]

Au vu de ces diérences, l'utilisation de trois leds infrarouges semble beaucoup plus in-téressante puisqu'elle permet une meilleure robustesse de l'application, ainsi que l'ajoutd'un degré de liberté supplémentaire. Toutefois, nous sommes freinés par une limitationstricte du matériel utilisé : la wiimote ne peut détecter que 4 sources infrarouges. Si noussouhaitons utiliser la main en plus du visage, il devient alors impossible d'utiliser deuxleds pour détecter la position des mains, car trois sources sont déjà utilisées pour la dé-tection du visage. Nous sommes donc restreints à n'utiliser qu'une seule led pour interagiravec la main dans nos applications. Comme nous le savons, l'utilisation d'une seule ledne nous permet pas de calculer l'information de profondeur associée à la main.

Si nous utilisons trois leds comme points de repère, notre solution devient alors plusproche de celle employée par Track IR (voir section 1.4). Pour détecter la position del'utilisateur avec un total de six degrés de liberté, Track IR utilise une solution avec troisleds infrarouges pour calculer la position, ainsi que l'orientation du joueur dans l'espace.L'émetteur utilisé par Track IR contenant trois sources infrarouges est représenté à lagure 2.10.

Pour conclure, l'utilisation de trois leds pour détecter tous les mouvements de la têtepeut sembler utile, mais rend dicile l'utilisation de la main. Une évolution possible denotre programme est d'intégrer la détection de la tête grâce à trois leds, et de laisser lapossibilité à l'utilisateur de choisir quelle solution il souhaite utiliser (deux ou trois ledspour détecter le visage, sachant que l'utilisation de trois leds rend le calcul de la profondeurimpossible sur la main). Si nous comparons cette solution avec l'ajout de la stéréoscopie(cf section 2.1.5), l'utilisation de deux wiimotes est plus intéressante, car seules deux ledssont nécessaires pour de détecter tous les mouvements possibles de la tête, et l'utilisationd'une seule led pour la main permet de calculer l'information de profondeur lui étantassociée.

2.1.6.2 Polarisation

An d'améliorer la qualité de la trois dimensions, d'autres solutions plus performantesque la projection d'anaglyphes existent. Parmi ces solutions, la polarisation est la tech-nique la plus courante utilisée dans les salles de cinéma équipées pour la 3D.

27

Nous savons que la lumière qui nous entoure est consitutée de photons se propageantdans toutes les directions. Ces photons se répercutent dans toutes les directions sur lesdiérentes surfaces qui nous entourent, et nissent par arriver à notre oeil, en provenancede toutes les directions.

La polarisation de la lumière est un procédé qui ltre les rayons lumineux, en ne lais-sant passer que les rayons ayant une certaine direction, par rapport à la surface polarisée.Par exemple, si nous utilisons une surface polarisée de façon horizontale, seuls les rayonslumineux ayant une direction horizontale pourront passer à travers le ltre polarisé. C'estle cas des lunettes de soleil dites polarisées. Elles contiennent un ltre qui permet debloquer les rayons du soleil issus de la rééxion sur une surface plane telle qu'une routemouillée ou encore un sol enneigé.

Pour observer des images en relief, la polarisation peut être utilisée. Il est alors néces-saire d'utiliser deux projecteurs équipés de ltres polarisés perpendiculairement l'un parrapport à l'autre et une paire de lunettes, elle aussi équipée de deux ltres orientés dansles directions correspondantes à ceux placés sur les projecteurs. Grâce à cet équipement,chaque projecteur va acher une image étant destinée à un seul oeil. L'image achée parle projecteur étant équipée du ltre horizontal ne pourra alors être perçue que par l'oeildevant lequel le ltre horizontal a été placé. De cette façon, il est possible de visualiserune scène avec un eet de relief, en projetant une image diérente pour chaque oeil, dela même façon que pour des images anaglyphes.

Le principal problème est que, pour avoir un eet de relief ecace, il est nécessaire degarder les lunettes bien horizontales. En eet, puisque les images achées par le projecteursont polarisées horizontalement et verticalement, ne pas garder les lunettes dans uneposition horizontale empêcherait les rayons lumineux de passer au travers des ltres placéssur les lunettes (qui ne sont plus horizontaux et verticaux, si les lunettes ne sont pas bienhorizontales).

Par la suite, cette technologie de lunettes à polarisation dite linéaire, a été remplacéepar des lunettes équipées de ltres polarisés de façon circulaire, rendant alors la visuali-sation indépendante de l'orientation de la paire de lunettes.

Au niveau ecacité, la polarisation est plus intéressante que l'anaglyphe, car elle nedoit pas utiliser des ltres colorés pour donner un eet de relief. Pour une ecacité opti-male, l'utilisation de ltres colorés pour donner un eet de relief à une image se retreint àla génération d'images en noir et blanc. Puisque les couleurs sont utilisées pour générer lerelief, elles ne peuvent plus être utilisées pour coloriser l'image. Toutefois, il est toujourspossible d'utiliser les couleurs pour visualiser des anaglyphes, mais il est souvent nécessaired'optimiser ces images. La technique de polarisation est plus ecace que l'anaglyphe, carla qualité du relief ne dépend pas de la couleur de l'image à acher. Si nous souhaitonsacher un objet rouge en relief avec des lunettes à ltres colorés, la composante cyan decet objet est nulle. Par conséquent, la partie destinée à l'oeil droit (typiquement, le ltrecyan est placé sur l'oeil droit, mais il ne s'agit pas d'une obligation) ne contiendra pasl'objet rouge. Avec la technique de polarisation, ce problème n'est pas rencontré.

Notons toutefois que l'utilisation de la polarisation est bien plus onéreuse que la mé-

28

thode basée sur les anaglyphes. Pour utiliser cette méthode, il est nécessaire de s'équiperde deux projecteurs, ainsi que de ltres polarisés qu'il faudra placer devant chacun d'eux.Il est également indispensable de s'équiper de lunettes polarisées, compatibles avec lesltres placés sur les projecteurs. Au total, plusieurs milliers d'euros sont nécessaires à lamise en place d'un tel système.

En plus de son prix élevé, la mise en place d'une solution basée sur la polarisationrequiert une mise en oeuvre beaucoup plus importante. La présence de deux projecteursétant indispensable, la solution est bien plus dicile à déplacer, comparée à celle utilisantles anaglyphes, qui ne requiert aucun écran spécial, et une simple paire de lunettes.

2.1.6.3 Obturation

Le système de lunettes à obturation (Liquid Crystal shutter glasses en anglais) est unesolution alternative à l'utilisation de la polarisation, de plus en plus utilisée pour le grandpublic, pour visualiser des images en relief.

De nos jours, de plus en plus de télévisions estampillées 3D Ready font leur apparitiondans les grandes surfaces. La plupart de ces télévisions requièrent l'utilisation de lunettesà obturation pour obtenir un eet de relief dans l'image achée.

D'un point de vue technique, la visualisation d'images en trois dimensions est possiblegrâce à l'utilisation de lunettes spéciales. Ces lunettes contiennent des verres à l'intérieurdesquels une couche de cristaux liquides est contenue. Cette couche a la particularitéde pouvoir s'assombrir très rapidement lorsqu'une tension électrique lui est appliquée.Lorsqu'aucune tension électrique ne lui est appliquée, la couche de cristaux liquides esttranslucide et laisse donc passer la lumière.

Comme pour tous les procédés permettant de voir des images en relief, cette méthodeache une image diérente pour chaque oeil. C'est donc la manière dont les images par-viennent à chaque oeil qui dière. Comme les lunettes sont capables de s'obturer à une trèsgrande vitesse, il est possible de ne laisser passer la lumière que pour un seul oeil durantune très courte période (typiquement 1/60ede seconde). Le procédé utilisé est donc le sui-vant : pendant que l'image est projetée à l'écran, son taux de rafraîchissement est mesuré.Les lunettes se synchronisent alors et obturent successivement l'oeil gauche, puis l'oeildroit à la même vitesse que le taux de rafraîchissement de l'écran. Une image sur deuxsera donc visible uniquement par l'oeil gauche/droit. Pour permettre cette synchronisa-tion, la télévision est équipée d'un émetteur infrarouge, qui envoie aux lunettes un signalde timing leur permettant de s'adapter au taux de rafraîchissement de l'écran. Notonsque d'autres méthodes existent pour eectuer cette synchronisation entre la télévision etles lunettes. Parmi celles-ci, nous citerons le DLP-Link, qui ne nécessite pas d'émetteurinfrarouge. Durant la projection, un bref ash de lumière est émis par le téléviseur, lorsde la transition entre l'image destinée à l'oeil gauche et celle destinée à l'oeil droit. Leslunettes utilisent ce signal pour changer l'obturation de l'oeil droit à l'oeil gauche. Lemême signal est utilisé lors du passage de l'oeil droit à l'oeil gauche.

Le principal avantage de l'obturation est que la télévision projette successivementune image pour chaque oeil. Comme les deux images ne sont jamais présentes en mêmetemps sur l'écran, la qualité du relief est meilleure qu'avec un système à polarisation, qui atendance à parfois acher des images oues, comme montré sur la gure 2.11. Cependant,

29

Figure 2.11: Eet de ghosting [4]

comme chaque oeil ne voit qu'une image sur deux, il ne reçoit que la moitié du taux derafraîchissement eectif du téléviseur qui doit alors être important (supérieur à 120Hz)pour éviter l'eet de clignotement.

2.2 Choix informatiques

Lors du développement d'un projet logiciel, il est nécessaire de choisir un langageadapté au travail réalisé. En fonction des besoins requis par l'application, certaines carac-téristiques d'un langage sont parfois intéressantes. L'exemple le plus simple est l'utilisationd'un langage fonctionnel pour réaliser des calculs mathématiques. Pour notre travail, noussouhaitons développer une application temps réel qui soit portable et réutilisable. De plus,an d'éviter de réinventer la roue, il est souhaitable de choisir un langage pour lequel unelibrairie capable d'interagir avec la Wiimote existe. Le choix d'un langage adapté seradonc déterminé par la réalisation de ces diérents besoins.

2.2.1 Besoins du langage

Pour implémenter le concept de headtracking, une chose importante est de se munird'une librairie ecace. Lors de nos recherches, nous avons pu constater qu'une multitudede libraires permettant de contrôler la Wiimote existent. Ces librairies sont présentes dansdiérents langages de programmation, tels que C, C#, Java, Python. Malheureusement,pour bon nombre de ces librairies, la documentation présente est très restreinte, ce quine permet pas à un développeur de pouvoir les utiliser facilement, sans avoir à se plongerdans le code source (c'est par exemple le cas de Cwiid, une librairie développée en Cpour interagir avec la Wiimote). Nous avons également remarqué que certaines librairiesfonctionnaient mieux que d'autres. Lors de nos tests, nous avons essayé plusieurs librairies,parmi celles-ci, nous en avons extrait trois qui semblaient adéquates pour le travail quenous souhaitons réaliser.

30

1. Cwiid [2] : il s'agit d'une librairie développée en C, qui permet d'interagir avec laWiimote. Cwiid est disponible sur les dépôts d'ubuntu et peut donc être facilementtéléchargé. Pour fonctionner, il est nécessaire d'installer diverses librairies gérantl'interface bluetooth. Son principal défaut est le manque de documentation, quirend son utilisation pour le développement assez dicile.

2. WiiRemoteJ [8] est une API développée en Java, qui permet de communiquer avecla Wiimote. La documentation concernant cette librairie est très riche, et faciliteson utilisation. Malheureusement, sa robustesse est assez faible. La communicationavec bluetooth est assez instable, ce qui rend son utilisation assez aléatoire.

3. Wiiuse [26] est la librairie la plus intéressante que nous avons rencontrée. Sa docu-mentation est susante pour comprendre son utilisation. Sa prise en main est trèsaisée, et sa robustesse est plus importante que celle de la librairie WiiRemoteJ. Lorsde nos recherche, nous avons pu constater que Wiiuse semblait être la librairie laplus utilisée sur Internet.

Une fois le choix d'une bonne librairie eectué, il est nécessaire d'opter pour un langagequi puisse interagir ecacement avec celle-ci. Nous souhaitons programmer une applica-tion temps réel, il est donc impératif d'utiliser un langage qui soit non seulement robuste,mais aussi susamment rapide pour interagir avec la librairie choisie. Avec la puissancegrandissante des ordinateurs, la plupart des langages récents, même de haut niveau ouinterprété, sont capables de gérer des applications multimédia en temps réel. Le critèrede performance est donc de moindre importance, même si l'utilisation d'un langage per-formant nous permettrait de représenter des scènes plus complexes. Toutefois, poussé àl'extrême, ce raisonnement ne nous aurait jamais permis de passer à des langages deplus haut niveau, et l'assembleur serait toujours le langage le plus utilisé. De nos jours,l'utilisation d'un langage de haut niveau s'impose presque comme un standard, car il estimportant de privilégier la qualité du code, ainsi que sa lisibilité, an de rendre son évo-lution plus aisée.

Puisque nous souhaitons développer des applications avec un rendu en trois dimen-sions, notre langage doit posséder une API 3D. La plupart des langages de haut niveaupossèdent une telle librairie. La plus connue est OpenGL [6]. Il s'agit d'une librairie gra-phique, multiplateforme, qui possède une implémentation dans de très nombreux langagesde programmation. OpenGL est presque considéré comme un standard et est la librairiegraphique la plus utilisée dans le monde scientique et industriel.

Lors du développement d'une application, la portabilité est un atout majeur, pourêtre utilisable sous diérentes plateformes, telles que Windows, Unix (incluant MacOS)ou Linux. Le principal avantage d'un langage portable est qu'une application développéene nécessite que peu voire pas de changement pour fonctionner sur diérents systèmesd'exploitation.

2.2.2 Choix du langage et argumentation

Un des langages qui rencontre tous les besoins de notre module headtracking est lelangage Java. Dans la suite de cette section, nous montrerons que ce langage est un bonchoix pour ce type de programme.

31

2.2.2.1 Ecacité de la librairie

La première chose à aborder est la librairie utilisée pour interagir avec la camérainfrarouge (la Wiimote). Parmi celles qui ont été testées, la plus ecace et la mieux docu-mentée est Wiiuse [26]. Cette librairie a été implémentée en C, un choix particulièrementintéressant puisque l'interaction avec un contrôleur est un travail d'assez bas niveau quirequiert l'utilisation de sémaphores, de threads, etc et dont le protocole de communicationest souvent proche du langage machine.

L'avantage du Java est la présence de l'interface JNI (Java Native Interface). À titreinformatif pour le lecteur, les couches bas-niveau de Java ont été écrites en C. JNI estune interface qui permet d'utiliser du code C via un appel de méthode en Java. Pour plusd'informations sur JNI, consulter [13]. La librairie Wiiuse a ainsi pu être étendue au Javavia l'utilisation de JNI et le nouveau nom accompagnant cette interface est WiiuseJ [27].Cette interface est donc toute indiquée puisqu'elle eectue du code C via un appel deméthode en Java. Cette technique nous permet donc de communiquer via le langage Javaà une vitesse très correcte avec notre librairie. Pour nous convaincre de la réactivité ob-tenue grâce à la librairie WiiuseJ, nous avons eectué un petit benchmark où nous avonsmesuré le nombre d'évènements moyen par seconde que la librairie est capable de traiter.En moyenne, les résultats montrent que plus de 60 évènements peuvent être gérés chaqueseconde, c'est-à-dire un temps de réponse moyen de l'ordre de 15ms. Dans le pire des cas,il peut arriver que le nombre d'évènements chute à 25 par seconde (temps de réponsed'environ 40 ms), ce qui reste toutefois raisonnable.

Dans le cadre de notre travail, nous n'exploitons qu'une petite partie de cette librairie.La seule partie qui nous intéresse est celle qui gère la caméra infrarouge. Une fois la caméraactivée, nous pouvons invoquer des méthodes sur notre Wiimote qui nous permettent derécupérer des points infrarouges sur le capteur (sous la forme d'un objet de type IRDot).De ces points infrarouges, nous pouvons tirer un certain nombre de renseignements, telsque leur position ou encore leur intensité (codée sur un entier positif de 4 bits). Ces infor-mations sont susantes pour calculer la position de la tête d'un utilisateur par rapport àla caméra.

2.2.2.2 Rapidité du langage

Le langage Java est un langage de haut niveau qui est compilé (c'est-à-dire qu'avantde l'exécuter, il est nécessaire de le traduire en un programme plus bas niveau appelébytecode, an qu'il puisse être exécuté par la machine). Un avantage d'un langage compiléest qu'il est très souvent plus rapide que son opposé, le langage interprété. De plus, il estbon de savoir que pour des calculs mathématiques, et c'est principalement l'objet denotre travail, le Java est un langage susament rapide notamment grâce à la présencedes types primitifs Pour représenter les nombres 4. Les performances du langage Java sontdonc plutôt correctes, malgré qu'il tourne sur une machine virtuelle, ce qui le rend moins

4. Pour se faire une meilleure idée des performances de Java, un article discutant de ses performancesa été réalisé sur Wikipédia. Il peut être visité à cette adresse http://en.wikipedia.org/wiki/Java_

performance. Bien qu'il soit plutôt objectif, ce type d'article ne doit pas être considéré comme une réalitéabsolue. La lecture de Statistically rigorous java performance evaluation [19] pourrait nous donner unemeilleure idée de ses performances

32

performant qu'un langage compilé nativement (Nous parlerons un peu plus en détail dela machine virtuelle dans la partie suivante, portabilité).

Le but de notre programme est de créer une application temps réel, elle doit donc êtreréactive. C'est pourquoi il est important d'utiliser un langage susamment rapide. Eneet, pour de petites applications, un langage interprété peut sure. Cependant, il pour-rait se montrer insusant pour représenter un grand nombre de formes assez complexes ettraiter un grand nombre d'informations avant de pouvoir rafraîchir l'image comme c'estle cas ici, puisqu'il est nécessaire de recalculer la position de l'utilisateur avant de pouvoirla rafraichir. Pour éviter ce type de problèmes, nous préférons utiliser un langage compilé.

2.2.2.3 Portabilité

Un autre avantage non négligeable du Java est sa portabilité. Un langage portablesignie qu'il peut être executé sur diérentes machines en ne nécéssitant que peu, voirpas de modications. La plupart des langages sont adaptables, cela signie qu'ils peuventfonctionner sur plusieurs machines sans être nécessairement modiés, mais il est néces-saire de les recompiler à chaque fois qu'on change de machine. Cette contrainte n'est pasprésente dans le langage Java. Une fois traduit en bytecode le programme peut être exé-cuté sur n'importe quelle machine, quelque soit son système d'exploitation sans devoir lerecompiler. Cet avantage est dû à l'utilisation d'une machine virtuelle

Une machine virtuelle est un procédé permettant de simuler le travail d'unemachine de façon logicielle. Dans le cas de la machine virtuelle Java (JVM),le programme Java est converti en un code compréhensible et exécutable parcette machine virtuelle. De cette façon, un même code peut être utilisé surn'importe quelle couple machine/plateforme en donnant les mêmes résultats,puisque le code est exécuté via la JVM. Chaque plateforme possède sa propreJVM [16].

L'utilisation d'une machine virtuelle, comparée à un code natif entraîne une légère pertede performances, toutefois, elles restent supérieures à celle d'un langage interprété.

Dans le cadre de notre projet, la portabilité est un atout important car elle nous assurela compatibilité avec n'importe quelle machine (pourvue de Java). Le programme créépourra donc être utilisé sur n'importe quel type de machine, moyennant la compilationdes librairies C utilisées.

2.2.2.4 Orienté Objet

En permettant la programmation de type orienté objet (POO), le Java est un langagequi permet de développer simplement, en considérant que chaque composant est un objet,à l'exception des nombres, qui sont des types primitifs. De plus, le concept d'interface nousest très utile pour permettre une bonne portabilité. Grâce à cette notion, notre modulecontiendra une interface HeadtrackedCamera et une classe CameraHandler qui utilise unobjet implémentant l'interface HeadtrackedCamera pour diriger la caméra. Ces classes in-teragissent directement avec la Wiimote via le système de gestion d'évènements. À chaquefois que le capteur infrarouge détecte un mouvement d'une source infrarouge, il pourra

33

le notier à la classe WiimoteHandler, qui se chargera à son tour d'appeller la méthodehandleEvent() de la calsse CameraHandler. La classe CameraHandler pourra alors modi-er les variables de position de la caméra contenues dans l'interface HeadtrackedCamera.La POO permet donc de programmer tout en gardant une structure claire ou chaqueobjet eectue un travail précis (concept de cohésion), cela permet une meilleure lisibilitéqu'un programme entièrement codé avec un paradigme procédural tel que le C.

Une fois le concept de POO bien maîtrisé, il est assez simple d'implémenter des pro-grammes qui sont en réalité complexes, grâce aux concepts d'emboîtement et d'intéractionentre les diérents objets qui seront créés. Pour réaliser une application de grande enver-gure, celui-ci peut être séparé en plusieurs modules distincts, dont chacun eectuera unepartie précise du travail demandé par l'application.

Pour en revenir à la gestion évènementielle, nous noterons que ce concept est largementutilisé à diérents endroits de l'application. C'est le cas de la détection des mouvementspour le headtracking. Lorsqu'un mouvement de la main est détecté, un appel à une mé-thode de l'interface MovementListener est alors automatiquement déclenché. La gestiondes bords de la caméra utilise elle aussi la gestion évènementielle. Lorsqu'une source in-frarouge s'approche d'un des bords du capteur, un évènement est déclenché, qui provoquela coloration du bord de l'écran correspondant au bord du capteur dont la source serapproche.

2.2.2.5 API 3D

En plus de toutes ces qualités, le Java est capable de travailler avec la célèbre librairie3D OpenGL. Dans le monde de la 3D, il existe 2 grands noms, Direct3D et OpenGL. Cesont les deux librairies les plus avancées et les plus stables en la matière. La première li-brairie est directement liée au systeme d'exploitation Windows, elle est donc dépendanted'un système d'exploitation payant et n'est pas multi-plateforme. La seconde librairiecomme son nom l'indique est open-source et possède une implémentation dans la plupartdes langages actuels. l'OpenGL est donc un choix qui s'impose si nous voulons une appli-cation stable, mais aussi utilisable par tous.

En Java, il existe aussi une librairie nommée Java3D, cette librairie est en fait unbinding qui fait appel à des fonctions OpenGL ou Direct3D, ce n'est donc pas une implé-mentation à part entière d'une librairie 3D propre à Java.

L'intégration de OpenGL dans le langage Java est possible en plaçant le contexteOpenGL de la scène dans une fenêtre graphique de awt ou swing. Cela nous permettradonc d'intégrer ce composant dans une interface graphique complète, réalisée avec l'apiswing. Cette interface graphique nous permettra de contrôler les nombreux paramètresde l'application réalisée.

2.2.2.6 Perfectionnement du langage

La dernière motivation concernant le Java concerne l'opportunité de perfectionner unlangage déjà maîtrisé. En eet, nous avons appris à utiliser ce langage pour réaliser des

34

applications diverses.

L'utilisation d'une librairie graphique 3D est une des chose qui n'a pas encore été réa-lisée dans ce langage, cette occasion est donc intéressante pour découvrir les possibilitésdu Java en termes de rendu en trois dimensions.

Enn, le développement de notre application demande une certaine richesse de pro-grammation. Nous développerons des interfaces, utiliserons les concepts d'héritage et degestion évènementielle. Un ensemble de concept déjà connu qu'il nous sera une fois deplus possible de perfectionner, grâce à la réalisation d'une application conséquente.

Remarquons que le Java n'est pas un silver bullet il a, comme tous les langages cespetits défauts. Nous pourrions par exemple lui reprocher d'être très verbeux (la réalisationd'un application simple demande parfois un grand nombre de lignes de code, pour faireau nal peu de choses). Aussi, sa vitesse n'est en général pas comparable à celle desautres langages compilés, à cause du bytecode généré. Cependant, sa portabilité et sonexpressivité pèsent lourdement de l'autre coté de la balance.

Java n'est donc pas le langage absolu pour réaliser notre application. D'autres langagesauraient pu convenir, comme le C++ par exemple.

2.2.3 Idées alternatives

Plutôt que de rechercher un langage qui nous permette de communiquer aisément avecla librairie qui sera utilisée, il aurait été possible d'utiliser n'importe quel autre langage,même s'il ne permet pas d'interagir directement avec la librairie.

Une solution simple aurait été de récupérer les données renvoyées par la librairie et deles écrire dans un chier à chaque mouvement de l'utilisateur. En pratique cette solutionest tout à fait possible. Gardons toutefois en tête que notre application devra interagir entemps réel avec l'utilisateur. Il est pour cela nécessaire que le temps de latence entre lemouvement réel et le mouvement simulé soit minimal. Or la lecture/écriture sur un chierest un procédé d'entrée/sortie dont la vitesse est de loin inférieure à une simple gestiond'évènement en Java. Pour cette raison, cette solution a très vite été écartée au prot del'utilisation d'un seul langage pour réaliser l'ensemble de l'application.

Plutôt que de dialoguer entre diérents langages via des chiers, il est aussi possibled'utiliser le procédé de mémoire partagée ou de pipeline entre le processus détectant lesmouvements sur le capteur infrarouges et celui s'occupant de traiter l'information reçuepour simuler le déplacement de la tête dans une application 3D. Ce procédé est bien plusrapide que la lecture écriture sur un chier puisque le pipelining s'exécute sur la mémoireprincipale de l'ordinateur (la RAM). Cette solution n'a pas été retenue car sa mise enplace aurait pris un temps inutile, puisque l'interface JNI nous ore déjà tout ce dontnous avons besoin.

35

Figure 2.12: Repère Wiimote/joueur/TV

2.3 Concepts théoriques

Dans cette section, nous détaillerons les concepts théoriques utilisés pour la mise enoeuvre du headtracking et du handtracking. Nous discuterons notamment du modèle ma-thématique utilisé pour simuler les mouvements d'un utilisateur de façon réaliste, ansi quedes concepts théoriques inhérents à l'eet fenêtre. Nous eectuerons également quelquesrappels de mécanique théorique, qui nous serons utiles à la compréhension de l'implémen-tation du jeu de pong, en ce qui concerne la modélisation des mouvements de la balle detennis de table.

2.3.1 Concernant le headtracking

Commençons par détailler comment fonctionne le headtracking. Supposons que lacaméra infrarouge est placée sous l'écran, et qu'elle regarde dans une direction perpendi-culaire à celui-ci, comme le montre la gure 2.12. Nous pouvons voir du dessus, en grisfoncé l'écran, en bleu la wiimote et son champ de vision, ainsi qu'en rouge les axes x et y.

Pour nos calculs, nous utilisons un repère orthonormé dont l'axe des abscisses est

36

l'axe x sur la gure, l'axe des ordonnées est celui des y, et l'axe des cotes correspond àl'axe z, qui sort de l'écran. Le point (0,0,0) est situé là ou est plaçée notre caméra. l'axedes x délimite donc la frontière entre le monde réel et le monde virtuel représenté à l'écran.

La première chose que nous devons faire est calculer la distance entre l'utilisateur etla caméra. Supposons que celui-ci se trouve au point p. Comme expliqué à la section 2.1,il y a deux sources infrarouges sur le capteur, correspondant chacune à une des deuxsources présente sur la paire de lunettes. Comme nous avons besoin d'un seul point, nousconsidérons que le point p est le milieu des deux sources (juste entre les deux yeux). Pourcalculer la distance entre l'utilisateur et la caméra, nous pouvons utiliser le principe ma-thématique suivant :

Soit Ω un cercle de centre (0,0) et de rayon r (cf gure 2.13 ).Considérons l'arc de cercle formé par deux rayons séparés par un angle α, cet arc de cerclea une longueur α ∗ r (alpha est en radians).Si le rayon de ce cercle passe de r à 2r, alors la taille de l'arc de cercle passe de α ∗ r àα ∗ 2r. Sa taille est donc deux fois plus importante.

Figure 2.13: cercles et leurs arcs

Appliquons cette propriété à notre capteur. En réalité, la résolution qu'il peut observerest xe, par conséquent, lorsqu'un objet s'éloigne d'une distance x à une distance 2x, cet

37

objet est vu sur un arc de cercle deux fois plus grand (l'arc de cercle est un arc virtuelqui contient tous les points situés à une distance x du capteur). Comme notre capteur estde taille xe, l'objet sera donc perçu comme ayant une taille deux fois plus petite. Cettepropriété nous permet donc d'établir que la distance entre les deux sources infrarougesdécroît selon une hyperbole parfaite (d'équation y = 1

x). De cette façon, si nous connais-

sons la distance en millimètres entre les deux sources infrarouges, nous pouvons aisémentcalculer à quelle distance se trouve l'utilisateur portant les lunettes. Pour ce faire, nousdevons connaître la distance en pixels entre nos sources infrarouge à une distance arbi-traire de vingt centimètres. Ce calcul sert donc de base, puisque nous savons qu'à 40cm lenombre de pixels entre les deux sources sera divisé par deux. Ce calcul doit bien entenduêtre relativisé par la distance réelle qui sépare les leds. De cette façon, si nous utilisons undispositif d'émission d'infrarouges diérent, il sut de modier la valeur en millimètresd'une variable contenant la distance entre les deux sources infrarouge.

À présent que nous savons calculer la distance entre les points, nous avons tout ce qu'ilnous faut pour calculer la position de l'utilisateur dans le plan. Soit p, cette position. Nousla calculons comme suit :Considérons le triangle rectangle formé par les points np, p et o (cf g 2.14). Ce triangleest bien rectangle par construction puisque le point np est le projeté orthogonal de p surla normale du capteur (l'axe y). Pour calculer la position p, nous devons calculer l'angleα. Dans nos calculs, nous allons approximer la distance |np − p| par la longueur de l'arcde cercle formé entre np et p. Comme l'angle est assez petit (ne dépasse pas 20° de chaquecôté de la normale) l'erreur commise est assez faible.

Pour calculer cette erreur, nous devons calculer la diérence de longueur entre le rayondu cercle de centre o et de rayon h et le coté adjacent à l'angle α du triangle rectangleformé par les points o, p et np. Cette diérence de longueur est la diérence de longueurentre l'hypothénuse et le coté adjacent à l'angle α de ce même triangle rectangle.

Pour un triangle rectangle dont l'angle α vaut 21° et la longueur de l'hypothénuse vaut1, la longueur du coté adjacent est de cos(21°)=0,933. L'erreur commise est donc inférieurà 7%, si l'angle ne dépasse pas 21°.

En OpenGL, la plupart des représentations géométriques ne sont pas 100% correctes.Nous pouvons donc estimer que ce facteur d'erreur ne nuira pas à la qualité du headtra-cking.

Cette erreur sera plus importante lorsque l'angle α grandit, et donc la qualité du head-tracking pourrait être légèrement détériorée avec des angles importants, si nous utilisonsplusieurs Wiimotes. Un facteur de correction pourra alors être introduit pour limiter cetteerreur. En fonction de l'angle formé entre la normale de la caméra et la position de l'uti-lisateur, nous pouvons calculer l'erreur commise, comme nous l'avons fait ci-dessus, etintroduire un facteur de correction au calcul de la position.

Pour calculer la valeur de l'angle horizontal α, formé entre la caméra et l'utilisatuer,nous calculons dans le triangle virtuel représenté à la gure 2.15. Supposons que la camérapossède un angle horizontal de 42°, cela signie qu'elle a un angle de 21° de chaque cotéde sa normale. comme le capteur a une taille horizontale de 1024 pixels, Nous pouvonsdire que

38

Figure 2.14: Triangle rectangle dans le champ de vision

39

Figure 2.15: Triangle virtuel

Tan(21) = 512x

et par conséquent,

x = 5120.38

= 1347, 36

Le coté opposé de l'angle de 21° a donc une longueur de 1347,36.Nous pouvons à présent calculer l'angle horizontal pour n'importe quel point p sur lecapteur (le point milieu des deux sources infrarouges). Considérons la distance en pixelsentre le centre du capteur (sa normale) et le point p, notons cette valeur x (cf gure2.16). Il y a un angle α entre la normale et le coté formé en joignant p au point o.Comme nous connaissons la valeur de x, ainsi que la valeur du coté opposé de l'angle α(longueur de 1347,36), nous pouvons calculer l'angle par la formule suivante :

α = Atan( x1347,36

).

Grâce à cette formule, nous connaissons la valeur de α . Il est a présent aisé de calculerla coordonnée x du point p grâce à la formule

sin(α) = cote−opposehypothenuse

calculons px, en utilisant cette formule :

px = hypothenuse ∗ sin(α)

40

Figure 2.16: Angle dans le triangle virtuel

41

où hypothénuse est la distance réelle calculée à partir de la distance entre les deuxsources infrarouges, et α est l'angle calculé à l'aide du triangle virtuel.

L'ensemble de ces calculs ayant été eectué pour la dimension horizontale, Le calculde l'angel vertical est eectué en modiant les valeurs qui distinguent le cas horizontal ducas vertical (tel que l'angle, qui passe de 42° à 33°, et la taille du coté opposé du trianglevirtuel sera par conséquent diérente). Les résultats obtenus pourront être utilisés pourcalculer la coordonnée z du point p. C'est pourquoi nous ne détaillerons pas ces calculsici, et laissons le soin au lecteur de les eectuer s'il le souhaite.

2.3.2 Concernant le handtracking

Passons à présent au module handtracking. La partie de ce module permettant de dé-placer des objets nécéssite quelques précisions quant à la méthode employée pour calculerla position de la main, en utilisant une seule led.

L'inconvénient majeur, en utilisant une seule source infrarouge pour détecter la po-sition de la main, est qu'il n'est pas possible (avec une seule Wiimote) de calculer ladistance à laquelle se trouve la main. Nous devrons donc utiliser un artice pour savoirà quelle profondeur il faut placer la main. Celui-ci est en réalité très simple : l'utilisationdu handtracking se fait toujours en complément du headtracking. En eet, si le headtra-cking n'était pas utilisé, nous aurions pû utiliser deux sources infrarouges pour situer lamain dans l'espace. Comme nous savons calculer la position de la tête de l'utilisateur,nous pouvons supposer que la main de celui-ci se trouve légèrement en avant par rapportà sa tête. Lorsque nous souhaitons interagir avec les mains, nous les plaçons devant lecorps. Il sut alors de xer la position de la main à une distance de quelques dizainesde centimètres en avant du visage. Cette valeur doit être choisie judicieusement pour quel'eet rendu soit le plus réaliste possible.

Une fois la distance estimée, nous pouvons raisonner en utilisant une seule sourceinfrarouge, exactement de la même façon que pour détecter la tête avec le headtracking.En eet, lorsque nous avons calculé dans le triangle rectangle formé par la normale de lacaméra, la distance caméra/utilisateur, et la distance caméra/normale, nous avons utiliséun seul point qui était situé au milieu des deux sources infrarouge. Par conséquent, lehandtracking ne nécéssite pas l'introduction de concepts théoriques nouveaux, car nouspouvons réutiliser ceux qui ont été introduits pour le headtracking.

2.3.3 Concernant l'eet fenêtre

Pour réaliser une application de headtracking mettant en oeuvre un eet fenêtre, c'està dire, une image projetée à l'écran dont la partie visible est modiée, en temps réel, enfonction de la position de l'utilisateur par rapport à l'écran. L'écran se comporte alorscomme une fenêtre, au travers de laquelle une scène est visionnée.

La principale diculté de cette application consiste à calculer la partie de l'image quidoit être visible, en fonction de la position de l'utilisateur par rapport à l'écran. Nousexpliquons ci-dessous comment ce calcul est eectué pour la dimension horizontale. Le

42

Figure 2.17: Schématisation de l'eet fenêtre

passage à la dimension verticale implique des calculs similaires que nous ne présenteronspas dans ce document.

Considérons la gure 2.17, celle-ci représente une vue schématique du dessus, où l'utili-sateur est représenté au point p, l'écran correspond au rectangle bleu, et la scène à achers'étend du point m au point n. Nous cherchons à déterminer la position des points A etB.

Considérons la droite d1 passant par le point p et coupant le bord gauche de l'écran.Cette droite coupe la scène au point A. considérons également la droite d2 qui passe parle point p et coupant le bord droit de l'écran. Cette droite coupe la scène au point B. Nousconnaissons la distance qui sépare la scène de l'écran, cette distance est d. Nous savonségalement que l'écran possède une largeur e, et que le point p se trouve aux coordonnées(px, py).

Le calcul du point A consiste donc à trouver l'intersection entre deux droite. La pre-mière de ces deux droites est la scène, dont l'équation est y = d. Pour trouver la positiondu point A, il nous sut de calculer l'équation de la droite passant par le point p et lebord gauche de l'écran situé en eright = (− e

2, 0). L'équation d'une droite passant par deux

points étant :

y − ya=m(x−xa) où m = (yb−ya)(xb−xa)

Il nous sut alors de remplacer les valeurs par les données que nous connaissons pourcalculer l'équation de la droite A. Pour trouver la coordonnée x du point A, il nous reste

43

à remplacer y par d dans l'équation. Sachant que d est la coordonnée y du point A. Nousobtenons alors :

x =d− py +m.px

m

La coordonnée du point A est donc (x, d). Nous calculons le point B de façon similaire.Comme la droite formée par le point p et le point B passe en toute logique, elle aussi, parle point p. La coordonnée du point B est (x, d), où x est calculé de la même façon quepour A, mais avec un m diérent (puisque le second point correspond au bord droit del'écran, situé en ( e

2, 0).

Après avoir calculé la position des points C et D, qui correspondent aux point A etB, mais pour calculer la portion verticale visible de l'image, nous connaissons les quatresbords visibles de l'image, et savons donc quelle partie de l'image acher.

2.3.4 Rappels de mécanique

Le dernier concept théorique que nous présenterons consiste en un très bref rappel deséquations de mouvements issues de la mécanique. Ces équations nous sont utiles lors dela réalisation du jeu de pong, an de modéliser la trajectoire de la balle.

La première équation que nous utilisons est l'équation du mouvement rectiligne uni-forme ou MRU. Cette formule caractérise un mobile se déplaçant à une vitesse constante.L'équation du MRU est la suivante :

pos(t) = v0.t+ x0

Où v0 correspond à la vitesse initiale, t correspond au temps, et x0 est la positioninitiale du mobile. Cette formule est utilisée pour caractériser le déplacement latéral etlongitudinal de la balle de tennis de table. En eet, lorsque la balle est envoyée vers lejoueur opposé avec un angle horizontal α, la balle se déplace à vitesse constante dans ladirection correspondant à l'angle. La vitesse du mobile selon l'axe des x (horizontal) estalors

v0x = v0.cos(α)

Le déplacement longitudinal de la balle est lui aussi caractérisé par un MRU. Si laballe est envoyée avec un angle vertical β, la vitesse selon l'axe y (longitudinal) est :

v0y = v0.cos(β)

La seconde équation est utilisée pour caractériser le mouvement de la balle selon ledernier axe, l'axe z, qui correspond à la verticale. Cet axe étant soumis à la gravité, uneéquation de type MRU ne sut pas, nous devons utiliser une équation de mouvementrectiligne uniformément accéléré ou MRUA dont l'équation est la suivante :

pos(t) =1

2a.t2 + v0.t+ x0

44

Le facteur a correspondant à l'accélération du mobile, qui aura une valeur de -9,81dans notre cas, puisque l'accélération subie par le mobile est la gravité terrestre.

Grâce à ces deux équations, nous sommes a présent capables de calculer le mouvementde la balle de tennis de table, durant une partie, entre chaque rebond. Lorsqu'un rebonda lieu, la balle est simplement relancée à partir d'une nouvelle position initiale, avec unangle vertical égal à l'angle d'arrivée de la balle sur la table, juste avant le rebond. L'anglehorizontal est quant à lui conservé, car aucun eet n'est donné à la balle.

45

Chapitre 3

Implémentation du module

A présent que nous maîtrisons les concepts théoriques nécessaires à une bonne com-préhension du problème, nous pouvons détailler l'implémentation de chaque partie desmodules. Dans la suite de ce chapitre, nous présenterons un aperçu général des classescréées avant de détailler les liens présents entre les parties les plus importantes. Nous dé-taillerons ensuite les classes et interfaces qui jouent un rôlé clé dans chacun des modulesdéveloppés.

3.1 Vue d'ensemble

Comme l'a dit un jour un Napoléon : Un bon croquis vaut mieux qu'un long discours.Typiquement, en informatique, la présence d'un diagramme de classe permet de faciliterla compréhension d'un programme. Grâce à ce type de schéma, nous pouvons avoir unevue de haut niveau des classes, de leur interface publique, ainsi que de liens qui les unissent.

Le schéma de la gure 3.1 nous montre un diagramme de classe épuré contenant cha-cune des classes ayant un rôle important dans la réalisation de notre application. Lesinterfaces sont représentées en bleu, et les classes en beige. Par soucis de lisibilité nousn'avons intégré que les signatures de méthodes importantes dans la représentation desclasses. Les attributs ne sont pas représentés.

Cette gure nous montre que quatre interfaces sont présentes dans notre projet, cesinterfaces seront expliquées dans les sections 3.3.1, 3.4.1, 3.5.1 et 3.5.3. Trois de ces quatreinterfaces jouent un rôle clé dans la portabilité de l'application. Ce sont ces interfaces quipermettent à un développeur d'utiliser notre module, en respectant les signatures de mé-thodes qui y sont présentes.

Au niveau des classes, nous pouvons séparer l'ensemble des classes présentes en troisgroupes distincts :

1. Les classes qui concernent la gestion du headtracking : CameraHandler, ShakeDe-tector, BorderPainter, Windowed View et Camera

2. Les classes qui correspondent au handtracking : HandMovementsDetector, Hand-Handler

46

Figure 3.1: Diagramme de classe (nettoyé) des modules

3. Les classes qui gèrent l'interface avec la Wiimote : WiimoteHand et WiimoteHea-dAndHand, qui héritent de WiimoteHandler

3.2 Utilisation de la librairie

Avant de détailler davantage l'implémentations des modules, il est nécessaire de sa-voir comment utiliser la librairie WiiuseJ, qui permet de communiquer avec la Wiimote.Comme nous n'utilisons que la caméra infrarouge de la Wiimote, l'utilisation de la librai-rie est assez simple.

Pour détecter les mouvements des sources infrarouges sur le capteur, il faut créer uneclasse qui implémente l'interface WiimoteListener. Cette interface contient des signaturesde méthodes qui sont automatiquement appelées lorsqu'un évènement issu de la Wiimoteest déclenché. Une seule méthode de l'interface WiimoteListener nous intéresse, il s'agitde onIrEvent(IREvent ir). Cette méthode est automatiquement appelée lorsqu'un mou-vement est détecté sur le capteur infrarouge de la Wiimote. Les informations concernantcet évènement sont contenues dans un objet de type IREvent. L'utilisation de la méthodeir.getIRPoints() permet alors de récupérer un tableau de sources infrarouges, duquel nouspouvons extraire les coordonnées des sources infrarouges sur le capteur de la Wiimote.

La connexion d'une Wiimote est eectuée à partir de la classe WiiUseApiManager.Les commandes à saisir pour connecter une Wiimote, activer sa caméra infrarouge et lalier au WiimoteListener sont dénies ci-dessous :

47

tryWiimote[] wiimotes = WiiUseApiManager.getWiimotes(1, true) ;wiimote = wiimotes[0] ;wiimote.activateIRTRacking() ;wiimote.addWiiMoteEventListeners(this) ;

catch(Exception e)e.printStackTrace() ;

Ces commandes doivent se situer dans un bloc try car elles sont susceptibles de renvoyerune exception si la connexion échoue.

3.3 Module headtracking

Maintenant que nous savons comment utiliser la librairie, nous pouvons détailler l'im-plémentation du module headtracking. Dans la suite de cette section, nous exposerons lesclasses importantes du module headtracking, et développerons les méthodes importantesqui sont propres à chaque classe.

3.3.1 HeadtrackedCamera

En termes de réutilisabilité, une bonne pratique est d'utiliser les Interfaces de Java.Celles-ci dénissent un ensemble de signatures de méthodes qui devront être respectéespar les classes qui l'implémentent.

Développer un système de headtracking réutilisable demande donc d'identier les ac-tions desquelles dépendent la position de la tête dans l'espace. Nous savons que le head-tracking consiste à déplacer la caméra virtuelle, présente dans la scène OpenGL, en accordavec les mouvements du visage de l'utilisateur. Cela signie que les paramètres dont dé-pendent le headtracking concernent la position de cette caméra.

Nous avons donc développé une interface HeadtrackedCamera dont le but est de pi-loter la caméra OpenGL. Cette interface est composée de 24 signatures de méthodes (12fonctions pour récupérer la valeur de chaque variable, 12 autres pour les modier). 18 deces fonctions correspondent à un paramètre de la fonction GluLookAt() d'OpenGL. Pourinformation, la fonction GluLookAt() est une primitive qui permet de contrôler la caméragrâce aux 9 paramètres suivants. A chacun de ces paramètres, nous avons associé, en bleu,la signature de l'interface HeadtrackedCamera qui permettra de piloter le paramètre.

1. cameraX - setCameraX(double x) / getCameraX() : permet de positionner la caméraà la position x sur l'axe des abscisses du repère de la scène

2. cameraY - setCameraY(double y) / getCameraY() : permet de positionner la caméraà la position y sur l'axe des ordonnées du repère de la scène

3. cameraZ - setCameraZ(double z) / getCameraZ() : permet de positionner la caméraà la position z sur l'axe des cotes du repère de la scène

48

4. eyeX - setCameraXLook(double x) / getCameraXLook() : permet de diriger la ca-méra pour qu'elle regarde en abscisse x

5. eyeY - setCameraYLook(double y) / getCameraYLook() : permet de diriger la ca-méra pour qu'elle regarde en ordonnée y

6. eyeZ - setCameraZLook(double z) / getCameraZLook() : permet de diriger la camérapour qu'elle regarde en cote z

7. upX - setUpX(double x) / getUpX() : upX, upY et upZ permettent de dénirle vecteur vertical. Si nous voulons que l'axe des cotes soit notre verticale, alorsnous donnerons respectivement les valeurs 0,0 et 1 à upX, upY et upZ. Dans notreapplication, la convention est d'utiliser l'axe des cotes (celui des z) comme verticale.

8. upY - setUpY(double y) / getUpY()

9. upZ - setUpZ(double z) / getUpZ()

Grâce à ces paramètres, nous pouvons donc contrôler tout ce qui concerne la caméra dansun monde en 3 dimensions.

Les six dernières signatures de méthode concernent la position initiale de la caméra,qui doit être modiable, pour s'adapter à n'importe quel type de scène. L'utilisation de cesparamètres permet également de déplacer la Caméra indépendamment du headtracking.Il est alors possible de déplacer la caméra avec une manette (ou en utilisant le clavier),sur de grandes distances, et en même temps d'utiliser le headtracking pour déplacer lacaméra sur une distance plus courte. Les méthodes permettant de déplacer la caméraindépendamment du headtracking sont les suivantes :

1. getInitX() / setInitX(double x)

2. getInitY() / setInitY(double y)

3. getInitZ() / setInitZ(double z)

Ces six signatures permettent d'accéder et de modier la position initiale de la caméra.Cette position initiale sera utilisée comme origine pour le placement de la caméra, enutilisant le headtracking.

Parlons à présent des conventions. Comme nous l'avons remarqué, les 3 derniers pa-ramètres de la fonction GluLookAt() nous permettent de dénir notre axe vertical. C'estdonc au programmeur de choisir ses propres conventions. Toutes les applications que nousdévelopperons utiliseront les conventions suivantes :

l'axe X est celui qui permet de se déplacer de gauche à droite par rapport à l'écran, l'axe Y s'enfonce dans l'écran, et permet donc d'avancer ou de reculer, l'axe Z représente la verticale et donc la hauteur de la scène.

Si une application ne respecte pas ces conventions, il sera alors nécessaire d'intervertir lesméthodes pour qu'elles correspondent aux conventions du module.

3.3.2 Camera

L'interface HeadtrackedCamera est très riche en termes de nombre de signatures. Celaest dû aux nombreux paramètres dont dépendent la position de la caméra. Pour limiter le

49

nombre de signatures, nous aurions pu renvoyer les données par triplets, contenant ainsiles données correspondant aux trois axes. Toutefois, l'encapsulation des données peut serévéler peu ecace, dans le cas où une seule des trois données doit être modiée. Laprésence d'un grand nombre de méthodes est donc un choix qui permet à l'utilisateurpotentiel du module de cibler les appels, limitant ainsi l'overhead dû à une encapsulationtrop importante.

Lorsqu'une scène OpenGL est créée, elle doit alors implémenter l'interface Headtra-ckedCamera. Pour améliorer la structure du code et éviter d'être contraints d'ajouterplus de 20 signatures de méthodes dans la classe représentant la scène, nous avons crééune classe Camera qui implémente l'interface HeadtrackedCamera. Douze variables d'ins-tances correspondant aux douze accessors et mutators ont été ajoutées dans cette classe.De cette façon, il sut de créer un objet de type Camera dans la scène OpenGL, et d'ac-céder à ses variables via les méthodes de l'interface HeadtrackedCamera.

L'utilisation de la classe Camera n'est pas nécessaire. Il est toujours possible d'utiliserdirectement l'interface HeadtrackedCamera dans l'application développée.

3.3.3 CameraHandler

Le coeur du module de headtracking est développé dans la classe CameraHandler. Sontravail est de récupérer les coordonnées des sources infrarouges issues de la Wiimote, etde calculer la position de l'utilisateur par rapport à celle-ci en fonction de la positiondes sources sur le capteur. Une fois la position calculée, elle met à jour la position de lacaméra qui a été préalablement passée à la construction de l'objet CameraHandler. Cetteclasse s'occupe également de gérer les intéractions au clavier, elle possède donc un lienavec la classe WiimoteHeadAndHand pour lui permettre de connecter une Wiimote oud'activer la caméra infrarouge en appuyant sur les touches R et I.

La gestion du clavier est assurée par KeyListener, l'interface par défaut de Java poureectuer ce type de travail. Implémenter cette interface nous permet de paramétrer notrescène grâce à l'appui sur certaines touches, donnant ainsi une plus grande liberté à l'uti-lisateur. Elle est composée de 3 méthodes, dont une seule nous servira, il s'agit de key-Pressed(KeyEvent e) qui est déclenchée lors de l'appui sur une touche du clavier. Cetteinterface est utilisée pour modier les paramètres suivants :

Modication de la position initiale de la caméra, qui permet d'ajuster la positioninitiale de la caméra pour tenir compte par exemple de la taille de l'utilisaeur, ouencore de sa position initiale dans la scène.

Modication du point de vue, qui permet de déplacer le point observé par la caméra. Modication de la sensibilité des déplacements et du headtracking, qui permet d'in-tensier ou de diminuer l'amplitude des mouvements de la tête de l'utilisateur dansl'application. Cela peut-être utile si l'utilisateur souhaite calibrer l'intensité des mou-vements pour les adapter à l'espace dont il dispose.

Connexion de la Wiimote et activation de la caméra infrarouge.La plus grande partie du travail de headtracking se déroule à l'intérieur de la méthodehandleEvent(IRSource[] ir). Lorsque l'utilisateur se déplace avec les lunettes sur les yeux,

50

il déclenche un évènement qui appelle la méthode onIREvent(IREvent ir) de la classeimplémentant l'interface WiimoteListener. Cette méthode se charge alors d'appeler hand-leEvent(), qui calcule la position de l'utilisateur par rapport à la caméra en se basant surles sources infrarouges passées en paramètre de la méthode onIREvent.

Si la détection des bords est activée, alors la méthode handleEvent se charge d'appelerla fonction handleBorders() dont le travail est de déclencher un évènement lorsque lessources infrarouges sont trop proches du capteur. Le calcul de cette proximité s'eectuesur base de paramètres modiables, de façon à pouvoir personnaliser la sensibilité de ladétection des bords.

Supposons que nous avons deux points infrarouges situés de part et d'autre de la pairede lunettes. Nous pouvons calculer la distance entre la caméra et la tête de l'utilisateuren utilisant les concepts vus dans la section 2.3. Nous savons que la distance entre lesdeux points suit une loi de type Hyperbolique lorsqu'on s'éloigne ou se rapproche de lacaméra, il est donc aisé de calculer la distance entre la tête et la caméra en se basantsur la distance entre les deux sources infrarouges. Ce calcul est eectué par la méthodegetRealDistance(x1, y1, x2, y2) de la classe 3DMath, qui utilise les deux points détectés(x1,y1) et (x2,y2) pour calculer la distance.

Une fois la distance calculée, nous calculons l'angle horizontal et vertical entre la nor-male de la caméra (située au centre de celle-ci) et la position courante de la tête (le pointqui représente la tête est situé au milieu des deux sources infrarouges). Nous pouvons uti-liser ces informations pour calculer la position exacte de la tête dans notre monde virtuel,grâce aux principes des trigonométries sur le triangle rectangle évoqués à la section 2.3.

Sur base de toutes ces informations, les variables contenues dans l'objet Camera sontmises à jour, et lors du prochain appel par Java à la fonction Display() 1, la fonctionGluLookAt() sera appelée avec ces nouveaux paramètres modiés. Il en résultera donc undéplacement de la caméra sur la scène, reproduisant le mouvement eectué par l'utilisa-teur.

3.3.4 WiimoteHandler

Pour gérer les intéractions avec la Wiimote, la classe WiimoteHandler a été implémen-tée. Il s'agit d'une classe générique qui implémente l'interface WiimoteListener. Toutes lesméthodes de cette interface y sont donc dénies. La principale utilité de cette classe est laprésence de deux fonctions qui sont reactivateIRTrack() et reconnectWiimote(). Ces deuxméthodes permettent respectivement, comme leur nom l'indique, de réactiver la camérainfrarouge de la Wiimote connectée (car l'activation ne fonctionne pas toujours) et dereconnecter la Wiimote, lorsque la connexion a échoué.

1. Pour information, la fonction Display est une fonction appellée en boucle par java de l'interfaceGLEventListener qui permet de dessiner la scène en OpenGL. Pour plus de détails, consulter la docu-mentation de Jogl [14].

51

Deux classes plus spéciques héritent de WiimoteHandler, il s'agit de WiimoteHea-dAndHand et de WiimoteHand.

3.3.4.1 WiimoteHeadAndHand

Le but de cette classe est de gérer les évènements infrarouges captés par la Wiimoteet d'envoyer les informations concernant l'évènement aux classes qui se chargeront de cal-culer la position de la caméra et, éventuellement, de la main.

Lors de la construction d'un objet de typeWiimoteHeadAndHand, il faut passer un Ca-meraHandler, et éventuellement un HandHandler. Comme nous l'avons précisé plus haut,cette classe hérite de WiimoteHandler. Elle implémente donc l'interface WiimoteListener,par transitivité. Pour donner un comportement plus spécique à la méthode onIREvent(),nous l'avons redénie dans cette classe. Son travail est très simple, elle est chargée d'appe-ler les méthodes handleEvent() de l'objet de type CamerHandler passé en paramètre, ethandleEventSimply() de l'objet de type HandHandler éventuellement passé en paramètre.Eventuellement, car le passage d'un HandHandler est optionnel. Deux constructeurs sontdénis dans la classe WiimoteHeadAndHand, le premier a déjà été cité, et le second nenécessite pas de HandHandler. Lorsque l'appel à la fonction onIREvent() est déclenchépar un évènement infrarouge, la présence d'un HandHandler est testée. S'il n'a pas étépassé lors de la construction alors l'appel à la fonction handleEventSimply() n'est paseectué.

3.3.4.2 WiimoteHand

Le comportement de cette classe, qui hérite de WiimoteHandler, est lié au handtra-cking. Pour construire un objet de type WiimoteHand, il faut lui passer en paramètredu constructeur un HandMovementsDetector, dont le but est de détecter les mouvementssimples de la main (voir section 3.5.3). Tout comme sa soeur, la classe WiimoteHand sur-charge la méthode onIREvent() pour lui donner un comportement plus spécique. Cettefonction est chargée d'appeler la méthode HandleEvent() de l'objet HandMovementsDe-tector passé en paramètre du constructeur.

3.3.4.3 Utilité du WiimoteHandler

Nous l'avons compris, les classes héritant de WiimoteHandler servent de relais entre lalibrairie WiiuseJ et notre module. C'est ce relais qui rend notre module réutilisable, car ilne dépend pas directement de la librairie utilisée. De cette façon, il est possible d'utiliserune autre librairie pour récupérer les sources infrarouges sur le capteur de la Wiimote. Ilest également possible d'utiliser un autre type de matériel, comme une webcam ou unecaméra stéréoscopique pour eectuer la détection. Tout ce que le module a besoin, c'estde récupérer deux sources ponctuelles placées au niveau de la tête, peu importe la façondont ces sources sont obtenues.

52

3.3.5 3DMath

Cette dernière classe dépendante du module headtracking, regroupe toutes les fonc-tions statiques qui sont utilisées pour eectuer des calculs sur les données. L'utilisationd'une classe auxiliaire pour les fonctions annexe donne une meilleure structure au code,car tout ce qui peut être séparé de la gestion de la wiimote ou du headtracking se trouvedans cette classe. Nous retrouvons par exemple les fonctions suivantes :

distance(double x1, double y1, double x2, double y2), dont le but est de calculer ladistance euclidienne entre deux points (x1,y1) et (x2,y2).

realdist(double x1, double y1, double x2, double y2), qui calcule la distance réelle àlaquelle se trouve l'utilisateur par rapport au dispositif de capture, en fonction dela position des deux sources infrarouges (x1,y1) et (x2,y2).

getMilieu(IRSource[] s), permet de calculer le point milieu entre deux sources in-frarouges. Ce point sera alors utilisé pour représenter la position de la tête sur lecapteur (la présence de deux points n'est utile que pour le calcul de la distance, etde l'inclinaison de l'utilisateur).

nearestFromBorderH(IRSource[] ir) / nearestFromBorderH(IRSource[] ir), qui sechargent de déterminer, parmi les sources infrarouges quel est le point le plus proched'un des bords horizontal ou vertical. Cette fonction est utile pour la gestion desangles.

calcNormal(XYZ p, XYZ p1, XYZ p2), qui calcule la normale entre les deux vecteursv1=(p,p1) et v2=(p,p2). Utilisé dans la génération des formes en 3D.

normalise(XYZ p), qui permet de normaliser un point p=(x,y,z).

3.4 Fonctionnalités étendues

Pour améliorer le concept de headtracking, une série de fonctionnalités additionnellesont été développées. Ces fonctionnalités ont pour but d'améliorer la qualité des modules,en fournissant des méthodes qui détectent les sorties du champ de vision de la caméra,ou qui limitent les tremblements de l'image lorsque l'utlisateur se trouve à une distanceplus importante de la caméra.

3.4.1 Gestion des angles

Lors de l'utilisation d'une application qui met en pratique le concept de headtracking,nous avons remarqué qu'il arrive très souvent à l'utilisateur de sortir du champ de visionde la caméra. Rappelons que notre capteur possède un champ de vision assez peu étendu.Pour remédier à ce problème, nous avons ajouté à notre module une fonctionnalité per-mettant d'éviter de sortir du champ de vision sans s'en rendre compte.

Pour pallier au problème de sortie du champ de vision, nous avons procédé de la façonsuivante : lorsqu'un mouvement est détecté sur le capteur infrarouge et que la méthodehandleEvent() de la classe CameraHandler est appelée, les sources infrarouges récupéréessont passées à des fonctions qui se chargent de calculer le point le plus proche de chaquebord. Nous calculons ensuite la diérence en pixels entre chaque bord et le point le plusproche de celui-ci. Cette valeur est comparée à un seuil variable dont la valeur par défaut

53

est de 150 pixels. Si la distance est inférieure à ce seuil, alors un évènement de type An-gleEvent est généré par la méthode handleEvent(). L'évènement généré déclenche alorsl'appel d'une méthode de l'interface AngleEventListener.

C'est La classe BorderPainter qui se charge de récupérer cet évènement car c'est ellequi implémente l'interface AngleEventListener. Les deux méthodes de cette interface sontangleLimitReached(AngleEvent ae) et AngleLimitLeaved(AngleEvent ae). La premièreméthode est appelée à chaque fois qu'une source est trop proche d'un bord du capteur.Dans l'objet de type AngleEvent, sont stockées des informations sur la proximité despoints par rapport aux bords. De cette façon, plus un point se rapproche du bord, plusle bord correspondant de l'écran sera peint d'un rouge vif.

Par exemple, si le seuil est de 150 pixels, et que le point le plus proche d'un des bordsest à 140 pixels de ce bord, celui-ci sera peint dans un rouge très pale (transparent), quis'intensiera à mesure que la source infrarouge se rapproche du bord du capteur. De cettefaçon, l'utilisateur sera capable de contrôler en temps réel sa position pour éviter de sortirdu champ de vision grâce à ce que nous appellerons la détection des bords du capteur.

3.4.2 Gestion des tremblements

Une observation faite lors de l'utilisation de notre module, est que nous observons destremblements de la part de la caméra virtuelle lorsque l'utilisateur se trouve à plus dedeux mètres de la caméra. Ceci s'explique par le fait que lorsque l'utilisateur s'éloignede la caméra, la distance en pixel entre les deux sources infrarouges devient de plus enplus faible, et une diérence de un ou deux pixels correspond à un mouvement de 10à 20 centimètres de l'utilisateur. De plus, il est naturel que la tête d'utilisateur deboutoscille en permanence de quelques centimètres, ce mouvement est retranscrit sur le cap-teur infrarouge, et la source perçue se déplace alternativement d'un pixel à l'autre sur lecapteur. Pour éviter ce problème, nous devrons mettre en place un système de détectionde tremblements.

Deux solutions ont été implémentées pour limiter ce phénomène de tremblement. Lapremière solution utilise une boite pour limiter les tremblements lorsque l'utilisateur nebouge pas, alors la seconde consiste en une interpolation des précédentes positions qui estalors eective à tout moment.

3.4.2.1 ShakeDetector

La première solution mise en place permet de limiter les tremblements de la caméralorsque l'utilisateur ne bouge plus. Les mouvements de tremblements dans l'image étantmoins gênants lorsque l'utlisateur se déplace. Le système mis en place à été implémentédans une classe appelée ShakeDetector. Le principe utilisé par cette classe est très simple.Si l'utilisateur reste pendant quelques dixièmes de seconde sans se déplacer, nous xonssa position. Plus aucun mouvement n'est alors eectué par la caméra, empêchant alors leserreurs de calculs et les tremblements qui s'en suivent d'apparaître à l'écran. La principalediculté consiste alors à savoir quand le mouvement peut reprendre.

54

Détecter l'absence de mouvements Pour détecter l'absence de mouvements, nousavons procédé de la sorte. Si la position de l'utilisateur n'a changé que de quelques cen-timètre (nous avons choisi arbitrairement 5 centimètres) durant les 200 dernières milli-secondes, nous pouvons considérer qu'il y a absence de mouvements. Une variable estalors placée à true pour indiquer qu'il n'y a pas eu de mouvements les 200 dernièresmillisecondes.

Chacune des variables présentée ci-dessus a été choisie avec soin car leur utilisationdonnait un résultat assez bon. Toutefois, ces valeurs sont tout à fait modiables, car ellesont été plaçées dans des variables, qu'il est possible de modier.

Détecter la reprise de mouvements la partie la plus compliquée consiste à savoirquand le mouvement peut reprendre. Si nous bloquons les mouvements après 200 millise-condes sans mouvement important, il est nécessaire de pouvoir reprendre le mouvementlorsque l'utilisateur se remet à bouger de façon signicative. Nous devons donc dénir lanotion de bouger de façon signicative.

Nous pouvons considérer que la tête peut osciller d'une dizaine de centimètres lorsquenous sommes debout. Un mouvement d'une amplitude supérieure doit alors être considérécomme une intention de reprendre le headtracking. Pour mettre en place ce principe, nousplaçons chaque source infrarouge dans une boite virtuelle lorsque l'absence de mouvementest détectée. Cette boite est de forme circulaire et possède un rayon calculé de telle sorteque sa taille en pixel équivaut à un mouvement d'environ dix centimètres. En eet, sil'utilisateur se trouve à cinquante centimètres du capteur, un mouvement de dix centi-mètres correspond à un déplacement de environ cent pixels sur le capteur. A deux mètres,le même mouvement correspond à un déplacement quatre fois inférieur des sources sur lecapteur.

Lorsqu'une des deux source infrarouge dépasse de la boite, celle-ci est immédiatementretirée et le headtracking est remis en fonction.

3.4.2.2 Interpolation des précédents évènements

Bien que les tremblements de la caméra soient moins gênants durant le déplacementde la caméra, ceux-ci entraînent tout de même un certain inconfort à l'utilisation. An delimiter ce phénomène de tremblement qui se passe presque exclusivement sur la profondeur(l'erreur de calcul est majoritairement commise sur le calcul de la distance. Le calcul dela position horizontale ou verticale ne soure pas de ce problème car il sut de calculerla position de la source sur le capteur pour calculer l'angle par rapport à la normale.Ce calcul n'est donc pas dépendant d'une loi hyperbolique) nous gardons en mémoire lesvingt dernières positions calculée de l'utilisateur sur l'axe de profondeur, et nous intégronsces valeurs dans le calcul de la nouvelle position. Nous avons choisi une valeur de vingtpositions précédentes car une valeur inférieure ne lisse pas susament le déplacement,alors qu'une valeur supérieure le rend trop peu réactif, car trop la position de la caméradépend de trop de positions précédentes. La formule utilisée pour le lissage est basée surune formule souvent utilisé en réseaux pour l'estimation du Round Trip Time 2 :

2. Le round trip time ou RTT correspond au temps qui s'écoule entre l'envoi d'un segment TCP etson acquittement.

55

EstimatedPosition = (1− α) ∗ EstimatedPosition + α ∗ newPosition

Dans notre cas, nous avons choisi α = 0.5, et EstimatedPosition situé à l'intérieur del'aectation a été remplacé par la moyenne des 20 précédentes positions. De cette façon,nous donnons un poids assez important aux anciennes valeurs de la position.

3.4.3 Gestion de plusieurs Wiimotes

Nous avons déjà remarqué que l'angle de vue du capteur que nous utilisons est assezfaible (environ 40° horizontalement et 35° verticalement). Pour permettre une plus grandeliberté à l'utilisateur, Il pourrait être intéressant d'améliorer notre module an qu'il puisseprendre en charge plusieurs caméras. Cette amélioration n'a pas été implémentée, maiselle a été le sujet d'une réexion dont nous exposerons les conclusions ci-dessous.

Les caméras utilisées devront être plaçées l'une à côté de l'autre (ou l'une en dessousde l'autre, si nous souhaitons élargir le champ de vision vertical) et regarder dans desdirections diérentes de sorte que l'angle obtenu par l'ensemble des caméras connectéessoit plus important qu'avec une seule. De plus, il faut que chaque caméra possède unrecouvrement de quelques degrés avec ses caméras voisines (celles dont le champ de visionest juste à gauche et/ou à droite de celle-ci). Ce recouvrement est nécessaire pour éviterd'avoir des angles non couverts, et donc de ne pas pouvoir détecter une source d'infra-rouges dans cet angle mort.

Pour mettre en oeuvre cet ajout, une solution simple serait de raisonner en utilisant lemême principe que les ordinateurs connectés à plusieurs écrans, avec pour seul diérencequ'un léger recouvrement est nécessaire. Lorsqu'une machine est connectée à plusieursécrans, et que l'achage n'est pas dupliqué, une résolution virtuelle est utilisée. Si lesdeux écrans possèdent une résolution de 1024x768 pixels, et qu'il sont plaçés l'un a côtéde l'autre, l'ordinateur peut créer un écran virtuel ayant une résolution de 2048x768 pixels.

Notre gestion de plusieurs Wiimotes peut fonctionner de la même façon. Comme nousconnaissons la résolution du capteur, il sut de connaître la position d'une caméra parrapport à l'autre, ainsi que le recouvrement, pour pouvoir calculer cette résolution vir-tuelle. Ce calcul peut se faire via un étalonnage. Au lancement de l'application, nouspouvons demander à l'utilisateur de déplacer une source infrarouge à une vitesse relative-ment lente de la gauche vers la droite (en supposant que les deux capteurs sont positionnéspour étendre le champ de vision horizontal), pour passer d'une caméra à l'autre et ainsicalculer le recouvrement existant entre les deux caméras. Ensuite, il ne reste plus qu'àeectuer les calculs pour connaître l'angle total couvert par les deux Wiimotes. Ce calculest assez simple.

Puisqu'une Wiimote possède un angle vertical de 42° et une résolution horizontale de1024 pixels, chaque pixel compte pour 0,04101°. La résolution totale des deux caméras estalors :

2 ∗ 42− 0, 04101 ∗ recouvrement

56

où recouvrement correspond à la largeur en pixel de la zone couverte par les deuxWiimotes.

Un problème se pose alors. Supposons que les deux Wiimotes ne sont pas orientéesexactement de la même façon. Le recouvrement en pixel entre les deux Wiimotes estalors diérent au dessus du capteur par rapport au recouvrement présent dans le bas ducapteur. Deux solution sont envisageables, la première, très simple consiste à s'assurerque les deux Wiimotes sont bien plaçées. La seconde méthode, plus technique, consiste àeectuer deux étalonnages, un sur la partie supérieure du capteur, et l'autre sur la par-tie inférieure. Il faut ensuite calculer la droite qui passe par les deux points de jonctionentre les deux caméras. Cette sorte de régression linéaire nous permettra alors de calculerl'overlap correct entre les deux capteurs, et la résolution virtuelle pourra être ajustée enconséquence.

Dans tous les cas, la première technique est préférable, et la seconde ne sert que deroue de secours, dans le cas où la diérence d'overlap entre le haut et le bas du capteurn'excède pas quelques pixels. Si cet diérence est trop grande, la mauvaise orientationdes caméras risque de poser un problème. En eet, lors d'un déplacement parfaitementhorizontal de l'utilisateur, la source infrarouge sur le capteur ne sera pas toujours située àla même hauteur, si le capteur n'est pas positionné de façon horizontale. Les calculs sontalors faussés, et la qualité du headtracking est dégradée.

Pour améliorer l'angle de vision supporté par la Wiimote, une autre solution est pos-sible. Nous pourrions placer la caméra sur un socle mobile, qui entraine une rotation de lacaméra (grâce à un servomoteur) lorsque les sources se rapprochent des bords du capteur.La solution n'est techniquement pas dicile à mettre en place, en revanche, calculer avecprécision la rotation eectuée par le servomoteur est un problème plus délicat qu'il nefaut pas négliger. Cette solution mérite tout de même d'être étudiée, et éventuellementtestée, pour améliorer l'angle de vision, sans pour autaut utiliser une seconde Wiimote.

3.4.4 3D stéréoscopique

Un ajout intéressant à notre module concerne la gestion de la 3D stéréoscopique. Lastéréoscopie est un procédé utilisé en photographie ou en vidéo permettant de percevoirun relief en 3 dimensions à partir de deux images planes. En eet, notre vision du mondeen 3 dimensions est due à nos deux yeux. Chaque oeil voit une image légèrement décaléepar rapport à l'autre, et notre cerveau rassemble ces deux images pour nous permettre dedistinguer la profondeur . Dans notre cas, à partir de lunette anaglyphes (cf section 2.1)et d'une image composée de deux images surperposées (destinées chacune à un oeil) nouspouvons faire apparaître cet eet de profondeur dans notre application. Ces deux imagessuperposées devront présenter un décallage cohérent ainsi que des couleurs complémen-taires correspondant aux couleurs des ltres présents sur les lunettes.

Pour développer une application qui génère des images stéréoscopique, une marche àsuivre bien précise doit être suivie. Il est bon de noter que toute scène utilisant la primi-tive gluLookAt() pour positionner la caméra peut être transformée en une scène en trois

57

dimensions, grâce à la générations d'images stéréoscopiques.

Pour illustrer de quelle façon il est possible de générer des anaglyphes en temps réelavec OpenGL, nous partons d'une scène normale, et expliquons quelles sont les modica-tions nécessaires pour transformer le rendu de l'image, en un anaglyphe généré en tempsréel.

Supposons que la scène soit dessinée dans une fonction render(). Le squelette de per-mettant de dessiner la scène est le suivant :

gl.glMatrixMode(GL.GL_PROJECTION) ;gl.glLoadIdentity() ;glu.gluPerspective(45.0f, screenAspect, .01, 1000.0) ;gl.glMatrixMode(GL.GL_MODELVIEW) ;gl.glLoadIdentity() ;glu.gluLookAt(cx, cy, cz, xl, yl, zl, ux,uy,uz) ;render() ;

Pour modier la scène en une scène anaglyphe, il faut prendre deux images, distantesd'environ 6,5 centimètres (la distance moyenne entre les yeux, chez l'être humain), quiregardent le même point. Ces deux images devront ensuite être passée à un ltre de couleurdiérent pour chaque image (un correspondant à la couleur du ltre équipé sur l'oeil droit,et l'autre correspondant à la couleur du ltre de l'oeil gauche). Les deux images généréesdoivent ensuite être superposées sur une seule image et achées. Appliquons toutes cesmodications à notre squelette, et visualisons le résultat :

gl.glMatrixMode(GL.GL_PROJECTION) ;gl.glLoadIdentity() ;glu.gluPerspective(45.0f, screenAspect, .01, 1000.0) ;gl.glMatrixMode(GL.GL_MODELVIEW) ;gl.glLoadIdentity() ;glu.gluLookAt(cx - EYE_SEP/2, cy, cz, xl, yl, zl, ux,uy,uz) ;gl.glColorMask(false, true, true, false) ;render() ;

gl.glClear( GL.GL_DEPTH_BUFFER_BIT ) ;

gl.glMatrixMode(GL.GL_PROJECTION) ;gl.glLoadIdentity() ;glu.gluPerspective(45.0f, screenAspect, .01, 1000.0) ;gl.glMatrixMode(GL.GL_MODELVIEW) ;gl.glLoadIdentity() ;glu.gluLookAt(cx + EYE_SEP/2, cy, cz, xl, yl, zl, ux,uy,uz) ;gl.glColorMask(true, false, false, false) ;render() ;

gl.glColorMask(true, true, true, true) ;

58

Nous voyons dans ce squelette que le buer de profondeur doit être vidé entre l'achagede la partie gauche et celui de la partie droite. Entre ces deux achages, la position dela caméra a une diérence de EYE_SEP, ayant une valeur de 0,065, ce qui correspondà 6,5 centimètres dans le choix de nos unités en OpenGL. La fonction glColorMask()permet quant à elle de ltrer les composantes qui peuvent être achées. La signature dela méthode étant glColorMask(boolean red, boolean green, boolean blue, boolean alpha).Le booléen est mis à true si et seulement si la composante correspondante peut êtreachée. Ce squelette est le point de départ de toute scène anaglyphe.

3.4.5 WindowedView

La classe WindowedView permet de calculer la portion visible d'une image, en suppo-sant que l'écran est une fenêtre et que l'utilisateur équipé de lunettes infrarouges regardeà travers cette fenêtre. Pour calculer la zone visible, la fonction getImageOset() de laclasse WindowedView a besoin d'une série d'informations concernant l'image et l'écran :

Le premier paramètre est la caméra, qui est nécessaire pour connaitre la position del'utilisateur par rapport à l'écran. C'est cette position qui sera utilisée pour calculerla portion visible de l'image en fonction de la position de l'utilisateur par rapport àl'écran.

La distance réelle qui existe entre l'image représentée et l'objectif de l'appareil quia pris cette image.

La hauteur de l'écran, et son ratio, qui nous permettront de calculer sa largeur. Cesinformations sont nécessaires puisque l'écran représente la fenêtre à travers laquellela scène doit être visible.

La taille réelle que représente la scène, sous la forme d'un objet Point, qui contienten abscisse la longueur en centimètres de la scène et en ordonnée sa largeur, toujoursen centimètres.

Le schéma de la gure 4.1 peut être utile à la compréhension du calcul de la portionvisible de l'image qui est également détaillé à la section 2.3.3. Grâce à ces informations, laméthode getImageOset() peut calculer la calibration de l'image, qui est alors renvoyéedans un objet de type ImageOset. Cet objet contient quatre variables qui correspondentau bords haut, bas , gauche et droite qui dénissent la portion visible de l'image.

3.5 Module Handtracking

Passons a présent à une brève explication des quelques classes importantes du mo-dule handtracking. Deux types de handtracking ont été développés, le premier permet dedéplacer des objets en temps réel, en déplaçant la main, alors que le second détecte desmouvements simples pour piloter une interface.

3.5.1 HandTracking

Tout comme le headtracking doit connaître la position de la tête dans l'espace pouracher la scène, la partie du handtracking qui permet de déplacer des objets doit connaîtrela position de la main, dans ce même espace. Pour ce faire, nous avons développé une

59

interface qui permet de caractériser la position de la main. Cette interface est composéede six accessors et mutators, dont l'utilité est expliquée ci-dessous.

1. setHandX(double x) / getHandX() permet de récupérer ou de modier la positionde la main le long de l'axe des x.

2. setHandY(double y) / getHandY() fait le même travail que ci-dessus, mais avecl'axe des y

3. setHandZ(double z) / getHandZ() fait la même chose que 1, mais avec l'axe des z.

4. setHandXInit(double x) / getHandXInit() permet de modier la position initiale dela main dans le monde virtuelle. Typiquement dans le jeu de pong, cela permet deplacer la raquette à une position initiale qui nous convient. En général la positionde la main est dépendante de la position du visage, et cette fonction n'a pas grandintérêt si on mixe headtracking et handtracking, mais peut avoir plus d'intérêt si lehandtracking seul est utilisé, pour positionner la main dans la scène OpenGL.

5. setHandYInit(double y) / getHandYInit() possède le même comportement que 4,avec l'axe y

6. setHandZInit(double z) / getHandZInit() fait la même chose que 4, mais avec l'axedes z.

3.5.2 HandHandler

la classe HandHandler est le succédané de la classe CameraHandler, appliqué auconcept de Handtracking. Elle est composée d'une méthode principale handleEventSim-ply() dont le but est de calculer la position de la main dans l'espace et de stocker cetteposition dans un objet implémentant l'interface HandTracking, qu'il est nécessaire de pas-ser en paramètre du constructeur, à la création d'un objet HandHandler.

Pour détecter la position de la main, nous n'avons à notre disposition qu'une seuleled, c'est pourquoi le calcul de la distance entre la caméra et la main est impossible. Nousdevons donc nous baser sur la position de la tête pour déterminer à quelle profondeurse situe la main, et placer celle-ci à un distance arbitraire devant la tête. Cette distanceest déterminée par la variable HAND_HEAD_DIST, dont la valeur par défaut est 1.5,signiant que la main se trouvera toujours un mètre cinquante devant la tête. Le calculde la position de la main étant dépendant de la position de la tête, nous n'avons dans cecas d'autre choix que de passer en paramètre du constructeur, la référence vers un objetimplémentant l'interface HeadtrackedCamera, qui contiendra la position de la tête, calcu-lée grâce à la classe CameraHandler. Cette dépendance est malheureusement inévitablesi nous n'avons qu'une seule led pour détecter la position de la main.

Pour distinguer la main du visage, nous avons développé une méthode très naïve.C'est la raison pour laquelle la méthode qui calcule la position de la main se nommehandleEventSImply(). Tout au long du tracking, celle-ci ne peut pas se trouver au dessusdu visage. Cette limitation n'est pas vraiment restrictive, car l'utlisateur a très souventtendance à interagir avec les mains situées plus bas que le visage.

60

Une seconde méthode basée sur une heuristique de suivi a été implémentée, mais samauvaise performance nous a poussé à déprécier cette méthode. Les mauvaises perfor-mances sont dues au nombre d'évènements générés par seconde qui est parfois beaucouptrop irrégulier. Il est alors dicile de suivre les points lorsque l'utilisateur déplace la maintrès rapidement et que l'application n'a pu rafraîchir la position de la main que 25 foisdurant la précédente seconde. Cette méthode pourrait être améliorée, mais un travailsupplémentaire est requis pour lui donner une certaine robustesse, c'est pourquoi nousavons préféré déprécier cette méthode, qui reste toutefois disponible dans le code sourcede l'application.

3.5.3 HandMovementsDetector

La seconde implémentation de headtracking proposée permet de détecter quelquesmouvements très simples. Cette détection est eectuée dans la classe HandMovements-Detector.

Pour détecter les mouvements, nous utilisons une heuristique que nous appelons heu-ristique de scoring. Le terme de scoring est utilisé car nous utilisons un score pour détecterles mouvements. La détection à lieu de la façon suivante : lorsque au moins trois évène-ments consécutifs accusent un déplacement de la source infrarouge sur le capteur dans unecertaine direction, un score de zero est attribué à ce déplacement (la direction est alorsgardée en mémoire). Pour chaque nouvel évènement ou la coordonnée de la led continuede se déplacer dans la même direction (haut, bas, gauche ou droite), nous augmentonsla valeur du score de un. Si par contre l'évènement indique une direction opposée à celleactuellement en mémoire, nous diminuons la valeur du score de 2. L'idée est de pénaliserplus fortement les mouvements qui nuisent au déplacement, pour éviter de considérer lespetits mouvements non contrôlés de l'utilisateur comme un mouvement valide.

Une fois que le score atteint une certaine valeur, nous pouvons armer avec unecertaine conance que le mouvement est valide, et le listener MovementListener, passé enparamètre de la classe HandMovementsDetector, est notié de ce mouvement.

Si par contre le score atteint une valeur négative, alors la direction qui avait été retenueest supprimée.

Le listener MovementListener est un interface contenant une série de signatures deméthodes correspondant aux mouvements que la classe HandMovementsDetector est ca-pable de détecter. Toute application souhaitant attribuer un comportement à chacun deces mouvements doit donc implémenter l'interface MovementListener.

Au total, la classe HandMovementsDetector est capable de distinguer huit mouvementsdiérents. Ces mouvements correspondent aux signatures de méthodes présentes dansl'interface MovementListener. Ces signatures sont citées ci-dessous.

1. leftMovementDetected() est déclenché lorsqu'un mouvement de la main, allant dela droite vers la gauche est détecté, avec un certain degré de conance, grâce àl'heuristique de scoring.

2. rightMovementDetected() est appelée lorsqu'un mouvement de gauche à droite dela main est détecté.

61

3. upMovementDetected() correspond à un mouvement de bas en haut de la main.

4. downMovementDetected() est appelé lorsqu'un mouvement de haut en bas de lamain est détecté.

5. zoomedIn(double factor) est une méthode qui est appelée lorsque deux sources surle capteur infrarouge s'éloignent. factor correspond alors au taux de zoom courant.

6. zoomedOut(double factor) est appelée lorsque deux sources se rapprochent sur lecapteur infrarouge. Le taux de zoom est alors disponible dans la variable factor.

7. straX(double pas), est une méthode qui est appelée si le taux de zoom possèdeune valeur positive. Si celui-ci à une valeur négative, la méthode ne peut pas êtreappelée. La méthode est prend une valeur positive en paramètre lorsque la sourceinfrarouge sur le capteur se situe plus à droite que l'évènement précédent. Sinon, levaleur est négative. Cette méthode est décelenchée à chaque évènement, si la sources'est déplacée horizontalement (sur l'axe des X du capteur).

8. straY(double pas) possède le même comportement que straX(), mais appliquésur la direction haut / bas de la source infrarouge. La méthode est appelée avecune valeur positive si la source courante est plus haute que celle de l'évènementprécédent.

62

Chapitre 4

Applications

4.1 Jeu de Pong

Le jeu de Pong est la première application développée pour illustrer notre moduleheadtracking. Son principe est très simple, il s'agit d'un jeu de tennis de table où l'utili-sateur contrôle la position de la raquette en se déplaçant dans l'espace, devant son écran.Le but étant de tenter d'intercepter la balle pour qu'elle puisse être renvoyée à votre ad-versaire (l'ordinateur).

Pour développer un jeu de tennis de table, plusieurs éléments clés sont à distinguer.Dans la suite de cette section, nous détaillerons l'implémentation du jeu, de la détectionde collisions, à la gestion des règles du jeu.

4.1.1 Trajectoire de la balle

Pour modéliser la trajectoire de la balle, nous avons utilisé les équations de mouve-ments issues des lois de mécanique (voir Section 2.3.4). La balle se déplace, sans frotte-ments, et donc sans aucune force opposée à son déplacement. De cette façon, le calcul desa position est grandement simplié. Pour modéliser son déplacement, un mouvement detype rectiligne uniforme est utilisé pour son déplacement latéral et d'avant en arrière, tan-dis qu'un mouvement rectiligne uniformément accéléré est utilisé pour son déplacementvertical, soumis à la force de la gravité.

En utilisant un procédé numérique de résolution d'équations diérentielles (tel queRunge-Kutta par exemple), nous aurions pu intégrer ces forces dans les équations demouvements. Cependant, mettre en place ce système de façon ecace pourrait se révélertrès couteux en temps CPU. De plus, l'intérêt du jeu de pong est davantage lié au conceptde headtracking, pour lequel un jeu simple sut à démontrer le principe.

4.1.2 Gestion des collisions

Lors du développement d'un jeu de pong, un élément clé est la gestion des collisions.Celle-ci doit être eectuée pour détecter les moments où la balle doit rebondir, que ce soitsur la table, sur le let, ou encore sur le sol.

63

Pour gérer les collisions, nous avons créé une classe Trajectoire dans laquelle toute lagestion de collisions est mise en place. Lors du déplacement de la balle, dont la position estremise à jour avant chaque achage, nous vérions si un rebond ne doit pas être eectué.Pour ce faire, nous calculons le moment de la prochaine collision, qui se fera soit avec latable, soit avec la raquette.

Nous commençons par tester à chaque mise à jour de la position de la balle, siune collision ne doit par être gérée entre celle-ci et la raquette (du joueur ou del'ordinateur). Ce test est nécessaire, car les règles du tennis de table permettent derattraper la balle avant son rebond sur la table. Si une collision est détectée, alorscelle-ci est gérée et la balle est renvoyée dans la direction opposée, avec un anglede réexion vertical égal à l'angle d'incidence avec lequel la balle est arrivée sur laraquette. L'angle horizontal est quant à lui généré aléatoirement, avec une tendanceà diriger la balle vers le centre de la table pour le joueur humain (cela évite d'avoir àgérer soi-même l'angle d'inclinaison de la raquette, rendant alors le jeu encore plusdicile).

Nous calculons ensuite le moment auquel la balle aura atteint la hauteur de la tabledurant sa chute (la table se trouve à 76 centimètres du sol). Si le temps courant estsupérieur au temps calculé pour le rebond, nous appelons la méthode checkTable()qui vérie si la balle se trouve bien sur la table lorsqu'elle se trouve à une hauteur de76 centimètres. Si la balle ne se trouve pas dans les bornes de la table, le mouvementcontinue jusqu'au niveau du sol.

Si par contre, la balle se trouve sur la table, nous générons le rebond à l'aide dela méthode makeRebond(). Cette méthode est chargée de mettre à jour l'équationdu mouvement et de réinitialiser le temps permettant le calcul de l'équation. Unproblème se pose alors : imaginons que le jeu soit utilisé sur une machine peuperformante ou la position de la balle ne peut être remise à jour que 15 fois parseconde. Comme nous attendons que le temps courant soit supérieur au temps decollision avec la table, il est possible que celui-ci soit fortement supérieur au tempsde collision réel. Dans ce cas, la balle se trouve en-dessous de la table, et le rebondsera calculé à partir de la position courante, en-dessous de la table, entraînant alorsune erreur dans son mouvement.Pour éviter ce problème, au lieu de faire rebondir la balle à partir de sa positionverticale courante, nous initialisons l'équation à une hauteur de 76 centimètres,avec un temps initial égal à t - tc, où t correspond au temps courant, et tc au tempscalculé pour la collision entre la table et la balle. De cette façon, le mouvement dela balle est indépendant du nombre d'images par seconde pouvant être générées,rendant alors le comportement de la balle parfaitement déterministe quelle que soitla machine utilisée.

4.1.3 Règles du jeu et Calcul du score

Une autre partie importante concerne l'application des règles du jeu et le calcul duscore, tout au long de la partie.

64

4.1.3.1 Règles du jeu

En fonction de la position de la balle sur la table lorsqu'elle doit rebondir, le rebonddoit être autorisé ou refusé. L'exemple suivant montre une situation qui doit être refusée.

Exemple 1 Supposons que le service a été fait par l'ordinateur. Si le joueur humainfait rebondir la balle dans son camp lorsqu'il la renvoie à l'ordinateur, le rebond doit êtrerefusé, et un point doit être accordé à l'ordinateur.

Nous pouvons grâce à cet exemple dégager les éléments qui déterminent l'acceptationou le refus du rebond :

Il est nécessaire de savoir si c'est le service, auquel cas le joueur a le droit (et mêmel'obligation) de faire rebondir la balle dans son camp.

Si c'est le service, il faut savoir si le premier rebond a eu lieu dans la partie de la tableappartenant au serveur, et si le second rebond a eu lieu sur la partie appartenant àl'adversaire.

Le sens de la balle est lui aussi important, pour savoir de quel côté doit avoir lieule rebond. La balle peut aller du joueur vers l'ordinateur ou inversément.

Si ce n'est pas le service, il faut savoir si l'unique rebond a bien lieu dans la partiede la table opposée à celui qui envoie la balle.

etc.

Les élements ci-dessus, ainsi que certains autres éléments non cités, constituent l'état de lapartie. Nous pouvons donc nous baser sur ces éléments pour déterminer si un rebond doitêtre accepté ou non. Au niveau de l'implémentation, nous pouvons voir cela comme unemachine à états, où le rebond sera accepté ou refusé en fonction de l'état de la trajectoire.

Lorsqu'un rebond est refusé, il est nécessaire de savoir à qui le point du jeu doit êtreaccordé. Nous pouvons remarquer que l'attribution du point est dépendante de l'état de latrajectoire au moment du refus. C'est donc l'état qui détermine à qui le point est attribué,et de façon plus générale, les règles du jeu sont déterminées par une machine à états.

Exemple 2 Si la balle se déplace du joueur vers l'ordinateur, et que le premier rebonda lieu en dehors de la table, le point est attribué à l'ordinateur.

Lorsqu'un jeu se termine, la partie est mise en pause, l'appui sur la touche P permetde lancer un nouveau jeu. Le service est alors automatiquement envoyé, y compris lorsquec'est au tour du joueur de servir. Au niveau du service, chaque joueur a le droit de servir5 fois, ensuite le service est passé à l'adversaire.

4.1.3.2 Calcul du score

Lorsqu'un point est attribué à un joueur, le score doit être remis à jour. Ce score estcalculé et maintenu à jour dans la classe Score. La méthode principale de cette classe estla méthode score(boolean isHuman) qui permet d'ajouter un point au joueur si le booléenpassé en paramètre est vrai, ou à l'ordinateur s'il est faux.

65

Dans les règles du tennis de table, le premier joueur qui marque onze points remportele set. Pour remporter un set, le score doit avoir un écart d'au moins deux. Si le scoreest dix partout, alors la partie continue au moins jusqu'à douze. Le set continue ainsitant qu'il n'y a pas deux points d'écart entre les deux joueurs. Le premier joueur ayantremporté trois sets gagne la partie.

L'implémentation du score est eectuée de la même façon qu'expliqué ci-dessus. Poursavoir si une partie est terminée, la méthode score() renvoie un booléen vrai si et seulementsi la partie est terminée. Le gagnant est alors le joueur qui a remporté trois sets.

4.1.4 Intelligence articielle

Notre jeu de pong se joue contre l'ordinateur. Nous avons donc développé un intelli-gence articielle très simple dont nous expliquons le comportement ci-dessous.

En cours de partie, l'ordinateur calcule la trajectoire de la balle, pour savoir ou placersa raquette lorsque celle-ci arrive dans sa direction. Le déplacement de la raquette est ef-fectué au moment du rebond de la balle sur le côté de la table appartenant à l'ordinateur.Ce mouvement est opéré de façon simple et brutale. Pour améliorer le réalisme apportépar le jeu, une amélioration intéressante serait de déplacer la raquette progressivementvers la balle, plutôt que de façon brutale. Une fois la raquette placée au bon endroit, l'or-dinateur attend patiemment que la balle rebondisse sur cette dernière. La balle est alorsenvoyée dans une direction horizontale variable. Nous avons implémenté une fonction quigénère un angle pour le rebond. Cet angle se base sur la position de la balle par rapport àla table. Si la balle se situé du côté gauche de la table, alors l'angle généré aura tendanceà envoyer la balle vers la droite, an de la recentrer.

Pour rendre le jeu amusant, il est nécessaire que l'ordinateur commette des erreurs.Un facteur aléatoire a donc été ajouté lors de la génération de l'angle pour renvoyer laballe. De cette façon, il arrivera à l'ordinateur de renvoyer la balle a côté de la table,permettant alors au joueur de marquer un point. Une autre erreur que peut commettrel'ordinateur est au niveau de la vitesse de la balle. Lorsqu'il renvoie la balle, l'ordinateurfrappe avec une certaine force, modiant ainsi la vitesse de la balle, qui peut alors sortirde la table, sans avoir eectué de rebond.

L'intelligence articielle n'est pas la partie la plus développée de l'application. Denombreuses améliorations pourraient lui être apportées. Par exemple il pourrait être inté-ressant que la raquette ne parvienne pas toujours à rattraper la balle. Une possibilité estd'initier le déplacement de la raquette de l'ordinateur, à une vitesse constante, quelquesdixièmes de seconde avant le rebond de la balle. Il est alors possible que la raquette n'aitpas le temps de se déplacer jusqu'à sa position d'arrivée, ratant alors son coup, et laissantpasser la balle.

66

4.1.5 Handtracking

Un autre but recherché lors de la réalisation du jeu de pong est de montrer l'interac-tion possible entre le headtracking et le handtracking. En plus de piloter la position de lacaméra avec la tête, il peut être intéressant de contrôler un objet virtuel que l'utlisateurtient en main. Nous avons donc utilisé notre gant infrarouge pour donner la possibilité aujoueur d'utiliser sa main, pour contrôler la position de la raquette, en plus du déplacementdu personnage virtuel, grâce au déplacement de la tête.

Le procédé suivi pour la détection de la position de la main est très simple et similaireà la détection de la tête (voir section 2.3.2). Nous utilisons pour cette application un gantéquipé d'une seule led infrarouge. Il est alors possible de déplacer la raquette horizon-talement et verticalement. En ce qui concerne la position en profondeur, nous pouvonssupposer que la raquette suit les mouvements du personnage virtuel.

En cours de partie, il sut de déplacer la main équipée du gant infrarouge, pour dé-placer la raquette, dont les mouvements suivent alors ceux de la main. Pour faire rebondirla balle, il n'est pas nécessaire d'eectuer un mouvement simulant une frappe. Le simplefait de positionner la raquette au bon endroit sut à faire rebondir celle-ci à la mêmevitesse qu'avant le rebond, mais dans la direction opposée.

4.1.6 Déroulement d'une partie

Au lancement de l'application, la partie est en pause, et c'est au tour de l'utilisateurde servir. L'appui sur la touche P permet de lancer le jeu. Le service est automatiquementenvoyé (l'utilisateur ne doit pas frapper la balle). Le joueur peut alors se déplacer pourmodier la position du joueur virtuel, et éventuellement utiliser sa main, si le handtrackingest activé.

La partie continue jusqu'à ce qu'un des deux joueurs commette une erreur. Le jeuest alors remis en pause, et un point est attribué au joueur qui marque le point. L'appuisur la touche P permet de lancer le jeu suivant. Chaque joueur a droit à cinq servicesconsécutifs, après quoi le service est passé à l'adversaire.

Au cours de la partie, le joueur doit simplement positionner sa raquette à un endroitqu'il juge adéquat pour permettre à la balle de rebondir dessus. Lorsque la balle touche laraquette, la balle est renvoyée avec un angle horizontal variable, qui a tendance à l'envoyervers le centre de la table.

4.2 Targets

La seconde application créée est inspirée de celle développée par Johnny Lee (voirsection 1.4.1). Elle a été conçue an de comparer nos deux applications de headtracking.Tout comme dans la version de Johnny Lee, notre application représente une grille àl'intérieur de laquelle sont situées une série de cibles, aléatoirement placées. Ces ciblessont maintenues au fond de la boîte par un cable virtuel, donnant une impression deprofondeur à l'image.

67

Le déplacement de l'utilisateur autour de l'écran entraîne alors une modication entemps réel de la scène. L'achage réagit de façon proportionnelle au déplacement de l'uti-lisateur, donnant ainsi l'impression que l'écran n'existe pas et que de vraies cibles sontplacées devant l'utilisateur, juste derrière l'écran.

Pour obtenir des résultats similaires à l'application de J. Lee, nous avons dû utiliser unematrice de projection légèrement modiée, par rapport à la matrice obtenue en utilisantla primitive gluPerspective(). C'est la méthode glFrustum() qui a été utilisée pour simulerl'eet de profondeur donné aux cibles, lorsque l'utilisateur s'éloigne ou se rapproche del'écran. Grâce à cette matrice de projection, la dimension de profondeur se comprimelorsque l'utilisateur se rapproche, et se dilate lorsque celui-ci s'éloigne. Ce comportementa un eet plus proche de celui obtenu par notre oeil lorsque nous nous éloignons d'unobjet qui possède une certaine profondeur.

Le résultat obtenu avec la primitive gluPerspective() est quant à lui diérent. Lorsquel'utilisateur s'éloigne de l'écran, la scène s'éloigne, et semble alors plus petite, sans pourautant comprimer la dimension de profondeur.

L'utilisation de l'une ou l'autre de ces matrices de projection dépend en réalité dutype de scène à acher. Si l'eet recherché lors de l'éloignement est une compression dela scène, qui ne doit pas donner l'impression que la scène s'éloigne, alors la primitive gl-Frustum() sera préférée. Si par contre (c'est le cas de notre jeu de pong) nous souhaitonspouvoir nous déplacer sur la dimension de profondeur, il est plus intéressant d'utilisergluPerspective().

La réalisation de l'application Targets nous a également permis de tester les fonction-nalités additionnelles qui ont été développées. C'est le cas du degré de liberté supplémen-taire ajouté à l'application, qui permet de détecter et de simuler les mouvements de pivotde la tête sur le côté. Lorsque l'utilisateur pivote la tête sur le coté gauche (resp. droit),l'achage est alors incliné avec la même pente que celle entre les deux sources infrarouges,mais dans la direction opposée, c'est-à-dire vers la droite (resp. gauche).

La génération d'images stéréoscopiques nous a également permis d'ajouter une fonc-tionnalité supplémentaire à notre scène Targets, en comparaison à celle développée par J.Lee. La scène représentant les cibles a été adaptée pour pouvoir être visionnée avec uneet de relief, en portant des lunettes à anaglyphes.

4.3 Eet fenêtre

Un concept de headtracking relativement diérent de celui appliqué dans les applica-tions précédemment expliquées est la création d'un eet fenêtre. Par eet fenêtre nousentendons que l'écran est vu comme une fenêtre à travers laquelle une scène est observée.Si l'utilisateur se rapproche de celle-ci, il peut voir une plus grande partie de la scène. Sipar contre il s'éloigne, alors il verra une partie moins importante de la scène.

Le concept d'eet fenêtre est illustré à la gure 4.1. Supposons que l'utilisateur setrouve au point p1, alors la portion visible de la scène est obtenue en traçant les deuxdroites partant du point p1, et passant par les bords gauche et droit de l'écran, respecti-

68

Figure 4.1: Eet fenêtre

vement e_left et e_right sur la gure. L'intersection entre chacune de ces deux droites etla scène permet d'obtenir les deux points qui correspondent aux bords visibles de la scène(s_l1 et s_l2 sur l'image). Lors du passage du point p1 au point p2, nous voyons que laportion visible de la scène est légèrement plus large, car le point p2 est plus proche del'écran.

C'est ce principe d'eet fenêtre qui fait l'objet d'une de nos applications. A partird'une photographie dont nous connaissons la distance entre l'appareil et la scène pho-tographiée, ainsi que la largeur totale représentée par la photo, nous pouvons donnerà l'écran le même comportement qu'une fenêtre. Ce comportement est possible grâce àl'utilisation du headtracking, qui permet de situer dans l'espace la position du visage parrapport à l'écran. Cette position correspond au point p1 sur la gure 4.1. En ajoutant auxinformations ci-dessus, les informations concernant la dimension de l'écran. Il est possiblede calculer de façon exacte quelle est la portion de la scène qui est vue, en fonction de laposition de l'utlisateur par rapport à l'écran.

Grâce au headtracking, la portion visible de la scène peut être remise à jour en tempsréel, donnant alors un impressionnant eet de réalisme à l'écran qui semble être transforméen une fenêtre à travers laquelle l'utilisateur regarde.

4.4 Formes 3D

La génération d'images anaglyphes est plus ecace lorsque celles-ci sont représentéesen niveaux de gris. Nous avons vu que cela est dû au fait que nous utilisons des ltres de

69

couleurs pour faire apparaître le relief de l'image. Les couleurs ne peuvent alors plus êtreutilisées de la même façon pour colorer l'image. En eet, si nous utilisons des lunetteséquipées de ltres rouge et cyan, la présence de rouge sur une image ne pourra être dé-tectée que par l'oeil équipé du ltre rouge. La composante verte et bleue de l'image étantnulle, l'autre oeil ne pourra pas voir cette partie de l'image, et la stéréoscopie ne donnerapas un bon eet.

Pour illustrer ce principe, nous avons développé au départ d'un travail eectué parPaul Bourke [1] (initialement développé en C), une application représentant diérentesformes en trois dimensions, en utilisant uniquement les deux couleurs correspondant auxltres de couleurs des lunettes à anaglyphes. Ces formes sont dessinées en temps réel, enutilisant la primitive GL_LINE, ainsi que la méthode l de fer d'OpenGL, qui permettentde dessiner des formes géométriques en utilisant uniquement des lignes. Pour les formesplus complexes telles que le Lorenz, des points sont utilisés au lieu de traits. Pour uneliste complète des formes achables par l'application, se référer à la section 5.2.

Pour le rendu en trois dimensions, la caméra OpenGL est placée à deux endroits,distants d'environ 6,5 centimètres (la distance qui sépare nos yeux). Une image est prisede chacune de ces deux positions et passée à un ltre dont la couleur correspond à celuiéquipé sur l'oeil auquel l'image est destinée. Les deux images ltrées sont alors superpo-sées et achées à l'écran.

En plus du rendu tridimensionnel, le module de headtracking est également utilisabledans cette application. Il permet ainsi de proter davantage de l'eet apporté par lastéréoscopie, en modiant la position de la caméra, qui entraîne à son tour une redénitionde l'image en trois dimensions, et par conséquent, une modication de l'espace entre lesdeux images. Cet espace est réadapté en fonction de la position de l'utilisateur par rapportà l'écran. Grâce à l'ajout du headtracking, l'eet de profondeur est alors intensié.

4.5 Explorateur de Fichiers

Si nous nous intéressons plus particulièrement au concept de handtracking, il est pos-sible de développer une multitude d'applications qui mettent en pratique ce concept.

Une idée intéressante pourrait être de développer une application qui met en pratiquele handtracking pour piloter une interface. Imaginons un explorateur de chier tel queNautilus [3] qui puisse être entièrement piloté à distance grâce aux mouvements des mains.Nous pourrions piloter le curseur en déplaçant la main, le clic serait simulé en joignant lepouce et l'index, etc.

Dans un dossier contenant des videos, une interface spécique peut être développée.Elle permettrait par exemple de passer d'une video à l'autre en eectuant un mouvementde balayage de droite à gauche avec la main, ou encore de faire un arrêt sur image enjoignant le pouce et l'index.

Dans un dossier contenant des images, il serait possible d'agrandir une image en éloi-gnant ses deux mains, ou de la rétrécir en les rapprochant. Nous pouvons aussi déplacer

70

cette image sur l'écran en joignant pouce et index et en déplaçant notre main, l'imagesera alors déplaçée dans le sens correspondant à notre mouvement.

Pour détecter les mouvements de la main, nous pourrions utiliser deux gants infra-rouges, comme ceux dont nous avons parlé à la section 2.1.

Cette idée constitue une possibilité d'utilisation du concept de handtracking, et n'apas été implémentée dans le cadre de ce travail. Ce concept constitue toutefois un sujetde recherche qu'il serait intéressant d'approfondir.

4.6 Visualisateur de photos

L'explorateur de chier est une idée intéressante qui met en pratique l'utilisation duhandtracking. Toutefois, la mise en place d'une telle application demande beaucoup detemps. Pour illustrer les possibilités du handtracking de façon simple, nous avons décidéde développer une application de visualisation de photos, pouvant être pilotée avec lesmains. L'utilisation de cette application requiert la présence de deux gants infrarouges,équipés chacun d'une unique led.

Lors du lancement de l'application, un dossier spécique est parcouru, à la recherchede photographies. Celles-ci sont alors chargées en mémoire, et la première d'entre ellesest achée à l'écran. Pour passer à l'image suivante (resp. précédente), il sut alorsd'eectuer un mouvement de la main, de droite à gauche (resp. de gauche à droite). Lemouvement est détecté par la Wiimote et envoyé à l'ordinateur, qui utilise une simpleheuristique de scoring (voir section 3.5.3) pour détecter des mouvements simples tels queun déplacement de la main vers la gauche, la droite, vers le haut ou vers le bas.

En plus de ces mouvements simples, il est possible de zoomer (resp. dézoomer) surl'image, en écartant (resp. rapprochant) les mains. Une fois l'image agrandie, l'utilisationd'une seule main permet de déplacer l'image dans la direction empruntée par celle-ci. Lepassage à une autre image étant temporairement rendu impossible, tant que le facteurde zoom est supérieur à un (qui correspond à la taille initialle des images, au lancementde l'application). Remettre l'image à une taille plus petite réactive automatiquement lapossibilité de passer d'une photo à l'autre, d'un mouvement de la main.

4.7 Interface graphique

Pour utiliser chacune des applications dont nous avons parlé ci-dessus, nous avonsdéveloppé une interface graphique intégrant chacune de nos applications. Cette interfacegraphique permet de passer d'une application à l'autre, et pour chacune d'elles de fournirun ensemble d'outils permettant la modication de certains paramètres propres à chaquescène.

Pour faciliter l'utilisation de l'interface graphique, un guide de l'utilisateur est pré-sent à la section 5.2. Ce guide détaille chacune des fonctionnalités oertes par l'interfaceutilisateur.

71

4.7.1 Architecture globale

Dans cette section, nous nous focaliserons plus sur le côté implémentation, contraire-ment à la section 5.2, qui traite le coté utilisation de l'application.

Le coeur de notre application graphique se trouve dans la classe MainFrame, qui secharge d'interconnecter tous les modules graphiques dans une unique Fenêtre. Cette classehérite de la classe JFrame qui représente une fenêtre graphique. L'entièreté de l'interfacegraphique se trouve dans cette fenêtre (excepté le mode plein écran qui provoque lacréation d'un seconde fenêtre).

Le constructeur est divisé en sous fonctions, dont chacune a pour but d'initialiser unedes cinq parties principales de l'application, rangées grâce à un BorderLayout.

1. La première partie est la partie ouest, qui contient les paramètres propres aux me-sures et à la Wiimote. Ces paramètres sont respectivement contenus dans des classesnommées MesuresSettings et WiimoteSettings. Ces deux classes héritent de JPanel,et contiennent une série de labels et de champs de texte, rangés principalement enutilisant un LayoutManager de type GridLayout.

2. La seconde partie est la partie centrale de l'application, qui contient un GLCanvas,à l'intérieur duquel est géré l'achage de la scène OpenGL.

3. La partie sud de l'application contient un JLabel utilisé pour acher la position dela caméra et du point de vue.

4. Du coté est, est contenu une JTabbedPane contenant deux onglets. Le premier ongletache un panel contenant les paramètres propres à chaque scène. Ce panel quiest modié lorsque l'utilisateur change la scène représentée sur la partie centrale.Le second onglet contient un panel graphique déni dans une classe ControlPandonnant un aperçu en temps réel de la position de l'utilisateur par rapport à l'écran.Cet aperçu schématise une vue qui surplombe le lieu d'utilisation de l'application.L'écran, la Wiimote et l'utilisateur y sont ainsi représentés.

5. La dernière partie de l'application se situe au nord. Elle contient une JComboBoxqui permet de changer de scène. Pour eectuer cette modication, la ComboBoxest attachée à un listener qui récupère l'évènement généré lors de la modicationde la scène séléctionnée par la ComboBox. La partie nord de l'application contientégalement un bouton permettant de passer en mode plein écran. Ce bouton est luiaussi relié à un listener qui créée une nouvelle Fenêtre lorsque le bouton est pressé.La fenêtre ainsi crée contient uniquement la scène OpenGL, et toute la surface del'écran peut être utilisée pour proter de l'application.

4.7.2 Communication avec les applications

Pour permettre une modularité optimale, l'interface graphique est séparée du codedes applications et des modules. Un package gui regroupe toutes les classes concernantl'interface graphique.

Pour communiquer avec les applications et les modules développés, l'interface utiliseles variables disponibles dans chaque application. Par exemple, la classe PongParam est

72

destinée à interagir avec le jeu de pong, implémenté principalement dans la classe Pong-Game. Pour modier les paramètres du jeu, la classe PongParam prend paramètre duconstructeur, la classe PongGame qu'elle est sensée contrôler. De cette façon, la modi-cation des paramètres se fait via un appel de méthode sur l'objet PongGame, dans laclasse PongParam. Ainsi la modication de la position horizontale de la raquette se faitvia l'appel de la méthode setRaquetteX(oat raq).

La communication avec les modules est réalisée de la même façon dans les classesWiimoteSettings et MesureSettings.

4.7.3 Intégration des scènes

La représentation des scènes OpenGL utilise un objet de type GLCanvas pour acherle contexte OpenGL. La classe GLCanvas est une classe qui hérite de Canvas, apparte-nant au package awt. Notre application graphique étant construite avec le package swing,il est important de noter que la compatibilité entre awt et swing n'est pas optimale.En eet, lorsqu'un composant awt est utilisé dans une application utilisant swing, cer-tains problèmes peuvent apparaître lors de l'utilisation de popups. C'est le cas de l'objetJComboBox, qui déroule un popup lorsqu'on clique sur celui-ci. Si le popup doit s'ouvrirau-dessus d'une zone contenant un canevas awt, alors celui ci s'ouvre sous le canevas etest alors invisible. Ce problème est dû au fait que les composants awt sont heavyweightalors que les popups de swing sont lightweight. Java déconseille de mixer ces deux typesde composants.

Pour éviter ce comportement, sans pour autant ne plus utiliser les JComboBox, il estpossible de désactiver le caractère léger des popups. Ceci est fait par l'appel de la méthodesuivante, avant l'achage des composants.

JPopupMenu.setDefaultLightWeightPopupEnabled(false);

Une autre solution, qui évite de mixer des composants swing et awt, est d'utiliser unobjet de type GLJPanel plutôt que GLCanvas pour stocker le contexte OpenGL. Cetteclasse hérite de la classe JPanel. Le principal souci de cet objet est que ses performancessont quatre fois plus faibles que celles obtenues avec GLCanvas. Nous avons donc préféréutiliser ce dernier pour la réalisation de notre application.

73

Chapitre 5

Utilisation du module

5.1 Réaliser une application

Les modules de headtracking et de handtracking ont été développés comme une li-brairie, pouvant être réutilisée par des programmeurs désireux de créer des applicationsqui mettent en oeuvre l'un des deux concepts évoqués. Pour faciliter le démarrage d'unapplication, nous présenterons un prototype de programme pour chacun de nos deuxmodules.

5.1.1 Installation des librairies

Pour réaliser une application de Headtracking utilisant la Wiimote, il faut tout d'abordinstaller la librairie WiiuseJ.

Sous Windows WiiuseJ nécessite, pour fonctionner, l'installation d'un logiciel capablede gérer le bluetooth. C'est le cas du logiciel BlueSoleil, qui est téléchargeable gratui-tement à cette adresse http://www.bluesoleil.com/Default.aspx. Une fois le logicielinstallé, il sut de télécharger la librairie WiiuseJ contenant toutes les librairies (des .dll)nécessaires au fonctionnement du programme.

Avec Eclipse, il reste alors à ajouter ces libraires dans le java build path du projet,an de pouvoir lancer une application utilisant la librairie WiiuseJ.

Sous Linux Pour installer WiiuseJ sur linux, il est préférable de compiler soi-même leslibrairies natives (en C) sur sa propre machine. Pour ce faire, un tutoriel mis en lignepar le créateur de la librairie WiiuseJ explique toutes les démarches à eectuer et toutesles dépendances à installer pour pouvoir compiler la librairie. Le tutoriel est disponible àl'adresse suivante :http://code.google.com/p/wiiusej/wiki/CompileWiiusejOnLinux.

Pour compiler les chiers les dépendances suivantes sont à installer : libc-dev, libbluetooth-dev, xlibmesa-gl-dev, libglu1-mesa-dev, libsdl.Téléchargez ensuite la librairie Wiiuse sur sourceforge (http://sourceforge.net/projects/wiiuse/files/). Une fois la librairie téléchargée, compilez la en utilisant les commandessuivantes :

74

makesudo make install

Une fois la librairie compilée, une librairie dynamique au format .so est générée, il nereste plus qu'à l'ajouter au path de votre projet, qui utilise WiiuseJ.

5.1.2 Headtracking

Développer une application utilisant le module de headtracking est assez simple.Quelques conventions doivent toutefois être respectées.

Pour développer notre API, nous avons dû eectuer des choix concernant les axes.Ces choix ne sont pas restrictifs, mais ne pas respecter les conventions peut compliquerl'utilisation du module. Les conventions sont les suivantes :

L'axe des X représente la direction latérale, c'est-à-dire un déplacement de gaucheà droite de la caméra sur l'écran

L'axe des Y représente la profondeur, qui permet de déplacer la caméra d'avant enarrière, pour qu'elle rentre dans l'écran ou recule.

Enn, l'axe Z représente la direction verticale, utilisée pour monter ou descendre lacaméra à l'écran.

Le respect de ces conventions lors du développement d'une application 3D facilitera gran-dement l'intégration du module. Si ces conventions ne sont pas respectées, pas de panique,il sura de substituer chacun de vos axes à celui qui est utilisé pour eectuer le mêmemouvement dans notre API.

Exemple 1 Si l'axe Z est utilisé pour déplacer la caméra de gauche à droite, alors ilfaut placer toutes les méthodes concernant l'axe X (qui représente la direction latéraledans notre module), sur la composante Z de votre application. De façon plus claire, si lasituation est la suivante :

L'axe des X représente la direction verticale L'axe des Y représente la profondeur L'axe des Z représente la direction latérale

Alors, lors de l'appel à la fonction gluLookAt(), qui permet de positionner votre caméra,vous utiliserez les paramètres dans cet ordre :

gluLookAt(cam.getCameraZ(), cam.getCameraY(), cam.getCameraX(), cam.getEyeZ(),cam.getEyeY(), cam.getEyeX(), cam.getUpZ(), cam.getUpY(), cam.getUpX()) ;

Nous voyons ici que les méthodes de notre module ont été plaçées aux endroits corres-pondant aux conventions utilisées pour cette scène (le X et le Z ont été inversés, puisqueleurs conventions sont inversées par rapport aux conventions de la librairie).

5.1.2.1 Utiliser la Camera du module

Une fois l'application développée, en tenant compte des conventions citées plus haut,quelques ajouts sont nécessaires pour utiliser le headtracking. Commencez par créer unobjet de type Camera, cette classe se trouve dans le package objects du module développé,et doit donc être importée. Pour plus de détails sur le fonctionnement de la classe Camera,

75

voir section 3.3.2. La classe Camera est utilisée pour contenir la position de la caméradans l'espace, cette position correspond à celle de l'utilisateur par rapport à son écran.

Une fois l'objet Camera placé en variable d'instance, nous pouvons utiliser les mé-thodes dénies sur cette classe pour récupérer sa position dans l'espace. Ces méthodesdevront donc être appelées comme paramètre de la primitive gluLookAt(), comme expli-qué à l'exemple 1 ci-dessus.

5.1.2.2 Détection des angles

Pour pouvoir utiliser la détection des angles, expliquée à la section 3.4.1, il est néces-saire que la classe qui s'occupe de colorer les bords de l'écran ait connaissance du contexteOpenGL. C'est un objet de type BorderPainter, situé dans la classe Camera qui s'occupede colorer les bords.

Dans la méthode init() de votre application OpenGL (méthode issue de l'interfaceGLEventListener, qui représente une scène OpenGL), ajoutez cette ligne de code :

cam.getBorderPainter().setGL(gl) ;

Cette instruction a pour eet d'informer le BorderPainter du contexte OpenGL, ensupposant que le paramètre gl soit créé de cette façon :

public void init(GLAutoDrawable gLDrawable) nal GL gl = gLDrawable.getGL() ;//....

Grâce à cette instruction, le BorderPainter connaît le contexte OpenGL, et pourra êtreautomatiquement appelé lorsque l'utilisateur s'approche des bords de l'angle de vision dela Wiimote.

5.1.2.3 Lier la caméra au module

La dernière chose à faire pour proter du headtracking dans l'application développéeest de lier la caméra instanciée dans la classée créée au module de headtracking. Pource faire, nous allons devoir récupérer cette caméra, il est donc intéressant de créer uneméthode getCamera() dans le GLEventListener de l'application développée. La marche àsuivre pour utiliser le module de headtracking est la suivante :

Supposons que votre classe qui contient le contexte OpenGL s'appelle MyClass. Com-mençons par créer cette classe :

MyClass scene = new MyClass() ;

Créons à présent un objet CameraHandler, après l'avoir importé du package headtra-cking du module. Le CameraHandler a besoin de la caméra instanciée dans la scène pourfonctionner. Ensuite, il faut créer un objet WiimoteHeadAndHand disponible dans le pa-ckage wiimoteHandle. Cet objet se chargera de communiquer avec la librairie WiiuseJ et

76

de récupérer les informations des sources infrarouges. Enn, un lien est nécessaire entrele CameraHandler et le WiimoteHeadAndHand, car c'est le Caméra Handler qui gère lesinteractions clavier qui permettent par exemple de connecter une Wiimote en appuyantsur la touche R.

Le reste des démarches à suivre concerne OpenGL et permet de lier le gestionnaire declavier au canevas à l'intérieur duquel se trouve la scène OpenGL.

CameraHandler camh = new CameraHandler(scene.getCamera()) ;WiimoteHeadAndHand wim = new WiimoteHeadAndHand(camh) ;camh.setWiimoteHandler(wim) ;

canvas.addGLEventListener(scene) ;canvas.addKeyListener(camh) ;animator.start() ;canvas.requestFocus() ;

Il ne reste plus qu'à lancer l'application, et à activer la Wiimote en appuyant sur R.Le headtracking est alors utilisable dans la scène développée.

5.1.3 Handtracking

Détaillons à présent comment il est possible de créer une utilisation qui utilise le mo-dule de headtracking, basé sur la détection de mouvements simples. Nous procéderons defaçon similaire à notre explication permettant de créer une scène utilisant le headtracking,en supposant que l'utilisateur a développé une classe nommée MyClass, qui implémentel'interface GLEventListener de OpenGL (MyClass est donc une scène OpenGL).

En plus d'implémenter l'interface GLEventListener, la scène développée, que noussouhaitons adapter pour le handtracking doit implémenter l'interface MovementListener,contenant une série de méthodes qui seront appelées par le module de handtracking lors-qu'un mouvement sera détecté. Par exemple, si un mouvement vers la gauche de la mainest détecté, la méthode leftMovementDetected() de l'interface MovementListener sera au-tomatiquement appelée. C'est au développeur de détailler le comportement eectué par laméthode, en fonction de l'application qu'il souhaite réaliser. Le squelette d'une applicationutilisant le handtracking est détaillé ci-dessous :

MyClass scene = new MyClass() ;handmov = new HandMovementsDetector(scene) ;WiimoteHand wim = new WiimoteHand(handmov) ;handmov.setWimoteHandler(wim) ;

canvas.addGLEventListener(scene) ;canvas.addKeyListener(handmov) ;animator.start() ;canvas.requestFocus() ;

77

Figure 5.1: Au lancement de l'interface graphique

L'appui sur la touche R permet de connecter une Wiimote, une fois l'application lancée.Il ne reste plus qu'a déplacer les mains pour déclencher automatiquement les méthodesde l'interface MovementListener.

5.2 Interface utilisateur

Pour illustrer les concepts de headtracking et de handtracking, nous avons développéune série d'applications. Chacune dss applications développées a été discutée au chapitre4. Pour faciliter l'utilisation de ces applications, une interface utilisateur a été développéegrâce à la couche graphique Swing de Java. Dans cette section, nous avons rédigé unmanuel de l'utilisateur de notre interface graphique. Ce manuel a pour but de faciliter laprise en main de l'application en détaillant les diérentes fonctionnalités de l'interface.

5.2.1 Lancement de l'application

L'application développée est une archive au format jar exécutable. Pour démarrerl'application, il sut de saisir la ligne de commande suivante dans un terminal :

java -Djava.library.path="chemin_vers_les_ressources" -jar Headtracking.jar

où chemin_vers_les_ressources correspond à un dossier où se trouvent les librairies etles textures nécessaires à l'utilisation de l'application.

Une fois cette ligne de commande saisie, l'interface graphique s'ouvre. Cette interfaceest composée de 5 régions principales que nous nommerons Ouest, Est, Nord, Sud etCentre par référence à leur situation géographique sur l'écran (voir gure 5.1).

5.2.2 Région Ouest

La première partie de l'interface graphique correspond à la partie gauche de l'interfacegraphique. Il est possible que cette zone ne soit pas visible au lancement de l'application.

78

Figure 5.2: Région ouest invisible

Si c'est le cas, il sut de cliquer sur l'une des petites èches située en haut à gauchede l'interface graphique (voir gure 5.2). Ce bouton permet de disposer de plus d'espacepour acher la partie centrale de l'application (la scène OpenGL).

5.2.2.1 Onglet Mesures

La région ouest permet de paramétrer une série de fonctionnalités qui sont propresau matériel utilisé. Comme nous le voyons sur la gure 5.3a, il est possible de modierdiérents paramètres :

Distance Lunettes Lorsque l'utilisateur réalise ses propres lunettes infrarouges, la dis-tance entre les leds est susceptible d'être diérente de celle sur nos propres lunettes. Pourpermettre une meilleure portabilité, nous laissons à l'utilisateur la possibilité d'indiquer,en millimètres, la distance qui sépare les deux leds sur ses lunettes infrarouges (ou toutautre dispositif). La valeur par défaut de 215mm correspond à la distance entre les leds dela Sensor-bar de la Wii, que nous avons utilisée lors de la réalisation de notre application.

Hauteur Ecran En fonction de la taille de l'écran, l'application se comporte diérem-ment si l'utilisation d'unités écran est activée. Puisque la taille de l'écran est susceptiblede varier d'un utilisateur à l'autre, il est possible via ce champ de texte de modier lahauteur de l'écran (la largeur sera calculée en fonction de la hauteur, et le ratio peut êtrecalculé facilement à partir de la résolution de l'écran).

Eet de stra Lors de l'utilisation du headtracking, deux visions sont envisageables : Si le bouton eet de stra est coché, le point de vue observé par la caméra sedéplace de la même façon que l'utilisateur. Cela signie que le module se comportecomme si l'utilisateur regardait toujours devant lui, lorsque sa position par rapportà l'écran est modiée. Si l'utilisateur regarde face à lui-même, le terme stra estcouramment utilisé dans les jeux vidéos pour qualier un déplacement latéral quientraîne la modication du point de vue, pour suivre les mouvements du personnage.

79

(a) Onglet Mesures (b) Onlget Wiimote

Figure 5.3: Onglets de la partie Ouest

Dans le cas contraire, l'utilisateur regarde toujours le même point. Un déplacementde l'utilisateur n'entraîne alors pas de modication du point de vue, et le sujet aalors l'impression de tourner autour du point de vue xé par la caméra.

En fonction de la scène projetée, il est parfois plus propice d'activer l'eet de stra. C'estpar exemple le cas du jeu de pong, où l'eet est plus intéressant lorsque le stra est activé.Avec l'application Targets, au contraire, la qualité du headtracking est améliorée lorsquel'eet de stra est désactivé.

Caméra sous écran Si les unités écran sont utilisées, il devient indispensable de tenircompte de la position de la Wiimote par rapport à l'écran. En eet, si l'utilisateur estsitué à moins d'un mètre de l'écran, le visage situé à la hauteur du dessus de l'écran, lascène doit être achée pour être vue du dessus. Si la position de la Wiimote n'est pasconnue, il est impossible de tenir compte de cette information.

Imaginons les deux situations, sans tenir compte de la position de la Wiimote. Si celle-ci est placée sous l'écran et que la tête de l'utilisateur se trouve à la hauteur du dessusde l'écra, alors les leds infrarouges seront situées sur la partie supérieure du capteur.Inversemment, si la Wiimote est placée au-dessus de l'écran, les leds infrarouges étantsituées à la même hauteur que le capteur, les sources infrarouges seront situées sur lapartie centrale du capteur. Dans le cas où nous utilisons des unités écran, cette diérenceest très importante.

Unités écran Plutôt que de calculer la position absolue de l'utilisateur par rapport àl'écran (e.g. le sujet est plaçé 1m devant la caméra et 40cm sur la gauche). Il peut êtreintéressant de considérer l'écran comme un cube unitaire à l'intérieur duquel on peuttravailler. Cette fonctionnalité est très utile pour développer des applications où le sujetest assez proche de son écran et se trouve à la même hauteur que celui-ci. Avec les unités

80

écran, il est plus facile de savoir si l'utilisateur se trouve au dessus de l'écran, auquel cas lacaméra doit être placée au-dessus de la scène, où bien s'il se trouve en dessous de l'écran(la caméra sera alors placée pour voir la scène du dessous). L'écran apparaît alors commeune boîte à l'intérieur de laquelle une scène est achée.

Ce mode ne convient pas à des applications où les mouvements doivent simuler laréalité, tel que le jeu de Pong. Les dimensions d'une table de tennis de table étant bienconnues par l'être humain, l'eet de réalisme ne sera pas optimal si le déplacement del'utilisateur ne concorde pas exactement à un déplacement représentant le même mouve-ment dans la scène OpenGL. Plus précisément, si la largeur de la table de tennis de tableest de 1m52, un déplacement latéral de 1m52 dans la réalité doit permettre de déplacerla caméra d'un bord à l'autre de l'écran.

Pivoter Tête Comme précisé à la section 1.5, un apport intéressant au module deheadtracking a été l'ajout d'un degré de liberté supplémentaire, permettant d'interpréterle roulis de la tête pour le simuler dans nos applications utilisant le headtracking. L'uti-lisation de cet ajout ne se prête pas à toutes les formes de headtracking, c'est pourquoinous laissons la possibilité à l'utilisateur d'activer ou non cette fonctionnalité. Cocherce bouton met en place le système de roulis, et l'eet obtenu est alors comparable celuiobtenu lorsqu'une caméra embarquée est plaçée sur une moto qui enchaîne des viragesserrés.

5.2.2.2 Onglet Wiimote

Le second onglet de la partie ouest de notre application contient des informationspropres à la Wiimote. Les paramètres suivants sont modiables (voir gure 5.3b) :

Angle H/V Camera La Wiimote possède un angle de vision de 42° horizontalementet 33° verticalement. Ces valeurs sont largement utilisées dans le calcul de la position del'utilisateur par rapport à l'écran. Comme nous avons développé un module réutilisablequi est indépendant du périphérique de capture utilisé, il est nécessaire de pouvoir modierles angles de vision perçus par le matériel de détection. Si un développeur souhaite ajouterla possibilité d'utiliser une nouvelle interface de capture, il peut modier ces valeurs pourqu'elles correspondent aux angles de vision du matériel qu'il utilise.

Largeur/Hauteur Capteur Dans la même optique que pour l'angle de vision, il estnécessaire de pouvoir modier la résolution du capteur. Nous savons que la Wiimote estéquipée d'un capteur ayant une résolution de 1024x768 pixels. Ce sont donc les valeurs pardéfaut présentes dans les champs de texte Largeur/Hauteur capteur. Modier ces champspermet à l'application de travailler avec un capteur ayant une résolution diérente de cellede la Wiimote.

Pas Pour étalonner les applications, nous verrons (voir section 5.2.6) qu'il est possibled'utiliser le clavier. La valeur du pas permet de modier l'amplitude des mouvementseectués à chaque appui sur une des touches permettant d'étalonner la scène. Par exemplesi le pas est mis à 2, apppuyer sur la touche 'Q' permet de déplacer de 2 unités OpenGL

81

vers la gauche la position de la caméra. La plupart de nos scènes ont comme conventionque une unité OpenGL correspond à un mètre dans la réalité. Par conséquent la longueurd'une table de tennis de table est de 2,74 unités OpenGL.

La modication de ce paramètre est utile lorsque les unités écran sont utilisées, car lavaleur par défaut de 1 fait basculer la caméra en dehors de la scène. Remplacer le pas parune valeur plus faible est alors nécessaire.

Sensibilité Lorsque l'utilisateur dispose d'un espace réduit pour utiliser le headtracking,il peut être intéressant d'amplier les mouvements perçus par la caméra. La sensibilitéest un facteur multiplicatif de la position réelle calculée. Par conséquent, une sensibilitésupérieure à 1 entraînera des mouvements plus importants à l'écran que les mouvementsréellement eectués, alors qu'une valeur inférieure à 1 (et supérieure à 0) aura tendanceà diminuer l'amplitude des mouvements eectués.

En pratique une valeur de deux pour la sensibilité aura pour eet de doubler l'intensitéde chaque mouvement. Un mouvement de un mètre vers la gauche sera donc traduit dansl'application par un mouvement de deux mètres dans la même direction.

Largeur bordure Parmi les fonctionnalités supplémentaires oertes par notre appli-cation, il est possible de contrôler sa position par rapport à la Wiimote, an d'éviterde sortir de son champ de vision (voir section 3.4.1). La valeur qui est indiquée dans cechamp de texte correspond à la largeur brute en pixel à considérer comme en bordure ducapteur. La valeur par défaut est 150, cela signie que sur un capteur d'une résolution de1024x768, les bords sont sur l'intervalle :

1. X=[0-150] pour le bord droit (Notons que lorsque l'utilisateur se déplace vers lagauche, les sources se déplacent sur la droite du capteur. Puisque le dispositif decapture est situé en face de l'utilisateur, la gauche et la droite sont inversées).

2. X=[874-1024] pour le bord gauche.

3. Y=[0-150] pour le bord inférieur

4. Y= [618-768] pour le bord supérieur

Modier la valeur présente dans ce champ de texte permet donc d'utiliser une valeurdiérente pour la coloration des bords de l'écran, lorsque l'utilisateur s'approche du champde vision limite de la caméra.

Taille Interpolation Lorsque l'utilisateur s'éloigne de l'écran, nous savons que le cal-cul de la distance est de plus en plus dicile et que les erreurs deviennent de plus enplus importantes. A 1 mètre, l'image est assez stable, mais dès que le sujet se trouve àplus de deux mètres de la caméra, la résolution du capteur ne permet pas de détecteravec précision la distance à laquelle il se trouve, à cause du caractère hyperbolique dela distance entre les sources infrarouges sur le capteur (discuté à la section 2.3). Cetteperte de précision entraîne des tremblements dans l'image, car d'un évènement à l'autre,la distance calculée entre la caméra et le sujet varie de plusieurs dizaines de centimètres.

Pour limiter ce problème, nous avons ajouté une fonction de lissage qui s'appliqueuniquement sur l'axe de profondeur (voir section 3.4.2). Par défaut, nous nous basonssur les 20 évènements qui précèdent pour lisser le mouvement. La modication de cette

82

valeur permet de tenir compte d'un nombre diérent d'évènements. Une valeur inférieurelimitera l'eet de lissage et aura tendance à intensier les tremblements, alors qu'unevaleur supérieure aura tendance à augmenter le lissage, et par conséquent à diminuer laréactivité de la profondeur sur la scène. Puisque la mise à jour de la profondeur dépenddes points précédents, un déplacement rapide sera eectué de façon moins réactive quedans la réalité, car les points concernant les positions précédentes sont impliqués dans lecalcul de la nouvelle position.

Distance sensible Lorsque la sensibilité est modiée, tous les mouvements sont modi-és (latéraux, verticaux et en profondeur). Dans certains cas, il peut être intéressant dene modier la sensibilité que pour les déplacements verticaux et latéraux, sans aecterl'intensité donnée aux mouvements de profondeur. En désactivant cette option, la profon-deur devient insensible au facteur Sensibilité. De cette façon, le fait de s'éloigner ou de serapprocher ne dépend pas de la sensibilité.

Cette fonctionnalité a de l'intérêt pour jouer au Pong, qui est plus facile à jouer avecune Sensibilité de deux, mais en laissant la profondeur insensible à ce facteur.

5.2.3 Région Est

La région est de notre application est composée de deux onglets, le premier concerneles paramètres propres à chacune des scènes, alors que le second permet d'acher une vuevirtuelle de la position de l'utilisateur par rapport à l'écran.

5.2.3.1 Onglet Paramètres

L'onglet paramètres a pour but de contenir les variables qui sont propres à chaquescène achable avec notre application graphique. Pour chacune d'entre elles, diérentescongurations spéciques existent. Les paramètres propres à un jeu de pong n'étant pasles mêmes que ceux d'un acheur de forme, il était nécessaire d'avoir un panneau qui soitmodié en fonction de la scène achée.

Jeu de Pong Les premiers paramètres dont nous discuterons concernent le jeu de Pong.Les variables propres à cette scène ainsi que leur utilité sont expliquées ci-dessous etreprésentées sur la gure 5.4.

Raquette X/Y/Z Lorsque l'application Pong est lancée, la raquette se trouve pardéfaut juste un mètre en avant de la caméra. Les trois sliders Raquette X/Y/Z permettentde modier la position de la raquette pour l'adapter à la convenance du joueur. De cettefaçon, il est par exemple possible d'adapter le jeu pour un gaucher qui tient sa raquetteavec la main gauche. Déplacer le slider X permet de déplacer la raquette latéralement,alors que le Slider Y permet de faire avancer ou reculer la raquette. Enn, le dernier sliderpermet de postionner la raquette verticalement.

Vitesse Balle La balle de tennis de table suit les équations issues des lois de mé-canique simple. Les mouvements selon les axes latéraux et de profondeur suivent uneéquation de type rectiligne uniforme (MRU), alors que le déplacement vertical est soumis

83

à la pensanteur et est par conséquent représenté par une loi rectiligne uniformément ac-célérée (MRUA). A travers un écran et à vitesse réelle, les mouvements sont bien souventperçus comme trop rapides, car la taille de l'écran fait apparaître une balle plus petitequ'en réalité, laquelle est assez dicile à situer dans l'espace durant le jeu. Pour parerà ce problème, le slider Vitesse Balle permet de modier la vitesse de la balle. Ralentircette dernière rend alors le jeu plus facile alors que l'accélérer le rend plus dicile. Pardéfaut, la balle se déplace à 50% de sa vitesse réelle, une valeur raisonnable pour un joueurmoyen.

Taille Raquette Dans notre application, la taille de la raquette de ping pong estd'environ 12 centimètres de diamètre. Il s'agit approximativement de la taille ocielle.Malheureusement, dans le monde des jeux vidéos, les constantes de taille peuvent rarementêtre respectées, car cela rend le jeu tellement dicile qu'il risque de ne pas être amusant.Pour ce faire, les dimensions sont souvent revues. Lorsque le but du jeu est d'attraperune balle avec une raquette, sa taille est très souvent supérieure à la taille réelle de laraquette, an d'augmenter la jouabilité. Un slider a donc été intégré, an de permettre àl'utilisateur de régler la taille de la raquette à sa convenance.

Raquette Transparente Augmenter la taille de la raquette à une valeur deux foisplus grande que sa taille originale peut poser un problème de visibilité. Lorsque celle-cigrandit, elle cache une partie de la table et il devient dicile de suivre la trajectoire de laballe de façon confortable. Pour permettre au joueur de voir la balle derrière la raquette,même lorsque celle-ci a une taille importante, le bouton raquette transparente permet,comme son nom l'indique, de rendre la raquette transparente, an de distinguer ce qui setrouve derrière. De cette façon, le jeu est beaucoup plus confortable.

Utiliser Main Jouer au pong en utilisant la tête pour déplacer le personnage virtuelest un concept assez intéressant, mais pas forcément pratique. Au niveau du gameplay,cela donne tout simplement l'impression d'avoir une raquette collée sur le torse ! Pouraméliorer l'expérience, nous avons ajouté la possibilité le contrôler la raquette en utilisantla main. Grâce à cette fonctionnalité supplémentaire, il est possible de déplacer son per-sonnage virtuel en bougant la tête, mais il est également permis de déplacer la raquettede façon latérale et verticale, en étant équipé du gant infrarouge dont nous avons parléà la section 2.1.2. Ce gant infrarouge n'étant équipé que d'une seule led, il n'est pour lemoment pas encore possible de modier la profondeur de la raquette indépendamment decelle du visage, mais cet ajout pourrait faire l'objet d'une des premières mises à jour del'application.

Vue en 3D Ce bouton permet de visualiser la scène en anaglyphe, orant alors uneet de relief au joueur équipé de lunettes à anaglyphes. La vue en 3D projette une imagepour chaque oeil, comme expliqué à la section 2.1.1.

Targets Passons à présent à l'explication des paramètres mobiles de l'application tar-gets. Ces paramètres sont visibles sur la gure 5.7 qui nous donne un aperçu complet del'application lorsque la scène visualisée est Targets.

84

Figure 5.4: Paramètres du Jeu de Pong

Brouillard Le slider brouillard permet de modier l'intensité du brouillard. Lebrouillard aché suit une fonction linéaire, et la valeur achée sur le slider correspondau pourcentage de clarté désiré. Plus la valeur est faible, moins la boîte à l'intérieur delaquelle se trouvent les cibles est visible. Lorsqu'aucun brouillard n'est présent, la présencede la grille est assez prononcée. Il est également possible de la rendre invisible lorsque lepourcentage de visibilité est proche de zéro.

Replacer Cibles Ce bouton permet de repositionner les cibles de façon aléatoire àl'intérieur de la boîte. La fonction de positionnement implémentée agit de telle sorte àce qu'au moins 3 cibles se trouvent à l'avant plan. Grâce à cette génération aléatoire, ilest possible d'avoir une multitude de dispositions diérentes, qui peuvent servir de baseà un jeu de tir où le but du jeu serait d'éliminer le plus rapidement possible les ciblesprésentes à l'écran. Ce petit jeu constitue une possibilité d'évolution de la scène Targets.L'élimination des cibles peut se faire grâce à un curseur qu'il serait possible de déplaceren utilisant les mains. L'action de tir peut être eectuée grâce à un gant contenant deuxleds infrarouges situées à l'extrémité du pouce et de l'index. Un algorithme serait alorschargé de détecter la jointure des doigts, qui déclencherait alors le tir.

Nb cibles Ce petit champ de texte est destiné à modier le nombre de cibles achéesà l'écran. Par défaut dix cibles sont achées. La présence de cette variable se justie elleaussi par la possibilité d'évolution de la scène en un petit jeu de tir/réexe. Le nombre decibles constituerait alors la diculté. Une fois le jeu lancé, l'idée est de laisser 10 ou 20secondes à l'utilisateur pour détruire le plus de cibles possible. L'intérêt du jeu est assezlimité avec des cibles qui ne bougent pas, mais la principale utilité de l'application est dedonner un aperçu des possibilités oertes par le headtracking.

Vue Frustum/perspective En OpenGL, plusieurs types de matrices de projectionexistent, parmi celles-ci, deux sont particulièrement intéressantes pour notre application

gluPerspective, qui dénit une projection perspective pour laquelle les objets éloi-gnés apparaissent plus petits (voir gure 5.5). La fonction gluPerspective() calcule la

85

Figure 5.5: Projection Perspective [7]

pyramide visible en tenant compte de l'angle de vision (fovy), de l'aspect de l'écran(aspect), de la zone visible la plus proche (glNear), et du point visible le plus éloigné(glFar). La fonction appelle ensuite glFrustum pour générer cette pyramide.

glFrustum est une fonction de plus bas niveau, qui ore plus de possibilités quegluPerspective. La spécication de la pyramide d'achage est déterminée par 6 pa-ramètres qui sont les plans de clipping gauche (left), bas(bottom), haut (top) etdroit (right), ainsi que le point le plus proche visible (zNear) et le point le pluséloigné (zFar). En utilisant directement cette projection, la profondeur agit dié-remment lorsque la caméra s'éloigne ou s'approche du point de vue. Lorsque lacaméra s'éloigne du point de vue, la scène se comprime sur l'axe de profondeur etlorsqu'elle se rapproche, la scène se dilate sur ce même axe. Utilisée en combinaisonavec le headtracking, cette projection donne davantage l'impression que l'écran estune boîte, à l'intérieur de laquelle se trouvent des cibles. Avec une projection pers-pective traditionnelle, les cibles s'éloignent lorsque l'utilisateur s'écarte de l'écran.Avec l'utilisation explicite de glFrustum, la grille se comprime et semble alors moinsprofonde lorsque l'utilisateur s'en éloigne.

La présence des boutons vue frustum et vue perspective permet donc de choisir entre cesdeux types de projection. Le comportement de l'axe de profondeur est alors diérent enfonction du choix eectué.

Vue en 3D Tout comme pour le jeu de Pong, il est possible de visualiser cette scèneavec un eet de relief en portant des lunettes à anaglyphes.

86

Figure 5.6: Projection Frustum [7]

Espace yeux La matrice de projection issue de glFrustum se comportant d'une fa-çon diérente à la matrice de projection gluPerspective, l'espacement entre les yeux estdiérent lorsque cette projection est utilisée. Il est alors nécessaire d'étalonner l'espace-ment entre les deux images projetées. Cet étalonnage est rendu possible grâce au sliderespace yeux. De plus, cet étalonnage permet également d'adapter la 3D à l'utilisateur.En eet, nous avons remarqué que certains utilisateurs perçoivent mieux le relief lorsquel'écart entre les deux images est plus important.

Eet Fenêtre Discutons à présent des paramètres modiables pour la scène Eet Fe-nêtre. La partie graphique concernant ces variables est visible sur la gure 5.8.

Charger Image Ce champ de texte a pour but de modier l'image utilisée pourl'eet fenêtre, en spéciant le lien complet vers cette image. Notons que pour importerdes textures en OpenGL, il est nécessaire que leur taille soit une puissance de deux. Nousavons donc redimensionné les images à l'aide d'un logiciel externe.

Largeur Champ Lorsqu'une image est chargée, le programme doit connaître lalargeur, en centimètres, que représente cette image. Par exemple si une photo d'une cuisineest montrée, une largeur possible est 500 centimètres. Cette valeur est nécessaire pour quele programme puisse calculer correctement l'achage.

87

Figure 5.7: Paramètres des cibles

Figure 5.8: Paramètres de l'eet fenêtre

88

Figure 5.9: Paramètres des Formes 3D

Ratio Image Les images chargées par OpenGL doivent avoir une taille en pixelsqui est une puissance de deux. Les images chargées sont donc redimensionnées et parconséquent déformées. Connaître le ratio de l'image est indispensable pour acher celle-ci avec le bon format.

Hauteur Ecran L'écran doit agir comme une fenêtre. Il est donc nécessaire deconnaître la hauteur de cette fenêtre an de calculer correctement la partie de l'image quidoit être achée. Ce champ de texte permet donc de spécier la hauteur, en centimètres,de l'écran.

Ratio Ecran Pour calculer exactement les dimensions de l'écran, connaître son ratioest nécessaire, pour déduire sa largeur à partir de sa hauteur. Ce champ de texte est prévupour indiquer le ration de l'écran, sous la forme d'un seul nombre à virgule ottante.

Distance Image Le dernier paramètre nécessaire au calcul de la zone visible del'image est la distance à laquelle se trouve l'image. Cette distance doit être spéciée encentimètres.

Par exemple, si nous reprenons le cas où l'image représentée est une cuisine, unedistance possible est 300 centimètres.

Formes 3D Lors de la visualisation de formes en 3D, certains paramètres sont égalementmodiables. L'interface graphique correspondant à cette scène est visible à la gure 5.9et la description des variables est détaillée ci-dessous.

Forme Cette Combo box permet de choisir quelle forme nous souhaitons représen-ter sur notre scène, chacune des formes est représentée avec la primitive l de fer pour

89

permettre une meilleure visualisation du relief en 3D. Il est possible de choisir parmi lesformes suivantes :

Mesh, représente une simple grille Box, représente un cube Sphere Pulsar, il s'agit d'une représentation simpliée d'un pulsar. Knot, une forme géométrique qui représente une sorte de courbe de bézier noueuse. Tritorus, un tore en trois dimensions. Lorenz, qui représente une gure de Lorenz.

Vitesse de Rotation Chacune des formes représentée à la possibilité de pivoter surelle même. Le déplacement de ce slider permet de modier la vitesse de rotation de laforme représentée.

Taille Points/Lignes Ce slider permet de tracer des lignes ou des points plus épais.Cela est intéressant car en fonction de l'écran utilisé, l'eet de relief est de meilleure qualitélorsque les traits sont plus épais. Cela donne aussi un léger lissage aux formes généréesqui semblent moins pixélisées qu'avec une épaisseur de 1 seul pixel.

Vue en 3D De façon identique aux autres scènes présentées plus haut, il est possiblede visualiser les formes en trois dimensions. C'est d'ailleurs là que se situe tout l'intérêtde cette scène, qui a été initialement conçue pour acher des formes en 3D, grâce à latechnique d'anaglyphe.

Idées concernant le Visualisateur de PhotosNous terminerons par le visualisateur de photo. Ce dernier ne possède encore aucun pa-

ramètre modiable. Toutefois, certains ajouts pourraient s'avérer intéressants, comme parexemple la possibilité de charger un dossier sur la machine, an d'en visualiser les photos.La version existante du visualisateur de photos étant réalisée dans un but plutôt pratique,elle n'intègre pas la possibilité de changer le dossier visité. Toutefois, il est possible devisualiser d'autres photos en les ajoutant dans le dossier parcouru par l'application, quise chargera alors de les importer pour les acher.

Un autre paramètre intéressant serait de pouvoir faire varier la vitesse de rotation etd'accélération du cube, pour adapter sa vitesse à la convenance de l'utilisateur. Il pouraitégalement être intéressant de modier l'intensité du facteur de zoom et de déplacement,lors d'un mouvement sur une image zoomée.

5.2.3.2 Onglet Contrôles

Le but de l'onglet contrôles est de fournir un aperçu rapide de la position de l'utilisateurpar rapport à la caméra. Sur cette partie de l'interface graphique sont dessinés de façonschématique l'écran, la Wiimote, l'utilisateur et le champ de vision de la Wiimote (voirgure 5.10). Ce schéma est vu du dessus, les mouvements verticaux ne sont donc pasmodélisés sur ce petit écran. L'utilisateur est représenté par un point, et est relié par unsegment à la Wiimote virtuelle. Cette visualisation permet d'apporter à l'utilisateur uncertain contrôle de sa position horizontale et en profondeur, cet écran peut être utilisé en

90

Figure 5.10: Onglet contrôles

Figure 5.11: Région Nord de l'application

plus du système de détection des bords pour anticiper toute sortie du champ de vision.Cette petite fenêtre graphique permet également de vérier en temps réel la qualité duheadtracking.

5.2.4 Région Nord

Une autre partie importante de l'interface graphique est la région nord. Cette régionpossède deux fonctionnalités détaillées ci-dessous, qui sont visibles sur la gure 5.11

Changer de scène Notre interface graphique a pour but de regrouper, dans une seuleapplication graphique, toutes les scènes créées pour illustrer les concepts développés dansle cadre de ce travail. Un point clé de l'application est donc la possibilité de pouvoirbasculer d'une scène à l'autre. C'est cette possibilité qui est oerte par la présence de laCombo changer de scène. Cette boîte de dialogue permet de choisir quelle scène acherdans la région centrale.

Mode plein écran Un autre intérêt de l'application est de pouvoir basculer en modeplein écran, an de proter de toute la surface d'achage pour représenter la scène.L'appui sur le bouton plein écran permet de créer une nouvelle fenêtre ayant pour taille larésolution de l'écran et ne possédant pas de décoration (le bord de la fenêtre qui permetnotamment de la réduire ou de la fermer). Ce plein écran est donc assez articiel, mais ilconstitue la façon la plus simple de réaliser une fenêtre graphique utilisant tout l'espacede l'écran. Notons que la création d'un vrai plein écran en Java est assez dicile et nefonctionne pas toujours, en fonction de la machine sur laquelle on utilise l'application.

91

Figure 5.12: Région Sud de l'application

Le but n'étant pas de créer l'application graphique la plus performante possible, nous nenous sommes donc pas focalisés sur cet aspect.

5.2.5 Région Sud

La partie sud de l'application possède un petit label de texte, dont le but est d'acheren temps réel, durant l'utilisation de l'application, la position de la caméra et de l'oeil(voir gure 5.12). Ces positions sont mises à jour à chaque évènement. La raison de leurprésence est similaire celle de l'onglet contrôles dont nous avons discuté au point 5.2.3.2.La présence de ces labels permet de contrôler en temps réel la position de l'utilisateur parrapport à la caméra, ainsi que l'évolution de cette position.

5.2.6 Région Centrale

La partie principale de notre application se trouve sur la région centrale. C'est à cetendroit qu'est représentée la scène 3D. Lorsque l'utilisateur souhaite modier celle-ci viala combo box située sur la région nord, ce panel est alors rafraîchi pour acher la scènechoisie.

Utilisation du clavier Chaque scène étant liée à un gestionnaire de clavier, il estpossible d'utiliser ce dernier pour modier certains paramètres génériques applicables surl'ensemble des scènes proposées. Pour pouvoir utiliser le clavier, il est nécessaire que lefocus de l'application soit situé sur la région centrale. Pour prendre le focus, il sut decliquer avec le bouton gauche de la souris sur la scène 3D.

L'appui sur les touches Z et S du clavier permet respectivement d'avancer ou dereculer le long de l'axe de profondeur (c'est la caméra de OpenGL qui est déplacée).

Les touches Q et D permettent quant à elles de déplacer la caméra vers la gaucheou la droite.

L'appui sur une des touches A ou E permet de se déplacer verticalement, de bas enhaut en appuyant sur A, et de haut en bas en appuyant sur E.

Les èches directionnelles du clavier permettent de modier le point de vue xé parla caméra. Alors que les touches Haut / Bas permettent de déplacer le point de vuede haut en bas, les touches Gauche / Droite peuvent être utilisées pour le déplacerde gauche à droite. Enn, les touches W et X permettent respectivement de faireavancer ou reculer le point de vue sur l'axe de profondeur.

Il est possible d'utiliser les touches Page Up et Page Down, pour augmenter ou dimi-nuer la sensibilité. L'augmentation de la sensibilité permettant en outre d'amplierou de réduire l'intensité des mouvements virtuels par rapport aux mouvements réels.Ces touches modient également la sensibilité des touches Z, S, Q, D, A, E, W, X,Haut, Bas, Gauche et Droite.

L'appui sur la touche R permet d'activer la connexion d'une Wiimote à la scène.Pour lier la Wiimote, il est nécessaire d'appuyer simultanément sur les boutons A et

92

B de la petite télécommande. Après avoir appuyé sur ces boutons, les leds de la Wii-motent se mettent à clignotter, et 30 secondes sont disponibles pour la synchroniserà l'ordinateur, en appuyant sur la touche R du clavier. Une fois la synchronisationeectuée, la manette émet une légère vibration et le détecteur infrarouge est auto-matiquement activé. L'utilisateur peut alors se déplacer pour proter du systèmede headtracking.

La touche I permet, quant à elle, d'activer le détecteur infrarouge. L'ajout de cettefonction a été nécessaire car l'activation de la caméra infrarouge ne fonctionne pas àtous les coups. Il est donc parfois nécessaire d'appuyer plusieurs fois sur ce boutonpour activer la caméra infrarouge de la Wiimote, qui doit avoir été préalablementconnectée à l'ordinateur, grâce à l'appui sur la touche R.

93

Chapitre 6

Conclusion

Le headtracking est un procédé utilisé dans le cadre de la réalité virtuelle qui a unbel avenir devant lui, tant les applications sont nombreuses et intéressantes. Ce documentnous a permis de nous familiariser avec le principe de headtracking et de comprendrecomment il est possible de développer un programme qui met en application ce procédé.

Tout au long de notre travail, nous avons présenté notre approche du problème quiconsiste à utiliser la caméra infrarouge de la wiimote pour détecter des sources d'infra-rouges posées de part et d'autre d'une paire de lunettes portées par un utilisateur. Nousavons également détaillé le matériel utilisé pour mettre en place notre système de head-tracking ; il s'agit principalement d'une wiimote, d'une paire de lunettes équipées de ledsinfrarouges et d'un gant infrarouge, pour détecter la position de la main (Le terme hand-tracking est alors employé). En plus des outils utilisés, nous avons également parlé demoyens alternatifs utiles à la mise en oeuvre d'un système de headtracking plus perfor-mant (utilisation de lunettes à polarisation, remplacement de la Wiimote par une camérastéréoscopique, ...). Ensuite, nous avons présenté les concepts théoriques qui ont été utili-sés pour implémenter notre module. En eet, nous avons vu comment calculer la distanceentre l'utilisateur et la caméra, ainsi que l'angle formé entre la normale de cette caméra etla position l'utilisateur, en utilisant les règles de trigonométrie dans un triangle rectangle.Quelques rappels de mécanique de base ont également été proposés, ceux-ci étant utiliséspour la modélisation de la trajectoire de la balle, dans notre application de tennis de table.

Après avoir développé notre approche, nous avons parlé des diérentes fonctionnalitésde notre module, dont les plus importantes sont comment le headtracking est géré, com-ment éviter que l'utilisateur ne sorte du champ de vision de la caméra, et comment gérerles tremblements perçus à une plus grand distance. Nous avons aussi parlé d'autres fonc-tions telles que la gestion de plusieurs caméras ou encore l'ajout de la 3D stéréoscopique.

Pour terminer, nous avons introduit quelques exemples d'applications du concept deheadtracking qui ont été réalisés pour mettre en application les outils développés. Parmices applications, un jeu de tennis de table, un eet fenêtre, un visualisateur de formes, oude photographies ont notamment été présentés.

94

Bibliographie

B

[1] Paul Bourke. Creating and viewing anaglyphs, http://local.wasp.uwa.edu.au/~pbourke/texture_colour/anaglyph/.

D

[2] Téléchargement de Cwiid. http://packages.debian.org/fr/sid/libcwiid-dev.

[3] Explorateur de chiers Nautilus. http://doc.ubuntu-fr.org/nautilus.

[4] Eet de ghosting. http://en.wikipedia.org/wiki/File:TV_ghosting_

interference.jpg.

[5] Image de la Playstation Eye. http://psp-white.blog.playersrepublic.fr/

images/medium_playstation_eye_cam_sc1.jpg.

[6] Site Web de OpenGL. http://www.opengl.org/.

[7] Matrices de projection. http://arkham46.developpez.com/articles/office/

vbaopengl/?page=page_3.

[8] Téléchargement de WiiRemoteJ (Documentation incluse). http://www.

world-of-cha0s.hostrocket.com/WiiRemoteJ/.

E

[9] Sony Playsation Eye. http://www.generation-nt.com/

ps3-playstation-eye-head-tracking-actualite-69060.html.

G

[10] GDC. http://www.computer.org/portal/web/csdl/doi/10.1109/MPRV.2008.

53.

H

[11] Chris Harrison. http://www.chrisharrison.net/.

[12] Webcam Headtracking. http://www.youtube.com/results?search_query=

headtracking+webcam\&aq=f.

95

I

[13] Java Native Interface. http://java.sun.com/docs/books/jni/.

J

[14] JOGL. https://jogl.dev.java.net/.

L

[15] Johnny Chung Lee. http://johnnylee.net/projects/wii/.

M

[16] Java Virtual Machine. http://fr.wikipedia.org/wiki/Machine_virtuelle_

Java.

O

[17] OpenCV. http://opencv.willowgarage.com/wiki/.

P

[18] projectnatal wiki. http://www.computer.org/portal/web/csdl/doi/10.1109/

MPRV.2008.53.

R

[19] Statistically rigorous java performance evaluation. http://doi.acm.org/10.1145/1297105.1297033.

S

[20] Caméra stéréoscopique. http://a10.idata.over-blog.com/0/00/47/87/photos/

pr-060117-3dvx3-3qtr_lg.jpg.

T

[21] Eye Toy. http://www.eyetoy.com/shared/locale.asp?returnURL=/index.asp.

[22] dispositif de capture Track IR. http://flightsimx.s3.amazonaws.com/

wp-content/uploads/2009/05/001-550x470.jpg.

[23] Emetteur infrarouge Track IR. http://www.trackir.fr/19-67-thickbox/

classic-bundle-trackir-pro-trackclip-pro.jpg.

96

W

[24] Webcam. http://images.wikio.com/images/s/2da/

creative-webcam-live-effects.jpeg.

[25] Wiibrew. http://wiibrew.org/wiki/Wiimote/.

[26] sur Sourceforge Wiiuse. http://sourceforge.net/projects/wiiuse/.

[27] Project Hosting on Google Code WiiuseJ. http://code.google.com/p/wiiusej/.

[28] Wikipedia. http://www.computer.org/portal/web/csdl/doi/10.1109/MPRV.

2008.53.

97