FlightGear

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 Citroën 2 CV. 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 a é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. Une version de flightgear sort tous les 6 mois (le 17 février et le 17 aout ).

Améliorations participatives

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.

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 relança 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[1]. Ces données gratuites, en conjonction avec les outils de fabrication de scènes inclus dans FlightGear, sont une fonctionnalité 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 d'utiliser une carte graphique 3D avec le support de l’accélération matérielle OpenGL. 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és 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 ensuite intégrée 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.

• En septembre 1998 Curt Olson a réussi à créer un modèle de terrain complet pour les États-Unis. La scène est disponible pour tous en cliquant sur une carte à http://www.flightgear.org/Downloads/scenery.html

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 fioul, 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 eut 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 eut 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 d'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.

Le cockpit 3D de l'A-10 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. Le moteur de rendu est d'organisation est OpenSceneGraph, auquel sont ajoutés des effets spécifiques à FlightGear (dont des shaders).

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 privés, avions de ligne et les chasseurs, bombardiers et multirôles ou la navette spatiale. Ces aéronefs ont pour origine la communauté FlightGear. Il existe également un OVNI (appelé ufo), permettant de se déplacer à volonté et facilement autour de la planète, un char du Père Noël, une 2 CV et quelques vaisseaux spatiaux de séries de science-fiction.

Actuellement, seul un moteur de rendu de terrain est disponible : TerraGear, comportant différents modules et évoluant avec le temps. Il est possible d'y plaquer des photos satellites, moyennant quelques ajouts, il gère l'inclusion de bâtiments depuis les OpenStreetMap, en 2018, Hawaii était ainsi inclus par défaut avec ces bâtiments, et début 2020, une partie de l'Islande. Par défaut, si activé, TerraGear utilise TerraSync pour récupérer le scénario planétaire depuis les serveurs, via Internet. Il récupère une zone, au moment où l'aéronef va y pénétrer et les conserve sur disque dur. Il est possible d'ajouter des scénarios de différentes parties de la planète affinés par certains contributeurs. Ou d’améliorer le scénario via les outils du site du logiciel.

Le scénario comporte une majorité des grands aéroports de la planète et de nombreux aérodromes, basé sur les données en développement collaboratif, utilisé avec le simulateur X-Plane. Un porte avion est également disponible, qu'il est possible, depuis Flightgear 2020.1, de placer à l'endroit désiré[2].

La simulation météorologiques incluent les nuages 3D, les éclairs pendant les orages, des trombes d'eau, la brume, le brouillard, les effets d'illumination du soleil en fonction des conditions météo, et du lever ou coucher. Le rendu tient compte par défaut de l'heure courante et de la météo courante, à l'endroit où se situe l'aéronef, grâce aux données METAR, mais il est possible de désactiver ces données ou de forcer une heure ou un climat différent.

• 
  Coucher de soleil sur l'aéroport de Caracas (v3.7, 2015)
• 
  brume au dessus des montagnes de Lago di Guardia, données topographiques de Corine land cover

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 est 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.

La carte du logiciel est par défaut celle de la Terre, qui est modélisée dans sa totalité, avec des précisions plus ou moins élevées. Elle utilise une construction collaborative, via à la fois les données d'OpenStreetMap, ainsi que la modélisation des infrastructures terrestres et l'affinement des reliefs et textures du terrain par ses utilisateurs.

Les données disponibles sous licence libre, d’élévation de terrain, basées sur des données satellitaires, SRTM, GSHHS, ainsi que pour l'Europe, avec une précision accrue, Corine Land Cover, sont également utilisées.

Les aéroports utilisent les données agglomérées dans la base de X-Plane par ses utilisateurs et sous licence libre, pour les pistes et les taxiway. Les bâtiments des aéroports sont par contre modélisés par les utilisateurs de FlighGear.

OpenStreetMap est principalement utilisé pour la modélisation des routes, cours d'eau, et la distinction des différentes zones (forêts, déserts, villes, villages, champs, etc.). OSM2City, un système de génération automatique des infrastructures en volume (bâtiments, phares, éoliennes, etc.) existe également depuis 2017, mais il n'est pour le moment utilisé que pour des scénarios créés par des utilisateurs et non pas dans la carte standard de base. Il est possible de mixer les deux, en précisant le chemin de ces scénarios au démarrage de FlightGear[3].

Un système de génération de la surface de la terre se base sur ces différents éléments, et est mis à jour à intervalle irrégulier, en fonction de ses améliorations et d'arrivée de nouvelles données dans les sources.

L'ensemble du terrain de la planète peut être chargé dynamiquement pendant le jeu, grâce au système Terrasync créé pour ce simulateur.

• (en) Perry (2004). « The FlightGear Flight Simulator » .