Block3D

Block3D

31 mai 2012

La réalité virtuelleau département informatiqueEtudiants

Edgar-Fernando Arriaga-Garcia

Charles-Henri Babiaud

Clément Grellier

Quentin Petit

Jérôme Ricœur

Florent Violleau

Encadrants

Ronan Gaugne

Valérie Gouranton

2

Introduction

2

3

Plan

1. Rappels du contexte : µRV

2. Fonctionnalités de Block3D

3. Architecture logicielle et physique

4. Conception et développement

5. Démonstration de Block3D

3

6. Bilan du projet de réalité virtuelle

7. Planification

4

Plan






4


7. Planification

5

1. Rappel du contexte - Problématique et but

Portes ouvertes

Vitrine technologique du département informatique

Administration de la salle µRV• Mise en place de la salle• Gestion de l’accès à la salle

Intégration d’autres projets• 1 projet de 3INFO• 3 projets de 5INFO

Application ludique de réalité virtuelle à partir du projet L3G0Déploiement dans la salle Immersia

1. Rappel du contexte - Matériel

Équipement de visualisation 3D :

• Un moniteur 3D• Un vidéoprojecteur 3D• Deux paires de lunettes Nvidia 3D• Une paire de lunettes Vuzix Wrap 920

6

Équipement d’interaction :

• Une Kinect• Deux Wiimotes avec Nunchuk• Un joystick à retour de force

7

Périphériques

Visualisation :• Lunettes 3D Nvidia

• Vidéoprojecteur

Interaction : • Kinect

Actions

Se déplacer

Pivoter la caméra

1. Rappel du contexte – Le coureur

1. Rappel du contexte – Le constructeur

8

Périphériques

Visualisation• Lunettes Vuzix

Interaction• Wiimote

Actions

Déplacer la caméra

Poser pièces

9

1. Rappel du contexte – Collaboration

9

Collaboration avec les autres groupesUn groupe de 3ème année, Daedalus :

• Application de génération de labyrinthe

Un groupe de 4ème année, Linnova :• Stockage de leur matériel dans la salle µRV

Un groupe de 5ème année :• Application distribuée à l’aide d’OpenMASK

D’autres groupes de 5ème année• Utilisation temporaire de la salle

10

Aperçu du labyrinthe

Paramètres de configuration

Sauvegarde du fichier XML

Daedalus, génération de labyrinthes

11

Plan1. Rappels du contexte : µRV





11


7. Planification

12

2. Fonctionnalités – Interactions (1/3)

12

Avancer

Reculer

Tourner à gauche

Tourner à droite

Translater à gauche

Translater à droite

Sauter

Accéder au menu

Fonctionnalités du coureur

13


13

Dézoomer

Translater la vue

Orienter la vue

Ajouter une pièce

Changer la pièce courante

Accéder au menu

Fonctionnalités du constructeur

14


14

Reprendre la partie

Choisir le labyrinthe

Choisir les paramètres sonores

Afficher l’aide

Quitter le jeu

Fonctionnalités du menu

15

2. Fonctionnalités – Mode distribué (1/2)

15

Communication distante

16

2. Fonctionnalités – Mode distribué (2/2)

16


3D Labyrinthe Décors Déplacement du coureur/constructeur

Menus Collisions Wiimote Interactions coureur/constructeur

17






17


7. Planification

1818

OpenMask Ogre3D OpenA

L

OgreAL PhysX NxOgre

Critter

3. Architecture logicielle – Vue générale

19

3. Architecture logicielle – Ogre

19

Moteur 3DCommunauté active

Licence libre (MIT)

Multiplateforme

C++

20

3. Architecture logicielle – Son spatialisé (1/4)

20

• Utilisation d’OpenAL :• Bibliothèque qui permet la manipulation de

tampons sonores à bas niveau• Adapté à de très nombreuses utilisations

• Utilisation d’OgreAL• Wrappeur d’OpenAL pour Ogre3D• Simplification dans le positionnement des

sources sonores dans le monde symbolique• Intégration aisée avec les objets de Ogre3D

• Utilisation des enceintes 5.1 dans le cadre de l’application

