B.Sc Thesis: Moteur 3D en XNA pour un simulateur de vol

Moteur 3D en XNA pour un simulateur de vol
Atachiants Roman Haute Ecole Rennequin Sualem page 1
MOTEUR 3D EN XNA POUR UN
SIMULATEUR DE VOL
Atachiants Roman
Année académique : 2006-2007
Travail de Fin d’Études en vue de l’obtention du grade
de Bachelier en Informatique de Gestion

SOMMAIRE
1. Remerciements............................................................................................................................... 5
2. Introduction.................................................................................................................................... 6
2.1 Architecture du document..................................................................................................... 6
2.2 Choix du stage........................................................................................................................ 6
3. Contexte général ............................................................................................................................ 7
3.1 L’entreprise............................................................................................................................ 7
3.2 Les objectifs de travail ........................................................................................................... 9
3.2.1 Objectifs généraux............................................................................................................. 9
3.2.2 Objectifs à court terme...................................................................................................... 9
3.2.3 Objectifs à long terme ..................................................................................................... 10
3.3 L’environnement technique et les outils............................................................................. 12
3.3.1 Environnement de travail : L’équipe ............................................................................... 12
3.3.2 Outils et librairies utilisés ................................................................................................ 13
3.3.3 Standards de codage ....................................................................................................... 15
4. Considérations théoriques, études préalables............................................................................. 16
4.1 Développement d’une application orientée objet .............................................................. 16
4.1.1 Expérience personnelle ................................................................................................... 16
4.1.2 Analyse et conception d’une architecture repondant aux besoins................................. 17
4.1.3 Implémentation & sécurité ............................................................................................. 17
4.1.4 Optimisation.................................................................................................................... 17
4.1.5 Tests & débogage ............................................................................................................ 18
4.2 Au plan logiciel..................................................................................................................... 19
4.2.1 Choix de l’application ...................................................................................................... 19
4.2.2 OpenGL ou DirectX ?........................................................................................................ 19
4.2.3 Choix de Framework........................................................................................................ 20
4.3 Au plan matériel................................................................................................................... 22
4.3.1 Unité de calcul et mémoire ............................................................................................. 22
4.3.2 Choix de carte graphique................................................................................................. 22
5. Framework XNA............................................................................................................................ 24
5.1 Introduction ......................................................................................................................... 24
5.1.1 Généralités....................................................................................................................... 24
5.1.2 Prérequis.......................................................................................................................... 24
5.2 Architecture ......................................................................................................................... 26
5.2.1 Généralités....................................................................................................................... 26
5.2.2 La couche plate-forme..................................................................................................... 27
5.2.3 La couche framework de base......................................................................................... 27
5.2.4 La couche framework étendu.......................................................................................... 29
6. Notions de 3D............................................................................................................................... 30
6.1 Introduction ......................................................................................................................... 30

6.2 Repères 3D........................................................................................................................... 30
6.3 Un vertex, des vertices......................................................................................................... 31
6.4 Les meshes........................................................................................................................... 35
6.5 Déplacement 3D : les matrices ............................................................................................ 35
7. Notions d’aviation ........................................................................................................................ 38
7.1 Introduction ......................................................................................................................... 38
7.2 Rotations.............................................................................................................................. 39
Rotations....................................................................................................................................... 39
Le rotor ......................................................................................................................................... 40
8. Le projet........................................................................................................................................ 42
8.1 vision du produit fini............................................................................................................ 42
8.2 Objet principal...................................................................................................................... 45
8.3 Objets secondaires............................................................................................................... 46
8.4 Interfaces utilisateur............................................................................................................ 47
8.5 En conclusion ....................................................................................................................... 47
9. L’architecture globale de l’application ......................................................................................... 49
9.1 L’architecture modulaire de l’application............................................................................ 49
9.1.1 Simulation........................................................................................................................ 50
9.1.2 Affichage.......................................................................................................................... 52
9.1.3 Entrées............................................................................................................................. 53
9.2 L’architecture en couches de l’application.......................................................................... 54
9.2.1 Couche native.................................................................................................................. 55
9.2.2 Couche managée ............................................................................................................. 55
9.2.3 Couche abstraite.............................................................................................................. 56
9.2.4 Couche spécifique à l’application.................................................................................... 56
10. Simulation..................................................................................................................................... 58
10.1 Introduction ......................................................................................................................... 58
10.2 Wrapper pour MOSCA ......................................................................................................... 59
11. Moteur de rendu graphique......................................................................................................... 64
11.1 Framework objets................................................................................................................ 64
11.1.1 Pourquoi un framework d’objets ? ............................................................................. 64
11.1.2 L’objet de base ............................................................................................................ 66
11.1.3 Les interfaces............................................................................................................... 67
11.1.4 L’utilisation.................................................................................................................. 68
11.2 Caméra................................................................................................................................. 69
11.2.1 Introduction ................................................................................................................ 69
11.2.2 Notions d’une caméra................................................................................................. 69
11.2.3 Méthodes principales.................................................................................................. 72
11.2.4 Déplacement............................................................................................................... 73
11.3 Octree d’optimisation de rendu .......................................................................................... 75
11.3.1 Définition..................................................................................................................... 75
11.3.2 View Frustum .............................................................................................................. 75
11.3.3 Représentation graphique .......................................................................................... 76
11.3.4 Implémentation........................................................................................................... 77
11.3.5 Annexe......................................................................................................................... 80
11.4 Zones d’affichage................................................................................................................. 81
11.4.1 Généralités .................................................................................................................. 81

11.4.2 Résultat final ............................................................................................................... 82
11.4.3 Exemple d’utilisation « pas à pas » ............................................................................. 84
11.4.4 Interaction entre le rendu et le framework objets ..................................................... 88
11.4.5 l’architecture Direct 3D............................................................................................... 89
11.4.6 L’architecture .............................................................................................................. 92
11.4.7 L’implémentation........................................................................................................ 98
11.5 Shaders et le post-processing............................................................................................ 103
11.5.1 Introduction .............................................................................................................. 103
11.5.2 HLSL........................................................................................................................... 105
11.5.3 Shader-model Framework......................................................................................... 107
11.6 Graphe de scène ................................................................................................................ 110
11.6.1 Généralités ................................................................................................................ 110
11.6.2 Utilité......................................................................................................................... 111
11.6.3 Implémentation......................................................................................................... 112
12. Perspectives et conclusions........................................................................................................ 113
12.1 Perspectives et développements ultérieurs ...................................................................... 113
12.2 Conclusions personnelles................................................................................................... 114
13. Bibliographie............................................................................................................................... 115
14. Lexique........................................................................................................................................ 116

1. REMERCIEMENTS
De nombreuses personnes ont apporté leur aide et leur soutien pendant tout le projet. Aussi, je
tiens à remercier tout particulièrement les personnes suivantes :
Monsieur Quentin Charlier qui fut un inoubliable coéquipier.
Monsieur Emmanuel Previnaire, Fondateur et administrateur délégué de Flying-Cam, pour avoir
permis, soutenu la réalisation de ce stage et également pour les idées novatrices apportées à ce
projet.
Monsieur Marco La Civita pour ses conseils tout au long du développement.
Monsieur Bernard Tollet pour ses conseils et son suivi pendant le travail de fin d’études.
Monsieur Jan Sperling, Directeur Technique, pour les explications sur l’hélicoptère.
Madame Sarah Krins, Executive Assistant Manager, pour l’aide apportée à la rédaction de ce
document et ses conseils sur l’activité de Flying-Cam.
Monsieur Christophe Schaaf, Office Manager pour son implication dans le développement du
moteur 3D en tant que personne de contact officielle.

2. INTRODUCTION
2.1 ARCHITECTURE DU DOCUMENT
Ce document a été écrit, en partie, à deux. Il contient donc deux types de chapitres :
Les chapitres écrits en commun qui sont d’ordre général. Par exemple, ce chapitre-ci ou le chapitre 3
« Contexte général » à la page 7.
Les chapitres écrits seul sont ceux où nous avons le plus travaillé par rapport au deuxième étudiant.
Ces deux types de chapitres sont reconnaissables par leurs icones : [ ] pour la partie
commune et [ ] pour la partie personnelle. Si l’icône se situe en dessous du titre principal
du chapitre, cela signifie que tout le chapitre est commun ou personnel.
Nous vous renverrons vers le deuxième document lorsque nous introduirons un concept développé
plus en détail dans le deuxième document.
2.2 CHOIX DU STAGE
Pendant tout mon cycle d’études, j’ai été confronté à de nombreux défis : que cela soit dans le
domaine de l’informatique, de la culture ou le simple fait de réussir un examen et être capable
d’assimiler une quantité importante de matière.
Mon but premier dans le choix du stage était de choisir un domaine qui me plaisait : travailler dans
un domaine et avec une technologie moderne.
Mon second souhait dans le choix du stage était d’apprendre de nouvelles technologies et m’enrichir
intellectuellement pendant ce stage.
Etant quelqu’un de passionné par les jeux vidéo, les domaines multimédia et cinématographique ; j’ai
été directement séduit par la société Flying-Cam et le projet de création d’un moteur 3D. Le fait
d’apprendre la programmation 3D m’a vraiment plu car c’était quelque chose que je souhaitais
apprendre depuis plusieurs années.

3. CONTEXTE GÉNÉRAL
3.1 L’ENTREPRISE
La société Flying-Cam, créée à Liège, en 1988, propose des services professionnels de prise de vues
aériennes par hélicoptère sans pilote. Elle fut la première société au monde à proposer ce service. La
société a réalisé des projets dans plus de 50 pays à ce jour et pour plus de 800 clients.
Figure 1 - Un hélicoptère Flying-Cam
Depuis sa création à Liège, la société a créé deux filiales, la première à Santa-Monica aux Etats-Unis
en 1994 et la seconde à Hong-Kong créée en 2005.
La société Flying-Cam maîtrise la conception et la fabrication de ses propres hélicoptères et du
système gyrostabilisé de prise de vues. Elle travaille donc aussi bien du coté matériel que logiciel. Le
système Flying-Cam a démontré une fiabilité irréprochable grâce au respect de normes
aéronautiques dans la conception et la fabrication.
La société développe pour le moment le 3ième
prototype de ses hélicoptères et réalise ainsi la
transition vers l’industrialisation ainsi que le passage du pilotage manuel au pilotage automatique. Ce
projet appelé « Flying-Cam III Diamant » sera un hélicoptère autonome, taillé sur mesure pour le plus
grand nombre d’applications possibles dans le marché des UAVs (Unmanned Air Vehicles) à voilure
tournante. Le concept fait appel à des avancées dans trois technologies : la visionique, l’aéronautique
et l’aérobotique.
En plus du marché du cinéma et de l’audiovisuel, Flying-Cam vendra, sous licence, un système
complet dénommé SARAH (Special Aerial Response Autonomous Helicopter). L’actuelle Flying-Cam II
et la future Flying-Cam III Diamant seront les plates-formes porteuses du système. Ce
développement fera évoluer la société Flying-Cam de l’activité de prestation de services vers la
licence de systèmes fabriqués sur mesure pour les besoins des clients les plus variés.
Il permettra aussi la pénétration de nouveaux marchés comme la sécurité, la protection civile, le
militaire, et les productions télévisées d’événements.
La société Flying-Cam travaille également pour des annonceurs publicitaires, des séries télévisées,
des événements sportifs, des bureaux de tourisme, des universités ou encore des parcs d’attractions.

