Advanced weather

The Advanced Weather (AW) system, formerly called Local Weather (LW) and sometimes Detailed Weather, is included in FlightGear since version 2.4 (see release notes). It was then renamed and improved for FlightGear 2.6 (see release notes and detailed explanation and many screenshots for version 1.4 of the Advanced Weather in FlightGear 2.6).

Unification of basic and advanced weather system

It is planned to unify the weather systems in FlightGear. Possibly for the upcoming version 3.0. It is therefore needed to improve the usability of the advanced weather configuration system. Join the discussion on this topic in the forums.

History

Status: August 2010

The current weather system of FlightGear can be called global when FlightGear runs offline: Any menu weather setting, be it windspeed, visibility, precipitation or cloud coverage, affects the weather everywhere. It is not possible to fly to a region where the cloud cover is different, or see precipitation from an aircraft flying in sunshine, or to observe a change in atmospheric pressure by flying somewhere else.

When online, the weather system offers a link with METAR servers, which makes the weather locally-determined global: One can change the weather by flying to a different location where a different METAR is available, but the change happens instantaneously everywhere, i.e. there is no transition of for example crossing a rain front or leaving dense clouds behind to emerge in sunshine.

A local weather system in contrast is one in which continuous changes from the weather at one location to the weather in a different location are simulated, i.e. weather phenomena are tied to a specific location. Needless to say, a local weather system is significantly more complicated to simulate than the present system. Below is a conceptual outline how a local weather system for FlightGear could be created using mainly existing technology and code.

Advanced Weather has had the capability to do a 3-dim interpolation of a windfield for years - you just need to hand it the correct aloft information, and it rotates the wind with altitude and position. It's actually 4d, because it has also the ability to gradually fade interpolation vectors in and out. Since default METAR doesn't say anything about aloft layer, it tries to deduce how much the local boundary layer winds are reduced from the terrain topology, guesses the lowest aloft wind layer from there, then guesses higher aloft layers based on Coriolis deflection of winds and the generic strengthening of high-altitude winds. ^[1]

Scales for weather phenomena

Real weather phenomena are determined by processes occurring at vastly different size scales. At the large end of the scale is the system of low and high pressure regions and fronts between cold and warm air masses, which have spatial size scales of O(1000) km. At the other end of the scale are very localized phenomena, for instance a dark tarmac surface heated by sunlight acting as the source point of a thermal updraft resulting in a Cumulus cloud. Both size scales are relevant for the FlightGear experience - an airliner on a long haul flight is able to observe large-scale weather fronts from above, whereas a glider pilot needs a reasonable simulation of local updrafts and sinks tied to terrain features in a credible way for a realistic flight experience. A local weather system therefore needs to

Simulate weather phenomena at different scales
Ideally work offline as well as online
Allow modification by the user on various scales
Be reasonably fast to run in real-time

The actual dynamics of the atmosphere is a very complex problem which even solved approximately needs hours of CPU time on supercomputing clusters. From this, it is clear that a local weather system cannot be an (even approximately) physically accurate description of processes in the atmosphere, but needs to be a credible mockup of such a description in which heuristic rules replace simulation.

To give an example for what this means, consider the development of Cumulus clouds. Cumulus development is reduced on a hot day under a hazy Cirrus sky. The reason is that the Cirrus sky reflects part of the sunlight, thus the ground is not heated that much by direct sunlight and the convective processes responsible for Cumulus cloud formation are lessened. An accurate simulation would need to start with the energy absorbed from the sunlight on various types of surfaces, then solve the equations governing the heat flux from the ground to the air above, followed by fluid-dynamical equations for the convective currents creating Cumulus clouds. A heuristic rule would simply state that the probability for the placement of a Cumulus cloud into the FlightGear environment is reduced by 50% when a Cirrus cover is present (obviously, the sophistication of the rule set determines how realistic the weather system will appear).

In the following, the technology for such a local weather system needed at the relevant scales is outlined - first for the situation offline, followed by ideas how it could be connected with the METAR system in online use.

Small scale - effect volumes and average conditions

To simulate local weather at small scale, effect volumes (EV) are a useful concept. The effect volumes define regions in which the normal weather conditions (wind, turbulence, updraft, visibility, precipitation...) are replaced by ones characteristic for the region. As an example, one would define the inside of a cloud as an effect volume in which visibility is reduced as compared to outside, or the precipitation layer underneath a thunderstorm as an EV in which heavy rain is on, visibility is reduced, the temperature is reduced and some turbulence may be active.

