fly/fgdata
1
0
Fork 0
Code Activity

Local Weather 1.0 by Thorsten Renk

Browse source
This commit is contained in:
Frederic Bouvier 2011-03-19 14:03:28 +01:00
parent 3d3fa8131e
commit 65c166c12c
20 changed files with 1771 additions and 276 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

141
Docs/README.local_weather.html
View file

@ -7,33 +7,33 @@
<body>
<h1>Local Weather Package - v0.9</h1>
<h1>Local Weather Package - v1.0</h1>
<h2>1. Introduction</h2>
The aim of a local weather system is to simulate weather phenomena tied to specific locations. Examples for this are a thunderstorm, a rainfront or thermal development. In the case of the thunderstorm, severe rain and turbulence occur in a location a few kilometers in scale, i.e. one can easily view it 'from outside' or fly in and out of this region. Similarly, the development of thermal convection clouds is strongly tied to features of the terrain - thermal development does not occur easily over open water or snow, but it is strong over rock or similar surfaces which heat in the sun. Finally, a rainfront is a phenomenon like a thunderstorm that divides the sky into two regions - one with essentially good visibility and clear sky, the other with severe clouds and rain, and both are visible at the same time.<p>
This is in contrast to the current (v.2.0.0) weather system of Flightgear where weather changes affect the weather everywhere in the simulated world and are (with few exceptions) not tied to specific locations. In such a system, it is impossible to observe e.g. the approach of a rainfront while flying in sunshine.<p>
This is in contrast to the current (v.2.0.0) global weather system of Flightgear where weather changes affect the weather everywhere in the simulated world and are (with few exceptions) not tied to specific locations. In such a system, it is impossible to observe e.g. the approach of a rainfront while flying in sunshine.<p>
The local weather package ultimately aims to provide the functionality to simulate such local phenomena. In version 0.9, the package supplies various cloud placement algorithms, as well as local control over most major weather parameters (wind, visibility, pressure, temperature, rain, snow, thermal lift, turbulence...) through interpolation routines and effect volumes. The dynamics of the different systems is tied together - clouds and weather effects drift in the specified wind field. The package also contains a fairly detailed algorithm to generate convective clouds and thermals with a realistic distribution. In addition, there is a simulation of realistic interaction of the convective cloud system with the terrain as a function of time. Clouds drifting in the wind flow over obstacles, i.e. they change their altitude dynamically. Convection is implemented with a life cycle model of clouds - they are generated, evolve for a given lifetime dependent on the underlying terrain and decay at the end of their life cycle. Thermals associated with the clouds follow the same pattern. In particular, in the presence of wind favourable spots for convection generate 'alleys' of dense cloud cover downwind, or thermals and clouds generated over land decay rapidly once they reach open water.<p>
The local weather package aims to provide the functionality to simulate such local phenomena. In version 1.0, the package supplies various cloud placement algorithms, as well as local control over most major weather parameters (wind, visibility, pressure, temperature, rain, snow, thermal lift, turbulence...) through interpolation routines and effect volumes. The dynamics of the different systems is tied together - for instance clouds and weather effects drift in the specified wind field. The package also contains a fairly detailed algorithm to generate convective clouds and thermals with a realistic distribution over the various terrain types. There is a simulation of the interaction of the convective cloud system with the terrain as a function of time. Clouds drifting in the wind flow over obstacles, i.e. they change their altitude dynamically. Convection is implemented with a life cycle model of Cumulus clouds - they are generated, evolve for a given lifetime dependent on the underlying terrain and decay at the end of their life cycle. Thermals associated with the clouds follow the same pattern. In particular, in the presence of wind favourable spots for convection generate 'alleys' of dense cloud cover downwind, or thermals and clouds generated over land decay rapidly once they reach open water.<p>
For long-range flights, the system automatically provides transitions between different weather patterns like fronts and low and high pressure areas. However, basically all features currently present can and will eventually be improved.<p>
For long-range flights, the system provides an offline weather system with plausible transitions between different large-scale weather patterns like fronts and low and high pressure areas, as well as the optional use of live METAR data. <p>
<h2>2. Installation</h2>
The package needs to be unpacked in the Flightgear root directory. It writes content into the <i>Nasal/, gui/, gui/dialogs/, Shaders, Effects/, Docs/</i>, and <i>Models/Weather/</i> subdirectories. The installation does not overwrite any of the default Flightgear files, but to be accessible from the menu, one must copy <i>gui/menubar.xml.alt</i> to the default <i>menubar.xml</i> or copy the last two lines of the environemnt menu calling <i>local_weather</i> and <i>local_weather_tiles</i> into the default file.<p>
The package needs to be unpacked in the Flightgear root directory. It writes content into the <i>Nasal/, gui/, gui/dialogs/, Shaders, Effects/, Docs/</i>, and <i>Models/Weather/</i> subdirectories. The installation does not overwrite any of the default Flightgear files, but to be accessible from the menu for Flightgear 2.0.0, one must copy <i>gui/menubar.xml.alt</i> to the default <i>menubar.xml</i> or copy the three lines of the environemnt menu calling <i>local_weather</i>, <i>local_weather_tiles</i> and <i>local_weather_config</i> into the default file. More recent versions of Flightgear already provide the necessary menu items.<p>
This adds the items <i>Local Weather</i>, <i>Local Weather Tiles</i> and <i>Local Weather Settings</i> to the <i>Environment</i> menu when Flightgear is up. Most of the basic functionality is contained in <i>local_weather.nas</i> which is loaded at startup and identifies itself with a message.<p>
This adds the items <i>Local Weather</i>, <i>Local Weather Tiles</i> and <i>Local Weather Config</i> to the <i>Environment</i> menu when Flightgear is up. Most of the basic functionality is contained in <i>local_weather.nas</i> which is loaded at startup and identifies itself with a message.<p>
Unless asked to do so from the menu, local weather does <b>not</b> run any process in the background. Upon loading, the package does not set any properties already existing, but only generates properties necessary for the menu entries in its own subdirectory <i>/local-weather/</i> in the tree. The package also does a features check on startup if particular functions are available in hard-coded form. If the features are not present, the package will still function properly using slower Nasal fallbacks.<p>
Unless asked to do so from the menu, local weather does <b>not</b> run any process in the background. Upon loading, the package does not set any properties already existing, but only generates properties necessary for the menu entries in its own subdirectory <i>/local-weather/</i> in the tree. The package also does a features check on startup if particular functions are available in hard-coded form. If the features are not present, the package will largely still function properly using slower Nasal fallback code.<p>
<h2>3. Functionality</h2>
The general rule is that the gui is not hardened against problematic user input, for example it will not reject meaningless input like negative windspeeds or unphysical windshear. It is recommended to watch the console, because some level of warnings and errors are passed to the console if the log options is on. Crucial warnings are also printed on-screen.<p>
The general rule is that the gui is not hardened against problematic user input, for example it will not reject meaningless input like negative windspeeds or unphysical windshear. It is recommended to watch the console, because some level of warnings and errors are passed to the console if the log option is on. Crucial warnings are also printed on-screen.<p>
Placement calls may sometimes take a significant time to execute especially for large numbers of clouds tied in a complicated way to the terrain. Placing 500 barrier clouds against a small barrier may take a minute to compute. During this time, a reduced framerate is to be expected<p>
Cloud placement calls may sometimes take a significant time to execute especially for large numbers of clouds tied in a complicated way to the terrain. Placing 500 barrier clouds against a small barrier may take a minute to compute. During this time, a reduced framerate is to be expected<p>
The first menu <b>Local Weather</b> contains the low level cloud placement functions. Its purpose is mainly for developing cloud patterns without having to resort to re-type the underlying Nasal code every time. Currently five options are supported: <i>Place a single cloud</i>, <i>Place a cloud streak</i>, <i>Start the convective system</i>, <i>Create barrier clouds</i> , <i>Place a cloud layer</i> and <i>Make a cloudbox</i>.<p>
@ -43,7 +43,7 @@ The first menu <b>Local Weather</b> contains the low level cloud placement funct
<h3>Single cloud placement</h3>
Single cloud placement is straightforward, it places a (randomly chosen) cloud model of specified type and subtype to a set location. The last parameter, direction of placement, is only relevant for static cloud models (Cirrus) as it sets their orientation, it is overwritten for any rotated cloud models (Altocumulus, Cumulus, Cumulonimbus).<p>
Single cloud placement is straightforward, it places a (randomly chosen) cloud model of specified type and subtype to a set location. The last parameter, direction of placement, is only relevant for static cloud models (Cirrus, Cirrocumulus) as it sets their orientation, it is overwritten for any rotated cloud models (Altocumulus, Cumulus, Cumulonimbus, Stratus, Nimbostratus).<p>
<h3>Streak placement</h3>
@ -55,29 +55,29 @@ The pattern can then be randomized in x, y and altitude. Basically, specifying n
<h3>The convective system</h3>
The convective system places Cumulus clouds centered on the current position based on the underlying terrain. Currently it models daily variation of convective strength and the latitude variation based on a simple sinusoidal model (i.e. it produces different results when called in the morning than at noon), but it does not take into account seasonal variation (i.e. it assumes the date to be the equinox). This will be significantly improved in the future. The actual placement is chosen based on the type of the underlying terrain, with Cumulus development more likely over city areas than on water. Details of the algorithm are described in the appendix. The parameters for this need fine-tuning and are currently rather rough, but they lead for example to pronounced differences between land and sea in coastal regions. The following picture shows the result of a call of the system in the afternoon over TNCM.<p>
The convective system places Cumulus clouds centered on the current position based on the underlying terrain. Currently it models daily variation of convective strength and the latitude variation based on a simple sinusoidal model (i.e. it produces different results when called in the morning than at noon), but it does not take into account seasonal variation (i.e. it assumes the date to be the equinox). The actual placement is chosen based on the type of the underlying terrain, with Cumulus development more likely over city areas than on water. Details of the algorithm are described in the appendix. The parameters for this need some fine-tuning and are currently rather rough, but they lead for example to pronounced differences between land and sea in coastal regions. The following picture shows the result of a call of the system in the afternoon over TNCM.<p>
<center>
<img src="clouds-cumulus_afternoon.jpg">
</center><p>
Unless 'Terrain presampling' is active, clouds are placed in a constant altitude <i>alt</i> in a tile with given <i>size</i> where the size measures the distance to the tile border, i.e. a size parameter of 15 km corresponds to a 30x30 km region. When 'Terrain presampling' is selected, the distribution of clouds in altitude is determined by a more complicated algorithm described in the appendix. Clouds are placed with constant density for given terrain type, so be careful with large area placements! <i>strength</i> is an overall multiplicative factor to fine-tune.
Unless 'Terrain presampling' is active, clouds are placed in a constant altitude <i>alt</i> in a tile with given <i>size</i> where the size measures the distance to the tile border, i.e. a size parameter of 15 km corresponds to a 30x30 km region. When 'Terrain presampling' is selected, the distribution of clouds in altitude is determined by a more complicated algorithm described in the appendix. Clouds are placed with constant density for given terrain type, so be careful with large area placements! <i>strength</i> is an overall multiplicative factor to fine-tune the amount of cloud generation.
<h3>The barrier cloud system</h3>
The barrier cloud system places a cloud at a random point within the region centered around the current position given by <i>size</i> with some probability if there is a terrain barrier downwind with the elevation <i>alt</i> within a distance <i>dist</i> or less. Cloud placement probability is larger for small distances to the barrier. The system tries to place <i>number</i> clouds and assumes that the wind comes from direction <i>wind</i>. If clouds cannot be placed (because there is no barrier within the specified altitude) the algorithm exits with a warning. The picture illustrates the result for the mountains above Geneva.<p>
The barrier cloud system places a cloud at a random point within the region centered around the current position given by <i>size</i> with some probability if there is a terrain barrier downwind with the elevation <i>alt</i> within a distance <i>dist</i> or less. Cloud placement probability is larger for small distances to the barrier. The system tries to place <i>number</i> clouds and assumes that the wind comes from direction <i>wind</i>. If clouds cannot be placed (because there is no barrier within the specified altitude) the algorithm exits with a warning. The picture illustrates the result for the mountains above Las Vegas.<p>
<center>
<img src="barrier.jpg">
</center><p>
Currently, the algorithm does not check for a barrier upstream - this will change in future versions. The ufo is a good way to explore the results of the algorithm by simply flying to a suitable location and calling it there for a relatively small region.
Currently, the algorithm does not check for a barrier upstream - this may change in future versions. The ufo is a good way to explore the results of the algorithm by simply flying to a suitable location and calling it there for a relatively small region. Due to its large performance use, the barrier cloud system is currently not part of the large-scale weather generating system.
<h3>The layer cloud system</h3>
The layer cloud placement is not drastically different from the streak placement in terms of what one can do with it - just its application philosophy is different. It randomly places cloudlets into an ellipsoid region given by the radii <i>rad x</i> and <i>rad y</i> which is rotated by <i>dir</i>, beginning at altitude <i>alt</i> up to thickness <i>thick</i> with a density controlled by <i>density</i>. The parameter <i>edge</i> specifies a boundary region in which smaller clouds are placed less densely. <p>
If <i>rainflag</i> is set to 1, the system will also place external precipitation models (i.e. visible rain layers), roughly at the transition between edge and core of the cloud placement region with a density given by <i>rain dens.</i>. The system will however not place an effect volume which would lead to the actual simulation of rain below the layer - this must be done separately by the user.<p>
If <i>rainflag</i> is set to 1, the system will also place external precipitation models (i.e. visible rain layers), roughly at the transition between edge and core of the cloud placement region with a density given by <i>rain dens</i>. The system will however not place an effect volume which would lead to the actual simulation of rain below the layer - this must be done separately by the user.<p>
The picture illustrates the result of a layer generation call for Nimbostratus clouds with precipitation models. <p>
@ -92,36 +92,38 @@ The cloudbox placement is an experimental routine allowing to define a cloud cor
<h3>Tile placement</h3>
The second menu is used to place complete weather tiles based on low-level calls. It is intended for the user to automatically create the various weather patterns during flight. <p>
The second menu is used to place complete weather patterns based on low-level calls. It is intended for the user to automatically create the various weather development during flight. Unless stated otherwise, all parameters in this menu are parsed at startup time of local weather only (i.e. when the user selects the <i>OK</i> button, but not while the system runs.<p>
<center>
<img src="menu2.jpg">
</center><p>
Weather is created in a series of 40x40 km squares, called tiles. Tiles are classified by airmass, such that the sequence of tiles can describe for example the transition from a high pressure area to a low pressure area. The dropdown menu is used to select the type of weather tile to build initially. <p>
Weather is created in a series of 40x40 km squares, called tiles. Tiles are classified by airmass, such that the sequence of tiles can describe for example the transition from a high pressure area to a low pressure area. The dropdown menu is used to select the type of weather tile to build initially and to determine the rules according to which subsequent tiles are generated. <p>
Below are entries for three parameters. The first two are the simplified version of wind direction and speed for the user who is not interested in specifying many different wind interpolation points.
The third parameter, the altitude offset, is to manually adjust the altitude level of clouds in the absence of terrain presampling. Cloud layer placement calls are then specified for absolute altitudes and calibrated at sea level. As a result, layers are placed too low in mountainous terrain, hence the need for an offset. <p>
Below are entries for three parameters. The first two are the simplified version of wind direction and speed for the user who is not interested in specifying many different wind interpolation points or an altitude structure.
The third parameter, the altitude offset, is to manually adjust the altitude level of clouds in the absence of terrain presampling. Cloud layer placement calls are then specified for absolute altitudes and calibrated at sea level. As a result, layers are placed too low in mountainous terrain, hence the need for an offset. If <i>aloft interpolated</i> or <i>aloft waypoints</i> are chosen as wind models or if tile selection mode is set to <i>METAR</i>, the first two fields are not parsed, if the option <i>terrain presampling</i> is selected the offset is not used.<p>
The three sliders below are used to control gusty winds. They are parsed at runtime and changes do not require a restart of local weather to be effective. The first slider controls how frequent gusts are, the second slider determines the strength relative to the base wind and the third slider their variation in direction. Gusts are, regardless of the wind model, only created in the atmospheric boundary layer close to the terrain surface. The rules for the gust model are described in the appendix in more detail. If the tile selection mode is set to <i>METAR</i>, user-specified values may be overwritten.<p>
The dropdown menu for the wind contains various models for how the windfield is specified which require a different amount of user-specified input. The options are described further down when the windfield modelling is described in more detail.<p>
The dropdown menu for the tile selection mode controls the long-range behaviour of weather. It specifies according to what rules tiles are automatically generated once the aircraft reaches the border of the original tile. The option 'single tile' creates a single weather tile as specified without automatic generation of further tiles. The option 'repeat tile' creates new tiles of the same type as the originally selected tile. This does not mean that weather will be unchanged during flight, as both parameters like pressure, temperature and visibility as well as the positioning of cloud banks are randomized to some degree. In addition, each tile typically contains 2-5 different cloud scenarios, so five repeated generations of 'low-pressure-border' tiles may never result in the same arrangement of cloud layers. Necertheless, the option will keep weather conditions roughly the same. This is different with the (somewhat optimistically named) 'realistic weather'. This option allows transitions between different airmasses, thus one may select 'low-pressure-core' initially, but as the flight goes on, eventually a region of high pressure and clear skies may be reached. Moreover, it does not cover transitions to arctic or tropical weather conditions - those will be covered in a future release. 'repeat tile' does not work for any tile which is part of a front.<p>
The dropdown menu for the tile selection mode controls the long-range behaviour of weather. It specifies according to what rules tiles are automatically generated once the aircraft reaches the border of the original tile. The option <i>single tile</i> creates a single weather tile as specified without automatic generation of further tiles. The option <i>repeat tile</i> creates new tiles of the same type as the originally selected tile. This does not mean that weather will be unchanged during flight, as both parameters like pressure, temperature and visibility as well as the positioning of cloud banks are randomized to some degree. In addition, each tile typically contains typically 6-8 different cloud scenarios, so five repeated generations of <i>low-pressure-border</i> tiles may never result in the same arrangement of cloud layers. Nevertheless, the option will keep weather conditions roughly the same. This is different with the (somewhat optimistically named) <i>realistic weather</i>. This option allows transitions between different airmasses, thus one may select <i>low-pressure-core</i> initially, but as the flight goes on, eventually a region of high pressure and clear skies may be reached. Currently, it does not cover transitions to arctic or tropical weather conditions - those will be covered in a future release. Note also that <i>repeat tile</i> does not work for any tile which is part of a weather front.<p>
The final option, 'METAR', generates weather according to parsed METAR information. This information must be made available in the property tree. Currently this is <b>not</b> done automatically and the METAR system does <b>not</b> work with real-weather-fetch, this needs some work on the Flightgear core. Future versions will be able to use parsed METAR to generate weather tiles.<p>
The final option, <i>METAR</i>, generates weather according to parsed METAR information. This means that user-specified information for tile type and winds is overwritten by live data. The <i>METAR</i> mode is described in more detail below.<p>
Below the menu are six tickboxes. 'Terrain presampling' finds the distribution of altitude in the terrain before placing a cloud layer. As a result, the layers or clouds are automatically placed at the correct altitude above ground in level terrain. In mountain regions, cloud placement is fairly tricky, and the algorithm analyzes quantities like the median altitude to determine what to do. The appendix contains a detailed description of the algorithm. If the box is ticked, the altitude offset specified above is not parsed.<p>
Below the menu are six tickboxes. <i>Terrain presampling</i> finds the distribution of altitude in the terrain before placing a cloud layer. As a result, the layers or clouds are automatically placed at the correct altitude above ground in level terrain. In mountain regions, cloud placement is fairly tricky, and the algorithm analyzes quantities like the median altitude to determine what to do. The appendix contains a detailed description of the algorithm. If the box is ticked, the altitude offset specified above is not parsed.<p>
'generate thermals' is an option intended primarily for soaring. It determines if thermals will be placed whenever a convective clouds is generated. Since managing a large number of thermals costs some amount of resources, it is recommended to generate thermals only if they are needed, i.e. definitely for soaring, possibly for added realism in small aircraft.<p>
<i>generate thermals</i> is an option intended primarily for soaring. It determines if thermals will be placed whenever a convective clouds is generated. Since managing a large number of thermals costs some amount of resources, it is recommended to generate thermals only if they are needed, i.e. definitely for soaring, possibly for added realism in small aircraft.<p>
'debug output' determines if the system writes status messages to the console. Unselecting the option suppresses normal status messages (warnings and errors will still be written). However, in many cases the log of status messages is needed to trace bugs, so if you switch it off and experience a problem, it is likely that the problem cannot be traced.<p>
<i>debug output</i> determines if the system writes status messages to the console. Unselecting the option suppresses normal status messages (warnings and errors will still be written). However, in many cases the log of status messages is needed to trace bugs, so if you switch it off and experience a problem, it is likely that the problem cannot be traced.<p>
'detailed clouds' will change the technique for generating Cumulus clouds from a multilayer model to multiple cloudlets filling a box. This improves the visual appearance of the clouds significantly, albeit at the expense of some loss of framerate. Rendering multiple tiles of dense Cumulus development with detailed clouds will quite possibly slow down even a powerful system. <p>
<i>detailed clouds</i> will change the technique for generating Cumulus clouds from a multilayer model to multiple cloudlets filling a box. This improves the visual appearance of the clouds significantly, albeit at the expense of some loss of framerate. Rendering multiple tiles of dense Cumulus development with detailed clouds will quite possibly slow down even a powerful system. <p>
The option 'dynamical weather' ties all clouds and weather effects to the windfield. If that option is not chosen, the wind is still generated according to the chosen model, but only felt by the aircraft. This makes e.g. soaring unrealistic, as the aircraft continuously drifts out of a static thermal below a static cap cloud. When 'dynamical weather' is selected, aircraft, cloud and thermal are all displaced by the wind and follow elevation changes to some degree.<p>
The option <i>dynamical weather</i> ties all clouds and weather effects to the windfield. If that option is not chosen, the wind is still generated according to the chosen model, but only felt by the aircraft. This makes e.g. soaring unrealistic, as the aircraft continuously drifts out of a static thermal below a static cap cloud. When <i>dynamical weather</i> is selected, aircraft, cloud and thermal are all displaced by the wind and follow elevation changes to some degree.<p>
The final option 'dynamical convection' requires both 'terrain presamling' and 'dynamical weather' to be on (if not, a warning is given and the system aborts). If this option is chosen, all convective clouds and thermals have a life cycle - clouds are continually spawned and decay after a while. This preserves realistic cloud configurations over islands even with wind drift on and improves the realism of the soaring experience as the thermals change over time, but again uses somewhat more performance - switch it on if you need it, for fast planes the visual gain is almost non-existent.<p>
The final option <i>dynamical convection</i> requires both <i>terrain presamling</i> and <i>dynamical weather</i> to be selected (if not, a warning is given and the system aborts). If this option is chosen, all convective clouds and thermals have a life cycle - clouds are continually spawned and decay after a while. This preserves realistic cloud configurations over islands even with wind drift on and improves the realism of the soaring experience as the properties of thermals change over time, but again uses somewhat more performance - switch it on if you need it, for fast planes the visual gain is almost non-existent.<p>
The slider 'Thermal properties' is mainly relevant for soaring scenarios. It governs the rato of maximum lift to radius of a thermal. A setting close to 'low convection' creates large thermals with relatively small lift and virtually no turbulence, a setting close to 'rough day' creates very narrow, turbulent thermals with large lift. However, it also affects the Cumulus textures to be used. 'low convection' creates well-formed, smooth Cumuli whereas 'rough day' biases the texture selection towards more rugged and diffuse clouds.<p>
The slider <i>Thermal properties</i> is mainly relevant for soaring scenarios. It governs the rato of maximum lift to radius of a thermal. A setting close to <i>low convection</i> creates large thermals with relatively small lift and virtually no turbulence, a setting close to <i>rough day</i> creates very narrow, turbulent thermals with large lift. However, it also affects the Cumulus textures to be used. <i>low convection</i> creates well-formed, smooth Cumuli whereas <i>rough day</i> biases the texture selection towards more rugged and diffuse clouds.<p>
The difference is apparent from the following pictures: Smooth and well-formed clouds characteristic of a calm day:<p>
@ -135,17 +137,16 @@ Rough clouds characteristic of windshear and more turbulent conditions:<p>
<img src="detailed_clouds05.jpg">
</center><p>
As for the buttons, 'Ok' starts the local weather system with the selected options (note that all options in this menu are startup-time options, they are read once and changing them without restarting the system will not affect the behaviour of the system). 'Clear/End' clears all clouds and ends all local weather functionality - the button brings the system back into the state before it was started. No loops or other subroutines are executed after the button is pressed. 'Close' closes the dialog without starting the system.<p>
As for the buttons, <i>OK</i> starts the local weather system with the selected options (note that almost all options in this menu are startup-time options, they are read once and changing them without restarting the system will not affect the behaviour of the system). <i>Clear/End</i> clears all clouds and ends all local weather functionality - the button brings the system back into the state before it was started. No loops or other subroutines are executed after the button is pressed. <i>Close</i> closes the dialog without starting the system.<p>
The button 'Show winds' brings up the detailed wind menu which is needed for the wind models 'aloft interpolated' and 'aloft waypoints':<p>
The button <i>Show winds</i> brings up the detailed wind menu which is needed for the wind models <i>aloft interpolated</i> and <i>aloft waypoints</i> when not in <i>METAR</i> mode:<p>
<center>
<img src="menu3.jpg">
</center><p>
For 'aloft interpolated', the menu is used by inserting wind direction and speed for all given altitudes. After 'Okay', the specified values are used. For 'aloft waypoints', the same info must be supplied for a series of waypoints. First, the latitude and longitude has to be inserted, afterwards the aloft winds for that point below. The button 'Set waypoint' commits the windfield as specified in the menu for this position into memory. For orientation, the number of points inserted is counted on the lower right. 'Clear Waypoints' removes all information entered so far. Note that 'Okay' does not commit the data for a waypoint. <p>
For <i>aloft interpolated</i>, the menu is used by inserting wind direction and speed for all given altitudes. After <i>OK</i>, the specified values are used. For <i>aloft waypoints</i>, the same info must be supplied for a series of waypoints. First, the latitude and longitude has to be inserted, afterwards the aloft winds for that point below. The button <i>Set waypoint</i> commits the windfield as specified in the menu for this position into memory. For orientation, the number of points inserted is counted on the lower right. <i>Clear Waypoints</i> removes all information entered so far. Note that <i>OK</i> does not commit the data for a waypoint. Entering a windfield in this way by hand is rather cumbersome, but may be useful occasionally - the main purpose of the wind model however is to work with live weather data.<p>
In principle, the waypoint information inserted so far can be seen using the property browser. It is stored under <i>/local-weather/interpolation/wind[n]/</i>.<p>
@ -184,7 +185,7 @@ All performance setting menu-options work at runtime, but are processed over tim
<h2>4. Cloud models</h2>
The package contains a number of different cloud models, both static ones for Cirrus and Cirrocumulus clouds as well as rotated ones for Altocumulus, Cirrostratus, Cumulus, Cumulonimbus, Stratus and Nimbostratus cloudlet models. Neither the cloud textures, nor the models nor the transformations are perfected, and any aspect can be improved.<p>
The package contains a number of different cloud models, both static ones for Cirrus and Cirrocumulus clouds as well as rotated ones for Altocumulus, Cirrostratus, Cumulus, Cumulonimbus, Stratus and Nimbostratus cloudlet models. Neither the cloud textures, nor the models nor the transformations are perfected, and any aspect can be improved, albeit at the cost of performance consumption.<p>
Static clouds project textures onto curved sheets into the sky. The advantage of the technique is that cloud layers consisting of thousands of cloudlets with different sizes can be modelled. However, the sheets do not look equally well from all perspectives and somewhat unrealistic from close up.<p>
@ -215,17 +216,17 @@ Currently all clouds which need to be rotated are treated in the shaders using a
<h2>5. Local weather parameters</h2>
The local weather package provides three different ways to control the position dependence of weather parameters: 1) by interpolation between stations 2) by constant inside an effect volume and 3) by function inside an effect volume. This in principle allows to represent any 3-dim distribution of a parameter in a tile volume - but the user-input required to actually do that kind of micromanagement is substantial. However, the system is designed to run with good results and minimum user input.<p>
The local weather package provides three different ways to control the position dependence of weather parameters: 1) by interpolation between stations 2) by constant inside an effect volume and 3) by function inside an effect volume. This in principle allows to represent any 3-dim distribution of a parameter in a tile volume - but the user-input required to actually do that kind of micromanagement is substantial. However, the system is designed to run with good results and minimal user input.<p>
The idea is that the interpolation system takes care of slow, large-distance scale changes of weather whereas the effect volume system models rapid, small-scale changes. Thus, the gradual drop in visibility when flying into a more humid air mass is dealt with by the interpolation system whereas the sudden drop in visibility when entering a cloud is modeled as an effect volume. It doesn't make sense to have both systems available for all weather parameters, for example pressure can't change suddenly and discontinuously. Consequently the effect volume system does not support pressure.
<h3>Determining weather parameters by interpolation</h3>
The interpolation system determines the weather parameters outside of special regions, i.e. possibly in the larger part of the tile volume. The weather is specified for an arbitrary number of stations. Each station is characterized by its position (latitude and longitude) and a set of surface weather observations (visibility, pressure, temperature, dew point, rain, snow). In Flight, the interpolation system computes the distance to each station every 3 seconds, computes an average of the parameters weighted by the inverse distance to the station and sets this average as the current weather. This procedure makes the weather exactly as specified whenever the plane is above a station and changes smoothly as the plane is between stations. It may not yield the desired results when the plane is outside a grid of stations.<p>
The interpolation system determines the weather parameters outside of special regions, i.e. possibly in the larger part of the tile volume. The weather is specified for an arbitrary number of stations. Each station is characterized by its position (latitude and longitude) and a set of surface weather observations (visibility, pressure, temperature, dew point, rain, snow). In flight, the interpolation system computes the distance to each station regularly, computes an average of the parameters weighted by the inverse distance to the station and sets this average as the current weather. This procedure makes the weather exactly as specified whenever the plane is above a station and changes smoothly as the plane is between stations. It may not yield the desired results when the plane is outside a grid of stations.<p>
While the station concept is designed to support easy connection with weather updates from real METAR stations, stations do not need to be real stations, and each weather tile creation call by default writes its own station at the center of the tile, so weather tiles can be different and the weather will change smoothly between them.<p>
Technically, the structure of the interpolation system means that while it is running, neither setting weather parameters in the standard menu nor changing visibility using the <i>z</i>-key will have an effect - any setting made there will be overwritten periodically. Only changing the relevant properties (see below) will have the desired effect.<p>
Technically, the structure of the interpolation system means that while it is running, neither setting weather parameters in the GUI menu nor changing visibility using the <i>z</i>-key will have an effect - any setting made there will be overwritten by the interpolation loop periodically, and local weather needs to be stopped before such changes have an effect. <p>
<h3>Weather parameters in effect volumes</h3>
@ -243,9 +244,11 @@ Effect volumes are always specified between a minimum and a maximum altitude, an
<i>create_effect_volume(geometry, lat, lon, r1, r2, phi, alt_low, alt_high, vis, rain, snow, turb, lift, lift_flag, sat);</i><p>
where <i>geometry</i> is a flag (1: circular, 2: elliptical and 3: rectangular), <i>lat</i> and <i>lon</i> are the latitude and longitude, <i>r1</i> and <i>r2</i> are the two size parameters for the elliptic or rectangular shape (for the circular shape, only the first is used), <i>phi</i> is the rotation angle of the shape (not used for circular shape), <i>alt_low</i> and <i>alt_high</i> are the altitude boundaries, <i>vis, rain, snow, turb</i> and <i>lift</i> are weather parameters which are either set to the value they should assume, or to -1 if they are not to be used, or to -2 if a function instead of a parameter is to be used and -3 if a function for wave lift is used. Since thermal lift can be set to negative values in a sink, a separate flag is provided in this case. <i>sat</i> finally determines the light saturation - it can be used to dim the light beneath cloud layers (which is not done automatically as objects don't cast shades in Flightgear, and given that most cloud models are rotated, their shade would look rather odd on any case).<p>
where <i>geometry</i> is a flag (1: circular, 2: elliptical and 3: rectangular), <i>lat</i> and <i>lon</i> are the latitude and longitude, <i>r1</i> and <i>r2</i> are the two size parameters for the elliptic or rectangular shape (for the circular shape, only the first is used), <i>phi</i> is the rotation angle of the shape (not used for circular shape), <i>alt_low</i> and <i>alt_high</i> are the altitude boundaries, <i>vis, rain, snow, turb</i> and <i>lift</i> are weather parameters which are either set to the value they should assume, or to -1 if they are not to be used, or to -2 if a function instead of a parameter is to be used and -3 if a function for wave lift is used. Since thermal lift can be set to negative values in a sink, a separate flag is provided in this case. <i>sat</i> finally determines the light saturation, a parameter between 0 (dark) and 1 (normal light) - it can be used to dim the light beneath cloud layers (which is not done automatically as objects don't cast shades in Flightgear, and given that most cloud models are rotated, their shade would look rather odd on any case).<p>
In version 0.9, thermal lift and wave lift are implemented by function (wave lift is not yet automatically placed, but can be easily from Nasal). There is no easy way to implement any weather parameter by function in an effect volume, as this requires some amount of Nasal coding.
In version 1.0, thermal lift and wave lift are implemented by function (wave lift is not yet automatically placed, but can be easily from Nasal). There is no easy way to implement any weather parameter by function in an effect volume, as this requires some amount of Nasal coding.<p>
Both thermal lift and saturation require a more recent version of Flightgear than 2.0.0 in order to take effect.<p>
<h2>6. Wind models and dynamical weather</h2>
@ -257,7 +260,7 @@ In the horizontal windfield, aloft and bounday layers need to be distinguished.
When the option 'dynamical weather' is active, clouds and effect volumes move with the wind. Due to performance reasons, only clouds in the field of view are processed in each frame. As an efficient way to do this, a quadtree structure is used. However, this has the side effect that all clouds inside a tile need to be moved with the same windspeed (otherwise they would over time drift out of the position where the quadtree expects to find them). Since thermals and their cap clouds should not drift apart, also weather effects are moved with the same windspeed inside each tile. In the following, this is referred to as 'tile wind speed'. The tile wind speed always corresponds to the lowest aloft layer windspeed. The reason why this is considered acceptable is that at the same altitude for different positions inside a tile, the correct windspeed is at most a few kt different from the tile windspeed, and this is impossible to see visually. At high altitudes, the true wind is very different from the speed at which clouds are moved, but without reference and from fast-moving planes, the error is again very hard to see. However, with e.g. a hot air balloon, the fact that at high altitudes clouds are not moved with the high-altitude windspeed would be quite apparent.<p>
Dependent on how detailed the wind field should be specified, what the pilot aims to do and how much user control is desired, there are several options to model the wind.
Dependent on how detailed the wind field should be specified, what the pilot aims to do and how much user control is desired, there are several options to model the wind outside the boundary layer:
<ul>
<li> <b>constant</b> sets the aloft wind to the same speed and direction as specified in the weather tile menu everywhere - at every spatial position and at every altitude. This is for the casual pilot who just wants some simple wind setting, or when it is mandatory that clouds, plane and weather effects all move with the same speed, such as for lighter-than-air aviation. Note that the wind set in the menu is not the wind seen on the runway, as the option sets the aloft wind, from which the boundary layer wind is computed using terrain information.<p>
@ -269,10 +272,38 @@ Dependent on how detailed the wind field should be specified, what the pilot aim
In all cases, the boundary layer is computed separately. Since the boundary layer effect depends on terrain, there is no direct way to set the wind as experienced on the runway (but of course changing the lowest aloft layer will lead to the desired result).
<h2>7. The METAR mode</h2>
The METAR mode allows to use live weather data together with the local weather package, which means that all user-defined weather parameters in the menu will not be parsed if this mode is selected. Some weather parameters (pressure, temperature, dewpoint) are straightforwardly passed on to the interpolation subsystem. For other parameters, the problem is more tricky.<p>
METAR information usually specifies cloud cover and altitude only, but does not mention the type of cloud to be placed. The purpose of the METAR heuristics subroutine is to decide what cloud patterns to place based on the available information. This routine for instance checks if there is an overcast layer above the lowest layer (which makes Cumulus development unlikely) or if the cloud cover is too strong for convective clouds given the time of the day. Once the heuristics has some idea of what the weather pattern indicated in the METAR string looks like, it starts to select cloud types to place into the individual layers. The heuristics is usually good, but certainly not perfect, it may occasionally go wrong and create implausible cloud configurations.<p>
<h2>7. Property tree structure</h2>
The behaviour of winds depends on the selected wind model. In all cases, the wind in a METAR string is assumed to be the wind on the runway, i.e. the lowest aloft wind will be increased relative to the METAR info because the wind on the runway is subject to the boundary layer effect.<p>
<ul>
<li> <b>constant</b> uses the winds of the first METAR everywhere at all times
<li> <b>constant in tile</b> uses the winds of the first METAR in all tiles until the next METAR becomes available, then uses the new value for all tiles till yet another report becomes available. To maintain the internal coordinate system, intermediate tiles may be generated which do not immediately show the new wind
<li> <b>aloft interpolated</b> is not supported by the METAR mode - this makes no sense, as METAR does not report aloft winds
<li> <b>aloft waypoints</b> uses a plausible guess for the aloft winds based on the surface winds. In general, higher aloft winds become stronger and turn somewhat dependent on the Coriolis effect. Based on the interpolation points generated in this way, the windfield at each tile center determines the tile wind direction for the visual cloud movement.
</ul>
The METAR mode currently does not support all types of reported weather. The weather is not changed when the same station makes a different report, only if a new station comes in range. Note that the METAR mode cannot be used for Flightgear 2.0.0!<p>
<h2>8. Program and property tree structure</h2>
The program runs in a number of loops which operate at different timescales - some tasks require attention in every frame, others may wait for a number of seconds. The main loops are:<p>
<ul>
<li><b>Effect volume loop:</b> Determines if the plane is inside an effect volume and executes its action
<li><b>Interpolation loop:</b> Interpolates the weather parameters in space, takes care of the altitude model of the visibility and of the wind boundary layer effects (see Appendix for details)
<li><b>Tile management loop:</b> Controls the generation of new tiles and the removal of old ones.
<li><b>Buffer loop and housekeeping loop:</b> Move clouds out of the buffer into the scenery and back.
<li><b>Quadtree loop:</b> Determines which clouds are inside the field of view and moves them with the tile windspeed.
<li><b>Dynamics loop:</b> Moves effect volumes, tile centers and interpolation points with the windfield, ages convective clouds in their lifecycle.
<li><b>Convective loop:</b> Periodically re-creates convective clouds to compensate for the decaying clouds.
</ul>
All other subroutines are called by one of these loops. <p>
The internal state of the local weather system is found in the property tree under <i>local-weather/</i>. In this directory, various loop flags are found. They indicate the state of the main monitoring loops - they are set to 1 if a loop is running, setting them to zero terminates the loop.<p>
@ -284,9 +315,9 @@ The <i>local-weather/effect-volumes/</i> subfolder contains the management of th
<i>local-weather/tiles</i> stores the information of the 9 managed weather tiles (the one the airplane is currently in, and the 8 surrounding it). By default each directory contains the tile center coordinates and a flag if it has been generated. Tiles are not generated unless a minimum distance to the tile center has been reached. Once this happens, the tile type is written as a code, and the cloud, interpolation and effect volume information corresponding to the tile is generated. <p>
<i>local-weather/METAR</i> is used to store the METAR information for the METAR based tile setup. This must include latitude, longitude and altitude of a weather station, temperature, dewpoint, pressure, wind direction and speed, rain, snow and thunderstorm information as well as cloud layer altitude and coverage in oktas. Any properties set here will be executed when 'METAR' is selected as tile selection mode as long as <i>local-weather/METAR/available-flag</i> is set to 1 (this flag is set to zero whenever a tile has been created from METAR info to indicate that the information has been used, so if the user wants to reuse the information, then the flag must be reset).<p>
<h2>8. Weather tile setup</h2>
<h2>9. Weather tile setup</h2>
Examples for weather tile setup can be found in <i>Nasal/weather-tiles.nas</i>. Each tile is generated by a sequence of Nasal function calls to first set weather stations, then to draw the cloud layers, and effect volumes. It is a bit awkward to have to write in Nasal to customize the system, but I can't think of a reasonable GUI for the task, except marking every placement on a map which exceeds my coding skills a bit. The problem is that there is no real standard solution - every weather tile needs different calls, sometimes a large one generating many clouds, sometimes several smaller ones.<p>
@ -300,7 +331,7 @@ If the cloud layer has an orientation, then all placement coordinates should be
To make your own tile visible, an entry in the menu <i>gui/dialogs/local_weather_tiles.xml</i> needs to be created and the name needs to be added with a tile setup call to the function <i>set_tile</i> in <i>Nasal/local_weather.nas</i>.
<h2>9. Performance tuning</h2>
<h2>10. Performance tuning</h2>
With default settings, the local weather package generates a 40x40 km weather tile when the aircraft is closer than 39 km to the tile center and unloads it when the aircraft is more than 39.5 km away. This means that the system can generate at most 4 tiles at once and clouds are visible for at least 19 km and up to 45 km (the latter number determined by fading in the shaders). However, rendering and managing multiple overcast cloud layers in a region of 80x80 km is a significant drain on performance. For older systems, a few things can be done:<p>
@ -321,29 +352,33 @@ With default settings, the local weather package generates a 40x40 km weather ti
</ul>
<h2>10. Known issues</h2>
<h2>11. Known issues</h2>
<ul>
<li> The local weather system does not mix well with the standard weather system. 3d cloud layers can be placed in the absence of effect volumes, but any effect volume causing precipitation will let the layer behave in a strange way. Likewise, 2d cloud layers can be placed, but may or may not lead to strange rendering artefacts. Local weather, as long as interpolation and effect volumes are running, will in general overwrite all other settings - bother real weather METAR and user-specified settings from the menu. The results of mixing standard and local weather settings are unpredictable, and may not lead to the desired results.<p>
<li> [2.0.0] The local weather system does not mix well with the standard weather system. 3d cloud layers can be placed in the absence of effect volumes, but any effect volume causing precipitation will let the layer behave in a strange way. Likewise, 2d cloud layers can be placed, but may or may not lead to strange rendering artefacts. Local weather, as long as interpolation and effect volumes are running, will in general overwrite all other settings - bother real weather METAR and user-specified settings from the menu. The results of mixing standard and local weather settings are unpredictable, and may not lead to the desired results.<p>
<li> Some cloud textures have artefacts, rain textures have too sharp boundaries and in general some things could look better. Please don't complain, but rather get me good photographs of the sky, cloud texture files or create better AC3D cloud models. I will eventually improve texture quality, but it's not high up in the to-do list, and the cloud model files are openly accessible for anyone with an editor.<p>
<li> Rain and snow may not start properly. For me, rain is only generated when I switch 'Shader effects' on and off in the menu on startup, otherwise neither moving the menu slider nor entering an effect volume generate rain. This seems to be a bug of some Flightgear versions, not of the local weather system.<p>
<li> Especially with multiple overcast layers and weather fronts, loading and unloading weather tiles may take a long time / cause severe drops in framerate. The problem is much worse in GIT than in 2.0.0. Please refer to performance tuning to solve such problems. In general, overcast layers and tropical weather tiles do require a system on the high end of the performance scale to render properly.<p>
<li> Especially with multiple overcast layers and weather fronts, loading and unloading weather tiles may take a long time / cause severe drops in framerate. It seems that a dual core processor is very valuable with this particular issue - try switching multiprocessor support on if needed, otherwise please refer to performance tuning to solve such problems. In general, overcast layers and tropical weather tiles do require a system on the high end of the performance scale to render properly.<p>
<li> The local weather package is able to occasionally trigger errors like 'Warning:: Picked up error in TriangleIntersect'. These seem to be a problem in the core Flightgear code - the package does nothing but placing normal (rather simple) AC3D models into the scenery.<p>
<li> For dynamical weather, clouds sometimes appear to 'jump' to a position. The reason is that the control loop of cloud drift accepts for performance reasons only a limited number of clouds. If there are more in the field of view, the most distant clouds are not processed. As nearby clouds drift out of the visual field, more distant clouds move into the loop, at which point their position is suddenly updated, resulting in a jump. Short of committing potentially vast computational resources (if there is a large number of clouds in the visual field), there is no easy fix to the problem.<p>
<li> To smooth out changes in wind settings, rather than producing a sudden gust, the wind is changed over about 1 second. In sharp wind gradients, this produces a series of ripples like turbulence. This is actually a realistic behaviour in this situation and hence left as it is. Some systems seem to take an unreasonable effort to reinit the environment (as must be done to set wind) - here the function call <i>setWindSmoothly()</i> in <i>local_weather.nas</i> should perhaps be replace by <i>setWind</i> to ease the load.<p>
<li> [2.0.0] To smooth out changes in wind settings, rather than producing a sudden gust, the wind is changed over about 1 second. In sharp wind gradients, this produces a series of ripples like turbulence. This is actually a realistic behaviour in this situation and hence left as it is. Some systems seem to take an unreasonable effort to reinit the environment (as must be done to set wind) - here the function call <i>setWindSmoothly()</i> in <i>local_weather.nas</i> should perhaps be replace by <i>setWind</i> to ease the load.<p>
<li> Large tile creation distances can cause problems in low visibility weather, because Flightgear loads terrain only if it is within visual range. Thus, trying to sample the terrain for a tile 55 km away in 8 km visibility doesn't work because the terrain elevation and altitude is not known. This may cause improper placement of clouds - chiefly convective clouds, but also layered clouds may not appear on the proper altitude. Currently, there is a limit which restricts tile loading range to 3 times the visibility, but presumably a better solution can be found.<p>
<li> Using the 'aloft interpolated' wind option, it is possible to turn the wind direction sharply over a small distance (for example, one may turn the wind by 90 degrees from one tile to the next). Such sharp wind changes are (in most situations) unphysical, and they may cause problems for local weather because they rotate the coordinate system to a degree that the neighbouring tile may not be identified correctly. In essence, the system may not generate new tiles because the nearest tile is still the last generated one. There will be a future fix to address the problem, for the moment just avoid rotating the wind strongly.<p>
<li> Using the 'aloft interpolated' wind option, it is possible to turn the wind direction sharply over a small distance (for example, one may turn the wind by 90 degrees from one tile to the next). Such sharp wind changes are (in most situations) unphysical, and they may cause problems for local weather because they rotate the coordinate system to a degree that the neighbouring tile may not be identified correctly. In essence, the system may not generate new tiles because the nearest tile is still the last generated one. The system largely tries to detect the problem and compensate, but occasionally this may be an issue.<p>
<li> The thermals in the soaring scenarios need GIT to work.<p>
<li> [2.0.0] The thermals in the soaring scenarios need GIT to work.<p>
<li> [2.0.0] No support for live weather data.<p>
<li> [2.0.0] No change of light saturation. <p>
</ul>
<h2><a name="appendix_A">Appendix A: An introduction to the algorithms</a></h2>
@ -492,14 +527,20 @@ The boundary layer effectiveness, i.e. the amount of windspeed reduction at the
Realistically, the boundary layer should also depend on terrain coverage. Due to the need for performance to sample terrain coverage in the vicinity of the aircraft frequently, this is currently not implemented.<p>
Gusty winds are assumed to be a bounday layer phenomenon and faded out to zero at a multiple of the boundary layer thickness which is given by <i>base wind speed [kt]/10</i>, i.e. for 25 kt winds the gusts are absent for 2.5 times the bounday layer thickness.<p>
<h3>The altitude model of visibility</h3>
Relatively low visibility (as reported by METAR) is usually confined to low altitudes, due to the lower density of the upper atmosphere and the reduced level of dust and water the visibility at airliner cruise altitude is frequently in excess of 100 km. This means that an altitude model of the visibility is needed.<p>
Local weather assumes that haze and dust are confined to the lowest air layer. As a proxy for the transition to a higher layer, the altitude of the lowest cloud layer (or for 9000 ft for clear skies) is used. The visibility always increases with altitude, but below the first layer transition it increases slowly at a rate of 0.2 m / ft in altitude gain. During the layer transition where the transition occurs during 1500 ft, the visibility increases rather rapidly at a rate of 5 m / ft, which means that above the lowest air layer the visibility is almost 10 km more than on the ground. The visibility then continues to grow at a rate of 1 m / ft towards the Stratosphere. In all likelihood, this dramatically underestimates the true visibility at high altitudes, but has been chosen to limit the impact on performance.<p>
<h2>Credits</h2>
The model of a thermal has been developed by Patrice Poly. The shader code used to transform clouds is heavily based on prior work by Stuart Buchanan. Hard-coding of some features by Torsten Dreyer is greatly appreciated.<p>
Thorsten Renk, October 2010
Thorsten Renk, March 2011
</body>

BIN
Docs/barrier.jpg
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 66 KiB

After

Width:  |  Height:  |  Size: 94 KiB

BIN
Docs/cloud_altitude_01.jpg
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 61 KiB

After

Width:  |  Height:  |  Size: 83 KiB

BIN
Docs/cloud_altitude_02.jpg
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 79 KiB

After

Width:  |  Height:  |  Size: 74 KiB

BIN
Docs/cloud_altitude_03.jpg
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 65 KiB

After

Width:  |  Height:  |  Size: 84 KiB

BIN
Docs/clouds-cumulus_afternoon.jpg
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 34 KiB

BIN
Docs/high_pressure_border.jpg
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 56 KiB

After

Width:  |  Height:  |  Size: 71 KiB

BIN
Docs/menu2.jpg
View file

Binary file not shown.
Side by side Swipe Overlay

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 28 KiB

72
Effects/clouds-box.eff Normal file
View file

@ -0,0 +1,72 @@
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<name>Effects/clouds-thin</name>
<parameters>
<texture n ="0">
</texture>
</parameters>
<technique n="10">
<predicate>
<and>
<property>/sim/rendering/shader-effects</property>
<less-equal>
<value type="float">1.0</value>
<shader-language/>
</less-equal>
</and>
</predicate>
<pass n="0">
<!-- This is apparently not used, so maybe we'll blow it way soon. -->
<lighting>true</lighting>
<material>
<ambient type="vec4d">0.5 0.5 0.5 1.0</ambient>
<diffuse type="vec4d">0.5 0.5 0.5 1.0</diffuse>
<color-mode>off</color-mode>
</material>
<alpha-test>
<comparison>greater</comparison>
<reference type="float">0.01</reference>
</alpha-test>
<shade-model>smooth</shade-model>
<blend>
<source>src-alpha</source>
<destination>one-minus-src-alpha</destination>
</blend>
<depth>
<write-mask>false</write-mask>
</depth>
<render-bin>
<bin-number>10</bin-number>
<bin-name>DepthSortedBin</bin-name>
</render-bin>
<texture-unit>
<unit>0</unit>
<type><use>texture[0]/type</use></type>
<image><use>texture[0]/image</use></image>
<filter><use>texture[0]/filter</use></filter>
<wrap-s><use>texture[0]/wrap-s</use></wrap-s>
<wrap-t><use>texture[0]/wrap-t</use></wrap-t>
<!--<wrap-s>clamp</wrap-s>
<wrap-t>clamp</wrap-t>-->
</texture-unit>
<program>
<vertex-shader>Shaders/clouds-box.vert</vertex-shader>
<fragment-shader>Shaders/clouds-box.frag</fragment-shader>
<!--<attribute>
<name>usrAttr3</name>
<index>10</index>
</attribute>
<attribute>
<name>usrAttr4</name>
<index>11</index>
</attribute>-->
</program>
<uniform>
<name>baseTexture</name>
<type>sampler-2d</type>
<value type="int">0</value>
</uniform>
<vertex-program-two-side>true</vertex-program-two-side>
</pass>
</technique>
</PropertyList>

64
Effects/rain-layer.eff Normal file
View file

@ -0,0 +1,64 @@
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<name>Effects/rain-layer</name>
<parameters>
<texture n ="0">
</texture>
</parameters>
<technique n="10">
<predicate>
<and>
<property>/sim/rendering/shader-effects</property>
<less-equal>
<value type="float">1.0</value>
<shader-language/>
</less-equal>
</and>
</predicate>
<pass n="0">
<!-- This is apparently not used, so maybe we'll blow it way soon. -->
<lighting>true</lighting>
<material>
<ambient type="vec4d">0.5 0.5 0.5 1.0</ambient>
<diffuse type="vec4d">0.5 0.5 0.5 1.0</diffuse>
<color-mode>off</color-mode>
</material>
<alpha-test>
<comparison>greater</comparison>
<reference type="float">0.01</reference>
</alpha-test>
<shade-model>smooth</shade-model>
<blend>
<source>src-alpha</source>
<destination>one-minus-src-alpha</destination>
</blend>
<depth>
<write-mask>false</write-mask>
</depth>
<render-bin>
<bin-number>10</bin-number>
<bin-name>DepthSortedBin</bin-name>
</render-bin>
<texture-unit>
<unit>0</unit>
<type><use>texture[0]/type</use></type>
<image><use>texture[0]/image</use></image>
<filter><use>texture[0]/filter</use></filter>
<wrap-s><use>texture[0]/wrap-s</use></wrap-s>
<wrap-t><use>texture[0]/wrap-t</use></wrap-t>
<!--<wrap-s>clamp</wrap-s>
<wrap-t>clamp</wrap-t>-->
</texture-unit>
<program>
<vertex-shader>Shaders/rain-layer.vert</vertex-shader>
<fragment-shader>Shaders/rain-layer.frag</fragment-shader>
</program>
<uniform>
<name>baseTexture</name>
<type>sampler-2d</type>
<value type="int">0</value>
</uniform>
<vertex-program-two-side>true</vertex-program-two-side>
</pass>
</technique>
</PropertyList>

56
Nasal/compat_layer.nas
View file

@ -1,11 +1,12 @@
########################################################
# compatibility layer for local weather package
# Thorsten Renk, July 2010
# Thorsten Renk, March 2011
########################################################
# function purpose
#
# setDefaultCloudsOff to remove the standard Flightgear 3d clouds
# setVisibility to set the visibility to a given value
# setLift to set lift to given value
# setRain to set rain to a given value
@ -97,6 +98,29 @@ print("Compatibility layer: tests done.");
var setDefaultCloudsOff = func {
if (features.can_disable_environment == 1)
{
var layers = props.globals.getNode("/environment/clouds").getChildren("layer");
foreach (l; layers)
{
l.getNode("coverage-type").setValue(5);
}
}
else
{
var layers = props.globals.getNode("/environment/clouds").getChildren("layer");
foreach (l; layers)
{
l.getNode("coverage").setValue("clear");
}
}
}
####################################
# set visibility to given value
@ -144,11 +168,18 @@ if (features.can_disable_environment == 1)
var setRain = func (rain) {
# setting the lowest cloud layer to 30.000 ft is a workaround
# as rain is only created below that layer in default
if (features.can_disable_environment == 1)
{
setprop("/environment/rain-norm", rain);
}
else
{
# setting the lowest cloud layer to 30.000 ft is a workaround
# as rain is only created below that layer in default
setprop("environment/clouds/layer[0]/elevation-ft", 30000.0);
setprop("environment/metar/rain-norm",rain);
setprop("/environment/clouds/layer[0]/elevation-ft", 30000.0);
setprop("/environment/metar/rain-norm",rain);
}
}
@ -158,11 +189,18 @@ setprop("environment/metar/rain-norm",rain);
var setSnow = func (snow) {
# setting the lowest cloud layer to 30.000 ft is a workaround
# as snow is only created below that layer in default
if (features.can_disable_environment == 1)
{
setprop("/environment/snow-norm", snow);
}
else
{
# setting the lowest cloud layer to 30.000 ft is a workaround
# as snow is only created below that layer in default
setprop("environment/clouds/layer[0]/elevation-ft", 30000.0);
setprop("environment/metar/snow-norm",snow);
setprop("environment/clouds/layer[0]/elevation-ft", 30000.0);
setprop("environment/metar/snow-norm",snow);
}
}

472
Nasal/local_weather.nas
View file

@ -1,7 +1,7 @@
########################################################
# routines to set up, transform and manage local weather
# Thorsten Renk, October 2010
# Thorsten Renk, March 2011
# thermal model by Patrice Poly, April 2010
########################################################
@ -41,6 +41,7 @@
# cumulus_exclusion_layer to create a layer with 'holes' left for thunderstorm placement
# create_rise_clouds to create a barrier cloud system
# create_streak to create a cloud streak
# create_undulatus to create an undulating cloud pattern
# create_layer to create a cloud layer with optional precipitation
# create_hollow_layer to create a cloud layer in a hollow cylinder (better for performance)
# create_cloudbox to create a sophisticated cumulus cloud with different textures (experimental)
@ -56,6 +57,7 @@
# create_effect_volume to create an effect volume
# set_weather_station to specify a weather station for interpolation
# set_wind_ipoint to set an aloft wind interpolation point
# set_wind_ipoint_metar to set a wind interpolation point from available ground METAR info where aloft is modelled
# showDialog to pop up a dialog window
# readFlags to read configuration flags from the property tree into Nasal variables at startup
# streak_wrapper wrapper to execute streak from menu
@ -72,6 +74,7 @@
# object purpose
# weatherStation to store info about weather conditions
# windIpoint to store an interpolation point of the windfield
# effectVolume to store effect volume info and provide methods to move and time-evolve effect volumes
# thermalLift to store thermal info and provide methods to move and time-evolve a thermal
# waveLift to store wave info
@ -285,20 +288,26 @@ var wind_altitude_interpolation = func (altitude, w) {
if (altitude < wind_altitude_array[0]) {var alt_wind = wind_altitude_array[0];}
else if (altitude > wind_altitude_array[8]) {var alt_wind = 0.99* wind_altitude_array[8];}
else {alt_wind = altitude;}
else {var alt_wind = altitude;}
for (var i = 0; i<9; i=i+1)
{if (alt_wind < wind_altitude_array[i]) {break;}}
var altNodeMin = w.getChild("altitude",i-1);
var altNodeMax = w.getChild("altitude",i);
#var altNodeMin = w.getChild("altitude",i-1);
#var altNodeMax = w.getChild("altitude",i);
var vmin = altNodeMin.getNode("windspeed-kt").getValue();
var vmax = altNodeMax.getNode("windspeed-kt").getValue();
#var vmin = altNodeMin.getNode("windspeed-kt").getValue();
#var vmax = altNodeMax.getNode("windspeed-kt").getValue();
var dir_min = altNodeMin.getNode("wind-from-heading-deg").getValue();
var dir_max = altNodeMax.getNode("wind-from-heading-deg").getValue();
var vmin = w.alt[i-1].v;
var vmax = w.alt[i].v;
#var dir_min = altNodeMin.getNode("wind-from-heading-deg").getValue();
#var dir_max = altNodeMax.getNode("wind-from-heading-deg").getValue();
var dir_min = w.alt[i-1].d;
var dir_max = w.alt[i].d;
var f = (alt_wind - wind_altitude_array[i-1])/(wind_altitude_array[i] - wind_altitude_array[i-1]);
@ -307,20 +316,28 @@ var res = add_vectors(dir_min, (1-f) * vmin, dir_max, f * vmax);
return res;
}
###################################
# windfield spatial interpolation
###################################
var wind_interpolation = func (lat, lon, alt) {
var windNodes = props.globals.getNode(lw~"interpolation").getChildren("wind");
# var windNodes = props.globals.getNode(lw~"interpolation").getChildren("wind");
var sum_norm = 0;
var sum_wind = [0,0];
var wsize = size(windIpointArray);
foreach (var w; windNodes) {
for (var i = 0; i < wsize; i=i+1) {
var wlat = w.getNode("latitude-deg").getValue();
var wlon = w.getNode("longitude-deg").getValue();
#var wlat = w.getNode("latitude-deg").getValue();
#var wlon = w.getNode("longitude-deg").getValue();
var w = windIpointArray[i];
var wpos = geo.Coord.new();
wpos.set_latlon(wlat,wlon,1000.0);
wpos.set_latlon(w.lat,w.lon,1000.0);
var ppos = geo.Coord.new();
ppos.set_latlon(lat,lon,1000.0);
@ -328,10 +345,16 @@ foreach (var w; windNodes) {
var d = ppos.distance_to(wpos);
if (d <100.0) {d = 100.0;} # to prevent singularity at zero
sum_norm = sum_norm + 1./d;
sum_norm = sum_norm + (1./d) * w.weight;
var res = wind_altitude_interpolation(alt,w);
sum_wind = add_vectors(sum_wind[0], sum_wind[1], res[0], res[1]/d);
sum_wind = add_vectors(sum_wind[0], sum_wind[1], res[0], (res[1]/d) * w.weight);
# gradually fade in the interpolation weight of newly added points to
# avoid sudden jumps
if (w.weight < 1.0) {w.weight = w.weight + 0.02;}
}
@ -397,12 +420,30 @@ var iNode = props.globals.getNode(lw~"interpolation", 1);
var cNode = props.globals.getNode(lw~"current", 1);
var viewpos = geo.aircraft_position();
var sum_alt = 0.0;
var sum_vis = 0.0;
var sum_T = 0.0;
var sum_p = 0.0;
var sum_D = 0.0;
var sum_norm = 0.0;
var vis_before = getprop(lwi~"visibility-m");
# determine at which distance we no longer keep an interpolation point, needs to be larger for METAR since points are more scarce
if (metar_flag == 1)
{var distance_to_unload = 250000.0;}
else
{var distance_to_unload = 120000.0;}
# if we can set environment without a reset, the loop can run a bit faster for smoother interpolation
# so determine the suitable timing
if (compat_layer.features.can_disable_environment == 1)
{var interpolation_loop_time = 0.2; var vlimit = 1.01;}
else
{var interpolation_loop_time = 1.0; var vlimit = 1.05;}
# get an inverse distance weighted average from all defined weather stations
@ -422,7 +463,7 @@ for (var i = 0; i < n_stations; i=i+1) {
sum_norm = sum_norm + 1./d * s.weight;
sum_alt = sum_alt + (s.alt/d) * s.weight;
sum_vis = sum_vis + (s.vis/d) * s.weight;
sum_T = sum_T + (s.T/d) * s.weight;
sum_D = sum_D + (s.D/d) * s.weight;
@ -431,12 +472,12 @@ for (var i = 0; i < n_stations; i=i+1) {
# gradually fade in the interpolation weight of newly added stations to
# avoid sudden jumps
if (s.weight < 1.0) {s.weight = s.weight + 0.1;}
if (s.weight < 1.0) {s.weight = s.weight + 0.02;}
# automatically delete stations out of range
# take care not to unload if weird values appear for a moment
# never unload if only one station left
if ((d > 120000.0) and (d<140000.0) and (n_stations > 1))
if ((d > distance_to_unload) and (d < (distance_to_unload + 20000.0)) and (n_stations > 1))
{
if (debug_output_flag == 1)
{print("Distance to weather station ", d, " m, unloading ...", i);}
@ -448,24 +489,62 @@ for (var i = 0; i < n_stations; i=i+1) {
setprop(lwi~"station-number", i);
var ialt = sum_alt/sum_norm;
var vis = sum_vis/sum_norm;
var p = sum_p/sum_norm;
var D = sum_D/sum_norm;
var T = sum_T/sum_norm;
# a simple altitude model for visibility - increase it with increasing altitude
# altitude model for visibility - increase above the lowest inversion layer to simulate ground haze
var altitude = getprop("position/altitude-ft");
vis = vis + 0.5 * altitude;
var current_tile_index = getprop(lw~"tiles/tile[4]/tile-index");
if (vis > 0.0) {iNode.getNode("visibility-m",1).setValue(vis);} # a redundancy check
iNode.getNode("temperature-degc",1).setValue(T);
iNode.getNode("dewpoint-degc",1).setValue(D);
if (p>0.0) {iNode.getNode("pressure-sea-level-inhg",1).setValue(p);} # a redundancy check
iNode.getNode("turbulence",1).setValue(0.0);
#if (presampling_flag == 1)
# {var current_mean_terrain_elevation = alt_20_array[current_tile_index -1];}
#else
# {var current_mean_terrain_elevation = getprop(lw~"tmp/tile-alt-offset-ft");}
current_mean_terrain_elevation = ialt;
var alt1 = weather_dynamics.tile_convective_altitude[current_tile_index -1];
var alt2 = alt1 + 1500.0;
var inc1 = 0.2;
var inc2 = 5.0;
var inc3 = 1.0;
var alt_above_mean = altitude - current_mean_terrain_elevation;
if (alt_above_mean < alt1)
{vis = vis + inc1 * alt_above_mean;}
else if (alt_above_mean < alt2)
{vis = vis + inc1 * alt1 + inc2 * (alt_above_mean - alt1);}
else if (alt_above_mean > alt2)
{vis = vis + inc1 * alt1 + inc2 * (alt2-alt1) + inc3 * (alt_above_mean - alt2);}
# limit relative changes of the visibility, will make for gradual transitions
if (vis/vis_before > vlimit)
{vis = vlimit * vis_before;}
else if (vis/vis_before < (2.0-vlimit))
{vis = (2.0-vlimit) * vis_before;}
# write all properties into the weather interpolation record in the property tree
setprop(lwi~"mean-terrain-altitude-ft",ialt);
if (vis > 0.0) {setprop(lwi~"visibility-m",vis);} # a redundancy check
setprop(lwi~"temperature-degc",T);
setprop(lwi~"dewpoint-degc",D);
if (p > 10.0) {setprop(lwi~"pressure-sea-level-inhg",p);}
setprop(lwi~"turbulence",0.0);
# now check if an effect volume writes the property and set only if not
@ -517,15 +596,15 @@ else if (wind_model_flag ==2) # constant in tile
}
else if (wind_model_flag ==3) # aloft interpolated, constant in tiles
{
var w = props.globals.getNode(lw~"interpolation").getChild("wind",0);
var w = windIpointArray[0];
var res = wind_altitude_interpolation(altitude,w);
var winddir = res[0];
var windspeed = res[1];
}
else if (wind_model_flag == 5) # aloft waypoint interpolated
{
var res = wind_interpolation(viewpos.lat(), viewpos.lon(), viewpos.alt());
var res = wind_interpolation(viewpos.lat(), viewpos.lon(), altitude);
var winddir = res[0];
var windspeed = res[1];
}
@ -540,6 +619,8 @@ if (presampling_flag == 0)
{
var boundary_alt = 600.0;
var windspeed_ground = windspeed/3.0;
var f_min = 2.0/3.0;
if (altitude_agl < boundary_alt)
{var windspeed_current = windspeed_ground + 2.0 * windspeed_ground * (altitude_agl/boundary_alt);}
@ -577,6 +658,37 @@ else
}
# determine gusts and turbulence in the bounday layer
var gust_frequency = getprop(lw~"tmp/gust-frequency-hz");
if (gust_frequency > 0.0)
{
var gust_relative_strength = getprop(lw~"tmp/gust-relative-strength");
var gust_angvar = getprop(lw~"tmp/gust-angular-variation-deg");
var alt_scaling_factor = 1.2 * windspeed / 10.0;
if (alt_scaling_factor < 1.0) {alt_scaling_factor = 1.0;}
# expected mean number of gusts in time interval (should be < 1)
var p_gust = gust_frequency * interpolation_loop_time;
if (rand() < p_gust) # we change the offsets for windspeed and direction
{
var alt_fact = 1.0 - altitude_agl/(boundary_alt * alt_scaling_factor);
if (alt_fact < 0.0) {alt_fact = 0.0};
windspeed_multiplier = (1.0 + ((rand()) * gust_relative_strength * alt_fact));
winddir_change = alt_fact * (1.0 - 2.0 * rand() * gust_angvar);
}
windspeed_current = windspeed_current * windspeed_multiplier;
winddir = winddir + winddir_change;
}
compat_layer.setWindSmoothly(winddir, windspeed_current);
@ -588,7 +700,9 @@ cNode.getNode("wind-from-heading-deg").setValue(winddir);
cNode.getNode("wind-speed-kt").setValue(windspeed_current);
if (getprop(lw~"interpolation-loop-flag") ==1) {settimer(interpolation_loop, 1.0);}
if (getprop(lw~"interpolation-loop-flag") ==1) {settimer(interpolation_loop, interpolation_loop_time);}
}
@ -1572,10 +1686,11 @@ setprop(lw~"convective-loop-flag",0);
weather_dynamics.convective_loop_kill_flag = 1; # long-running loop needs a different scheme to end
# also remove rain and snow effects
# also remove rain snow and saturation effects
compat_layer.setRain(0.0);
compat_layer.setSnow(0.0);
compat_layer.setLight(1.0);
# set placement indices to zero
@ -1592,6 +1707,10 @@ settimer ( func { setsize(weather_dynamics.cloudQuadtrees,0);},0.1); # to avoid
setsize(effectVolumeArray,0);
n_effectVolumeArray = 0;
# if we have used METAR, we may no longer want to do so
metar_flag = 0;
settimer ( func {
setsize(weather_tile_management.modelArrays,0);
@ -1604,15 +1723,20 @@ settimer ( func {
setsize(weather_dynamics.tile_convective_altitude,0);
setsize(weather_dynamics.tile_convective_strength,0);
setsize(weatherStationArray,0);
setsize(windIpointArray,0);
setprop(lw~"clouds/buffer-count",0);
setprop(lw~"clouds/cloud-scenery-count",0);
weather_tile_management.n_cloudSceneryArray = 0;
props.globals.getNode("local-weather/interpolation", 1).removeChildren("wind");
#props.globals.getNode("local-weather/interpolation", 1).removeChildren("wind");
setprop(lwi~"ipoint-number",0);
},1.1);
setprop(lw~"tmp/presampling-status", "idle");
# indicate that we are no longer running
local_weather_running_flag = 0;
}
@ -2246,6 +2370,76 @@ for (var i=0; i<ny; i=i+1)
}
###########################################################
# place an undulatus pattern
###########################################################
var create_undulatus = func (type, blat, blong, balt, alt_var, nx, xoffset, edgex, x_var, ny, yoffset, edgey, y_var, und_strength, direction, tri) {
var flag = 0;
var path = "Models/Weather/blank.ac";
calc_geo(blat);
var dir = direction * math.pi/180.0;
var ymin = -0.5 * ny * yoffset;
var xmin = -0.5 * nx * xoffset;
var xinc = xoffset * (tri-1.0) /ny;
var jlow = int(nx*edgex);
var ilow = int(ny*edgey);
var und = 0.0;
var und_array = [];
for (var i=0; i<ny; i=i+1)
{
und = und + 2.0 * (rand() -0.5) * und_strength;
append(und_array,und);
}
for (var i=0; i<ny; i=i+1)
{
var y = ymin + i * yoffset;
for (var j=0; j<nx; j=j+1)
{
var y0 = y + y_var * 2.0 * (rand() -0.5);
var x = xmin + j * (xoffset + i * xinc) + x_var * 2.0 * (rand() -0.5) + und_array[i];
var lat = blat + m_to_lat * (y0 * math.cos(dir) - x * math.sin(dir));
var long = blong + m_to_lon * (x * math.cos(dir) + y0 * math.sin(dir));
var alt = balt + alt_var * 2 * (rand() - 0.5);
flag = 0;
var rn = 6.0 * rand();
if (((j<jlow) or (j>(nx-jlow-1))) and ((i<ilow) or (i>(ny-ilow-1)))) # select a small or no cloud
{
if (rn > 2.0) {flag = 1;} else {path = select_cloud_model(type,"small");}
}
if ((j<jlow) or (j>(nx-jlow-1)) or (i<ilow) or (i>(ny-ilow-1)))
{
if (rn > 5.0) {flag = 1;} else {path = select_cloud_model(type,"small");}
}
else { # select a large cloud
if (rn > 5.0) {flag = 1;} else {path = select_cloud_model(type,"large");}
}
if (flag==0){
if (thread_flag == 1)
{create_cloud_vec(path, lat, long, alt, 0.0);}
else
{compat_layer.create_cloud(path, lat, long, alt, 0.0);}
}
}
}
}
###########################################################
# place a cloud layer
@ -2876,11 +3070,11 @@ append(effectVolumeArray,ev);
# set a weather station for interpolation
###########################################################
var set_weather_station = func (lat, lon, vis, T, D, p) {
var set_weather_station = func (lat, lon, alt, vis, T, D, p) {
var s = weatherStation.new (lat, lon, vis, T, D, p);
var s = weatherStation.new (lat, lon, alt, vis, T, D, p);
s.index = getprop(lw~"tiles/tile-counter");
s.weight = 0.1;
s.weight = 0.02;
# set a timestamp if needed
@ -2899,42 +3093,56 @@ append(weatherStationArray,s);
var set_wind_ipoint = func (lat, lon, d0, v0, d1, v1, d2, v2, d3, v3, d4, v4, d5, v5, d6, v6, d7, v7, d8, v8) {
var n = props.globals.getNode(lwi, 1);
for (var i = 0; 1; i += 1)
if (n.getChild("wind", i, 0) == nil)
break;
var w = windIpoint.new(lat, lon, d0, v0, d1, v1, d2, v2, d3, v3, d4, v4, d5, v5, d6, v6, d7, v7, d8, v8);
s = n.getChild("wind", i, 1);
append(windIpointArray, w);
s.getNode("latitude-deg",1).setValue(lat);
s.getNode("longitude-deg",1).setValue(lon);
s.getChild("altitude",0,1).getNode("wind-from-heading-deg",1).setValue(d0);
s.getChild("altitude",0,1).getNode("windspeed-kt",1).setValue(v0);
}
s.getChild("altitude",1,1).getNode("wind-from-heading-deg",1).setValue(d1);
s.getChild("altitude",1,1).getNode("windspeed-kt",1).setValue(v1);
s.getChild("altitude",2,1).getNode("wind-from-heading-deg",1).setValue(d2);
s.getChild("altitude",2,1).getNode("windspeed-kt",1).setValue(v2);
###########################################################
# set a wind interpolation point from ground METAR data
###########################################################
s.getChild("altitude",3,1).getNode("wind-from-heading-deg",1).setValue(d3);
s.getChild("altitude",3,1).getNode("windspeed-kt",1).setValue(v3);
var set_wind_ipoint_metar = func (lat, lon, d0, v0) {
s.getChild("altitude",4,1).getNode("wind-from-heading-deg",1).setValue(d4);
s.getChild("altitude",4,1).getNode("windspeed-kt",1).setValue(v4);
# insert a plausible pattern of aloft winds based on ground info
s.getChild("altitude",5,1).getNode("wind-from-heading-deg",1).setValue(d5);
s.getChild("altitude",5,1).getNode("windspeed-kt",1).setValue(v5);
s.getChild("altitude",6,1).getNode("wind-from-heading-deg",1).setValue(d6);
s.getChild("altitude",6,1).getNode("windspeed-kt",1).setValue(v6);
# direction of Coriolis deflection depends on hemisphere
if (lat >0.0) {var dsign = -1.0;} else {var dsign = 1.0;}
var v1 = v0 * (1.0 + rand() * 0.2);
var d1 = d0 + dsign * 3.0 * rand();
var v2 = v0 * (1.2 + rand() * 0.2);
var d2 = d0 + dsign * (3.0 * rand() + 2.0);
var v3 = v0 * (1.3 + rand() * 0.4) + 5.0;
var d3 = d0 + dsign * (3.0 * rand() + dsign * 4.0);
var v4 = v0 * (1.7 + rand() * 0.5) + 10.0;
var d4 = d0 + dsign * (4.0 * rand() + dsign * 8.0);
var v5 = v0 * (1.7 + rand() * 0.5) + 20.0;
var d5 = d0 + dsign * (4.0 * rand() + dsign * 10.0);
var v6 = v0 * (1.7 + rand() * 0.5) + 40.0;
var d6 = d0 + dsign * (4.0 * rand() + dsign * 12.0);
var v7 = v0 * (2.0 + rand() * 0.7) + 50.0;
var d7 = d0 + dsign * (4.0 * rand() + dsign * 13.0);
var v8 = v0 * (2.0 + rand() * 0.7) + 55.0;;
var d8 = d0 + dsign * (5.0 * rand() + dsign * 14.0);
var w = windIpoint.new(lat, lon, d0, v0, d1, v1, d2, v2, d3, v3, d4, v4, d5, v5, d6, v6, d7, v7, d8, v8);
append(windIpointArray, w);
s.getChild("altitude",7,1).getNode("wind-from-heading-deg",1).setValue(d7);
s.getChild("altitude",7,1).getNode("windspeed-kt",1).setValue(v7);
s.getChild("altitude",8,1).getNode("wind-from-heading-deg",1).setValue(d8);
s.getChild("altitude",8,1).getNode("windspeed-kt",1).setValue(v8);
}
@ -3185,6 +3393,14 @@ if (wind_model_flag == 5)
var set_tile = func {
# check if another instance of local weather is running already
if (local_weather_running_flag == 1)
{
setprop("/sim/messages/pilot", "Local weather: Local weather is already running, use Clear/End before restarting. Aborting...");
return;
}
var type = getprop("/local-weather/tmp/tile-type");
@ -3227,6 +3443,9 @@ if (compat_layer.features.can_disable_environment ==1)
}
# switch off normal 3d clouds
compat_layer.setDefaultCloudsOff();
# now see if we need to presample the terrain
@ -3246,14 +3465,7 @@ if ((getprop("/environment/metar/valid") == 1) and (getprop(lw~"tmp/tile-managem
setprop(lw~"METAR/station-id","METAR");
# switch off normal 3d clouds
var layers = props.globals.getNode("/environment/clouds").getChildren("layer");
foreach (l; layers)
{
l.getNode("coverage-type").setValue(5);
}
}
else if ((getprop("/environment/metar/valid") == 0) and (getprop(lw~"tmp/tile-management") == "METAR"))
@ -3267,24 +3479,44 @@ else if ((getprop("/environment/metar/valid") == 0) and (getprop(lw~"tmp/tile-ma
# see if we need to create an aloft wind interpolation structure
if ((wind_model_flag == 3) or ((wind_model_flag ==5) and (getprop(lwi~"ipoint-number") == 0)))
{set_aloft_wrapper();}
{
if (metar_flag != 1)
{set_aloft_wrapper();}
}
# prepare the first tile wind field
if (metar_flag == 1) # the winds from current METAR are used
{
# METAR reports ground winds, we want to set aloft, so we need to compute the local boundary layer
# need to set the tile index for this
setprop(lw~"tiles/tile[4]/tile-index",1);
var boundary_correction = 1.0/get_slowdown_fraction();
var metar_base_wind_deg = getprop("environment/metar/base-wind-dir-deg");
var metar_base_wind_speed = boundary_correction * getprop("environment/metar/base-wind-speed-kt");
if ((wind_model_flag == 1) or (wind_model_flag == 2))
{
# METAR reports ground winds, we want to set aloft, so we need to compute the local boundary layer
# need to set the tile index for this
setprop(lw~"tiles/tile[4]/tile-index",1);
append(weather_dynamics.tile_wind_direction, metar_base_wind_deg);
append(weather_dynamics.tile_wind_speed, metar_base_wind_speed);
setprop(lw~"tmp/tile-orientation-deg",metar_base_wind_deg);
}
else if (wind_model_flag == 5)
{
var station_lat = getprop("/environment/metar/station-latitude-deg");
var station_lon = getprop("/environment/metar/station-longitude-deg");
var boundary_correction = 1.0/get_slowdown_fraction();
set_wind_ipoint_metar(station_lat, station_lon, metar_base_wind_deg, metar_base_wind_speed);
append(weather_dynamics.tile_wind_direction, getprop("environment/metar/base-wind-dir-deg"));
append(weather_dynamics.tile_wind_speed, boundary_correction * getprop("environment/metar/base-wind-speed-kt"));
setprop(lw~"tmp/tile-orientation-deg",getprop("environment/metar/base-wind-dir-deg"));
var res = wind_interpolation(lat,lon,0.0);
append(weather_dynamics.tile_wind_direction,res[0]);
append(weather_dynamics.tile_wind_speed,res[1]);
setprop(lw~"tmp/tile-orientation-deg", weather_dynamics.tile_wind_direction[0]);
}
else
{
@ -3466,6 +3698,10 @@ if (getprop(lw~"config/buffer-flag") ==1)
}
}
# and indicate that we're up and running
local_weather_running_flag = 1;
# weather_tile_management.watchdog_loop();
}
@ -3594,10 +3830,11 @@ fgcommand("reinit", props.Node.new({subsystem:"environment"}));
#################################################################
var weatherStation = {
new: func (lat, lon, vis, T, D, p) {
new: func (lat, lon, alt, vis, T, D, p) {
var s = { parents: [weatherStation] };
s.lat = lat;
s.lon = lon;
s.alt = alt;
s.vis = vis;
s.T = T;
s.D = D;
@ -3613,6 +3850,63 @@ var weatherStation = {
},
};
var windIpoint = {
new: func (lat, lon, d0, v0, d1, v1, d2, v2, d3, v3, d4, v4, d5, v5, d6, v6, d7, v7, d8, v8) {
var w = { parents: [windIpoint] };
w.lat = lat;
w.lon = lon;
altvec = [];
var wv = windVec.new(d0, v0);
append(altvec,wv);
wv = windVec.new(d1, v1);
append(altvec, wv);
wv = windVec.new(d2, v2);
append(altvec, wv);
wv = windVec.new(d3, v3);
append(altvec, wv);
wv = windVec.new(d4, v4);
append(altvec, wv);
wv = windVec.new(d5, v5);
append(altvec, wv);
wv = windVec.new(d6, v6);
append(altvec, wv);
wv = windVec.new(d7, v7);
append(altvec, wv);
wv = windVec.new(d8, v8);
append(altvec, wv);
w.alt = altvec;
w.weight = 0.02;
return w;
},
};
var windVec = {
new: func (d, v) {
var wv = { parents: [windVec] };
wv.d = d;
wv.v = v;
return wv;
},
};
var effectVolume = {
new: func (geometry, lat, lon, r1, r2, phi, alt_low, alt_high, vis, rain, snow, turb, lift, lift_flag, sat) {
var e = { parents: [effectVolume] };
@ -3763,7 +4057,7 @@ var ec = "/environment/config/";
# a hash map of the strength for convection associated with terrain types
var landcover_map = {BuiltUpCover: 0.35, Town: 0.35, Freeway:0.35, BarrenCover:0.3, HerbTundraCover: 0.25, GrassCover: 0.2, CropGrassCover: 0.2, EvergreenBroadCover: 0.2, Sand: 0.25, Grass: 0.2, Ocean: 0.01, Marsh: 0.05, Lake: 0.01, ShrubCover: 0.15, Landmass: 0.2, CropWoodCover: 0.15, MixedForestCover: 0.1, DryCropPastureCover: 0.25, MixedCropPastureCover: 0.2, IrrCropPastureCover: 0.15, DeciduousBroadCover: 0.1, pa_taxiway : 0.35, pa_tiedown: 0.35, pc_taxiway: 0.35, pc_tiedown: 0.35, Glacier: 0.01, DryLake: 0.3, IntermittentStream: 0.2};
var landcover_map = {BuiltUpCover: 0.35, Town: 0.35, Freeway:0.35, BarrenCover:0.3, HerbTundraCover: 0.25, GrassCover: 0.2, CropGrassCover: 0.2, EvergreenBroadCover: 0.2, EvergreenNeedleCover: 0.2, Sand: 0.25, Grass: 0.2, Ocean: 0.01, Marsh: 0.05, Lake: 0.01, ShrubCover: 0.15, Landmass: 0.2, CropWoodCover: 0.15, MixedForestCover: 0.1, DryCropPastureCover: 0.25, MixedCropPastureCover: 0.2, IrrCropPastureCover: 0.15, DeciduousBroadCover: 0.1, Bog: 0.05, pa_taxiway : 0.35, pa_tiedown: 0.35, pc_taxiway: 0.35, pc_tiedown: 0.35, Glacier: 0.01, DryLake: 0.3, IntermittentStream: 0.2};
# a hash map of average vertical cloud model sizes
@ -3806,9 +4100,11 @@ var thermal = {};
var wave = {};
# array of currently existing weather stations
# arrays of currently existing weather stations and wind interpolation points
var weatherStationArray = [];
var windIpointArray = [];
# a flag for the wind model (so we don't have to do string comparisons all the time)
# 1: constant 2: constant in tile 3: aloft interpolated 4: airmass interpolated
@ -3828,6 +4124,11 @@ var cloud_mean_altitude = 0.0;
var cloud_fractional_lifetime = 0.0;
var cloud_evolution_timestamp = 0.0;
# globals propagating gust information inside the interpolation loop
var windspeed_multiplier = 1.0;
var winddir_change = 0.0;
# global flags mirroring property tree menu settings
var generate_thermal_lift_flag = 0;
@ -3838,7 +4139,7 @@ var detailed_clouds_flag = 1;
var dynamical_convection_flag = 1;
var debug_output_flag = 1;
var metar_flag = 0;
var local_weather_running_flag = 0;
# set all sorts of default properties for the menu
@ -3893,10 +4194,13 @@ setprop(lw~"tmp/box-bottom-n",12);
setprop(lw~"tmp/tile-type", "High-pressure");
setprop(lw~"tmp/tile-orientation-deg", 260.0);
setprop(lw~"tmp/windspeed-kt", 8.0);
setprop(lw~"tmp/gust-frequency-hz", 0.0);
setprop(lw~"tmp/gust-relative-strength",0.0);
setprop(lw~"tmp/gust-angular-variation-deg",0.0);
setprop(lw~"tmp/tile-alt-offset-ft", 0.0);
setprop(lw~"tmp/tile-alt-median-ft",0.0);
setprop(lw~"tmp/tile-alt-min-ft",0.0);
setprop(lw~"tmp/tile-management", "single tile");
setprop(lw~"tmp/tile-management", "realistic weather");
setprop(lw~"tmp/presampling-flag", 1);
setprop(lw~"tmp/asymmetric-tile-loading-flag", 0);
setprop(lw~"tmp/last-reading-pos-del",0);
@ -3933,7 +4237,7 @@ setprop(lw~"tmp/ipoint-longitude-deg",getprop("position/longitude-deg"));
setprop(lw~"config/distance-to-load-tile-m",39000.0);
setprop(lw~"config/distance-to-remove-tile-m",39500.0);
setprop(lw~"config/detailed-clouds-flag",1);
setprop(lw~"config/dynamics-flag",1);
setprop(lw~"config/dynamics-flag",0);
setprop(lw~"config/thermal-properties",1.0);
setprop(lw~"config/wind-model","constant");
setprop(lw~"config/buffer-flag",1);
@ -3943,9 +4247,9 @@ setprop(lw~"config/asymmetric-buffering-flag",0);
setprop(lw~"config/asymmetric-buffering-reduction",0.3);
setprop(lw~"config/asymmetric-buffering-angle-deg",90.0);
setprop(lw~"config/clouds-in-dynamics-loop",250);
setprop(lw~"config/debug-output-flag",1);
setprop(lw~"config/debug-output-flag",0);
setprop(lw~"config/generate-thermal-lift-flag", 0);
setprop(lw~"config/dynamical-convection-flag", 1);
setprop(lw~"config/dynamical-convection-flag", 0);
setprop(lw~"config/thread-flag", 1);
# set the default loop flags to loops inactive

309
Nasal/weather_tile_management.nas
View file

@ -1,6 +1,6 @@
########################################################
# routines to set up, transform and manage weather tiles
# Thorsten Renk, October 2010
# Thorsten Renk, March 2011
########################################################
# function purpose
@ -18,6 +18,8 @@
# calc_geo to get local Cartesian geometry for latitude conversion
# get_lat to get latitude from Cartesian coordinates
# get_lon to get longitude from Cartesian coordinates
# relangle to compute the relative angle between two directions, normalized to [0:180]
# norm_relangle to compute the relative angle between two directions, normalized to [0:360]
# delete_from_vector to delete an element 'n' from a vector
# object purpose
@ -53,6 +55,15 @@ if (distance_to_load > 3.0 * current_visibility)
if (distance_to_load < 29000.0)
{distance_to_load = 29000.0;}
# check here if we have a new weather station if METAR is running
if ((local_weather.metar_flag == 1) and (getprop(lw~"METAR/station-id") != getprop("/environment/metar/station-id")))
{
weather_tiles.set_METAR_weather_station();
}
foreach (var t; tNode) {
var tpos = geo.Coord.new();
@ -200,32 +211,81 @@ if (((local_weather.presampling_flag == 1) and (getprop(lw~"tmp/presampling-stat
}
else
{
var step = 20.0;
var alpha_test = getprop("/environment/metar/base-wind-dir-deg");
print("alpha: ", alpha, " alpha_test: ", alpha_test, " relangle: ", relangle(alpha, alpha_test));
if (relangle(alpha, alpha_test) > step)
if (local_weather.debug_output_flag == 1)
{print("alpha: ", alpha, " alpha_test: ", alpha_test, " relangle: ", relangle(alpha, alpha_test));}
var coordinate_rotation_angle = norm_relangle(alpha, alpha_test);
if (coordinate_rotation_angle < 45.0)
{
print("Coordinate rotation by more than ",step," deg... compensating");
if (relangle(alpha + step, alpha_test) < relangle(alpha-step, alpha_test))
{
alpha = alpha + step;
}
else
{
alpha = alpha - step;
}
var system_rotation_angle = 0;
var displacement_angle = coordinate_rotation_angle;
}
else if (coordinate_rotation_angle < 135.0)
{
var system_rotation_angle = 90.0;
var displacement_angle = coordinate_rotation_angle - 90.0;
}
else if (coordinate_rotation_angle < 225.0)
{
var system_rotation_angle = 180.0;
var displacement_angle = coordinate_rotation_angle - 180.0;
}
else if (coordinate_rotation_angle < 315.0)
{
var system_rotation_angle = 270.0;
var displacement_angle = coordinate_rotation_angle - 270.0;
}
else
{
alpha = alpha_test;
var system_rotation_angle = 0;
var displacement_angle = coordinate_rotation_angle - 360.0;
}
if (displacement_angle < -step)
{
print("Coordinate rotation by more than ",step," deg... compensating");
displacement_angle = -step;
}
else if (displacement_angle > step)
{
print("Coordinate rotation by more than ",step," deg... compensating");
displacement_angle = step;
}
alpha = alpha + system_rotation_angle + displacement_angle;
#if (relangle(alpha, alpha_test) > step)
# {
# print("Coordinate rotation by more than ",step," deg... compensating");
# if (relangle(alpha + step, alpha_test) < relangle(alpha-step, alpha_test))
# {
# alpha = alpha + step;
# }
# else
# {
# alpha = alpha - step;
# }
# }
#else
# {
# alpha = alpha_test;
# }
}
setprop(lw~"tmp/tile-orientation-deg",alpha);
@ -255,7 +315,85 @@ if (((local_weather.presampling_flag == 1) and (getprop(lw~"tmp/presampling-stat
{
var res = local_weather.wind_interpolation(lat,lon,0.0);
alpha = res[0];
var step = 20.0;
var alpha_test = res[0];
if (local_weather.debug_output_flag == 1)
{print("alpha: ", alpha, " alpha_test: ", alpha_test, " relangle: ", relangle(alpha, alpha_test));}
var coordinate_rotation_angle = norm_relangle(alpha, alpha_test);
#print("Norm_relangle : ", norm_relangle(alpha, alpha_test));
if (coordinate_rotation_angle < 45.0)
{
var system_rotation_angle = 0;
var displacement_angle = coordinate_rotation_angle;
}
else if (coordinate_rotation_angle < 135.0)
{
var system_rotation_angle = 90.0;
var displacement_angle = coordinate_rotation_angle - 90.0;
}
else if (coordinate_rotation_angle < 225.0)
{
var system_rotation_angle = 180.0;
var displacement_angle = coordinate_rotation_angle - 180.0;
}
else if (coordinate_rotation_angle < 315.0)
{
var system_rotation_angle = 270.0;
var displacement_angle = coordinate_rotation_angle - 270.0;
}
else
{
var system_rotation_angle = 0;
var displacement_angle = coordinate_rotation_angle - 360.0;
}
#print("Displacement angle: ", displacement_angle);
if (displacement_angle < -step)
{
print("Coordinate rotation by more than ",step," deg... compensating");
displacement_angle = -step;
}
else if (displacement_angle > step)
{
print("Coordinate rotation by more than ",step," deg... compensating");
displacement_angle = step;
}
#print("Normalized displacement angle: ", displacement_angle);
alpha = alpha + system_rotation_angle + displacement_angle;
#print("alpha_out: ", alpha);
#if (relangle(alpha, alpha_test) > step)
# {
# print("Coordinate rotation by more than ",step," deg... compensating");
# if (relangle(alpha + step, alpha_test) < relangle(alpha-step, alpha_test))
# {
# alpha = alpha + step;
# }
# else
# {
# alpha = alpha - step;
# }
# }
#else
# {
# alpha = alpha_test;
# }
#alpha = alpha_test;
setprop(lw~"tmp/tile-orientation-deg",alpha);
var windspeed = res[1];
setprop(lw~"tmp/windspeed-kt",windspeed);
@ -521,8 +659,40 @@ var t = props.globals.getNode(lw~"tiles").getChild("tile",index,0);
var lat = t.getNode("latitude-deg").getValue();
var lon = t.getNode("longitude-deg").getValue();
var alpha = getprop(lw~"tmp/tile-orientation-deg");
# var alpha = getprop(lw~"tmp/tile-orientation-deg");
var alpha_old = getprop(lw~"tiles/tile[4]/orientation-deg");
var alpha = t.getNode("orientation-deg").getValue();
var coordinate_rotation_angle = norm_relangle(alpha_old, alpha);
if (coordinate_rotation_angle < 45.0)
{
var system_rotation_angle = 0;
var displacement_angle = coordinate_rotation_angle;
}
else if (coordinate_rotation_angle < 135.0)
{
var system_rotation_angle = 90.0;
var displacement_angle = coordinate_rotation_angle - 90.0;
}
else if (coordinate_rotation_angle < 225.0)
{
var system_rotation_angle = 180.0;
var displacement_angle = coordinate_rotation_angle - 180.0;
}
else if (coordinate_rotation_angle < 315.0)
{
var system_rotation_angle = 270.0;
var displacement_angle = coordinate_rotation_angle - 270.0;
}
else
{
var system_rotation_angle = 0;
var displacement_angle = coordinate_rotation_angle - 360.0;
}
alpha = alpha_old + displacement_angle;
if (index == 0)
{
@ -622,8 +792,90 @@ else if (index == 8)
}
if (system_rotation_angle > 0.0)
{
if (local_weather.debug_output_flag == 1)
{print("Rotating coordinate system by ", system_rotation_angle, " degrees");}
# create a buffer entry for rotation, this is deleted in the rotation routine
create_neighbour(lat, lon, 9, alpha);
rotate_tile_scheme(system_rotation_angle);
}
}
###################################
# rotate tile scheme
###################################
var rotate_tile_scheme = func (angle) {
if (angle < 45.0)
{
return;
}
else if (angle < 135)
{
copy_entry(2,9);
copy_entry(8,2);
copy_entry(6,8);
copy_entry(0,6);
copy_entry(9,0);
copy_entry(5,9);
copy_entry(7,5);
copy_entry(3,7);
copy_entry(1,3);
copy_entry(9,1);
props.globals.getNode(lw~"tiles").removeChild("tile",9);
}
else if (angle < 225)
{
copy_entry(8,9);
copy_entry(0,8);
copy_entry(9,0);
copy_entry(7,9);
copy_entry(1,7);
copy_entry(9,1);
copy_entry(6,9);
copy_entry(2,6);
copy_entry(9,2);
copy_entry(5,9);
copy_entry(3,5);
copy_entry(9,3);
props.globals.getNode(lw~"tiles").removeChild("tile",9);
}
else if (angle < 315)
{
copy_entry(0,9);
copy_entry(6,0);
copy_entry(8,6);
copy_entry(2,8);
copy_entry(9,2);
copy_entry(3,9);
copy_entry(7,3);
copy_entry(5,7);
copy_entry(1,5);
copy_entry(9,1);
props.globals.getNode(lw~"tiles").removeChild("tile",9);
}
else
{
return;
}
}
#####################################
# copy tile info in neighbour matrix
#####################################
@ -1024,6 +1276,14 @@ foreach(t; tNode)
}
print("alpha: ",getprop(lw~"tmp/tile-orientation-deg"));
var lat = getprop("/position/latitude-deg");
var lon = getprop("/position/longitude-deg");
var res = local_weather.wind_interpolation(lat,lon,0.0);
print("Wind: ", res[0], " tile alpha: ", getprop(lw~"tiles/tile[4]/orientation-deg"));
print("Mismatch: ", relangle(res[0], getprop(lw~"tiles/tile[4]/orientation-deg")));
print("====================");
settimer(watchdog_loop, 10.0);
@ -1281,6 +1541,23 @@ return angdiff;
}
var norm_relangle = func (alpha, beta) {
var angdiff = beta - alpha;
while (angdiff < 0.0)
{angdiff = angdiff + 360.0;}
while (angdiff > 360.0)
{angdiff = angdiff - 360.0;}
if (angdiff == 360.0)
{angdiff = 0.0;}
return angdiff;
}
var delete_from_vector = func(vec, index) {
var n = index+1;

685
Nasal/weather_tiles.nas
View file

File diff suppressed because it is too large Load diff

11
Shaders/clouds-box.frag Normal file
View file

@ -0,0 +1,11 @@
uniform sampler2D baseTexture;
varying float fogFactor;
void main(void)
{
vec4 base = texture2D( baseTexture, gl_TexCoord[0].st);
vec4 finalColor = base * gl_Color;
gl_FragColor.rgb = mix(gl_Fog.color.rgb, finalColor.rgb, fogFactor );
gl_FragColor.a = mix(0.0, finalColor.a, fogFactor);
}

72
Shaders/clouds-box.vert Normal file
View file

@ -0,0 +1,72 @@
// -*-C++-*-
#version 120
varying float fogFactor;
//attribute vec3 usrAttr3;
//attribute vec3 usrAttr4;
//float textureIndexX = usrAttr3.r;
//float textureIndexY = usrAttr3.g;
//float wScale = usrAttr3.b;
//float hScale = usrAttr4.r;
//float shade = usrAttr4.g;
//float cloud_height = usrAttr4.b;
void main(void)
{
float shade = 0.9;
float cloud_height = 1000.0;
gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;
//gl_TexCoord[0] = gl_MultiTexCoord0 + vec4(textureIndexX, textureIndexY, 0.0, 0.0);
vec4 ep = gl_ModelViewMatrixInverse * vec4(0.0,0.0,0.0,1.0);
vec4 l = gl_ModelViewMatrixInverse * vec4(0.0,0.0,1.0,1.0);
vec3 u = normalize(ep.xyz - l.xyz);
// Find a rotation matrix that rotates 1,0,0 into u. u, r and w are
// the columns of that matrix.
vec3 absu = abs(u);
vec3 r = normalize(vec3(-u.y, u.x, 0));
vec3 w = cross(u, r);
// Do the matrix multiplication by [ u r w pos]. Assume no
// scaling in the homogeneous component of pos.
gl_Position = vec4(0.0, 0.0, 0.0, 1.0);
gl_Position.xyz = gl_Vertex.x * u;
gl_Position.xyz += gl_Vertex.y * r * 1.0;
gl_Position.xyz += gl_Vertex.z * w * 1.0;
//gl_Position.xyz += gl_Vertex.y * r * wScale;
//gl_Position.xyz += gl_Vertex.z * w * hScale;
gl_Position.xyz += gl_Color.xyz;
// Determine a lighting normal based on the vertex position from the
// center of the cloud, so that sprite on the opposite side of the cloud to the sun are darker.
float n = dot(normalize(-gl_LightSource[0].position.xyz),
normalize(mat3x3(gl_ModelViewMatrix) * (- gl_Position.xyz)));;
// Determine the position - used for fog and shading calculations
vec3 ecPosition = vec3(gl_ModelViewMatrix * gl_Position);
float fogCoord = abs(ecPosition.z);
float fract = smoothstep(0.0, cloud_height, gl_Position.z + cloud_height);
// Final position of the sprite
gl_Position = gl_ModelViewProjectionMatrix * gl_Position;
// Determine the shading of the sprite based on its vertical position and position relative to the sun.
n = min(smoothstep(-0.5, 0.0, n), fract);
// Determine the shading based on a mixture from the backlight to the front
vec4 backlight = gl_LightSource[0].diffuse * shade;
gl_FrontColor = mix(backlight, gl_LightSource[0].diffuse, n);
gl_FrontColor += gl_FrontLightModelProduct.sceneColor;
// As we get within 100m of the sprite, it is faded out. Equally at large distances it also fades out.
gl_FrontColor.a = min(smoothstep(10.0, 100.0, fogCoord), 1 - smoothstep(25000.0, 30000.0, fogCoord));
gl_BackColor = gl_FrontColor;
// Fog doesn't affect clouds as much as other objects.
fogFactor = exp( -gl_Fog.density * fogCoord * 0.2);
fogFactor = clamp(fogFactor, 0.0, 1.0);
}

10
Shaders/rain-layer.frag Normal file
View file

@ -0,0 +1,10 @@
uniform sampler2D baseTexture;
varying float fogFactor;
void main(void)
{
vec4 base = texture2D( baseTexture, gl_TexCoord[0].st);
vec4 finalColor = base * gl_Color;
gl_FragColor.rgb = mix(gl_Fog.color.rgb, finalColor.rgb, fogFactor );
gl_FragColor.a = mix(0.0, finalColor.a, fogFactor);
}

54
Shaders/rain-layer.vert Normal file
View file

@ -0,0 +1,54 @@
// -*-C++-*-
#version 120
varying float fogFactor;
float shade = 0.8;
float cloud_height = 1000.0;
void main(void)
{
gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;
//gl_TexCoord[0] = gl_MultiTexCoord0 + vec4(textureIndexX, textureIndexY, 0.0, 0.0);
vec4 ep = gl_ModelViewMatrixInverse * vec4(0.0,0.0,0.0,1.0);
vec4 l = gl_ModelViewMatrixInverse * vec4(0.0,0.0,1.0,1.0);
vec3 u = normalize(ep.xyz - l.xyz);
gl_Position = vec4(0.0, 0.0, 0.0, 1.0);
gl_Position.x = gl_Vertex.x;
gl_Position.y += gl_Vertex.y;
gl_Position.z += gl_Vertex.z;
gl_Position.xyz += gl_Color.xyz;
// Determine a lighting normal based on the vertex position from the
// center of the cloud, so that sprite on the opposite side of the cloud to the sun are darker.
float n = dot(normalize(-gl_LightSource[0].position.xyz),
normalize(mat3x3(gl_ModelViewMatrix) * (- gl_Position.xyz)));;
// Determine the position - used for fog and shading calculations
vec3 ecPosition = vec3(gl_ModelViewMatrix * gl_Position);
float fogCoord = abs(ecPosition.z);
float fract = smoothstep(0.0, cloud_height, gl_Position.z + cloud_height);
gl_Position = gl_ModelViewProjectionMatrix * gl_Position;
// Determine the shading of the sprite based on its vertical position and position relative to the sun.
n = min(smoothstep(-0.5, 0.0, n), fract);
// Determine the shading based on a mixture from the backlight to the front
vec4 backlight = gl_LightSource[0].diffuse * shade;
gl_FrontColor = mix(backlight, gl_LightSource[0].diffuse, n);
gl_FrontColor += gl_FrontLightModelProduct.sceneColor;
// As we get within 100m of the sprite, it is faded out. Equally at large distances it also fades out.
gl_FrontColor.a = min(smoothstep(100.0, 250.0, fogCoord), 1 - smoothstep(40000.0, 45000.0, fogCoord));
gl_BackColor = gl_FrontColor;
// Fog doesn't affect rain as much as other objects.
fogFactor = exp( -gl_Fog.density * fogCoord * 0.4);
fogFactor = clamp(fogFactor, 0.0, 1.0);
}

14
gui/dialogs/local_weather.xml
View file

@ -10,8 +10,6 @@
<modal>false</modal>
<text>
<x>10</x>
<y>570</y>
@ -64,7 +62,7 @@
<x>0</x>
<y>525</y>
<combo>
<x>10</x>
<y>0</y>
@ -103,7 +101,7 @@
<command>dialog-apply</command>
</binding>
</combo>
<input>
<x>203</x>
@ -233,7 +231,7 @@
<x>0</x>
<y>440</y>
<combo>
<x>10</x>
<y>0</y>
@ -428,7 +426,7 @@
<x>165</x>
<y>0</y>
<label>alt (ft)</label>
</text>
</text>
<input>
<x>245</x>
@ -442,7 +440,7 @@
<x>320</x>
<y>0</y>
<label>size (km)</label>
</text>
</text>
<input>
<x>410</x>
@ -651,7 +649,7 @@
<x>0</x>
<y>195</y>
<combo>
<x>10</x>
<y>0</y>

87
gui/dialogs/local_weather_tiles.xml
View file

@ -6,20 +6,20 @@
<name>local_weather_tiles</name>
<width>310</width>
<height>330</height>
<height>360</height>
<modal>false</modal>
<text>
<x>5</x>
<y>300</y>
<y>330</y>
<label>Select initial weather scenario tile</label>
</text>
<combo>
<x>10</x>
<y>275</y>
<y>305</y>
<width>280</width>
<height>25</height>
<live>true</live>
@ -43,13 +43,13 @@
<text>
<x>5</x>
<y>240</y>
<y>270</y>
<label>wind deg</label>
</text>
<input>
<x>67</x>
<y>240</y>
<y>270</y>
<width>40</width>
<height>25</height>
<property>/local-weather/tmp/tile-orientation-deg</property>
@ -57,13 +57,13 @@
<text>
<x>105</x>
<y>240</y>
<y>270</y>
<label>kt</label>
</text>
<input>
<x>125</x>
<y>240</y>
<y>270</y>
<width>30</width>
<height>25</height>
<property>/local-weather/tmp/windspeed-kt</property>
@ -71,17 +71,86 @@
<text>
<x>155</x>
<y>240</y>
<y>270</y>
<label>alt. offset (ft)</label>
</text>
<input>
<x>240</x>
<y>240</y>
<y>270</y>
<width>50</width>
<height>25</height>
<property>/local-weather/tmp/tile-alt-offset-ft</property>
</input>
<text>
<x>5</x>
<y>240</y>
<label>gust freq.</label>
</text>
<slider>
<x>65</x>
<y>240</y>
<width>50</width>
<height>20</height>
<min>0.0</min>
<max>1.0</max>
<property>/local-weather/tmp/gust-frequency-hz</property>
<binding>
<command>dialog-apply</command>
</binding>
</slider>
<text>
<x>112</x>
<y>240</y>
<label>strength</label>
</text>
<slider>
<x>167</x>
<y>240</y>
<width>50</width>
<height>20</height>
<min>0.0</min>
<max>1.5</max>
<property>/local-weather/tmp/gust-relative-strength</property>
<binding>
<command>dialog-apply</command>
</binding>
</slider>
<text>
<x>215</x>
<y>240</y>
<label>dir.</label>
</text>
<slider>
<x>240</x>
<y>240</y>
<width>50</width>
<height>20</height>
<min>0.0</min>
<max>45.0</max>
<property>/local-weather/tmp/gust-angular-variation-deg</property>
<binding>
<command>dialog-apply</command>
</binding>
</slider>
<text>
<x>5</x>