En outre, Flying-Cam participe à des programmes d’intérêt civil comme ceux de la NASA.

3.2 LES OBJECTIFS DE TRAVAIL
3.2.1 OBJECTIFS GÉNÉRAUX
L’objectif du travail est la conception d’un moteur 3D. Ce travail s’exécute dans le cadre du projet
« Flying-Cam III Diamant » et permettra à long terme d’améliorer, entre autres, la communication
avec les clients.
Plus précisément, l’objectif est de créer une application graphique 3D qui interagira avec un
simulateur de vol, fournit par la société sous forme de librairie dynamique (DLL).
Figure 2 - Photo prise lors du film "Curse of the Golden Flower"
3.2.2 OBJECTIFS À COURT TERME
A court terme, l’objectif de ce travail est de créer un moteur 3D. La société Flying-Cam souhaite que
le moteur 3D dispose de:
• La possibilité de contrôler l’hélicoptère Flying-Cam avec les radios utilisées réellement ;
• La possibilité d’avoir plusieurs vues : vue de l’hélicoptère, vue de la caméra, vue fixe, … ;
• Hélicoptère animé ;
• Décors ;
• Une interface graphique simple et claire ;

Le simulateur pourra servir d’entraînement pour les futurs pilotes. Comme dit dans le chapitre 3.1 ci-
dessus, le projet Flying-Cam III Diamant permettra à n’importe qui de piloter un hélicoptère Flying-
Cam. Cependant, tout n’est pas si simple, même avec un pilote automatique, il faut savoir comment
donner de l’altitude ou réaliser un virage avec l’hélicoptère : le simulateur permettra donc à ces
utilisateurs de s’entraîner au préalable dans un environnement virtuel sans risque.
3.2.3 OBJECTIFS À LONG TERME
A long terme, le simulateur pourrait être transformé et utilisé dans plusieurs domaines. Par exemple,
dans le cadre du tournage d’un film, un réalisateur crée un story-board pour montrer au pilote ce
qu’il attend comme plan. Souvent, le problème est que le réalisateur ne pense pas à certaines
contraintes comme la vitesse. Sachant que l’hélicoptère Flying-Cam vole à une vitesse maximale de
120 Km/h, certains plans ne peuvent pas être réalisés, surtout si des virages doivent être exécutés.
Avec le simulateur, le réalisateur verra ce qu’il est possible de faire.
Un autre exemple de développement à long terme serait de permettre de réaliser à l’écran un plan
de vol avec un modèle 3D du lieu à filmer en capturant les coordonnées des endroits où l’hélicoptère
doit passer, en sauvegardant ces coordonnées, en envoyant ensuite ces coordonnées (et d’autres
informations nécessaires à ce plan de vol, comme la vitesse ou les commandes à réaliser) au vrai
hélicoptère afin de permettre à l’hélicoptère de réaliser cette trajectoire sans l’aide d’un pilote.
Evidemment, cet objectif est à très long terme et demandera beaucoup de travail et de temps.
De notre coté, pour le temps donné, nous nous sommes fixés comme objectif de créer un moteur 3D
avec les fonctions demandées comme le changement de caméra.
Ci-dessous, un exemple de story-board utilisé pour représenter une scène réalisée à l’aide de la
Flying-Cam dans le cadre du film « Mission : Impossible 2 » :

Figure 3 - Story-board pour le film Mission Impossible 2

3.3 L’ENVIRONNEMENT TECHNIQUE ET LES OUTILS
3.3.1 ENVIRONNEMENT DE TRAVAIL : L’ÉQUIPE
L’équipe de Flying-Cam est assez petite, mais en même temps fortement motivée et déterminée.
Les personnes constituant l’équipe :
Emmanuel Prévinaire: Fondateur de la société et administrateur délégué
Sarah Krins : Executive Assistant Manager
Marco La Civita: Responsable Innovation Technologie
Jan Sperling : Directeur Technique
Alexandre Philippart de Foy : Technicien de Maintenance
Nicolas Wetzels: Apprenti
Pierre Steenput: Apprenti
Christophe Schaaf: Office Manager EU
Marc Asmode: Operations Manager US
Angel Kwok Wing Yee : Office Manager Asia