The conditions characteristic for the EV are imposed once the aircraft enters the volume, they are restored to the outside values once the aircraft leaves the region again. The FlightGear AI system already has examples of structures which in essence are EVs - thermal and thunderstorm. The first structure contains an EV in which vertical air motion is active, the second one in which turbulence is present. These structures could be generalized to an AI system weather in which essentially all weather parameters inside the volume could be set by XML tags.

On the visual side, parts of the EV must also be tied to visible models. The inside of a cloud can be modelled by reduced visibility, but the outside of the cloud must be a model. Similarly, the inside of a rain front appears as rain generated by the FlightGear system, but the outside must be a 3-d model of a precipitation layer. This means that individual 3-d models for various visible atmospheric phenomena (clouds, precipitation, fog, ...) need to be created (see Howto: Modelling Clouds for a collection of techniques for creating cloud and precipitation models).

Outside the EV, many meteorological parameters may vary in a continuous way, for example visibility may decrease from 5000 to 4000 m when flying 20 km north - but inside the cloud (the EV), it will change in a discontinuous way very suddenly to a low value (say 30 m), to jump back to a large value outside the cloud. Thus, the EVs are used to simulate only discontinuous, local changes in conditions, the larger scale changes in the background need to be taken care of by a different system.

EV's should be implemented such that they can be user-specified, i.e. a user should be able to place any particular combination of weather effects and cloud/precipitation model to a specific location.

Mid scale - weather tiles

Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) which would cover a region of, say, 30x30 km or something of that size. Inside tiles, weather is simulated explicitly in terms of EVs and 3-d models.

As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warm front - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front.

Thus, there need to be different 'types' of tiles, each representing a typical snapshot of a development inside the larger system. Tile themes would be something like 'leading edge of warm front', 'trailing edge of warm front', 'cold front', 'dry high-pressure region', 'developed tropical thunderstorms' and so on. This has the added benefit that the user can specify the weather locally simply by choosing an appropriate tile from a menu (he does not need to micromanage the weather by placing individual EV and cloud models).

The type of tile then determines the rules for populating the tile with EV and models. A 'leading edge of a warm front' tile could for example have the rules

Populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft
Make sure the models are spaced sufficiently far apart
Make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)
Populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft

(...)

The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles.

Technically, each tile can be populated by a Nasal script specific for the tile type whenever the tile is needed (probably when it becomes visible). As an example for the development state of the system (March 2010), here is the view for a weather tile representing an approaching cold front with a Stratocumulus layer and occasional Cumulonimbus activity.

Large scale - tile placement rules

To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.

If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simply due to the tile placement rules mocking up the presence of real large-scale weather systems.

Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.

Connection with the METAR system

Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:

Selection of tile type
Placement of EVs and models inside the tile
Continuously varying weather parameters

Selection of tile type

If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.

Placement of EVs and models inside the tile

At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).

METAR and continuously varying weather parameters

If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).

To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure p is known at n positions, such that the pressure at position i is p_i and the distance between aircraft and i is d_i, then a good approximation of the local pressure is

p = (sum p_i (1/d_i)) / (sum 1/d_i)

as this will make the pressure at position i equal to p_i and lead to the average of the individual pressures if the distance to all METAR stations is the same.

Creating custom Weather Tiles

Hard-customizing a weather scenario for your needs is fairly easy. If you look into Nasal/local-weather/weather_tiles.nas you can for instance find the function set_high_pressure_tile() That has lines var spread = 10.0 + 4.0 * rand(); var D = T - spread; which set spread and dewpoint D, so if you want a certain cloud base, you just set spread to your desired value such that the cloudbase will later be spread * 400 later. The exact cloud base will always depend a bit on the topology, outcrops of the terrain tend to push it up under some conditions.^[2]

If you have a function (data table,...) providing the wind vector w =(wx, wy, wz) as a function of position and time, i.e. w (x,y,z,t), is it possible to make that work in FG, yes that is possible.

Advanced Weather allows to specify a weather effect volume by function (like the distribution of lift inside thermals is implemented) and such a dedicated windshear function could be simulated close to the ground. The required tool is Nasal, FGs scripting language.

Nasal files are usually *.nas files, they are program code, not just "configuration files". So you will want to check out $FG_ROOT/Nasal/local_weather and in particular, see the various "tiles" in weather_tiles.nas

For instance, to add support for wind-shear, you probably want to have a look at the effect volume management routines. Basically you want to write something analogous to thermal_lift_start(), thermal_lift_stop() and thermal_lift_loop() in /Nasal/local_weather/local_weather.nas and use the management routines of effect_volume_loop()

You'd have the best control over weather just defining your own specific tile (see the various tiles in weather_tiles.nas - a minimal structure might be

####################################
# my own tile
####################################

