<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.flightgear.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Sahliyoussef</id>
	<title>FlightGear wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.flightgear.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Sahliyoussef"/>
	<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/Special:Contributions/Sahliyoussef"/>
	<updated>2026-04-08T11:36:25Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.39.6</generator>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=58072</id>
		<title>Fr/FlightGear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=58072"/>
		<updated>2013-02-19T21:12:50Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Software&lt;br /&gt;
| title                  = FlightGear&lt;br /&gt;
| logo                   = fglogosm.jpg&lt;br /&gt;
| image                  = FlightGear - 1903 Wright Flyer.jpg&lt;br /&gt;
| alt                    = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9&lt;br /&gt;
| developedby            = FlightGear Developers &amp;amp; Contributors&lt;br /&gt;
| initialrelease         = July 17, 1997&lt;br /&gt;
| latestrelease          = 2.10 (February 17, 2013)&lt;br /&gt;
| writtenin              = C++&lt;br /&gt;
| os                     = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX&lt;br /&gt;
| platform               = Cross-platform&lt;br /&gt;
| developmentstatus      = Active (1996-)&lt;br /&gt;
| type                   = Flight simulator&lt;br /&gt;
| license                = [[GNU General Public License]]&lt;br /&gt;
| website                = http://www.flightgear.org/&lt;br /&gt;
}}[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]&lt;br /&gt;
&lt;br /&gt;
'''FlightGear''' ( Souvent nommé '''Flightgear''' ou '''FGFS''') est un simulateur de vol sophistiqué, libre, et créé par des volontaires. FlightGear est distribué sous les termes de la [[GNU General Public License]]. Le logiciel est principalement codé en C++.&lt;br /&gt;
&lt;br /&gt;
Des versions de plus en plus détaillées et réalistes sont distribuées depuis le début du projet, en 1996, et dorénavant tous les six mois. &lt;br /&gt;
&lt;br /&gt;
La dernière version en date est disponible à l'adresse  [http://www.flightgear.org/download/ flightgear.org/download/], fonctionnelle sur nombre de systèmes d'exploitation dont Microsoft Windows, Mac OS X, Linux, IRIX, et Solaris.&lt;br /&gt;
&lt;br /&gt;
== Histoire ==&lt;br /&gt;
{{main article|FlightGear History}}&lt;br /&gt;
&lt;br /&gt;
Le développement de flightgear commença par un échange sur internet en 1996, contenant un code inédit de graphiques 3D. Le développement d'une version basée sur [[OpenGL]] fut menée par Curtis Olson dès 1997. Nombre de volontaires ont contribués au projet, depuis.&lt;br /&gt;
&lt;br /&gt;
FlightGear associe d'autres ressources libres, comme plusieurs modèles de vol dont JSBsim, ainsi que certaines données de paysages, concues par la NASA et disponibles gratuitement. les premières librairies fontionnelles utilisant l'Opengl pour la 3D furent réalisées en 1997.  Un développement fulgurant et professionnel de nouvelles versions pendant plusieurs années fut à l'origine de la sophistication du logiciel. Depuis 2001, L'équipe Flightgear sort de nouvelles versions &amp;quot;beta&amp;quot; régulièrement, et dès 2005, la qualité du software conduit à des critiques plus appliquées, et plus sérieuses, accompagnée par une popularité grandissante. L'année 2007 marque une symbolique sortie du développement secondaire avec la distribution de la version 1.0.0 , 10 ans après la première version en 1997.&lt;br /&gt;
&lt;br /&gt;
[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]&lt;br /&gt;
&lt;br /&gt;
En 2008, la version 1.9.0 de FlightGear introduit un majeur changement de [[PLIB]] à [[OSG]], qui causa temporairement la perte de fonctionalités comme les nuages 3D ou les ombres, tandis que les nouvelles, comme les particules, impacte sur le degré de réalisme de la simulation. &lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
&lt;br /&gt;
Le moteur de simulation dans FlightGear est appelé [[SimGear]]. Il est utile à la fois pour l'utilisateur normal et dans les milieux universitaires et de recherche, pour le developpement et la recherche d'idées sur la simulation de vol.&lt;br /&gt;
&lt;br /&gt;
La flexibité de FlightGear est illustrée par la grande quantité d'appareils, qui y sont disponibles: Nous pouvons compter plusieurs catégories, dont: [[:Category:Gliders|glider]]s,[[Helicopter]]s, [[:Category:Airliners|airliners]],[[Military aircraft|fighter jets]]. Ces modèles ont été créés par des développeurs différents.&lt;br /&gt;
&lt;br /&gt;
Les aéronefs de Flightgear utilisent un au moins des trois modèles de vols JSBSim, YAsim, ou UIUC depuis la version 0.9.10. Pour l'instant seulement un seul moteur de simulation est utilisé, TerraGear. Les effects météo (cf.[[Weather]]) sont très complexes et réalistes, de même que les effects visuels qui y sont liés: nuages 3D, effects lumineux, effects d'horizon, et heure de la journée.&lt;br /&gt;
&lt;br /&gt;
=== Flight Dynamics Models, alias...FDM ===&lt;br /&gt;
&lt;br /&gt;
Le modèle de vol [[Flight Dynamics Models]] ou (FDM) ) simule le comportement de l'avion dans une situation précise. FlightGear utilise beaucoup de scripts et de FDM codés de manière interne au programme . &lt;br /&gt;
Tout aéronef ''doit'' être programmé pour obéir à un de ces modèles de vol. Actuellement FlightGear est le seul simulateur utilisant autant de FDMs, et dont au moins trois sont créés de manière spécifique pour le logiciel.&lt;br /&gt;
Les plus anciennes versions utilisaient [[LaRCsim]], FDM créé par la NASA, mais il fut remplacé par des modèles plus flexibles. &lt;br /&gt;
&lt;br /&gt;
* [[JSBSim]] - Depuis 2000, le FDM par défaut de flightgear.&lt;br /&gt;
* [[YASim]] - Autre FDM utilisant une approche différente. Fait partie de la version 0.7.9 en 2002.&lt;br /&gt;
* [[UIUC]] - Autre FDM inclut, developpé par le ''UIUC Applied Aerodynamics Group'' à l' Université de l'Illinois à Urbana-Champaign, également partit de LaRCsim.&lt;br /&gt;
* FlightGear peut aussi être configuré pour utiliser des entrées de FDM externes, comme [[MATLAB]].&lt;br /&gt;
* D'autres FDM marginaux pour un aéronef spécifique ont été écrits, comme les appareils volants &amp;quot;plus légers que l'air&amp;quot;, tel le Zeppelin, ballon contenu dans la version de base de flightgear.&lt;br /&gt;
&lt;br /&gt;
=== FlightGear dependencies ===&lt;br /&gt;
&lt;br /&gt;
Contrairement à certains titres commerciaux, le but principal du projet est la sortie d'un code source. Pour le rendre utile, il faut le compiler sur une quelconque système d'exploitation. Les librairies utilisées par flightgear ont changées au cours du temps, et des versions. la principale est [[SimGear]], qui est le moteur de simulation necessaire à flightgear. Dans le cas de [[TerraGear]], il ne s'agit pas de secteur de dépendance, mais seulement d'un nom pour le programme de ''données de terrain'' dans le simulateur. OpenAL est utilisée pour  le son d'entrée/sortie, dont un support pour SDL (depuis 0.9.5). PLIB est utilisé pour le support matériel (driver), anciennement utilisé par le pilote son, actuellement repris par OpenAl. [[OpenGL]] est utilisé pour ses routines graphiques intégrées, et il est bon de savoir que d'autres accélérations matérielles (directX) ne sont pas prises en charge. [[OpenSceneGraph]] est aussi intégré dans FlightGear. Enfin, Simple DirectMedia Layer est une logitèque qui est utilisée pour compiler. certains de ces secteurs de dépendances varient, la plateforme utilisée faisant la différence. Les utilisateurs de FlightGear doivent à la fois compiler le code eux-même, ou trouver un tiers pour distribuer un fichier binaire.&lt;br /&gt;
&lt;br /&gt;
== Hardware ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Le matériel nécessaire pour faire tourner FlightGear est relativement faible, bien qu'il faut savoir que les cartes graphiques les plus compatibles sont de la série Nvidia . Les premières versions du simulateur avaient le support des cartes 3dfx, bien que la proportion de rencontrer ce genre de cartes a chutée de la même manière que la configuration matérielle moyenne s'est accrue.&lt;br /&gt;
&lt;br /&gt;
[[File:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]&lt;br /&gt;
&lt;br /&gt;
== Add-ons et tuning ==&lt;br /&gt;
&lt;br /&gt;
Certains programmes sont soit intégrés dans flightgear (&amp;quot;dependencies&amp;quot;),soit font une action, une opération à travers lui. Quelque uns sont intégrés dans la distribution populaire du simulateur (pour une plateforme spécifique,quelques fois) mais créées pour le projet, quand d'autres sont étrangers à Flightgear bien que supportés par la communauté. &lt;br /&gt;
&lt;br /&gt;
Un logiciel important est l'interface destinée à lancer FlightGear. A ses débuts, FlightGear ne pouvait se lancer que par l'interface DOS ([[command line]]). Cependant, ''the FlightGear Launch Control'' fut inclus dans le FGrun (''[[FG launcher]]'') depuis la version 0.9.3 en 2003. ''[[KFreeFlight]]'' est un &amp;quot;launcher/front-end&amp;quot; pour KDE. ''FGTools'' est une fenêtre alternative de lancement. ''FGKicker'' est une front-end basée GTK+ .&lt;br /&gt;
&lt;br /&gt;
D'autres projets très utiles contiennent des éditeurs de données de terrain. ''[[Atlas]]'' est un support de cartes aéronautiques pour FlightGear; ''[[Kelpie Flight Planner]]'' est un plannificateur de vol Java pour FlightGear. ''[[FlightGear Scenery Designer]]'' est un éditeur de scènes. Le ''[[World Custom Scenery Project]]'' est un projet destiné à coordiner tous les efforts effectués sur les scènes et les données de terrain. Enfin, ''[[TaxiDraw]]'' est un éditeur de pistes et taxiway, permettant un meilleur confort visuel.&lt;br /&gt;
&lt;br /&gt;
=== Aéronefs ===&lt;br /&gt;
{{Main article|Table of models}}&lt;br /&gt;
&lt;br /&gt;
FlightGear commença avec un avion inclut dans le FDM LaRCsim, le Navion, qui fut remplacé par un Cessna 170 en 2000. Le développement des trois FDM, en particulier YASim, apporta son lot de nouveaux avions: Plus de 350 aéronefs et 450 livrées uniques, sont disponibles pour la version 2.0.0, alors que seulement quelques uns sont inclus dans le package de base.&lt;br /&gt;
[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]&lt;br /&gt;
&lt;br /&gt;
=== Scènes ===&lt;br /&gt;
{{Main article|Scenery}}&lt;br /&gt;
Le monde de FlightGears ([[world scenery]]) couvre des données d'élévation et de terrain du monde entier. Les moulins à vents, les ponts et autres objets sont présents dans la base de données  ([[FlightGear Scenery Database|Scenery Database]]) .&lt;br /&gt;
Vous pouvez téléchargez le monde entier sur le site officiel de flightgear, indiqué plus haut.&lt;br /&gt;
&lt;br /&gt;
=== Mise en réseau et multi-écrans ===&lt;br /&gt;
&lt;br /&gt;
Plusieurs options de réseaux permettent une communication entre flightgear et ses instances. Un serveur multijoueurs ([[Multiplayer Howto|multiplayer]]) fut disponible pour utiliser FlightGear sur un réseau local dans un environnement à plusieurs aéronefs. Il peut être usé pour les vols en formation, ou la simulation de l' [[ATC|control tower]]. Le Multijoueurs fut bientôt élargit pour permettre aux joueurs de voler sur Internet. D'autres fonctionalitées comme la carte Google Map permettant de connaître la position  de chaque avions dans flightgear existent.&lt;br /&gt;
Plusieurs instances de FlightGear peuvent être synchronisées pour permettre un environnement multi-moniteur. Si toutes ces instances fonctionnent aux mêmes Frames per second, il est possible d'obtenir une bonne synchronisation agréable, et réaliste.&lt;br /&gt;
&lt;br /&gt;
== FlightGear code vs. binaries ==&lt;br /&gt;
&lt;br /&gt;
Les dates de la sortie du logiciel consiste à la distribution du code, et nond'un executable. Pour créer un programme efficace, il faut le compiler, ce qui requiert certaines logithèques, dont certaines sont générales, tandis que d'autres sont spécifiques au système. En revanche, puisque la tâche demande nombre de compétences informatiques pour la plupart des utilisateurs grand public, d'autres contributeurs travailleront à rendre les binaires disponibles pour une plate-forme spécifique. Les performances, dépendent de la date de la mise à jour du code. Par exemple, certains travaux plus anciens binaires marchent sur Mac OS 9, mais les nouvelles versions  nécessitent certaines versions du Mac OS.&lt;br /&gt;
&lt;br /&gt;
Par exemple, fin 2007, la dernière version du code était 0.9.11-pre1 (pre-release) et 0.9.10 (final). Toutefois, la date de distribution des fichiers binaires réels  varient considérablement. Des exemples de binaires réels disponibles un an après la sortie de la version 0.9.10 du code:&lt;br /&gt;
&lt;br /&gt;
* Win-32 has ~138 Mb package (v0.9.10) (For Windows 98, 2000, ME, 32-bit XP) &lt;br /&gt;
* Linux- pre-built packages for specific Linux distributions&lt;br /&gt;
** Slackware package (v0.9.10), Fedora Core 2,3,4 packages (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) &lt;br /&gt;
* Solaris packages either for it running on either SPARC or x86 processors.&lt;br /&gt;
** SPARC (v0.9.8),  x86 (v0.9.9) &lt;br /&gt;
* Silicon Graphics IRIX&lt;br /&gt;
** SGI binaries for (v0.9.9) &lt;br /&gt;
* Mac OS X&lt;br /&gt;
** Mac OS 10.4 (v0.9.10) &lt;br /&gt;
** Mac OS 10.3 (v0.9.9) &lt;br /&gt;
* FreeBSD has a package for(v0.9.10)&lt;br /&gt;
&lt;br /&gt;
==Applications et usages==&lt;br /&gt;
{{Main article|Professional and educational FlightGear users}}&lt;br /&gt;
FlightGear a été utilisé dans une série de projets dans le milieu universitaire et de l'industrie (y compris la NASA) ainsi que dans des simulateurs &amp;quot;maison&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Reviews ==&lt;br /&gt;
{{Main article|FlightGear Reviews}}&lt;br /&gt;
&lt;br /&gt;
== liens externes ==&lt;br /&gt;
{{Main article|Links}}&lt;br /&gt;
* [http://www.flightgear.org Official website]&lt;br /&gt;
* [http://fgfs.i-net.hu/ Community website] &lt;br /&gt;
&lt;br /&gt;
{{Appendix|all|&lt;br /&gt;
* {{cite web |url=http://www.flightgear.org/proposal-3.0.1 |title=Original FlightGear Proposal |last=Murr |first=David L. |date=11 September, 1998 }}&lt;br /&gt;
* {{cite web |url=http://en.wikipedia.org/wiki/FlightGear |title=FlightGear |publisher=Wikipedia }}&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[[de:FlightGear]]&lt;br /&gt;
[[es:FlightGear]]&lt;br /&gt;
[[nl:FlightGear]]&lt;br /&gt;
[[pt:FlightGear]]&lt;br /&gt;
[[en:FlightGear]]&lt;br /&gt;
[[Category:FlightGear| ]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55427</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55427"/>
		<updated>2012-11-01T12:33:18Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar  devrait influencer conceptuellementtrois différentes choses:&lt;br /&gt;
&lt;br /&gt;
* selection du type de tuile&lt;br /&gt;
* placement de EVs et de modèles dans la tuile&lt;br /&gt;
* continuellement varier les paramètres météo&lt;br /&gt;
&lt;br /&gt;
=== Sélection du type de tuile ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR peut déterminer le type de tuile, il faudrait trouver un algorithme qui prend le METAR depuis des stations proches, et essaye d'extraire un modèle météorologique plus global à partir de cette information. Par exemple, les différences de pression et la direction du vent peuvent être utilisées pour localiser des régions de hautes et basses pression, ainsi que la différence de température (corrigée en fonction de l'élévation) peut aider pour trouver des masses d'air froid et chaud, et sur la base de la situation météorologique la plus probable compte tenu de ces éléments d'information, le type initial de tuile ainsi que les tuiles voisines les plus probables correspondantes pourraient être choisies.&lt;br /&gt;
&lt;br /&gt;
=== Placement des EVs et des modèles dans la tuile ===&lt;br /&gt;
&lt;br /&gt;
Au moins quelques aspects des EVs et du placement des modèles, comme une base de nuages,la force des précipitations,ou le nombre de nuages peut plus ou moins être modifié directement depuis l'information METAR. Cependant, les règles des tuiles peuvent en général être en conflit avec les détails de l'info METAR, de sorte que le système météo décrit ici ne saurait pas toujours reproduite l'info METAR (par exemple, il pourrait arriver que les rapports METAR indiquent une pluie vers une aérodrome, mais que la génération de tuiles ne place pas un nuage de pluie directement au-dessus de cet endroit).&lt;br /&gt;
&lt;br /&gt;
=== METAR et variation continuelle des paramètres météo  ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR est récupérable, elle devrait être utilisée pour régler certains paramètres météo, comme (plutôt que les paramètres par défaut)la visibilité, la pression, ou la température. Pour éviter certains sauts discontinus, l'information météo devrait être interpolée linéairement dans le temps pour chaque position où un METAR est disponible. Si le METAR est mis à jour toutes les dix minutes,on peut utiliser l'information au début de chaque position des premières dix minutes de vol, puis faire de même au prochain METAR en changeant lentement la valeur ( à chaque position) dans les prochaines dix minutes, et ainsi de suite ( il ya essentiellement un décalage de dix minutes par rapport au temps réel).&lt;br /&gt;
&lt;br /&gt;
Pour interpoler dans l'espace,  un simple algorithme avec une pondération des distances peut être utilisé (d'autres solutions plus précises mais plus compliquées existent): Si la pression &amp;quot;p&amp;quot; est connue à la position &amp;quot;n&amp;quot;, de telle sorte que la pression à la position &amp;quot;i&amp;quot; est &amp;quot;p_i&amp;quot; et la distance entre l'avion et &amp;quot;i&amp;quot; est &amp;quot;d_i&amp;quot;, alors une bonne approximation de la pression locale peut être exprimée comme ceci: &lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
Cela rendrait la pression à la position &amp;quot;i&amp;quot; egale à &amp;quot;p_i&amp;quot; et conduirait à la moyenne des pressions du système si la distance de toutes les stations METAR est la même.&lt;br /&gt;
&lt;br /&gt;
== Discussions relatives ==&lt;br /&gt;
(en)&lt;br /&gt;
&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système Multijoueurs ==&lt;br /&gt;
&lt;br /&gt;
(devrait être écrit par quelqu'un qui connait les fonctions et limites du système multijoueurs)&lt;br /&gt;
&lt;br /&gt;
== Développement ==&lt;br /&gt;
&lt;br /&gt;
* Quelques utilisateurs ont affirmé avoir des problèmes en utilisant l'outil recommencer/nouveau lieu; le système de météo locale devrait enregistrer dans /sim/signals/* et se suspendre/remettre à zéro lui-même, de sorte que toutes les opérations soient correctement mises en pause. This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamiquement examiner les APIs FG/Nasal en faisant marcher le code responsable d'exceptions, peut aussi causer certaines impressions d'erreurs sur la console, cela serait une bonne idée d'exposer les variables à l'arbre de propriétés, de sorte que le système log peut quelques fois être dans de tels cas, c'est à dire en introduisant une priorité &amp;quot;nulle&amp;quot; ou &amp;quot;muette&amp;quot; : [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* L'approche &amp;quot;feature-checking&amp;quot; utilisée par &amp;quot;compat_layer.nas&amp;quot; devrait probablement être généralisée et être disponible comme un module nasal standard, ainsi que pour une utilisation par d'autres scripts, tant qu'il propose une bonne méthode pour tenir une compatibilité d'arrière-plan.&lt;br /&gt;
[http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* On pourrait introduire un autre hash/espace de nom dans le module &amp;quot;compact_layer&amp;quot; pour des solutions de contournement basées en nasal, qui sont directement critiques au niveau des performances, de sorte que l'implémentation C++ soit prioritaire.&lt;br /&gt;
* Pour certains usages, &amp;quot;threading&amp;quot; peut fournir un réel bénéfice de performances. Cependant, nous avons besoin d'assurer que le &amp;quot;threading&amp;quot; est par défaud OPTIONEL, ainsi les utilisateurs peuvent aisément vérifier si des potentiels problèmes sont reliés au threading ou non. Les &amp;quot;Worker threads&amp;quot; semblent être le meilleur moyen.&lt;br /&gt;
* Une utilisation excessive de l'arbre de propriétés pour conserver toutes sortes de variables d'état, est une source potentielle de pertes de performances. Il est souvent meilleur de directement utiliser des structures de données en Nasal. De plus, il est plus facile de faire l'usage de &amp;quot;worker threads&amp;quot; quand toutes les données sont disponibles en Nasal, d'autant plus que l'arbre de propriété ( et fondamentalement toutes les fonctions d'extension en Nasal) ne sont pas faites pour être &amp;quot;thread-safe&amp;quot;.&lt;br /&gt;
* Pour être capable d'optimiser plus encore le système, il serait bon d'intégrer quelques formes de références simples, de sorte que les utilisateurs peuvent facilement fournir les résultats [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (Nous avons parlé de cela le 9/2011, Il y a ainsi des possibilités de fournir cette information automatiquement, mais cela exigerait une modification du coeur de l'interpréteur Nasal, et probablement introduire quelques nouveaux instruments spécifiques (new instrumentation-specific) opcodes, aussi - Cela ne semble pas être une idée très populaire pour le moment.&lt;br /&gt;
&lt;br /&gt;
== Les demandes de fonctionnalités du côté C++ ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55426</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55426"/>
		<updated>2012-11-01T11:56:03Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar  devrait influencer conceptuellementtrois différentes choses:&lt;br /&gt;
&lt;br /&gt;
* selection du type de tuile&lt;br /&gt;
* placement de EVs et de modèles dans la tuile&lt;br /&gt;
* continuellement varier les paramètres météo&lt;br /&gt;
&lt;br /&gt;
=== Sélection du type de tuile ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR peut déterminer le type de tuile, il faudrait trouver un algorithme qui prend le METAR depuis des stations proches, et essaye d'extraire un modèle météorologique plus global à partir de cette information. Par exemple, les différences de pression et la direction du vent peuvent être utilisées pour localiser des régions de hautes et basses pression, ainsi que la différence de température (corrigée en fonction de l'élévation) peut aider pour trouver des masses d'air froid et chaud, et sur la base de la situation météorologique la plus probable compte tenu de ces éléments d'information, le type initial de tuile ainsi que les tuiles voisines les plus probables correspondantes pourraient être choisies.&lt;br /&gt;
&lt;br /&gt;
=== Placement des EVs et des modèles dans la tuile ===&lt;br /&gt;
&lt;br /&gt;
Au moins quelques aspects des EVs et du placement des modèles, comme une base de nuages,la force des précipitations,ou le nombre de nuages peut plus ou moins être modifié directement depuis l'information METAR. Cependant, les règles des tuiles peuvent en général être en conflit avec les détails de l'info METAR, de sorte que le système météo décrit ici ne saurait pas toujours reproduite l'info METAR (par exemple, il pourrait arriver que les rapports METAR indiquent une pluie vers une aérodrome, mais que la génération de tuiles ne place pas un nuage de pluie directement au-dessus de cet endroit).&lt;br /&gt;
&lt;br /&gt;
=== METAR et variation continuelle des paramètres météo  ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR est récupérable, elle devrait être utilisée pour régler certains paramètres météo, comme (plutôt que les paramètres par défaut)la visibilité, la pression, ou la température. Pour éviter certains sauts discontinus, l'information météo devrait être interpolée linéairement dans le temps pour chaque position où un METAR est disponible. Si le METAR est mis à jour toutes les dix minutes,on peut utiliser l'information au début de chaque position des premières dix minutes de vol, puis faire de même au prochain METAR en changeant lentement la valeur ( à chaque position) dans les prochaines dix minutes, et ainsi de suite ( il ya essentiellement un décalage de dix minutes par rapport au temps réel).&lt;br /&gt;
&lt;br /&gt;
Pour interpoler dans l'espace,  un simple algorithme avec une pondération des distances peut être utilisé (d'autres solutions plus précises mais plus compliquées existent): Si la pression &amp;quot;p&amp;quot; est connue à la position &amp;quot;n&amp;quot;, de telle sorte que la pression à la position &amp;quot;i&amp;quot; est &amp;quot;p_i&amp;quot; et la distance entre l'avion et &amp;quot;i&amp;quot; est &amp;quot;d_i&amp;quot;, alors une bonne approximation de la pression locale peut être exprimée comme ceci: &lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
Cela rendrait la pression à la position &amp;quot;i&amp;quot; egale à &amp;quot;p_i&amp;quot; et conduirait à la moyenne des pressions du système si la distance de toutes les stations METAR est la même.&lt;br /&gt;
&lt;br /&gt;
== Discussions relatives ==&lt;br /&gt;
(en)&lt;br /&gt;
&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système Multijoueurs ==&lt;br /&gt;
&lt;br /&gt;
(devrait être écrit par quelqu'un qui connait les fonctions et limites du système multijoueurs)&lt;br /&gt;
&lt;br /&gt;
== Développement ==&lt;br /&gt;
&lt;br /&gt;
* Quelques utilisateurs ont affirmé avoir des problèmes en utilisant l'outil recommencer/nouveau lieu; le système de météo locale devrait enregistrer dans /sim/signals/* et se suspendre/remettre à zéro lui-même, de sorte que toutes les opérations soient correctement mises en pause. This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamiquement examiner les APIs FG/Nasal en faisant marcher le code responsable d'exceptions, peut aussi causer certaines impressions d'erreurs sur la console, cela serait une bonne idée d'exposer les variables à l'arbre de propriétés, de sorte que le système log peut quelques fois être dans de tels cas, c'est à dire en introduisant une priorité &amp;quot;nulle&amp;quot; ou &amp;quot;muette&amp;quot; : [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* L'approche &amp;quot;feature-checking&amp;quot; utilisée par &amp;quot;compat_layer.nas&amp;quot; devrait probablement être généralisée et être disponible comme un module nasal standard, ainsi que pour une utilisation par d'autres scripts, tant qu'il propose une bonne méthode pour tenir une compatibilité d'arrière-plan.&lt;br /&gt;
[http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55424</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55424"/>
		<updated>2012-11-01T11:52:28Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar  devrait influencer conceptuellementtrois différentes choses:&lt;br /&gt;
&lt;br /&gt;
* selection du type de tuile&lt;br /&gt;
* placement de EVs et de modèles dans la tuile&lt;br /&gt;
* continuellement varier les paramètres météo&lt;br /&gt;
&lt;br /&gt;
=== Sélection du type de tuile ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR peut déterminer le type de tuile, il faudrait trouver un algorithme qui prend le METAR depuis des stations proches, et essaye d'extraire un modèle météorologique plus global à partir de cette information. Par exemple, les différences de pression et la direction du vent peuvent être utilisées pour localiser des régions de hautes et basses pression, ainsi que la différence de température (corrigée en fonction de l'élévation) peut aider pour trouver des masses d'air froid et chaud, et sur la base de la situation météorologique la plus probable compte tenu de ces éléments d'information, le type initial de tuile ainsi que les tuiles voisines les plus probables correspondantes pourraient être choisies.&lt;br /&gt;
&lt;br /&gt;
=== Placement des EVs et des modèles dans la tuile ===&lt;br /&gt;
&lt;br /&gt;
Au moins quelques aspects des EVs et du placement des modèles, comme une base de nuages,la force des précipitations,ou le nombre de nuages peut plus ou moins être modifié directement depuis l'information METAR. Cependant, les règles des tuiles peuvent en général être en conflit avec les détails de l'info METAR, de sorte que le système météo décrit ici ne saurait pas toujours reproduite l'info METAR (par exemple, il pourrait arriver que les rapports METAR indiquent une pluie vers une aérodrome, mais que la génération de tuiles ne place pas un nuage de pluie directement au-dessus de cet endroit).&lt;br /&gt;
&lt;br /&gt;
=== METAR et variation continuelle des paramètres météo  ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR est récupérable, elle devrait être utilisée pour régler certains paramètres météo, comme (plutôt que les paramètres par défaut)la visibilité, la pression, ou la température. Pour éviter certains sauts discontinus, l'information météo devrait être interpolée linéairement dans le temps pour chaque position où un METAR est disponible. Si le METAR est mis à jour toutes les dix minutes,on peut utiliser l'information au début de chaque position des premières dix minutes de vol, puis faire de même au prochain METAR en changeant lentement la valeur ( à chaque position) dans les prochaines dix minutes, et ainsi de suite ( il ya essentiellement un décalage de dix minutes par rapport au temps réel).&lt;br /&gt;
&lt;br /&gt;
Pour interpoler dans l'espace,  un simple algorithme avec une pondération des distances peut être utilisé (d'autres solutions plus précises mais plus compliquées existent): Si la pression &amp;quot;p&amp;quot; est connue à la position &amp;quot;n&amp;quot;, de telle sorte que la pression à la position &amp;quot;i&amp;quot; est &amp;quot;p_i&amp;quot; et la distance entre l'avion et &amp;quot;i&amp;quot; est &amp;quot;d_i&amp;quot;, alors une bonne approximation de la pression locale peut être exprimée comme ceci: &lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
Cela rendrait la pression à la position &amp;quot;i&amp;quot; egale à &amp;quot;p_i&amp;quot; et conduirait à la moyenne des pressions du système si la distance de toutes les stations METAR est la même.&lt;br /&gt;
&lt;br /&gt;
== Discussions relatives ==&lt;br /&gt;
(en)&lt;br /&gt;
&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système Multijoueurs ==&lt;br /&gt;
&lt;br /&gt;
(devrait être écrit par quelqu'un qui connait les fonctions et limites du système multijoueurs)&lt;br /&gt;
&lt;br /&gt;
== Développement ==&lt;br /&gt;
&lt;br /&gt;
* Quelques utilisateurs ont affirmé avoir des problèmes en utilisant l'outil recommencer/nouveau lieu; le système de météo locale devrait enregistrer dans /sim/signals/* et se suspendre/remettre à zéro lui-même, de sorte que toutes les opérations soient correctement mises en pause. This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamiquement examiner les APIs FG/Nasal en faisant marcher le code responsable d'exceptions, peut aussi causer certaines impressions d'erreurs sur la console, cela serait une bonne idée d'exposer les variables à l'arbre de propriétés, de sorte que le système log peut quelques fois être dans de tels cas, c'est à dire en introduisant une priorité &amp;quot;nulle&amp;quot; ou &amp;quot;muette&amp;quot; : [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* L'approche &amp;quot;feature-checking&amp;quot; utilisée par &amp;quot;compat_layer.nas&amp;quot; devrait probablement être généralisée et être disponible comme un module nasal standard, ainsi que pour une utilisation par d'autres scripts, tant qu'il propose une bone méthode pour tenir une compatibilité d'arrière-plan.&lt;br /&gt;
[http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55404</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55404"/>
		<updated>2012-10-30T13:50:48Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar  devrait influencer conceptuellementtrois différentes choses:&lt;br /&gt;
&lt;br /&gt;
* selection du type de tuile&lt;br /&gt;
* placement de EVs et de modèles dans la tuile&lt;br /&gt;
* continuellement varier les paramètres météo&lt;br /&gt;
&lt;br /&gt;
=== Sélection du type de tuile ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR peut déterminer le type de tuile, il faudrait trouver un algorithme qui prend le METAR depuis des stations proches, et essaye d'extraire un modèle météorologique plus global à partir de cette information. Par exemple, les différences de pression et la direction du vent peuvent être utilisées pour localiser des régions de hautes et basses pression, ainsi que la différence de température (corrigée en fonction de l'élévation) peut aider pour trouver des masses d'air froid et chaud, et sur la base de la situation météorologique la plus probable compte tenu de ces éléments d'information, le type initial de tuile ainsi que les tuiles voisines les plus probables correspondantes pourraient être choisies.&lt;br /&gt;
&lt;br /&gt;
=== Placement des EVs et des modèles dans la tuile ===&lt;br /&gt;
&lt;br /&gt;
Au moins quelques aspects des EVs et du placement des modèles, comme une base de nuages,la force des précipitations,ou le nombre de nuages peut plus ou moins être modifié directement depuis l'information METAR. Cependant, les règles des tuiles peuvent en général être en conflit avec les détails de l'info METAR, de sorte que le système météo décrit ici ne saurait pas toujours reproduite l'info METAR (par exemple, il pourrait arriver que les rapports METAR indiquent une pluie vers une aérodrome, mais que la génération de tuiles ne place pas un nuage de pluie directement au-dessus de cet endroit).&lt;br /&gt;
&lt;br /&gt;
=== METAR et variation continuelle des paramètres météo  ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR est récupérable, elle devrait être utilisée pour régler certains paramètres météo, comme (plutôt que les paramètres par défaut)la visibilité, la pression, ou la température. Pour éviter certains sauts discontinus, l'information météo devrait être interpolée linéairement dans le temps pour chaque position où un METAR est disponible. Si le METAR est mis à jour toutes les dix minutes,on peut utiliser l'information au début de chaque position des premières dix minutes de vol, puis faire de même au prochain METAR en changeant lentement la valeur ( à chaque position) dans les prochaines dix minutes, et ainsi de suite ( il ya essentiellement un décalage de dix minutes par rapport au temps réel).&lt;br /&gt;
&lt;br /&gt;
Pour interpoler dans l'espace,  un simple algorithme avec une pondération des distances peut être utilisé (d'autres solutions plus précises mais plus compliquées existent): Si la pression &amp;quot;p&amp;quot; est connue à la position &amp;quot;n&amp;quot;, de telle sorte que la pression à la position &amp;quot;i&amp;quot; est &amp;quot;p_i&amp;quot; et la distance entre l'avion et &amp;quot;i&amp;quot; est &amp;quot;d_i&amp;quot;, alors une bonne approximation de la pression locale peut être exprimée comme ceci: &lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
Cela rendrait la pression à la position &amp;quot;i&amp;quot; egale à &amp;quot;p_i&amp;quot; et conduirait à la moyenne des pressions du système si la distance de toutes les stations METAR est la même.&lt;br /&gt;
&lt;br /&gt;
== Discussions relatives ==&lt;br /&gt;
(en)&lt;br /&gt;
&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système Multijoueurs ==&lt;br /&gt;
&lt;br /&gt;
(devrait être écrit par quelqu'un qui connait les fonctions et limites du système multijoueurs)&lt;br /&gt;
&lt;br /&gt;
== Dévelopemment ==&lt;br /&gt;
&lt;br /&gt;
* Quelques utilisateurs ont affirmé avoir des problèmes en utilisant l'outil recommencer/nouveau lieu; le système de météo locale devrait enregistrer dans /sim/signals/* et se suspendre/remettre à zéro lui-même, de sorte que toutes les opérations soient correctement mises en pause. This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamiquement examiner les APIs FG/Nasal en faisant marcher le code responsable d'exceptions, peut aussi causer certaines impressions d'erreurs sur la console, cela serait une bonne idée d'exposer les variables à l'arbre de propriétés, de sorte que le système log peut quelques fois être dans de tels cas, c'est à dire en introduisant une priorité &amp;quot;nulle&amp;quot; ou &amp;quot;muette&amp;quot; : [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55181</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55181"/>
		<updated>2012-10-21T10:29:03Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar  devrait influencer conceptuellementtrois différentes choses:&lt;br /&gt;
&lt;br /&gt;
* selection du type de tuile&lt;br /&gt;
* placement de EVs et de modèles dans la tuile&lt;br /&gt;
* continuellement varier les paramètres météo&lt;br /&gt;
&lt;br /&gt;
=== Sélection du type de tuile ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR peut déterminer le type de tuile, il faudrait trouver un algorithme qui prend le METAR depuis des stations proches, et essaye d'extraire un modèle météorologique plus global à partir de cette information. Par exemple, les différences de pression et la direction du vent peuvent être utilisées pour localiser des régions de hautes et basses pression, ainsi que la différence de température (corrigée en fonction de l'élévation) peut aider pour trouver des masses d'air froid et chaud, et sur la base de la situation météorologique la plus probable compte tenu de ces éléments d'information, le type initial de tuile ainsi que les tuiles voisines les plus probables correspondantes pourraient être choisies.&lt;br /&gt;
&lt;br /&gt;
=== Placement des EVs et des modèles dans la tuile ===&lt;br /&gt;
&lt;br /&gt;
Au moins quelques aspects des EVs et du placement des modèles, comme une base de nuages,la force des précipitations,ou le nombre de nuages peut plus ou moins être modifié directement depuis l'information METAR. Cependant, les règles des tuiles peuvent en général être en conflit avec les détails de l'info METAR, de sorte que le système météo décrit ici ne saurait pas toujours reproduite l'info METAR (par exemple, il pourrait arriver que les rapports METAR indiquent une pluie vers une aérodrome, mais que la génération de tuiles ne place pas un nuage de pluie directement au-dessus de cet endroit).&lt;br /&gt;
&lt;br /&gt;
=== METAR et variation continuelle des paramètres météo  ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR est récupérable, elle devrait être utilisée pour régler certains paramètres météo, comme (plutôt que les paramètres par défaut)la visibilité, la pression, ou la température. Pour éviter certains sauts discontinus, l'information météo devrait être interpolée linéairement dans le temps pour chaque position où un METAR est disponible. Si le METAR est mis à jour toutes les dix minutes,on peut utiliser l'information au début de chaque position des premières dix minutes de vol, puis faire de même au prochain METAR en changeant lentement la valeur ( à chaque position) dans les prochaines dix minutes, et ainsi de suite ( il ya essentiellement un décalage de dix minutes par rapport au temps réel).&lt;br /&gt;
&lt;br /&gt;
Pour interpoler dans l'espace,  un simple algorithme avec une pondération des distances peut être utilisé (d'autres solutions plus précises mais plus compliquées existent): Si la pression &amp;quot;p&amp;quot; est connue à la position &amp;quot;n&amp;quot;, de telle sorte que la pression à la position &amp;quot;i&amp;quot; est &amp;quot;p_i&amp;quot; et la distance entre l'avion et &amp;quot;i&amp;quot; est &amp;quot;d_i&amp;quot;, alors une bonne approximation de la pression locale peut être exprimée comme ceci: &lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
Cela rendrait la pression à la position &amp;quot;i&amp;quot; egale à &amp;quot;p_i&amp;quot; et conduirait à la moyenne des pressions du système si la distance de toutes les stations METAR est la même.&lt;br /&gt;
&lt;br /&gt;
== Discussions relatives ==&lt;br /&gt;
(en)&lt;br /&gt;
&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système Multijoueurs ==&lt;br /&gt;
&lt;br /&gt;
(devrait être écrit par quelqu'un qui connait les fonctions et limites du système multijoueurs)&lt;br /&gt;
&lt;br /&gt;
== Dévelopemment ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55180</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55180"/>
		<updated>2012-10-21T10:27:50Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar  devrait influencer conceptuellementtrois différentes choses:&lt;br /&gt;
&lt;br /&gt;
* selection du type de tuile&lt;br /&gt;
* placement de EVs et de modèles dans la tuile&lt;br /&gt;
* continuellement varier les paramètres météo&lt;br /&gt;
&lt;br /&gt;
=== Sélection du type de tuile ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR peut déterminer le type de tuile, il faudrait trouver un algorithme qui prend le METAR depuis des stations proches, et essaye d'extraire un modèle météorologique plus global à partir de cette information. Par exemple, les différences de pression et la direction du vent peuvent être utilisées pour localiser des régions de hautes et basses pression, ainsi que la différence de température (corrigée en fonction de l'élévation) peut aider pour trouver des masses d'air froid et chaud, et sur la base de la situation météorologique la plus probable compte tenu de ces éléments d'information, le type initial de tuile ainsi que les tuiles voisines les plus probables correspondantes pourraient être choisies.&lt;br /&gt;
&lt;br /&gt;
=== Placement des EVs et des modèles dans la tuile ===&lt;br /&gt;
&lt;br /&gt;
Au moins quelques aspects des EVs et du placement des modèles, comme une base de nuages,la force des précipitations,ou le nombre de nuages peut plus ou moins être modifié directement depuis l'information METAR. Cependant, les règles des tuiles peuvent en général être en conflit avec les détails de l'info METAR, de sorte que le système météo décrit ici ne saurait pas toujours reproduite l'info METAR (par exemple, il pourrait arriver que les rapports METAR indiquent une pluie vers une aérodrome, mais que la génération de tuiles ne place pas un nuage de pluie directement au-dessus de cet endroit).&lt;br /&gt;
&lt;br /&gt;
=== METAR et variation continuelle des paramètres météo  ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR est récupérable, elle devrait être utilisée pour régler certains paramètres météo, comme (plutôt que les paramètres par défaut)la visibilité, la pression, ou la température. Pour éviter certains sauts discontinus, l'information météo devrait être interpolée linéairement dans le temps pour chaque position où un METAR est disponible. Si le METAR est mis à jour toutes les dix minutes,on peut utiliser l'information au début de chaque position des premières dix minutes de vol, puis faire de même au prochain METAR en changeant lentement la valeur ( à chaque position) dans les prochaines dix minutes, et ainsi de suite ( il ya essentiellement un décalage de dix minutes par rapport au temps réel).&lt;br /&gt;
&lt;br /&gt;
Pour interpoler dans l'espace,  un simple algorithme avec une pondération des distances peut être utilisé (d'autres solutions plus précises mais plus compliquées existent): Si la pression &amp;quot;p&amp;quot; est connue à la position &amp;quot;n&amp;quot;, de telle sorte que la pression à la position &amp;quot;i&amp;quot; est &amp;quot;p_i&amp;quot; et la distance entre l'avion et &amp;quot;i&amp;quot; est &amp;quot;d_i&amp;quot;, alors une bonne approximation de la pression locale peut être exprimée comme ceci: &lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
 Cela rendrait la pression à la position &amp;quot;i&amp;quot; egale à &amp;quot;p_i&amp;quot; et conduirait à la moyenne des pressions du système si la distance de toutes les stations METAR est la même.&lt;br /&gt;
&lt;br /&gt;
== Discussions relatives ==&lt;br /&gt;
(en)&lt;br /&gt;
&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système Multijoueurs ==&lt;br /&gt;
&lt;br /&gt;
(devrait être écrit par quelqu'un qui connait les fonctions et limites du système multijoueurs)&lt;br /&gt;
&lt;br /&gt;
== Dévelopemment ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55149</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55149"/>
		<updated>2012-10-20T18:38:20Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar  devrait influencer conceptuellementtrois différentes choses:&lt;br /&gt;
&lt;br /&gt;
* selection du type de tuile&lt;br /&gt;
* placement de EVs et de modèles dans la tuile&lt;br /&gt;
* continuellement varier les paramètres météo&lt;br /&gt;
&lt;br /&gt;
=== Sélection du type de tuile ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR peut déterminer le type de tuile, il faudrait trouver un algorithme qui prend le METAR depuis des stations proches, et essaye d'extraire un modèle météorologique plus global à partir de cette information. Par exemple, les différences de pression et la direction du vent peuvent être utilisées pour localiser des régions de hautes et basses pression, ainsi que la différence de température (corrigée en fonction de l'élévation) peut aider pour trouver des masses d'air froid et chaud, et sur la base de la situation météorologique la plus probable compte tenu de ces éléments d'information, le type initial de tuile ainsi que les tuiles voisines les plus probables correspondantes pourraient être choisies.&lt;br /&gt;
&lt;br /&gt;
=== Placement des EVs et des modèles dans la tuile ===&lt;br /&gt;
&lt;br /&gt;
Au moins quelques aspects des EVs et du placement des modèles, comme une base de nuages,la force des précipitations,ou le nombre de nuages peut plus ou moins être modifié directement depuis l'information METAR. Cependant, les règles des tuiles peuvent en général être en conflit avec les détails de l'info METAR, de sorte que le système météo décrit ici ne saurait pas toujours reproduite l'info METAR (par exemple, il pourrait arriver que les rapports METAR indiquent une pluie vers une aérodrome, mais que la génération de tuiles ne place pas un nuage de pluie directement au-dessus de cet endroit).&lt;br /&gt;
&lt;br /&gt;
=== METAR et variation continuelle des paramètres météo  ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).&lt;br /&gt;
&lt;br /&gt;
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is&lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same.&lt;br /&gt;
&lt;br /&gt;
== Related Discussions ==&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection with the Multiplayer system ==&lt;br /&gt;
&lt;br /&gt;
(should be written by someone who knows what the Multiplayer system can and cannot do)&lt;br /&gt;
&lt;br /&gt;
== Development ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/Aide:Traduire&amp;diff=55146</id>
		<title>Fr/Aide:Traduire</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/Aide:Traduire&amp;diff=55146"/>
		<updated>2012-10-20T18:23:02Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Depuis septembre 2009, le [[Main Page|Wiki FlightGear]] permet l'utilisation de plusieurs langues. Dorénavant, chaque article peut être traduit dans n'importe quelle langue, afin d'en faciliter la compréhension pour les utilisateurs non-anglophones.&lt;br /&gt;
&lt;br /&gt;
=== Nous avons besoin de vous ! ===&lt;br /&gt;
Le Wiki contenant déjà {{NUMBEROFARTICLES}} articles (certains plus petits que d'autres), cela représente beaucoup de travail de traduire toutes les pages. Quelques utilisateurs ont commencés à traduire, mais nous avons vraiment besoin d'aide et pour être plus précis : de la vôtre !&lt;br /&gt;
&lt;br /&gt;
Si nous traduisions ne serait-ce qu'un ou deux articles chacun, cela ne prendrait pas &amp;quot;si&amp;quot; longtemps pour avoir au moins les articles les plus importants comme [[Flying the helicopter]], [[FlightGear]], [[Installing Scenery]] et [[New to FlightGear]].&lt;br /&gt;
&lt;br /&gt;
=== Exemples ===&lt;br /&gt;
Pour les exemples d'articles déjà traduits allez voir [[Main Page]].&lt;br /&gt;
&lt;br /&gt;
=== Comment commencer à traduire ? ===&lt;br /&gt;
Tout d'abord, vous devez trouver un article que vous aimeriez traduire. Ensuite, dans la barre d'adresse de votre navigateur web (Safari, Firefox, Opéra...) ajoutez l'abréviation du langage désiré (allez voir [http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/languages/Names.php ici] pour la liste) suivie par une barre de fraction (/) avant le titre de l'article anglais et allez sur cette page. Par exemple si je voulais traduire l'article terrasync en français, je visiterais [[fr/TerraSync]]. Comme vous pouvez le voir cette page n'existe pas encore, donc nous sommes sûrs que personne n'a traduit cet article pour le moment.&lt;br /&gt;
&lt;br /&gt;
Maintenant, traduisons cet article. Vous pouvez laisser les liens wiki comme ils sont (ils redirigent vers l'article anglais), à moins que l'article soit traduit dans la langue de votre article. Dans ce cas, vous faites un lien wiki comme ceci : &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[[:nl:Hoofdpagina]]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;. [[:nl:Hoofdpagina]] sera montré dans l'article. Il est cependant recommandé d'utiliser&amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[[:nl:Hoofdpagina|Hoofdpagina]]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;, car il permet de ne pas faire référe&amp;quot;nce au préfixe de la langue ([[:nl:Hoofdpagina|Hoofdpagina]]).&lt;br /&gt;
&lt;br /&gt;
Tout en bas de l'article, vous devez placer les liens de langue, de manière à ce qu'il y ait une sympathique liste de sélection dans le menu. Toutes les traductions de l'article devraient être listées. Par exemple, dans l'article anglais de [[TerraSync]], nous ajoutons: &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[[nl:TerraSync]]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;. Sur l'article néerlandais, nous ajoutons &amp;lt;tt&amp;gt;&amp;lt;nowiki&amp;gt;[[en:TerraSync]]&amp;lt;/nowiki&amp;gt;&amp;lt;/tt&amp;gt;. La langue dans laquelle l'article a été rédigé peut être laissée de côté. Veuillez laisser les langues en ordre alphabétique, de manière à ce qu'il soit plus facile d'ajouter ou de supprimer des langues.&lt;br /&gt;
&lt;br /&gt;
==== Quels articles ne devraient pas être traduit ====&lt;br /&gt;
&amp;lt;u&amp;gt;'''Ne pas'''&amp;lt;/u&amp;gt; commencer à traduire des articles qui doivent '''[[:Category:afd|être détruits]]''' ou '''[[:Category:Articles to be merged|améliorés]]'''. Ces articles doivent d'abord être améliorés dans leur langue d'origine.&lt;br /&gt;
&lt;br /&gt;
'''Merci beaucoup pour vos traductions ou pour toute autre contribution que vous auriez réalisé sur le wiki ! Votre dur labeur est très apprécié par tous les utilisateurs de Flightgear !'''&lt;br /&gt;
[[de:Help:Übersetzen]]&lt;br /&gt;
[[es:Help:Traducir]]&lt;br /&gt;
[[nl:Help:Vertalen]]&lt;br /&gt;
[[fr:Help:traduire]]&lt;br /&gt;
[[en:Help:translate]]&lt;br /&gt;
[[ru:Справка:Перевод]]&lt;br /&gt;
[[pt:Help: Traduzir]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Help|Translate]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55042</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=55042"/>
		<updated>2012-10-18T17:34:20Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar  devrait influencer conceptuellementtrois différentes choses:&lt;br /&gt;
&lt;br /&gt;
* selection du type de tuile&lt;br /&gt;
* placement de EVs et de modèles dans la tuile&lt;br /&gt;
* continuellement varier les paramètres météo&lt;br /&gt;
&lt;br /&gt;
=== Sélection du type de tuile ===&lt;br /&gt;
&lt;br /&gt;
Si l'info METAR peut déterminer le type de tuile, il faudrait trouver un algorithme qui prend le METAR depuis des stations proches, et essaye d'extraire un modèle météorologique plus global à partir de cette information. Par exemple, les différences de pression et la direction du vent peuvent être utilisées pour localiser des régions de hautes et basses pression, ainsi que la différence de température (corrigée en fonction de l'élévation) peut aider pour trouver des masses d'air froid et chaud, et sur la base de la situation météorologique la plus probable compte tenu de ces éléments d'information, le type initial de tuile ainsi que les tuiles voisines les plus probables correspondantes pourraient être choisies.&lt;br /&gt;
&lt;br /&gt;
=== Placement of EVs and models inside the tile ===&lt;br /&gt;
&lt;br /&gt;
At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).&lt;br /&gt;
&lt;br /&gt;
=== METAR and continuously varying weather parameters ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).&lt;br /&gt;
&lt;br /&gt;
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is&lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same.&lt;br /&gt;
&lt;br /&gt;
== Related Discussions ==&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection with the Multiplayer system ==&lt;br /&gt;
&lt;br /&gt;
(should be written by someone who knows what the Multiplayer system can and cannot do)&lt;br /&gt;
&lt;br /&gt;
== Development ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=54976</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=54976"/>
		<updated>2012-10-17T19:43:35Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar  devrait influencer conceptuellementtrois différentes choses:&lt;br /&gt;
&lt;br /&gt;
* selection du type de tuile&lt;br /&gt;
* placement de EVs et de modèles dans la tuile&lt;br /&gt;
* continuellement varier les paramètres météo&lt;br /&gt;
&lt;br /&gt;
=== Selection of tile type ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.&lt;br /&gt;
&lt;br /&gt;
=== Placement of EVs and models inside the tile ===&lt;br /&gt;
&lt;br /&gt;
At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).&lt;br /&gt;
&lt;br /&gt;
=== METAR and continuously varying weather parameters ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).&lt;br /&gt;
&lt;br /&gt;
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is&lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same.&lt;br /&gt;
&lt;br /&gt;
== Related Discussions ==&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection with the Multiplayer system ==&lt;br /&gt;
&lt;br /&gt;
(should be written by someone who knows what the Multiplayer system can and cannot do)&lt;br /&gt;
&lt;br /&gt;
== Development ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=54790</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=54790"/>
		<updated>2012-10-10T14:54:36Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression'  près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.&lt;br /&gt;
&lt;br /&gt;
Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.&lt;br /&gt;
&lt;br /&gt;
Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuiles dès que l'on en a besoin.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection avec le système METAR ==&lt;br /&gt;
&lt;br /&gt;
Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:&lt;br /&gt;
&lt;br /&gt;
* selection of tile type&lt;br /&gt;
* placement of EVs and models inside the tile&lt;br /&gt;
* continuously varying weather parameters&lt;br /&gt;
&lt;br /&gt;
=== Selection of tile type ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.&lt;br /&gt;
&lt;br /&gt;
=== Placement of EVs and models inside the tile ===&lt;br /&gt;
&lt;br /&gt;
At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).&lt;br /&gt;
&lt;br /&gt;
=== METAR and continuously varying weather parameters ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).&lt;br /&gt;
&lt;br /&gt;
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is&lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same.&lt;br /&gt;
&lt;br /&gt;
== Related Discussions ==&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection with the Multiplayer system ==&lt;br /&gt;
&lt;br /&gt;
(should be written by someone who knows what the Multiplayer system can and cannot do)&lt;br /&gt;
&lt;br /&gt;
== Development ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=53942</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=53942"/>
		<updated>2012-09-09T10:46:13Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de &amp;quot;tuiles&amp;quot; météo (analogues aux &amp;quot;scenery tiles&amp;quot;) couvrent un région, disons, de 30x30 km environ. &lt;br /&gt;
&lt;br /&gt;
Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages ​​en couches comme l'Altostratus, mais généralement pas par un front orageux.&lt;br /&gt;
&lt;br /&gt;
Ainsi, il doit y avoir différent types de &amp;quot;tiles&amp;quot;, chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les &amp;quot;EVs&amp;quot; ou les orages).&lt;br /&gt;
&lt;br /&gt;
Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type &amp;quot; pointe d'un front chaud&amp;quot; peut avoir les règles suivantes:&lt;br /&gt;
&lt;br /&gt;
* créer vers le nord du terrain de manière aléatoire dix nuages de type &amp;quot;cirrus&amp;quot; entre 25.000 et 30.000 pieds &lt;br /&gt;
* s'assurer que les modèles sont suffisamment espacés&lt;br /&gt;
* s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)&lt;br /&gt;
* créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines. &lt;br /&gt;
&lt;br /&gt;
Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Grande échelle - règle de placement ===&lt;br /&gt;
&lt;br /&gt;
To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.&lt;br /&gt;
&lt;br /&gt;
If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simpy due to the tile placement rules mocking up the presence of real large-scale weather systems.&lt;br /&gt;
&lt;br /&gt;
Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection with the METAR system ==&lt;br /&gt;
&lt;br /&gt;
Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:&lt;br /&gt;
&lt;br /&gt;
* selection of tile type&lt;br /&gt;
* placement of EVs and models inside the tile&lt;br /&gt;
* continuously varying weather parameters&lt;br /&gt;
&lt;br /&gt;
=== Selection of tile type ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.&lt;br /&gt;
&lt;br /&gt;
=== Placement of EVs and models inside the tile ===&lt;br /&gt;
&lt;br /&gt;
At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).&lt;br /&gt;
&lt;br /&gt;
=== METAR and continuously varying weather parameters ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).&lt;br /&gt;
&lt;br /&gt;
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is&lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same.&lt;br /&gt;
&lt;br /&gt;
== Related Discussions ==&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection with the Multiplayer system ==&lt;br /&gt;
&lt;br /&gt;
(should be written by someone who knows what the Multiplayer system can and cannot do)&lt;br /&gt;
&lt;br /&gt;
== Development ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=53792</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=53792"/>
		<updated>2012-09-04T08:58:28Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== A moindre échelle - effets de volumes et conditions moyennes ===&lt;br /&gt;
&lt;br /&gt;
Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences. &lt;br /&gt;
&lt;br /&gt;
Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - '''thermiques''' et '''orages'''. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé  '''weather''' dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML. &lt;br /&gt;
&lt;br /&gt;
Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir [[Howto: Modelling clouds|modéliser des nuages]] pour la technique de création de nuages).&lt;br /&gt;
&lt;br /&gt;
A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.&lt;br /&gt;
&lt;br /&gt;
Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.&lt;br /&gt;
&lt;br /&gt;
=== Echelle moyenne - temps par &amp;quot;tuiles&amp;quot; ===&lt;br /&gt;
&lt;br /&gt;
Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) which would cover a region of, say, 30x30 km or something of that size. Inside tiles, weather is simulated explicitly in terms of EVs and 3-d models. &lt;br /&gt;
&lt;br /&gt;
As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warmfront - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front. &lt;br /&gt;
&lt;br /&gt;
Thus, there need to be different 'types' of tiles, each representing a typical snapshot of a development inside the larger system. Tile themes would be something like 'leading edge of warmfront', 'trailing edge of warmfront', 'cold front', 'dry high-pressure region', 'developed tropical thunderstorms' and so on. This has the added benefit that the user can specify the weather locally simply by chosing an appropriate tile from a menu (he does not need to micromanage the weather by placing individual EV and cloud models).&lt;br /&gt;
&lt;br /&gt;
The type of tile then determines the rules for populating the tile with EV and models. A 'leading edge of a warmfront' tile could for example have the rules&lt;br /&gt;
&lt;br /&gt;
* populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft &lt;br /&gt;
* make sure the models are spaced sufficiently far apart&lt;br /&gt;
* make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)&lt;br /&gt;
* populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles. &lt;br /&gt;
&lt;br /&gt;
Technically, each tile can be populated by a Nasal script specific for the tile type whenever the tile is needed (probably when it becomes visible). As an example for the development state of the system (March 2010), here is the view for a weather tile representing an approaching cold front with a Stratocumulus layer and occasional Cumulonimbus activity.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Large scale - tile placement rules ===&lt;br /&gt;
&lt;br /&gt;
To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.&lt;br /&gt;
&lt;br /&gt;
If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simpy due to the tile placement rules mocking up the presence of real large-scale weather systems.&lt;br /&gt;
&lt;br /&gt;
Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection with the METAR system ==&lt;br /&gt;
&lt;br /&gt;
Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:&lt;br /&gt;
&lt;br /&gt;
* selection of tile type&lt;br /&gt;
* placement of EVs and models inside the tile&lt;br /&gt;
* continuously varying weather parameters&lt;br /&gt;
&lt;br /&gt;
=== Selection of tile type ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.&lt;br /&gt;
&lt;br /&gt;
=== Placement of EVs and models inside the tile ===&lt;br /&gt;
&lt;br /&gt;
At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).&lt;br /&gt;
&lt;br /&gt;
=== METAR and continuously varying weather parameters ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).&lt;br /&gt;
&lt;br /&gt;
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is&lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same.&lt;br /&gt;
&lt;br /&gt;
== Related Discussions ==&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection with the Multiplayer system ==&lt;br /&gt;
&lt;br /&gt;
(should be written by someone who knows what the Multiplayer system can and cannot do)&lt;br /&gt;
&lt;br /&gt;
== Development ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=53757</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=53757"/>
		<updated>2012-09-02T16:19:34Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de FlightGear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :&lt;br /&gt;
