Embed Size (px)
Citation preview
Documentation
Technique
Documentation technique
- 2 -
Référence
Auteurs :
Matthieu Kermagoret
Céline Baraban
Dorian Guillois
Stéphane Lapie
Thomas Lecomte
Yoann Moizan
Monirath Pontiac
Alexis Rolland
Vincent Schoener
Table des mises à jour :
Version Date Chapitres modifiés Changements
V1.0 01/04/10 / Création
V1.1 17/06/10 / Modification ergonomiques
V1.2 19/06/10 3.3 Dépendance libusb / driver
Vuzix
Objet du document :
Ce document a pour but de décrire le projet Nysa pour un futur développeur.
Documentation technique
- 3 -
Sommaire
REFERENCE ...................................................................................................... - 2 -
SOMMAIRE ....................................................................................................... - 3 -
1. CONTEXTE DU PROJET ................................................................................... - 5 -
1.1 RAPPEL DU CONTEXTE GENERAL ............................................................................ - 5 - 1.1.1 OBJECTIFS DE L’EIP ............................................................................... - 5 - 1.1.2 ORGANISATION DU PROJET ........................................................................ - 6 -
1.2 LES OUTILS ..................................................................................................... - 6 - 1.2.1 SUBVERSION ........................................................................................ - 6 - 1.2.2 LE TRAC ............................................................................................. - 7 - 1.2.3 LE SERVEUR WEB .................................................................................. - 7 -
1.3 ENVIRONNEMENT DU PROJET ................................................................................ - 7 - 1.3.1 ENVIRONNEMENT DE REALISATION................................................................ - 7 - 1.3.2 ENVIRONNEMENT MATERIEL ....................................................................... - 8 - 1.3.3 CONTRAINTES SPECIFIQUES ....................................................................... - 9 -
2. PRESENTATION DU PROJET ........................................................................... - 10 -
2.1 PERIMETRE DU PROJET ..................................................................................... - 10 - 2.1.1 DOMAINE ........................................................................................... - 10 - 2.1.2 L’EXISTANT DU LE MARCHE ....................................................................... - 10 - 2.1.3 PRINCIPES DE BASE DU SYSTEME ................................................................ - 12 -
2.2 LES DIAGRAMMES ............................................................................................ - 13 - 2.2.1 COMMUNICATION EXTERNE ....................................................................... - 13 - 2.2.2 COMMUNICATION INTERNE ....................................................................... - 14 - 2.2.3 DIAGRAMME GLOBAL .............................................................................. - 15 - 2.2.4 DIAGRAMME UML SDK .......................................................................... - 16 - 2.2.5 DIAGRAMME UML FRAMEWORK ................................................................. - 17 -
2.3 LES BESOINS FONCTIONNELS .............................................................................. - 18 - 2.3.1 DRIVERS GANTS ................................................................................... - 18 - 2.3.2 DRIVERS LUNETTES ............................................................................... - 18 - 2.3.3 BIBLIOTHEQUE GRAPHIQUE ....................................................................... - 18 - 2.3.4 LE SDK ............................................................................................ - 19 - 2.3.5 UNE APPLICATION DEMONSTRATION ............................................................. - 19 - 2.3.6 UN GUIDE DE DEVELOPPEMENT ................................................................... - 19 -
3. INTEGRATION DES SOLUTIONS TIERCES ........................................................ - 20 -
3.1 SUBVERSION ................................................................................................. - 20 - 3.2 CMAKE ......................................................................................................... - 20 - 3.3 LIBUSB / DRIVER VUZIX .................................................................................. - 21 -
Documentation technique
- 4 -
3.4 MESA 3D ...................................................................................................... - 21 - 3.5 OGRE 3D ...................................................................................................... - 22 -
4. GANTT ........................................................................................................ - 22 -
GLOSSAIRE .................................................................................................... - 24 -
Documentation technique
- 5 -
1. Contexte du projet
1.1 Rappel du contexte général
1.1.1 Objectifs de l’EIP
L'Epitech Innovative Project (EIP), projet de fin d'études à l'EPITECH, a
pour objectif de faire passer les étudiants de la réalisation pédagogique à la
réalisation de projet concret et de grande envergure, comme ce que l'on trouve
en entreprise.
L'EIP se réalise sur 14 mois et par groupes de 5 à 12 personnes.
Il a pour vocation de faciliter l'entrée des étudiants dans le monde
professionnel.
Ce projet constitue une carte de visite, une expérience bénéfique pour
trouver un stage, un part-time job ou un emploi.
Un projet
L'EIP est la concrétisation des 5 ans d'études à l'EPITECH. Il se veut
professionnel et exploitable par une entreprise. Réalisé sur 14 mois, l'EIP offre
aux participants une opportunité de réaliser un projet de grande ampleur.
Un groupe
En moyenne les groupes d'EIP sont constitués de 7 à 8 membres. Il y a
deux raisons à la règle du minimum de 5 étudiants par projet :
- La première est pédagogique, un groupe relativement important doit se
gérer. Les étudiants pratiqueront donc la gestion de groupe.
- La seconde est pratique, le projet se déroule sur 14 mois, un groupe
relativement nombreux permet de palier à toutes sortes de problèmes
rencontrés : départ, maladie, manque de travail, prise de retard.
Documentation technique
- 6 -
Une image
L'EIP est aussi une image d'EPITECH apportée dans le monde de
l'entreprise. C'est une démonstration des capacités des étudiants ainsi qu'un
gage de la qualité de l'enseignement dispensé au sein de l'école.
1.1.2 Organisation du projet
Ce projet est réalisé par les personnes suivantes :
- Matthieu Kermagoret
- Thomas Lecomte
- Stéphane Lapie
- Monirath Pontiac
- Alexis Rolland
- Vincent Schoener
- Céline Baraban
- Yoann Moizan
- Dorian Guillois
Ce projet est dirigé par Matthieu Kermagoret.
1.2 Les outils
Pour pouvoir réaliser le projet le LabEIP met en place un certain nombre
d'outils pour tous les groupes :
1.2.1 Subversion
Subversion sert à gérer les sources du projet en centralisant les fichiers,
en les versionnant et les synchronisant sur l'ensemble des copies locales des
développeurs.
https://labeip.epitech.eu/svn/2011/nysa
Documentation technique
- 7 -
1.2.2 Le Trac
Afin de faciliter la gestion du projet, le Trac permet de :
- Avoir un wiki ;
- Affecter des tickets ;
- Avoir un suivi de l'avancement avec les roadmaps ;
- Visualiser les sources.
1.2.3 Le serveur WEB
Le serveur web permet de faire connaître notre projet en mettant en ligne
un site vitrine :
https://eip.epitech.eu/2011/nysa
1.3 Environnement du projet
1.3.1 Environnement de réalisation
L'équipe
L'équipe, composée de 9 personnes possède un vaste panel de
compétences telles que :
- le développement
- la modélisation
- le graphisme
- la documentation
- la communication
Cette complémentarité entre les membres de l'équipe nous permettra de
mener notre EIP jusqu'au bout !
La documentation issue du code
En supplément des différentes documentations existantes, des
documentations techniques seront extraites du code source C++, grâce
notamment aux commentaires présents dans les fichiers sources.
Documentation technique
- 8 -
Entre autre la documentation des fonctions, classes et méthodes sera
fournie et présentée sous une forme hiérarchique.
Nous utiliserons donc un logiciel nommé Doxygen afin d'extraire de
manière présentable les informations données par les développeurs.
1.3.2 Environnement Matériel
De part sa nature immersive, notre projet requiert une interface homme –
machine innovante.
Pour se faire nous allons utiliser des gants de données et des lunettes
stéréoscopiques afin de procurer la meilleure expérience utilisateur possible !
Les gants de données devront supporter 6 degrés de liberté et fournir des
informations via un capteur indépendant pour chacun des doigts. Ces
informations nous permettront de reproduire avec la plus grande précision les
mouvements des utilisateurs.
Notre attention a été retenue par les Accelegloves
http://www.cwonline.com/store/view_product.asp?Product=1179, des gants de
données relativement anciens mais ayant les avantages suivants :
- bon marché
- 6 degrés de liberté
- précision correcte
- spécifications techniques disponibles
- informations de courbure indépendantes pour chaque doigt
Les lunettes stéréoscopiques de par leur nature doivent posséder au moins
2 écrans indépendants (un pour chaque œil). Afin de garantir une qualité
graphique acceptable il semble judicieux de choisir une résolution par écran d'au
minimum 320x240. De plus les lunettes devront êtres capables de fournir les
informations de rotation de la tête sur les 3 axes (X, Y et Z).
Les lunettes Vuzix VR920 http://cgi.ebay.ca/VuZix-VR920-Icuiti-iWear-
Video-Gaming-3D-Eyewear-
NEW_W0QQitemZ290358905593QQcmdZViewItemQQptZLH_DefaultDomain_0?h
ash=item439abd4af9 respectent toutes ces conditions et plus encore :
- deux écrans de 640x480
- informations de rotations sur les trois axes
- bon marché
Ce matériel de haute technologie nous permettra de rendre la plus réaliste
possible l'immersion de l'utilisateur.
Documentation technique
- 9 -
1.3.3 Contraintes spécifiques
De part sa nature assimilable au domaine du jeux-vidéo notre EIP fait face
à la même contrainte principale : la performance. D'autant plus que
contrairement aux jeux-vidéo classiques notre projet devra gérer deux rendus
graphiques différents simultanément.
Ainsi lors de l'écriture du code, devront nous faire extrêmement attention
à l'optimisation de manière à ce que le projet puisse tourner sur des machines
actuelles sans aucun problème.
Étant donné que nous allons créer un framework de développement
destiné à des développeurs externes, nous devons prendre en compte
l'ergonomie de l'API que nous allons proposer afin que le développement soit le
plus naturel possible.
Documentation technique
- 10 -
2. Présentation du projet
2.1 Périmètre du projet
2.1.1 Domaine
Nysa se rapproche avant tout des frameworks de développement de jeux-
vidéo. Le projet rajoute cependant la gestion d'une interface homme-machine
innovante qui est le couple gants-lunettes.
Cependant afin de pouvoir gérer ce matériel il faudra au préalable faire de
la gestion bas niveau tel que le développement de drivers pour différentes
plateformes. Ceci est appelé la programmation système.
2.1.2 L’existant du le marché
Les solutions existantes sont peu nombreuses et représentent souvent
uniquement une solution d'une partie du problème qui permettrait d'avoir accès
à une immersion compatible avec la majorité des logiciels existants.
Lorsque des solutions complètes existent, elles sont bien souvent très
onéreuses et difficiles d'accès.
Parmi les fonctionnalités que l'on peut retrouver indépendamment :
les gants : constructeurs indépendants de chaque marque
5DT
Virtual Technologies
Essential Reality
...
les lunettes : constructeurs indépendants de chaque marque
Vuzix
Emagin
…
Le problème principalement rencontré avec des solutions séparées est que
pour fournir leur valeur ajoutée, ces solutions ont bien souvent besoin que les
logiciels existants et déclarés compatibles soient mis à jour, c'est à dire modifiés
Documentation technique
- 11 -
de manière souvent non officielles. Dans le cas contraire, la valeur ajoutée reste
minimale.
Parmi les fonctionnalités que l'on peut retrouver groupées :
3DVIA Virtools - Dassault Systèmes
Dont la solution n'est pas destinée au grand public
Nvidia 3D vision
Le problème de Nvidia est le fait qu'ils vendent une solution avec lunettes
+ Ecran + PC + Carte graphique qui vont ensemble ce qui devient vite onéreux
et contraignant
Microsoft Natal
Pour la Xbox360, rajouter un système dont le corps servira de contrôleur
de jeux.
Au niveau framework de développement, il existe énormément de
solutions pour créer des applications graphiques.
On pourra citer des exemples en logiciels libres :
- Ogre3D
- Irrlicht
- ...
Et en logiciel propriétaire :
- Source Engine
- Cry Engine
- Unreal Engine
- ...
Toutes ces solutions ont l'avantage de gérer toutes les créations de scènes
et problématiques générales du jeux-vidéo, mais aucune d'entre elles ne gèrent
les rendus stéréoscopiques ou les entrées des gants de données.
Pour le rendu graphique les bibliothèques principales qui gèrent l'OpenGL
sont :
- Mesa 3D (Open-source et software)
- ATI Catalyst (Propriétaire et hardware)
- drivers Nvidia (Propriétaire et hardware)
Documentation technique
- 12 -
Le problème ici est que les solutions qui pourraient permettre des rendus
stéréoscopiques sont principalement propriétaires (drivers ATI et Nvidia).
Mesa3D fournit certes une implémentation software d'OpenGL, mais les
performances en rendu stéréoscopique restent à démontrer.
2.1.3 Principes de base du système
Le but du projet est de mettre à la portée du plus grand nombre la réalité
virtuelle.
En effet, les jeux vidéos fournissent pour le moment tous les mêmes
interfaces homme-machine : clavier/souris ou manette toujours couplé à un
écran. De part sa nature l'écran est limité à 2 dimensions qui sont elles-mêmes
comprises dans des limites fixes.
Il y a bien quelques essais pour contourner ces limitations intrinsèques :
les rendus polarisés donnant une fausse impression de 3D en sont un exemple.
Malheureusement personne dans l'industrie ne semble vouloir mettre cette
révolution technologique que représente la réalité virtuelle à la portée de tous.
Nous nous proposons donc de fournir aux développeurs à l'imagination
débordante un moyen d'exprimer toute leur créativité.
Ils ne seront donc ainsi plus limités par des périphériques d'entrées/sorties
datant des années 60. Ils pourront tirer partie de ce qui est à l'heure actuelle à la
pointe de la technologie en matière de rendu intégral.
Bien sûr notre solution ne sera pas limitée aux seuls jeux-vidéos. Il sera
bien entendu possible, par exemple, de créer une interface de bureau totalement
novatrice ou encore des logiciels de visite d'appartement sur plan, les limites de
notre SDK ne seront posées que par les limites du génie humain.
Documentation technique
- 13 -
2.2 Les diagrammes
2.2.1 Communication externe
Documentation technique
- 14 -
2.2.2 Communication interne
Documentation technique
- 15 -
2.2.3 Diagramme global
Documentation technique
- 16 -
2.2.4 Diagramme UML SDK
Documentation technique
- 17 -
2.2.5 Diagramme UML Framework
Documentation technique
- 18 -
2.3 Les besoins fonctionnels
2.3.1 Drivers Gants
Les matériels proposés fonctionnent majoritairement sous Windows et
utilisent des drivers propriétaires. Afin de pouvoir atteindre notre but de portage
sur différentes plateformes nous allons donc être contraints de développer un
driver au moins pour un Unix. Les drivers Windows et Unix devront être
harmonisés afin de nous abstraire de la plateforme sur laquelle nous nous
trouvons dans le reste de nos développements.
Les données issues du driver gants ne sont pas directement exploitables, il
faut généralement les extrapoler à partir de valeurs moyennes. De plus il est
nécessaire de prévoir un mécanisme d'étalonnage des capteurs. Les informations
issues des capteurs devront également être traitées d'une manière la plus proche
possible du temps réel, et ce afin d'assurer une fluidité dans la gestion des
mouvements.
2.3.2 Drivers lunettes
Les matériels proposés fonctionnent majoritairement sous Windows et
utilisent des drivers propriétaires. Afin de pouvoir atteindre notre but de portage
sur différentes plateformes nous allons donc être contraints de développer un
driver au moins pour un Unix. Les drivers Windows et Unix devront être
harmonisés afin de nous abstraire de la plateforme sur laquelle nous nous
trouvons dans le reste de nos développements.
Les informations envoyées aux lunettes comprennent deux flux vidéos
distincts, il faudra donc porter une attention particulière au problème de bande
passante, afin d'éviter que le flux vidéo soit désynchronisé ou saccadé.
2.3.3 Bibliothèque graphique
La bibliothèque Mesa 3D fournit une implémentation libre d'OpenGL. Nous
comptons la modifier afin que n'importe quel rendu OpenGL standard génère
deux images stéréoscopiques. Il y a là un challenge afin de conserver des
performances correctes dans tous les cas d'utilisation.
Documentation technique
- 19 -
2.3.4 Le SDK
Afin d'éviter de réinventer la roue, nous comptons nous baser sur un
framework de développement déjà existant : Ogre 3D. Celui-ci fournira les
actions de base qu'attendent tous les développeurs d'applications graphiques et
nous rajouterons notre valeur ajoutée : la gestion du mouvement des mains (la
stéréoscopie étant gérée de manière transparente grâce à OpenGL).
Nous fournirons donc plusieurs niveaux d'API permettant de gérer de
manière plus ou moins précise ou plus ou moins rapide, les gants.
2.3.5 Une application démonstration
Dans le but de montrer le fonctionnement et la valeur ajoutée de notre
réalisation, nous comptons faire marcher une version modifiée d'une application
existante : Quake3 ou équivalent.
2.3.6 Un guide de développement
Dans le but de séduire nos futurs utilisateurs et de fédérer pourquoi pas
une communauté, nous élaborerons au moins un guide de développement, afin
d'aider les jeunes développeurs débutants, à la prise en main.
Documentation technique
- 20 -
3. Intégration des solutions tierces
3.1 Subversion
Site internet : http://subversion.tigris.org
Subversion (SVN) est un système de gestion de sources. Ce logiciel
permet de stocker plusieurs versions successives d'un même fichier source,
permettant ainsi de revenir à une version précédente à tous moment.
3.2 CMake
Site internet : http://www.cmake.org
Description
CMake est un outil de construction de projet automatisé multi-plateforme.
Avec un seul fichier de configuration, CMake peut générer les fichiers de
construction spécifiques a la plateforme sur laquelle celui-ci est exécuté. Ceci est
d'autant plus utile quand nous souhaitons porter un logiciel sur plusieurs types
de plateformes.
Utilisation dans Nysa
CMake dispose de son propre répertoire de 'construction' dans Nysa pour
ne pas mélanger à la fois les sources du projet et les fichiers automatiquement
générés par les scripts de construction. Le fichier principal de configuration est
appelé CMakeLists.txt . Ce fichier fait récursivement appel au fichier
CMakeLists.txt des pilotes, du framework et du SDK afin de construire l'ensemble
du projet. CMake est utilisé de manière standard pour la construction du SDK
(add_library et add_executable) et de façon plus spécifique avec le framework et
les pilotes.
Pour les pilotes, les sources du module Linux doivent être construites via
l'arbre de construction du noyau lui même. Le fichier CMakeLists.txt des drivers
appel donc les Makefiles des sous-répertoires des lunettes et des gants.
Documentation technique
- 21 -
Le framework quand à lui est basé sur Ogre3D et le fichier CMakeLists.txt
associé à celui-ci se charge donc d'exécuter les scripts de construction de Ogre.
Les scripts de Ogre utilisent les outils GNU autoconf et automake et se trouvent
dans le dossier framework/ois.
3.3 Libusb / Driver Vuzix
Site internet : http://www.libusb.org
http://www.vuzix.com
La bibliothèque libusb nous permet de communiquer de manière portable
sur différents Unix avec des périphériques USB. Nous utilisons cette bibliothèque
dans notre driver lunettes Unix. Sous Windows, la communication se fait
directement car des pilotes dédiés Vuzix sont disponibles.
3.4 Mesa 3D
Site internet : http://www.mesa3d.org
Image Stéréoscopique :
Pour obtenir un effet de relief nous devons générer une même scène à
partir deux points légèrement distants. Le résultat recherché est de projeter une
image à l'œil gauche ainsi que la même image sous une vue décalée à l'œil droit.
Mesa3D :
Mesa3D est une bibliothèque graphique libre qui fournit une
implémentation générique d'OpenGL. L'utilisation de Mesa3D nous permet de
réaliser nos rendus graphiques. L'intérêt d'utiliser Mesa3D est l'optimisation du
rendu exclusivement software ainsi que sa compatibilité avec toutes les plate-
formes modernes. Beaucoup de systèmes ne sont pas supportés par OpenGL
c'est alors que Mesa est utilisé.
Avantages de Mesa3D par rapport à OpenGL :
- Mesa est gratuit
- Mesa fonctionne sur de nombreuses plate-formes
- Calcul de rendu software
- Optimisations, modifications du code source de Mesa
- De nombreuses applications écrites pour OpenGL peuvent utiliser Mesa3D
sans modification du code source
Documentation technique
- 22 -
Notre objectif est de fournir aux lunettes un couple d'images pratiquement
identiques générées par Mesa3D pour réaliser notre impression de relief et de
profondeur.
3.5 Ogre 3D
Site internet : http://www.ogre3d.org
http://www.ogre3d.org/wiki/index.php/OIS
OGRE (Object-Oriented Graphics Rendering Engine) est un moteur de
rendu 3D orienté mise en scène et flexibilité. OGRE est écrit avec le langage C++
pour apporter une manière plus intuitive et plus simple de développer des
applications tirant parti de l'accélération 3D.
La bibliothèque de classes permet de s'abstraire de toutes les couches
système des bibliothèques Direct3D et OpenGL et fournit une interface objet
avec beaucoup de classes intuitives.
Notre but est de fournir un support des lunettes 3D et des gants aussi
simple que celui du clavier ou de la souris dans OGRE.
Le système de gestion des périphériques de OGRE se nomme OIS (Object
Oriented Input System), c'est une bibliothèque qui permet d'utiliser le clavier, la
souris et le joystick. Il nous est maintenant possible d'utiliser nos périphériques
dans OGRE à travers OIS comme n'importe quel autre matériel.
Les gants et les lunettes 3D sont des classes dérivées de l'interface de
gestion des périphériques de OIS, ces classes utilisent aussi le système
d'événements de OIS à travers des événements spécifiques à chaque
périphérique.
Pour bien comprendre comment utiliser les gants de donné et les lunettes
3D il vous faut vous familiariser avec OIS :
http://www.ogre3d.org/wiki/index.php/Using_OIS
4. Gantt
Documentation technique
- 23 -
Documentation technique
- 24 -
Glossaire
API
Une API (Application Programmable Interface, traduisez « interface de
programmation » ou « interface pour l’accès programmé aux applications ») est
un ensemble de fonctions permettant d’accéder aux services d’une application,
par l’intermédiaire d’un langage de programmation.
Degré de liberté
En mécanique, un degré de liberté est une possibilité de mouvement. En
3D, il en existe 6 : les rotations suivant les 3 axes et les translations suivant les
3 axes.
Driver
Pour pouvoir fonctionner, n'importe quel matériel nécessite une couche
logicielle qui comprend comment il marche. Cette couche logicielle est
génériquement appelée driver.
Gants de données
Gants possédant des capteurs permettant de modéliser sur machine la
position exacte dans l'espace des mains, doigts inclus.
Mailing-list
Une liste de diffusion (en anglais mailing-list) est un des services les plus
couramment utilisés sur internet, permettant à un expéditeur d'envoyer un
message à un ou plusieurs destinataires via une seule adresse. Le courrier
électronique a été inventé par Ray Tomlinson en 1972.
OpenGL
OpenGL est une API permettant de créer des images 3D (et 2D). Le but
est d'uniformiser sur toutes les plateformes l'API graphique. Les rendus OpenGL
peuvent être accélérés (hardware) ou non (software).
Stéréoscopie
La stéréoscopie est une technique mise en œuvre afin de percevoir une
sensation de relief à partir de deux images planes (une pour chaque œil). Elle se
base sur la perception du cerveau qui restitue une seule image en 3D à partir des
informations fournies par chaque œil.
