20,741
edits
Advanced weather: Difference between revisions
m
→Connection with the multiplayer system
| Line 180: | Line 180: | ||
== Connection with the multiplayer system == | == Connection with the multiplayer system == | ||
<!-- | |||
(should be written by someone who knows what the multiplayer system can and cannot do) | (should be written by someone who knows what the multiplayer system can and cannot do) | ||
--> | |||
Basically that'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 == | == Development == | ||