FlightGear

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
FlightGear
image

Concepteur Curt Olson

Début du projet 1996
Licence Licence libre : GNU GPL
Version 3.0 (17 février 2014)[1]
Genre Simulation de vol
Mode de jeu Un joueur / Multijoueurs
Plate-forme GNU/Linux, Windows, BSD, SGI IRIX, Solaris, Mac OS
Média téléchargeable (gratuit) / CD (payant)
Langue anglais

FlightGear Flight Simulator, souvent abrégé FlightGear ou FGFS est un jeu vidéo libre de simulation de vol, gratuit, open-source et multiplate-forme développée par le projet FlightGear. Principalement écrit dans le langage de programmation C++, FlightGear est, tout comme Fly! Legacy, un simulateur de vol dont les sources sont libres.

Fonctionnalités[modifier | modifier le code]

Le projet est en premier lieu destiné à la simulation de vol civil. Il doit être approprié pour simuler l'aviation générale (les aéronefs légers, comprenant avions légers, ULM) aussi bien que l'aviation civile (le transport et l'aviation de ligne), mais il comporte également des aéronefs de secours (hélicoptères, canadair) et des aéronefs militaires (chasseurs, bombardiers, multirôles, hélicoptères de combat) et des porte-avions pour s’entraîner à l’atterrissage et décollage depuis ceux-ci. Un scénario nommé 'bombable' est présent pour simuler des combats avec armes. Il y a aussi des aéronefs plus fantaisistes ; OVNI (nommé UFO), utilisé pour ajouter des éléments dans le paysage, mais aussi avion en papier, traîneau du Père Noël et quelques véhicules terrestres comme la Deux chevaux. Il est possible d'ajouter ses propres aéronefs, moyennant quelques connaissances techniques.

Le paysage comprend l'ensemble de la planète avec des détails plus ou moins élevés selon les régions. Paris est la ville la plus détaillée avec une grande partie du centre ville et de ses monuments. Il comporte également les plus grands aéroports et de nombreux aérodromes. Certains détails de grandes villes du monde comme New York, Berlin, Tokyo, Séoul, Shanghai ou encore Hong Kong sont également présents. Par défaut, le décollage est situé à l'aéroport international de San Francisco. Depuis la version 2.4.0, il est possible de mettre automatiquement à jour le scénario pendant le vol au dessus d'une zone, grâce à l'utilisation d’Apache Subversion pour le téléchargement des scènes. La majorité des grands aéroports sont inclus et peuvent être trouvés grâce à leur nom ou leur Code OACI.

Le simulateur supporte les interfaces des simulateurs de vol courants (palonnier, pédales, manettes de poussée, etc.) et l'utilisation de plusieurs écrans pour une vue panoramique de la simulation. Quelques outils existent sur le système Android, pour gérer des éléments de tableau de bord depuis une tablette ou un smartphone par exemple.

Il est possible de bénéficier de la prise en charge de plusieurs processeurs ou cœurs en modifiant le fichier de configuration de la simulation preferences.xml, que ce soit une thread par écran de sortie ou plusieurs threads en parallèle pour les calculs.

Les échanges radio (informations météo, état du trafic) sont simulés avec les aéroports ainsi que les balises de repérages aérien radio.

La météo peut être récupérée depuis les stations météo réelles et intégrée à la simulation, c'est le réglage par défaut. Les intempéries et leurs effets sur la navigation sont alors intégrés à la simulation, mais il est également possible de forcer un climat.

Si par défaut le simulateur simule les conditions de l'heure réelle (jour/nuit, saisons), il est également possible de modifier ces paramètres en les forçant.

Le logiciel offre la possibilité d'utiliser le scénario à plusieurs en réseau et de simuler ainsi les contraintes d'encombrement des aéroports et du ciel. Une interface tour de contrôle à également été crée pour simuler à plusieurs les échanges entre tour de contrôle et aéronefs.

Le logiciel est actuellement utilisable sous Windows (95, 98, ME, NT, 2000, XP, Vista et 7), GNU/Linux (toutes plates-formes et distributions), BSD, IRIX, Solaris, et Mac OS X. Un port en OpenGL ES à destination d'Android est également en cours.

Améliorations participatives[modifier | modifier le code]

simulation volumétrique des nuages et survol de San-Francisco.

Les formats de scènes et d'avions, les variables internes, etc. sont accessibles aux utilisateurs et documentés depuis le début. Le but des développeurs est de construire un moteur de base dans lequel les développeurs de scènes, les ingénieurs de tableaux de bord, peut-être les auteurs d'aventures ou de routines ATC, les artistes du son et les autres puissent faire des ajouts.

Historique[modifier | modifier le code]

Le projet a démarré d'une discussion entre des internautes en 1996, d'où est sortie une proposition écrite par David Murr (qui, plus tard, abandonne le projet). La proposition originale est encore disponible sur le site Web de FlightGear et peut être trouvée à http://www.flightgear.org/proposal-3.0.1

La programmation a démarré à l'été 1996 et à la fin de cette année, les routines graphiques essentielles étaient écrites. À cette époque, la programmation a été principalement effectuée et coordonnée par Eric Korpela de l'université de Californie à Berkeley. Très tôt, le code a tourné sous Linux aussi bien que sous DOS, OS/2, Windows 95/NT et Sun-OS, ce qui nécessitait, entre autres, d'écrire toutes les routines graphiques indépendantes du système entièrement à partir de rien. Le développement s'est ralenti puis a finalement stoppé au début de 1997 quand Eric a fini sa thèse. À ce moment, le projet sembla mort et le nombre de messages sur la liste de discussion fut proche de 0.

Ce fut Curt Olson de l'Université du Minnesota qui a relancé le projet dans le milieu de 1997. Son idée était d'intégrer du logiciel existant dans FlightGear. Il existait plusieurs simulateurs de vol libres disponibles sur station de travail sous différents systèmes Unix. Un d'entre eux, LaRCsim (développé par Bruce Jackson de la NASA), semblait être parfait dans cette approche. Curt prit celui-ci à part et réécrit plusieurs routines afin qu'il puisse être construit et exécuté sur les plates-formes cibles prévues. L'idée-clé était d'exploiter une plate-forme graphique indépendante du système : OpenGL.

En outre, une décision astucieuse pour la sélection des données de la scène de base a été prise dans les toutes premières versions. La scène de FlightGear est créée sur une base de données satellites publiée par la US Geological Survey. Ces données de terrains sont disponibles pour le monde entier sur l'Internet librement (http://edcwww.cr.usgs.gov/doc/edchome/ndcdb/ndcdb.html pour les États-Unis, et à http://edcwww.cr.usgs.gov/landdaac/gtopo30/gtopo30.html), pour les autres pays. Ces données gratuites, en conjonction avec les outils de fabrication de scènes inclus dans FlightGear, sont une fonctionalité importante permettant à quiconque de créer sa propre scène.

Navigation aux instruments, de nuit.

Ce nouveau code de FlightGear — encore largement basé sur le code original de LaRCsim — a été livré en juillet 1997.

Il y eut des étapes importantes dans l'histoire plus récente du développement :

  • L'affichage du soleil, de la lune et des étoiles est une possibilité dans laquelle les simulateurs pour PC sont notoirement faibles depuis des années. C'est une des grandes réussites de FlightGear que d'inclure un modèle exact et l'affichage du soleil, de la lune et des planètes. Le code correspondant a été ajouté en automne 1997 par Durk Talsma.
  • Les textures ont été ajoutées par Curt Olson au printemps 1998. Cela a marqué une amélioration significative en termes de réalisme. Microsoft Flight Simulator avait des scènes non texturées jusqu'à la version 4.0. Quelques textures de haute qualité ont été fournies par Eric Mitchell pour le projet FlightGear.
  • Un affichage tête haute (head up display - HUD) a été ajouté, basé sur le code de Michele America et Charlie Hotchkiss en automne 1997 et a été amélioré par Norman Vine. Bien qu'il ne soit habituellement pas disponible dans la réalité pour le Cessna 172, le HUD est pratique pour afficher des informations sur la simulation en cours. Cependant, les instruments se comportent comme dans l'avion réel (y compris avec leurs erreurs) et cela peut être très déstabilisant pour un apprenti pilote ou un développeur.
  • Après avoir amélioré la scène et les textures et ajouté quelques autres possibilités, la fréquence image (« frame rate ») a chuté au point de rendre FlightGear involable au printemps 1998. La solution a été d'utiliser la partie matérielle des cartes OpenGL, qui devint disponible à cette date ; de programmer le « View Frustum Culling » (une technique de visualisation qui ignore la partie non visible de la scène), grâce au travail de Curt Olson. Ces mesures ont rendu FlightGear utilisable de nouveau - même sur des machines peu puissantes - à condition qu'une carte graphique 3D avec le support de l’accélération matérielle OpenGL soit dans l'ordinateur utilisé. Avec égard pour la fréquence d'images : on doit garder à l'esprit que le code, à présent, n'est en aucune façon optimisé, ce qui laisse la possibilité d'améliorations dans le futur.
  • Un auto-pilote rudimentaire (maintien du cap) a été la contribution de Jeff Goeke-Smith en avril 1998. Il a été amélioré avec l'ajout du maintien de l'altitude et d'un « terrain following switch », en octobre 1998.
  • Les bases d'un système de menu a été apporté par la bibliothèque portable PLIB de Steve Baker en juin 1998. Après avoir été inutilisé un temps, les premiers menus furent actifs au printemps 1999.

PLIB a alors subi un rapide développement. Elle a été distribuée par Steve dans un paquet séparé avec l'idée d'être utile à d'autres applications depuis le printemps 1999. Elle fournit les bases d'un moteur de rendu graphique pour FlightGear depuis l'automne 1999.

  • Friedemann Reinhard a développé tôt le code d'un tableau de bord, qui a été disponible en juin 1998. Le développement de ce tableau s'est arrêté ensuite, en partie à cause de problèmes de compatibilité avec OpenGL. Finalement, David Megginson a décidé de repartir de zéro en janvier 2000, le résultat étant que le tableau est maintenant de nouveau en développement rapide.
  • En 1998 il y eut le support audio de base, c'est-à-dire une bibliothèque (de routines) et quelques sons de moteurs. Ce fut la contribution de Steve Baker et ce fut ensuite intégré dans sa déjà mentionnée bibliothèque portable, PLIB. Cette même bibliothèque a été étendue pour supporter les poignées de jeu, volants, palonniers en octobre 1999, ce qui a encore marqué une étape importante dans le réalisme.

La scène a été améliorée en ajoutant des repères géographiques comme les lacs, rivières et côtes au printemps 1999.

  • Le code pour la gestion en réseau / multijoueurs a été intégré par Oliver Delise et Curt Olson au début de l'automne 1999. Cet effort a permis à FlightGear de fonctionner simultanément sur plusieurs machines à travers un réseau local, en intranet ou sur Internet ; couplé à un planificateur de vol tournant sur une seconde machine, et plus.
  • Christian Mayer et Durk Talsma, ont ajouté la gestion de la météo durant l'hiver 1999. Ce module météorologique gère les nuages, les vents et même les orages.
  • Changer manuellement les vues dans un simulateur de vol est dans un certain sens toujours « irréel » mais néanmoins requis dans certaines situations. Une solution possible a été fournie par Norman Vine en hiver 1999. Norman a écrit le code pour changer de vue avec la souris.
  • Finalement, le « Navion » du LaRCsim a été remplacé comme avion par défaut par le Cessna 172, quand celui-ci devint assez stable en février 2000 - un changement bienvenu pour la plupart des utilisateurs. Il y a maintenant plusieurs options de modèles de vol à choisir à l'exécution : un Cessna 172 avec le LaRCsim modifié et amélioré développé par Tony Peden, le X15 de Jon Berndt, et le ballon à air chaud de Christian Mayer. Jon Berndt a investi beaucoup de temps dans un modèle de vol plus réaliste et plus souple, avec une méthode de configuration des avions plus puissante. « JSBSim », comme il allait être appelé, peut éventuellement remplacer LaRCsim comme modèle de vol dynamique (FDM - Flight Dynamics Model) et il est prévu d'y ajouter quelques fonctionnalités comme les effets de clapotage (NDT ?) du fuel, la turbulence, un système de contrôle de vol complet, et d'autres choses peu souvent trouvées ensemble dans un simulateur de vol.

Pendant le développement, il y a eu plusieurs efforts de réorganisation du code. Des sous-systèmes de codes variés ont été mis en paquets. Actuellement, le code est organisé ainsi :

L'utilisateur doit avoir une carte vidéo 3D -- de préférence une avec gestion matérielle d'OpenGL. Basé sur OpenGL, La bibliothèque portable PLIB de Steve Baker fournit les routines de base du rendu graphique, de la gestion du son, des poignées de jeu, etc. SimGear, également basé sur PLIb, inclut toutes les routines de base requises pour la simulation du vol aussi bien que pour la construction de la scène via la bibliothèque OpenSceneGraph. Au-dessus de SimGear il y a (i) FlightGear (le simulateur lui-même), et (ii) TerraGear, qui comprend les outils de construction de scènes.

Depuis l'été 1999 FlightGear a été divisé en une branche stable et une autre de développement. Chaque numéro de version comme 0.6, 0.8, et 1.0 fait référence à des versions stables, tandis que les numéros impairs 0.7, 0.9, et ainsi de suite font référence à des versions de développement. La ligne de conduite est de ne faire que des résolutions de bogues dans les versions paires, alors que les nouvelles fonctionnalités sont généralement ajoutées dans les versions impaires qui, quand tout est stabilisé, deviennent la prochaine version stable avec un numéro calculé en ajoutant 0.1.

Ce n'est certainement pas une histoire complète et certaines personnes qui ont fait des contributions importantes n'ont probablement pas été citées. Excepté les contributions déjà nommées il y a eu un travail important concernant la structure interne effectué par : Steve Baker, Jon S.Berndt, Oliver Delise, Christian Mayer, Curt Olson, Tony Peden, Gary R. Van Sickle, Norman Vine, et les autres. Une liste plus complète des participants peut être trouvée dans le manuel, et également dans le fichier Thanks fourni avec le code. Le site web de FlightGear contient aussi une histoire détaillée de tous les développements notables à http://www.flightgear.org/#news/

À noter l'arrivée courant novembre 2004 d'une traduction japonaise et française du site officiel, venant rejoindre, avec la communauté allemande, la communauté internationale de ce simulateur de vol.

Logiciel[modifier | modifier le code]

Le cockpit 3D en 2008

Le moteur de simulation est SimGear. Il est utilisé autant pour des applications finales qu'en environnement de recherche, que pour le développement de simulations de vol.

Cette polyvalence de Flightgear est parfaitement illustrée par la grande variété d'aéronefs disponibles, allant du planeur à l'hélicoptère, en passant par les avions de ligne et les chasseurs. Ces aéronefs ont pour origine la communauté FlightGear.

Actuellement, seul un moteur de rendu de terrain est disponible : TerraGear. Les effets météo incluent les nuages 3D, les éclairs pendant les orages et l'heure courante. Il est possible d'avoir la météo en temps réel grâce aux données METAR.

Modèles de vol dynamique[modifier | modifier le code]

Le modèle de vol est la manière dont est simulé un aéronef dans le programme. FlightGear peut utiliser plusieurs modèles de vol parmi les trois disponibles à l'heure actuelle et chaque aéronef doit être programmé spécifiquement pour un de ces modèles.

Les premières versions utilisaient un modèle appelé LaRCsim, développé par la NASA, qui fut plus tard remplacé par des modèles plus flexibles :

  • JSBSim - Le modèle par défaut depuis 2000. Un modèle de vol JSBSim contient toutes les données aérodynamiques de l'avion qui définissent son comportement, telles que les coefficients de portance et de traînée, les modifications de portance/traînée dues aux ailerons, volets, à l'effet de sol...
  • YASim - Un autre modèle utilisant des algorithmes différents et disponible depuis 2002 dans la version 0.7.9. Ce modèle de vol fonctionne différemment: il contient la forme de l'avion (position du fuselage, des ailes, des gouvernes, etc) et simule le comportement de l'avion à partir de ces données.
  • UIUC - Un autre modèle, développé par l'UIUC Applied Aerodynamics Group de l'université de l'Illinois à Urbana-Champaign, qui utilisait LaRCsim.

Notes et références[modifier | modifier le code]

Annexes[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]

Sur les autres projets Wikimedia :