Architecture sonore

21


21

Permettre l’immersion dans le monde symbolique du coureur

Guider le coureur jusqu’à son objectif

22


22

Sonar

Pose des briques

Coureur

• Guider le coureur par l’utilisation d’un sonar• Informer le coureur et le constructeur

qu’une brique a été posée

23


23

• Variation de la fréquence et du tempo du son :• Du sonar• De la musique d’ambiance

0 25 500

5

10

15

20

25

30

Distance par rapport à l’objectif

Fréq

uenc

e (k

Hz)Plus aigu

Plus rapide

Plus graveMoins rapide

Arrivée Départ

24

3. Architecture logicielle – Modélisation du coureur

24

• Démarche d’utilisation de Blender :• Importation d’un personnage Lego• Correction des défauts (faces transparentes,

…)• Modification du squelette• Création des animations• Exportation en .mesh pour être utilisé dans

Ogre

• Exportation des animations pour Ogre peu intuitive

• Relativement peu de documentation

2525

3. Architecture logicielle – PhysX

Empêcher le coureurde traverser les murs

Caractéristiques• C++

• Licence commerciale• Multiplateforme• Développement actif• Utilisé dans la plupart des jeux

actuels • Bien documenté• Contrôleurs d’avatar• Corps rigides et souples • Champs de force, etc.

26

•NxOgre = Wrappeur •Critter = Interface et

26

Licence LGPL

C++

Développement actif

Tutoriels

Visual débogueur intégré

3. Architecture logicielle – PhysX et Critter (1/2)

27

Fonctionnalités supplémentaires

27

Débogueur visuel

3. Architecture logicielle – PhysX et Critter (2/2)

28

3. Architecture logicielle – Gestion de projet

28

Site web collaboratif : Media Wiki

• http://micro-rv.insa-rennes.fr

Redmine : forge de l’INSA

• gestionnaire de version : Subversion intégré• hébergement de la documentation : wiki intégré• discussion par sujets sur des erreurs : forum intégré

Communication

• IRC (Internet Relay Chat)

http://micro-rv.insa-rennes.fr/

29

OgreAL et OpenAL

VRPNOpenMA

SK OgreCppUnit et CxxTest

NxOgre et Critter

29

Gestion des dépendances logicielles

• Génération Makefile

• Génération projet VisualStudio

• Multiplateforme

• Indique les dépendances manquantes

3. Architecture logicielle – Cmake

30

Bilan prévu / réel

30

FAAST

NxOgre et CritterVRPN

OpenMASK

OgreAL

Ogre

CppUnit

CEGUI

Cmake

Ogre Bites

3131

5INFO

MPI

TCP IP


OpenMASK

Participation des 5INFO

Coureur

3. Architecture physique– Généralités

Même arborescence de fichiers sur les pc

Copie locale du monde virtuel

Copie locale du monde virtuel

32

Virtual Reality Peripheral NetworkInterfaçage avec les périphériques

• Un serveurAssocié à une IP et un port

• N clientsSur une machine ou plusieurs machines

32

3. Architecture physique– VRPN (1/2)

Serveur

Clients

33

•Bouton : Envoi pour chaque pression/relâchement▫Clavier, clic, bouton

•Analogique : Envoi continu de l’état▫Joystick

•Tracker : Suivi d’une position▫Casque

33

3. Architecture physique– VRPN (2/2)

Bouton

AnalogiqueTracker

Événements récupérés

VRPN

34

• Intégration d’un serveur VRPN Wiimote existant

• Création d’un client VRPN

• Interfaçage avec Block3D▫ Boutons pressés (Bouton)▫ Boutons relâchés (Bouton)▫ Mouvement du joystick (Analogique)▫ Accélération de la Wiimote (Analogique)▫ Accélération des Nunchuk (Analogique)

34

Wiimote - Nunchuk

3. Architecture physique– Wiimote

35

1. La Wiimote est connectée (Bluetooth)

2. Le serveur Wiimote est lancé

3. Block3D récupère les informations du serveur

4. Les événements sont filtrés par un écouteur « WiimoteListener »

35

Serveur

Wiimote

ClientBlock 3

D