&lt;br /&gt;
* simuler la météo à différentes echelles&lt;br /&gt;
* idéalement générer le temps avec ou sans connexion&lt;br /&gt;
* autoriser une quelconque modification par l'utilisateur&lt;br /&gt;
* être suffisament rapide pour pouvoir générer en temps réel&lt;br /&gt;
&lt;br /&gt;
Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation  du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques. &lt;br /&gt;
&lt;br /&gt;
Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).&lt;br /&gt;
&lt;br /&gt;
Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.&lt;br /&gt;
&lt;br /&gt;
=== Small scale - effect volumes and average conditions ===&lt;br /&gt;
&lt;br /&gt;
To simulate local weather at small scale, effect volumes (EV) are a useful concept. The effect volumes define regions in which the normal weather conditions (wind, turbulence, updraft, visibility, precipitation...) are replaced by ones characteristic for the region. As an example, one would define the inside of a cloud as an effect volume in which visibility is reduced as compared to outside, or the precipitation layer underneath a thunderstorm as an EV in which heavy rain is on, visibility is reduced, the temperature is reduced and some turbulence may be active. &lt;br /&gt;
&lt;br /&gt;
The conditions characteristic for the EV are imposed once the aircraft enters the volume, they are restored to the outside values once the aircraft leaves the region again. The Flightgear AI system already has examples of structures which in essence are EVs - '''thermal''' and '''thunderstorm'''. The first structure contains an EV in which vertical air motion is active, the second one in which turbulence is present. These structures could be generalized to an AI system '''weather''' in which essentially all weather parameters inside the volume could be set by XML tags. &lt;br /&gt;
&lt;br /&gt;
On the visual side, parts of the EV must also be tied to visible models. The inside of a cloud can be modelled by reduced visibility, but the outside of the cloud must be a model. Similarly, the inside of a rain front appears as rain generated by the Flightgear system, but the outside must be a 3-d model of a precipitation layer. This means that individual 3-d models for various visible atmospheric phenomena (clouds, precipitation, fog, ...) need to be created (see [[Howto: Modelling clouds|Howto: Modelling Clouds]] for a collection of techniques for creating cloud and precipitation models).&lt;br /&gt;
&lt;br /&gt;
Outside the EV, many meteorological parameters may vary in a continuous way, for example visibility may decrease from 5000 to 4000 m when flying 20 km north - but inside the cloud (the EV), it will change in a discontinuous way very suddenly to a low value (say 30 m), to jump back to a large value outside the cloud. Thus, the EVs are used to simulate only discontinuous, local changes in conditions, the larger scale changes in the background need to be taken care of by a different system.&lt;br /&gt;
&lt;br /&gt;
EV's should be implemented such that they can be user-specified, i.e. a user should be able to place any particular combination of weather effects and cloud/precipitation model to a specific location.&lt;br /&gt;
&lt;br /&gt;
=== Mid scale - weather tiles ===&lt;br /&gt;
&lt;br /&gt;
Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) which would cover a region of, say, 30x30 km or something of that size. Inside tiles, weather is simulated explicitly in terms of EVs and 3-d models. &lt;br /&gt;
&lt;br /&gt;
As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warmfront - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front. &lt;br /&gt;
&lt;br /&gt;
Thus, there need to be different 'types' of tiles, each representing a typical snapshot of a development inside the larger system. Tile themes would be something like 'leading edge of warmfront', 'trailing edge of warmfront', 'cold front', 'dry high-pressure region', 'developed tropical thunderstorms' and so on. This has the added benefit that the user can specify the weather locally simply by chosing an appropriate tile from a menu (he does not need to micromanage the weather by placing individual EV and cloud models).&lt;br /&gt;
&lt;br /&gt;
The type of tile then determines the rules for populating the tile with EV and models. A 'leading edge of a warmfront' tile could for example have the rules&lt;br /&gt;
&lt;br /&gt;
* populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft &lt;br /&gt;
* make sure the models are spaced sufficiently far apart&lt;br /&gt;
* make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)&lt;br /&gt;
* populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles. &lt;br /&gt;
&lt;br /&gt;
Technically, each tile can be populated by a Nasal script specific for the tile type whenever the tile is needed (probably when it becomes visible). As an example for the development state of the system (March 2010), here is the view for a weather tile representing an approaching cold front with a Stratocumulus layer and occasional Cumulonimbus activity.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Large scale - tile placement rules ===&lt;br /&gt;
&lt;br /&gt;
To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.&lt;br /&gt;
&lt;br /&gt;
If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simpy due to the tile placement rules mocking up the presence of real large-scale weather systems.&lt;br /&gt;
&lt;br /&gt;
Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection with the METAR system ==&lt;br /&gt;
&lt;br /&gt;
Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:&lt;br /&gt;
&lt;br /&gt;
* selection of tile type&lt;br /&gt;
* placement of EVs and models inside the tile&lt;br /&gt;
* continuously varying weather parameters&lt;br /&gt;
&lt;br /&gt;
=== Selection of tile type ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.&lt;br /&gt;
&lt;br /&gt;
=== Placement of EVs and models inside the tile ===&lt;br /&gt;
&lt;br /&gt;
At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).&lt;br /&gt;
&lt;br /&gt;
=== METAR and continuously varying weather parameters ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).&lt;br /&gt;
&lt;br /&gt;
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is&lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same.&lt;br /&gt;
&lt;br /&gt;
== Related Discussions ==&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection with the Multiplayer system ==&lt;br /&gt;
&lt;br /&gt;
(should be written by someone who knows what the Multiplayer system can and cannot do)&lt;br /&gt;
&lt;br /&gt;
== Development ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=53731</id>
		<title>Fr/A local weather system</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/A_local_weather_system&amp;diff=53731"/>
		<updated>2012-09-01T23:11:09Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: Created page with &amp;quot;Statut: Août 2010  Le système météo actuel de flightgear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet: Touts les paramètres, que ce soi...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Statut: Août 2010&lt;br /&gt;