var set_my_own_tile = func {

setprop(lw~"tiles/code","myown");

tile_start();

var x = 0.0;
var y = 0.0;
var lat = 0.0;
var lon = 0.0;

var alpha = getprop(lw~"tmp/tile-orientation-deg");
var phi = alpha * math.pi/180.0;
var alt_offset = getprop(lw~"tmp/tile-alt-offset-ft");

# get tile center coordinates

var blat = getprop(lw~"tiles/tmp/latitude-deg");
var blon = getprop(lw~"tiles/tmp/longitude-deg");
calc_geo(blat);

# first weather info for tile center (lat, lon, visibility, temperature, dew point, pressure)

local_weather.set_weather_station(blat, blon, alt_offset, 45000.0, 14.0, 12.0, 29.78);

var alt_offset = getprop(lw~"tmp/tile-alt-offset-ft");

# draw some clouds

create_2_8_altocumulus_streaks(blat, blon, 12000+alt_offset, alpha) ;
create_6_8_stratus(blat, blon, 3000+alt_offset, alpha) ;

# set visibility and light attenuation as a function of altitude

local_weather.set_atmosphere_ipoint(blat, blon, 45000.0, 3000.0, 45000.0, 0.0, 15000.0, 17000.0, 0.8, 12000.0, 17000.0); 

append(weather_dynamics.tile_convective_altitude,3000.0);
append(weather_dynamics.tile_convective_strength,0.0);

tile_finished();

}

which controls all clouds/visibility. Turbulence can be coded into that as an effect volume spanning the whole tile (as for example for the cold front). Wind is read from the menu, so the properties need to be set accordingly.

METAR strings give you a lower level of control (you can't control the precise clouds being drawn and the vertical structure of the atmosphere that way).

If you have a Nasal subroutine creating the wind field, Thorsten (get in touch via the forum) volunteers to provide integration help you with implementing it in the correct places.

There are other possibilities, you might for instance try to alter the generic boundary layer code of Advanced Weather to add automatic windshear detection, or you might alter the C++ code of Basic Weather - it really depends on what information you have and what you'd like to do.

Connection with the multiplayer system

Note

It would seem useful to get Richard into the boat, because (once again) Emesary seems kind of ideal for the required communication.^[3]

This is a feature that could have been there at least four years ago. AW is nearly made for efficient sync over MP, because once you give it a dedicated random number generator, all you need to send is tile coordinates, a handful of meta-data variables and a random seed, and it'll get identical weather across multiple instances. No need to send thousands of cloud positions (which never shares the thermals anyway) - you can get the whole tile structure identical for hardly any transmission cost. All it really takes is someone who cares about multi-instance sync and has some Nasal experience to get up and code it. It's probably less than 300 lines of code added to the AW tile manager. But we're moving in circles - every six months someone remarks it'd be nice to have, Thorsten writes how it can be accomplished but that since he is neither interested in MP nor have an MP test setup won't do it himmself (you don't seriously expect him to develop something he can't test? himself), Thorsten offers his help with the AW internals to everyone who wants to have a go - and nothing happens, we repeat the exercise half a year later. So the offer still stands - Thorsten believes synchronizing AW over MP is not very difficult, and he'll help with the task, but it has to be done by someone who has a setup to actually test it. ^[4]

We have two weather systems that work aircraft-centered, but zero which work server-centered - what's the smaller task - creating a p2p design to transmit a comparatively small amount of info, or write a server-based weather system from scratch?^[5]

To state the problem in a nutshell: An aircraft-centered system doesn't have to care about matching to large-scale weather patterns beyond cloud visibility range. It doesn't have to care that Earth is a sphere. It doesn't have to care if winds lead to severe inconsistencies 3 hours into tile generation, because you'll be long gone from the area by the time the problems become visible. A server-based weather system has to care about all things. There is no space beyond visible range into which you can simply let problems run.^[6]

Suppose we manage to spawn exactly the same weather tile for two players. In scheme B), since cloud motion is a tile property, they would continue to evolve the same way. But in scheme A), if one player flies at 5000 ft where the wind is 10 kt and the other at 15.000 ft in 20 kt winds, the clouds will drift apart with 10 kt even if you manage to create them synchronied. So you can't cast this into a mere synchronization problem at tile creation. But if you want to enforce synchronization later, the problem goes beyond a mere exchange of information - it becomes one of control (and consistency) Nature moves clouds in a windfield C), and at least you must detatch that from aircraft position as in scheme A). My original scheme B) would have been suitable for MP synchronization (this is part of the reason I introduced it that way). But since Stuart's cloud rendering system doesn't recognize 'tile-index' as a valid concept, there is no easy way to get it back and to move clouds by tile again. And thus, wind is going to be a problem if you require high precision and wind drift of clouds.

^[7]