3.3.2 OUTILS ET LIBRAIRIES UTILISÉS
Nom du logiciel/SDK Description et justification du choix
Microsoft Visual Studio 2005
Microsoft Visual Studio est un environnement de
développement intégré permettant d’écrire/compiler du
code .Net (C # dans notre cas). Cet outil est de loin le plus
populaire et le plus permissif et extensible parmi des
outils similaires.
XNA Game Studio Express
Microsoft XNA est une série d'outils fournis gratuitement
par Microsoft qui facilitent les développements de jeux
pour les plates-formes Windows et Xbox 360 en
réunissant un maximum d'outils en provenance de
Microsoft et de ses partenaires (DirectX, Visual Studio,
PIX, XACT).
Voir § 4.2.2 ci-dessouspour plus d’informations concernant
notre choix.
Nvidia SDK
Nvidia SDK (Software Developement Kit) est une série
d’outils fournis gratuitement par Nvidia qui contiennent
de la documentation, des exemples et des divers logiciels
facilitant le développement 3D pour les cartes graphiques
Nvidia, ainsi les exploitant au maximum.
Voir § 4.3.2 ci-dessouspour plus d’informations concernant
notre choix.
DirectX 9 SDK
Microsoft DirectX est une suite d’APIs multimédia
intégrées au système d'exploitation Windows permettant
d'exploiter les capacités matérielles d'un ordinateur.
Voir § 4.2.2 ci-dessous pour plus d’informations concernant
notre choix.
Okino PolyTrans
Okino PolyTrans est un logiciel de conversion des divers
formats des modèles/scènes/animations 3D, ce logiciel a
été choisi parmi d’autres à cause de sa puissance de
conversion et support de multiples formats
d’import/export.
Google SketchUp est un logiciel de modélisation 3d, à la
base utilisé pour Google Earth. Nous avons choisi ce
produit pour sa facilité et pour son gain de productivité.

Google SketchUp 6 Pro
Autodesk 3D studio Max 9.0
3D Studio Max est un logiciel de modélisation et
d'animation 3D sous licence propriétaire payante,
développé par la société Autodesk. Il est l'un des logiciels
de référence dans le domaine de l'infographie 3D. Ce
logiciel a été retenu dans le projet pour sa puissance et
support des animations intégrées.
Autodesk Inventor 11
Autodesk Inventor est un logiciel de modélisation 3D
développé par la société Autodesk. Celui-ci permet
d'exploiter le concept de conception paramétrique. C'est
un logiciel de dessin technique à vocation mécanique. Le
choix de ce produit a été fait par la société Flying-Cam à
des fins professionnelles. Pour notre part, nous devons
l’utiliser afin d’avoir la possibilité d’exportation des
modèles d’hélicoptère dans le simulateur de vol.

3.3.3 STANDARDS DE CODAGE
Il n’existe pas vraiment de département informatique chez Flying-Cam et donc aucun standard de
codage n’était imposé. Nous avons donc établi nos propres règles de codage. Ceci pour plusieurs
raisons :
▪ Premièrement, nous sommes deux à travailler sur le projet et il est fort probable que
d’autres personnes continuent son développement ;
▪ Deuxièmement, pour faciliter la relecture et la lisibilité du code.
Organisation
▪ Utilisation de l’anglais pour le code (noms de classe, variables, …) ;
▪ Regroupement des fichiers en répertoires et namespace respectifs en fonction de leurs
utilités ;
Choix des noms
Voici les conventions que nous avons respectées pour nommer les éléments :
▪ Un nom de variable facile à lire, à retenir et sans ambiguïté ;
▪ Une variable membre sera toujours précédé par m_, par exemple : m_MaVariable ;
▪ Une classe sera toujours précédée par C, par exemple : CMaClasse ;
▪ Une énumération sera toujours précédée par E, par exemple : EMonEnumeration ;
▪ Une interface sera toujours précédée par I, par exemple : IMonInterface.
Documentation
▪ Utilisation à bon escient des commentaires. Ils ne doivent être ni trop nombreux, ni absents;
ils se doivent d'expliquer clairement la partie de code qui suit ;
▪ L'utilisation des /// permettant la création automatique de documentation est
recommandée ;
Nous avons décidé de ne pas commenter systématiquement toutes les méthodes mais de
commenter uniquement les méthodes quand cela s’avère utile.

4. CONSIDÉRATIONS THÉORIQUES, ÉTUDES PRÉALABLES
4.1 DÉVELOPPEMENT D’UNE APPLICATION ORIENTÉE OBJET
4.1.1 EXPÉRIENCE PERSONNELLE
Ces trois dernières années de mon activité dans le développement d’applications très diverses m’ont
amené à construire mon point de vue sur plusieurs questions. L’une d’elles, qui semble évidente mais
pas toujours bien comprise, est le cycle de développement. Comment doit-on s’y prendre afin de
concevoir une application qui à la fois :
• réponde aux besoins des utilisateurs ;
• soit facilement modifiable ;
• soit rapidement conçue ;
• soit sécurisée ;
• possède un code lisible ;
• soit optimisée ;
• et finalement soit avec le moins de bugs possibles ;
Le développement d’une telle application ne doit jamais être pris à la légère. Il nous amène à
penser : comment doit-on concevoir l’application et avec quelles techniques ? Comment faire pour
économiser le plus de temps possible sans négliger des étapes importantes ? Voici comment
j’interprète ce processus itératif : le cycle de vie d’une application:

Figure 4 - Cycle de vie d'une application orientée objet
Ce cycle de vie ne s’applique pas spécialement à l’application dans son entièreté, mais le plus
souvent à des parties de l’application.
4.1.2 ANALYSE ET CONCEPTION D’UNE ARCHITECTURE REPONDANT AUX BESOINS
A cette étape du développement, nous devons établir une architecture qui répond ou plutôt essaye
de répondre à tous les besoins des utilisateurs, et qui possède une architecture la plus souple
possible. La souplesse de l’architecture est très importante, car non seulement les besoins des
utilisateurs vont forcément changer mais en plus nous devrons probablement repenser beaucoup de
choses pendant le cycle de vie et tout est susceptible de subir les changements. On pensera aussi à
toutes les technologies nécessaires à utiliser : les langages de programmation, frameworks, etc. C’est
aussi à cette étape qu’on élabore une première liste des logiciels et composants qu’on utilisera
pendant le développement. On essayera de choisir les composants les plus adaptés à nos besoins et
faire une analyse de coûts afin d’optimiser la durée de développement.
4.1.3 IMPLÉMENTATION & SÉCURITÉ
Une fois l’architecture établie, on va procéder à son implémentation. C’est pendant l’implémentation
que l’on est le plus susceptible de revenir à l’étape précédente et de changer l’architecture, d’y
ajouter quelque chose de nouveau ou même de complètement tout repenser. Tout en effectuant
l’implémentation, nous devons intégrer les diverses techniques de sécurité et ne jamais les perdre de
vue. Les techniques de sécurité utilisées dépendront du contexte de l’application.
4.1.4 OPTIMISATION

Cette étape nous amène à revoir tout le code de l’application afin de l’optimiser. Nous utiliserons
divers outils, le plus souvent des profilers qui nous permettent d’optimiser le temps d’exécution de
l’application. Cette étape est malheureusement trop souvent oubliée ou négligée ce qui a pour
conséquence la production d’une application dont les performances ne sont pas optimales.
4.1.5 TESTS & DÉBOGAGE
Une fois l’écriture du code terminée, nous passons à l’étape des tests effectués par nous-mêmes ou
par les testeurs. Le plus souvent dans cette étape on effectuera des tests unitaires et leur débogage.
On veillera à ce que tous les besoins soient respectés et que les calculs soient effectués dans un délai
raisonnable. Pendant cette étape on testera également la sécurité de l’application.

4.2 AU PLAN LOGICIEL
4.2.1 CHOIX DE L’APPLICATION
Nous avons dû prendre plusieurs décisions importantes dès le début de la conception de l’application
sur le plan logiciel.
Tout d’abord, nous avions le choix entre deux applications à développer : une application basée sur
le motion builder, technique qui, en gros, consiste à « capturer » une scène réelle et à reproduire
celle-ci sur l’ordinateur ou un moteur 3D basé sur un simulateur de vol temps-réel.
Nous avons choisi de faire le moteur 3D car la première application devait être faite dans un langage
de programmation totalement inconnu pour nous : le « python ». De plus, le programme de
développement nécessitait l’achat d’une licence et donc le programme était assez dépendant du
logiciel. Enfin, il nous était impossible d’obtenir le code source. Remarque : le développement d’une
application en python nous offrait peu d’apports personnels pour notre avenir professionnel.
4.2.2 OPENGL OU DIRECTX ?
Après ce premier choix, nous devions choisir quelle technologie nous allions utiliser pour réaliser le
moteur 3D. Nous avions le choix entre une programmation en DirectX (Managed ou non) ou OpenGL
ou XNA.
Tableau basique comparant DirectX et OpenGL:
DirectX OpenGL
Avantages - Une seule API pour toutes
les fonctions du
simulateur ;
- plus puissant.
- Multiplateforme ;
- plus simple.
Inconvénients - Non portable. - Nécessite des librairies
additionnelles (notamment
pour le fenêtrage et la gestion
des entrées).
Point de vue
personnel
- Proche du C# : bonnes
connaissances
personnelles ;
- nous travaillons sous
Windows XP : DirectX se
prête mieux.
- Moins de connaissances.

4.2.3 CHOIX DE FRAMEWORK
MANAGED DIRECTX OU XNA FRAMEWORK ?
Le choix de DirectX ayant été fait, il nous restait à savoir quelle version de DirectX nous allions
utiliser, le managé ou non. Après certaines recherches, nous avons découvert un nouveau
framework développé par Microsoft appelé XNA.
Nous avions donc 3 possibilités car nous voulions utiliser les produits Microsoft afin d’avoir le plus de
support et de documentation possibles :
• utilisation de l’API DirectX native en C++ ;
• utilisation du framework « Managed DirectX » en code managé;
• utilisation du framework XNA en code managé.
Le Framework XNA est complètement différent du Managed DirectX (MDX), ce framework basé sur le
framework .NET 2.0 a été créé spécialement pour les développeurs de jeux 2D et 3D sous Windows
et pour la console de jeux Xbox.
Le Framework XNA partage bien entendu des similitudes avec Managed DirectX car ces deux
technologies sont basées sur DirectX. En plus de ces points communs, d’autres technologies comme
XACT (librairies de programmation audio) ou X/Input (une API qui permet la gestion des entrées à
partir du contrôleur de la console XBOX 360 sur un PC Windows) ont été intégrées au framework
XNA. Le Framework XNA implémente également une large partie des fonctionnalités de Direct3D X.
Ce framework est destiné à remplacer Managed DirectX. Ainsi, les libraires de Managed DirectX 2.0
beta ont été déclarées obsolètes (deprecated) en Avril 2006 et ont expiré le 5 octobre 2006 ; il n’y a
donc plus de développement en cours pour le Managed DirectX 2.0. De plus, XNA reprend la plupart
des fonctionnalités qui ont précédemment existé dans le MDX 2.0 beta. Il n’y aura donc pas de
nouvelles fonctionnalités pour Managed DirectX 1.1 et il est possible de faire migrer du code MDX
1.1 en code pour le framework XNA. Le framework XNA peut donc être utilisé par tout le monde : les
anciens développeurs sous MDX et les nouveaux sous XNA.
Nous avons donc choisi d’utiliser ce framework pour des choix de simplicité et de perspective
d’avenir car XNA est le futur pour le développement de jeux vidéo, notre simulateur pouvant être
considéré comme un jeu. De plus, il tend à remplacer le DirectX Managed, ce qui renforce notre
décision pour ce type de programmation. Finalement, nous avons appris qu’un projet appelé
« Mono.XNA » était en développement, celui-ci permettant un portage de XNA sous Linux et Mac.
Ainsi, en utilisant XNA, notre projet sera également portable.

Voici un résumé de l’analyse que nous avons fait afin de comparer les 3 possibilités et faire ce choix :
API en mode natif
Avantages - Meilleures performances.
Inconvénients - Productivité moindre.
Point de vue
personnel
- Création d’un projet sous cette API en 3 mois nous semblait impossible ;
- beaucoup de débogages et de problèmes dus à trop de liberté de l’API.
Framework Managed DirectX
Avantages - Code managé ;
- Bien documenté.
Inconvénients - Productivité moyenne ;
- Pas de support XBox ;
- N’utilise pas les patterns de programmation .Net.
Point de vue
personnel
- A long terme, MDX ne sera plus supporté et son utilisation va diminuer de
plus en plus, nous ne souhaitons pas apprendre une technologie destinée à
disparaître à moyen terme.
Framework XNA
Avantages - Code managé ;
- support XBox 360 ;
- utilise les patterns de programmation .Net

Inconvénients - Peu documenté car trop nouveau
Point de vue
personnel
- A long terme, XNA va devenir le framework « principal » de Microsoft
permettant l’utilisation DirectX en code managé. Une opportunité pour
nous.
4.3 AU PLAN MATÉRIEL
4.3.1 UNITÉ DE CALCUL ET MÉMOIRE
Un simulateur de vol, même en étant optimisé, effectue les calculs à la fois de simulation et de rendu
graphique qui sont très complexes. Nous avions besoin d’acheter une machine capable de faire
tourner le simulateur. Pour ceci on a choisi d’avoir quelque chose de fiable et stable :
• Processeur Intel Core 2 Duo ;
• Mémoire vive Corsair (2 giga de DDR2).
4.3.2 CHOIX DE CARTE GRAPHIQUE
L’étape suivante était de choisir une carte graphique correspondant aux besoins du simulateur. En ce
qui concerne les cartes graphiques, après avoir fait diverses recherches, nous avons constaté que ce
choix avait un impact direct sur le développement de l’application. Cet impact est directement lié à
la manipulation des shaders, car chaque constructeur de chipset avait des petites différences dans ce
langage. Nous reviendrons plus en détail sur cette notion de shaders dans le chapitre §11.5 ci-
dessous. La 2ième
différence consistait dans la version de ce fameux shader langage, après une petite
recherche nous avons établi une liste des versions existantes, introduites dans des versions de
DirectX correspondantes :
Version de DirectX Shader Model Pixel Shader Vertex Shader
8.0 1.0, 1.1 1.0, 1.1 1.0
8.1 1.2, 1.3, 1.4 1.2, 1.3, 1.4
9.0 2.0 2.0 2.0
9.0a 2_x 2_A, 2_B 2_x
9.0c 3.0 3.0 3.0
10 4.0 4.0 4.0
Nous avons opté pour la version du Shader Model 3.0, la plus répandue et la plus accessible au
moment du développement. La version 4.0 étant encore prématurée et peu documentée a été
recalée lors de notre choix.

Une fois le choix du Shader Model fait, le choix du constructeur et le modèle de la carte graphique
nécessaire fut assez simple. Nous avons opté pour le constructeur le plus répandu/vendu dans le
milieu professionnel : Nvidia. Pour ce qui est du modèle de la carte graphique, nous avons opté pour
une GeForce de série 7 car c’est la seule à supporter le Shader Model 3.0.

5. FRAMEWORK XNA
5.1 INTRODUCTION
5.1.1 GÉNÉRALITÉS
Le framework XNA permet aux développeurs de créer des jeux modernes en utilisant le langage C# et
un ensemble complet de bibliothèques de développements. Il utilise son propre pipeline de contenu
rendant l'accès simple et rapide aux contenus 3D, 2D, sonores, etc. Il fournit une API de haut niveau
indépendante des plates-formes Windows et 360, éliminant par ce fait le coût et l'effort à fournir
pour porter les jeux entre ces deux plates-formes.
Le Framework .Net est la principale API de développement pour réaliser des applications Windows.
Le framework XNA a été conçu pour profiter de ce framework en ajoutant un ensemble de
fonctionnalités propre au développement de jeux.
XNA Game Studio Express est une nouvelle solution de développement de jeu destinée
principalement aux étudiants, passionnés et développeurs de jeux indépendants. XNA Game Studio
Express fonctionne avec Visual C# Express 2005 et permet aux développeurs de créer des jeux à la
fois pour Windows et pour la XBOX 360. XNA Game Studio Express inclus :
• le framework XNA est un ensemble de bibliothèques de développement qui permet aux
développeurs d'être plus productifs dans la création de jeux pour Windows et Xbox 360 ;
• le framework XNA Framework Content Pipeline est un ensemble d'outils qui permet aux
développeurs d’incorporer facilement des contenus 3D à l'intérieur de leurs jeux ;
• XNA Game Studio Express contient une documentation complète, des cas pratiques et des
starters kits qui mettent en évidence les bonnes pratiques (patterns) de développement
.Net ;
• XNA Game Studio Express cohabite sans problème avec les autres versions de Visual Studio ;
• XNA Game Studio Express supporte à la fois le développement Windows et Xbox 360.
En résumé, dans XNA Game Studio Express, on peut distinguer deux choses :
• XNA Game Studio Express : un ensemble d'outils basés sur Visual C# Express 2005 ;
• le framework XNA : un ensemble de bibliothèques managées (.NET).
5.1.2 PRÉREQUIS

Pour pouvoir utiliser le framework XNA, il est nécessaire de télécharger et installer Visual C#
Express et les dernières mises à jour des librairies DirectX (le SDK complet n'est pas obligatoire). De
même, il est nécessaire d’avoir une carte vidéo compatible Direct3D 9.0 supportant le modèle Shader
1.1.
Microsoft recommande une carte supportant le modèle 2.0 sachant qu'une partie du
starter kits l'utilise.
Pour plus d’informations sur Visual C# Express, rendez vous sur le site :
http://msdn.microsoft.com/vstudio/express/visualcsharp/
Pour plus d’informations sur le DirectX Software Development Kit (SDK), vous pouvez le télécharger à
cette adresse : http://www.microsoft.com/downloads/details.aspx?FamilyID=86CF7FA2-E953-475C-
ABDE-F016E4F7B61A&displaylang=en

5.2 ARCHITECTURE
5.2.1 GÉNÉRALITÉS
Afin d’expliquer l’architecture XNA, voici un schéma officiel de Microsoft décrivant cette
architecture :
Sur ce schéma, nous pouvons voir que le développement a été effectué couche par couche afin de
rendre le framework le plus souple et extensible possible.

5.2.2 LA COUCHE PLATE-FORME
XNA Game Studio Express réunit un maximum d'outils en provenance de Microsoft et de ses
partenaires :
• API Direct3D pour le rendu graphique ;
• XACT fournissant les outils et fonctionnalités du support sonore ;
• XINPUT offrant des fonctionnalités de base pour le stockage d’informations ;
• XCONTENT offrant une gestion de contenu et des formats de fichiers portables et souples.
5.2.3 LA COUCHE FRAMEWORK DE BASE
XNA inclut un certain nombre de librairies spécifiques pour le développement de jeux afin de
promouvoir un maximum de réutilisations du code entre les deux plates-formes ciblées. On trouve
entre autres des librairies pour les graphiques, l’audio, les inputs, les mathématiques et la
sauvegarde de données.
La librairie « graphique » fournit des capacités pour le rendu de bas niveau ; elle est construite sur
Direct3D 9 et fournit des ressources comme les modèles, les textures, les effets, etc.
La librairie « audio » est basée sur XACT, ce qui permet aux ingénieurs du son et aux programmeurs
de travailler plus naturellement. De plus, elle permet une intégration plus facile pour les
développeurs, par exemple :
- l’accès via des noms logiques,
- les boucles, le streaming et la gestion de la mémoire,
- et ne nécessite aucune gestion du buffer bas niveau1
.
La librairie « input » permet une capture des entrées extrêmement facile. La programmation est
immédiate, il n’y a pas d’initialisation, ni de gestion d’état. La gestion du clavier, de la souris et de la
manette XBOX 360 sont fournies.
La librairie « mathématique » fournit toutes sortes de notions mathématiques utiles en 3D comme
les vecteurs, les matrices, les quaternions, la notion de plan, les sphères, le rayon, le frustrum, la
courbe, etc.2
Un repère main droite est défini par défaut alors qu’un repère main gauche était utilisé
dans DirectX Managed, nous y reviendrons plus tard. Cette librairie fournit également une aide sur
les intersections et les mouvements.
1
Ces notions sont décrites dans le lexique
2
Ces notions sont décrites dans le lexique

La librairie « sauvegarde » fournit un moyen simple pour écrire et lire les données du jeu et les écrire
sur le disque. Ces données seront toujours sauvegardées dans un répertoire correct pour chaque
plate-forme.

5.2.4 LA COUCHE FRAMEWORK ÉTENDU
La couche du framework étendu est une couche supplémentaire et une des différences majeures
entre XNA et le Managed DirectX ; elle est divisée en deux parties :
• application model ;
• et content pipeline.
La dite « application model » est une librairie contenant le squelette d’un moteur 3D basé sur les
composants, offrant ainsi un modèle de base pour permettre aux programmeurs de concevoir les
composants des jeux, se les échanger, voire les vendre. Ce concept est issu du modèle classique des
formulaires Windows (WindowsForms), où il existe beaucoup de sociétés privées qui vendent des
composants offrant de nombreuses fonctionnalités supplémentaires.
Dans toute application XNA, il est nécessaire de gérer différentes ressources de type graphique, son,
modèles 3D, etc. Le « Content Pipeline » de XNA permet de charger ces ressources et de les utiliser
simplement.
A partir d'un fichier "traditionnel" comme une image .png, un son .wav ou un modèle 3D .x (ou .fbx),
une classe de type « Content Importer » charge le fichier et son « Content Processor » le transforme
en ressource utilisable par le jeu (.xnb). Il est également possible de créer votre propre
Importer/Processor mais XNA Game Express en fournit déjà plusieurs qui suffisent dans un premier
temps pour la plupart des assets (contenu artistique). De plus, l'IDE de C# Express supporte
nativement ces Importers/Processors ce qui fait qu'importer une image (son, modèle) revient
simplement à ajouter dans le projet la dite image (son, modèle).
Il existe aussi un Importer/Processor pour les effets (shaders), effets stockés dans des fichiers .fx
pour des effets de type Vertex, Pixels Shader en HLSL (High Level Shader Language).

6. NOTIONS DE 3D
6.1 INTRODUCTION
Beaucoup de nouvelles notions en 3D ont dû être acquises lors de la conception du simulateur. XNA
fournit des aides pour ces notions, mathématiques ou autres.
Tout d’abord, il faut savoir se positionner dans un repère orthonormé 3D. Ensuite, on doit créer des
points et les relier pour former des formes géométriques. Une fois que nous avons notre objet en 3D,
il faut pouvoir le faire bouger.
Tout développeur 3D doit faire face à ces notions et ne pas les comprendre rendrait le
développement plus compliqué qu’il ne l’est déjà. Ces notions sont donc primordiales.
6.2 REPÈRES 3D
Pour positionner un point en 2D, on dispose de deux axes orthonormés : X est l’axe horizontal et Y
l’axe vertical. La 3D nécessite un troisième axe : l’axe Z.
Le monde où l’hélicoptère va évoluer est donc un espace 3D orthonormé. Tout point est donc situé
par l’intermédiaire de trois composantes:
- sa position par rapport à la côte X,
- sa position par rapport à la hauteur Y,
- sa position par rapport à la profondeur Z.
En 3D "XNA", on se situe par rapport à un repère dit de
"main droite". La figure ci-contre montre un repère main
droite.
Ce nom vient du fait que vous pouvez reproduire ce
repère à l'aide de votre main droite. Le pouce représente
l'axe X, l'index l'axe Z et le majeur l'axe Y. Nous
positionnerons donc nos objets en utilisant ces
coordonnées 3D. Z croît avec la distance, Y croît avec la
hauteur et X permet de se déplacer sur l'horizontale.
Figure 5 - Repère 3D dit "main droite"

6.3 UN VERTEX, DES VERTICES
En 2D, afficher un objet consiste à « plaquer » une image à l’écran. En 3D, c’est différent. Les objets
ne sont pas dessinés à partir d'une image mais plutôt à partir de différents points. C’est ce qu’on
appelle un vertex ou les vertices au pluriel.
Un vertex est donc un point dans l'espace auquel on associe des propriétés (couleur, position, ...).
C’est le pipeline 3D qui va relier ces points pour former un objet ; concrètement c’est toute
l’architecture de l’ordinateur qui s’en occupe (à l’aide de la carte graphique par exemple). Le
développeur a pour tâche de bien placer ces points et d'indiquer au device l’objet permettant
l’interfaçage avec la carte graphique ainsi que la façon de relier les vertices. Il existe différentes
méthodes pour relier ces vertices, nous y reviendrons rapidement.
La figure ci-dessous illustre bien la notion de vertex. Nous voyons un cube et un tube en trois
dimensions. On remarque qu'ils sont tout simplement formés à partir de points (nos vertices) qui
sont reliés entre eux.
Figure 6 - Un cube et un tube en 3D
Nous remarquons que notre cube et notre cylindre ci-dessus sont formés uniquement de triangles.
Le triangle est la forme géométrique la plus simple en 3D. Trois vertices sont nécessaires pour la
former. Toute forme géométrique en 3D est formée de triangles, c’est à dire d’une multitude de
vertices qui, reliés, permettent de donner une apparence à certains objets.
Voici deux exemples de code où nous utilisons les vertices :

• Le premier provient de la classe CGrid qui représente une grille sur le sol. On y utilise un
VertexPositionColor ; comme son nom l’indique on peut paramétrer sa position et sa couleur.
• Le second provient de la classe CTexturedQuad qui permet de créer un carré en 3D avec pour
surface une texture. On y utilise VertexPositionTexture, celui-ci aura comme second
paramètre les coordonnées des points dans la texture.
namespace Diamond.World
{
public partial class CGrid : CObject, ILoadable, IRenderable
{
#region Members
private Color m_color = Color.White;
private VertexDeclaration m_vDec;
private VertexPositionColor[] m_verts;
private VertexBuffer m_vBuffer;
private void FillBufferForXZPlane(VertexPositionColor[] data, int
gridSize)
{
int index = 0;
float zPos = (CMeasure.PointsPerMeter * m_MeterPerSquare);
float xPos = (CMeasure.PointsPerMeter * m_MeterPerSquare);
int gridSizeHalfed = gridSize / 2;
float yPos = 0;
// Draw x zero line
data[index++] = new VertexPositionColor(new
Vector3(gridSizeHalfed * (CMeasure.PointsPerMeter * m_MeterPerSquare),
yPos, 0), m_color);
data[index++] = new VertexPositionColor(new Vector3(-
gridSizeHalfed * (CMeasure.PointsPerMeter * m_MeterPerSquare), yPos, 0),
m_color);
( … )
}
#endregion
}
}
namespace Diamond.Render
{
public class CTexturedQuad : CObject, IRenderable, ILoadable
{
private string m_Asset;
private Texture2D m_Texture;
private VertexBuffer m_Vertices;
#region ILoadable Membres
public void LoadGraphicsContent(GraphicsDevice _Device,
ContentManager _Loader)
{
m_Texture = _Loader.Load<Texture2D>(m_Asset) as Texture2D;
VertexPositionTexture[] verts =
{
new VertexPositionTexture(new Vector3(-0.5f, 0.5f, 0), new
Vector2(0, 0)),

new VertexPositionTexture(new Vector3(0.5f, 0.5f, 0), new
Vector2(1, 0)),
new VertexPositionTexture(new Vector3(-0.5f, -0.5f, 0), new
Vector2(0, 1)),
new VertexPositionTexture(new Vector3(0.5f, -0.5f, 0), new
Vector2(1, 1))
};
( … )
}
}
}
Remarque : nous utiliserons le type Vector3 pour définir une position dans l’espace. Un Vector3 est
un vecteur possédant trois composants x, y et z : nos trois coordonnées.
Comme signalé plus haut, il existe plusieurs solutions pour relier les vertices entre eux afin de former
des objets 3D. Chaque solution possède ses propres avantages en fonction de la forme de l’objet.
C'est pourquoi il convient d’utiliser celle qui s'avère la plus adaptée dans un seul but : réduire au
maximum le nombre de vertices. L’association de plusieurs vertices entre eux permet à XNA de
former des triangles (assimilables à des surfaces). L’association de ces surfaces permet alors de
former des objets dans l’espace. XNA raisonne en ternaire ; Il lui faut trois point pour former la plus
petit figure géométrique possible : le triangle.
Triangle List
Le mode de liaison de vertex le plus simple : les points sont liés trois
par trois afin de former les triangles à afficher. Avec ce mode de
liaison, il est donc nécessaire de créer un nombre de vertices multiple
de trois. Les trois premiers vertices représenteront le premier
triangle, les trois suivant le second triangle et ainsi de suite... C’est le
mode de définition le plus simple mais aussi le plus coûteux. Il n’est
jamais utilisé sur des formes géométriques complexes car il impose
de créer et de placer un nombre très important de vertices...
Pour dessiner 3 triangles : Vertices (0, 1, 2) puis Vertices (3, 4, 5), puis Vertices (6 7, 8) : 9 vertices
pour afficher 3 triangles.
Triangle Fan
Ce mode est plus intelligent ; il réutilise des vertices déjà utilisé pour
les liaisons. On gagne ainsi de précieux octets en mémoire libérant
ainsi le pipeline 3D. Dans ce mode, le premier vertex est relié à tous
les autres. Là aussi, les possibilités sont limitées ; on ne peut faire que
des formes rectangulaires et/ou cylindriques comme le montre le
schéma ci-contre.
Pour dessiner 3 triangles : Vertices (0, 1, 2) puis Vertices (0, 2, 3), puis
Vertices (0, 3, 4) : 5 vertices pour afficher 3 triangles.

Triangle Strip
Ce troisième mode est un peu plus compliqué. On relie ici
aussi les vertices par trois. Mais en considérant que le dernier
vertex créé doit être relié aux deux précédents. Le gain de
place en mémoire est très important, mais la difficulté pour
créer des formes complexes est multipliée.
Pour dessiner 6 triangles : Vertices (0, 1, 2), Vertices (1, 2, 3),
Vertices (2, 3, 4), Vertices (3, 4, 5), Vertices (4, 5, 6), Vertices
(5, 6, 7) : 8 vertices pour afficher 6 triangles.
Au niveau du code, c'est l'énumération PrimitiveType qui contient les différents types
d'énumérations possibles. D'autres types de liaisons plus simples sont possibles :
▪ Point qui ne fait aucune liaison et laisse les points tels quels,
▪ LineList qui relie les points deux à deux,
▪ LineStrip qui relie un point à son prédécesseur.
Dans nos classes CGrid et CTexturedQuad nous relions respectivement nos vertices avec les modes
PrimitiveType.LineList et PrimitiveType.TriangleList.
Dans le cas de CGrid, nous utilisons le mode LineList car nous ne faisons que de relier chaque fois
deux points pour former une ligne. Nous créons donc notre grille en créant une succession de lignes
formées de deux points.
Dans le cas de CTexturedQuad, nous utilisons le mode TriangleList car notre forme géométrique est
très basique, il n’y a que deux triangles, utilisé un mode compliqué n’aurait pas apporté un gain
significatif.
Pour dessiner un triangle, il faudra donc créer 3 vertices, leur donner une position et, au moment de
l'affichage, spécifier la méthode de liaison.
Un modèle 3D est donc constitué de vertices ; plus il y en a et plus le modèle est complexe. Pour
donner un exemple, le modèle de l’hélicoptère Flying-Cam possède environ 13000 vertices.

6.4 LES MESHES
Un Mesh est littéralement un treillis ou un maillage. C’est un objet tridimensionnel constitué de
polygones sous forme de fil de fer. Cet ensemble structuré contient la géométrie, les matrices, les
caractéristiques de couleurs et les textures d’un modèle 3D.
Figure 7 – Le modèle de l'hélicoptère Flying-Cam en mode "fil de fer"
6.5 DÉPLACEMENT 3D : LES MATRICES
Pour déplacer nos objets dans un monde 3D, nous devons utiliser les matrices. Ces matrices vont
effectuer des transformations sur nos objets.
Ainsi, si l’on multiplie une position dans l’espace (un Vecteur3 est une matrice ligne3
) par une
matrice, on obtient en retour une position transformée.
Nous pouvons paramétrer nos matrices afin d’effectuer plusieurs sortes de transformations : une
translation (déplacement), une homothétie (redimensionnement) et/ou une rotation.
Grâce à XNA, nos matrices peuvent aussi représenter un ensemble de calculs mathématiques comme
une série de transformations ou encore les propriétés d'une caméra (position, direction, angle de
vision, distance de vision ...).
Par exemple, nous utiliserons souvent des matrices nommées View et Projection.
3
Une matrice ligne est une matrice qui ne possède qu’une seule ligne.

La première matrice est utilisée pour reproduire la vue de la caméra, elle contient des informations à
propos de la position de la caméra, le point vers lequel elle regarde et l’axe vertical. XNA fournit des
méthodes permettant de créer cette matrice. Par exemple, la méthode CreateLookAt de la classe
Matrix.
Exemple de création d’une matrice vue m_View dans la classe CCamera :
m_View = Matrix.CreateLookAt(m_Position, m_Target, m_UpVector);
La seconde matrice nous permet de paramétrer la caméra. XNA fournit encore une fois une méthode
pour créer cette matrice, c’est la méthode CreatePerspectiveFieldOfView de la classe Matrix. Les
paramètres de cette méthode sont l’angle d’ouverture de la caméra, l’aspect ratio, la position la plus
proche visible et la position la plus éloignée visible. Nous reviendrons sur ces notions propres à la
caméra dans le chapitre § 11.2 ci-dessous qui lui est consacré.
m_Projection =
Matrix.CreatePerspectiveFieldOfView(fieldOfView, aspectRatio,
m_Viewport.MinDepth, m_Viewport.MaxDepth);
Comme indiqué plus haut, les matrices sont utilisées aussi pour effectuer des transformations sur les
objets. Par exemple, toujours dans la classe Matrix, nous avons des méthodes comme
CreateTranslation, CreateRotationX, CreateRotationY, CreateRotationZ, CreateScale, …
Voici un exemple venant de la classe CCubeLogo où nous créons une matrice d’étirement, le
« scale », une matrice de translation et une matrice de rotation. Ces matrices sont ensuite utilisées
pour calculer la matrice World qui est la représentation de la géométrie 3D :
public void SetSize(Vector3 size)
{
this.m_Width = size.X;
this.m_Height = size.Z;
this.m_Depth = size.Y;
this.m_ScaleMatrix = Matrix.CreateScale(size.X, size.Y, size.Z);
this.UpdateTransformation();
}
public void SetPosition(Vector3 location)
{
this.m_X = location.X;
this.m_Y = location.Y;
this.m_Z = location.Z;
this.m_TranslationMatrix = Matrix.CreateTranslation(location.X,
location.Y, location.Z);
}
public void SetRotation(float rotationX, float rotationY, float rotationZ)
{
this.m_RotationX = rotationX;
this.m_RotationY = rotationY;
this.m_RotationZ = rotationZ;

this.m_RotationMatrix = Matrix.CreateRotationX(rotationX) *
Matrix.CreateRotationY(rotationY) * Matrix.CreateRotationZ(rotationZ);
}
private void UpdateTransformation()
{
this.m_TransformationMatrix = this.m_ScaleMatrix *
this.m_RotationMatrix * this.m_TranslationMatrix;
this.m_Effect.World = this.m_TransformationMatrix;
}
XNA fournit donc une aide précieuse dans l’utilisation des matrices. Tout est fait automatiquement,
la programmation n’en est que plus simple. Les opérateurs sont surchargés pour les matrices et
d’autres fonctions comme Invert ou Transposed également. Le programmeur n’a donc plus besoin de
faire toutes sortes de calculs pour programmer en 3D.

7. NOTIONS D’AVIATION
7.1 INTRODUCTION
Avant de nous lancer dans la conception même du moteur 3D, même si la simulation a été conçue
par un ingénieur spécialisé, nous devions comprendre le fonctionnement d’un hélicoptère et avoir
des notions de base d’aviation.
Dans un hélicoptère, comme pour un avion, la vitesse relative de l'air et de la voilure génère une
action mécanique qui permet à l'engin de voler. On distingue deux composantes de cette action
aérodynamique:
• la traînée qui est la résistance à l'avancement. De son action sur le rotor de l'hélicoptère, il
résulte un couple tendant à faire tourner l'appareil autour de son axe, d'où la nécessité d'un
dispositif anti-couple. La trainée a également un effet sur le fuselage dès que la vitesse de
l’hélicoptère augmente ;
• la portance qui soulève l'appareil.
Le contrôle d'un appareil repose alors sur la gestion de cette portance. Alors que sur les avions, des
volets permettent de modifier la portance moyenne des ailes pour virer et monter, sur l'hélicoptère
on modifie le pas qui modifie l'inclinaison des pales.
Tout déplacement et stabilisation d’un hélicoptère est effectué grâce à l’inclinaison des pales.
Equilibre en vol stationnaire Déséquilibre Déplacement stabilisé
Vol stationnaire.
Le rotor de l'hélicoptère étant entraîné à vitesse constante, les déplacements verticaux de
l'hélicoptère sont obtenus par la seule modification du pas des pales. À ce stade du vol, la portance
des pales reste identique sur un tour du rotor. Il existe une position où la portance globale s'oppose
exactement au poids de l'appareil : l'hélicoptère peut rester immobile. Si elle lui est inférieure,
l'appareil descend. Si elle est supérieure, il monte.

7.2 ROTATIONS
ROTATIONS
Afin d’effectuer correctement les rotations de l’hélicoptère dans l’espace, ces rotations doivent être
effectuées dans un certain ordre.
Il existe une convention de nommage des angles de rotations. Voici ces 3 angles :
: Angle “Phi” : Rotation autours de l’axe X;
: Angle “The” : Rotation autours de l’axe Y;
: Angle “Psi” : Rotation autours de l’axe Z.
Pour faciliter la compréhension, illustrons ces rotations.
La rotation sur l’axe Z :

La rotation sur l’axe X :
La rotation sur l’axe Y :
LE ROTOR
Toute rotation du rotor principal entraîne un
couple de réaction qui a tendance à faire tourner
la cellule autour de lui et en sens inverse (3e
loi
de Newton). Pour contrer cet effet indésirable,
on place (pour les hélicoptères à un seul rotor
principal) à l'extrémité de la poutre de queue, un
rotor secondaire plus petit et tournant dans un
plan sensiblement vertical appelé rotor anti-
couple.

Pour ce qui concerne le sens des rotations du rotor principal, ça n’a pas vraiment d’importante. Une
petite anecdote est que tous les hélicoptères américains utilisent la rotation contraire au sens
inverse des aiguilles d’une montre et les hélicoptères russes utilisent la rotation dans le sens des
aiguilles d’une montre. Les européens n’ont pas de normes.

8. LE PROJET
8.1 VISION DU PRODUIT FINI
Notre projet est donc la réalisation d’un moteur 3D pour un simulateur. Mais qu’est-ce qu’un
simulateur ?
Un simulateur est un outil permettant notamment à l'apprenant de simuler les expériences en vue
de retrouver lui-même les lois qui les sous-tendent ou d'en voir le résultat.
Dans notre cas, nous devons donc permettre à un pilote ou à un futur pilote d’obtenir les mêmes
sensations que s’il pilotait un vrai hélicoptère. Afin de faciliter la compréhension du projet et de ce
document, voici plusieurs captures d’écran du moteur 3D fini :
Nous voyons à l’écran plusieurs choses :
• deux vues ;
• un menu ;

• un hélicoptère au centre de l’écran ;
• deux bateaux dont l’un (le voilier) est affiché dans deux vues différentes;
• de l’eau et le ciel.
Sur cette capture d’écran on peut remarquer la complexité de la scène :
• l’hélicoptère est penché en arrière (à cause du mouvement effectué) mais la vue de la
caméra reste fixe par rapport à l’horizon ;
• l’affichage de l’hélicoptère est assez complexe, contenant des parties transparentes afin de
donner une impression de flou ;
• la deuxième vue a été déplacée sur l’écran.
On peut donc déduire qu’il y a plusieurs choses bien distinctes dans cette scène :
• les interfaces utilisateurs afin de configurer la scène ;
• un espace de travail (ou monde) dans lequel nous avons nos objets ;
• une interface homme /machine définie par des contrôleurs de l’hélicoptère ;

• plusieurs zones d’affichage permettant d’afficher les espaces de travail sous différents
angles ;
• des objets quelconques pouvant être affichés ;
• un hélicoptère pouvant être contrôlé et déplacé.

8.2 OBJET PRINCIPAL
Notre objet principal est donc notre hélicoptère. En 3D, on parle de modèle 3D. Cet objet possède
une géométrie et différentes propriétés par rapport au monde :
• il peut se déplacer ;
• il peut être affiché ;
• il peut être contrôlé par différents contrôleurs (joystick par exemple);
• en fonction des angles de la caméra, une vue spécifique est affichée ;
Figure 8 - Modèle 3D de l'hélicoptère Flying-Cam
Cet hélicoptère qu’on voit à l’écran est, en réalité, un modèle 3D composé de meshes ( Voir § 6.4
above pour plus d’informations concernant les meshes et la 3D). Il possède des propriétés et des méthodes et
peut interagir avec le matériel. Il peut être donc considéré comme un objet dans le sens orienté
objet.

8.3 OBJETS SECONDAIRES
Les objets secondaires (bateaux, ciel, eau, …) que nous avons vu sur l’écran, ont la même structure
que l’objet principal (hélicoptère) excepté qu’ils ne peuvent pas être contrôlés et que la complexité
d’affichage est moindre :
• pas de transparence des parties de l’objet ;
• pas d’animations à l’intérieur.
Figure 9 - Objet secondaire (bateau)

8.4 INTERFACES UTILISATEUR
Voyons maintenant un peu plus en détail le menu de contrôle rapide :
Nous pouvons voir que ce menu permet :
(1) De créer une nouvelle scène de simulation.
(2) Une fois la scène créée, nous pouvons démarrer ou arrêter la simulation.
(3) Nous pouvons afficher la console de simulation, avec les données de cette dernière (les
angles, positions ou autre).
(4) Nous pouvons choisir un contrôleur actif (il existe deux types d’interfaçages de contrôleurs
utilisés chez Flying-Cam : USB et Série.
(5) Plusieurs modes de simulation (un mode de simulation normal et un mode de test).
(6) Nous pouvons afficher ou pas les diverses composantes d’environnement (l’eau, grille).
Nous pouvons donc déduire qu’il y a :
• une scène et une gestion de scène ;
• démarrage et arrêt de la simulation (qui n’est pas spécialement attachée à la scène) ;
• deux types d’interfaçages de contrôleurs à gérer : USB et Série.
8.5 EN CONCLUSION
Pour conclure, nous pouvons donc déduire de tout ceci que nous avons plusieurs parties plus
globales :

9. L’ARCHITECTURE GLOBALE DE L’APPLICATION
9.1 L’ARCHITECTURE MODULAIRE DE L’APPLICATION
L’architecture globale de l’application a été pensée et conçue par modules, une division logique a été
faite. Le schéma ci-dessous montre les divers modules logiques :
Figure 10 - Architecture globale (Modules)

9.1.1 SIMULATION
Le processus de simulation est effectué grâce à un modèle non linéaire dans l’hélicoptère obtenu par
une technique appelée MOdelling for Flight Simulation and Control Analysis (MOSCA) [9].
MOSCA est le fruit des recherches de Marco La Civita réalisé pour son mémoire « Integrated
Modeling and Robust Control for Full-Envelope Flight of Robotic Helicopters ». Il est responsable de
la recherche et développement chez Flying-Cam.
C’est une technique de modélisation de vol automatisé en combinant 2 techniques différentes :
• First-principles modeling, permettant d’obtenir les modèles de vol à la fois en temps réel et
non temps réel. Ces modèles possèdent les dynamiques non-linéaires.
• System Identification, permettant d’obtenir les modèles de vol en temps réel (donc très
haute fréquence). Ces modèles possèdent les dynamiques linéaires.
De notre côté, en utilisant cette librairie on peut assez facilement échanger les données et effectuer
l’affichage de l’hélicoptère en 3D sur l’écran. Pour assurer l’exécution fluide de la simulation, nous
devons nous assurer d’une exécution à 125 hertz de la librairie MOSCA. Nous devons également
gérer les différentes scènes du simulateur, l’échange des données (axes, contrôleurs) entre la
librairie et notre code C#.

Figure 11 - Suivi d'une voiture de Formule 1 par la Flying-Cam

9.1.2 AFFICHAGE
Le module d’affichage est le plus gros module que nous devions développer. Ce module est composé
de plusieurs parties :
• moteur de rendu graphique ;
• objets de scènes;
• interfaces utilisateur.
Le moteur de rendu graphique est en même temps le moteur d’optimisation d’affichage. Il possède
une notion des objets 3D permettant de développer simplement et rapidement diverses scènes. Ce
moteur lui-même intègre plusieurs parties, dont 3 principales :
• framework de rendu « objets », simplifiant le processus de développement grâce à une
couche plus abstraite. Ceci permet de développer les classes standards et flexibles afin de ne
plus vraiment se soucier des vertices en tant que tels et travailler par objets. Par exemple,
l’hélicoptère est un objet 3D en lui-même qui contient un modèle 3d, une fonction de mise à
jour et de rendu. Il peut être tourné en modifiant sa propriété de rotation et déplacé en
modifiant sa propriété de position ;
• gestion d’optimisation de rendu qui permet ne pas dessiner ce qui n’est pas visible, rendant
ainsi le temps d’affichage de la scène plus court. Cette partie de moteur de rendu utilise des
techniques avancées utilisées dans le domaine des jeux vidéos (où la performance est
importante) ;
• gestion des zones d’affichage et des vues de caméra qui permettent de définir une zone
d’affichage et de n’afficher que dans cette zone. Cette partie remplace une partie du
framework XNA qui, lui, a été conçu pour les jeux vidéo et ne possède pas cette notion de
zone. Nous avions besoin de cette technique afin d’afficher plusieurs vues simultanément
(dont une de la caméra qui se trouve dans l’hélico).
Divers objets de scène ont été créés pour l’environnement 3D de la simulation : l’hélicoptère, skybox,
skydome, bateaux, maisons, océan...
Les interfaces utilisateurs ont également été créées afin d’assurer l’interaction la plus simple possible
entre l’utilisateur et la simulation. Ces interfaces comprennent la configuration des contrôleurs et
divers composants personnalisés.

9.1.3 ENTRÉES
Le module des entrées est un module très important car il permet de configurer et d’utiliser divers
types de radios. Ce module a été conçu en 2 parties :
• module USB, permettant de brancher et de gérer n’importe quel contrôleur USB. Ce module
a été conçu pour être le plus flexible possible, vu la diversité des radios existantes sur le
marché ;
• module Série, permettant de gérer les données qui arrivent par le port série d’un contrôleur
spécifique. Nous nous sommes basés sur un protocole de ce contrôleur afin d’extraire les
données dans le bon ordre.

9.2 L’ARCHITECTURE EN COUCHES DE L’APPLICATION
L’architecture globale de l’application a été pensée en plusieurs couches en se basant sur DirectX
pour l’affichage graphique et l’interaction avec le matériel de l’ordinateur et sur la librairie de
simulation MOSCA pour la simulation en elle-même.
Figure 12 - Architecture en couches

9.2.1 COUCHE NATIVE
La première couche native comprend 2 parties
principales : DirectX API et Mosca. Chacune de ces
librairies est écrite en mode natif Win32.
Microsoft DirectX est une suite d'API multimédia
intégrée au système d'exploitation Windows
permettant d'exploiter les capacités matérielles
d'un ordinateur. DirectX fournit un ensemble de
bibliothèques de fonctions essentiellement
dédiées aux traitements audio / vidéo (carte vidéo, carte son, etc.) et aux périphériques d'entrée /
sortie (joystick, carte réseau, souris, etc.).
L'avantage des fonctions de DirectX pour les programmeurs est que celles-ci utilisent un algorithme
alternatif (confié au processeur) quand le matériel installé ne gère pas ce type de traitement. Il
fonctionne comme une surcouche de Windows, évitant théoriquement aux programmeurs de devoir
s'occuper des différences matérielles qui existent entre les différents PC. Par exemple, si une carte
vidéo n'a pas de fonctions dédiées à la 3D, DirectX demandera au processeur principal de s'occuper
du rendu d'une image de synthèse ou du rendu 3D en temps réel.
Pour plus d’information sur le fonctionnement global de la librairie MOSCA, voir § 9.1.1 ci-dessus.
9.2.2 COUCHE MANAGÉE
La deuxième couche était nécessaire afin de
donner une interface managée à la couche
native. Cette couche amène à la fois la portabilité
des couches du dessus et l’amélioration de la
productivité et de la sécurité.
La librairie Diamond.Mosca que nous avons
conçu permet l’interfaçage avec la librairie
MOSCA. Cette librairie assure également
l’exécution de la librairie à une fréquence de 125 hertz et permet l’échange des données entre les
deux. Elle utilise des fonctionnalités non portables.
La première couche de XNA Framework et la librairie DirectInput du Managed DirectX servent à faire
le même interfaçage mais au niveau de la carte graphique et des entrées USB.

9.2.3 COUCHE ABSTRAITE
La troisième couche est une couche à la fois
abstraite et générique. Le but de cette dernière
est de fournir les fonctionnalités simplifiant la
programmation et améliorant la productivité. Sur
cette couche il existe 2 parties principales : une
pour le rendu (c’est en fait le moteur de rendu
graphique) et une autre pour les entrées des
contrôleurs.
Diamond.Input.Usb et Diamond.Input.Serial sont des librairies qui permettent d’utiliser facilement
les contrôleurs USB et Série et qui fournissent les fonctionnalités afin de configurer ces contrôleurs.
Diamond.Render est une des librairies les plus développées de notre application. C’est à la fois le
moteur de rendu graphique et le remplacement de la deuxième couche XNA nécessaire pour
l’affichage par zone et non plus par fenêtre Windows. Cette librairie se compose principalement de :
• framework de gestion objets ;
• gestion de multiples caméras (de rendu) ;
• gestion de terrain et les optimisations de ce dernier ;
• graphe de scène ;
• octree d’optimisation de rendu ;
• zones d’affichage et leur gestion ;
• gestion des shaders et du post-processing ;
• gestion des exceptions du moteur.
Chacune de ses parties sera expliquée dans le chapitre consacré au moteur de rendu graphique et
ses composants. Voir § 11 below pour plus d’informations sur le moteur de rendu graphique.
9.2.4 COUCHE SPÉCIFIQUE À L’APPLICATION
La dernière couche est une couche spécifique à
l’application. Elle intègre les fonctionnalités
demandées (logique métier en quelque sorte), les
interfaces graphiques et d’autres fonctionnalités
accessoires comme l’enregistrement des
paramètres ou le logging. Cette couche intègre

également une couche plus abstraite des entrées utilisées dans le simulateur.

10. SIMULATION
10.1 INTRODUCTION
Une simulation de vol est un système dans lequel un pilote réel est aux commandes d'un hélicoptère
virtuel dont le comportement est obtenu par simulation.
Notre moteur 3D est un outil professionnel conçu pour remplir plusieurs besoins de l’entreprise :
• la formation continue des pilotes;
• simulation des scènes réelles (sur un tournage par exemple) ;
• permettre le pilotage en aveugle (sans voir l’hélicoptère réel, en regardant uniquement
l’écran).
En plus simple, MOSCA prend en charge tout ce qui concerne le modèle des vols et nous permet de
l’utiliser de cette manière :
MOSCA est implémenté chez Flying-Cam sous forme d’une librairie écrite en langage C. Etant donné
que nous devions pouvoir l’utiliser en langage C#, le développement du module « Wrapper » fut
nécessaire pour permettre l’interaction.

10.2 WRAPPER POUR MOSCA
Dans le cadre de simulation, afin d’assurer une
exécution fluide de la simulation, nous devons
nous assurer d’une exécution à 125 hertz de la
librairie MOSCA.
Le module de simulation interne à notre
simulateur est représenté sous forme d’une
classe statique CMoscaWrapper. Cette classe
permet de :
• démarrer/arrêter la
simulation ;
• assurer l’exécution à
125 hertz ;
• offrir des accès
rapides à des valeurs d’entrée/sortie
de la librairie MOSCA ;
• effectuer la
transition entre le code C et le code
managé.
L’exécution de la librairie MOSCA se résume à un appel itératif d’une fonction. Cette fonction est
prototypée d’une manière à avoir les valeurs d’entrées (double InputValues[]) et les valeurs de sortie
(double OutputValues[]). Ces valeurs sont mémorisées sous forme des variables statiques dans la
classe CMoscaWrapper.
Examinons maintenant les principales fonctions de cette classe en commençant par la fonction de
démarrage de la simulation, la fonction Start(). Dans cette fonction l’appel itératif à la fonction
MOSCA est implémenté. Cette dernière n’est pas conçue en temps réel et la durée d’exécution peut
varier. Nous devions donc nous assurer d’attendre le temps restant, calculé suivant la formule :
Où : est le temps d’attente à trouver.

est le temps d’exécution de la fonction MOSCA.

public static void Start()
{
if(CInputController.Instance.ControllerType ==
EInputController.SerialController)
{
CInputController.Instance.SerialController.SerialReadMessageEvent +=
new CSerialReadEventHandler(SerialController_SerialReadMessageEvent);
SerialAsyncThread =
CInputController.Instance.SerialController.ReadLoopThread();
} //(1)
GetPosition(true, Microsoft.Xna.Framework.Input.Keys.D9, ref
InputValues, ref OutputValues); //(2)
Started = true;
timeBeginPeriod(1); //(3)
while (Started) //(4)
{
PerfTimer2.Stop();
PerfTimer1.Start();
GetPosition(false, KeyPressed, ref.InputValues, ref OutputValues);//(5)
PerfTimer1.Stop();
int diff=8-(int)((PerfTimer1.Duration+PerfTimer2.Duration)*1000); //(6)
if (diff > 0)
Thread.Sleep(diff); //(7)
PerfTimer2.Start();
}
}
(1) Tout d’abord, nous initialisons l’événement de la lecture du contrôleur
série ( Voir le TFE de Quentin Charlier pour plus d’informations sur la gestion des contrôleurs).
(2) Un premier appel à la fonction MOSCA est effectué, réinitialisant ainsi la
simulation.
(3) La période de temps (la résolution du timer) est mise à 1 milliseconde,
assurant ainsi que la fonction Thread.Sleep() effectue une attente avec la bonne précision
(Thread.Sleep(7) sans avoir forcé une période peut attendre 15ms suivant l’horloge).
(4) On démarre la boucle principale, la simulation en elle-même.
(5) On effectue l’appel à la fonction MOSCA, en passant par référence les
valeurs d’entrée et en récupérant les valeurs de sortie.
(6) On effectue le calcul à l’aide des chronomètres.
(7) Finalement, on effectue un Thread.Sleep( ) et on attend le temps
nécessaire.
Examinons maintenant la fonction MOSCA et son prototype C :
int wrapper_fc_gui__(integer *first_call__, integer *
mode_key__, doublereal *input_futaba__, doublereal *all_state__)

Cette fonction contient 4 paramètres dont 2 vecteurs (doublereal*). Afin de pouvoir l’utiliser en C#, il
est nécessaire de créer une liaison sous forme d’une fonction « static extern » et dotée d’un attribut
DllImport, disant au compilateur que c’est une fonction externe se trouvant dans une librairie.
[DllImport("mosca_FC.dll", EntryPoint = "wrapper_fc_gui__",
CallingConvention = CallingConvention.Cdecl)]
unsafe static extern int UnsafeCallFcGui(int* first_call__, int*
mode_key__, double* input_futaba__, double* all_state__);
Pour mieux expliquer la fonction, voici un tableau des 4 paramètres de la fonction et les valeurs
possibles :
Paramètre Description Valeurs possibles
int*
first_call__
Permet de dire à la librairie MOSCA si
les valeurs doivent être réinitialisées
dans un état de situation initiale ou pas.
0 : non
1 : oui
int*
mode_key__
Permet de transférer à la librairie
MOSCA des informations sur le mode
de la simulation.
0 : Pilotage manuel
9 : Pilotage automatique
8 : Pilotage automatique avec caméra
gyrostabilisé
double*
input_futaba__
Vecteur de 8 entrées des valeurs des La valeur de pulsion est comprise entre

axes des contrôleurs. -0.5 et 0.5
double*
all_state__
Vecteur de 35 entrées avec des diverses
informations de sortie.
all_state__[6] : angle de
l’hélicoptère
all_state__[7] : angle de l’hélicoptère
all_state__[8] : angle 4
de
l’hélicoptère
all_state__[11] : angle du rotor
all_state__[12] : angle du rotor
all_state__[30] : position x de
l’hélicoptère
all_state__[31] : position y de
l’hélicoptère
all_state__[32] : position z de
l’hélicoptère
all_state__[33] : angle de la caméra
all_state__[34] : angle de la caméra
4
: “Psi”

11. MOTEUR DE RENDU GRAPHIQUE
11.1 FRAMEWORK OBJETS
11.1.1 POURQUOI UN FRAMEWORK D’OBJETS ?
Le framework d’objets a été conçu dans le but de simplifier et d’uniformiser l’affichage des objets 3D
et également de rendre possible l’optimisation de rendu de scène. Ce framework définit:
• une classe de base représentant une entité 3D ;
• des interfaces représentant les capacités d’une entité 3D.
Grâce à une représentation de ce genre, nous pouvons afficher un objet 3D, définir ses propriétés,
charger/décharger le contenu graphique ou le mettre à jour. Tout cela se fait très rapidement et est
pris en charge par le moteur de rendu. Voir § 11.4 below pour plus d’information sur cette prise en charge.
Voici un schéma des interfaces et d’objets de base avec les propriétés et méthodes contenues :
Figure 13 - Framework d'objets, schéma global

11.1.2 L’OBJET DE BASE
L’objet de base (la classe CObject) représentant une entité 3D possède 4 propriétés principales:
Propriété Description
Vector3 Position Une position en 3D (un point) permettant de positionner l’objet
simplement en définissant ses coordonnées.
Vector3 Scaling L’étirement de cet objet permettant de l’agrandir ou diminuer.
Représenté par une coordonnée de proportions sur chaque axe.
Quaternion Rotation Un quaternion de rotation définissant les rotations sur les axes X, Y
et Z de l’objet.
bool Visible Une propriété permettant de voir si l’objet est visible ou pas, donc
doit ou pas être affiché.
Cet objet de base implémente une fonction Draw() unique, qui analyse les interfaces implémentées
et exécute les méthodes nécessaires pour effectuer le rendu avec la prise en charge du framework
des shaders objet intégré.
public void Draw(CRenderContext _RenderContext)
{
if (this is IChildRenderer)
((IChildRenderer)this).RenderChildren(_RenderContext);
if (this is IRenderable)
{
CShader objShader = CShaderManager.Instance.GetShader(m_Shader);
if (objShader != null)
{
objShader.SetParameters(this,_RenderContext);
objShader.Effect.Begin();
foreach (EffectPass pass in objShader.Effect.CurrentTechnique.Passes)
{
pass.Begin();
((IRenderable)this).Render(_RenderContext);
pass.End();
}
objShader.Effect.End();
}
}
}

11.1.3 LES INTERFACES
Notre framework définit plusieurs interfaces que l’objet peut ou pas implémenter. Chacune de ses
interfaces est également un « flag logique » permettant de créer les différents objets. On peut créer
un objet qui n’a pas de contenu graphique ou même un objet qui ne sera pas affiché du tout (objet
de mise à jour).
• IRenderable, une interface qui définit une méthode Render(). Cette interface permet au
moteur de rendu graphique de comprendre que l’objet est « Affichable » et l’afficher en
exécutant la méthode implémentée ;
• IUpdateable, une interface qui définit une méthode Update(). Cette interface permet au
moteur de rendu graphique de comprendre que l’objet peut être mis à jour par sa méthode
implémentée ;
• IChildRenderer, une interface définissant une méthode RenderChildren(), l’exécution de
cette méthode ressemble à celle de IRenderable, mais le shader d’objet n’est pas pris en
compte. Il est sous-entendu que l’objet implémentant l’interface est un container d’objets
graphiques ;
• ILoadable, une interface définissant deux méthodes : LoadGraphicsContent() et
UnloadGraphicsContent(). Cette interface permet au moteur de rendu de charger/décharger
le contenu graphique de l’objet. Ex : le chargement des textures, modèles 3D, etc.

11.1.4 L’UTILISATION
Le framework objet a été largement utilisé pendant le projet pour créer une variété d’objets utilisés
dans le simulateur, dont les plus importants sont :
• la classe CMobile, représentant une entité 3D avec la possibilité de se déplacer dans le
monde ;
• la classe CHelicopter, dérivée de CMobile. Elle est la représentation de l’hélicoptère et prend
en charge des contrôleurs et d’autres propriétés spécifiques à l’hélicoptère ;
• la classe CGrid, représentant une grille. Elle permet de s’orienter dans l’espace.

11.2 CAMÉRA
11.2.1 INTRODUCTION
Le composant caméra est en réalité la vue de l’utilisateur dans le monde 3D. Plusieurs caméras ou
vues sont possibles. Par exemple, il y a la vue en mode FirstPerson ou en mode ThirdPerson. La
première est en réalité la vue à l’intérieur de l’hélicoptère, c’est-à-dire ce qu’il filme. La deuxième est
une vue extérieure où l’on suit l’hélicoptère, on est à la place du pilote.
11.2.2 NOTIONS D’UNE CAMÉRA
Pour bien comprendre la notion de caméra, nous devons connaitres les propriétés de celle-ci. Dans le
schéma ci-dessous les principales propriétés d’une caméra ont été reprises et dans le tableau qui suit
une explication plus détaillée est fournie.
Figure 14 - Caméra

Nous avons implémenté la notion de caméra sous forme d’un objet CCamera, facilement
configurable grâce à ses propriétés, les voici :
Propriétés Descriptions
Vector3 Position Position de la caméra définie dans l’espace 3D
par trois coordonnées x, y et z.
BoundingFrustum Frustum Le frustum est l’espace 3D visible par la caméra,
il est compris entre le plan visible le plus proche
et le plan visible le plus lointain.
Vector3 UpVector L’axe pour la hauteur de la caméra
Vector3 Target Le point que la caméra va fixer.
float NearVision La vision minimale de la caméra en terme de
distance.
float FarVision La vision maximale de la caméra en terme de
distance.
int ScreenHeight La hauteur de l’écran en pixel (h sur le schéma).
int ScreenWidth La largeur de l’écran en pixel (w sur le schéma).
float AspectRatio Proportion de la largeur sur la hauteur de
l’écran. Cela permet d'éviter de voir les objets
affinés ou grossis si la taille de la zone
d'affichage n'est pas carrée.

Autres propriétés de la caméra :
Propriétés Description
ECameraState Mode Mode de la caméra : FirstPerson, ThirdPerson,
FreeFloating, …
Quaternion Rotation Quaternion utilisé pour effectuer une rotation
de la caméra. Un quaternion contient un axe et
un angle. On effectue donc une rotation d’un
certain angle sur un axe.
Viewport Viewport Définit les dimensions de la fenêtre de notre
écran (2D) sur laquelle notre monde virtuel (3D)
va être dessiné.
float FieldOfView Angle d’ouverture de la caméra.
Matrix View Matrice de vue de la caméra. Elle permet de
calculer les points qui sont visibles par la
caméra.
Matrix Projection Matrice de projection de la caméra. C’est la
projection de l’image sur l’écran, on passe bien
d’un monde 3D (View) à un monde 2D
(projection).

11.2.3 MÉTHODES PRINCIPALES
Notre caméra doit pouvoir changer de position et être tournée, comme une caméra réelle. Elle peut
donc bouger sur les axes x, y et z et être tournée sur ces mêmes axes d’un angle donné.
Tout d’abord, notre caméra doit pouvoir bouger dans l’espace. On parle de translation.
public void Translate(Vector3 distance)
{
m_Position +=
Vector3.Transform(distance,Matrix.CreateFromQuaternion(m_Rotation));
}
Ensuite, la caméra doit être tournée. On parle d’une rotation de caméra. Cette rotation est
représentée par un quaternion, une notion mathématique souvent utilisée dans les moteur 3D.
public void Rotate(Vector3 axis, float angle)
{
axis = Vector3.Transform(axis, Matrix.CreateFromQuaternion(m_Rotation));
m_Rotation = Quaternion.Normalize(Quaternion.CreateFromAxisAngle(axis,
angle) * m_Rotation);
}
Et finalement, une caméra doit pouvoir « orbiter » autour d’une cible. Cette fonctionnalité est
représentée par la méthode Revolve(). La caméra tourne sur un axe donné suivant un angle donné et
la cible (représentée par la propriété Target).
public void Revolve(Vector3 axis, float angle)
{
Vector3 revolveAxis = Vector3.Transform(axis,
Matrix.CreateFromQuaternion(m_Rotation));
Quaternion rotate = Quaternion.CreateFromAxisAngle(revolveAxis, angle);
m_Position = Vector3.Transform(m_Target - m_Position,
Matrix.CreateFromQuaternion(rotate)) + m_Target;
Rotate(axis, angle);
}

11.2.4 DÉPLACEMENT
Une caméra doit pouvoir être déplacée dans notre monde 3D. Cette caméra est donc mise à jour à
chaque frame. La position de la caméra et donc ce qu’elle voit (les matrices View et Projection) est
mis à jour tout le temps.
La fonction qui effectue cette mise à jour :
public virtual void Update()
{
if (mode == ECameraState.FreeFloating) //(1)
{
//Translate the camera with the target
if (!m_Target.Equals(m_OldTarget))
{
m_Position.X += (m_Target.X - m_OldTarget.X);
m_Position.Y += (m_Target.Y - m_OldTarget.Y);
m_Position.Z += (m_Target.Z - m_OldTarget.Z); //(2)
m_OldTarget = m_Target;
}
m_View = Matrix.Invert(Matrix.CreateFromQuaternion(m_Rotation) *
Matrix.CreateTranslation(m_Position)); //(3)
}
else if (mode == ECameraState.FirstPerson)
{
m_View = Matrix.CreateLookAt(m_Position, m_Target, m_UpVector);
m_Rotation =
Quaternion.CreateFromRotationMatrix(Matrix.Invert(m_View));
}
else if (mode == ECameraState.FixedFollow)
{
m_View = Matrix.CreateLookAt(m_Position, m_Target, Vector3.Up);
m_Rotation =
Quaternion.CreateFromRotationMatrix(Matrix.Invert(m_View));
}
else
{
m_View = Matrix.Invert(Matrix.CreateFromQuaternion(m_Rotation) *
Matrix.CreateTranslation(m_Position));
}
m_Projection = Matrix.CreatePerspectiveFieldOfView(
m_FieldOfView, m_AspectRatio, m_Viewport.MinDepth,
m_Viewport.MaxDepth); //(4)
m_Frustum = new BoundingFrustum(Matrix.Multiply(m_View, m_Projection));
}
(1) On fait une vérification sur le mode de la caméra (le plus utilisé est le mode FreeFloating,
permettant à la caméra de suivre une cible tout en permettant d’orbiter autour).
(2) Pour chaque mode diffèrent, on effectue la mise à jour différemment. Dans le cas de
FreeFloating, on fait suivre la cible par la caméra en modifiant la position de la caméra.
(3) Ensuite, il est possible pour chaque mode de créer la matrice de vue.

(4) Finalement, la matrice de projection et le frustum de la caméra sont créés.

B.Sc Thesis: Moteur 3D en XNA pour un simulateur de vol

B.Sc Thesis: Moteur 3D en XNA pour un simulateur de vol

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (16)

Destacado

Destacado (9)

Similar a B.Sc Thesis: Moteur 3D en XNA pour un simulateur de vol

Similar a B.Sc Thesis: Moteur 3D en XNA pour un simulateur de vol (20)

Más de Roman Atachiants

Más de Roman Atachiants (7)

Último

Último (20)

B.Sc Thesis: Moteur 3D en XNA pour un simulateur de vol