&lt;br /&gt;
Le système météo actuel de flightgear peut être appelé ''Global'' quand Flightgear se lance sans connexion internet: Touts les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables . Il n'est pas possible de voler dans un endroit ou le temps est différent, ou voir des changements atmosphériques dans un autre lieu.&lt;br /&gt;
&lt;br /&gt;
Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui determinent le temps de manière locale : On peut changer de météo en volant en un lieu ou le METAR disponible est différent,Mais le changement s'opère de manière globale, C'est à dire qu'il n' y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.&lt;br /&gt;
&lt;br /&gt;
Au contraire,un système de météo locale permet des changements continus de la météo d'un endroit  à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour Flightgear pourrait être créé en utilisant la technologie et le code existants.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Echelle des phénomènes météorologiques ==&lt;br /&gt;
&lt;br /&gt;
Real weather phenomena are determined by processes occurring at vastly different size scales. At the large end of the scale is the system of low and high pressure regions and fronts between cold and warm air masses, which have spatial size scales of O(1000) km. At the other end of the scale are very localized phenomena, for instance a dark tarmac surface heated by sunlight acting as the source point of a thermal updraft resulting in a Cumulus cloud. Both size scales are relevant for the Flightgear experience - an airliner on a longhaul flight is able to observe large-scale weather fronts from above, whereas a glider pilot needs a reasonable simulation of local updrafts and sinks tied to terrain features in a credible way for a realistic flight experience. A local weather system therefore needs to&lt;br /&gt;
&lt;br /&gt;
* simulate weather phenomena at different scales&lt;br /&gt;
* ideally work offline as well as online&lt;br /&gt;
* allow modification by the user on various scales&lt;br /&gt;
* be reasonably fast to run in real-time &lt;br /&gt;
&lt;br /&gt;
The actual dynamics of the atmosphere is a very complex problem which even solved approximately needs hours of CPU time on supercomputing clusters. From this, it is clear that a local weather system cannot be an (even approximately) physically accurate description of processes in the atmosphere, but needs to be a credible mockup of such a description in which heuristic rules replace simulation. &lt;br /&gt;
&lt;br /&gt;
To give an example for what this means, consider the development of Cumulus clouds. Cumulus development is reduced on a hot day under a hazy Cirrus sky. The reason is that the Cirrus sky reflects part of the sunlight, thus the ground is not heated that much by direct sunlight and the convective processes responsible for Cumulus cloud formation are lessened. An accurate simulation would need to start with the energy absorbed from the sunlight on various types of surfaces, then solve the equations governing the heat flux from the ground to the air above, followed by fluid-dynamical equations for the convective currents creating Cumulus clouds. A heuristic rule would simply state that the probability for the placement of a Cumulus cloud into the Flightgear environment is reduced by 50% when a Cirrus cover is present (obviously, the sophistication of the ruleset determines how realistic the weather system will appear).&lt;br /&gt;
&lt;br /&gt;
In the following, the technology for such a local weather system needed at the relevant scales is outlined - first for the situation offline, followed by ideas how it could be connected with the METAR system in online use.&lt;br /&gt;
&lt;br /&gt;
=== Small scale - effect volumes and average conditions ===&lt;br /&gt;
&lt;br /&gt;
To simulate local weather at small scale, effect volumes (EV) are a useful concept. The effect volumes define regions in which the normal weather conditions (wind, turbulence, updraft, visibility, precipitation...) are replaced by ones characteristic for the region. As an example, one would define the inside of a cloud as an effect volume in which visibility is reduced as compared to outside, or the precipitation layer underneath a thunderstorm as an EV in which heavy rain is on, visibility is reduced, the temperature is reduced and some turbulence may be active. &lt;br /&gt;
&lt;br /&gt;
The conditions characteristic for the EV are imposed once the aircraft enters the volume, they are restored to the outside values once the aircraft leaves the region again. The Flightgear AI system already has examples of structures which in essence are EVs - '''thermal''' and '''thunderstorm'''. The first structure contains an EV in which vertical air motion is active, the second one in which turbulence is present. These structures could be generalized to an AI system '''weather''' in which essentially all weather parameters inside the volume could be set by XML tags. &lt;br /&gt;
&lt;br /&gt;
On the visual side, parts of the EV must also be tied to visible models. The inside of a cloud can be modelled by reduced visibility, but the outside of the cloud must be a model. Similarly, the inside of a rain front appears as rain generated by the Flightgear system, but the outside must be a 3-d model of a precipitation layer. This means that individual 3-d models for various visible atmospheric phenomena (clouds, precipitation, fog, ...) need to be created (see [[Howto: Modelling clouds|Howto: Modelling Clouds]] for a collection of techniques for creating cloud and precipitation models).&lt;br /&gt;
&lt;br /&gt;
Outside the EV, many meteorological parameters may vary in a continuous way, for example visibility may decrease from 5000 to 4000 m when flying 20 km north - but inside the cloud (the EV), it will change in a discontinuous way very suddenly to a low value (say 30 m), to jump back to a large value outside the cloud. Thus, the EVs are used to simulate only discontinuous, local changes in conditions, the larger scale changes in the background need to be taken care of by a different system.&lt;br /&gt;
&lt;br /&gt;
EV's should be implemented such that they can be user-specified, i.e. a user should be able to place any particular combination of weather effects and cloud/precipitation model to a specific location.&lt;br /&gt;
&lt;br /&gt;
=== Mid scale - weather tiles ===&lt;br /&gt;
&lt;br /&gt;
Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) which would cover a region of, say, 30x30 km or something of that size. Inside tiles, weather is simulated explicitly in terms of EVs and 3-d models. &lt;br /&gt;
&lt;br /&gt;
As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warmfront - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front. &lt;br /&gt;
&lt;br /&gt;
Thus, there need to be different 'types' of tiles, each representing a typical snapshot of a development inside the larger system. Tile themes would be something like 'leading edge of warmfront', 'trailing edge of warmfront', 'cold front', 'dry high-pressure region', 'developed tropical thunderstorms' and so on. This has the added benefit that the user can specify the weather locally simply by chosing an appropriate tile from a menu (he does not need to micromanage the weather by placing individual EV and cloud models).&lt;br /&gt;
&lt;br /&gt;
The type of tile then determines the rules for populating the tile with EV and models. A 'leading edge of a warmfront' tile could for example have the rules&lt;br /&gt;
&lt;br /&gt;
* populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft &lt;br /&gt;
* make sure the models are spaced sufficiently far apart&lt;br /&gt;
* make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)&lt;br /&gt;
* populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft&lt;br /&gt;
(...)&lt;br /&gt;
&lt;br /&gt;
The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles. &lt;br /&gt;
&lt;br /&gt;
Technically, each tile can be populated by a Nasal script specific for the tile type whenever the tile is needed (probably when it becomes visible). As an example for the development state of the system (March 2010), here is the view for a weather tile representing an approaching cold front with a Stratocumulus layer and occasional Cumulonimbus activity.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;&lt;br /&gt;
[[File:Clouds-coldfront02.jpg|400px]]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Large scale - tile placement rules ===&lt;br /&gt;
&lt;br /&gt;
To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.&lt;br /&gt;
&lt;br /&gt;
If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simpy due to the tile placement rules mocking up the presence of real large-scale weather systems.&lt;br /&gt;
&lt;br /&gt;
Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Connection with the METAR system ==&lt;br /&gt;
&lt;br /&gt;
Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:&lt;br /&gt;
&lt;br /&gt;
* selection of tile type&lt;br /&gt;
* placement of EVs and models inside the tile&lt;br /&gt;
* continuously varying weather parameters&lt;br /&gt;
&lt;br /&gt;
=== Selection of tile type ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.&lt;br /&gt;
&lt;br /&gt;
=== Placement of EVs and models inside the tile ===&lt;br /&gt;
&lt;br /&gt;
At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).&lt;br /&gt;
&lt;br /&gt;
=== METAR and continuously varying weather parameters ===&lt;br /&gt;
&lt;br /&gt;
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).&lt;br /&gt;
&lt;br /&gt;
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is&lt;br /&gt;
&lt;br /&gt;
p = (sum p_i (1/d_i)) / (sum 1/d_i)&lt;br /&gt;
&lt;br /&gt;
as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same.&lt;br /&gt;
&lt;br /&gt;
== Related Discussions ==&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms] (06/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8137 A smart cloud altitude algorithm] (05/2010)&lt;br /&gt;
* [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7591 Weather dynamics] (04/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=6968 New thunderstorm AI scenario alpha release] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7107 Cirrus sky (download link in first post)] (02/2010)&lt;br /&gt;
* [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358 A local weather system] (03/2010)&lt;br /&gt;
&lt;br /&gt;
== Connection with the Multiplayer system ==&lt;br /&gt;
&lt;br /&gt;
(should be written by someone who knows what the Multiplayer system can and cannot do)&lt;br /&gt;
&lt;br /&gt;
== Development ==&lt;br /&gt;
&lt;br /&gt;
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94765]&lt;br /&gt;
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a &amp;quot;NONE&amp;quot; or &amp;quot;MUTE&amp;quot; logging priority [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96370].&lt;br /&gt;
* The feature-checking approach used by &amp;quot;compat_layer.nas&amp;quot; should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;p=96439#p96358]&lt;br /&gt;
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.&lt;br /&gt;
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.&lt;br /&gt;
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.&lt;br /&gt;
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).&lt;br /&gt;
&lt;br /&gt;
== Feature requests on the C++ side ==&lt;br /&gt;
&lt;br /&gt;
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=8365 Weather algorithms discussion] from 06/2010.&lt;br /&gt;
&lt;br /&gt;
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be '''performance''', '''accessibility''', a '''clear structure''' and '''backward compatibility'''. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.&lt;br /&gt;
&lt;br /&gt;
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file '''compat_layer.nas'''. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:&lt;br /&gt;
&lt;br /&gt;
=== Terrain related ===&lt;br /&gt;
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.&lt;br /&gt;
&lt;br /&gt;
=== Environment related ===&lt;br /&gt;
* (08/2012): Provide an option to disable the precipitation &amp;quot;layer&amp;quot; system [http://flightgear.org/forums/viewtopic.php?f=69&amp;amp;t=7358&amp;amp;start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]&lt;br /&gt;
&lt;br /&gt;
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&amp;amp;sort=-id&amp;amp;colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].&lt;br /&gt;
&lt;br /&gt;
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&amp;amp;t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&amp;amp;t=7358&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&amp;amp;start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]&lt;br /&gt;
&lt;br /&gt;
* Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set '''/environment/ridge-lift/enabled''' to 0&lt;br /&gt;
&lt;br /&gt;
=== Cloud placement ===&lt;br /&gt;
* 08/2012: Cloud placement meanwhile uses a new fgcommand &amp;quot;add-cloud&amp;quot;, however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.&lt;br /&gt;
&lt;br /&gt;
* calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:&lt;br /&gt;
&lt;br /&gt;
:* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. &lt;br /&gt;
&lt;br /&gt;
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.&lt;br /&gt;
&lt;br /&gt;
=== Performance bottlenecks ===&lt;br /&gt;
&lt;br /&gt;
For reference, the main performance bottlenecks in v0.81 seem to be:&lt;br /&gt;
&lt;br /&gt;
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.&lt;br /&gt;
&lt;br /&gt;
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. &lt;br /&gt;
&lt;br /&gt;
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal&lt;br /&gt;
&lt;br /&gt;
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) &lt;br /&gt;
&lt;br /&gt;
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery&lt;br /&gt;
&lt;br /&gt;
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.&lt;br /&gt;
&lt;br /&gt;
* frequently used fgcommands &lt;br /&gt;
&lt;br /&gt;
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)&lt;br /&gt;
&lt;br /&gt;
=== New Nasal API requests ===&lt;br /&gt;
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++&lt;br /&gt;
The file [http://gitorious.org/fg/fgdata/blobs/master/Nasal/compat_layer.nas $FG_ROOT/Nasal/compat_layer.nas] contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.&lt;br /&gt;
&lt;br /&gt;
== Current development status ==&lt;br /&gt;
&lt;br /&gt;
The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 0.85:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]&lt;br /&gt;
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
A feature gallery of version 1.0:&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]&lt;br /&gt;
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]&lt;br /&gt;
&lt;br /&gt;
== Download ==&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]&lt;br /&gt;
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]&lt;br /&gt;
&lt;br /&gt;
== Related content ==&lt;br /&gt;
* [[Atmospheric light scattering]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/VU_University_Medical_Center&amp;diff=53730</id>
		<title>Fr/VU University Medical Center</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/VU_University_Medical_Center&amp;diff=53730"/>
		<updated>2012-09-01T22:57:02Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: Created page with &amp;quot;{{infobox Airport |name = VU Medical Center |image =EH0001.jpg |alt =EH0001 in the FlightGear scenery |icao =EH0001 |iata = |type =Helideck |city =Amsterdam, [[The Netherlands...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox Airport&lt;br /&gt;
|name = VU Medical Center&lt;br /&gt;
|image =EH0001.jpg&lt;br /&gt;
|alt =EH0001 in the FlightGear scenery&lt;br /&gt;
|icao =EH0001&lt;br /&gt;
|iata =&lt;br /&gt;
|type =Helideck&lt;br /&gt;
|city =Amsterdam, [[The Netherlands]]&lt;br /&gt;
|website =http://www.vumc.nl&lt;br /&gt;
}}&lt;br /&gt;
La '''VU University Medical Center''' ou simplement '''VUMC''', est l'hopital affilié avec la Vrije Université (litéralement: &amp;quot;L'université libre&amp;quot;) d'Amsterdam, aux Pays-Bas. Il est un des plus grands hôpitaux du pays,  et est situé à côté du By-pass A10 dans la partie sud-ouest de la ville, à côté du campus VU et près d'[[Amsterdam Airport Schiphol|Schiphol airport]].&lt;br /&gt;
L'hôpital abrite un équipe de traumatologie, équipée avec un [[Eurocopter EC135|EC135 helicopter]], qui peut opérer sur le toit de l'immeuble ( [[Howto: Make a helipad|helideck]] (ICAO: EH0001)).&lt;br /&gt;
&lt;br /&gt;
== Scène FlightGear ==&lt;br /&gt;
&lt;br /&gt;
Ajouter les lignes suivantes au fichier apt.dat pour pouvoir décoller de l'hélipad, comme [[FlightGear User Created Helipad List|expliqué ici]].&lt;br /&gt;
&lt;br /&gt;
 17 126 0 0 EH0001 [H] VU Medisch Centrum &lt;br /&gt;
 10 52.33434 4.85911 H1x 360.00 40 0000.0000 0000.0000 36 111111 1 0 2 0.25 0 0300.0300&lt;br /&gt;
&lt;br /&gt;
[[Category:Airports in the Netherlands]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/fg2blender&amp;diff=53728</id>
		<title>Fr/fg2blender</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/fg2blender&amp;diff=53728"/>
		<updated>2012-09-01T22:43:09Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{infobox Aircraft&lt;br /&gt;
|image   		= FG2Blender.jpg&lt;br /&gt;
|name    		= FG2Blender&lt;br /&gt;
|authors 		= PAF team&lt;br /&gt;
|status 		= Development&lt;br /&gt;
|development 		= http://equipe-flightgear.forumactif.com/t987-script-flightgear&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
FG2Blender est un script python pour Blender qui permet de créer des animations, charger des fichiers XML, lire des FDM, créer des positions de caméra, exporter des morceaux de FDM...&lt;br /&gt;
Il fonctionne à partir de Blender 2.6x&lt;br /&gt;
&lt;br /&gt;
Ce script vise les contributeurs qui souhaitent faire des animations complexes (faire bouger un aileron selon un axe n'est pas une animation complexe).&lt;br /&gt;
Aussi il peut vous aider à créer un environnement 3D complexe car il permet de charger un cockpit entier récursivement. Ainsi vous avez une vue globale du rendu final sans devoir lancer FlightGear pour vérifier chaque modifications.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Téléchargements &amp;amp; Installation==&lt;br /&gt;
&lt;br /&gt;
Le script est disponible ici : https://gitorious.org/paf/fg2blender (Script non stable, en cours de développement)&lt;br /&gt;
&lt;br /&gt;
Une fois téléchargé, il vous suffit de déposer le dossier fg2blender dans votre dossier script/addons/ de Blender&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Le menu FlightGear Tools Menu==&lt;br /&gt;
&lt;br /&gt;
[[File:FG2Blender Flightgear Tools Menu.png|thumb|FG2Blender : Flightgear Tools Menu]]&lt;br /&gt;
&lt;br /&gt;
Le menu &amp;quot;Flightgear Tools Menu&amp;quot; est accessible à l'aide de la touche &amp;quot;f&amp;quot; dans la fenêtre 3D de Blender.&lt;br /&gt;
&lt;br /&gt;
;Insert Keyframe Rotate&lt;br /&gt;
:Insert une keyframe pour les animations de type &amp;quot;rotate&amp;quot;. Pour l'utiliser il faut sélectionner une armature créée avec l'item &amp;quot;Armatures &amp;gt; Create Rotation&amp;quot;&lt;br /&gt;
&lt;br /&gt;
;Insert Keyframe Rotate&lt;br /&gt;
:Insert une keyframe pour les animations de type &amp;quot;rotate&amp;quot;. Pour l'utiliser il faut sélectionner une armature créée avec l'item &amp;quot;Armatures&amp;gt;Create Translate&amp;quot;&lt;br /&gt;
&lt;br /&gt;
;Import (.xml)&lt;br /&gt;
:Importe un fichier d'animation XML&lt;br /&gt;
&lt;br /&gt;
;Creation animations&lt;br /&gt;
:Crée la visualisation des animations. Pour l'utiliser il faut avoir importé un fichier d'animation XML avec l'item &amp;quot;Import (.xml)&amp;quot;&lt;br /&gt;
&lt;br /&gt;
;Edge Split&lt;br /&gt;
:Applique un &amp;quot;modifier&amp;quot; de type edge-split sur l'ensemble des objets sélectionnés&lt;br /&gt;
&lt;br /&gt;
;Select property&lt;br /&gt;
:Sélectionne un ensemble d'objets et d'armatures liés à l'objet actif. Par exemple pour sélectionner un train d'atterrissage (armature+mesh) on sélectionne une partie. Puis avec l'item &amp;quot;Select roperty&amp;quot; on sélectionne l'ensemble. Puis avec CTRL+I (inversion sélection) et H(hide cache). On ne voit finalement que le train d'atterrissage. Cela peut être très utile lorsque l'animation est caché par d'autre maillage.&lt;br /&gt;
&lt;br /&gt;
;Time x2&lt;br /&gt;
:Augmente la vitesse de visualisation des animations par 2 (à utiliser après avoir créé la visualisation des animations)&lt;br /&gt;
&lt;br /&gt;
;Time x0.5&lt;br /&gt;
:Diminue la vitesse de visualisation des animations par 2 (à utiliser après avoir créé la visualisation des animations)&lt;br /&gt;
&lt;br /&gt;
;Copy blender name to ac name&lt;br /&gt;
:Recopie le nom blender dans l'onglet flightgear &amp;quot;ac name&amp;quot; un objet maillage (mesh). Lorsque l'on importe un avion ce champ est déjà rempli, mais lorsque l'on crée un objet ce champ est vide. Lorsque l'on fait de la modélisation on est très concentré sur le maillage et pas forcément sur le script.&lt;br /&gt;
&lt;br /&gt;
;Copy ac file (active-&amp;gt;selects)&lt;br /&gt;
:Permet de faire cette recopie en bloc sur une sélection. &lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Create Rotation&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Create Translate&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Transfom to rotate&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Transform to translate&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Select Property&lt;br /&gt;
:Sélection uniquement sur les armatures. Sélectionne toutes les armatures avec une même property flightgear&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Copy xml file (active-&amp;gt;selects)&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Copy property (active-&amp;gt;selects)&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Reset Rotate&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Init Rotate&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Save Keyframe and Reset&lt;br /&gt;
:Sauvegarde une(des) animation(s) et la(les) réinitialise à zéro (plus de translation, ou plus de rotation)&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Restore Keyframe&lt;br /&gt;
:Restaure l'(les) animation(s) sauvegardée&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Save Parent and Reset&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Armatures &amp;gt; Restore Parent&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Unwrap 4 faces&lt;br /&gt;
:Dépliage 4 faces&lt;br /&gt;
&lt;br /&gt;
;Manual&lt;br /&gt;
:Ouvre votre navigateur web pour consulter le manuel ici présent&lt;br /&gt;
&lt;br /&gt;
== La fenêtre Flightgear Object ==&lt;br /&gt;
&lt;br /&gt;
[[File:FG2Blender Flightgear Object.png|thumb|FG2Blender : Flightgear Object]]&lt;br /&gt;
&lt;br /&gt;
Panneau visible dans l'onglet &amp;quot;Object&amp;quot; de Blender après avoir sélectionné un objet 3D&lt;br /&gt;
&lt;br /&gt;
;Mesh Name&lt;br /&gt;
:Nom de l'objet 3D tel qu'il est dans le fichier AC3D et qui sera utiliser lors de l'export. Cela évite les noms du genre vitre.001, vitre.002, vitre.003... lorsque l'on importe plusieurs fichiers AC3D qui contiennent des objets du même nom.&lt;br /&gt;
&lt;br /&gt;
;Filename&lt;br /&gt;
:Emplacement du fichier AC3D auquel appartient l'objet 3D. C'est aussi ce fichier qui sera utiliser lors de l'export.&lt;br /&gt;
&lt;br /&gt;
;Save ac file&lt;br /&gt;
:Exporte &amp;lt;ins&amp;gt;tous&amp;lt;/ins&amp;gt; les objets 3D appartenant au fichier AC3D situé dans le champs &amp;quot;Filename&amp;quot;&lt;br /&gt;
&lt;br /&gt;
;Parent&lt;br /&gt;
:Armature parent dont dépend l'objet. Cliquez sur &amp;quot;Select&amp;quot; afin de travailler sur l'armature qui régie cet objet. (Uniquement visible si une animation est déjà associé à l'objet)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== La fenêtre Flightgear Animation ==&lt;br /&gt;
&lt;br /&gt;
[[File:FG2Blender Flightgear Animation.png|thumb|FG2Blender : Flightgear Animation]]&lt;br /&gt;
&lt;br /&gt;
;Family&lt;br /&gt;
:Famille de propriété associé à l'animation&lt;br /&gt;
&lt;br /&gt;
;Node&lt;br /&gt;
:Nom de la propriété qui doit être utilisé (Visible uniquement si Family est différent de &amp;quot;custom&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
;Property&lt;br /&gt;
:Chemin complet de la propriété qui doit être utilisé&lt;br /&gt;
&lt;br /&gt;
;Value&lt;br /&gt;
:Dans le cas d'une propriété numérotée c'est la valeur du numéro de la propriété. Par exemple, si value = 0, la propriété sera gear/gear[0]/rollspeed-ms, si value = 3, la propriété sera gear/gear[3]/rollspeed-ms&lt;br /&gt;
&lt;br /&gt;
;Include disk file&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;to Disc&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;xml File&lt;br /&gt;
:Emplacement du fichier XML auquel appartient l'objet 3D.&lt;br /&gt;
&lt;br /&gt;
;Write File&lt;br /&gt;
:Exporte &amp;lt;ins&amp;gt;toutes&amp;lt;/ins&amp;gt; les animations appartenant au fichier XML situé dans le champs &amp;quot;xml file&amp;quot; (Les données ne son pas écrites directement dans le fichier XML, elles sont accessible dans l'environnement &amp;quot;Scripting&amp;quot;)&lt;br /&gt;
&lt;br /&gt;
;Type&lt;br /&gt;
:Type de l'animation&lt;br /&gt;
&lt;br /&gt;
;factor&lt;br /&gt;
:Valeur de la balise &amp;lt;factor&amp;gt;&lt;br /&gt;
&lt;br /&gt;
;Time&lt;br /&gt;
:&lt;br /&gt;
&lt;br /&gt;
;Min&lt;br /&gt;
:Valeur minimum que peut prendre la propriété dans FlightGear&lt;br /&gt;
&lt;br /&gt;
;Max&lt;br /&gt;
:Valeur maximum que peut prendre la propriété dans FlightGear&lt;br /&gt;
&lt;br /&gt;
;Child(s) object(s)&lt;br /&gt;
:Liste des objets et armature qui dépendent de cette armature&lt;br /&gt;
&lt;br /&gt;
;Parent&lt;br /&gt;
:Armature dont dépend l'armature actuellement sélectionnée&lt;br /&gt;
&lt;br /&gt;
== Liens ==&lt;br /&gt;
&lt;br /&gt;
Développement : http://equipe-flightgear.forumactif.com/t987-script-flightgear&lt;br /&gt;
&lt;br /&gt;
Dépôt GIT : https://gitorious.org/paf/fg2blender&lt;br /&gt;
&lt;br /&gt;
Tutoriel : http://equipe-flightgear.forumactif.com/t1019-script-d-animation-blender&lt;br /&gt;
&lt;br /&gt;
Exemple : http://clemaez.fr/flightgear/fg2blender_example.tar.gz&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/Beechcraft_Starship&amp;diff=53668</id>
		<title>Fr/Beechcraft Starship</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/Beechcraft_Starship&amp;diff=53668"/>
		<updated>2012-08-31T08:32:44Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: Created page with &amp;quot;{{aero-stub}}  {{infobox Aircraft |image = startship1.jpg |name = Beechcraft Starship |type = twin turboprop business transport |fdm = Yasim |authors = BARANGER Emmanuel (3D) ...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{aero-stub}} &lt;br /&gt;
{{infobox Aircraft&lt;br /&gt;
|image = startship1.jpg&lt;br /&gt;
|name = Beechcraft Starship&lt;br /&gt;
|type = twin turboprop business transport&lt;br /&gt;
|fdm = Yasim&lt;br /&gt;
|authors = BARANGER Emmanuel (3D)&lt;br /&gt;
|fgname = starship&lt;br /&gt;
|status-fdm	= 1&lt;br /&gt;
|status-systems	= 1&lt;br /&gt;
|status-cockpit	= 2&lt;br /&gt;
|status-model	= 2&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Le '''Beechcraft Starship''' est vaisseau au look futuriste américain( USA ) turbo-propulsé, et peut emporter de 6 à 8 personnes pour un vol commercial. La conception fut lancée par la firme '''Beechcraft''' en Janvier 1980 en tant que &amp;quot;Preliminary Design 330 (PD 330)&amp;quot;, c'est à dire en conception préliminaire. Burt Rutan fut retenu pour affiner le PD 330.Un des majeurs changments qu'il institua fut l'addition d'une géométrie variable au [[Category:Canard aircraft|&amp;quot;canard&amp;quot;]] (Il a déposé un brevet). La compagnie de Rutan, centrée sur le design et la construction de matériaux composites ,basée en Californie, fut par la suite retenue pour construire des prototypes en modèles-réduits pour servir dans la recherche.&lt;br /&gt;
&lt;br /&gt;
== Aide ==&lt;br /&gt;
{|class=&amp;quot;prettytable&amp;quot;&lt;br /&gt;
!Key&lt;br /&gt;
!Function&lt;br /&gt;
|-&lt;br /&gt;
|d&lt;br /&gt;
|Ouvrir/fermer la porte&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Liens externes ==&lt;br /&gt;
* [http://helijah.free.fr/flightgear/hangar.htm Helijah's Hangar] &lt;br /&gt;
* [http://en.wikipedia.org/wiki/Beechcraft_Starship Wikipedia]&lt;br /&gt;
&lt;br /&gt;
{{Beechcraft}}&lt;br /&gt;
[en/Beechcraft]&lt;br /&gt;
[[Category:Canard aircraft]]&lt;br /&gt;
[[Category:Civil utility aircraft]]&lt;br /&gt;
[[Category:Pusher aircraft]]&lt;br /&gt;
[[Category:Twin-engined aircraft]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/Accueil&amp;diff=53649</id>
		<title>Fr/Accueil</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/Accueil&amp;diff=53649"/>
		<updated>2012-08-30T15:03:09Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&amp;lt;!--------------------------------Banner across top of page------------------------------&amp;gt;&lt;br /&gt;
{| style=&amp;quot;width:100%; background:#efefef; margin-top:1.2em; border:1px solid #d9e2e2;&amp;quot;&lt;br /&gt;
|style=&amp;quot;width:100%; color:#000&amp;quot;|&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!-------------&amp;quot;Welcome to FlightGear&amp;quot; and article count----------&amp;gt;&lt;br /&gt;
{| style=&amp;quot;width:100%; border:solid 0px; background:none;&amp;quot;&lt;br /&gt;
|style=&amp;quot;width:100%; text-align:center; white-space:nowrap; color:#000;&amp;quot;|&lt;br /&gt;
&amp;lt;div style=&amp;quot;font-size:162%; border:none; margin:0; padding:.1em; color:#000;&amp;quot;&amp;gt;Bienvenue sur le Wiki de FlightGear !&amp;lt;/div&amp;gt;&lt;br /&gt;
&amp;lt;div id=&amp;quot;articlecount&amp;quot; style=&amp;quot;width:100%; text-align:center; font-size:85%;&amp;quot;&amp;gt;nous en sommes actuellement à [[Special:Statistics|{{NUMBEROFARTICLES}}]] articles&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:de.gif|link=:de:Hauptseite]]&lt;br /&gt;
[[File:en.gif|link=:en:Main Page]]&lt;br /&gt;
[[File:es.gif|link=:es:Portada]]&lt;br /&gt;
[[File:fi.gif|link=:fi:Etusivu]]&lt;br /&gt;
[[File:fr.gif|link=:fr:Accueil]]&lt;br /&gt;
[[File:nl.gif|link=:nl:Hoofdpagina]]&lt;br /&gt;
[[File:pl.gif|link=:pl:Strona główna]]&lt;br /&gt;
[[File:pt.gif|link=:pt:Página principal]]&lt;br /&gt;
[[File:zh.gif|link=:zh:Main Page]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!--------------Portal list on righthand side----------&amp;gt;&lt;br /&gt;
|style=&amp;quot;width:11%; font-size:95%; color:#000;&amp;quot;|&lt;br /&gt;
|}&amp;lt;!--&lt;br /&gt;
&lt;br /&gt;
[[----------Strapline immediately below banner----------&amp;gt;&lt;br /&gt;
{|style=&amp;quot;width:100%; background:none; margin:-.8em 0 -.7em 0;&amp;quot;&lt;br /&gt;
|style=&amp;quot;font-size:95%; padding:10px 0; margin:0px; text-align:left; white-space:nowrap; color:#000;&amp;quot;| [[Help:Tutorial|Modifier]]&amp;amp;nbsp;'''·''' [[Help:Contents|Aide]]&lt;br /&gt;
|style=&amp;quot;font-size:95%; padding:10px 0; margin:0px; text-align: right; white-space:nowrap; color:#000;&amp;quot;| [[Special:Allpages|Toutes les pages]]&amp;amp;nbsp;'''·''' [[Special:Search|Chercher&lt;br /&gt;
]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
{|style=&amp;quot;border-spacing:8px; margin:0px -8px;&amp;quot;&lt;br /&gt;
|class=&amp;quot;MainPageBG&amp;quot; style=&amp;quot;width:100%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;&amp;quot;|&lt;br /&gt;
{|width=&amp;quot;100%&amp;quot; cellpadding=&amp;quot;1&amp;quot; cellspacing=&amp;quot;5&amp;quot; style=&amp;quot;vertical-align:top; background:#efefef;&amp;quot;&lt;br /&gt;
! &amp;lt;h2 style=&amp;quot;margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;&amp;quot;&amp;gt;FlightGear Flight Simulator&amp;lt;/h2&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
|style=&amp;quot;color:#000;&amp;quot;| &lt;br /&gt;
[[File:fr.gif|left]] '''[[Fr/FlightGear|FlightGear]] Flight Simulator''' est un simulateur de vol open-source sophistiqué et fonctionnel, créé et maintenu entièrement par des volontaires. Le code source complet est accessible par [[Git]], sous une licence libre [[GNU General Public License]]. &lt;br /&gt;
&lt;br /&gt;
Le projet [[Fr/FlightGear|FlightGear]] propose un environnement de développement de simulateur de vol sophistiqué, pour une utilisation académique ou à des fins de recherche; il permet le développement d'autres idées intéressantes en simulation de vol, tout en restant aussi accessible à l'utilisateur lambda. Toute personne intéressée peut [[Volunteer|contribuer]] à l'ajout de fonctionnalités ou à l'amélioration de FlightGear (avions, scènes). De plus, il existe de nombreux [[FlightGear related projects|projets connexes]] ([http://www.flightgear.org/links.html liens]).&lt;br /&gt;
&lt;br /&gt;
FlightGear est doté d'une documentation illustrée, parmi laquelle &amp;quot;Le Manuel&amp;quot;, disponible aux formats [http://mapserver.flightgear.org/getstart.pdf PDF] et [http://www.flightgear.org/Docs/getstart/getstart.html HTML]. Ce Wiki a été lancé en 2006 et couvre actuellement une bonne partie des sujets liés à FlightGear. La fonctionnalité multi-langues est plus récente (été 2009) et, pour le moment, seulement une petite partie est effectivement traduite.&lt;br /&gt;
&lt;br /&gt;
'''Veuillez sélectionner un portail :'''&lt;br /&gt;
&lt;br /&gt;
{|style=&amp;quot;background:none;&amp;quot;&lt;br /&gt;
|style=&amp;quot;font-size:95%; padding-left:10px; padding-right:20px; margin:0px; vertical-align: top; text-align:left; white-space:nowrap; color:#000;&amp;quot;| &lt;br /&gt;
* [[Portal:Developer|Développeur]]&lt;br /&gt;
** [[Portal:Developer/3D Modelers|Modélisation 3D]]&lt;br /&gt;
** [[Portal:Developer/Aircraft|Aéronef]]&lt;br /&gt;
** [[Portal:Developer/Scenery|Paysage]]&lt;br /&gt;
|style=&amp;quot;font-size:95%; padding-left:20px; margin:0px; vertical-align: top; text-align: left; border-left: 2px solid #d9e2e2; white-space:nowrap; color:#000;&amp;quot;| &lt;br /&gt;
* [[fr/Portal:Utilisateur|Utilisateur]]&lt;br /&gt;
* [[Portal:Pilot|Pilote]]&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===== '''Si vous êtes nouveau ici, jetez un oeil sur le [[Help:Contents|manuel]] avant de créer ou d'éditer un article!''' =====&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;!---------------------------Today's featured article, Did you know------------------------&amp;gt;&lt;br /&gt;
{|style=&amp;quot;border-spacing:8px; margin:0px -8px;&amp;quot;&lt;br /&gt;
|class=&amp;quot;MainPageBG&amp;quot; style=&amp;quot;width:50%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;&amp;quot;|&lt;br /&gt;
{|width=&amp;quot;100%&amp;quot; cellpadding=&amp;quot;2&amp;quot; cellspacing=&amp;quot;5&amp;quot; style=&amp;quot;vertical-align:top; background:#efefef;&amp;quot;&lt;br /&gt;
! &amp;lt;h2 style=&amp;quot;margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;&amp;quot;&amp;gt;Pour commencer&amp;lt;/h2&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
|style=&amp;quot;color:#000;&amp;quot;| &lt;br /&gt;
* [[:fr:Foire aux questions|FAQ]]&lt;br /&gt;
* [[:fr:Howto: Débarrassez-vous des erreurs les plus fréquentes|Messages d'erreur communs]]&lt;br /&gt;
* [[:fr:Howto: Multijoueur|Multijoueur]]&lt;br /&gt;
* [[:fr:Nouveau sur flightgear|Introduction à FlightGear]]&lt;br /&gt;
* [[Troubleshooting Problems|Dépannage]]&lt;br /&gt;
|-&lt;br /&gt;
! &amp;lt;h2 style=&amp;quot;margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;&amp;quot;&amp;gt;Utilisation de FlightGear&amp;lt;/h2&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
|style=&amp;quot;color:#000;&amp;quot;| &lt;br /&gt;
* [[:fr:Avions|Aéronefs]]&lt;br /&gt;
* [[:fr:Piloter l'hélicoptère|Piloter l'hélicoptère]]&lt;br /&gt;
* [[:fr:Table des modèles|Liste des modèles]]&lt;br /&gt;
'''[[Portal:User|Plus...]]'''&lt;br /&gt;
|-&lt;br /&gt;
! &amp;lt;h2 style=&amp;quot;margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;&amp;quot;&amp;gt;Développement de FlightGear&amp;lt;/h2&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
|style=&amp;quot;color:#000;&amp;quot;| &lt;br /&gt;
* [[:fr:Compiler FlightGear sous GNU/Linux|Compiler FlightGear]]&lt;br /&gt;
* [[Building terragear-cs in Ubuntu 64|Compiler Terragear sous Ubuntu 64 bits]]&lt;br /&gt;
'''[[Portal:Developer|Plus...]]''' &lt;br /&gt;
|-&lt;br /&gt;
! &amp;lt;h2 style=&amp;quot;margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;&amp;quot;&amp;gt;Nouvelles&amp;lt;/h2&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
|style=&amp;quot;color:#000;&amp;quot;| &lt;br /&gt;
{{News}}&lt;br /&gt;
|-&lt;br /&gt;
|}&amp;lt;!--&lt;br /&gt;
&lt;br /&gt;
--------------------------------In the news, On this day-------------------------------&amp;gt;&lt;br /&gt;
|class=&amp;quot;MainPageBG&amp;quot; style=&amp;quot;width:50%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top&amp;quot;|&lt;br /&gt;
{| width=&amp;quot;100%&amp;quot; cellpadding=&amp;quot;2&amp;quot; cellspacing=&amp;quot;5&amp;quot; style=&amp;quot;vertical-align:top; background:#efefef;&amp;quot;&lt;br /&gt;
! &amp;lt;h2 style=&amp;quot;margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;&amp;quot;&amp;gt;Image de la semaine&amp;lt;/h2&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
|style=&amp;quot;color:#000;&amp;quot;| &lt;br /&gt;
{{POTW/{{CURRENTYEAR}}-{{CURRENTWEEK}}}}&lt;br /&gt;
|-   &lt;br /&gt;
! &amp;lt;h2 style=&amp;quot;margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;&amp;quot;&amp;gt;Le saviez-vous...&amp;lt;/h2&amp;gt;   &lt;br /&gt;
|-   &lt;br /&gt;
|style=&amp;quot;color:#000;&amp;quot;|  &lt;br /&gt;
{{Did you know}}&lt;br /&gt;
|-&lt;br /&gt;
! &amp;lt;h2 style=&amp;quot;margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;&amp;quot;&amp;gt;Promotion de FlightGear&amp;lt;/h2&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
|style=&amp;quot;color:#000;&amp;quot;|&lt;br /&gt;
* [[FlightGear Reviews|Évaluations de FlightGear]]&lt;br /&gt;
* [[FlightGear Videos|Vidéos de FlightGear]]&lt;br /&gt;
 &lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
__NOTOC__&lt;br /&gt;
__NOEDITSECTION__&lt;br /&gt;
&lt;br /&gt;
[[en:Main Page]]&lt;br /&gt;
[[de:Hauptseite]]&lt;br /&gt;
[[es:Portada]]&lt;br /&gt;
[[fi:Etusivu]]&lt;br /&gt;
[[fr:Accueil]]&lt;br /&gt;
[[it:Pagina principale]]&lt;br /&gt;
[[nl:Hoofdpagina]]&lt;br /&gt;
[[pt:Página principal]]&lt;br /&gt;
[[pl:Strona główna]]&lt;br /&gt;
[[ru:Заглавная страница]]&lt;br /&gt;
[[zh:Main Page]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/flightgear&amp;diff=53648</id>
		<title>Fr/flightgear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/flightgear&amp;diff=53648"/>
		<updated>2012-08-30T14:59:25Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: moved Fr/flightgear to Fr/FlightGear&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;#REDIRECT [[Fr/FlightGear]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53647</id>
		<title>Fr/FlightGear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53647"/>
		<updated>2012-08-30T14:59:25Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: moved Fr/flightgear to Fr/FlightGear&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Software&lt;br /&gt;
| title                  = FlightGear&lt;br /&gt;
| logo                   = fglogosm.jpg&lt;br /&gt;
| image                  = FlightGear - 1903 Wright Flyer.jpg&lt;br /&gt;
| alt                    = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9&lt;br /&gt;
| developedby           = FlightGear Developers &amp;amp; Contributors&lt;br /&gt;
| initialrelease         = July 17, 1997&lt;br /&gt;
| latestrelease          = 2.8.0 (February 17, 2012)&lt;br /&gt;
| writtenin              = C++&lt;br /&gt;
| os                     = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX&lt;br /&gt;
| platform               = Cross-platform&lt;br /&gt;
| developmentstatus      = Active (1996-)&lt;br /&gt;
| type                   = Flight simulator&lt;br /&gt;
| license                = [[GNU General Public License]]&lt;br /&gt;
| website                = http://www.flightgear.org/&lt;br /&gt;
}}[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]&lt;br /&gt;
&lt;br /&gt;
'''FlightGear''' ( Souvent nommé '''Flightgear''' ou '''FGFS''') est un simulateur de vol sophistiqué, libre, et créé par des volontaires. FlightGear est distribué sous les termes de la [[GNU General Public License]]. Le logiciel est principalement codé en C++.&lt;br /&gt;
&lt;br /&gt;
Des versions de plus en plus détaillées et réalistes sont distribuées depuis le début du projet, en 1996, et dorénavant tous les six mois. &lt;br /&gt;
&lt;br /&gt;
La dernière version en date est disponible à l'adresse  [http://www.flightgear.org/download/ flightgear.org/download/], fonctionnelle sur nombre de systèmes d'exploitation dont Microsoft Windows, Mac OS X, Linux, IRIX, et Solaris.&lt;br /&gt;
&lt;br /&gt;
== Histoire ==&lt;br /&gt;
{{main article|FlightGear History}}&lt;br /&gt;
&lt;br /&gt;
Le développement de flightgear commença par un échange sur internet en 1996, contenant un code inédit de graphiques 3D. Le développement d'une version basée sur [[OpenGL]] fut menée par Curtis Olson dès 1997. Nombre de volontaires ont contribués au projet, depuis.&lt;br /&gt;
&lt;br /&gt;
FlightGear associe d'autres ressources libres, comme plusieurs modèles de vol dont JSBsim, ainsi que certaines données de paysages, concues par la NASA et disponibles gratuitement. les premières librairies fontionnelles utilisant l'Opengl pour la 3D furent réalisées en 1997.  Un développement fulgurant et professionnel de nouvelles versions pendant plusieurs années fut à l'origine de la sophistication du logiciel. Depuis 2001, L'équipe Flightgear sort de nouvelles versions &amp;quot;beta&amp;quot; régulièrement, et dès 2005, la qualité du software conduit à des critiques plus appliquées, et plus sérieuses, accompagnée par une popularité grandissante. L'année 2007 marque une symbolique sortie du développement secondaire avec la distribution de la version 1.0.0 , 10 ans après la première version en 1997.&lt;br /&gt;
&lt;br /&gt;
[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]&lt;br /&gt;
&lt;br /&gt;
En 2008, la version 1.9.0 de FlightGear introduit un majeur changement de [[PLIB]] à [[OSG]], qui causa temporairement la perte de fonctionalités comme les nuages 3D ou les ombres, tandis que les nouvelles, comme les particules, impacte sur le degré de réalisme de la simulation. &lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
&lt;br /&gt;
Le moteur de simulation dans FlightGear est appelé [[SimGear]]. Il est utile à la fois pour l'utilisateur normal et dans les milieux universitaires et de recherche, pour le developpement et la recherche d'idées sur la simulation de vol.&lt;br /&gt;
&lt;br /&gt;
La flexibité de FlightGear est illustrée par la grande quantité d'appareils, qui y sont disponibles: Nous pouvons compter plusieurs catégories, dont: [[:Category:Gliders|glider]]s,[[Helicopter]]s, [[:Category:Airliners|airliners]],[[Military aircraft|fighter jets]]. Ces modèles ont été créés par des développeurs différents.&lt;br /&gt;
&lt;br /&gt;
Les aéronefs de Flightgear utilisent un au moins des trois modèles de vols JSBSim, YAsim, ou UIUC depuis la version 0.9.10. Pour l'instant seulement un seul moteur de simulation est utilisé, TerraGear. Les effects météo (cf.[[Weather]]) sont très complexes et réalistes, de même que les effects visuels qui y sont liés: nuages 3D, effects lumineux, effects d'horizon, et heure de la journée.&lt;br /&gt;
&lt;br /&gt;
=== Flight Dynamics Models, alias...FDM ===&lt;br /&gt;
&lt;br /&gt;
Le modèle de vol [[Flight Dynamics Models]] ou (FDM) ) simule le comportement de l'avion dans une situation précise. FlightGear utilise beaucoup de scripts et de FDM codés de manière interne au programme . &lt;br /&gt;
Tout aéronef ''doit'' être programmé pour obéir à un de ces modèles de vol. Actuellement FlightGear est le seul simulateur utilisant autant de FDMs, et dont au moins trois sont créés de manière spécifique pour le logiciel.&lt;br /&gt;
Les plus anciennes versions utilisaient [[LaRCsim]], FDM créé par la NASA, mais il fut remplacé par des modèles plus flexibles. &lt;br /&gt;
&lt;br /&gt;
* [[JSBSim]] - Depuis 2000, le FDM par défaut de flightgear.&lt;br /&gt;
* [[YASim]] - Autre FDM utilisant une approche différente. Fait partie de la version 0.7.9 en 2002.&lt;br /&gt;
* [[UIUC]] - Autre FDM inclut, developpé par le ''UIUC Applied Aerodynamics Group'' à l' Université de l'Illinois à Urbana-Champaign, également partit de LaRCsim.&lt;br /&gt;
* FlightGear peut aussi être configuré pour utiliser des entrées de FDM externes, comme [[MATLAB]].&lt;br /&gt;
* D'autres FDM marginaux pour un aéronef spécifique ont été écrits, comme les appareils volants &amp;quot;plus légers que l'air&amp;quot;, tel le Zeppelin, ballon contenu dans la version de base de flightgear.&lt;br /&gt;
&lt;br /&gt;
=== FlightGear dependencies ===&lt;br /&gt;
&lt;br /&gt;
Contrairement à certains titres commerciaux, le but principal du projet est la sortie d'un code source. Pour le rendre utile, il faut le compiler sur une quelconque système d'exploitation. Les librairies utilisées par flightgear ont changées au cours du temps, et des versions. la principale est [[SimGear]], qui est le moteur de simulation necessaire à flightgear. Dans le cas de [[TerraGear]], il ne s'agit pas de secteur de dépendance, mais seulement d'un nom pour le programme de ''données de terrain'' dans le simulateur. OpenAL est utilisée pour  le son d'entrée/sortie, dont un support pour SDL (depuis 0.9.5). PLIB est utilisé pour le support matériel (driver), anciennement utilisé par le pilote son, actuellement repris par OpenAl. [[OpenGL]] est utilisé pour ses routines graphiques intégrées, et il est bon de savoir que d'autres accélérations matérielles (directX) ne sont pas prises en charge. [[OpenSceneGraph]] est aussi intégré dans FlightGear. Enfin, Simple DirectMedia Layer est une logitèque qui est utilisée pour compiler. certains de ces secteurs de dépendances varient, la plateforme utilisée faisant la différence. Les utilisateurs de FlightGear doivent à la fois compiler le code eux-même, ou trouver un tiers pour distribuer un fichier binaire.&lt;br /&gt;
&lt;br /&gt;
== Hardware ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Le matériel nécessaire pour faire tourner FlightGear est relativement faible, bien qu'il faut savoir que les cartes graphiques les plus compatibles sont de la série Nvidia . Les premières versions du simulateur avaient le support des cartes 3dfx, bien que la proportion de rencontrer ce genre de cartes a chutée de la même manière que la configuration matérielle moyenne s'est accrue.&lt;br /&gt;
&lt;br /&gt;
[[File:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]&lt;br /&gt;
&lt;br /&gt;
== Add-ons et tuning ==&lt;br /&gt;
&lt;br /&gt;
Certains programmes sont soit intégrés dans flightgear (&amp;quot;dependencies&amp;quot;),soit font une action, une opération à travers lui. Quelque uns sont intégrés dans la distribution populaire du simulateur (pour une plateforme spécifique,quelques fois) mais créées pour le projet, quand d'autres sont étrangers à Flightgear bien que supportés par la communauté. &lt;br /&gt;
&lt;br /&gt;
Un logiciel important est l'interface destinée à lancer FlightGear. A ses débuts, FlightGear ne pouvait se lancer que par l'interface DOS ([[command line]]). Cependant, ''the FlightGear Launch Control'' fut inclus dans le FGrun (''[[FG launcher]]'') depuis la version 0.9.3 en 2003. ''[[KFreeFlight]]'' est un &amp;quot;launcher/front-end&amp;quot; pour KDE. ''FGTools'' est une fenêtre alternative de lancement. ''FGKicker'' est une front-end basée GTK+ .&lt;br /&gt;
&lt;br /&gt;
D'autres projets très utiles contiennent des éditeurs de données de terrain. ''[[Atlas]]'' est un support de cartes aéronautiques pour FlightGear; ''[[Kelpie Flight Planner]]'' est un plannificateur de vol Java pour FlightGear. ''[[FlightGear Scenery Designer]]'' est un éditeur de scènes. Le ''[[World Custom Scenery Project]]'' est un projet destiné à coordiner tous les efforts effectués sur les scènes et les données de terrain. Enfin, ''[[TaxiDraw]]'' est un éditeur de pistes et taxiway, permettant un meilleur confort visuel.&lt;br /&gt;
&lt;br /&gt;
=== Aéronefs ===&lt;br /&gt;
{{Main article|Table of models}}&lt;br /&gt;
&lt;br /&gt;
FlightGear commença avec un avion inclut dans le FDM LaRCsim, le Navion, qui fut remplacé par un Cessna 170 en 2000. Le développement des trois FDM, en particulier YASim, apporta son lot de nouveaux avions: Plus de 350 aéronefs et 450 livrées uniques, sont disponibles pour la version 2.0.0, alors que seulement quelques uns sont inclus dans le package de base.&lt;br /&gt;
[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]&lt;br /&gt;
&lt;br /&gt;
=== Scènes ===&lt;br /&gt;
{{Main article|Scenery}}&lt;br /&gt;
Le monde de FlightGears ([[world scenery]]) couvre des données d'élévation et de terrain du monde entier. Les moulins à vents, les ponts et autres objets sont présents dans la base de données  ([[FlightGear Scenery Database|Scenery Database]]) .&lt;br /&gt;
Vous pouvez téléchargez le monde entier sur le site officiel de flightgear, indiqué plus haut.&lt;br /&gt;
&lt;br /&gt;
=== Mise en réseau et multi-écrans ===&lt;br /&gt;
&lt;br /&gt;
Plusieurs options de réseaux permettent une communication entre flightgear et ses instances. Un serveur multijoueurs ([[Multiplayer Howto|multiplayer]]) fut disponible pour utiliser FlightGear sur un réseau local dans un environnement à plusieurs aéronefs. Il peut être usé pour les vols en formation, ou la simulation de l' [[ATC|control tower]]. Le Multijoueurs fut bientôt élargit pour permettre aux joueurs de voler sur Internet. D'autres fonctionalitées comme la carte Google Map permettant de connaître la position  de chaque avions dans flightgear existent.&lt;br /&gt;
Plusieurs instances de FlightGear peuvent être synchronisées pour permettre un environnement multi-moniteur. Si toutes ces instances fonctionnent aux mêmes Frames per second, il est possible d'obtenir une bonne synchronisation agréable, et réaliste.&lt;br /&gt;
&lt;br /&gt;
== FlightGear code vs. binaries ==&lt;br /&gt;
&lt;br /&gt;
Les dates de la sortie du logiciel consiste à la distribution du code, et nond'un executable. Pour créer un programme efficace, il faut le compiler, ce qui requiert certaines logithèques, dont certaines sont générales, tandis que d'autres sont spécifiques au système. En revanche, puisque la tâche demande nombre de compétences informatiques pour la plupart des utilisateurs grand public, d'autres contributeurs travailleront à rendre les binaires disponibles pour une plate-forme spécifique. Les performances, dépendent de la date de la mise à jour du code. Par exemple, certains travaux plus anciens binaires marchent sur Mac OS 9, mais les nouvelles versions  nécessitent certaines versions du Mac OS.&lt;br /&gt;
&lt;br /&gt;
Par exemple, fin 2007, la dernière version du code était 0.9.11-pre1 (pre-release) et 0.9.10 (final). Toutefois, la date de distribution des fichiers binaires réels  varient considérablement. Des exemples de binaires réels disponibles un an après la sortie de la version 0.9.10 du code:&lt;br /&gt;
&lt;br /&gt;
* Win-32 has ~138 Mb package (v0.9.10) (For Windows 98, 2000, ME, 32-bit XP) &lt;br /&gt;
* Linux- pre-built packages for specific Linux distributions&lt;br /&gt;
** Slackware package (v0.9.10), Fedora Core 2,3,4 packages (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) &lt;br /&gt;
* Solaris packages either for it running on either SPARC or x86 processors.&lt;br /&gt;
** SPARC (v0.9.8),  x86 (v0.9.9) &lt;br /&gt;
* Silicon Graphics IRIX&lt;br /&gt;
** SGI binaries for (v0.9.9) &lt;br /&gt;
* Mac OS X&lt;br /&gt;
** Mac OS 10.4 (v0.9.10) &lt;br /&gt;
** Mac OS 10.3 (v0.9.9) &lt;br /&gt;
* FreeBSD has a package for(v0.9.10)&lt;br /&gt;
&lt;br /&gt;
==Applications et usages==&lt;br /&gt;
{{Main article|Professional and educational FlightGear users}}&lt;br /&gt;
FlightGear a été utilisé dans une série de projets dans le milieu universitaire et de l'industrie (y compris la NASA) ainsi que dans des simulateurs &amp;quot;maison&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Reviews ==&lt;br /&gt;
{{Main article|FlightGear Reviews}}&lt;br /&gt;
&lt;br /&gt;
== liens externes ==&lt;br /&gt;
{{Main article|Links}}&lt;br /&gt;
* [http://www.flightgear.org Official website]&lt;br /&gt;
* [http://fgfs.i-net.hu/ Community website] &lt;br /&gt;
&lt;br /&gt;
{{Appendix|all|&lt;br /&gt;
* {{cite web |url=http://www.flightgear.org/proposal-3.0.1 |title=Original FlightGear Proposal |last=Murr |first=David L. |date=11 September, 1998 }}&lt;br /&gt;
* {{cite web |url=http://en.wikipedia.org/wiki/FlightGear |title=FlightGear |publisher=Wikipedia }}&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[[de:FlightGear]]&lt;br /&gt;
[[es:FlightGear]]&lt;br /&gt;
[[nl:FlightGear]]&lt;br /&gt;
[[pt:FlightGear]]&lt;br /&gt;
[[en:FlightGear]]&lt;br /&gt;
[[Category:FlightGear| ]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=FlightGear&amp;diff=53646</id>
		<title>FlightGear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=FlightGear&amp;diff=53646"/>
		<updated>2012-08-30T14:45:19Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Software&lt;br /&gt;
| title                  = FlightGear&lt;br /&gt;
| logo                   = fglogosm.jpg&lt;br /&gt;
| image                  = FlightGear - 1903 Wright Flyer.jpg&lt;br /&gt;
| alt                    = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9&lt;br /&gt;
| developedby            = FlightGear Developers &amp;amp; Contributors&lt;br /&gt;
| initialrelease         = July 17, 1997&lt;br /&gt;
| latestrelease          = 2.8.0 (February 17, 2012)&lt;br /&gt;
| writtenin              = C++&lt;br /&gt;
| os                     = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX&lt;br /&gt;
| platform               = Cross-platform&lt;br /&gt;
| developmentstatus      = Active (1996-)&lt;br /&gt;
| type                   = Flight simulator&lt;br /&gt;
| license                = [[GNU General Public License]]&lt;br /&gt;
| website                = http://www.flightgear.org/&lt;br /&gt;
}}[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]&lt;br /&gt;
&lt;br /&gt;
'''FlightGear Flight Simulator''' (often shortened to '''FlightGear''' or '''FGFS''') is a sophisticated free, completely open-source flight simulator framework, created by volunteers. FlightGear is released under the terms of the [[GNU General Public License]]. FlightGear is mostly written in the C++ programming language.&lt;br /&gt;
&lt;br /&gt;
Increasingly detailed and realistic versions of FlightGear have been released every year since the project was started in 1996.&lt;br /&gt;
&lt;br /&gt;
The latest public release is available as a free download at [http://www.flightgear.org/download/ flightgear.org/download/], with specific builds for a variety of operating systems including Microsoft Windows (Win 32), Mac OS X, Linux, IRIX, and Solaris.&lt;br /&gt;
&lt;br /&gt;
== History ==&lt;br /&gt;
{{main article|FlightGear History}}&lt;br /&gt;
&lt;br /&gt;
FlightGear development started with an online proposal in 1996, using custom 3D graphics code. Development of an [[OpenGL]] based version was spearheaded by Curtis Olson starting in 1997. Many people have contributed to the project in the years since its inception.&lt;br /&gt;
&lt;br /&gt;
FlightGear incorporated other open-source resources, including the LaRCsim flight model from NASA, and freely available elevation data. The first working binaries, using OpenGL for 3D graphic code, came out in 1997.  Enthusiastic development of newer versions for several years resulted in progressively more stable and advanced versions. By 2001, the team was releasing new beta versions regularly, and by 2005, the maturity of software lead to more widespread reviews, and increased popularity. 2007 marked a formal transition out of beta development with the release of version 1.0.0, ten years after FlightGear's first release in 1997.&lt;br /&gt;
&lt;br /&gt;
[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]&lt;br /&gt;
&lt;br /&gt;
In 2008, version 1.9.0 of FlightGear included a major change from [[PLIB]] to [[OSG]], which caused the temporarily loss of some features like 3D clouds and shadows, while newly added features, such as particles, imparted another degree of realism to the simulation.  &lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
&lt;br /&gt;
The simulation engine in FlightGear is called [[SimGear]]. It is used both as an end-user application and in academic and research environments, for the development and pursuit of flight simulation ideas.&lt;br /&gt;
&lt;br /&gt;
This customizability of FlightGear is illustrated by the wide range of aircraft models that are available in FlightGear, from [[:Category:Gliders|glider]]s to [[Helicopter]]s, and from [[:Category:Airliners|airliners]] to [[Military aircraft|fighter jets]]. These aircraft models have been contributed by many different people.&lt;br /&gt;
&lt;br /&gt;
The FlightGear aircraft use one of three main data models JSBSim, YAsim, or UIUC as of version 0.9.10. Currently only one terrain engine is used, TerraGear. Weather effects include 3D clouds, lighting effects, and time of day.&lt;br /&gt;
&lt;br /&gt;
=== Flight Dynamics Models ===&lt;br /&gt;
[[Flight Dynamics Models]] (FDM) are how the flight for an aircraft is simulated in the program. FlightGear uses a variety of internally written and imported flight model projects. Any aircraft must be programmed to use one of these models. Currently FlightGear is the only flight  graphical flight simulator all the FDM are used for, and UIUC and YASim were developed specifically for FlightGear. &lt;br /&gt;
&lt;br /&gt;
Early version used a FDM based on [[LaRCsim]] by NASA, which was replaced with more flexible FDM. &lt;br /&gt;
&lt;br /&gt;
* [[JSBSim]] - the default flight dynamics model software since 2000.&lt;br /&gt;
* [[YASim]] - another FDM using different calculation method. Introduced starting in 0.7.9 in 2002.&lt;br /&gt;
* [[UIUC]] - another included FDM, developed by the UIUC Applied Aerodynamics Group at University of Illinois at Urbana-Champaign, also made use of LaRCsim.&lt;br /&gt;
* FlightGear can also be setup to render using inputs from an external FDM source, such as from [[MATLAB]].&lt;br /&gt;
* Other custom FDM for a specific aircraft type have been written, such as for lighter than air aircraft.&lt;br /&gt;
&lt;br /&gt;
=== FlightGear dependencies ===&lt;br /&gt;
Unlike commercial software titles, the main output of the project is simply the release of a collection of code. To turn it into a usable program it must be compiled for a given platform. The software libraries used to create FlightGear have varied over time. The main one is [[SimGear]], which is the underlying sim engine for FlightGear. [[TerraGear]] is not a dependency, but simply a name for the default terrain data program in FlightGear. OpenAL is used for sound/audio software, including support for SDL (since 0.9.5). PLIB is used for hardware support routines, formerly used for sound support also which was taken over by OpenAL. [[OpenGL]] is used for its integrated 3D graphics routines, and other hardware acceleration (namely DirectX) is not supported. [[OpenSceneGraph]] is also integrated into FlightGear. Finally, Simple DirectMedia Layer is a software library which is used for compiling. Some of the dependencies vary depending on which platform the code is being compiled for. FlightGear users must either compile the code themselves, or find a third party to release a binary, if it is not among the ones available from the project.&lt;br /&gt;
&lt;br /&gt;
== Hardware ==&lt;br /&gt;
Hardware needed for FlightGear is narrow to machines that support [[OpenGL]] and 3D hardware acceleration, with NVIDIA hardware having better support. Early versions had support for 3dfx cards, though this dropped as hardware requirements increased.&lt;br /&gt;
&lt;br /&gt;
[[File:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]&lt;br /&gt;
== Add-ons and customization ==&lt;br /&gt;
There are programs that are either integrated into FlightGear (dependencies) or perform a function with it. Some of these are included in the release of FlightGear for a specific platform but made by the project, while others are independently distributed but are hosted by the FlightGear project. &lt;br /&gt;
&lt;br /&gt;
One major additional software is the actual interface for launching an executable of FlightGear. For most of its early life FlightGear was only run through [[command line]] interfaces. However, the FlightGear Launch Control has been included with the ''[[FG launcher]]'' front-end since 0.9.3 in 2003. ''[[KFreeFlight]]'' is a launcher/front-end for KDE. ''FGTools'' is an alternative windows launcher front-end. ''FGKicker'' is a GTK+ based front-end.&lt;br /&gt;
&lt;br /&gt;
Other significant programs include editors and projects for Terrain Data. ''[[Atlas]]'' is a chart/map support for FlightGear; ''[[Kelpie Flight Planner]]'' is a Java based flight planner for FlightGear. ''[[FlightGear Scenery Designer]]'' is a FlightGear scenery editor for working with terrain data. The ''[[World Custom Scenery Project]]'' is a project coordinating custom scenery efforts. Finally, ''[[TaxiDraw]]'' is an editor for airport runways and taxiways.&lt;br /&gt;
&lt;br /&gt;
=== Aircraft ===&lt;br /&gt;
{{Main article|Table of models}}&lt;br /&gt;
&lt;br /&gt;
FlightGear started out with an aircraft included in NASA's LaRCsim, a Navion, which was replaced by a Cessna 172 by 2000. UIUC as well as JSBsim development brought several more aircraft with them, as did the development of YASim which have since become the main FDM used in FG. Over 350 aircraft in more than 450 unique liveries, are available for version 2.0.0, although only a few are included in the base package.&lt;br /&gt;
&lt;br /&gt;
[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]&lt;br /&gt;
&lt;br /&gt;
=== Scenery ===&lt;br /&gt;
{{Main article|Scenery}}&lt;br /&gt;
FlightGears [[world scenery]] project contains elevation and landclass data of the enitre world. Objects -like terminals, windmills and bridges- are collected in the [[FlightGear Scenery Database|Scenery Database]].&lt;br /&gt;
&lt;br /&gt;
=== Networking and multi-display ===&lt;br /&gt;
Several networking options allow FlightGear to communicate with other instances of FlightGear. A [[Multiplayer Howto|multiplayer]] protocol is available for using FlightGear on a local network in a multi aircraft environment. This could be used for formation flight or [[ATC|control tower]] simulation. Multiplayer was soon expanded to allow playing over the internet. Other features include a Google maps based moving up that allows users to observe where other players are.&lt;br /&gt;
&lt;br /&gt;
Several instances of FlightGear can be synchronized to allow for a multi-monitor environment. If all instances are running at the same frame rate consistently, it is possible to get good and tight synchronization between displays.&lt;br /&gt;
&lt;br /&gt;
== FlightGear code vs. binaries ==&lt;br /&gt;
Unlike most commercial software, the project release dates only apply to a release of code, not an executable program. To create a runnable program the code must be compiled, which requires several specific libraries, including some general ones and, in some cases some platform specific ones. However, since this too difficult for most mainstream users, other contributors will work to make binaries available for a specific platform and operating system. These packages vary in their stability, performance, dependencies, and how up to date they are with the code base. For example, some older binaries work on Mac OS 9 but newer releases require specific Mac OS X versions.&lt;br /&gt;
&lt;br /&gt;
For example, by late 2007 the latest code release was 0.9.11-pre1 (pre-release) and 0.9.10 (final). However, the actual binaries available vary significantly. Examples of actual binaries available a year after the release of the 0.9.10 code release:&lt;br /&gt;
&lt;br /&gt;
* Win-32 has ~138 Mb package (v0.9.10) (For Windows 98, 2000, ME, 32-bit XP) &lt;br /&gt;
* Linux- pre-built packages for specific Linux distributions&lt;br /&gt;
** Slackware package (v0.9.10), Fedora Core 2,3,4 packages (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) &lt;br /&gt;
* Solaris packages either for it running on either SPARC or x86 processors.&lt;br /&gt;
** SPARC (v0.9.8),  x86 (v0.9.9) &lt;br /&gt;
* Silicon Graphics IRIX&lt;br /&gt;
** SGI binaries for (v0.9.9) &lt;br /&gt;
* Mac OS X&lt;br /&gt;
** Mac OS 10.4 (v0.9.10) &lt;br /&gt;
** Mac OS 10.3 (v0.9.9) &lt;br /&gt;
* FreeBSD has a package for(v0.9.10)&lt;br /&gt;
&lt;br /&gt;
==Applications and usages==&lt;br /&gt;
{{Main article|Professional and educational FlightGear users}}&lt;br /&gt;
FlightGear has been used in a range of projects in academia and industry (including NASA) and even home-built cockpits.&lt;br /&gt;
&lt;br /&gt;
== Reviews ==&lt;br /&gt;
{{Main article|FlightGear Reviews}}&lt;br /&gt;
&lt;br /&gt;
== External links ==&lt;br /&gt;
{{Main article|Links}}&lt;br /&gt;
* [http://www.flightgear.org Official website]&lt;br /&gt;
* [http://fgfs.i-net.hu/ Community website] &lt;br /&gt;
&lt;br /&gt;
{{Appendix|all|&lt;br /&gt;
* {{cite web |url=http://www.flightgear.org/proposal-3.0.1 |title=Original FlightGear Proposal |last=Murr |first=David L. |date=11 September, 1998 }}&lt;br /&gt;
* {{cite web |url=http://en.wikipedia.org/wiki/FlightGear |title=FlightGear |publisher=Wikipedia }}&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[[de:FlightGear]]&lt;br /&gt;
[[es:FlightGear]]&lt;br /&gt;
[[nl:FlightGear]]&lt;br /&gt;
[[pt:FlightGear]]&lt;br /&gt;
[[fr:FlightGear]]&lt;br /&gt;
[[Category:FlightGear| ]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53645</id>
		<title>Fr/FlightGear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53645"/>
		<updated>2012-08-30T14:41:50Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Software&lt;br /&gt;
| title                  = FlightGear&lt;br /&gt;
| logo                   = fglogosm.jpg&lt;br /&gt;
| image                  = FlightGear - 1903 Wright Flyer.jpg&lt;br /&gt;
| alt                    = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9&lt;br /&gt;
| developedby           = FlightGear Developers &amp;amp; Contributors&lt;br /&gt;
| initialrelease         = July 17, 1997&lt;br /&gt;
| latestrelease          = 2.8.0 (February 17, 2012)&lt;br /&gt;
| writtenin              = C++&lt;br /&gt;
| os                     = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX&lt;br /&gt;
| platform               = Cross-platform&lt;br /&gt;
| developmentstatus      = Active (1996-)&lt;br /&gt;
| type                   = Flight simulator&lt;br /&gt;
| license                = [[GNU General Public License]]&lt;br /&gt;
| website                = http://www.flightgear.org/&lt;br /&gt;
}}[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]&lt;br /&gt;
&lt;br /&gt;
'''FlightGear''' ( Souvent nommé '''Flightgear''' ou '''FGFS''') est un simulateur de vol sophistiqué, libre, et créé par des volontaires. FlightGear est distribué sous les termes de la [[GNU General Public License]]. Le logiciel est principalement codé en C++.&lt;br /&gt;
&lt;br /&gt;
Des versions de plus en plus détaillées et réalistes sont distribuées depuis le début du projet, en 1996, et dorénavant tous les six mois. &lt;br /&gt;
&lt;br /&gt;
La dernière version en date est disponible à l'adresse  [http://www.flightgear.org/download/ flightgear.org/download/], fonctionnelle sur nombre de systèmes d'exploitation dont Microsoft Windows, Mac OS X, Linux, IRIX, et Solaris.&lt;br /&gt;
&lt;br /&gt;
== Histoire ==&lt;br /&gt;
{{main article|FlightGear History}}&lt;br /&gt;
&lt;br /&gt;
Le développement de flightgear commença par un échange sur internet en 1996, contenant un code inédit de graphiques 3D. Le développement d'une version basée sur [[OpenGL]] fut menée par Curtis Olson dès 1997. Nombre de volontaires ont contribués au projet, depuis.&lt;br /&gt;
&lt;br /&gt;
FlightGear associe d'autres ressources libres, comme plusieurs modèles de vol dont JSBsim, ainsi que certaines données de paysages, concues par la NASA et disponibles gratuitement. les premières librairies fontionnelles utilisant l'Opengl pour la 3D furent réalisées en 1997.  Un développement fulgurant et professionnel de nouvelles versions pendant plusieurs années fut à l'origine de la sophistication du logiciel. Depuis 2001, L'équipe Flightgear sort de nouvelles versions &amp;quot;beta&amp;quot; régulièrement, et dès 2005, la qualité du software conduit à des critiques plus appliquées, et plus sérieuses, accompagnée par une popularité grandissante. L'année 2007 marque une symbolique sortie du développement secondaire avec la distribution de la version 1.0.0 , 10 ans après la première version en 1997.&lt;br /&gt;
&lt;br /&gt;
[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]&lt;br /&gt;
&lt;br /&gt;
En 2008, la version 1.9.0 de FlightGear introduit un majeur changement de [[PLIB]] à [[OSG]], qui causa temporairement la perte de fonctionalités comme les nuages 3D ou les ombres, tandis que les nouvelles, comme les particules, impacte sur le degré de réalisme de la simulation. &lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
&lt;br /&gt;
Le moteur de simulation dans FlightGear est appelé [[SimGear]]. Il est utile à la fois pour l'utilisateur normal et dans les milieux universitaires et de recherche, pour le developpement et la recherche d'idées sur la simulation de vol.&lt;br /&gt;
&lt;br /&gt;
La flexibité de FlightGear est illustrée par la grande quantité d'appareils, qui y sont disponibles: Nous pouvons compter plusieurs catégories, dont: [[:Category:Gliders|glider]]s,[[Helicopter]]s, [[:Category:Airliners|airliners]],[[Military aircraft|fighter jets]]. Ces modèles ont été créés par des développeurs différents.&lt;br /&gt;
&lt;br /&gt;
Les aéronefs de Flightgear utilisent un au moins des trois modèles de vols JSBSim, YAsim, ou UIUC depuis la version 0.9.10. Pour l'instant seulement un seul moteur de simulation est utilisé, TerraGear. Les effects météo (cf.[[Weather]]) sont très complexes et réalistes, de même que les effects visuels qui y sont liés: nuages 3D, effects lumineux, effects d'horizon, et heure de la journée.&lt;br /&gt;
&lt;br /&gt;
=== Flight Dynamics Models, alias...FDM ===&lt;br /&gt;
&lt;br /&gt;
Le modèle de vol [[Flight Dynamics Models]] ou (FDM) ) simule le comportement de l'avion dans une situation précise. FlightGear utilise beaucoup de scripts et de FDM codés de manière interne au programme . &lt;br /&gt;
Tout aéronef ''doit'' être programmé pour obéir à un de ces modèles de vol. Actuellement FlightGear est le seul simulateur utilisant autant de FDMs, et dont au moins trois sont créés de manière spécifique pour le logiciel.&lt;br /&gt;
Les plus anciennes versions utilisaient [[LaRCsim]], FDM créé par la NASA, mais il fut remplacé par des modèles plus flexibles. &lt;br /&gt;
&lt;br /&gt;
* [[JSBSim]] - Depuis 2000, le FDM par défaut de flightgear.&lt;br /&gt;
* [[YASim]] - Autre FDM utilisant une approche différente. Fait partie de la version 0.7.9 en 2002.&lt;br /&gt;
* [[UIUC]] - Autre FDM inclut, developpé par le ''UIUC Applied Aerodynamics Group'' à l' Université de l'Illinois à Urbana-Champaign, également partit de LaRCsim.&lt;br /&gt;
* FlightGear peut aussi être configuré pour utiliser des entrées de FDM externes, comme [[MATLAB]].&lt;br /&gt;
* D'autres FDM marginaux pour un aéronef spécifique ont été écrits, comme les appareils volants &amp;quot;plus légers que l'air&amp;quot;, tel le Zeppelin, ballon contenu dans la version de base de flightgear.&lt;br /&gt;
&lt;br /&gt;
=== FlightGear dependencies ===&lt;br /&gt;
&lt;br /&gt;
Contrairement à certains titres commerciaux, le but principal du projet est la sortie d'un code source. Pour le rendre utile, il faut le compiler sur une quelconque système d'exploitation. Les librairies utilisées par flightgear ont changées au cours du temps, et des versions. la principale est [[SimGear]], qui est le moteur de simulation necessaire à flightgear. Dans le cas de [[TerraGear]], il ne s'agit pas de secteur de dépendance, mais seulement d'un nom pour le programme de ''données de terrain'' dans le simulateur. OpenAL est utilisée pour  le son d'entrée/sortie, dont un support pour SDL (depuis 0.9.5). PLIB est utilisé pour le support matériel (driver), anciennement utilisé par le pilote son, actuellement repris par OpenAl. [[OpenGL]] est utilisé pour ses routines graphiques intégrées, et il est bon de savoir que d'autres accélérations matérielles (directX) ne sont pas prises en charge. [[OpenSceneGraph]] est aussi intégré dans FlightGear. Enfin, Simple DirectMedia Layer est une logitèque qui est utilisée pour compiler. certains de ces secteurs de dépendances varient, la plateforme utilisée faisant la différence. Les utilisateurs de FlightGear doivent à la fois compiler le code eux-même, ou trouver un tiers pour distribuer un fichier binaire.&lt;br /&gt;
&lt;br /&gt;
== Hardware ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Le matériel nécessaire pour faire tourner FlightGear est relativement faible, bien qu'il faut savoir que les cartes graphiques les plus compatibles sont de la série Nvidia . Les premières versions du simulateur avaient le support des cartes 3dfx, bien que la proportion de rencontrer ce genre de cartes a chutée de la même manière que la configuration matérielle moyenne s'est accrue.&lt;br /&gt;
&lt;br /&gt;
[[File:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]&lt;br /&gt;
&lt;br /&gt;
== Add-ons et tuning ==&lt;br /&gt;
&lt;br /&gt;
Certains programmes sont soit intégrés dans flightgear (&amp;quot;dependencies&amp;quot;),soit font une action, une opération à travers lui. Quelque uns sont intégrés dans la distribution populaire du simulateur (pour une plateforme spécifique,quelques fois) mais créées pour le projet, quand d'autres sont étrangers à Flightgear bien que supportés par la communauté. &lt;br /&gt;
&lt;br /&gt;
Un logiciel important est l'interface destinée à lancer FlightGear. A ses débuts, FlightGear ne pouvait se lancer que par l'interface DOS ([[command line]]). Cependant, ''the FlightGear Launch Control'' fut inclus dans le FGrun (''[[FG launcher]]'') depuis la version 0.9.3 en 2003. ''[[KFreeFlight]]'' est un &amp;quot;launcher/front-end&amp;quot; pour KDE. ''FGTools'' est une fenêtre alternative de lancement. ''FGKicker'' est une front-end basée GTK+ .&lt;br /&gt;
&lt;br /&gt;
D'autres projets très utiles contiennent des éditeurs de données de terrain. ''[[Atlas]]'' est un support de cartes aéronautiques pour FlightGear; ''[[Kelpie Flight Planner]]'' est un plannificateur de vol Java pour FlightGear. ''[[FlightGear Scenery Designer]]'' est un éditeur de scènes. Le ''[[World Custom Scenery Project]]'' est un projet destiné à coordiner tous les efforts effectués sur les scènes et les données de terrain. Enfin, ''[[TaxiDraw]]'' est un éditeur de pistes et taxiway, permettant un meilleur confort visuel.&lt;br /&gt;
&lt;br /&gt;
=== Aéronefs ===&lt;br /&gt;
{{Main article|Table of models}}&lt;br /&gt;
&lt;br /&gt;
FlightGear commença avec un avion inclut dans le FDM LaRCsim, le Navion, qui fut remplacé par un Cessna 170 en 2000. Le développement des trois FDM, en particulier YASim, apporta son lot de nouveaux avions: Plus de 350 aéronefs et 450 livrées uniques, sont disponibles pour la version 2.0.0, alors que seulement quelques uns sont inclus dans le package de base.&lt;br /&gt;
[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]&lt;br /&gt;
&lt;br /&gt;
=== Scènes ===&lt;br /&gt;
{{Main article|Scenery}}&lt;br /&gt;
Le monde de FlightGears ([[world scenery]]) couvre des données d'élévation et de terrain du monde entier. Les moulins à vents, les ponts et autres objets sont présents dans la base de données  ([[FlightGear Scenery Database|Scenery Database]]) .&lt;br /&gt;
Vous pouvez téléchargez le monde entier sur le site officiel de flightgear, indiqué plus haut.&lt;br /&gt;
&lt;br /&gt;
=== Mise en réseau et multi-écrans ===&lt;br /&gt;
&lt;br /&gt;
Plusieurs options de réseaux permettent une communication entre flightgear et ses instances. Un serveur multijoueurs ([[Multiplayer Howto|multiplayer]]) fut disponible pour utiliser FlightGear sur un réseau local dans un environnement à plusieurs aéronefs. Il peut être usé pour les vols en formation, ou la simulation de l' [[ATC|control tower]]. Le Multijoueurs fut bientôt élargit pour permettre aux joueurs de voler sur Internet. D'autres fonctionalitées comme la carte Google Map permettant de connaître la position  de chaque avions dans flightgear existent.&lt;br /&gt;
Plusieurs instances de FlightGear peuvent être synchronisées pour permettre un environnement multi-moniteur. Si toutes ces instances fonctionnent aux mêmes Frames per second, il est possible d'obtenir une bonne synchronisation agréable, et réaliste.&lt;br /&gt;
&lt;br /&gt;
== FlightGear code vs. binaries ==&lt;br /&gt;
&lt;br /&gt;
Les dates de la sortie du logiciel consiste à la distribution du code, et nond'un executable. Pour créer un programme efficace, il faut le compiler, ce qui requiert certaines logithèques, dont certaines sont générales, tandis que d'autres sont spécifiques au système. En revanche, puisque la tâche demande nombre de compétences informatiques pour la plupart des utilisateurs grand public, d'autres contributeurs travailleront à rendre les binaires disponibles pour une plate-forme spécifique. Les performances, dépendent de la date de la mise à jour du code. Par exemple, certains travaux plus anciens binaires marchent sur Mac OS 9, mais les nouvelles versions  nécessitent certaines versions du Mac OS.&lt;br /&gt;
&lt;br /&gt;
Par exemple, fin 2007, la dernière version du code était 0.9.11-pre1 (pre-release) et 0.9.10 (final). Toutefois, la date de distribution des fichiers binaires réels  varient considérablement. Des exemples de binaires réels disponibles un an après la sortie de la version 0.9.10 du code:&lt;br /&gt;
&lt;br /&gt;
* Win-32 has ~138 Mb package (v0.9.10) (For Windows 98, 2000, ME, 32-bit XP) &lt;br /&gt;
* Linux- pre-built packages for specific Linux distributions&lt;br /&gt;
** Slackware package (v0.9.10), Fedora Core 2,3,4 packages (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) &lt;br /&gt;
* Solaris packages either for it running on either SPARC or x86 processors.&lt;br /&gt;
** SPARC (v0.9.8),  x86 (v0.9.9) &lt;br /&gt;
* Silicon Graphics IRIX&lt;br /&gt;
** SGI binaries for (v0.9.9) &lt;br /&gt;
* Mac OS X&lt;br /&gt;
** Mac OS 10.4 (v0.9.10) &lt;br /&gt;
** Mac OS 10.3 (v0.9.9) &lt;br /&gt;
* FreeBSD has a package for(v0.9.10)&lt;br /&gt;
&lt;br /&gt;
==Applications et usages==&lt;br /&gt;
{{Main article|Professional and educational FlightGear users}}&lt;br /&gt;
FlightGear a été utilisé dans une série de projets dans le milieu universitaire et de l'industrie (y compris la NASA) ainsi que dans des simulateurs &amp;quot;maison&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Reviews ==&lt;br /&gt;
{{Main article|FlightGear Reviews}}&lt;br /&gt;
&lt;br /&gt;
== liens externes ==&lt;br /&gt;
{{Main article|Links}}&lt;br /&gt;
* [http://www.flightgear.org Official website]&lt;br /&gt;
* [http://fgfs.i-net.hu/ Community website] &lt;br /&gt;
&lt;br /&gt;
{{Appendix|all|&lt;br /&gt;
* {{cite web |url=http://www.flightgear.org/proposal-3.0.1 |title=Original FlightGear Proposal |last=Murr |first=David L. |date=11 September, 1998 }}&lt;br /&gt;
* {{cite web |url=http://en.wikipedia.org/wiki/FlightGear |title=FlightGear |publisher=Wikipedia }}&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[[de:FlightGear]]&lt;br /&gt;
[[es:FlightGear]]&lt;br /&gt;
[[nl:FlightGear]]&lt;br /&gt;
[[pt:FlightGear]]&lt;br /&gt;
[[en:FlightGear]]&lt;br /&gt;
[[Category:FlightGear| ]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53635</id>
		<title>Fr/FlightGear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53635"/>
		<updated>2012-08-30T10:35:02Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Software&lt;br /&gt;
| title                  = FlightGear&lt;br /&gt;
| logo                   = fglogosm.jpg&lt;br /&gt;
| image                  = FlightGear - 1903 Wright Flyer.jpg&lt;br /&gt;
| alt                    = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9&lt;br /&gt;
| developedby           = FlightGear Developers &amp;amp; Contributors&lt;br /&gt;
| initialrelease         = July 17, 1997&lt;br /&gt;
| latestrelease          = 2.8.0 (February 17, 2012)&lt;br /&gt;
| writtenin              = C++&lt;br /&gt;
| os                     = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX&lt;br /&gt;
| platform               = Cross-platform&lt;br /&gt;
| developmentstatus      = Active (1996-)&lt;br /&gt;
| type                   = Flight simulator&lt;br /&gt;
| license                = [[GNU General Public License]]&lt;br /&gt;
| website                = http://www.flightgear.org/&lt;br /&gt;
}}[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]&lt;br /&gt;
&lt;br /&gt;
'''FlightGear''' ( Souvent nommé '''Flightgear''' ou '''FGFS''') est un simulateur de vol sophistiqué, libre, et créé par des volontaires. FlightGear est distribué sous les termes de la [[GNU General Public License]]. Le logiciel est principalement codé en C++.&lt;br /&gt;
&lt;br /&gt;
Des versions de plus en plus détaillées et réalistes sont distribuées depuis le début du projet, en 1996, et dorénavant tous les six mois. &lt;br /&gt;
&lt;br /&gt;
La dernière version en date est disponible à l'adresse  [http://www.flightgear.org/download/ flightgear.org/download/], fonctionnelle sur nombre de systèmes d'exploitation dont Microsoft Windows, Mac OS X, Linux, IRIX, et Solaris.&lt;br /&gt;
&lt;br /&gt;
== Histoire ==&lt;br /&gt;
{{main article|FlightGear History}}&lt;br /&gt;
&lt;br /&gt;
Le développement de flightgear commença par un échange sur internet en 1996, contenant un code inédit de graphiques 3D. Le développement d'une version basée sur [[OpenGL]] fut menée par Curtis Olson dès 1997. Nombre de volontaires ont contribués au projet, depuis.&lt;br /&gt;
&lt;br /&gt;
FlightGear associe d'autres ressources libres, comme plusieurs modèles de vol dont JSBsim, ainsi que certaines données de paysages, concues par la NASA et disponibles gratuitement. les premières librairies fontionnelles utilisant l'Opengl pour la 3D furent réalisées en 1997.  Un développement fulgurant et professionnel de nouvelles versions pendant plusieurs années fut à l'origine de la sophistication du logiciel. Depuis 2001, L'équipe Flightgear sort de nouvelles versions &amp;quot;beta&amp;quot; régulièrement, et dès 2005, la qualité du software conduit à des critiques plus appliquées, et plus sérieuses, accompagnée par une popularité grandissante. L'année 2007 marque une symbolique sortie du développement secondaire avec la distribution de la version 1.0.0 , 10 ans après la première version en 1997.&lt;br /&gt;
&lt;br /&gt;
[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]&lt;br /&gt;
&lt;br /&gt;
En 2008, la version 1.9.0 de FlightGear introduit un majeur changement de [[PLIB]] à [[OSG]], qui causa temporairement la perte de fonctionalités comme les nuages 3D ou les ombres, tandis que les nouvelles, comme les particules, impacte sur le degré de réalisme de la simulation. &lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
&lt;br /&gt;
Le moteur de simulation dans FlightGear est appelé [[SimGear]]. Il est utile à la fois pour l'utilisateur normal et dans les milieux universitaires et de recherche, pour le developpement et la recherche d'idées sur la simulation de vol.&lt;br /&gt;
&lt;br /&gt;
La flexibité de FlightGear est illustrée par la grande quantité d'appareils, qui y sont disponibles: Nous pouvons compter plusieurs catégories, dont: [[:Category:Gliders|glider]]s,[[Helicopter]]s, [[:Category:Airliners|airliners]],[[Military aircraft|fighter jets]]. Ces modèles ont été créés par des développeurs différents.&lt;br /&gt;
&lt;br /&gt;
Les aéronefs de Flightgear utilisent un au moins des trois modèles de vols JSBSim, YAsim, ou UIUC depuis la version 0.9.10. Pour l'instant seulement un seul moteur de simulation est utilisé, TerraGear. Les effects météo (cf.[[Weather]]) sont très complexes et réalistes, de même que les effects visuels qui y sont liés: nuages 3D, effects lumineux, effects d'horizon, et heure de la journée.&lt;br /&gt;
&lt;br /&gt;
=== Flight Dynamics Models, alias...FDM ===&lt;br /&gt;
&lt;br /&gt;
Le modèle de vol [[Flight Dynamics Models]] ou (FDM) ) simule le comportement de l'avion dans une situation précise. FlightGear utilise beaucoup de scripts et de FDM codés de manière interne au programme . &lt;br /&gt;
Tout aéronef ''doit'' être programmé pour obéir à un de ces modèles de vol. Actuellement FlightGear est le seul simulateur utilisant autant de FDMs, et dont au moins trois sont créés de manière spécifique pour le logiciel.&lt;br /&gt;
Les plus anciennes versions utilisaient [[LaRCsim]], FDM créé par la NASA, mais il fut remplacé par des modèles plus flexibles. &lt;br /&gt;
&lt;br /&gt;
* [[JSBSim]] - Depuis 2000, le FDM par défaut de flightgear.&lt;br /&gt;
* [[YASim]] - Autre FDM utilisant une approche différente. Fait partie de la version 0.7.9 en 2002.&lt;br /&gt;
* [[UIUC]] - Autre FDM inclut, developpé par le ''UIUC Applied Aerodynamics Group'' à l' Université de l'Illinois à Urbana-Champaign, également partit de LaRCsim.&lt;br /&gt;
* FlightGear peut aussi être configuré pour utiliser des entrées de FDM externes, comme [[MATLAB]].&lt;br /&gt;
* D'autres FDM marginaux pour un aéronef spécifique ont été écrits, comme les appareils volants &amp;quot;plus légers que l'air&amp;quot;, tel le Zeppelin, ballon contenu dans la version de base de flightgear.&lt;br /&gt;
&lt;br /&gt;
=== FlightGear dependencies ===&lt;br /&gt;
&lt;br /&gt;
Contrairement à certains titres commerciaux, le but principal du projet est la sortie d'un code source. Pour le rendre utile, il faut le compiler sur une quelconque système d'exploitation. Les librairies utilisées par flightgear ont changées au cours du temps, et des versions. la principale est [[SimGear]], qui est le moteur de simulation necessaire à flightgear. Dans le cas de [[TerraGear]], il ne s'agit pas de secteur de dépendance, mais seulement d'un nom pour le programme de ''données de terrain'' dans le simulateur. OpenAL est utilisée pour  le son d'entrée/sortie, dont un support pour SDL (depuis 0.9.5). PLIB est utilisé pour le support matériel (driver), anciennement utilisé par le pilote son, actuellement repris par OpenAl. [[OpenGL]] est utilisé pour ses routines graphiques intégrées, et il est bon de savoir que d'autres accélérations matérielles (directX) ne sont pas prises en charge. [[OpenSceneGraph]] est aussi intégré dans FlightGear. Enfin, Simple DirectMedia Layer est une logitèque qui est utilisée pour compiler. certains de ces secteurs de dépendances varient, la plateforme utilisée faisant la différence. Les utilisateurs de FlightGear doivent à la fois compiler le code eux-même, ou trouver un tiers pour distribuer un fichier binaire.&lt;br /&gt;
&lt;br /&gt;
== Hardware ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Le matériel nécessaire pour faire tourner FlightGear est relativement faible, bien qu'il faut savoir que les cartes graphiques les plus compatibles sont de la série Nvidia . Les premières versions du simulateur avaient le support des cartes 3dfx, bien que la proportion de rencontrer ce genre de cartes a chutée de la même manière que la configuration matérielle moyenne s'est accrue.&lt;br /&gt;
&lt;br /&gt;
[[File:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]&lt;br /&gt;
&lt;br /&gt;
== Add-ons et tuning ==&lt;br /&gt;
&lt;br /&gt;
Certains programmes sont soit intégrés dans flightgear (&amp;quot;dependencies&amp;quot;),soit font une action, une opération à travers lui. Quelque uns sont intégrés dans la distribution populaire du simulateur (pour une plateforme spécifique,quelques fois) mais créées pour le projet, quand d'autres sont étrangers à Flightgear bien que supportés par la communauté. &lt;br /&gt;
&lt;br /&gt;
Un logiciel important est l'interface destinée à lancer FlightGear. A ses débuts, FlightGear ne pouvait se lancer que par l'interface DOS ([[command line]]). Cependant, ''the FlightGear Launch Control'' fut inclus dans le FGrun (''[[FG launcher]]'') depuis la version 0.9.3 en 2003. ''[[KFreeFlight]]'' est un &amp;quot;launcher/front-end&amp;quot; pour KDE. ''FGTools'' est une fenêtre alternative de lancement. ''FGKicker'' est une front-end basée GTK+ .&lt;br /&gt;
&lt;br /&gt;
D'autres projets très utiles contiennent des éditeurs de données de terrain. ''[[Atlas]]'' est un support de cartes aéronautiques pour FlightGear; ''[[Kelpie Flight Planner]]'' est un plannificateur de vol Java pour FlightGear. ''[[FlightGear Scenery Designer]]'' est un éditeur de scènes. Le ''[[World Custom Scenery Project]]'' est un projet destiné à coordiner tous les efforts effectués sur les scènes et les données de terrain. Enfin, ''[[TaxiDraw]]'' est un éditeur de pistes et taxiway, permettant un meilleur confort visuel.&lt;br /&gt;
&lt;br /&gt;
=== Aéronefs ===&lt;br /&gt;
{{Main article|Table of models}}&lt;br /&gt;
&lt;br /&gt;
FlightGear commença avec un avion inclut dans le FDM LaRCsim, le Navion, qui fut remplacé par un Cessna 170 en 2000. Le développement des trois FDM, en particulier YASim, apporta son lot de nouveaux avions: Plus de 350 aéronefs et 450 livrées uniques, sont disponibles pour la version 2.0.0, alors que seulement quelques uns sont inclus dans le package de base.&lt;br /&gt;
[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]&lt;br /&gt;
&lt;br /&gt;
=== Scènes ===&lt;br /&gt;
{{Main article|Scenery}}&lt;br /&gt;
Le monde de FlightGears ([[world scenery]]) couvre des données d'élévation et de terrain du monde entier. Les moulins à vents, les ponts et autres objets sont présents dans la base de données  ([[FlightGear Scenery Database|Scenery Database]]) .&lt;br /&gt;
Vous pouvez téléchargez le monde entier sur le site officiel de flightgear, indiqué plus haut.&lt;br /&gt;
&lt;br /&gt;
=== Mise en réseau et multi-écrans ===&lt;br /&gt;
&lt;br /&gt;
Plusieurs options de réseaux permettent une communication entre flightgear et ses instances. Un serveur multijoueurs ([[Multiplayer Howto|multiplayer]]) fut disponible pour utiliser FlightGear sur un réseau local dans un environnement à plusieurs aéronefs. Il peut être usé pour les vols en formation, ou la simulation de l' [[ATC|control tower]]. Le Multijoueurs fut bientôt élargit pour permettre aux joueurs de voler sur Internet. D'autres fonctionalitées comme la carte Google Map permettant de connaître la position  de chaque avions dans flightgear existent.&lt;br /&gt;
Plusieurs instances de FlightGear peuvent être synchronisées pour permettre un environnement multi-moniteur. Si toutes ces instances fonctionnent aux mêmes Frames per second, il est possible d'obtenir une bonne synchronisation agréable, et réaliste.&lt;br /&gt;
&lt;br /&gt;
== FlightGear code vs. binaries ==&lt;br /&gt;
&lt;br /&gt;
Les dates de la sortie du logiciel consiste à la distribution du code, et nond'un executable. Pour créer un programme efficace, il faut le compiler, ce qui requiert certaines logithèques, dont certaines sont générales, tandis que d'autres sont spécifiques au système. En revanche, puisque la tâche demande nombre de compétences informatiques pour la plupart des utilisateurs grand public, d'autres contributeurs travailleront à rendre les binaires disponibles pour une plate-forme spécifique. Les performances, dépendent de la date de la mise à jour du code. Par exemple, certains travaux plus anciens binaires marchent sur Mac OS 9, mais les nouvelles versions  nécessitent certaines versions du Mac OS.&lt;br /&gt;
&lt;br /&gt;
Par exemple, fin 2007, la dernière version du code était 0.9.11-pre1 (pre-release) et 0.9.10 (final). Toutefois, la date de distribution des fichiers binaires réels  varient considérablement. Des exemples de binaires réels disponibles un an après la sortie de la version 0.9.10 du code:&lt;br /&gt;
&lt;br /&gt;
* Win-32 has ~138 Mb package (v0.9.10) (For Windows 98, 2000, ME, 32-bit XP) &lt;br /&gt;
* Linux- pre-built packages for specific Linux distributions&lt;br /&gt;
** Slackware package (v0.9.10), Fedora Core 2,3,4 packages (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) &lt;br /&gt;
* Solaris packages either for it running on either SPARC or x86 processors.&lt;br /&gt;
** SPARC (v0.9.8),  x86 (v0.9.9) &lt;br /&gt;
* Silicon Graphics IRIX&lt;br /&gt;
** SGI binaries for (v0.9.9) &lt;br /&gt;
* Mac OS X&lt;br /&gt;
** Mac OS 10.4 (v0.9.10) &lt;br /&gt;
** Mac OS 10.3 (v0.9.9) &lt;br /&gt;
* FreeBSD has a package for(v0.9.10)&lt;br /&gt;
&lt;br /&gt;
==Applications et usages==&lt;br /&gt;
{{Main article|Professional and educational FlightGear users}}&lt;br /&gt;
FlightGear a été utilisé dans une série de projets dans le milieu universitaire et de l'industrie (y compris la NASA) ainsi que dans des simulateurs &amp;quot;maison&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Reviews ==&lt;br /&gt;
{{Main article|FlightGear Reviews}}&lt;br /&gt;
&lt;br /&gt;
== liens externes ==&lt;br /&gt;
{{Main article|Links}}&lt;br /&gt;
* [http://www.flightgear.org Official website]&lt;br /&gt;
* [http://fgfs.i-net.hu/ Community website] &lt;br /&gt;
&lt;br /&gt;
{{Appendix|all|&lt;br /&gt;
* {{cite web |url=http://www.flightgear.org/proposal-3.0.1 |title=Original FlightGear Proposal |last=Murr |first=David L. |date=11 September, 1998 }}&lt;br /&gt;
* {{cite web |url=http://en.wikipedia.org/wiki/FlightGear |title=FlightGear |publisher=Wikipedia }}&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[[de:FlightGear]]&lt;br /&gt;
[[es:FlightGear]]&lt;br /&gt;
[[nl:FlightGear]]&lt;br /&gt;
[[pt:FlightGear]]&lt;br /&gt;
&lt;br /&gt;
[[Category:FlightGear| ]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53633</id>
		<title>Fr/FlightGear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53633"/>
		<updated>2012-08-30T10:21:58Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Software&lt;br /&gt;
| title                  = FlightGear&lt;br /&gt;
| logo                   = fglogosm.jpg&lt;br /&gt;
| image                  = FlightGear - 1903 Wright Flyer.jpg&lt;br /&gt;
| alt                    = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9&lt;br /&gt;
| developedby           = FlightGear Developers &amp;amp; Contributors&lt;br /&gt;
| initialrelease         = July 17, 1997&lt;br /&gt;
| latestrelease          = 2.8.0 (February 17, 2012)&lt;br /&gt;
| writtenin              = C++&lt;br /&gt;
| os                     = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX&lt;br /&gt;
| platform               = Cross-platform&lt;br /&gt;
| developmentstatus      = Active (1996-)&lt;br /&gt;
| type                   = Flight simulator&lt;br /&gt;
| license                = [[GNU General Public License]]&lt;br /&gt;
| website                = http://www.flightgear.org/&lt;br /&gt;
}}[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]&lt;br /&gt;
&lt;br /&gt;
'''FlightGear''' ( Souvent nommé '''Flightgear''' ou '''FGFS''') est un simulateur de vol sophistiqué, libre, et créé par des volontaires. FlightGear est distribué sous les termes de la [[GNU General Public License]]. Le logiciel est principalement codé en C++.&lt;br /&gt;
&lt;br /&gt;
Des versions de plus en plus détaillées et réalistes sont distribuées tous les 6 mois depuis le début du projet, en 1996.&lt;br /&gt;
&lt;br /&gt;
La dernière version en date est disponible à l'adresse  [http://www.flightgear.org/download/ flightgear.org/download/], fonctionnelle sur nombre de systèmes d'exploitation dont Microsoft Windows, Mac OS X, Linux, IRIX, et Solaris.&lt;br /&gt;
&lt;br /&gt;
== Histoire ==&lt;br /&gt;
{{main article|FlightGear History}}&lt;br /&gt;
&lt;br /&gt;
Le développement de flightgear commença par un échange sur internet en 1996, contenant un code inédit de graphiques 3D. Le développement d'une version basée sur [[OpenGL]] fut menée par Curtis Olson dès 1997. Nombre de volontaires ont contribués au projet, depuis.&lt;br /&gt;
&lt;br /&gt;
FlightGear associe d'autres ressources libres, comme plusieurs modèles de vol dont JSBsim, ainsi que certaines données de paysages, concues par la NASA et disponibles gratuitement. les premières librairies fontionnelles utilisant l'Opengl pour la 3D furent réalisées en 1997.  Un développement fulgurant etprofessionnel de nouvelles versions pendant plusieurs années fut à l'origine de la complexité du logiciel. Depuis 2001, L'équipe Flightgear sort de nouvelles versions &amp;quot;beta&amp;quot; régulièrement, et dès 2005, la qualité du software conduit à des critiques plus appliquées, et plus sérieuses, accompagnée par une popularité grandissante. L'année 2007 marque une symbolique sortie du développement secondaire avec la distribution de la version 1.0.0 , 10 ans après la première version en 1997.&lt;br /&gt;
&lt;br /&gt;
[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]&lt;br /&gt;
&lt;br /&gt;
En 2008, la version 1.9.0 de FlightGear introduit un majeur changement de [[PLIB]] à [[OSG]], qui causa temporairement la perte de fonctionalités comme les nuages 3D ou les ombres, tandis que les nouvelles, comme les particules, impacte sur le degré de réalisme de la simulation. &lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
&lt;br /&gt;
Le moteur de simulation dans FlightGear est appelé [[SimGear]]. Il est utile à la fois pour l'utilisateur normal et dans les milieux universitaires et de recherche, pour le developpement et la recherche d'idées sur la simulation de vol.&lt;br /&gt;
&lt;br /&gt;
La flexibité de FlightGear est illustrée par la grande quantité d'appareils, qui y sont disponibles: Nous pouvons compter plusieurs catégories, dont: [[:Category:Gliders|glider]]s,[[Helicopter]]s, [[:Category:Airliners|airliners]],[[Military aircraft|fighter jets]]. Ces modèles ont été créés par des développeurs différents.&lt;br /&gt;
&lt;br /&gt;
Les aéronefs de Flightgear utilisent un au moins des trois modèles de vols JSBSim, YAsim, ou UIUC depuis la version 0.9.10. Pour l'instant seulement un seul moteur de simulation est utilisé, TerraGear. Les effects météo (cf.[[Weather]]) sont très complexes et réalistes, de même que les effects visuels qui y sont liés: nuages 3D, effects lumineux, effects d'horizon, et heure de la journée.&lt;br /&gt;
&lt;br /&gt;
=== Flight Dynamics Models, alias...FDM ===&lt;br /&gt;
&lt;br /&gt;
Le modèle de vol [[Flight Dynamics Models]] ou (FDM) ) simule le comportement de l'avion dans une situation précise. FlightGear utilise beaucoup de scripts et de FDM codés de manière interne au programme . &lt;br /&gt;
Tout aéronef ''doit'' être programmé pour obéir à un de ces modèles de vol. Actuellement FlightGear est le seul simulateur utilisant autant de FDMs, et dont au moins trois sont créés de manière spécifique pour le logiciel.&lt;br /&gt;
Les plus anciennes versions utilisaient [[LaRCsim]], FDM créé par la NASA, mais il fut remplacé par des modèles plus flexibles. &lt;br /&gt;
&lt;br /&gt;
* [[JSBSim]] - Depuis 2000, le FDM par défaut de flightgear.&lt;br /&gt;
* [[YASim]] - Autre FDM utilisant une approche différente. Fait partie de la version 0.7.9 en 2002.&lt;br /&gt;
* [[UIUC]] - Autre FDM inclut, developpé par le ''UIUC Applied Aerodynamics Group'' à l' Université de l'Illinois à Urbana-Champaign, également partit de LaRCsim.&lt;br /&gt;
* FlightGear peut aussi être configuré pour utiliser des entrées de FDM externes, comme [[MATLAB]].&lt;br /&gt;
* D'autres FDM marginaux pour un aéronef spécifique ont été écrits, comme les appareils volants &amp;quot;plus légers que l'air&amp;quot;, tel le Zeppelin, ballon contenu dans la version de base de flightgear.&lt;br /&gt;
&lt;br /&gt;
=== FlightGear dependencies ===&lt;br /&gt;
&lt;br /&gt;
Contrairement à certains titres commerciaux, le but principal du projet est la sortie d'un code source. Pour le rendre utile, il faut le compiler sur une quelconque système d'exploitation. Les librairies utilisées par flightgear ont changées au cours du temps, et des versions. la principale est [[SimGear]], qui est le moteur de simulation necessaire à flightgear. Dans le cas de [[TerraGear]], il ne s'agit pas de secteur de dépendance, mais seulement d'un nom pour le programme de ''données de terrain'' dans le simulateur. OpenAL est utilisée pour  le son d'entrée/sortie, dont un support pour SDL (depuis 0.9.5). PLIB est utilisé pour le support matériel (driver), anciennement utilisé par le pilote son, actuellement repris par OpenAl. [[OpenGL]] est utilisé pour ses routines graphiques intégrées, et il est bon de savoir que d'autres accélérations matérielles (directX) ne sont pas prises en charge. [[OpenSceneGraph]] est aussi intégré dans FlightGear. Enfin, Simple DirectMedia Layer est une logitèque qui est utilisée pour compiler. certains de ces secteurs de dépendances varient, la plateforme utilisée faisant la différence. Les utilisateurs de FlightGear doivent à la fois compiler le code eux-même, ou trouver un tiers pour distribuer un fichier binaire.&lt;br /&gt;
&lt;br /&gt;
== Hardware ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Le matériel nécessaire pour faire tourner FlightGear est relativement faible, bien qu'il faut savoir que les cartes graphiques les plus compatibles sont de la série Nvidia . Les premières versions du simulateur avaient le support des cartes 3dfx, bien que la proportion de rencontrer ce genre de cartes a chutée de la même manière que la configuration matérielle moyenne s'est accrue.&lt;br /&gt;
&lt;br /&gt;
[[File:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]&lt;br /&gt;
&lt;br /&gt;
== Add-ons et tuning ==&lt;br /&gt;
&lt;br /&gt;
Certains programmes sont soit intégrés dans flightgear (&amp;quot;dependencies&amp;quot;),soit font une action, une opération à travers lui. Quelque uns sont intégrés dans la distribution populaire du simulateur (pour une plateforme spécifique,quelques fois) mais créées pour le projet, quand d'autres sont étrangers à Flightgear bien que supportés par la communauté. &lt;br /&gt;
&lt;br /&gt;
Un logiciel important est l'interface destinée à lancer FlightGear. A ses débuts, FlightGear ne pouvait se lancer que par l'interface DOS ([[command line]]). Cependant, ''the FlightGear Launch Control'' fut inclus dans le FGrun (''[[FG launcher]]'') depuis la version 0.9.3 en 2003. ''[[KFreeFlight]]'' est un &amp;quot;launcher/front-end&amp;quot; pour KDE. ''FGTools'' est une fenêtre alternative de lancement. ''FGKicker'' est une front-end basée GTK+ .&lt;br /&gt;
&lt;br /&gt;
D'autres projets très utiles contiennent des éditeurs de données de terrain. ''[[Atlas]]'' est un support de cartes aéronautiques pour FlightGear; ''[[Kelpie Flight Planner]]'' est un plannificateur de vol Java pour FlightGear. ''[[FlightGear Scenery Designer]]'' est un éditeur de scènes. Le ''[[World Custom Scenery Project]]'' est un projet destiné à coordiner tous les efforts effectués sur les scènes et les données de terrain. Enfin, ''[[TaxiDraw]]'' est un éditeur de pistes et taxiway, permettant un meilleur confort visuel.&lt;br /&gt;
&lt;br /&gt;
=== Aéronefs ===&lt;br /&gt;
{{Main article|Table of models}}&lt;br /&gt;
&lt;br /&gt;
FlightGear commença avec un avion inclut dans le FDM LaRCsim, le Navion, qui fut remplacé par un Cessna 170 en 2000. Le développement des trois FDM, en particulier YASim, apporta son lot de nouveaux avions: Plus de 350 aéronefs et 450 livrées uniques, sont disponibles pour la version 2.0.0, alors que seulement quelques uns sont inclus dans le package de base.&lt;br /&gt;
[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]&lt;br /&gt;
&lt;br /&gt;
=== Scènes ===&lt;br /&gt;
{{Main article|Scenery}}&lt;br /&gt;
Le monde de FlightGears ([[world scenery]]) couvre des données d'élévation et de terrain du monde entier. Les moulins à vents, les ponts et autres objets sont présents dans la base de données  ([[FlightGear Scenery Database|Scenery Database]]) .&lt;br /&gt;
Vous pouvez téléchargez le monde entier sur le site officiel de flightgear, indiqué plus haut.&lt;br /&gt;
&lt;br /&gt;
=== Mise en réseau et multi-écrans ===&lt;br /&gt;
&lt;br /&gt;
Plusieurs options de réseaux permettent une communication entre flightgear et ses instances. Un serveur multijoueurs ([[Multiplayer Howto|multiplayer]]) fut disponible pour utiliser FlightGear sur un réseau local dans un environnement à plusieurs aéronefs. Il peut être usé pour les vols en formation, ou la simulation de l' [[ATC|control tower]]. Le Multijoueurs fut bientôt élargit pour permettre aux joueurs de voler sur Internet. D'autres fonctionalitées comme la carte Google Map permettant de connaître la position  de chaque avions dans flightgear existent.&lt;br /&gt;
Plusieurs instances de FlightGear peuvent être synchronisées pour permettre un environnement multi-moniteur. Si toutes ces instances fonctionnent aux mêmes Frames per second, il est possible d'obtenir une bonne synchronisation agréable, et réaliste.&lt;br /&gt;
&lt;br /&gt;
== FlightGear code vs. binaries ==&lt;br /&gt;
&lt;br /&gt;
Les dates de la sortie du logiciel consiste à la distribution du code, et nond'un executable. Pour créer un programme efficace, il faut le compiler, ce qui requiert certaines logithèques, dont certaines sont générales, tandis que d'autres sont spécifiques au système. En revanche, puisque la tâche demande nombre de compétences informatiques pour la plupart des utilisateurs grand public, d'autres contributeurs travailleront à rendre les binaires disponibles pour une plate-forme spécifique. Les performances, dépendent de la date de la mise à jour du code. Par exemple, certains travaux plus anciens binaires marchent sur Mac OS 9, mais les nouvelles versions  nécessitent certaines versions du Mac OS.&lt;br /&gt;
&lt;br /&gt;
Par exemple, fin 2007, la dernière version du code était 0.9.11-pre1 (pre-release) et 0.9.10 (final). Toutefois, la date de distribution des fichiers binaires réels  varient considérablement. Des exemples de binaires réels disponibles un an après la sortie de la version 0.9.10 du code:&lt;br /&gt;
&lt;br /&gt;
* Win-32 has ~138 Mb package (v0.9.10) (For Windows 98, 2000, ME, 32-bit XP) &lt;br /&gt;
* Linux- pre-built packages for specific Linux distributions&lt;br /&gt;
** Slackware package (v0.9.10), Fedora Core 2,3,4 packages (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) &lt;br /&gt;
* Solaris packages either for it running on either SPARC or x86 processors.&lt;br /&gt;
** SPARC (v0.9.8),  x86 (v0.9.9) &lt;br /&gt;
* Silicon Graphics IRIX&lt;br /&gt;
** SGI binaries for (v0.9.9) &lt;br /&gt;
* Mac OS X&lt;br /&gt;
** Mac OS 10.4 (v0.9.10) &lt;br /&gt;
** Mac OS 10.3 (v0.9.9) &lt;br /&gt;
* FreeBSD has a package for(v0.9.10)&lt;br /&gt;
&lt;br /&gt;
==Applications et usages==&lt;br /&gt;
{{Main article|Professional and educational FlightGear users}}&lt;br /&gt;
FlightGear a été utilisé dans une série de projets dans le milieu universitaire et de l'industrie (y compris la NASA) ainsi que dans des simulateurs &amp;quot;maison&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Reviews ==&lt;br /&gt;
{{Main article|FlightGear Reviews}}&lt;br /&gt;
&lt;br /&gt;
== liens externes ==&lt;br /&gt;
{{Main article|Links}}&lt;br /&gt;
* [http://www.flightgear.org Official website]&lt;br /&gt;
* [http://fgfs.i-net.hu/ Community website] &lt;br /&gt;
&lt;br /&gt;
{{Appendix|all|&lt;br /&gt;
* {{cite web |url=http://www.flightgear.org/proposal-3.0.1 |title=Original FlightGear Proposal |last=Murr |first=David L. |date=11 September, 1998 }}&lt;br /&gt;
* {{cite web |url=http://en.wikipedia.org/wiki/FlightGear |title=FlightGear |publisher=Wikipedia }}&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[[de:FlightGear]]&lt;br /&gt;
[[es:FlightGear]]&lt;br /&gt;
[[nl:FlightGear]]&lt;br /&gt;
[[pt:FlightGear]]&lt;br /&gt;
&lt;br /&gt;
[[Category:FlightGear| ]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53632</id>
		<title>Fr/FlightGear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53632"/>
		<updated>2012-08-30T10:16:47Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Software&lt;br /&gt;
| title                  = FlightGear&lt;br /&gt;
| logo                   = fglogosm.jpg&lt;br /&gt;
| image                  = FlightGear - 1903 Wright Flyer.jpg&lt;br /&gt;
| alt                    = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9&lt;br /&gt;
| developedby           = FlightGear Developers &amp;amp; Contributors&lt;br /&gt;
| initialrelease         = July 17, 1997&lt;br /&gt;
| latestrelease          = 2.8.0 (February 17, 2012)&lt;br /&gt;
| writtenin              = C++&lt;br /&gt;
| os                     = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX&lt;br /&gt;
| platform               = Cross-platform&lt;br /&gt;
| developmentstatus      = Active (1996-)&lt;br /&gt;
| type                   = Flight simulator&lt;br /&gt;
| license                = [[GNU General Public License]]&lt;br /&gt;
| website                = http://www.flightgear.org/&lt;br /&gt;
}}[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]&lt;br /&gt;
&lt;br /&gt;
'''FlightGear''' ( Souvent nommé '''Flightgear''' ou '''FGFS''') est un simulateur de vol complexe, libre, et créé par des volontaires. FlightGear est distribué sous les termes de la [[GNU General Public License]]. Le logiciel est principalement codé en C++.&lt;br /&gt;
&lt;br /&gt;
Des versions de plus en plus détaillées et réalistes sont distribuées tous les 6 mois depuis le début du projet, en 1996.&lt;br /&gt;
&lt;br /&gt;
La dernière version en date est disponible à l'adresse  [http://www.flightgear.org/download/ flightgear.org/download/], fonctionnelle sur nombre de systèmes d'exploitation dont Microsoft Windows, Mac OS X, Linux, IRIX, et Solaris.&lt;br /&gt;
&lt;br /&gt;
== Histoire ==&lt;br /&gt;
{{main article|FlightGear History}}&lt;br /&gt;
&lt;br /&gt;
Le développement de flightgear commença par un échange sur internet en 1996, contenant un code inédit de graphiques 3D. Le développement d'une version basée sur [[OpenGL]] fut menée par Curtis Olson dès 1997. Nombre de volontaires ont contribués au projet, depuis.&lt;br /&gt;
&lt;br /&gt;
FlightGear associe d'autres ressources libres, comme plusieurs modèles de vol dont JSBsim, ainsi que certaines données de paysages, concues par la NASA et disponibles gratuitement. les premières librairies fontionnelles utilisant l'Opengl pour la 3D furent réalisées en 1997.  Un développement fulgurant etprofessionnel de nouvelles versions pendant plusieurs années fut à l'origine de la complexité du logiciel. Depuis 2001, L'équipe Flightgear sort de nouvelles versions &amp;quot;beta&amp;quot; régulièrement, et dès 2005, la qualité du software conduit à des critiques plus appliquées, et plus sérieuses, accompagnée par une popularité grandissante. L'année 2007 marque une symbolique sortie du développement secondaire avec la distribution de la version 1.0.0 , 10 ans après la première version en 1997.&lt;br /&gt;
&lt;br /&gt;
[[File:FG-A-10.jpg|thumb|270px|3D Cockpit panel for [[A-10]] in version 1.0.0 in 2008]]&lt;br /&gt;
&lt;br /&gt;
En 2008, la version 1.9.0 de FlightGear introduit un majeur changement de [[PLIB]] à [[OSG]], qui causa temporairement la perte de fonctionalités comme les nuages 3D ou les ombres, tandis que les nouvelles, comme les particules, impacte sur le degré de réalisme de la simulation. &lt;br /&gt;
&lt;br /&gt;
== Software ==&lt;br /&gt;
&lt;br /&gt;
Le moteur de simulation dans FlightGear est appelé [[SimGear]]. Il est utile à la fois pour l'utilisateur normal et dans les milieux universitaires et de recherche, pour le developpement et la recherche d'idées sur la simulation de vol.&lt;br /&gt;
&lt;br /&gt;
La flexibité de FlightGear est illustrée par la grande quantité d'appareils, qui y sont disponibles: Nous pouvons compter plusieurs catégories, dont: [[:Category:Gliders|glider]]s,[[Helicopter]]s, [[:Category:Airliners|airliners]],[[Military aircraft|fighter jets]]. Ces modèles ont été créés par des développeurs différents.&lt;br /&gt;
&lt;br /&gt;
Les aéronefs de Flightgear utilisent un au moins des trois modèles de vols JSBSim, YAsim, ou UIUC depuis la version 0.9.10. Pour l'instant seulement un seul moteur de simulation est utilisé, TerraGear. Les effects météo (cf.[[Weather]]) sont très complexes et réalistes, de même que les effects visuels qui y sont liés: nuages 3D, effects lumineux, effects d'horizon, et heure de la journée.&lt;br /&gt;
&lt;br /&gt;
=== Flight Dynamics Models, alias...FDM ===&lt;br /&gt;
&lt;br /&gt;
Le modèle de vol [[Flight Dynamics Models]] ou (FDM) ) simule le comportement de l'avion dans une situation précise. FlightGear utilise beaucoup de scripts et de FDM codés de manière interne au programme . &lt;br /&gt;
Tout aéronef ''doit'' être programmé pour obéir à un de ces modèles de vol. Actuellement FlightGear est le seul simulateur utilisant autant de FDMs, et dont au moins trois sont créés de manière spécifique pour le logiciel.&lt;br /&gt;
Les plus anciennes versions utilisaient [[LaRCsim]], FDM créé par la NASA, mais il fut remplacé par des modèles plus flexibles. &lt;br /&gt;
&lt;br /&gt;
* [[JSBSim]] - Depuis 2000, le FDM par défaut de flightgear.&lt;br /&gt;
* [[YASim]] - Autre FDM utilisant une approche différente. Fait partie de la version 0.7.9 en 2002.&lt;br /&gt;
* [[UIUC]] - Autre FDM inclut, developpé par le ''UIUC Applied Aerodynamics Group'' à l' Université de l'Illinois à Urbana-Champaign, également partit de LaRCsim.&lt;br /&gt;
* FlightGear peut aussi être configuré pour utiliser des entrées de FDM externes, comme [[MATLAB]].&lt;br /&gt;
* D'autres FDM marginaux pour un aéronef spécifique ont été écrits, comme les appareils volants &amp;quot;plus légers que l'air&amp;quot;, tel le Zeppelin, ballon contenu dans la version de base de flightgear.&lt;br /&gt;
&lt;br /&gt;
=== FlightGear dependencies ===&lt;br /&gt;
&lt;br /&gt;
Contrairement à certains titres commerciaux, le but principal du projet est la sortie d'un code source. Pour le rendre utile, il faut le compiler sur une quelconque système d'exploitation. Les librairies utilisées par flightgear ont changées au cours du temps, et des versions. la principale est [[SimGear]], qui est le moteur de simulation necessaire à flightgear. Dans le cas de [[TerraGear]], il ne s'agit pas de secteur de dépendance, mais seulement d'un nom pour le programme de ''données de terrain'' dans le simulateur. OpenAL est utilisée pour  le son d'entrée/sortie, dont un support pour SDL (depuis 0.9.5). PLIB est utilisé pour le support matériel (driver), anciennement utilisé par le pilote son, actuellement repris par OpenAl. [[OpenGL]] est utilisé pour ses routines graphiques intégrées, et il est bon de savoir que d'autres accélérations matérielles (directX) ne sont pas prises en charge. [[OpenSceneGraph]] est aussi intégré dans FlightGear. Enfin, Simple DirectMedia Layer est une logitèque qui est utilisée pour compiler. certains de ces secteurs de dépendances varient, la plateforme utilisée faisant la différence. Les utilisateurs de FlightGear doivent à la fois compiler le code eux-même, ou trouver un tiers pour distribuer un fichier binaire.&lt;br /&gt;
&lt;br /&gt;
== Hardware ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Le matériel nécessaire pour faire tourner FlightGear est relativement faible, bien qu'il faut savoir que les cartes graphiques les plus compatibles sont de la série Nvidia . Les premières versions du simulateur avaient le support des cartes 3dfx, bien que la proportion de rencontrer ce genre de cartes a chutée de la même manière que la configuration matérielle moyenne s'est accrue.&lt;br /&gt;
&lt;br /&gt;
[[File:Fgrun-page2.jpg|thumb|left|270px|The [[FlightGear Launch Control|FlightGear Launcher]]]]&lt;br /&gt;
&lt;br /&gt;
== Add-ons et tuning ==&lt;br /&gt;
&lt;br /&gt;
Certains programmes sont soit intégrés dans flightgear (&amp;quot;dependencies&amp;quot;),soit font une action, une opération à travers lui. Quelque uns sont intégrés dans la distribution populaire du simulateur (pour une plateforme spécifique,quelques fois) mais créées pour le projet, quand d'autres sont étrangers à Flightgear bien que supportés par la communauté. &lt;br /&gt;
&lt;br /&gt;
Un logiciel important est l'interface destinée à lancer FlightGear. A ses débuts, FlightGear ne pouvait se lancer que par l'interface DOS ([[command line]]). Cependant, ''the FlightGear Launch Control'' fut inclus dans le FGrun (''[[FG launcher]]'') depuis la version 0.9.3 en 2003. ''[[KFreeFlight]]'' est un &amp;quot;launcher/front-end&amp;quot; pour KDE. ''FGTools'' est une fenêtre alternative de lancement. ''FGKicker'' est une front-end basée GTK+ .&lt;br /&gt;
&lt;br /&gt;
D'autres projets très utiles contiennent des éditeurs de données de terrain. ''[[Atlas]]'' est un support de cartes aéronautiques pour FlightGear; ''[[Kelpie Flight Planner]]'' est un plannificateur de vol Java pour FlightGear. ''[[FlightGear Scenery Designer]]'' est un éditeur de scènes. Le ''[[World Custom Scenery Project]]'' est un projet destiné à coordiner tous les efforts effectués sur les scènes et les données de terrain. Enfin, ''[[TaxiDraw]]'' est un éditeur de pistes et taxiway, permettant un meilleur confort visuel.&lt;br /&gt;
&lt;br /&gt;
=== Aéronefs ===&lt;br /&gt;
{{Main article|Table of models}}&lt;br /&gt;
&lt;br /&gt;
FlightGear commença avec un avion inclut dans le FDM LaRCsim, le Navion, qui fut remplacé par un Cessna 170 en 2000. Le développement des trois FDM, en particulier YASim, apporta son lot de nouveaux avions: Plus de 350 aéronefs et 450 livrées uniques, sont disponibles pour la version 2.0.0, alors que seulement quelques uns sont inclus dans le package de base.&lt;br /&gt;
[[File:EHAM.jpg|thumb|270px|[[Boeing 737-300|Boeing 733]] docked in the [[EHAM]] scenery]]&lt;br /&gt;
&lt;br /&gt;
=== Scènes ===&lt;br /&gt;
{{Main article|Scenery}}&lt;br /&gt;
Le monde de FlightGears ([[world scenery]]) couvre des données d'élévation et de terrain du monde entier. Les moulins à vents, les ponts et autres objets sont présents dans la base de données  ([[FlightGear Scenery Database|Scenery Database]]) .&lt;br /&gt;
Vous pouvez téléchargez le monde entier sur le site officiel de flightgear, indiqué plus haut.&lt;br /&gt;
&lt;br /&gt;
=== Mise en réseau et multi-écrans ===&lt;br /&gt;
&lt;br /&gt;
Plusieurs options de réseaux permettent une communication entre flightgear et ses instances. Un serveur multijoueurs ([[Multiplayer Howto|multiplayer]]) fut disponible pour utiliser FlightGear sur un réseau local dans un environnement à plusieurs aéronefs. Il peut être usé pour les vols en formation, ou la simulation de l' [[ATC|control tower]]. Le Multijoueurs fut bientôt élargit pour permettre aux joueurs de voler sur Internet. D'autres fonctionalitées comme la carte Google Map permettant de connaître la position  de chaque avions dans flightgear existent.&lt;br /&gt;
Plusieurs instances de FlightGear peuvent être synchronisées pour permettre un environnement multi-moniteur. Si toutes ces instances fonctionnent aux mêmes Frames per second, il est possible d'obtenir une bonne synchronisation agréable, et réaliste.&lt;br /&gt;
&lt;br /&gt;
== FlightGear code vs. binaries ==&lt;br /&gt;
&lt;br /&gt;
Les dates de la sortie du logiciel consiste à la distribution du code, et nond'un executable. Pour créer un programme efficace, il faut le compiler, ce qui requiert certaines logithèques, dont certaines sont générales, tandis que d'autres sont spécifiques au système. En revanche, puisque la tâche demande nombre de compétences informatiques pour la plupart des utilisateurs grand public, d'autres contributeurs travailleront à rendre les binaires disponibles pour une plate-forme spécifique. Les performances, dépendent de la date de la mise à jour du code. Par exemple, certains travaux plus anciens binaires marchent sur Mac OS 9, mais les nouvelles versions  nécessitent certaines versions du Mac OS.&lt;br /&gt;
&lt;br /&gt;
Par exemple, fin 2007, la dernière version du code était 0.9.11-pre1 (pre-release) et 0.9.10 (final). Toutefois, la date de distribution des fichiers binaires réels  varient considérablement. Des exemples de binaires réels disponibles un an après la sortie de la version 0.9.10 du code:&lt;br /&gt;
&lt;br /&gt;
* Win-32 has ~138 Mb package (v0.9.10) (For Windows 98, 2000, ME, 32-bit XP) &lt;br /&gt;
* Linux- pre-built packages for specific Linux distributions&lt;br /&gt;
** Slackware package (v0.9.10), Fedora Core 2,3,4 packages (v0.9.10), Pardus (v0.9.10), Debian (v0.9.9) &lt;br /&gt;
* Solaris packages either for it running on either SPARC or x86 processors.&lt;br /&gt;
** SPARC (v0.9.8),  x86 (v0.9.9) &lt;br /&gt;
* Silicon Graphics IRIX&lt;br /&gt;
** SGI binaries for (v0.9.9) &lt;br /&gt;
* Mac OS X&lt;br /&gt;
** Mac OS 10.4 (v0.9.10) &lt;br /&gt;
** Mac OS 10.3 (v0.9.9) &lt;br /&gt;
* FreeBSD has a package for(v0.9.10)&lt;br /&gt;
&lt;br /&gt;
==Applications et usages==&lt;br /&gt;
{{Main article|Professional and educational FlightGear users}}&lt;br /&gt;
FlightGear a été utilisé dans une série de projets dans le milieu universitaire et de l'industrie (y compris la NASA) ainsi que dans des simulateurs &amp;quot;maison&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
== Reviews ==&lt;br /&gt;
{{Main article|FlightGear Reviews}}&lt;br /&gt;
&lt;br /&gt;
== liens externes ==&lt;br /&gt;
{{Main article|Links}}&lt;br /&gt;
* [http://www.flightgear.org Official website]&lt;br /&gt;
* [http://fgfs.i-net.hu/ Community website] &lt;br /&gt;
&lt;br /&gt;
{{Appendix|all|&lt;br /&gt;
* {{cite web |url=http://www.flightgear.org/proposal-3.0.1 |title=Original FlightGear Proposal |last=Murr |first=David L. |date=11 September, 1998 }}&lt;br /&gt;
* {{cite web |url=http://en.wikipedia.org/wiki/FlightGear |title=FlightGear |publisher=Wikipedia }}&lt;br /&gt;
}}&lt;br /&gt;
&lt;br /&gt;
[[de:FlightGear]]&lt;br /&gt;
[[es:FlightGear]]&lt;br /&gt;
[[nl:FlightGear]]&lt;br /&gt;
[[pt:FlightGear]]&lt;br /&gt;
&lt;br /&gt;
[[Category:FlightGear| ]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53629</id>
		<title>Fr/FlightGear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53629"/>
		<updated>2012-08-30T08:12:37Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Software&lt;br /&gt;
| title                  = FlightGear&lt;br /&gt;
| logo                   = fglogosm.jpg&lt;br /&gt;
| image                  = FlightGear - 1903 Wright Flyer.jpg&lt;br /&gt;
| alt                    = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9&lt;br /&gt;
| developedby           = FlightGear Developers &amp;amp; Contributors&lt;br /&gt;
| initialrelease         = July 17, 1997&lt;br /&gt;
| latestrelease          = 2.8.0 (February 17, 2012)&lt;br /&gt;
| writtenin              = C++&lt;br /&gt;
| os                     = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX&lt;br /&gt;
| platform               = Cross-platform&lt;br /&gt;
| developmentstatus      = Active (1996-)&lt;br /&gt;
| type                   = Flight simulator&lt;br /&gt;
| license                = [[GNU General Public License]]&lt;br /&gt;
| website                = http://www.flightgear.org/&lt;br /&gt;
}}[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]&lt;br /&gt;
&lt;br /&gt;
'''FlightGear''' ( Souvent nommé '''Flightgear''' ou '''FGFS''') est un simulateur de vol complexe, libre, et créé par des volontaires. FlightGear est distribué sous les termes de la [[GNU General Public License]]. Le logiciel est principalement codé en C++.&lt;br /&gt;
&lt;br /&gt;
Des versions de plus en plus détaillées et réalistes sont distribuées tous les 6 mois depuis le début du projet, en 1996.&lt;br /&gt;
&lt;br /&gt;
La dernière version en date est disponible à l'adresse  [http://www.flightgear.org/download/ flightgear.org/download/], fonctionnelle sur nombre de systèmes d'exploitation dont Microsoft Windows, Mac OS X, Linux, IRIX, et Solaris.&lt;br /&gt;
&lt;br /&gt;
== Histoire ==&lt;br /&gt;
{{main article|FlightGear History}}&lt;br /&gt;
&lt;br /&gt;
Le développement de flightgear commença par un échange sur internet en 1996, contenant un code inédit de graphiques 3D. Le développement d'une version basée sur [[OpenGL]] fut menée par Curtis Olson dès 1997. Nombre de volontaires ont contribués au projet, depuis.&lt;br /&gt;
&lt;br /&gt;
FlightGear associe d'autres ressources libres, comme plusieurs modèles de vol dont JSBsim, ainsi que certaines données de paysages, concues par la NASA et disponibles gratuitement. les premières librairies fontionnelles utilisant l'Opengl pour la 3D furent réalisées en 1997.  Un développement fulgurant etprofessionnel de nouvelles versions pendant plusieurs années fut à l'origine de la complexité du logiciel. Depuis 2001, L'équipe Flightgear sort de nouvelles versions &amp;quot;beta&amp;quot; régulièrement, et dès 2005, la qualité du software conduit à des critiques plus appliquées, et plus sérieuses, accompagnée par une popularité grandissante. L'année 2007 marque une symbolique sortie du développement secondaire avec la distribution de la version 1.0.0 , 10 ans après la première version en 1997.&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53628</id>
		<title>Fr/FlightGear</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Fr/FlightGear&amp;diff=53628"/>
		<updated>2012-08-30T08:11:43Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: Created page with &amp;quot;{{Infobox Software | title                  = FlightGear | logo                   = fglogosm.jpg | image                  = FlightGear - 1903 Wright Flyer.jpg | alt           ...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{Infobox Software&lt;br /&gt;
| title                  = FlightGear&lt;br /&gt;
| logo                   = fglogosm.jpg&lt;br /&gt;
| image                  = FlightGear - 1903 Wright Flyer.jpg&lt;br /&gt;
| alt                    = [[Wright Flyer (UIUC)|Wright Flyer]] in 0.9.9&lt;br /&gt;
| developedby           = FlightGear Developers &amp;amp; Contributors&lt;br /&gt;
| initialrelease         = July 17, 1997&lt;br /&gt;
| latestrelease          = 2.8.0 (February 17, 2012)&lt;br /&gt;
| writtenin              = C++&lt;br /&gt;
| os                     = 32-bit Windows, Linux, Mac OS X, FreeBSD, Solaris or IRIX&lt;br /&gt;
| platform               = Cross-platform&lt;br /&gt;
| developmentstatus      = Active (1996-)&lt;br /&gt;
| type                   = Flight simulator&lt;br /&gt;
| license                = [[GNU General Public License]]&lt;br /&gt;
| website                = http://www.flightgear.org/&lt;br /&gt;
}}[[File:OV10A-NASA-in-action.jpg|thumb|right|270px|NASA [[OV-10]] in FlightGear 1.0]]&lt;br /&gt;
&lt;br /&gt;
'''FlightGear''' ( Souvent nommé '''Flightgear''' ou '''FGFS''') est un simulateur de vol libre, sophistiqué, dont les sources sont libres, et créé par des volontaires. FlightGear est distribué sous les termes de la [[GNU General Public License]]. Le logiciel est principalement codé en C++.&lt;br /&gt;
&lt;br /&gt;
Des versions de plus en plus détaillées et réalistes sont distribuées tous les 6 mois depuis le début du projet, en 1996.&lt;br /&gt;
&lt;br /&gt;
La dernière version en date est disponible à l'adresse  [http://www.flightgear.org/download/ flightgear.org/download/], fonctionnelle sur nombre de systèmes d'exploitation dont Microsoft Windows, Mac OS X, Linux, IRIX, et Solaris.&lt;br /&gt;
&lt;br /&gt;
== Histoire ==&lt;br /&gt;
{{main article|FlightGear History}}&lt;br /&gt;
&lt;br /&gt;
Le développement de flightgear commença par un échange sur internet en 1996, contenant un code inédit de graphiques 3D. Le développement d'une version basée sur [[OpenGL]] fut menée par Curtis Olson dès 1997. Nombre de volontaires ont contribués au projet, depuis.&lt;br /&gt;
&lt;br /&gt;
FlightGear associe d'autres ressources libres, comme plusieurs modèles de vol dont JSBsim, ainsi que certaines données de paysages, concues par la NASA et disponibles gratuitement. les premières librairies fontionnelles utilisant l'Opengl pour la 3D furent réalisées en 1997.  Un développement fulgurant etprofessionnel de nouvelles versions pendant plusieurs années fut à l'origine de la complexité du logiciel. Depuis 2001, L'équipe Flightgear sort de nouvelles versions &amp;quot;beta&amp;quot; régulièrement, et dès 2005, la qualité du software conduit à des critiques plus appliquées, et plus sérieuses, accompagnée par une popularité grandissante. L'année 2007 marque une symbolique sortie du développement secondaire avec la distribution de la version 1.0.0 , 10 ans après la première version en 1997.&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
	<entry>
		<id>https://wiki.flightgear.org/w/index.php?title=Howto:Understand_console_output&amp;diff=53626</id>
		<title>Howto:Understand console output</title>
		<link rel="alternate" type="text/html" href="https://wiki.flightgear.org/w/index.php?title=Howto:Understand_console_output&amp;diff=53626"/>
		<updated>2012-08-30T03:41:34Z</updated>

		<summary type="html">&lt;p&gt;Sahliyoussef: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This document lists '''[[FlightGear]] errors''', how to get rid of them and other '''console output'''. If FlightGear quits but does not give you any error, try increasing the [[FlightGear Launch Control#Debugging|Log Level]].&lt;br /&gt;
&lt;br /&gt;
Errors can appear in various locations, but the most common one is the console (a black window), which pops up when you run fgfs.exe.&lt;br /&gt;
&lt;br /&gt;
== Errors with known solutions ==&lt;br /&gt;
=== Aircraft uses deprecated node egt_degf. Please upgrade to egt-degf ===&lt;br /&gt;
The aircraft should be updated to make use of the renamed egt-degf property but it will still work as expected. You could contact the aircraft's author but he/she is probably already aware of this.&lt;br /&gt;
&lt;br /&gt;
=== Airports/.... ... Done ===&lt;br /&gt;
This is not an error. The message lets us know that [[TerraSync]] is updating the &amp;lt;tt&amp;gt;[[$FG SCENERY]]/Airports&amp;lt;/tt&amp;gt; directory.&lt;br /&gt;
&lt;br /&gt;
=== Bad operation output detected in configuration file ===&lt;br /&gt;
[[JSBSim]] reports that a &amp;lt;output&amp;gt; tag is incorrectly placed in the aircraft's FDM. When used in a &amp;lt;fcs_function&amp;gt;, it should be outside the innter &amp;lt;function&amp;gt; tags, so like:&lt;br /&gt;
&amp;lt;syntaxhighlight&amp;gt;&lt;br /&gt;
	&amp;lt;fcs_function name=&amp;quot;Flap Cmd Deg&amp;quot;&amp;gt;&lt;br /&gt;
		&amp;lt;function&amp;gt;&lt;br /&gt;
			&amp;lt;product&amp;gt;&lt;br /&gt;
				   &amp;lt;property&amp;gt;fcs/flap-cmd-norm&amp;lt;/property&amp;gt;&lt;br /&gt;
				   &amp;lt;value&amp;gt;30&amp;lt;/value&amp;gt;&lt;br /&gt;
			&amp;lt;/product&amp;gt;&lt;br /&gt;
		&amp;lt;/function&amp;gt;&lt;br /&gt;
		&amp;lt;output&amp;gt;fcs/flap-cmd-deg1&amp;lt;/output&amp;gt;&lt;br /&gt;
	&amp;lt;/fcs_function&amp;gt;&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Base package check failed ... Found version ... at: ...&amp;lt;br /&amp;gt;Please upgrade to version: ===&lt;br /&gt;
When using [[Git]], the data must match the binary or compilation. You cannot use data from a different date than the binary's release date. &lt;br /&gt;
&lt;br /&gt;
=== Base package check failed ... Found version [none] at: ...&amp;lt;br /&amp;gt;Please upgrade to version: ===&lt;br /&gt;
FlightGear was unable to find the [[$FG ROOT]] directory. Set it using the &amp;lt;tt&amp;gt;--fg-root=&amp;lt;/tt&amp;gt; commandline option.&lt;br /&gt;
&lt;br /&gt;
=== Cannot find specified aircraft ===&lt;br /&gt;
Shows up when you use an incorrect aircraft name in the --aircraft=... command. Check the correct name by running --show-aircraft, or by looking at the aircraft's -set.xml file (eg. &amp;lt;tt&amp;gt;--aircraft=737-300&amp;lt;/tt&amp;gt; for &amp;lt;tt&amp;gt;737-300-set.xml&amp;lt;/tt&amp;gt;).&lt;br /&gt;
&lt;br /&gt;
=== condition: comparison without property[1] or value ===&lt;br /&gt;
A condition (like &amp;lt;tt&amp;gt;&amp;lt;less-than&amp;gt;&amp;lt;/tt&amp;gt; or &amp;lt;tt&amp;gt;&amp;lt;equals&amp;gt;&amp;lt;/tt&amp;gt;) exists, without either:&lt;br /&gt;
* a property to check&lt;br /&gt;
* a value to check the property against&lt;br /&gt;
&lt;br /&gt;
=== Could not find at least one of the following objects for animation: ===&lt;br /&gt;
This means that FlightGear is unable to find an object in a .ac file. Check the .xml file (where the animation is stored) to see if the object-names match those in the .ac file. Also in the .xml file make sure that there are not spaces at the beginning or end of the object name. If you are not the aircraft's author you can safely ignore such warnings.&lt;br /&gt;
&lt;br /&gt;
=== creating 3D noise texture... DONE ===&lt;br /&gt;
Tells you that a new noise texture is created. It is not an error and can be ignored.&lt;br /&gt;
&lt;br /&gt;
===Error: [Screen #0] GraphicsWindowWin32::setPixelFormat() - No matching pixel format found based on traits specified====&lt;br /&gt;
Try changing the [[FlightGear Launch Control#Page Four - Options and Run|BPP]] value of your FlightGear setup. If that does not work, your graphics card is probably not able to run FlightGear 1.9 and higher. Another graphics card, or an older FlightGear version will likely &amp;quot;fix&amp;quot; the problem.&lt;br /&gt;
&lt;br /&gt;
=== Error: bind() failed in make_server_socket() ===&lt;br /&gt;
When using [[Howto: Multiplayer|multiplayer]] or socket input, this usually means you specified an invalid ip address or the port is in use. Note: for multiplayer, you don't need to use the ''--multiplay=in,...'' option at all, FlightGear (since version 1.0) figures out the proper setting automatically. Only use when you know what you are doing.&lt;br /&gt;
&lt;br /&gt;
=== Error Building Technique: findAttr: could not find attribute bool ===&lt;br /&gt;
Make sure that your data and source (or binary) match. They must be from the same date, to provide the best performance.&lt;br /&gt;
&lt;br /&gt;
=== Error: connect() failed in make_client_socket()&amp;lt;br /&amp;gt;SG_IO_OUT socket creation failed ===&lt;br /&gt;
Your computer is not connected with the internet, while a certain enabled feature (eg. multiplayer) does require an internet connection.&lt;br /&gt;
&lt;br /&gt;
=== Error: RenderTexture requires the following unsupported OpenGL extensions... ===&lt;br /&gt;
Your graphics card doesn't support some graphics feature that FG requires. Update your drivers, change the BPP value and/or try disabling some of the visual goodies like [[3D Clouds]].&lt;br /&gt;
&lt;br /&gt;
=== Failed to find .... in apt.dat.gz ===&lt;br /&gt;
You need to edit ATC/default.tower and ATC/default.atis. You can open these files with any text editor. Either remove or fix the entries containing your airports ICAO code (like KSFO).&lt;br /&gt;
&lt;br /&gt;
===Failed to locate aircraft carrier = ...===&lt;br /&gt;
FlightGear is unable to find a [[Aircraft carrier|carrier]] under the set name. Check your commandline (&amp;lt;tt&amp;gt;--carrier=...&amp;lt;/tt&amp;gt;) or the [[FlightGear Launch Control#Page Three - Airport Selection|airport page]] of the launcher. Note that you might need to enable a scenario in combination with a --carrier= command.&lt;br /&gt;
&lt;br /&gt;
'''Hint:''' Make sure your park position and carrier name is correct. See the [[Howto: Carrier|wiki's carrier page]] for details.&lt;br /&gt;
&lt;br /&gt;
=== Failed to open file ... ===&lt;br /&gt;
Check if the file exists on your system. If the missing file is a scenery object; be sure you have the latest [http://scenemodels.flightgear.org/download/SharedModels.tgz Shared Models] from the [[FlightGear Scenery Database]].&lt;br /&gt;
&lt;br /&gt;
=== Fatal error: illegal character after . or .. ===&lt;br /&gt;
Some .xml file contains a fault. Possible solutions:&lt;br /&gt;
* To refer to a top-level property in the tree, &amp;lt;tt&amp;gt;../&amp;lt;/tt&amp;gt; should be used instead of &amp;lt;tt&amp;gt;.../&amp;lt;/tt&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Fatal error: mismatched tag ... ===&lt;br /&gt;
In some .xml file, an opening tag (like &amp;lt;tt&amp;gt;&amp;lt;sim&amp;gt;&amp;lt;/tt&amp;gt;) does not match its closing tag (like &amp;lt;tt&amp;gt;&amp;lt;/sim&amp;gt;&amp;lt;/tt&amp;gt;). This error is hard to track down, best method is to comment (place code between &amp;lt;nowiki&amp;gt;&amp;lt;!-- and --&amp;gt;&amp;lt;/nowiki&amp;gt;) most of the aircraft. Then uncomment code one by one, until the error appears again.&lt;br /&gt;
&lt;br /&gt;
'''Hint for Developers:''' Pre-test all your .xml files in Windows by opening them with Internet Explorer (usually by double clicking). IE can tell you if a tag is mis-matched and which tag is mis-matched. You'll probably know there's a problem if IE displays an error message.&lt;br /&gt;
&lt;br /&gt;
=== Fatal error: name must begin with alpha or '_' ===&lt;br /&gt;
This error comes up when a property should be formed of which the name does not start with a letter of the alphabet or _. If this error only happens with certain planes, contact their authors.&lt;br /&gt;
&lt;br /&gt;
=== Failed to tie property fcs/ to object methods ===&lt;br /&gt;
This [[JSBSim]] error comes up when there are unnamed components (eg. switches) in the FDM of an aircraft. Components must have unique names, from which properties will be created. As long as you are not overwriting an existing property, the &amp;lt;tt&amp;gt;name=&amp;quot;...&amp;quot;&amp;lt;/tt&amp;gt; can be used to output the components result to a property.&lt;br /&gt;
&lt;br /&gt;
=== Fatal error: unclosed token ===&lt;br /&gt;
A token (&amp;lt;nowiki&amp;gt;&amp;lt;!-- --&amp;gt;&amp;lt;/nowiki&amp;gt;) has been started, but not closes. Add &amp;lt;nowiki&amp;gt;--&amp;gt;&amp;lt;/nowiki&amp;gt; at the correct line.&lt;br /&gt;
&lt;br /&gt;
'''Hint for Developers:''' Pre-test all your .xml files in Windows by opening them with Internet Explorer (usually by double clicking). IE can tell you if a comment/token is not closed.&lt;br /&gt;
&lt;br /&gt;
=== FGMultiplayerMgr::Open - Failed to bind receive socket ===&lt;br /&gt;
This means FlightGear was unable to open the listening network socket required by the --multiplay=in option. Frequently this option can be omitted and FlightGear will figure out the necessary parameters automatically.&lt;br /&gt;
Common reasons are:&lt;br /&gt;
* Address given in the option does not resolve to one of the IP addresses of the local machine. This parameter should only be required if you want to fine-tune the network behavior. Omitting it directs FlightGear to listen on all local interfaces automatically. Example:&lt;br /&gt;
 --multiplay=in,10,,5001&lt;br /&gt;
Notice that you still need the comma.&lt;br /&gt;
* The UDP port given in the option (or the default port 5000 if no option given) is already in use. Verify nothing is using the port.&lt;br /&gt;
&lt;br /&gt;
=== FGMultiplayMgr::MP_ProcessData: No such file or directory ===&lt;br /&gt;
This is telling you that there's someone online on the multiplayerserver, using a plane that you do not have installed on your own system. In order to remove the error (and see the other plane) you have to install the plane that the other pilot is using.&lt;br /&gt;
&lt;br /&gt;
=== FGMultiplayMgr - No receiver port, Multiplayermode disabled ===&lt;br /&gt;
FlightGear [[Howto: Multiplayer|multiplayer]] has not been set.&lt;br /&gt;
&lt;br /&gt;
=== FGPropertyManager::GetNode() No node found for ...&amp;lt;br /&amp;gt; In component: ... unknown property ... referenced. Aborting ===&lt;br /&gt;
FlightGear found a reference in the [[FDM]] to a non-existing property.&lt;br /&gt;
&lt;br /&gt;
=== FGPropertyManager::GetNode() No node found for ...&amp;lt;br /&amp;gt; The property ... is undefined. ===&lt;br /&gt;
FlightGear found a reference in the [[FDM]] to a non-existing property. Keep in mind that JSBSim reads the FDM from top to bottom. Properties should always be created before they are needed somewhere.&lt;br /&gt;
&lt;br /&gt;
=== Fgtzfile_read(): : Invalid argument&amp;lt;br /&amp;gt;Fatal error: Timezone reading failed ===&lt;br /&gt;
This one is caused by wrong line ending in a timezone file. Solution might be to download the Timezone/time.tab file manually from [http://gitorious.org/fg/fgdata/blobs/raw/master/Timezone/zone.tab Gitorious] (Right mouseclick &amp;gt; Save target as) and overwrite the file in &amp;lt;tt&amp;gt;[[$FG ROOT]]/Timezone/time.tab&amp;lt;/tt&amp;gt; with it.&lt;br /&gt;
&lt;br /&gt;
=== Found unexpected subsystem: system exiting. JSBSim failed to load aircraft and/or engine model ===&lt;br /&gt;
You are probably trying to run an aircraft on a out-of-date version of FlightGear. The planes on the official download page are intended to be used with the latest version of FlightGear. Usage on any older systems may not work.&lt;br /&gt;
&lt;br /&gt;
=== freeglut (fgfs): Unable to create direct context rendering for window 'FlightGear'&amp;lt;br /&amp;gt;This may hurt performance ===&lt;br /&gt;
This reports that you do not have proper hardware accelerated 3D (direct rendering) configured.&lt;br /&gt;
&lt;br /&gt;
=== Gate ... doesn't seem to have routes associated with it ===&lt;br /&gt;
A startup location in the [[Interactive Traffic#Ground networks|groundnetwork]] is not (properly) connected to a taxi route. Contact the airport author, or import the network to [[TaxiDraw]] and run the Verify network command to find the corrupted gate.&lt;br /&gt;
&lt;br /&gt;
=== glLinkProgram &amp;quot;&amp;quot; Failed ===&lt;br /&gt;
Update your drivers; they have to support atleast OpenGL 2.0 for FlightGear 2.0 and later.&lt;br /&gt;
&lt;br /&gt;
=== loading scenario '...' ===&lt;br /&gt;
This is not an error. It shows that an [[AI Systems#AI Models|AI scenario]] is loaded.&lt;br /&gt;
&lt;br /&gt;
=== Model not found: ... ===&lt;br /&gt;
This one tells you that FlightGear was unable to find a certain file. The nice thing is that it also tells you excactly what file. &lt;br /&gt;
&lt;br /&gt;
# Check if the file really does not exist at your computer.&lt;br /&gt;
# Try to locate the file in which the missing file is referenced. This is likely to be &amp;lt;tt&amp;gt;-set.xml&amp;lt;/tt&amp;gt; in the root directory of the loaded [[aircraft]]. Between the &amp;lt;model&amp;gt; tags, the base model file is referenced. This file references to all other models that are displayed with the aircraft.&lt;br /&gt;
# Contact the aircraft author with a detailed bug-report, in which you state the excact location of the missing file and (if you found it) the file in which it is referenced.&lt;br /&gt;
&lt;br /&gt;
=== Nasal runtime error: nil used in numeric context ===&lt;br /&gt;
This error is [[Nasal]] triggered by a Nasal file (the console should show what file (and line) and from where it was referenced). The Nasal script tried to do something with a [[Property Tree|property]] with an empty value. A solution is to fill the property before the Nasal is loaded. This can be done by setting the property in an [[aircraft]]'s &amp;lt;tt&amp;gt;-set.xml&amp;lt;/tt&amp;gt; file or by adding a [[Nasal scripting language#Listeners and Signals|listener]] to the script. &lt;br /&gt;
&lt;br /&gt;
[[Howto: Contact the developers|Contact the developers]] if this error is shown for a &amp;lt;tt&amp;gt;[[$FG ROOT]]/Nasal/&amp;lt;/tt&amp;gt; script.&lt;br /&gt;
&lt;br /&gt;
=== Near camera not rendering ===&lt;br /&gt;
[[File:Near_camera_off.png|500px]]&lt;br /&gt;
&lt;br /&gt;
If you screen looks like the image above; make sure you have at least [[OSG]] version 2.7.6.&lt;br /&gt;
&lt;br /&gt;
=== No render bin name specified in render bin section ===&lt;br /&gt;
Update [[SimGear]] (or binary) and your data directory.&lt;br /&gt;
&lt;br /&gt;
=== No render bin number specified in render bin section ===&lt;br /&gt;
Update [[SimGear]] (or binary) and your data directory.&lt;br /&gt;
&lt;br /&gt;
=== ... not a valid win32 application ===&lt;br /&gt;
This Windows error could have various reasons to pop up. Usually, the file that is causing troubles is mentioned. Re-installing this file might solve the problem.&lt;br /&gt;
&lt;br /&gt;
=== OBJECT_SIGN: unexpected } in sign contents ===&lt;br /&gt;
One of the OBJECT_SIGN lines in the .stg file (of the tile that was loaded when this error showed up) contains a fault. Note that &amp;lt;tt&amp;gt;}&amp;lt;/tt&amp;gt; must be preceded by a &amp;lt;tt&amp;gt;{&amp;lt;/tt&amp;gt; character.&lt;br /&gt;
&lt;br /&gt;
=== OBJECT_SIGN: unsupported glyph `.' ===&lt;br /&gt;
Check the OBJECT_SIGN lines in the .stg file of the tile that was loaded when this error showed up.&lt;br /&gt;
&lt;br /&gt;
=== OpenAL error &amp;lt;AL_INVALID_VALUE&amp;gt;: bind source &amp;lt;alGenSources&amp;gt;&amp;lt;br /&amp;gt;Failed to generate audio source. ===&lt;br /&gt;
This error is probably displayed because of some misdirected audio settings in the [[aircraft]]s setup. Check the -sound.xml file of the aircraft and see if all files refered to really exist. If not, try to contact the author of the plane, so he can fix the problem in the [[Git]] version or solve the problem yourself and let someone commit the patch.&lt;br /&gt;
&lt;br /&gt;
=== OpenAL error (AL_INVALID_VALUE): constructor (alBufferData)&amp;lt;br /&amp;gt;Fatal error: Failed to buffer data. ===&lt;br /&gt;
Disabling sound is a temporarily solution for this problem.&lt;br /&gt;
&lt;br /&gt;
=== osgDB ac3d reader: could not find texture... ===&lt;br /&gt;
See [[#Failed to open file ...|Failed to open file ...]]&lt;br /&gt;
&lt;br /&gt;
=== osgDB ac3d reader: detected surface with less than 3 vertices! ===&lt;br /&gt;
In one of the loaded models a non-existing surface is found. This can be a single line (sometimes used to simulate thin wires) or a fault in the model.&lt;br /&gt;
&lt;br /&gt;
=== Program's vertex attrib binding ..., usrAttr... ===&lt;br /&gt;
Tells you that an effect binded certain attributes to a [[Shaders|shader]].&lt;br /&gt;
&lt;br /&gt;
=== QNAN ===&lt;br /&gt;
(Q)NAN stands for (Quiet) Not A Number, produced by 0/0 or other floating point break downs. There can be various causes for this:&lt;br /&gt;
* Using a &amp;quot;flap start&amp;quot; value of 0 in the [[YASim]] [[FDM]]. Use some small value like 0.001 instead.&lt;br /&gt;
&lt;br /&gt;
=== Scaling image... ===&lt;br /&gt;
This means a texture, whether in the scenery on your aircraft or anyone elses (when multiplayer is enabled), is not sized to powers of two. All textures in FlightGear have to be sized to power of two (eg. 16*16, 32*64, 32*1024). As of version 1.9 textures are resized automaticly, but it does slow your computer down, so it's better to resize the noted textures.&lt;br /&gt;
&lt;br /&gt;
=== ssgInit called without a valid OpenGL context ===&lt;br /&gt;
In short, your GL libraries are broken. So far only Red Hat 7.x users have experienced this (see http://www.redhat.com/bugzilla/show_bug.cgi?id=18867). The only solutions are possibly complicated ones: you can either change distributions (most of us prefer Debian) or upgrade/downgrade your Mesa libs.&lt;br /&gt;
&lt;br /&gt;
=== The system cannot find the file specified ===&lt;br /&gt;
* If you are running Windows Vista; start by looking in &amp;lt;tt&amp;gt;C:\Users\Owner\AppData\Local\VirtualStore&amp;lt;/tt&amp;gt; and seeing if you have a folder called FlightGear in there. If you do, cut-and-paste (merge) that one with &amp;lt;tt&amp;gt;C:\Program Files\Flightgear&amp;lt;/tt&amp;gt; and try to launch FlightGear again.&amp;lt;br /&amp;gt;&amp;lt;br /&amp;gt;'''Hint:''' you may need to go under Tools and Folder Options to specify &amp;quot;Show Hidden/System Files and Folders&amp;quot; in order for AppData to be visible.&lt;br /&gt;
* Make sure you did set the right executable (&amp;lt;tt&amp;gt;fgfs.exe&amp;lt;/tt&amp;gt;) on the first page of the [[FlightGear Launch Control]].&lt;br /&gt;
&lt;br /&gt;
=== Time zone reading failed ===&lt;br /&gt;
This is probably caused by a line-ending problem in the timezone files. Win32 users can resolve the problem by downloading a DOS to UNIX conversion utility available at http://www.nottingham.ac.uk/~eazdluf/d2u.zip. Run as `d2u *.tab` from within the timezone directory to fix your timezone files&lt;br /&gt;
&lt;br /&gt;
=== Traffic manager could not find airport ===&lt;br /&gt;
There is either an airport missing from apt.dat, or there is a wrong ICAO code in a [[Interactive Traffic#Building Traffic Files|traffic file]]. An airport missing from apt.dat could be due to a recent opening.&lt;br /&gt;
&lt;br /&gt;
=== Unable to choose requested pixel format ===&lt;br /&gt;
Error should be solved as of version 1.9. If not, try changing your [[FlightGear Launch Control#Page Four - Options and Run|BPP]] and/or resolution.&lt;br /&gt;
&lt;br /&gt;
=== Unable to find airport details for .... in FGTower::Init() ===&lt;br /&gt;
This error can be surpressed by disabling [[Interactive Traffic|AI Traffic]], via the AI/ATC [[menu]].&lt;br /&gt;
&lt;br /&gt;
The error appears when an airport in &amp;lt;tt&amp;gt;[[$FG ROOT]]/Airports/apt.dat.gz&amp;lt;/tt&amp;gt; cannot be found in &amp;lt;tt&amp;gt;[[$FG ROOT]]/ATC/default.tower&amp;lt;/tt&amp;gt; and &amp;lt;tt&amp;gt;[[$FG ROOT]]/ATC/default.atis&amp;lt;/tt&amp;gt;. Renaming the airports in the apt.dat.gz file ór in both default ATC files will fix the problem.&lt;br /&gt;
&lt;br /&gt;
=== Unable to open aircraft directory ===&lt;br /&gt;
The [[aircraft]] that you are trying to run most likely relies on another aircraft, which you did not install (yet). The error shows what aircraft, so go download that one!&lt;br /&gt;
=== Unexpected tag '...' found in YASim aircraft description ===&lt;br /&gt;
FlightGear found a non-existing tag in the [[FDM]] of the aircraft you are trying to launch. If you have not changed the original aircraft, contact the aircraft author. Else, check the FDM througly for mistakes.&lt;br /&gt;
&lt;br /&gt;
Also, make sure you didn't force a FDM to be loaded.&lt;br /&gt;
* '''Commandline:''' &amp;lt;tt&amp;gt;--fdm=...&amp;lt;/tt&amp;gt; should be left out.&lt;br /&gt;
* '''[[FGRun]]:''' &amp;lt;tt&amp;gt;Advanced &amp;gt; Flight Model&amp;lt;/tt&amp;gt; should be set to jsb (which will leave the whole command out of the commandline, so you can use this setting with any FDM).&lt;br /&gt;
&lt;br /&gt;
=== Unknown ... aircraft: ... defaulting to C172 ===&lt;br /&gt;
FlightGear is unable to load the forced [[FDM]] (set through &amp;lt;tt&amp;gt;--fdm=...&amp;lt;/tt&amp;gt; or via &amp;lt;tt&amp;gt;Advanced &amp;gt; Flight Model&amp;lt;/tt&amp;gt; in [[FGRun]]) for this aircraft. FlightGear automatically picks the right FDM for each aircraft, so there is no need to set it manually, unless you know what you are doing. In the Flight Model dialog of FGRun, set the FDM to &amp;lt;tt&amp;gt;jsb&amp;lt;/tt&amp;gt;; that is the &amp;quot;auto setting&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
=== Unknown exception to the main loop. Aborting... &amp;lt;br /&amp;gt;Possible cause: No such file or directory ===&lt;br /&gt;
This error could have a variety of sources, among them missing files but also other things. Increasing the [[FlightGear Launch Control#Debugging|log level]] to debug and repeating excactly what you did when the error came up, might provide some more information on what FlightGear was doing when the error occurred.&lt;br /&gt;
* Setting your [[FlightGear Launch Control#Page Four - Options and Run|BPP]] to a lower value might work.&lt;br /&gt;
* Changing the resolution to a smaller one might work as well.&lt;br /&gt;
&lt;br /&gt;
=== Unknown exception in main loop. Aborting...&amp;lt;br/&amp;gt;Possible cause: Not enough space ===&lt;br /&gt;
See [[Howto: Improve framerates#Optimus Technology]].&lt;br /&gt;
&lt;br /&gt;
When your computer does not have the Optimus Technolog (NVidia) or Hybrid Graphics technology (ATI), you are likely to be unable to run FlightGear. Integrated graphics cards are very weak; too weak for FlightGear. You can try to switch of some of the eye-candy though, but even then the same error may appear...&lt;br /&gt;
It may be useful to check the latest drivers for your graphic card. &lt;br /&gt;
•If you have a Nvidia GPU, then visit http://wiki.flightgear.org/Howto:Improve_framerates#nVidia.&lt;br /&gt;
•For '''ATI line''' of video cards, look at this site: http://www.amd.com/us/products/technologies/amd-catalyst/pages/catalyst.aspx .You should find a file named &amp;quot;Catalyst control center&amp;quot;, which allow you to modify the behaviour of your GPU with flightgear. I mean the Antialiasing control, the triple buffering, etc.&lt;br /&gt;
=== WARNING: Couldn't convert texture... ===&lt;br /&gt;
You are trying to run an aircraft not compatible with your FlightGear version. Most of the time, this error appears when you fly an aircraft, textured with .png files on versions older than 1.9. Convert the textures manually to .rgb or upgrade your FlightGear version.&lt;br /&gt;
&lt;br /&gt;
=== Warning: Could not find plugin to read objects from file ... ===&lt;br /&gt;
A library is missing from your computer. Therefore, certain fileformats cannot be read. Try to reinstall/update [[OSG]], as the libraries used by FlightGear should be part of the standard package.&lt;br /&gt;
&lt;br /&gt;
=== Warning: Picked up TriangleIntersect ===&lt;br /&gt;
Reduce your [[FlightGear Launch Control#Debugging|Log Level]] to alert. Or [[Showstoppers|send the fgfs output to /dev/null (unix systems) or 2&amp;gt;nul (Windows)]]. The errors might still be shown, but do not affect the sim anymore.&lt;br /&gt;
&lt;br /&gt;
=== Warning: TangentSpaceGenerator: unknown primitive mode 9 ===&lt;br /&gt;
This is an [[OSG]] error, showing up when an effect needs tangent vectors, but polygons are not support. The error itself can be ignored, altough some [[shaders]] may look wrong. Shader developers should try to minimise the use of polygons and use triangles and quads instead.&lt;br /&gt;
&lt;br /&gt;
=== YASim SOLUTION FAILURE: Solution failed to converge after 10000 iterations ===&lt;br /&gt;
Some control in the [[YASim]] [[FDM]] is too weak, according to YASim, to control the aircraft. An effectiveness tag will be required in the FDM to solve this error.&lt;br /&gt;
&lt;br /&gt;
=== YASim SOLUTION FAILURE:&amp;lt;br /&amp;gt;Zero length fuselage ===&lt;br /&gt;
There is a problem in the [[FDM]]. A fuselage section with similar ax and ay was created. Change the ax and/or ay values to match the aircraft.&lt;br /&gt;
&lt;br /&gt;
=== YOU HAVE AN INCOMPATIBLE CFG FILE FOR THIS AIRCRAFT. RESULTS WILL BE UNPREDICTABLE !! ===&lt;br /&gt;
Make sure the [[JSBSim]] [[FDM]] of the aircraft has a &amp;lt;code&amp;gt;&amp;lt;fdm_config version=&amp;quot;2.0&amp;quot;&amp;lt;/code&amp;gt; tag.&lt;br /&gt;
&lt;br /&gt;
== Errors without known solutions ==&lt;br /&gt;
Please take a look at the upcoming errors and see if you know a solution to get rid of them. Your additions are greatly appreciated!&lt;br /&gt;
&lt;br /&gt;
=== Aircraft propulsion element has problems in file ... ===&lt;br /&gt;
&lt;br /&gt;
=== AL Error (fx): Invalid Value at pitch and gain ===&lt;br /&gt;
The sound effect's pitch (high or low) and gain (volume multiplication factor) values are not valid.&lt;br /&gt;
&lt;br /&gt;
=== AL Error (sound manager): Invalid Operation at update ===&lt;br /&gt;
&lt;br /&gt;
=== AL Error (sound manager): Invalid Value at buffer add data&amp;lt;br /&amp;gt;No such buffer! ===&lt;br /&gt;
&lt;br /&gt;
=== Failed to execute command nasal ===&lt;br /&gt;
Has something to do with the [[Nasal]] scripting language used by FlightGear.&lt;br /&gt;
&lt;br /&gt;
=== Failed to tie (or untie while closing) property ... to object methods ===&lt;br /&gt;
A JSBSim error.&lt;br /&gt;
&lt;br /&gt;
=== FGMultiplayMgr::MP_ProcessData - message from ... has invalid length! ===&lt;br /&gt;
&lt;br /&gt;
=== FGMultiplayMgr::MP_ProcessData: Result too large ===&lt;br /&gt;
&lt;br /&gt;
===GPS: malformed route, index=1===&lt;br /&gt;
&lt;br /&gt;
=== Mesa 7.3 implementation error: bad texture level in r300UploadSubImage ===&lt;br /&gt;
http://www.flightgear.org/forums/viewtopic.php?f=2&amp;amp;t=6706&amp;amp;start=0&amp;amp;st=0&amp;amp;sk=t&amp;amp;sd=a&lt;br /&gt;
&lt;br /&gt;
=== Nasal runtime error: stack overflow ===&lt;br /&gt;
&lt;br /&gt;
=== No image file for texture, using white ===&lt;br /&gt;
A [[Shaders|shader]] error, possibly you (or the developer) have/has not specified a texture for a surface while modeling the aircraft model in AC3D, Blender, Wings...&lt;br /&gt;
&lt;br /&gt;
=== No path in /sim/sound/path ===&lt;br /&gt;
You (or the developer) have/has not specified a proper sound file in the aircraft's -set.xml file.&lt;br /&gt;
&lt;br /&gt;
=== OpenAL error (AL_ILLEGAL_COMMAND): set_source_pos ===&lt;br /&gt;
&lt;br /&gt;
Has something to do with OpenAL not understanding where the sound comes from.&lt;br /&gt;
&lt;br /&gt;
=== OpenAL error (AL_ILLEGAL_COMMAND): set_volume ===&lt;br /&gt;
&lt;br /&gt;
Has something to do with OpenAL not understanding the sound volume.&lt;br /&gt;
&lt;br /&gt;
=== PT_vs_hpt: ran out of layers ===&lt;br /&gt;
This is issued from the atmosphere implementation in FlightGear's environment system. A comment in the code says: &amp;quot;''should never get here''&amp;quot;. Please provide input when this happens: excessive altitudes? Negative altitudes?&lt;br /&gt;
&lt;br /&gt;
=== Tried to initialize a non-existent engine! ===&lt;br /&gt;
The developer of the aircraft did not code the engine properly. &lt;br /&gt;
&lt;br /&gt;
'''Developers:''' Check that the engine.xml file, FDM.xml, and -set.xml is coded properly.&lt;br /&gt;
&lt;br /&gt;
=== Unknown Chunk: ***UNKNOWN*** (0xA08A) ===&lt;br /&gt;
&lt;br /&gt;
=== Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,) ===&lt;br /&gt;
This warning is generated from OSG. Set your environment variable&lt;br /&gt;
 OSG_NOTIFY_LEVEL=FATAL&lt;br /&gt;
&lt;br /&gt;
=== Warning: GraphicsWindowWin32::grabFocus() - Failed grabbing the focus ===&lt;br /&gt;
It seems that this happens when you have another window open and you are &amp;quot;focusing&amp;quot; (the window is active) on it. FlightGear will try to grab itself infront of the other window.&lt;br /&gt;
&lt;br /&gt;
=== WARNING: PUI: Too many live puInterfaces open at once! ===&lt;br /&gt;
Appears when printing large outputs (very) frequently on the screen.&lt;br /&gt;
&lt;br /&gt;
=== Warning: State::drawQuads(0, 154400) too large handle in remapping to ushort glDrawElements ===&lt;br /&gt;
[[fr:Howto: Débarrassez-vous des erreurs les plus fréquentes]]&lt;br /&gt;
&lt;br /&gt;
[[Category:Howto|Console output]]&lt;/div&gt;</summary>
		<author><name>Sahliyoussef</name></author>
	</entry>
</feed>