TRAVAIL D`ÉTUDE ET DE RECHERCHE : Interactions 3D

!"#$%&'(')*+,&-"$./0%
'''1**2%'344563447
''
891:1);'<=>8?<@'@8'<@'9@AB@9AB@'C
)*$%&"D$.,*#'E<
F&"G'10&2H.%*
9.DI%H-.'J%"*KLI.H.MM%
!".'3447
@*D"N&%-%*$'C'<."*%';.*O&"*N
@/0.M%'9".*P,QR';"P,&"$,.&%')ESR'S,MI."'1*$.M,H.#
@*'D,HH"P,&"$.,*'"T%D'C
AS8U'VA%*$&%'SD.%*$.+./0%'%$'8%DI*./0%'N0'UW$.-%*$XR'S,MI."'1*$.M,H.#
Table des matières
I Introduction
Présentation du projet
3
1 Présentation du sujet
4
2 Présentation du CSTB
2.1 Salle immersive « Le Corbusier » . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Plateforme materielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Intégration de notre projet au CSTB . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
5
5
3 Présentation de Delta3D
6
II
7
Travail de Recherche
4 Inventaire
4.1 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Organisation du site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III
Implementation
8
8
8
8
10
5 Architecture GameManager
5.1 Introduction . . . . . . . . . . . . . . . . . . .
5.2 Notion d’Acteur . . . . . . . . . . . . . . . . .
5.2.1 Projet, Map, STAGE . . . . . . . . .
5.2.2 Acteurs, Proxies et Propriétés . . . . .
5.2.3 Bibliothèques d’acteurs . . . . . . . .
5.3 Game Manager et Messages . . . . . . . . . .
5.3.1 Game Manager : GM . . . . . . . . .
5.3.2 Game Actor . . . . . . . . . . . . . . .
5.3.3 Game Manager Component . . . . . .
5.3.4 Game message . . . . . . . . . . . . .
5.3.5 Créer une simulation avec GameStart
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
11
12
13
14
14
15
15
16
16
6 Wiimote
6.1 Présentation . . . . . .
6.2 Driver . . . . . . . . .
6.3 Intégration à Delta3D
6.4 Utilisation . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
17
18
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATIÈRES
2
7 Application de test
7.1 Introduction et but . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
19
8 Acteurs externes à l’application
8.1 Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Traitement des Messages et événements . . . . . . . . . . . . . . . . . . . . . . . .
21
21
22
9 Intégration des acteurs externes
9.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Intégration du composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Contraintes, intéractions isolées . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
23
23
23
IV Résultats obtenus
Conclusion
Perspectives
26
10 Planning
27
11 Résultats obtenus
11.1 Tests d’intégration au CSTB . . . . .
11.1.1 Contexte . . . . . . . . . . . .
11.1.2 Déroulement des tests . . . . .
11.1.3 Complexité de l’intégration . .
11.1.4 Lancement de l’application . .
11.2 Bilan . . . . . . . . . . . . . . . . . . .
11.2.1 Concernant notre architecture .
11.2.2 Déplacement des acteurs . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12 Conclusion
13 Travaux à poursuivre
13.1 Couche réseau . . . . . . . . . .
13.2 Centrale inertielle . . . . . . . .
13.3 Gestaction . . . . . . . . . . . .
13.4 Fonctionnalités supplémentaires
13.5 Site web : Retour d’utilisateurs
28
28
28
28
28
29
29
29
29
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
31
31
32
32
Première partie
Introduction
Présentation du projet
3
Chapitre 1
Présentation du sujet
Le sujet de notre projet est : Les interactions 3D.
Ce projet comprend tout d’abord une partie recherche qui consiste en la réalisation d’un inventaire interactif des différents périphériques d’interaction 3D existants. Cet inventaire permettra
de se faire une idée précise des produits existants et éventuellement d’utiliser l’un de ces produits
dans notre partie développement.
La partie principale de ce projet a pour but de développer de nouvelles façons d’interagir avec un
environnement 3D. Le CSTB (Centre Scientifique et Technique du Bâtiment) de Sophia Antipolis
dispose d’une salle immersive, permettant de créer des scènes 3D très réalistes. L’environnement
logiciel de cette salle repose sur le moteur Delta3D. Actuellement, les interactions se font de
manière classique, au moyen d’un clavier et d’un joystick. Notre but est de créer des « acteurs »
Delta3D utilisant d’autres types de périphériques, et de pouvoir intégrer ces acteurs, développés
de façon autonome, dans une scène déjà conçue au CSTB, sans avoir de modification à apporter
à leur code.
Ce qui nous intéresse également est le fait que actuellement, les spectateurs qui prennent place
dans la salle immersive sont totalement passifs, le contrôle de la caméra étant confié à un opérateur
assis à la console de commande.
On voudrait rendre les scènes plus interactives, avec la possibilité pour chaque spectateur de
disposer de son propre avatar dans la scène et d’un périphérique lui permettant de le diriger et
pourquoi pas d’interagir virtuellement avec les autres spectateurs présents.
4
Chapitre 2
Présentation du CSTB
Le Centre Scientifique et Technique du Bâtiment est un organisme public, qui est à la pointe
dans le domaine du bâtiment. Son but est d’améliorer la sécurité et le bien-être dans les nouvelles
constructions. Par exemple : résistance au vent, insonorisation, lutte contre l’incendie, etc...
Le CSTB possède plusieurs sites en France. Celui de Sophia Antipolis possède une salle immersive, qui permet de recréer sur une simulation informatique en 3D n’importe quel bâtiment ou
même une ville entière.
2.1
Salle immersive « Le Corbusier »
Cette salle possède un écran de projection conique de 9 mètres de diamètre et de 2.80 mètres
de haut, sur lequel sont projetées des images en très haute résolution (5000 x 1200 px). La salle
est équipée d’une quinzaine de sièges et dispose également d’une système de sonorisation complet
permettant des simulations audio-visuelles très poussées.
Bien qu’elle existe depuis plusieurs années, la salle a cependant été profondément modifiée cette
année, avec le remplacement complet de l’infrastructure matérielle.
2.2
Plateforme materielle
Jusqu’à l’an dernier, la salle disposait d’un super-calculateur SGI plutôt imposant (2 armoires
complètes) pour générer les scènes 3D, le tout relié a 3 video-projecteurs CRT.
La nouvelle plate-forme se compose de :
– 3 Vidéo-projecteurs DLP
– Une station de travail Dell :
– Bi-processeur Intel Xeon dual-core
– 32 Go de RAM
– 2 cartes graphique nVidia Quadro FX
– OS : Linux Mandriva (64 bits)
2.3
Intégration de notre projet au CSTB
Le but du projet est de créer un acteur indépendant, sous la forme d’une bibliothèque partagée,
qui pourra être intégrée facilement à une application déjà fonctionnelle au CSTB. Et cela sans
avoir à modifier le code ou à recompiler quoi que ce soit dans l’application.
5
Chapitre 3
Présentation de Delta3D
Delta3D est un moteur utilisé pour des jeux, simulations, modélisations et autres applications
en 3D. Il a été créé par l’institut MOVES, de la « Naval Postgraduate School » (Etats-Unis), et
est développé par l’armée Américaine. Le fonctionnement de Delta3D et ses fonctionnalités seront
étudiés en détails dans la partie « Implémentation ». Notons qu’il est écrit en C++.
Compagnies utilisant Delta3D Delta3D est surtout utilisé par des organisations gouvernementales ou militaires : Naval Postgraduate School, Office of Naval Research, Program Manager
for Training Systems, Naval Education and Training Command ...
OS supportés
– Windows
– Linux
– Mac OS X (support partiel)
Licence
Delta3D est sous licence GNU Lesser General Public License (LGPL).
Dépendances Pour pouvoir fonctionner, Delta3D utilise de nombreuses bibliothèques (libres)
externes telles que :
– Open Scene Graph (OSG) pour la 3D
– Open Dynamics Engine (ODE) pour la physique
– Character Animation Library (CAL3D) pour l’animation des personnages
– OpenAL pour l’audio
– Producer pour les périphériques d’entrée
– et bien d’autres...
Le rendu dans Delta3D s’effectue via OpenSceneGraph, qui utilise lui-même OpenGL.
Fig. 3.1 – Logo Delta3D
6
Deuxième partie
Travail de Recherche
7
Chapitre 4
Inventaire
Durant la première partie du TER, nous avons réalisé un inventaire des périphériques 3D
existants.
4.1
Limites
L’objectif de ce travail est de faire l’état de l’art des périphériques 3D disponibles. Or il est
souvent difficile de trouver des informations pertinentes sur ce genre de matériel. En effet même
les sites des constructeurs restent très vagues quant aux possibilités réelles de leurs produits. De
plus, il est presque impossible d’obtenir des tarifs pour la plupart des produits, sachant que ceux
ci coûtent en général plusieurs milliers d’euros.
Notre but est donc de regrouper le maximum d’informations au même endroit, afin d’avoir
un aperçu complet de l’offre de périphériques 3D. Il s’agit en même temps pouvoir recueillir des
critiques venant des utilisateurs de ces produits.
4.2
Travail réalisé
Nous avons réalisé un site web qui contient notre inventaire. Ce site a été rempli avec le
maximum d’informations disponibles, ce qui n’est d’ailleurs pas grand chose pour certains des
périphériques ! Cet inventaire est interactif puisqu’il permet aux visiteurs du site de laisser des
commentaires sur un produit ou bien de regarder les commentaires déjà laissés par d’autres utilisateurs.
Le site est en ligne à cette adresse : http://thx009.free.fr/TER/inventaire/
4.3
Organisation du site
Dans notre inventaire, nous avons choisi de répartir les périphériques en 6 catégories qui sont :
– Motion capture
– Gloves
– Haptic devices
– HMD : « Head Mounted Displays »
– 3D input devices
– 3D Displays
Motion capture il s’agit entre autres des centrales inertielles, qui permettent de capturer un
mouvement de manière plus ou moins complexe.
8
4.3. ORGANISATION DU SITE
9
Gloves Les gants interactifs permettent de « toucher » des objets dans une scène en 3D et
d’interagir avec eux. Certains sont dotés de systèmes à retour de force, qui permettent d’augmenter
le réalisme.
Haptic devices Ce sont des périphériques dont le principal intérêt est de fournir un retour
d’effort, la plupart sont composés d’une sorte de stylet relié a plusieurs moteurs, qui donnent une
sensation de toucher très réaliste.
Head Mounted Displays Il s’agit de casques ou de lunettes munis de petits écrans LCD. Ils
permettent une immersion totale dans un environnement en 3D. La plupart sont également munis
d’un système audio, afin de rendre l’environnement le plus réaliste possible.
3D input devices Ce sont des périphériques d’entrée souvent similaires à des Joysticks mais
leur conception a été pensée pour la 3D. Ils disposent en effet de 6 degrés de liberté, contre 3 pour
les périphériques plus classiques.
3D Displays Il s’agit d’écrans LCD qui utilisent la stéréoscopie, afin d’afficher des images en
3D sans avoir besoin d’utiliser des dispositifs externes, comme des lunettes par exemple.
Fig. 4.1 – Extrait d’une page de l’inventaire
Troisième partie
Implementation
10
Chapitre 5
Architecture GameManager
5.1
Introduction
Ce chapitre présente quelques notions fondamentales utilisées dans Delta3D, en particulier les
notions d’acteur et de message. Il vise également à montrer l’un des composants principaux de
Delta3D, qui sera utilisé dans notre implémentation : le Game Manager.
5.2
5.2.1
Notion d’Acteur
Projet, Map, STAGE
Projet Un projet est composé de plusieurs maps, de la même manière qu’un jeu peut se dérouler
dans plusieurs niveaux. Il est responsable des ressources importées dans l’éditeur, comme les
textures, les maillages et les sons.
Map Une map est constituée d’un ensemble d’acteurs, plus précisément de proxies d’acteur. Elle
est visualisable et éditable dans l’éditeur STAGE. Une map est enregistrée sous forme d’un fichier
XML, possédant des balises pour chaque acteur et leurs propriétés, ainsi que des informations
générales et les librairies et ressources importées.
Fig. 5.1 – Project - Map : Diagramme de Classes
11
12
CHAPITRE 5. ARCHITECTURE GAMEMANAGER
STAGE STAGE (Simulation, Training, And Game Editor) est un éditeur permettant de construire
un environnement 3D utilisable par le moteur Delta3D. Il est développé en C++/QT.
Eléments de l’interface graphique de STAGE :
– barre de menus
– barre d’outils
– éditeur de propriétés d’un acteur
– vues (haut, côté, face, perspective)
– explorateur de ressources (maillages, textures, sons, particules, ...)
– explorateur des acteurs
Fig. 5.2 – Editeur : STAGE
5.2.2
Acteurs, Proxies et Propriétés
Actor Un acteur est un objet qui possède des propriétés qui lui sont propres. Le terme d’acteur
est assez global, il peut être un maillage (par exemple un avion, un personnage), un système de
particules, une texture, du son, un terrain, une caméra, une source de lumière ... Les acteurs sont
des objets spécialisés qui permettent de définir un jeu ou une simulation.
ActorProxy Un proxy sert à envelopper un acteur. Les proxies sont de simples classes stockant
des données. Ils servent à deux choses. Tout d’abord, ils fournissent une interface standardisée
reconnue par l’éditeur (STAGE), contrairement aux acteurs proprement dits qui peuvent contenir
5.2. NOTION D’ACTEUR
13
n’importe quoi. Ils ont de plus accès à toutes les caractéristiques de l’acteur, en particulier les
propriétés.
Ces proxies permettent aux acteurs de communiquer leur comportement à des applications
externes, et d’établir un protocole de communication générique entre eux.
ActorProperties Ce sont les propriété d’un acteur, affichables et éditables, que ce soit dans
l’éditeur STAGE ou dynamiquement dans le code. Elles permettent de changer le comportement
d’un acteur en fonction du contexte de la simulation, et ce sans changer le code. Par exemple, un
drapeau est caractérisé par sa longueur, sa largeur et sa texture.
Les propriétés fournissent donc un mécanisme du type accesseurs/modifieurs, similaire aux
Java Beans.
Fig. 5.3 – Actor et ActorProxy : Diagrammes de Classes
5.2.3
Bibliothèques d’acteurs
Utilité Les bibliothèques d’acteurs sont des composants distribuables qui servent à encapsuler
des groupes d’acteurs et leurs proxies. Ce sont des librairies dynamiques de code C++ qui peuvent
être chargées dans l’éditeur ou dans d’autres applications. C’est un des outils les plus intéressant
de Delta3D dans le cadre de notre projet, qui consiste à intégrer un module externe dans une
application existante.
LibraryManager, ActorPluginRegistry et ActorType
LibraryManager Le LibraryManager gère les bibliothèques enregistrées et les types des
acteurs que chaque bibliothèque peut créer. C’est à travers lui que l’éditeur connait les acteurs
externes, plus précisément leurs proxies.
ActorPluginRegistry Cette classe permet aux développeurs de créer leur propre librairie en
l’étendant. Elle permet, via un ActorProxy, de créer un acteur à partir de son type (ActorType).
CHAPITRE 5. ARCHITECTURE GAMEMANAGER
14
L’éditeur ne connait rien des classes de l’objet/acteur, c’est l’ActorPluginRegistry qui sert de
passerelle. L’ActorPluginRegistry sert à enregistrer les types d’acteurs fournis et à les lier aux
proxies correspondants.
ActorType C’est une simple classe de données qui décrit un type d’acteur particulier. Il y
a un ActorType pour chaque classe d’acteur. Le type est caractérisé par un nom, une catégorie et
une description. La catégorie donne la hiérarchie de l’acteur, par exemple : "véhicule.voiture.4x4".
Intégrer une bibliothèque avec STAGE Une bibliothèque peut être importée très simplement dans STAGE. Les acteurs disponibles dans la bibliothèque s’ajoutent à la liste des acteurs
standards, on peut alors ajouter des acteurs dans la map.
5.3
Game Manager et Messages
Cette section vise à présenter l’infrastructure du Game Manager, qui sert à gérer les intéractions
entre acteurs dans un monde 3D. Elle donne une vue d’ensemble de ce que sont les Game Actors,
Game Components et Game Messages.
Fig. 5.4 – Organisation du Game Manager
5.3.1
Game Manager : GM
Le Game Manager est le coeur d’une application. Il gère tous les acteurs, les composants et les
messages. Ces notions seront expliquées plus loin. Le manager sert à gérer les intéractions entre
5.3. GAME MANAGER ET MESSAGES
15
tous les acteurs et les composants dans un monde 3D, et ce de manière générique et automatique.
Il serait bien sûr possible de gérer tout cela à la main mais cela deviendrait vite fastidieux !
Un exemple :
Comment intégrer un objet dans la scène qui puisse être utilisé par un personnage ?
Comment faire connaitre les actions d’un acteur aux autres instances d’acteur présentes ?
C’est là qu’intervient le Game Manager, qui fournit une architecture générique pour gérer ces
intéractions.
Afin de superviser une simulation, le GM effectue 3 tâches :
La première, la plus importante, est la gestion des messages (Game Messages), qui permettent la
communication entre les acteurs, les composants et le GM. Les messages peuvent être utilisés lors
d’événements, par exemple l’entrée d’un nouvel acteur dans la scène, ou bien une action effectuée
par un acteur. Mais ils ne s’envoient pas tout seuls, c’est le GM qui s’en charge : il reçoit et diffuse
les messages.
La deuxième tâche du GM est de cataloguer tous les acteurs dans l’application. Ceci inclut les
acteurs normaux et les GameActors (voir plus loin). Il repère les acteurs qui ont été créé dans le
code ou dans la map (via l’éditeur STAGE). Il indique aux acteurs de traiter les messages, gère
leurs entrées/sorties dans la scène et les font évoluer à intervalle régulier (à chaque frame).
La troisième tâche du GM est de gérer les composants (GMComponent). Un composant est un
objet de haut niveau qui utilise les messages. Contrairement aux acteurs, qui ne reçoivent que les
messages qui leurs sont dédiés, les composants reçoivent tous les messages. De plus, ils ne peuvent
avoir qu’une seule instance et ils assurent des fonctions plus globales que les acteurs comme la
gestion des périphériques (réseau, joystick ...).
5.3.2
Game Actor
La notion d’acteur a été vue plus haut. Un GameActor est simplement un acteur qui travaille
directement avec un Game Manager. Les acteurs normaux sont des objets statiques dans le monde.
Ils peuvent représenter des maillages statiques comme des bâtiments, des arbres, des sources
de lumières immobiles, un terrain. Ils ne possèdent pas de comportements. Les Game Actors,
quant à eux, donnent vie à la simulation. Ils possèdent des comportements qui leur sont propres,
peuvent envoyer et recevoir des messages, plus généralement ils peuvent intéragir avec le monde
environnant.
Tout comme les acteurs normaux, un GameActor a besoin d’un proxy (GameActorProxy). En
fait, le Game Manager ne connait que les proxies, ce qui lui permet d’être générique et donc plus
flexible. Il ne fait par exemple pas la différence entre un personnage et un véhicule.
5.3.3
Game Manager Component
Un GMComponent est un objet géré par le Game Manager, qui peut recevoir et envoyer
des messages. Contrairement aux acteurs, il reçoit tous les messages du système. Il fournit des
comportements de haut niveau. L’utilisation de composants est la principale solution pour ajouter
des comportements avancés, et ce sans modifier le Game Manager qui reste ainsi générique.
Par exemple, si l’on veut rajouter une couche pour l’audio ou un nouveau périphérique d’entrée,
il suffit de créer un composant qui pourra être rajouté/supprimé dynamiquement à l’exécution.
Puisque les composants reçoivent tous les messages du système, ils peuvent connaître tout
ce qui se passe, et en particulier les états des acteurs. On peut créer un composant simple, qui
attend des messages spécifiques et qui détecte et traite les événements d’un périphérique tel que
CHAPITRE 5. ARCHITECTURE GAMEMANAGER
16
le clavier. On peut aussi avoir un composant plus complexe, qui possède une liste d’acteurs et
effectue certaines actions en fonction de leurs états.
5.3.4
Game message
Une des principales fonctionnalités du Game Manager, et plus généralement de Delta3D, est
l’utilisation de messages. Les messages sont typiquement utilisés pour envoyer des données (ex :
changement d’une propriété d’un acteur) ou des comportements (requêtes ou commandes).
Un acteur ou un composant envoie un message au Game Manager, qui le diffuse aux autres
acteurs/composants concernés. Le composant, qui reçoit tous les messages, peut les traiter directement ou renvoyer des messages plus spécifiques à d’autres acteurs.
Les acteurs ne reçoivent pas tous les messages. En effet, puisqu’il peut y avoir de très nombreux
acteurs dans le monde, le fait d’envoyer tous les messages à tous les acteurs peut nuire aux
performances. Les acteurs ne s’enregistrent qu’à certains types de messages. Ce peut être par
exemple un message de communication entre acteurs, ou bien le « Tick » (message qui est envoyé
à chaque frame).
Événements : Game Events Les événements (Game Events) sont de simples mots-clés qui
sont envoyés dans un message du type GameEventMessage lorsqu’un certain événement se produit.
Ils représentent une action telle que ’Entre dans la salle’.
Tick message A chaque frame, le message ’Tick’ est envoyé par le Game Manager.
L’utilisation d’un message à chaque tour de boucle permet de ne pas mettre à jour tous les
acteurs. En effet, ceux-ci peuvent être nombreux et certains sont statiques et donc n’ont pas besoin
d’être modifiés, ou bien attendent un événement spécifique et asynchrone. Ainsi, seuls les acteurs
qui se sont enregistrés à ce message se mettent à jour à chaque frame.
Fig. 5.5 – Game Messages
5.3.5
Créer une simulation avec GameStart
Le Game Manager fournit un point d’entrée pour les applications : GameStart.
GameStart est un exécutable qui sert à lancer des applications, sans avoir à compiler un
exécutable. Ainsi notre application est sous la forme d’une bibliothèque dynamique qui contient
les classes des acteurs, proxies et composants. Elle possède aussi un point d’entrée (classe héritant
de GameEntryPoint), qui sert à charger l’application par le GameStart.
GameEntryPoint permet de créer le Game Manager automatiquement. Il permet ensuite de
créer tous les composants, de charger la map et d’effectuer toutes les tâches préliminaires que l’on
veut, avant de commencer la simulation.
Chapitre 6
Wiimote
6.1
Présentation
La Wiimote est la « manette » de la console de jeu Wii de Nintendo, sortie en décembre 2006.
Contrairement aux manettes de jeu classiques, elle a la particularité de posséder des accéléromètres
qui permettent de connaître les mouvements effectués par l’utilisateur. Elle dispose également d’un
récepteur Infra-Rouge qui permet à la wiimote de se repérer dans l’espace, en fonction de « spots »
émis par une barre munie de plusieurs diodes IR. De plus, la Wiimote est sans-fil et utilise le
protocole Bluetooth pour communiquer avec la console.
La Wiimote dispose de plusieurs accessoires dont le « Nunchuk », qui est un joystick possédant 2 boutons, il est également munis d’accéléromètres. Nous utiliserons le Nunchuk dans notre
implémentation.
Notons également qu’un des gros avantages de ce périphérique est son prix. En effet, une Wiimote
coûte 40 e et un Nunchuk 20 e ce qui est peu comparé aux prix d’autres périphériques ayant
moins de possibilités.
6.2
Driver
Comme nous l’avons dit, une Wiimote utilise un protocole de communication standard, ce qui
fait que de nombreux programmeurs se sont mis à programmer des drivers pour utiliser la Wiimote
avec un ordinateur équipé en Bluetooth. On trouve donc sur internet de nombreux drivers, à la
qualité et aux fonctionnalités variables pour n’importe quel OS (Linux, Mac OS X, Windows).
Dans le cadre de notre projet, nous travaillons sous Linux, et avons donc choisit comme base
de travail le driver Linux qui nous semblait le plus complet. Ce driver est bien entendu écrit
en langage C. Il nous donne facilement accès à la mémoire de la Wiimote et permet de récupérer
l’état des différents boutons de la télécommande ainsi que les valeurs des accéléromètres. Il permet
également d’utiliser le haut-parleur intégré et la fonction de vibration.
6.3
Intégration à Delta3D
Delta3D utilise une architecture orienté objet et est écrit en C++, nous avons donc écrit une
classe en C++, qui sert d’interface entre le driver de la Wiimote et Delta3D.
17
CHAPITRE 6. WIIMOTE
18
Nous avons donc un objet de type « Wiimote » qui permet de récupérer n’importe quel paramètre
de la Wiimote directement en C++. Il permet également d’envoyer diverses informations à la
Wiimote (allumage d’une LED, activation des vibrations, etc...). Notons également que notre
architecture permet de connecter jusqu’à 4 Wiimote à la même machine.
6.4
Utilisation
La Wiimote est utilisé dans Delta3D au niveau de notre InputComponent et l’intégration dans
le code est semblable à celle d’un joystick, ou de n’importe quel autre périphérique d’entrée.
Nous n’avons pas eu de problème d’utilisation de la Wiimote dans Delta3D. Nous avons cependant rencontré un problème de gestion de mémoire qui faisait planter l’application à certaines
occasions. Après vérifications, le problème ne semble pas venir du driver de la Wiimote, et il semble
que nous soyons tombé sur un problème de gestion de la mémoire dans Delta3D, étant donné qu’il
n’est pas réaliste de débugger Delta, nous nous sommes contentés d’allouer plus de mémoire au
driver, que ce qui lui est normalement nécessaire. Cette solution est évidemment peu élégante mais
elle résout le problème.
Fig. 6.1 – Wiimote et Nunchuk
Chapitre 7
Application de test
7.1
Introduction et but
Le but de cette partie est de créer un module externe contenant un acteur contrôlé grâce à une
Wiimote. Ce type d’acteur sera intégré dans les applications de la salle immersive du CSTB. La
seule information connue est que ces applications utilisent un Game Manager. Pour tester cette
intégration au cours de l’élaboration du module, une application de test a été créée, celle-ci étant
également basée sur un Game Manager. Cela permet de tester notre module dans une application
et de tester son intégration.
7.2
Fonctionnalités
L’application de test est minimale et ne propose qu’un nombre restreint de fonctionnalités. Elle
sert seulement à vérifier que notre bibliothèque peut être ajoutée de manière transparente à une
application existante.
Map Nous avons créé une map très simple représentant une petite ville avec quelques immeubles,
un environnement (le ciel) et un terrain plat basique. Nous avons également placé dans cette map
un GameActor tout simple, contrôlé au clavier.
Tout cela est réalisé grâce à l’éditeur STAGE.
Caméra, MotionModels On veut pouvoir changer de MotionModel de manière dynamique,
afin de changer le comportement de la caméra : Orbit, Walk, Fly, FPS, Collision, etc... Notre
navigation (au clavier) permet de déplacer la caméra comme l’on veut. Il est important de vérifier
que cela n’interfère pas avec nos acteurs externes. En effet, l’utilisation d’une même touche pour
des actions différentes peut entraîner des conflits, de même pour la gestion de la caméra, qui ne
peut pas aller dans 2 directions différentes en même temps.
Acteurs Nous avons un acteur « figurant » dans la map juste pour tester que cela ne pose pas
de problèmes avec nos acteurs, ainsi qu’un terrain qui entoure la ville.
Un GameActor (un tank) est également présent : ses déplacements sont contrôlés avec les
touches du clavier. Les mouvements prennent en compte l’inertie de l’engin, avec une accélération
et un freinage poussifs. Son déplacement entraîne un jet de poussières, créé par un système de
particules. Il possède ses propres propriétés de vitesse et vitesse de rotation.
La ville elle-même est représentée en tant que GameActor. Même si elle ne possède pas de
comportements proprement dits, elle est réceptive à un événement/message "Tsunami" (la ville
"s’incline", renversant le tank ...). Elle possède la propriété booléenne pour savoir si un tsunami
est en train de passer.
19
20
CHAPITRE 7. APPLICATION DE TEST
Déplacements du tank et collisions Les déplacements de l’acteur tank dans la ville sont
gérés de façon qu’il reste au niveau le plus bas. Cela suffit pour l’application de test, dont le
but n’est pas de recréer des situations complexes, même si cela peut être utile pour chercher des
fonctionnalités que peuvent apporter la wiimote. La map ne possédant qu’un seul niveau (celui
de la ville), l’acteur se déplace soit sur le sol, soit sur le toit. Le fait qu’il n’y ait pas de niveaux
inférieurs a l’avantage de ne pas gêner les mouvements.
Les collisions ne sont gérées qu’en mode de déplacement CollisionMotionModel : les acteurs
ont une zone de collision de type maillage, ce qui permet un contact plus réaliste. Ainsi, dans ce
mode, la caméra ne peut traverser les murs et le tank... Par contre, les collisions entre le tank et
les murs ne sont pas gérées de facon réalistes : le tank se retrouve sur le toit ... La raison est que
nous effectuons les déplacements du tank à la main et ne stoppons pas le tank en cas de contact.
Chaque acteur possède son proxy, qui permet d’avoir accès et de modifier ses propriétés initiales
dans l’éditeur STAGE.
InputComponent Ce composant permet d’effectuer des actions globales, comme metre en
marche / arrêter le tank, le mettre en mode turbo. Elles sont effectuées lors des événements
clavier correspondants (appui sur certaines touches).
Il permet également d’augmenter/diminuer la vitesse de la simulation. C’est-à-dire que les
messages ’TICK’ sont envoyés avec une fréquence plus ou moins grande.
Point d’entrée (GameEntryPoint) Le point d’entrée crée les MotionModels, crée et enregistre l’InputComponent dans le GameManager, charge la map et les acteurs (plus précisément
leus proxies) présents, place la caméra afin d’avoir une vue globale de la ville.
Fig. 7.1 – Aperçu de l’application de test
Chapitre 8
Acteurs externes à l’application
Nous avons écrit deux modules externes.
Le premier permet de contrôler les acteurs au clavier, il nous a servi pour effectuer les premiers
tests d’intégration de notre bibliothèque à l’application, alors que l’intégration de la wiimote n’était
pas encore finalisée.
Le fait de concevoir une architecture indépendante de la wiimote et de son driver a d’autres
avantages.
Même si l’équipe n’est que de 2 personnes, il faudrait au moins 2 wiimotes chacun pour tester
les intéractions entre acteurs. Or nous n’avions pas assez de périphériques.
Un autre avantage est de se séparer les tâches : pendant que l’un s’occupe de la wiimote et de
son intégration, l’autre se concentre sur l’organisation du programme et des messages.
Le second permet de contrôler les acteurs via une wiimote.
Les modifications par rapport au module sans wiimote concernent l’intégration de la wiimote
dans le code et la gestion des événements du périphérique, que ce soit à la réception d’un message
particulier, ou pour envoyer un message.
Ce module a l’avantage de tester les intéractions entre plusieurs acteurs à l’aide de plusieurs
wiimotes. C’est ce module qui sera intégré et testé au CSTB.
Emulation de la wiimote Il est possible de simuler les déplacements plusieurs wiimotes avec
un clavier, en assignant différentes touches pour chaque acteur. Cela a été fait dans le module sans
wiimote, en ajoutant une propriété "Numéro" aux acteurs : ceux-ci réagissent à certaines touches
en fonction de leur numéro (OLKM pour le 1, YHGJ pour le 2).
Mais il n’est pas possible de vérifier le bon traitement des messages par chaque acteur, qui peut
les interpréter différemment selon son état et la cible du message. De même, la wiimote possède
certaines fonctionnalités qui le clavier n’a pas (voir le chapitre Wiimote).
8.1
Fonctionnalités
Nos modules permettent de créer des « GameMeshActor » (maillage représentant un personnage). Ils permettent également des déplacer ces acteurs et de les faire interagir à l’aide de messages.
Tout sela est fait avec la wiimote, ou émulé au clavier.
Composant externe Nous utilisons un composant personnalisé pour gérer tous les acteurs
externes : il possède la liste de tous leurs proxies et a donc également accès aux wiimotes. Un de
ses rôles est de mettre à jour l’état de chaque wiimote.
21
22
CHAPITRE 8. ACTEURS EXTERNES À L’APPLICATION
Communication entre acteurs Le composant possède une fonction utilitaire qui permet de
connaître l’acteur visible le plus proche d’un autre. Cela leur permet de s’envoyer des messages du
type « Bonjour ». On ne veut évidemment pas que ce genre de message soit envoyé à des acteurs
éloignés.
Ainsi chaque acteur possède la propriété « ChampDeVision », qui représente la distance maximale laquelle il peut "voir" les autres acteurs.
Le message "bonjour" reçu par l’acteur le plus proche est caractérisé par la vibration de sa
wiimote.
Acteur principal Le premier de nos acteurs a être instancié est dit acteur « principal « . En plus
de ses fonctionnalités de base, il peut également quitter l’application ou bien envoyer un message
à tout les autres acteurs du même type. Par exemple, nous avons écrit un message qui fait tomber
tout les acteurs externes présents dans la scène.
Vue à la troisième personne Enfin, chacun de nos acteurs peut verrouiller la caméra sur lui
(vue à la troisième personne). Cela est réalisé à l’aide d’un Tripod qui permet d’attacher la caméra
à un objet quelconque. Chaque acteur possède son Tripod, qu’il active ou non.
8.2
Traitement des Messages et événements
Message « Bonjour » d’un acteur vers son plus proche voisin.
Lorsque l’utilisateur appuie sur le bouton correspondant de la wiimote, l’acteur associé demande au composant quel est son plus proche voisin. Il le met en tant que cible du message
(SetAboutActorId). Il faut noter que le message sera envoyé à tous les acteurs, même s’ils n’en
sont pas la "cible". La différenciation se fait lors de la réception du message : si l’acteur est la
cible, il fait vibrer sa wiimote. Sinon, il ne fait rien.
Message « Chute » lancé par l’acteur principal à tous les acteurs y compris lui-même. Le
message est envoyé lorsque cet acteur appuie sur le bouton approprié. C’est en fait au niveau
du component qui le message est envoyé : en effet, il regarde l’état de la wiimote du premier
acteur enregisté dans sa liste, qui correspond à l’acteur principal. Tous les acteurs qui recoivent
ce message tombent (leur maillage est renversé au sol).
Message « Lock » L’acteur émetteur se met en tant que cible dans le message, qui est envoyé
à tous les acteurs, y compris lui-même. Lorsqu’un acteur reçoit ce message : s’il en est la cible, il
active son Tripod (qui l’attache à la caméra). Sinon, il le désactive (il se lie à une caméra "nulle").
Message « UnLock » Il n’y a pas de message pour désactiver son Tripod. Mais il est possible de
désactiver tous les Tripods afin de revenir au mouvement de la caméra par défaut. Cela s’effectue
avec le même message "Lock", en ne spécifiant aucun acteur comme étant la cible du message.
Ainsi, chacun désactive son tripod. Le message est envoyé lorsqu’un des acteurs appuie sur le
bouton correspondant.
Quitter l’application envoyé par l’acteur principal à l’application. Aucun message n’est utilisé :
l’acteur demande à l’application du GameManager de s’arrêter.
Déplacements Pour pouvoir se déplacer, tous les acteurs reçoivent le message « Tick Local »à
chaque frame. A la réception de ce message, les acteurs doivent recalculer leurs positions. Les
déplacements utilisés sont basiques : avancer, reculer, tourner à droite ou à gauche. Ces événements
sont gérés avec le joystick de la wiimote.
Chapitre 9
Intégration des acteurs externes
9.1
Principe
Nos acteurs sont intégrés à l’application (au GameManager) via l’éditeur STAGE qui se charge
d’éditer le fichier XML de la map. Il suffit d’importer notre bibliothèque dans STAGE au préalable.
La map sera chargée au lancement de l’application.
On peux également éditer le fichier XML à la main, mais sa structure étant assez complexe, il
est préférable de laisser STAGE faire cela !
9.2
Intégration du composant
utilité Nous utilisons également un « Component »qui est chargé de mettre à jour la ou les
wiimotes connectées (une par acteur). Il permet également de gérer les actions globales des acteurs.
Dans le cadre d’une intégration d’acteurs qui possèdent des comportements complexes ou
utilisent des ressources externes, ou si l’on veut rajouter de nouvelles fonctionnalités à l’application,
le fait de pouvoir intégrer un composant devient préférable voire nécessaire.
approche originale Notons que notre approche est assez différente de ce qui se fait normalement, en effet Delta3D n’est pas vraiment conçu pour reçevoir un acteur sous cette forme de
« plug-in »que nous avons réalisé. Il a donc fallut faire un certain nombre d’arrangements pour
pouvoir intégrer notre composant dans l’application, plus précisément dans le Game Manager.
Normalement, un composant doit être créé dans l’EntryPoint du Game Manager. Or, comme
nous l’avons dit, nous n’avons pas accès au GameManager qui est dans le code de l’application et
nous nous refusons donc d’y toucher.
Nous avons donc créé un composant qui est intégré dans l’appli par un de nos acteur (en fait,
par son proxy). Le proxy est chargé d’instancier le composant et de le lier au Game Manager. Il
connait celui-ci car il fait partie de la map utilisée.
Comme il peut y avoir plusieurs acteurs et donc plusieurs proxies, mais un seul composant,
nous avons appliqué le design pattern « Singleton »pour notre composant afin qu’il n’en existe
qu’une seule instance.
9.3
Contraintes, intéractions isolées
Acteurs externes et Scène Les acteurs externes peuvent communiquer entre eux dans la scène
de l’application.
Ils peuvent se lier à la caméra avec des MotionModels ou un Tripod. Mais ils ne peuvent pas
la déplacer "à la main" ...
23
24
CHAPITRE 9. INTÉGRATION DES ACTEURS EXTERNES
Acteurs externes et Messages internes De plus, ils ne sont pas réceptifs aux messages
internes à l’application.
Pour cela, il faudrait connaitre leurs propriétés, comme leur type, leur nom, leur description.
On pourrait donc avoir besoin d’accéder au code source de l’application interne, ou de disposer
de ces information dans un format générique et public : ce peut être un fichier XML, ou bien un
ensemble de propriétés des messages visibles dans l’éditeur STAGE.
Cela n’est pas géré par la version actuelle de Delta3D (1.4).
Sans cette approche, il n’est pas possible d’avoir des interactions entre acteurs externes et
internes.
Acteurs internes et Messages externes Delta3D n’est pas conçu pour intégrer des plugins. Il est possible de définir des messages externes, mais leur utilisation par les acteurs internes
nécessite de modifier le code pour y rajouter l’enregistrement à ce type de message et le traitement
à effectuer lors sa la réception. Cela est contraire à notre but, qui est d’intégrer des acteurs sans
toucher à l’application.
Fig. 9.1 – Aperçu de 2 acteurs externes ajoutés dans l’application
9.3. CONTRAINTES, INTÉRACTIONS ISOLÉES
Fig. 9.2 – Intégration de la librairie dans l’application
25
Quatrième partie
Résultats obtenus
Conclusion
Perspectives
26
Chapitre 10
Planning
Nous présentons ici une version résumée du planning que nous avons suivi. De plus, nous ne
couvrons ici que la période suivant la pré-soutenance.
Le planning complet ainsi que les plannings individuels sont en ligne à l’adresse suivante :
http://thx009.free.fr/TER/
Semaine du 9 au 15 Avril :
– Ajout de périphériques dans notre inventaire
– Installation de Delta3D
– Découverte de Delta3D et des logiciels associés
Semaine du 16 au 22 Avril :
– Amélioration de l’ergonomie du site web
– Etude des tutoriaux de Delta3D
– Discussion sur une première architecture pour notre implémentation
Semaine du 23 au 29 Avril :
– Première visite au CSTB : démonstration de leurs applications
– Essai avec les fonctionnalités réseau de Delta3D
– Création d’une première bibliothèque pour utiliser la Wiimote dans Delta3D
– Réalisation d’une première application de test complète
Semaine du 30 Avril au 6 Mai :
– Suite et fin de l’implémentation concernant la Wiimote
– Ajout d’interaction entre nos acteurs (envoi de messages)
– Perfectionnement de l’application de test
Semaine du 7 au 13 Mai :
– Ajout de fonctionnalités à nos acteurs (messages, caméra personnalisé)
– Le 10 Mai : Tests au CSTB : intégration de notre bibliothèque dans une application
– Rédaction du rapport
Du 14 au 16 Mai : Fin de la rédaction de notre rapport
27
Chapitre 11
Résultats obtenus
11.1
11.1.1
Tests d’intégration au CSTB
Contexte
Scène Des acteurs pilotés par des Wiimotes se déplacent et communiquent dans la ville de
Cannes et dans le futur campus STIC.
Premier test Sur un portable possédant la même configuration logicielle que la machine de la
salle immersive.
Linux Mandriva (32bit), Bluetooth non intégré
Second test Dans la salle immersive.
Linux Mandriva (64bit), Bluetooth non intégré
11.1.2
–
–
–
–
–
Déroulement des tests
Installation du driver et des utilitaires Bluetooth
Installation du driver de la wiimote
Test de notre application de démonstration
Ajout de plusieurs de nos acteurs dans une scène du CSTB
Lancement de l’application et tests
11.1.3
Complexité de l’intégration
Les tests sur le portable n’ont posé aucun problème.
Nous avons eu des problèmes dans la salle immersive. En effet, l’adaptateur Bluetooth USB
n’était pas reconnu.
Après plusieurs essais, nous nous sommes rendus compte que le problème était matériel. En
effet, la machine est dans une salle dédiée à l’écart de la salle immersive, ce qui fait qu’il n’est pas
possible de connecter le module Bluetooth directement sur la machine, car il serait hors de portée
de fonctionnement. Nous avons donc utilisé la rallonge USB sur laquelle sont branchés clavier,
joystick, etc... et celle-ci était apparemment au maximum de sa capacité, il a donc fallu utiliser
une autre rallonge.
L’intégration de notre bibliothèque dans l’application a été rapide et simple. Il a simplement
fallu éditer le fichier XML de configuration, pour y déclarer l’importation de notre bibliothèque,
ainsi que les paramètres nécessaires pour créer 2 acteurs.
28
11.2. BILAN
11.1.4
29
Lancement de l’application
Nous avons rajouté 2 acteurs contrôlés par une Wiimote dans la scène. Le déplacement de la
caméra globale étant effectué à l’aide du joystick. Il faut noter que nous avons rencontré quelques
problèmes de latence lorsque l’on déplace la caméra à l’aide du joystick, dans ce cas, les mouvements
des acteurs Wiimote sont décalés dans le temps. La cause de ce problème n’est pas très claire mais
il semble que cela soit du à un problème au niveau du driver de la Wiimote, qui ne gère pas assez
rapidement les événements Bluetooth dès que nous l’intégrons dans Delta3D.
Fig. 11.1 – Démonstration dans la salle immersive
11.2
11.2.1
Bilan
Concernant notre architecture
Nous avons comparé l’architecture utilisée au CSTB avec la nôtre. Celle-ci peut être améliorée
par l’utilisation de callback et en évitant d’effectuer trop de tâches dans le « TickLocal » de chaque
acteur (tick d’horloge, message recu à intervalle régulier).
Il peut être également utile de gérer tous les événements de la Wiimote uniquement dans un
composant, même ceux liés au déplacement de l’acteur. Son déplacement s’effectuerait par l’envoi
de messages du genre « Deplace-toi » à l’acteur concerné.
11.2.2
Déplacement des acteurs
Nous avons remarqués que notre gestion des collisions au niveau de nos acteurs n’était pas
adaptée pour toutes les scènes. En effet, nos acteurs marche sur le plan horizontal situé le plus
bas dans la map. Si cela ne pose pas de problème quand on se déplace par exemple dans les rues
de Cannes, cela est gênant lorsqu’on veut se déplacer à l’intérieur des bâtiments du campus STIC,
nos acteurs restent en effet toujours à l’étage le plus bas. Ce comportement devra bien sur être
corrigé.
De plus, la prise en main est difficile si l’on se déplace en même temps que la caméra principale.
Enfin, la vue à la troisième personne a posée des soucis, lorsque l’on rentre dans un bâtiment : la
caméra reste en dehors (la distance par rapport à l’acteur est fixe)
Chapitre 12
Conclusion
Pour conclure, nous pouvons dire qu’en ce qui concerne l’implémentation, nous sommes arrivés
au but fixé, c’est-à-dire créer un module qui puisse être ajouté facilement dans une application au
CSTB. Et nous avons réussi à intégrer des périphériques « exotiques »dans Delta3D.
Cela n’a pas été réalisé sans mal. En effet, nous n’avions aucune expérience avec Delta3D avec ce
TER, et il a donc fallu apprendre à maîtriser cette API qui est loin d’être simple. On peut en effet
noter que Delta3D est peu documenté et que la communauté d’utilisateurs est assez restreinte, il
est donc difficile d’obtenir de l’aide lorsque l’on ne comprend pas quelque chose. La seule vraie
source d’informations est le forum officiel de Delta3D qui n’est pas si actif que ça. De plus les
tutoriaux disponibles sur le site de Delta3D sont buggés ou plus à jour depuis longtemps, ce qui
constitue un frein de plus à l’apprentissage de son utilisation.
De plus nous n’avons appris le travail exact que nous devions réaliser que morceau par morceau,
ce qui a compliqué notre implémentation. Le module que nous avons développé n’est d’ailleurs
pas vraiment dans l’esprit de Delta3D qui n’est normalement pas fait pour fonctionner selon ce
principe.
En revanche, une fois passé cet apprentissage difficile, Delta3d apparaît comme étant d’une
grande flexibilité, en particulier l’aspect transmission de messages est très important et simple à
utiliser. Plus globalement, il n’y a en fait jamais beaucoup de code à écrire pour réaliser des choses
assez complexes, le plus dur étant de savoir par où commencer.
Ce projet nous a en tout cas permis de découvrir des technologies que nous ne connaissions pas
du tout. Cela s’est avéré être très intéressant pour nous. Nous comptons d’ailleurs poursuivre ce
travail lors d’un stage durant le mois du Juin.
Les objectifs que nous nous sommes fixés pour cette suite sont détaillés dans le chapitre suivant.
30
Chapitre 13
Travaux à poursuivre
Nous allons encore travailler sur ce projet durant le mois de Juin, voici donc les suites envisagées.
13.1
Couche réseau
Intérêt Nous voulions avoir la possibilité d’utiliser des fonctionnalités réseau dans Delta3D, afin
de pouvoir développer un acteur complet sur un ordinateur portable, et brancher directement cette
machine sur le réseau du CSTB. Cela nous permettrait de n’avoir aucune installation à effectuer
sur la machine du CSTB, comme c’est le cas actuellement. Par exemple, quelqu’un vient avec son
portable sur lequel il a tous les drivers nécessaires pour un périphérique donné et un acteur qui
utilise ce périphérique, il pourrait se connecter via le réseau a une application qui tourne déjà
au CSTB et y faire rentrer son acteur à n’importe quel moment. De plus l’ordinateur portable
pourrait afficher une vue différente de celle projetée sur l’écran principal, par exemple avoir une
vue centrée sur son personnage au lieu de la vue globale.
Une couche réseau existe plus ou moins dans Delta3D mais cela n’est pas finalisé. Pour le
moment cela reste encore de très bas niveau, avec gestion de paquets de données à la main. La
prochaine version de Delta devrait apporter tout un ensemble de classes pour la gestion du réseau,
avec possibilité de création de « NetworkComponent ». Etant donné qu’on ne sait pas quand cette
version de Delta3D sortira, cette partie est suspendue pour le moment.
13.2
Centrale inertielle
Nous voulions également utiliser une centrale inertielle (InterSense InertiaCube3) comme périphérique d’entrée. Delta3D propose une classe « Tracker » pour cela. Nous avons écrit un fragment
de code pour faire un test simple, ce code est théoriquement valide, mais nous n’avons pas pu le
tester, suite à des problèmes avec l’alimentation électrique de la centrale.
13.3
Gestaction
Nous aimerions au final pouvoir intégrer toute sorte de périphériques dans l’architecture du
CSTB. En plus de la Wiimote et de la centrale inertielle, nous pourrions par exemple intégrer le
gant interactif développé dans le cadre du projet « Gestaction » de l’équipe Rainbow.
31
CHAPITRE 13. TRAVAUX À POURSUIVRE
32
13.4
Fonctionnalités supplémentaires
– Contrôle de différents MotionModel par une wiimote, pour suppléer le joystick encombrant
et unique
– Gérer le zoom dans la vue à la 3ème personne
– Rejoindre un acteur, se transférer dans une zone de rassemblement (entrée du campus, Resto
U ...)
– Vue à la 3eme personne : rapprochement automatique de la caméra si l’acteur est caché par
un obstacle (difficile !)
– ...
13.5
Site web : Retour d’utilisateurs
Une fois la réalisation du site terminée, nous devions réaliser une publicité de ce site auprès des
communautés de logiciels de création 3D. Cela aurait permis de recueillir des commentaires d’un
grand nombre d’utilisateurs et ainsi de voir quels produits ont de bonnes performances, et surtout
de juger du rapport qualité/prix de ces produits, ce qui est très important compte tenu des tarifs
auxquels sont vendus la plupart de ces périphériques. Cela n’a pas été fait dans la mesure ou Mme
Lingrand nous a demandé de nous consacrer à notre implémentation, qui est la partie principale
du TER. Le site est donc entièrement fonctionnel et est prêt à être utilisé le moment venu.
Bibliographie
Site officiel de Delta3D : http://www.delta3d.org/
Site officiel de OpenSceneGraph : http://www.openscenegraph.com/
Documentation de l’API de Delta3D : http://www.delta3d.org/api/index.html
Site de vente en ligne de périphériques 3D : http://www.inition.co.uk
Sites de constructeurs de périphériques 3D :
http://www.isense.com/
http://www.ascension-tech.com/
http://www.polhemus.com/
http://www.3dconnexion.com/
http://www.immersion.com/
http://www.forcedimension.com/
http://www.sensable.com/
http://www.sensics.com/
Et bien d’autres.
Philippe Fuchs : Le traité de la réalité virtuelle - 2eme édition
D’autres liens sont disponibles ici : http://thx009.free.fr/TER/liens.html
33