Interfaçage

3. Architecture physique– Intégration de la Wiimote

36

FAAST, serveur et client VRPN

36

3. Architecture physique– Contrôle de la Kinect (1/2)

37

FAAST, serveur et client VRPN• Intégration transparente de FAAST dans Block3D

▫ transforme des événements Kinect en événements claviers

37

Kinect

FAAST Block3D

3. Architecture physique– Contrôle de la Kinect (2/2)

38

Plan






38


7. Planification

3939

ogre interactions

kinect

wiimote

modelparsertimedataeleme

ntsound

openmaskblock3D

plugin

4. Conception et développement – Diagramme de Paquetages

4040

• CppUnit• CxxTest

Tests unitaires

Tests utilisateur

s

• Facilité à trouver des bêta testeurs

4. Conception et développement – Tests

41






41


7. Planification

42

5. Démonstration

42

Arriverez-vous à l’objectif avant que le temps soit fini ?

Constructeur

Coureur

43






43


7. Planification

44

6. Bilan - Matériel

•Vuzix•Wiimote et nunchuck•Changement de salle•2 adaptateurs VGA sur un même

ordinateur

44

45

•Synchronisation Ogre – NxOgre

45

6. Bilan – Difficultés de synchronisation

4646


•Difficultés de prise en main d’OpenMASK▫Documentation et communauté restreintes▫Sessions d’entrainement à l’ETI▫Connexion MPI en réseau

•Adaptation du travail des 5ème année▫Fonctionnalités aussi restreintes

•Contraintes sur la reprise du code▫Création de plugins OpenMASK nécessaires

6. Bilan – Difficultés du mode distribué

47

•Evolutions d’intégration▫Amélioration du support Linux▫Amélioration application distribuée

•Evolutions des interactions▫Intégration du joystick▫Gérer le saut de l’avatar▫L’avatar suit les mouvements de

l’utilisateur▫Jeu plateforme

47

6. Bilan – Possibilités d’évolution

48






48


7. Planification

49

7. Planification – Jalons réels et prévisionnels

49

Conception

Implémentation

Livraison

Livraison rapport planification10/02/201210/02/2012

Interactions utilisateur/matériel24/02/201201/04/2012

Immersion dans un monde en 3D16/03/201201/04/2012

Applications constructeur/coureur27/04/201228/05/2012

Livraison projet31/05/2012

Livraison rapport final30/05/2012

Présentation finale31/05/2012

Planification initialePlanification réelle

Intégration OpenMask31/05/2012

• En 4 mois ce sont 1 mois de retard qui ce sont accumulés

50

7. Planification – Nombre d’heures

50

Analys

e

Spéc

ificatio

n

Conce

ption

Modèle

Matéri

el

Gestio

n Grap

hique

Intég

ration

s de p

rojet

s

Admini

strati

on

Livrai

son

0

100

200

300

400

500

600

700

311

622

75

250

80160

11060 90

311

622

120

300250 250

30 20

176

Prévisionnel Réel

Réalisé 2079h

Prévu 1759h

Cha

rge

(h)

51

7. Planification – indicateurs et causes

51

Retard

•C’est une charge réelle totale de 2079h, alors que la charge prévisionnelle était de 1768h•Ce n’est qu’une V4 qui est livrée et non une V5

Causes

•Difficultés d’implémentation (distribué, NxOgre,…)•Départ d’un membre du groupe•Difficultés de gestion de la salle•Gestion du matériel

52

7. Planification – gestion de projet

52

Organisation de l’équipe

• Formation de 3 équipes : constructeur, coureur et matériel

Avancement itératif

• Etablissement de jalons, et livraison d’une application à chaque jalon

Méthode de gestion de projet

• Méthode de gestion de projet SCRUM, avec réunions régulières.

53

Conclusion

53

Un projet complet•Périphériques•Wiimote, Kinect

•Technologies•Ogre, PhysX, OpenAL

Objectifs atteints• Applicat

ion interactive• Coure

ur/Constructeur

• Application distribuée

Un projet passionnant• Découver

te de la réalité virtuelle

• Sujet très intéressant

Block3D

Documents

Block3D