Basically it's pretty difficult - it's a plane-centered approach - it won't translate into a global weather server and it won't naturally give two planes in approximately the same location precisely the same weather (apart from METAR reported parameters which would agree - but there's an inifinity of ways to have scattered cloud cover). Years ago ideas were discussed and Thorstten worked out a neat way of approximately synchronizing it in a peer-to-peer fashion among MP participants (assuming they all run on METAR, which seems the thing on MP).

Basically the first plane gets to build the weather tile is in the vicinity, any plane that reaches the area queries the plane already there whether it has weather tiles available or not, if yes it queries for the information to build them, if not it does it itself and announces their availability. This doesn't have to be high bandwidth because the meta-information to build a tile is very small (a random seed and a handful of parameters) and decision times can be of order of minutes.

Thorsten mentioned that Richard's Emesary framework would be ideal for this sort of thing.

The changes AW side would be modest - basically a shift to a dedicated random number generator, a routine to build a tile based on incoming information, one to store and encode the meta-data of tiles already created and that'd basically be it. Thorsten never did anything into this direction because he does not do MP himself, and has no opportunity to test and developing blind without being able to see how it works isn't what he considers fun... But that's the kind of thing Thorsten would do to synchronize weather across sessions.^[8]

Speaking for AW: the main thing is lots of stuff is a lot easier if you can assume it happens in the 100 km around a certain spot. Basically you can assume Earth is reasonably flat, you can expand coordinates into a local Cartesian system of equally-sied tiles, you never need to put up with spherical trig, you can put enough 'looseness' into the weather grid such that it gradually deforms to adapt to prevailing winds and traces the fronts (for instance weather at fronts is oriented - there's a cold and a warm side to a front with quite different properties). If you have to cover the whole globe with about equally sized weather tiles, the form of the grid and continuity quickly becomes issues. If you allow tile sizes to shrink with latitude, then the larger clouds may not fit into a tile any more... You have to use spherical trigonometry to set up everything, it's not clear where the 'looseness' to deal with frontal weather or higher latitudes should come from... Don't you wish sometimes we'd live on Discworld? Personally I think the idea of a local 'loose' grid gradually adapting to what's needed is pretty neat because it solves a lot. How you'd MP that depends on whether you want to have exact sync (i.e. see the identical arrangement of clouds at identical places) or approximate sync (see optically similar weather) across instances. Exact sync means either giving up the loose grid (without a clear idea on my side of what should replace it) or as in the P2P mode, allow the first plane in the region of interest to define the grid and make all others use it as long as they're close and transit to their own as they depart (should be unproblematic as long as Earth is sparsely covered by MP planes, i.e. most of the planet would not have to explicitly generate weather tiles - which I believe is the case). Approximate sync means that each instance fetches weather tile meta-data from the server and build from that (rather than its own random number driven tile generator), but that will not have the grids for two planes precisely aligned with each other, so they will see the same type of clouds and weather, but not necessarily in the same spot. Needless to say, that's easier. (Note that whether you see a cloud and fog etc. also depends on rendering settings, so we're unable to guarantee identical weather visuals for the simple reason that we have different renderers and selectable LOD and density ranges for clouds). That's at least my two cents. It wasn't called 'local weather' for nothing ;-)^[9]

Development

Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [1]
Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a "NONE" or "MUTE" logging priority [2].
The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [3]
We could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized.
For some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that.
Excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe.
To be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [4] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though).

Feature requests on the C++ side

Intended as a base for discussions on how to implement particular features in the C++ code. Also see Weather algorithms discussion from 06/2010.

As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be performance, accessibility, a clear structure and backward compatibility. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.

Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file compat_layer.nas. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the FlightGear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to FlightGear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:

Terrain related

(08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [5] [6].

To check for wave conditions far from the original obstacle doesn't work well in FlightGear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.

Environment related

(08/2012): Provide an option to disable the precipitation "layer" system [7]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [8] [9] (fixed by Stuart)

(06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [10].

Expose the atmospheric model to the property tree (or Nasal) [11] [12] [13] [14]

Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set /environment/ridge-lift/enabled to 0

Cloud placement

08/2012: Cloud placement meanwhile uses a new fgcommand "add-cloud", however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.

Calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard FlightGear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:

A 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules.

Clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.

Performance bottlenecks

For reference, the main performance bottlenecks in v0.81 seem to be:

Rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.

Moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed.

Generating a cloud configuration. This is only a significant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal

Sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed)

Placing clouds into the scenery. Performance is reduced while the FlightGear core lets clouds appear in the scenery

Deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.

Frequently used fgcommands

Property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)

New Nasal API requests

For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++ The file $FG_ROOT/Nasal/local_weather/compat_layer.nas contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.