https://wiki.flightgear.org/w/api.php?action=feedcontributions&user=Wicking&feedformat=atomFlightGear wiki - User contributions [en]2024-03-29T04:33:23ZUser contributionsMediaWiki 1.39.6https://wiki.flightgear.org/w/index.php?title=Advanced_weather&diff=54314Advanced weather2012-09-22T15:55:45Z<p>Wicking: /* One weather system */</p>
<hr />
<div>The '''Advanced Weather''' system was formerly called '''Local Weather''' and is included in FlightGear since version 2.4 (see [http://www.flightgear.org/news/flightgear-v2-4-0-released/ release notes]). It was then renamed and improved for FlightGear 2.6 (see [http://www.flightgear.org/news/flightgear-v2-6-0-released/ release notes] and [http://www.flightgear.org/tours/advanced-weather-v1-4-in-flightgear-2-6/ detailed explanation and many screenshots] for version 1.4 of the Advanced Weather in FlightGear 2.6).<br />
<br />
== Unification of basic and advanced weather system == <br />
It is planned to unify the weather systems in FlightGear. Possibly for the upcoming version 3.0. It is therefore needed to improve the usability of the advanced weather configuration system. Join the [http://www.flightgear.org/forums/viewtopic.php?f=69&t=16630 discussion on this topic in the forums].<br />
<br />
== History ==<br />
Status: August 2010<br />
<br />
The current weather system of Flightgear can be called global when Flightgear runs offline: Any menu weather setting, be it windspeed, visibility, precipitation or cloud coverage, affects the weather everywhere. It is not possible to fly to a region where the cloud cover is different, or see precipitation from an aircraft flying in sunshine, or to observe a change in atmospheric pressure by flying somewhere else.<br />
<br />
When online, the weather system offers a link with METAR servers, which makes the weather locally-determined global: One can change the weather by flying to a different location where a different METAR is available, but the change happens instantaneously everywhere, i.e. there is no transition of for example crossing a rain front or leaving dense clouds behind to emerge in sunshine.<br />
<br />
A local weather system in contrast is one in which continuous changes from the weather at one location to the weather in a different location are simulated, i.e. weather phenomena are tied to a specific location. Needless to say, a local weather system is significantly more complicated to simulate than the present system. Below is a conceptual outline how a local weather system for Flightgear could be created using mainly existing technology and code.<br />
<br />
<br />
== Scales for weather phenomena ==<br />
<br />
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<br />
<br />
* simulate weather phenomena at different scales<br />
* ideally work offline as well as online<br />
* allow modification by the user on various scales<br />
* be reasonably fast to run in real-time <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
=== Small scale - effect volumes and average conditions ===<br />
<br />
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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mid scale - weather tiles ===<br />
<br />
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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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<br />
<br />
* populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft <br />
* make sure the models are spaced sufficiently far apart<br />
* make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)<br />
* populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft<br />
(...)<br />
<br />
The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles. <br />
<br />
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.<br />
<br />
<center><br />
[[File:Clouds-coldfront02.jpg|400px]]<br />
</center><br />
<br />
=== Large scale - tile placement rules ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
== Connection with the METAR system ==<br />
<br />
Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:<br />
<br />
* selection of tile type<br />
* placement of EVs and models inside the tile<br />
* continuously varying weather parameters<br />
<br />
=== Selection of tile type ===<br />
<br />
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.<br />
<br />
=== Placement of EVs and models inside the tile ===<br />
<br />
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).<br />
<br />
=== METAR and continuously varying weather parameters ===<br />
<br />
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).<br />
<br />
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<br />
<br />
p = (sum p_i (1/d_i)) / (sum 1/d_i)<br />
<br />
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.<br />
<br />
== Related Discussions ==<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 Weather algorithms] (06/2010)<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8137 A smart cloud altitude algorithm] (05/2010)<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7591 Weather dynamics] (04/2010)<br />
* [http://flightgear.org/forums/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010)<br />
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010)<br />
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7358 A local weather system] (03/2010)<br />
<br />
== Connection with the Multiplayer system ==<br />
<br />
(should be written by someone who knows what the Multiplayer system can and cannot do)<br />
<br />
== Development ==<br />
<br />
* 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&t=7358&st=0&sk=t&sd=a&start=165#p94765]<br />
* 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 "NONE" or "MUTE" logging priority [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370].<br />
* The feature-checking approach used by "compat_layer.nas" 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&t=7358&p=96439#p96358]<br />
* 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.<br />
* 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.<br />
* 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.<br />
* 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&t=7358&st=0&sk=t&sd=a&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).<br />
<br />
== Feature requests on the C++ side ==<br />
<br />
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&t=8365 Weather algorithms discussion] from 06/2010.<br />
<br />
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++.<br />
<br />
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:<br />
<br />
=== Terrain related ===<br />
* (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&t=7358&start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].<br />
<br />
* 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.<br />
<br />
=== Environment related ===<br />
* (08/2012): Provide an option to disable the precipitation "layer" system [http://flightgear.org/forums/viewtopic.php?f=69&t=7358&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]<br />
<br />
* (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&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].<br />
<br />
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]<br />
<br />
* 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<br />
<br />
=== Cloud placement ===<br />
* 08/2012: Cloud placement meanwhile uses a new fgcommand "add-cloud", 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.<br />
<br />
* 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:<br />
<br />
:* 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. <br />
<br />
:* 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.<br />
<br />
=== Performance bottlenecks ===<br />
<br />
For reference, the main performance bottlenecks in v0.81 seem to be:<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
* 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<br />
<br />
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) <br />
<br />
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery<br />
<br />
* 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.<br />
<br />
* frequently used fgcommands <br />
<br />
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)<br />
<br />
=== New Nasal API requests ===<br />
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++<br />
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.<br />
<br />
== Current development status ==<br />
<br />
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.<br />
<br />
A feature gallery of version 0.85:<br />
<br />
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]<br />
<br />
<br />
A feature gallery of version 1.0:<br />
<br />
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]<br />
<br />
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]<br />
<br />
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]<br />
<br />
== Download ==<br />
* Advanced weather is now included in FlightGear, so in its Git repository you get the newest version: http://gitorious.org/fg<br />
<br />
== Related content ==<br />
* [[Atmospheric light scattering]]<br />
<br />
[[Category:Development]]</div>Wickinghttps://wiki.flightgear.org/w/index.php?title=Advanced_weather&diff=54313Advanced weather2012-09-22T15:54:53Z<p>Wicking: some hints to the developement</p>
<hr />
<div>The '''Advanced Weather''' system was formerly called '''Local Weather''' and is included in FlightGear since version 2.4 (see [http://www.flightgear.org/news/flightgear-v2-4-0-released/ release notes]). It was then renamed and improved for FlightGear 2.6 (see [http://www.flightgear.org/news/flightgear-v2-6-0-released/ release notes] and [http://www.flightgear.org/tours/advanced-weather-v1-4-in-flightgear-2-6/ detailed explanation and many screenshots] for version 1.4 of the Advanced Weather in FlightGear 2.6).<br />
<br />
== One weather system == <br />
It is planned to unify the weather systems in FlightGear. Possibly for the upcoming version 3.0. It is therefore needed to improve the usability of the advanced weather configuration system. Join the [http://www.flightgear.org/forums/viewtopic.php?f=69&t=16630 discussion on this topic in the forums].<br />
<br />
<br />
== History ==<br />
Status: August 2010<br />
<br />
The current weather system of Flightgear can be called global when Flightgear runs offline: Any menu weather setting, be it windspeed, visibility, precipitation or cloud coverage, affects the weather everywhere. It is not possible to fly to a region where the cloud cover is different, or see precipitation from an aircraft flying in sunshine, or to observe a change in atmospheric pressure by flying somewhere else.<br />
<br />
When online, the weather system offers a link with METAR servers, which makes the weather locally-determined global: One can change the weather by flying to a different location where a different METAR is available, but the change happens instantaneously everywhere, i.e. there is no transition of for example crossing a rain front or leaving dense clouds behind to emerge in sunshine.<br />
<br />
A local weather system in contrast is one in which continuous changes from the weather at one location to the weather in a different location are simulated, i.e. weather phenomena are tied to a specific location. Needless to say, a local weather system is significantly more complicated to simulate than the present system. Below is a conceptual outline how a local weather system for Flightgear could be created using mainly existing technology and code.<br />
<br />
<br />
== Scales for weather phenomena ==<br />
<br />
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<br />
<br />
* simulate weather phenomena at different scales<br />
* ideally work offline as well as online<br />
* allow modification by the user on various scales<br />
* be reasonably fast to run in real-time <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
=== Small scale - effect volumes and average conditions ===<br />
<br />
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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mid scale - weather tiles ===<br />
<br />
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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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<br />
<br />
* populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft <br />
* make sure the models are spaced sufficiently far apart<br />
* make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)<br />
* populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft<br />
(...)<br />
<br />
The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles. <br />
<br />
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.<br />
<br />
<center><br />
[[File:Clouds-coldfront02.jpg|400px]]<br />
</center><br />
<br />
=== Large scale - tile placement rules ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
== Connection with the METAR system ==<br />
<br />
Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:<br />
<br />
* selection of tile type<br />
* placement of EVs and models inside the tile<br />
* continuously varying weather parameters<br />
<br />
=== Selection of tile type ===<br />
<br />
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.<br />
<br />
=== Placement of EVs and models inside the tile ===<br />
<br />
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).<br />
<br />
=== METAR and continuously varying weather parameters ===<br />
<br />
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).<br />
<br />
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<br />
<br />
p = (sum p_i (1/d_i)) / (sum 1/d_i)<br />
<br />
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.<br />
<br />
== Related Discussions ==<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 Weather algorithms] (06/2010)<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8137 A smart cloud altitude algorithm] (05/2010)<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7591 Weather dynamics] (04/2010)<br />
* [http://flightgear.org/forums/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010)<br />
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010)<br />
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7358 A local weather system] (03/2010)<br />
<br />
== Connection with the Multiplayer system ==<br />
<br />
(should be written by someone who knows what the Multiplayer system can and cannot do)<br />
<br />
== Development ==<br />
<br />
* 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&t=7358&st=0&sk=t&sd=a&start=165#p94765]<br />
* 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 "NONE" or "MUTE" logging priority [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370].<br />
* The feature-checking approach used by "compat_layer.nas" 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&t=7358&p=96439#p96358]<br />
* 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.<br />
* 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.<br />
* 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.<br />
* 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&t=7358&st=0&sk=t&sd=a&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).<br />
<br />
== Feature requests on the C++ side ==<br />
<br />
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&t=8365 Weather algorithms discussion] from 06/2010.<br />
<br />
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++.<br />
<br />
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:<br />
<br />
=== Terrain related ===<br />
* (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&t=7358&start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].<br />
<br />
* 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.<br />
<br />
=== Environment related ===<br />
* (08/2012): Provide an option to disable the precipitation "layer" system [http://flightgear.org/forums/viewtopic.php?f=69&t=7358&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]<br />
<br />
* (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&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].<br />
<br />
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]<br />
<br />
* 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<br />
<br />
=== Cloud placement ===<br />
* 08/2012: Cloud placement meanwhile uses a new fgcommand "add-cloud", 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.<br />
<br />
* 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:<br />
<br />
:* 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. <br />
<br />
:* 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.<br />
<br />
=== Performance bottlenecks ===<br />
<br />
For reference, the main performance bottlenecks in v0.81 seem to be:<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
* 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<br />
<br />
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) <br />
<br />
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery<br />
<br />
* 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.<br />
<br />
* frequently used fgcommands <br />
<br />
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)<br />
<br />
=== New Nasal API requests ===<br />
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++<br />
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.<br />
<br />
== Current development status ==<br />
<br />
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.<br />
<br />
A feature gallery of version 0.85:<br />
<br />
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]<br />
<br />
<br />
A feature gallery of version 1.0:<br />
<br />
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]<br />
<br />
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]<br />
<br />
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]<br />
<br />
== Download ==<br />
* Advanced weather is now included in FlightGear, so in its Git repository you get the newest version: http://gitorious.org/fg<br />
<br />
== Related content ==<br />
* [[Atmospheric light scattering]]<br />
<br />
[[Category:Development]]</div>Wickinghttps://wiki.flightgear.org/w/index.php?title=Talk:A_local_weather_system&diff=54312Talk:A local weather system2012-09-22T15:26:06Z<p>Wicking: moved Talk:A local weather system to Talk:Advanced weather: this is the new name since it was included in FlightGear 2.4</p>
<hr />
<div>#REDIRECT [[Talk:Advanced weather]]</div>Wickinghttps://wiki.flightgear.org/w/index.php?title=Talk:Advanced_weather&diff=54311Talk:Advanced weather2012-09-22T15:26:06Z<p>Wicking: moved Talk:A local weather system to Talk:Advanced weather: this is the new name since it was included in FlightGear 2.4</p>
<hr />
<div>= improving the FG atmosphere model =<br />
* http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=70986&hilit=#p70714<br />
* http://www.av8n.com/fly/fgfs/README.altimetry.html<br />
* http://www.av8n.com/physics/altimetry.htm<br />
* http://flightgear.org/forums/viewtopic.php?f=6&t=12005&p=124326&hilit=#p124326<br />
* http://www.flightgear.org/forums/viewtopic.php?f=6&t=12005&start=15#p124435<br />
* http://flightgear.org/forums/viewtopic.php?f=47&t=11274&p=123972&hilit=#p123972<br />
<br />
<br />
= documentation =<br />
* meaning of various flags?<br />
<br />
= gui issues =<br />
There's currently: OK and Clear/End<br />
<br />
I ASSUME, that it would be more intuitive for most people to simply replace these two buttons with a single [APPLY] button and implicitly do CLEAR/END + OK that way. To stop the system, another item could be added to the scenario combo box saying "TERMINATE" or "DISABLED".<br />
<br />
= refactoring =<br />
* there's some overlapping stuff in tile codes and tile names, e.g. "Altocumulus sky" vs. "altocumulus_sky", this could be unified, so that a single hash could be used.<br />
<br />
= old code =<br />
* many of the CHECKS in compat_layer.nas are now obsolete (1==0)<br />
<br />
= dead code =</div>Wickinghttps://wiki.flightgear.org/w/index.php?title=A_local_weather_system&diff=54310A local weather system2012-09-22T15:26:06Z<p>Wicking: moved A local weather system to Advanced weather: this is the new name since it was included in FlightGear 2.4</p>
<hr />
<div>#REDIRECT [[Advanced weather]]</div>Wickinghttps://wiki.flightgear.org/w/index.php?title=Advanced_weather&diff=54309Advanced weather2012-09-22T15:26:06Z<p>Wicking: moved A local weather system to Advanced weather: this is the new name since it was included in FlightGear 2.4</p>
<hr />
<div>Status: August 2010<br />
<br />
The current weather system of Flightgear can be called global when Flightgear runs offline: Any menu weather setting, be it windspeed, visibility, precipitation or cloud coverage, affects the weather everywhere. It is not possible to fly to a region where the cloud cover is different, or see precipitation from an aircraft flying in sunshine, or to observe a change in atmospheric pressure by flying somewhere else.<br />
<br />
When online, the weather system offers a link with METAR servers, which makes the weather locally-determined global: One can change the weather by flying to a different location where a different METAR is available, but the change happens instantaneously everywhere, i.e. there is no transition of for example crossing a rain front or leaving dense clouds behind to emerge in sunshine.<br />
<br />
A local weather system in contrast is one in which continuous changes from the weather at one location to the weather in a different location are simulated, i.e. weather phenomena are tied to a specific location. Needless to say, a local weather system is significantly more complicated to simulate than the present system. Below is a conceptual outline how a local weather system for Flightgear could be created using mainly existing technology and code.<br />
<br />
<br />
== Scales for weather phenomena ==<br />
<br />
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<br />
<br />
* simulate weather phenomena at different scales<br />
* ideally work offline as well as online<br />
* allow modification by the user on various scales<br />
* be reasonably fast to run in real-time <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
=== Small scale - effect volumes and average conditions ===<br />
<br />
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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Mid scale - weather tiles ===<br />
<br />
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. <br />
<br />
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. <br />
<br />
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).<br />
<br />
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<br />
<br />
* populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft <br />
* make sure the models are spaced sufficiently far apart<br />
* make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)<br />
* populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft<br />
(...)<br />
<br />
The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles. <br />
<br />
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.<br />
<br />
<center><br />
[[File:Clouds-coldfront02.jpg|400px]]<br />
</center><br />
<br />
=== Large scale - tile placement rules ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
== Connection with the METAR system ==<br />
<br />
Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:<br />
<br />
* selection of tile type<br />
* placement of EVs and models inside the tile<br />
* continuously varying weather parameters<br />
<br />
=== Selection of tile type ===<br />
<br />
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.<br />
<br />
=== Placement of EVs and models inside the tile ===<br />
<br />
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).<br />
<br />
=== METAR and continuously varying weather parameters ===<br />
<br />
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).<br />
<br />
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<br />
<br />
p = (sum p_i (1/d_i)) / (sum 1/d_i)<br />
<br />
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.<br />
<br />
== Related Discussions ==<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 Weather algorithms] (06/2010)<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8137 A smart cloud altitude algorithm] (05/2010)<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7591 Weather dynamics] (04/2010)<br />
* [http://flightgear.org/forums/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010)<br />
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010)<br />
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7358 A local weather system] (03/2010)<br />
<br />
== Connection with the Multiplayer system ==<br />
<br />
(should be written by someone who knows what the Multiplayer system can and cannot do)<br />
<br />
== Development ==<br />
<br />
* 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&t=7358&st=0&sk=t&sd=a&start=165#p94765]<br />
* 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 "NONE" or "MUTE" logging priority [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370].<br />
* The feature-checking approach used by "compat_layer.nas" 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&t=7358&p=96439#p96358]<br />
* 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.<br />
* 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.<br />
* 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.<br />
* 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&t=7358&st=0&sk=t&sd=a&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).<br />
<br />
== Feature requests on the C++ side ==<br />
<br />
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&t=8365 Weather algorithms discussion] from 06/2010.<br />
<br />
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++.<br />
<br />
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:<br />
<br />
=== Terrain related ===<br />
* (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&t=7358&start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].<br />
<br />
* 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.<br />
<br />
=== Environment related ===<br />
* (08/2012): Provide an option to disable the precipitation "layer" system [http://flightgear.org/forums/viewtopic.php?f=69&t=7358&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]<br />
<br />
* (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&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone].<br />
<br />
* expose the atmospheric model to the property tree (or Nasal) [http://www.flightgear.org/forums/viewtopic.php?f=30&t=8743#p86387] [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=15#p70714] [http://www.av8n.com/fly/fgfs/README.altimetry.html] [http://www.av8n.com/physics/altimetry.htm]<br />
<br />
* 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<br />
<br />
=== Cloud placement ===<br />
* 08/2012: Cloud placement meanwhile uses a new fgcommand "add-cloud", 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.<br />
<br />
* 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:<br />
<br />
:* 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. <br />
<br />
:* 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.<br />
<br />
=== Performance bottlenecks ===<br />
<br />
For reference, the main performance bottlenecks in v0.81 seem to be:<br />
<br />
* 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.<br />
<br />
* 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. <br />
<br />
* 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<br />
<br />
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) <br />
<br />
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery<br />
<br />
* 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.<br />
<br />
* frequently used fgcommands <br />
<br />
* property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)<br />
<br />
=== New Nasal API requests ===<br />
For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++<br />
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.<br />
<br />
== Current development status ==<br />
<br />
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.<br />
<br />
A feature gallery of version 0.85:<br />
<br />
[[File:local_weather_0.85_01.jpg|150px|[ Cumulus and Cirrocumulus clouds (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_02.jpg|150px|[ Cirrus and Cirrostratus clouds heralding a warmfront (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_03.jpg|150px|[ 45 km cloud visibility range (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_04.jpg|150px|[ Realistic cloud bottoms (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_05.jpg|150px|[ Cumulus and Altocumulus clouds (Local Weather v0.85)]]<br />
[[File:local_weather_0.85_06.jpg|150px|[ Multiple 3d layered clouds (Local Weather v0.85)]]<br />
<br />
<br />
A feature gallery of version 1.0:<br />
<br />
[[File:local_weather_1.00_05.jpg|150px|[ Realistic skies with multiple cloud types (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_06.jpg|150px|[ Thin 3d cloud layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_11.jpg|150px|[ Thermal soaring beneath Cumulus clouds (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_12.jpg|150px|[ Flying with both thermal and ridge lift (Local Weather v1.0)]]<br />
<br />
[[File:local_weather_1.00_01.jpg|150px|[ Thick stratocumulus layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_03.jpg|150px|[ Thin Cirrocumulus sheets (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_02.jpg|150px|[ Altostratus layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_04.jpg|150px|[ Stratus coverage obscuring the sunlight (Local Weather v1.0)]]<br />
<br />
[[File:local_weather_1.00_07.jpg|150px|[ Evening light... (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_09.jpg|150px|[ ... and morning light (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_10.jpg|150px|[ Multiple 3d layers (Local Weather v1.0)]]<br />
[[File:local_weather_1.00_08.jpg|150px|[ Heavy rain (Local Weather v1.0)]]<br />
<br />
== Download ==<br />
* [http://www.phy.duke.edu/~trenk/files/local_weather_fgfsGITv1.0.tgz Local Weather package v1.0(Thorsten)]<br />
* [http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]<br />
<br />
== Related content ==<br />
* [[Atmospheric light scattering]]<br />
<br />
[[Category:Development]]</div>Wickinghttps://wiki.flightgear.org/w/index.php?title=Eurocopter_EC135&diff=54130Eurocopter EC1352012-09-16T18:08:11Z<p>Wicking: /* Development status/Issues/Todo */ wrong text removed</p>
<hr />
<div>{{infobox Aircraft<br />
|image =Ec135.png<br />
|name =Eurocopter EC135<br />
|type =Helicopter<br />
|livery= ADAC, ANWB, ÖAMTC, Prototype<br />
|fdm =YASim<br />
|status =v0.5 in 2.6.0<br />
|authors =Heiko Schulz, Maik Justus, Melchior Franz<br />
|fgname =ec135<br />
}}This is an model of the '''Eurocopter EC135''', a light twin-engine, multi-mission [[helicopter]]. <br />
<br />
[[Eurocopter]] has two version of it:<br />
* '''EC 135 P2i''': PRATT and WHITNEY PW 206B2 turbine engine with 743 PS (horsepower).<br />
* '''EC 135 T2i''': TURBOMECA Arrius 2B2 turbine engine with 706 PS.<br />
<br />
The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.<br />
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.<br />
<br />
The model includes the German ADAC version, the Austrian ÖAMTC version, the Dutch ANWB (Lifeliner) version and the EC135-prototype version as default.<br />
<br />
== Development status/Issues/Todo ==<br />
[[File:EC135NEW2.jpg|thumb|right|270px|New EC135 expected end of Summer/autumn 2012- here the "Offshore"variant]]<br />
<br />
[[File:EC135NEWBP.jpg|thumb|right|270px|New EC135 expected end of Summer/autumn 2012- here the converted "Bundespolizei"-livery by Sanni aka Tanja S.]]<br />
<br />
[[File:EC135NEW1.jpg|thumb|right|270px|New EC135 expected end of summer/autumn 2012- here the "Mountain rescue" variant]]<br />
<br />
[[File:Ec135_LFLJ.jpg|thumb|right|270px|EC 135 "D-HECZ" (prototype) in FGFS 1.9.1 takes off above the clouds at Courchevel; see [[Flying the helicopter]] ]]<br />
===Next upcoming version v1.0 (probably FGFS 3.0.0 Release)===<br />
Expected end of summer/autumn 2012<br />
<br />
* new 3d-model more accurate and detailed<br />
* latest shader (bumpspec-reflection and glasshader)<br />
* new, much more accurate fdm close to POH<br />
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...<br />
* one single texture file - old liveries can be converted<br />
* finally a complete flightdeck with photorealistic panel<br />
* and of course completely Rembrandt compatible!<br />
* and more to come....<br />
<br />
=== Actual version: v.0.6 (EC135-Repo on gitorious.org) ===<br />
<br />
* fixes wrong rotorshaft tilt in fdm<br />
* some bugfixes on fuselage<br />
* sound fixed<br />
<br />
very next To-Do:<br />
* rotor model and animation<br />
* bugfixing on windscreen<br />
* instruments finishing<br />
<br />
=== Actual version: v.0.5 (FGFS 2.6.0 release) ===<br />
<br />
* photorealistic panel<br />
* liveries improved<br />
* better fps-perfomance while changing liveries<br />
<br />
=== Actual version: v.0.4 (FGFS 1.9.1 release) ===<br />
<br />
This is a complete rebuild of the ec135 with a much better exterior<br />
model It is currently a work in progress, so a lots of things can be<br />
broken now, but it should be not worser to fly than in the last version.<br />
<br />
* complete new exterior with added antennas and other mounting parts(search lights, cameras)<br />
* glas shader with fresnel effect<br />
* variants changing over mp<br />
* better texture mapping so it should be easy to make your own livery<br />
<br />
Currently in Progress at this date:<br />
* replacing the panels and adding the digital version with a nearly photorealistic one!<br />
* adding the overhead<br />
* making it all clickable and working from the cockpit<br />
* better interior : EMS and VIP-version<br />
* remade D-HECZ-Livery<br />
* mapped ec135 with D-HECZ-Livery<br />
* added ADAC Chr. 23-Livery made with photorealistic parts like Fenestron and Logos- still some things missing like lines<br />
* added phtorealistic textures to exhaust and rails<br />
* adding and finishing the missing liveries like the OEAMTC, G-SASA, Bavarian Police<br />
* adding the high skid model<br />
<br />
=== Actual version: v.0.2 ===<br />
<br />
* fully new made 3D-model - matching real good to the real one<br />
* improved interior with stick and pedals<br />
* changed variants: ADAC Chr. 31 "Berlin", D-HECZ "second prototype", ÖAMTC Christopherus 1<br />
* improved cockpit with half analog IFR-panel <br />
* HSI is now working, working VOR<br />
* GSDI selectable<br />
* improved and more detailed main rotor with incidence animation<br />
* Fenestron now with the correct configuration of the blades: 1-4-1-4<br />
* dynamic flight model now with the correct position of the CG<br />
* added frontlight, retractable landinglight, strobes with the correct frequency, beacon with the correct frequency<br />
* rotor brake system now working<br />
<br />
To-Do:<br />
* adding antennas and other mounting parts (search lights, cameras)<br />
* fully clickable [[cockpit]] (half-analog and digital)<br />
* complete light function<br />
* variants with radardome<br />
* variants with high-skid<br />
* much more (international)variants! <br />
* realistic dynamic flight model<br />
* mainrotors much more detailed<br />
* animation of the fenestron blades (incidence)<br />
* sound still could be improved<br />
* adding pilots figures<br />
<br />
=== Actual version: v.0.1 ===<br />
<br />
* first 3d-model of an ec135<br />
* first try of an ec135-flight dynamic model<br />
* livery changing<br />
* two version: ADAC and Bavarian Police<br />
* first version of the half analog cockpit<br />
* doors to open<br />
<br />
To-Do:<br />
* better quality of the 3d-model<br />
* full mainrotor animation<br />
* better Fenestron <br />
* improve cockpit, implementing a working HSI<br />
* clean up the xml-files<br />
* improve soundsystem<br />
* realistic dynamic flight model<br />
* selectable GSDI<br />
* implementing rotor brake system<br />
* more variants<br />
<br />
== External links ==<br />
[http://www.eurocopter.de www.eurocopter.de]<br />
<br />
{{Eurocopter}}<br />
<br />
[[Category:Helicopters]]</div>Wickinghttps://wiki.flightgear.org/w/index.php?title=Tupolev_Tu-154B&diff=53922Tupolev Tu-154B2012-09-08T19:20:12Z<p>Wicking: link to new version of the plane that works with fg 2.8</p>
<hr />
<div>{{infobox Aircraft<br />
|image = Tu154Innsbruck.png<br />
|alt = Tupolev 154-B taking off from [[Amsterdam Airport Schiphol|Schiphol]]<br />
|name = Tupolev 154-B<br />
|type = Airliner<br />
|fdm = JSBSim<br />
|status-fdm = 5<br />
|status-systems = 5<br />
|status-cockpit = 5<br />
|status-model = 5<br />
|authors = <br />
|fgname = <br />
|download = http://yurik.flightgear.ru/tu154b-release/tu154b-1.2_may2011.tar.gz <!-- dl-link in this announce is for old version of the plane: http://yurik.flightgear.ru/tu154b-release/announce.html --><br />
}}<div style="padding-left:20px;">''Not to be confused with the [[Tupolev Tu-154]], a less complete simulation.''</div><br />
<br />
The '''Tupolev Tu-154B''' is a Russian medium-range jet [[:Category:Airliners|airliner]].<br />
<br />
[[FlightGear]]'s Tu-154 was converted from a model originally designed for Microsoft Flight Simulator by [http://www.protu-154.net/index_e.html Project Tupolev]. Systems and animations had to be re-rewritten especially for FlightGear though.<br />
<br />
== External links ==<br />
* [http://yurik.flightgear.ru/tu154eng.html Official website] of the project<br />
* [http://www.flightgear.org/forums/viewtopic.php?f=4&t=4925 Forum topic]<br />
<br />
{{Tupolev}}<br />
<br />
[[Category:Airliners]]<br />
[[Category:Military transport aircraft]]<br />
[[Category:Trijets]]</div>Wickinghttps://wiki.flightgear.org/w/index.php?title=MBB_Bo_105&diff=35553MBB Bo 1052011-10-08T08:19:54Z<p>Wicking: /* New Texture */ horacios</p>
<hr />
<div>{{infobox Aircraft<br />
|image =Bo105.jpg<br />
|name =Bo 105<br />
|type =Helicopter<br />
|fdm = YASim<br />
|status = production<br />
|authors = Melchior Franz, Maik Justus (FDM)<br />
|ratingfdm =5<br />
|ratingexterior=4<br />
|ratingcockpit=4<br />
|ratingsounds =5<br />
|fgname =bo105<br />
}}<br />
'''MBB Bo 105''' was a turbine powered [[helicopter]] introduced in the 1970s by Messerschmitt-Bölkow-Blohm also known as PAH-1. It was later produced by Eurocopter. In FlightGear it is included among the [[FlightGear 1.0 default aircraft|default]] [[aircraft]] and is one the more well developed and easier to fly helicopters for versions [[FlightGear 0.9.10|0.9.10]] and [[FlightGear 1.0|1.0]]. It has three selectable liveries that can be changed with Y key, included a military variant with armament that can be fired.<br />
<br />
== Aircraft help ==<br />
{| class="prettytable"<br />
! Key<br />
! Function<br />
|-<br />
| <nowiki>{/}</nowiki><br />
| Shutdown/Start turbines<br />
|- <br />
| d/D<br />
| Select next/previous door<br />
|-<br />
| Ctrl-D<br />
| Open/Close selected door<br />
|-<br />
| i<br />
| Toggle ignition switch<br />
|-<br />
| m/M<br />
| Shift engine balance to right/left engine<br />
|-<br />
| n/N<br />
| Engine power adjustment up/down<br />
|-<br />
| r<br />
| Apply rotor brake<br />
|-<br />
| R<br />
| Toggle rotor brake<br />
|-<br />
| y/Y<br />
| Switch to next/previous variant<br />
|-<br />
| Ctrl-Y<br />
| Open material dialogs<br />
|-<br />
| ,<br />
| Fire machine guns/missiles<br />
|-<br />
| Tab<br />
| Open/Close Bo105 config dialog<br />
|-<br />
| Middle mouse button<br />
| Adjust power lever<br />
|}<br />
<br />
== Nice textures for the interior ==<br />
Horacio has made a very nice new texture for the interior of the Bo 105. Get them here: “[http://www.grafikavirtual.com/fgfs/?sec=aviones.php Versión de prueba del BO-105]”<br />
<br />
[http://www.youtube.com/watch?v=0ASyBX1i4sM Here you can view a video] of the improved heli.<br />
<br />
== Gallery ==<br />
{{Gallery|<br />
Sitting inside the Bo105 on the right side of the cockpit|Bo105 cockpit.jpg|<br />
Bo105 at a heliplatform in the [[FlightGear NL]] scenery|FlightGearNL-9.jpg}}<br />
<br />
== External links ==<br />
* [http://www.fas.org/man/dod-101/sys/ac/row/bo105.htm FAS Bo 105 / PAH-1]<br />
* [http://en.wikipedia.org/wiki/MBB_Bo_105 Wikipedia: Bo 105]<br />
<br />
{{Eurocopter}}<br />
<br />
[[Category:Aircraft]]<br />
[[Category:Helicopters]]</div>Wickinghttps://wiki.flightgear.org/w/index.php?title=Howto:Fly_a_helicopter&diff=35056Howto:Fly a helicopter2011-09-25T10:11:16Z<p>Wicking: /* Getting started */ word removed</p>
<hr />
<div>== Preface ==<br />
'''First:''' in principle everything that applies to real helicopters, applies also to [[FlightGear]]. Fundamental maneuvers are well described on: http://www.cybercom.net/~copters/pilot/maneuvers.html Some details are simplified in FlightGear, in particular the engine handling and some overstresses are not simulated or are without any consequence. In FlightGear it is (up to now) not possible to damage a helicopter in flight.<br />
<br />
[[File:bo105_cockpit.jpg]]<br />
<br />
Since the release of FlightGear 0.9.10, important improvements have been made to the helicopter [[Flight dynamics model|flight model]]. For this reason, version 1.0.0 or later should be used. With these improvements the helicopter flight model of FlightGear should be quite realistic. A notable exception is “vortex ring conditions”. These occur if you descend too fast and perpendicularly (without forward speed). The heli can get into its own rotor downwash causing the lift to be substantially reduced. Recovering from this condition is possible only at higher altitudes. On the internet you can find a video of a SeaKing helicopter which got into this condition during a flight demonstration and touched down so hard afterwards that it was completely destroyed.<br />
<br />
=== Control hardware ===<br />
The parameters for FlightGear helicopters are not completely optimized and thus the performance between model and original may deviate. On the hardware side I recommend the use of a “good” [[joystick]]. A joystick without centering springs is recommended for cyclic control. You can achieve this with a normal joystick by removing or disabling the centering spring(s), or you could use a force feedback joystick with a disconnected voltage supply. Further, the joystick should have a “thrust controller” (throttle). For controlling the tail rotor you should have pedals or at least a twistable joystick; flying helicopters by keyboard is very difficult. ('''hint:''' Flightgear supports more than one joystick attached at the same time.)<br />
<br />
If using a mouse it's recommended to turn off auto-coordination:<br />
* in the [[FlightGear Wizard]] by unchecking the checkbox on the last page.<br />
* through commandline by omitting <tt>--enable-auto-coordination</tt> (which is the default). <br />
<br />
== Getting started ==<br />
The number of available helicopters in FlightGear is increasing rather quick. In my opinion the [[Eurocopter Bo105|Bo105]] is the easiest to fly, since it reacts substantially more directly than other helicopters. As helicopters have become more popular in FlightGear, many others have been developed. Each of them have their unique flight behaviour.<br />
<br />
Once you have loaded FlightGear, take a moment to centralize the controls by moving them around. In particular the collective is often at maximum on startup.<br />
<br />
[[File:s76c_landed.jpg]]<br />
<br />
The helicopter is controlled by four functions. The (joy)stick controls two of them, the inclination of the rotor disc (and thus the inclination of the helicopter) to the right/left and forwards/back. Together these functions are called “cyclic blade control”. Next there is the “collective blade control”, which is controlled by the thrust controller. This causes a change of the thrust produced by the rotor. Since the powering of the main rotor transfers torque (as a twisting or turning force) to the fuselage, this must be compensated by the tail rotor. Since the torque is dependent on the collective and on the flight condition as well as wind can add additional torque on the fuselage, the [[tail rotor]] is also controlled by the pilot using the pedals. If you push the right pedal, the helicopter turns to the right (!). The pedals are not a steering wheel. Using the pedals you can yaw helicopter around the vertical axis. The number of revolutions of the rotor is kept constant (if possible) by the aircraft.<br />
<br />
[[File:ec135_in_the_air.jpg]]<br />
<br />
== Lift-Off ==<br />
First reduce the collective to minimum. To increase the rotor thrust, you have to “pull” the collective. Therefore for minimum collective you have to push the control down (that is the full acceleration position (!) of the thrust controller). Equally, “full power” has the thrust controller at idle. Started the engine with “}”. After few seconds the rotor will start to turn and accelerates slowly. Keep the stick and the pedals approximately centered. Wait until the rotor has finished accelerating. For the Bo105 there is an instruments for engine and rotor speed on the left of the upper row.<br />
<br />
Once rotor acceleration is complete, pull the collective very slowly. Keep your eye on the horizon. If the heli tilts or turns even slightly, stop increasing the collective and correct the position/movement with stick and pedals. If you are successful, continue pulling the collective (slowly!).<br />
<br />
As the helicopter takes off, increase the collective a little bit more and try to keep the helicopter in a leveled position. The main challenge is reacting to the inadvertent rotating motion of the helicopter with the correct control inputs. Only three things can help you: practice, practice and practice. It is quite common for it to take hours of practice to achieve a halfway good looking hovering flight. Note: The stick position in a stable hover is not the center position of the joystick.<br />
<br />
Quick Reference:<br />
# Press } to start the turbines<br />
# Disengage parking or rotor brake. (If applicable)<br />
# Wait for your turbine to come to full speed<br />
# Push the throttle '''Down''', not up. Pushing up makes the chopper go down<br />
# When at desired altitude, push throttle to about 60%<br />
# Fly freely<br />
<br />
== In the air ==<br />
To avoid the continual frustration of trying to achieve level flight, you may want to try forward flight. After take off continue pulling the collective a short time and then lower the nose a slightly using the control stick. The helicopter will accelerate forward. With forward speed the tail rotor does not have to be controlled as precisely due to the relative wind coming from directly ahead. Altogether the flight behavior in forward flight is quite similar to that of an badly trimmed airplane. The “neutral” position of the stick will depend upon airspeed and collective.<br />
<br />
Transitioning from forward flight to hovering is easiest if you reduce speed slowly by raising the nose of the helicopter. At the same time, reduce the collective to stop the helicopter from climbing. As the helicopter slows, “translation lift” is reduced, and you will have to compensate by pulling the collective. When the speed is nearly zero, lower the nose to the position it was when hovering. Otherwise the helicopter will accelerate backwards!<br />
<br />
== Back to Earth I ==<br />
To land the helicopter transition to a hover as described above while reducing the altitude using the collective. Briefly before hitting the ground reduce the rate of descent slowly. A perfect landing is achieved if you managed to zero the altitude, speed and descent rate at the same time (gently). However, such landing are extremely difficult. Most pilots perform a hover more or less near to the ground and then decent slowly to the ground. Landing with forward velocity is easier, however you must make sure you don't land with any lateral (sideways) component to avoid a rollover. <br />
<br />
Quick Reference<br />
# Get to the airport<br />
# Throttle up slowly to about 80%<br />
# Keep it level<br />
# Don't come down too hard<br />
# Land and turn your turbines off (key-{-)<br />
# Have a nice day<br />
<br />
[[File:bo105_landed.jpg]]<br />
<br />
== Back to Earth II ==<br />
It is worth mentioning autorotation briefly. This is an unpowered flight condition, where the flow of air through the rotors rotates the rotor itself. At an appropriate altitude select a landing point (at first in the size of a larger airfield) and then switch the engine off by pressing "{". Reduce collective to minimum, place the tail rotor to approximately 0 degrees incidence (with the Bo push the right pedal about half , with Russian or French helicopters (like the [[Aérospatiale Alouette II|Alouette 2]]) the left). Approach at approximately 80 knots. Don't allow the rotor speed to rise more than a few percent over 100%, otherwise the rotor will be damaged (though this is not currently simulated). As you reach the ground, reduce the airspeed by lifting the nose. The descent rate will drop at the same time, so you do not need to pull the collective. It may be the case that the rotor speed rises beyond the permitted range. Counteract this by raising the collective if required. Just above the ground, reduce the descent rate by pulling the collective. The goal is it to touch down with a very low descent rate and no forward speed. With forward speed it is easier, but there is a danger of a roll over if the skids are not aligned parallel to the flight direction. During the approach it is not necessary to adjust the tail rotor, since without power there is almost no torque. If you feel (after some practice), that autorotation is too easy, try it with a more realistic payload via the payload menu.<br />
<br />
[[File:bo105_auto.jpg]]<br />
<br />
Not all helicopters will autorotate correctly in Flightgear. Here's a list of those which have been tested (missing rating and difficulty indicates lack of capability):<br />
{| class="wikitable sortable" border="1" cellspacing="0" <br />
|-<br />
! style="background:#efefef" | Model<br />
! style="background:#efefef" | Rating<br />
! style="background:#efefef" | Difficulty<br />
! style="background:#efefef" | Notes<br />
|-<br />
| [[AH-1]] || Good || Medium || It is fairly easy to go into an uncontrolled spin.<br />
|-<br />
| [[Bo105]] || Good || Medium ||<br />
|-<br />
| [[EC135]] || ? || Easy ||<br />
|-<br />
| [[Hughes OH-6 Cayuse]] || Good || Medium ||<br />
|-<br />
| [[R22]] || Bad - Fair || High || Poor tail authority. Compensate by increasing collective.<br />
|-<br />
| [[Sikorsky S76C]] || - || - ||<br />
|}<br />
<br />
'''Much fun with the Flightgear helicopters!'''<br />
<br />
== Challenging places to fly ==<br />
Once you have mastered to take off and land safely, you might want to try more challenging places to take your heli. Here are a few suggestions:<br />
* One of the [[aircraft carrier]]s<br />
* An [[oil platform]] in the North Sea<br />
* After all - [http://www.youtube.com/watch?v=j7aHqDkCzCw who needs a helipad?]<br />
<br />
[[Category:Howto|helicopter Fly a]]<br />
<br />
[[de:Fliegen mit dem Helikopter]]<br />
[[es:Volando el helicoptero]]<br />
[[fr:Piloter l'hélicoptère]]<br />
[[nl:Vliegen met de helicopter]]<br />
[[pl:Lot śmigłowcem]]</div>Wicking