Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Changes

Jump to: navigation, search

Advanced weather

10,801 bytes added, 19:43, 25 January 2017
Connection with the multiplayer system
The '''Advanced Weather''' (AW) system, formerly called '''Local Weather''' (LW) and sometimes '''Detailed Weather''', is included in FlightGear since version 2.4 (see [http://www.flightgear.org/news/flightgear-v2-4-0-released/ release notes]). It was then renamed and improved for FlightGear 2.6 (see [http://www.flightgear.org/news/flightgear-v2-6-0-released/ release notes] and [http://www.flightgear.org/tours/advanced-weather-v1-4-in-flightgear-2-6/ detailed explanation and many screenshots] for version 1.4 of the Advanced Weather in FlightGear 2.6).
== Unification of basic and advanced weather system ==
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 had 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. <ref> {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34960164/
| title = <nowiki>Re: [Flightgear-devel] Aircraft-specific weather (Extra 500)</nowiki>
== 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.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35259165/
|title = <nowiki> Re: [Flightgear-devel] Autostart advanced weather with METAR from
commandline </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Aug 3rd, 2016
|added = Aug 3rd, 2016
|script_version = 0.40
}}</ref>
 
 
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.
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
<syntaxhighlight lang="nasalphp">
####################################
# my own tile
== Connection with the multiplayer system ==
<!--
(should be written by someone who knows what the multiplayer system can and cannot do)
-->
 
{{Note|
It would seem useful to get Richard into the boat, because (once again) [[Emesary]] seems kind of ideal for the required communication.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35609551/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 17th, 2017
|added = Jan 17th, 2017
|script_version = 0.40
}}</ref>
 
 
}}
 
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. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35595674/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Jan 10th, 2017
|added = Jan 10th, 2017
|script_version = 0.40
}}</ref>
 
 
We have two weather systems that work aircraft-centered, butero 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?<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=151995#p151995
|title = <nowiki> Re: Clouds online </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 1st, 2012
|added = Mar 1st, 2012
|script_version = 0.40
}}</ref>
 
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.<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=152091#p152091
|title = <nowiki> Re: Clouds online </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 2nd, 2012
|added = Mar 2nd, 2012
|script_version = 0.40
}}</ref>
 
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.
 
<ref>{{cite web
|url = https://forum.flightgear.org/viewtopic.php?p=152428#p152428
|title = <nowiki> Re: Clouds online </nowiki>
|author = <nowiki> Thorsten </nowiki>
|date = Mar 5th, 2012
|added = Mar 5th, 2012
|script_version = 0.40
}}</ref>
 
 
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.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35491937/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Nov 15th, 2016
|added = Nov 15th, 2016
|script_version = 0.40
}}</ref>
 
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 ;-)<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35492964/
|title = <nowiki> Re: [Flightgear-devel] Traffic 2020: Towards a new Development
Model for FlightGear AI Traffic </nowiki>
|author = <nowiki> Thorsten Renk </nowiki>
|date = Nov 15th, 2016
|added = Nov 15th, 2016
|script_version = 0.40
}}</ref>
== Development ==
* [http://forum.flightgear.org/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010)
* [http://forum.flightgear.org/viewtopic.php?f=5&t=7358 A local weather system] (03/2010)
 
 
== References ==
{{Appendix}}
[[Category:Weather]]
[[Category:Development projects]]
18,232
edits

Navigation menu