Board index FlightGear Development Weather

Weather dynamics

Everything related to weather simulation, visuals should be discussed in the shader subforum.

Weather dynamics

Postby Thorsten » Wed Apr 07, 2010 6:42 am

This thread is part of the local weather project - I'm just trying to avoid one monster thread and split the topics a bit, because there is a lot of ground to cover.

It's still a bit in the future, but I have started to think about implementing weather dynamics, and I keep hitting some problems. I wanted to use the opportunity to put the concepts to a discussion early on to see if anyone else can see a good way to do things or can add a useful idea.

First, unless I want real atmospherical dynamics, I don't think CPU time is an issue - clouds drift slowly, it's completely pointless to change the position of a 1000 m scale cloud by 5 cm every frame, that wouldn't even be visible, so positioning loops can run much more slowly and don't take significant resources as compared to other tasks.

The obvious idea is to let clouds and weather effects drift with the wind. That is relatively easy to implement, but has a few problems in particular situations:

1) not all clouds actually do - Lenticularis clouds are for example stationary in strong winds and just mark the spot where the airstream is deflected upward

2) thunderstorms actually create their own wind system - the surface winds are towards the cloud since it sucks air in - but the cloud as such may still drift in the surrounding airmass, on top of which the thunderstorm wind system exists

3) what to do when drifting clouds hit a barrier (frequently an issue in the mountains)

To get this right, a weather tile would need to specify a relatively complex wind system, with mean drift of airmass and low altitude/high-altitude in and outflow of strong convective systems and some winds/clouds tied to terrain features. It's easier to do that offline, to get this to work with real METAR fetch when the system needs to decide if a given wind in a METAR represents just a low altitude inflow into a system or part of mean drift is in all likelihood a nightmare.

Suppose that's done - so you can see clouds moving in a weather tile with the wind system as specified in the tile and tied to the terrain. For a flight from A to B, everything works fine. But if you fly around A and stay there, a new problem occurs:

4) sooner or later all clouds will drift out of the tile, and you see clear skies. For Cumulus clouds which are explicitly generated and die no problem - but the system can't explicitly model the generation of high-altitude clouds and layers in a meaningful way (without massive atmosperical dynamics) so we're a bit stuck.

The solution to that is to let the tile center itself drift with the mean airmass flow. If you stay at A, essentially your initial weather tile moves out, a new tile center approaches and a new weather tile generation is triggered, so you can see changing weather drift by without ever leaving the airport, just as if you would fly to B and trigger new tiles all the time. Sounds neat, but has other difficulties:

5) weather tiles are now moving objects with changing angular size (dependent on their position) and randomly generated orientation. To get any type of multiplayer synchronization quickly becomes a mess - so then probably all weather would need to be generated from a central server and all cloud positions / effect volumes / interpolation points distributed to the player. I don't know what bandwidth is available, in this case every player would need to get the position of O(5000) objects from the server, that's something like 25.000 float numbers. It doesn't seem to be an excessive amount of data in the age of megabit/s data transfer though - but I honestly don't know if that is feasible.

6) weather tiles now could (and in general would) move with different tile center speeds (just because you can't honestly put in a continuity equation for airflow into the system without drastic performance loss) - so a fast tile might eventually merge with a slow one, or a slow tile might create a gap to a fast one. That would chiefly be visible if you stay with a tile a long time, i.e. if you fly with it with the velocity of the airstream. Not doable for planes, obviously, but that's the natural motion of balloons.

One can think of fixing that by enforcing some ad-hoc rules which would try to mimick a continuity equation, but the results of that go beyond what I can comfortably simulate in my imagination without actually coding it.

So - that's where my ideas are at the moment, and I'd appreciate any other thoughts on the matter!
Thorsten
 
Posts: 11322
Joined: Mon Nov 02, 2009 8:33 am

Re: Weather dynamics

Postby MAKG » Wed Apr 07, 2010 4:28 pm

The continuity equation is trivial for subsonic or other incompressible flow. It's that density is constant with time.

You're looking for the next order. Conventionally, it's the "energy equation," which relates winds to pressure differences. But what you really seem to be looking for is advection.

If you're going to do that "for real," it's a supercomputer problem. People may not notice second-scale physics, but the clouds do. Skip the small scale stuff without massive smoothing, and you make artifacts.

You seem to be rather clever at coming up with visual fakes; I think you're going to need to continue that. Perhaps you can advect as a background. But you're running up against the limitations of that -- it is inherently linear, but the weather isn't. There are inherently nonlinear effects such as fronts, thermals, and soliton waves.

I don't have a good answer for you -- what I've done in my own flight planner/simulator is far from satisfying. Basically, we grab a global upper air forecast twice a day from the US Navy (NOGAPS) or civilian (NCEP GFS), and quadrilinearly interpolate winds, temperature, and mixing ratio/relative humidity. We largely ignore ground effects, since we're most interested in the stratosphere. Perhaps you could use such an approach to linearly advect features, but keep in mind that prevents them from changing with time and decouples weather from topography, both of which are extremely unphysical (though it's conventionally asserted that topography doesn't affect the stratosphere, we can see small signatures from the Rocky Mountains in the NOGAPS 150 mbar data -- this may be an artifact).
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Re: Weather dynamics

Postby eotunun » Thu May 06, 2010 9:56 pm

Yepp, important thing!
I wanted to explore glider flying in FG tonight, finding there was next to no slope wind lift. :shock: :(
Another thing to take into account would be how to identify topological influence on weather, like fixed thermal sources. Forest areas and town areas are visualy distinguishable in the scenery, would it be possible to give such areas individual "heating textures", some guessing the albedo of the surface?

Remembering the beauty that was Flight Unlimited II, which ran smoothly on my PII 233Mhz, 64 MB RAM there must be a way of low resource weather simulation that produces very authentical weather simulation. Their approach to simulating the atmosphere basically must have been similar to Flight Gear´s, so I hope there still is some developement potential.

Thorsten, you talk about seeing the weather tiles. What I basically miss is feeling them in aircraft movement. As said, I feel of this as one of the major weaknesses of Flight Gear so far. The other one are the unbreakable planes. I must have flown through icing conditions as well without noticing any, did I just miss it or isn there none available so far?
User avatar
eotunun
 
Posts: 17
Joined: Fri Apr 23, 2010 10:50 am
Callsign: D-ENUN

Re: Weather dynamics

Postby Tuxklok » Thu May 06, 2010 10:51 pm

About synchronization over mp, rather than trying to send data for every cloud position and whatever else (which would be bandwidth excessive and slow) you should look at making the entire system deterministic and entirely client side. Given the same inputs(METAR), it should generate exactly the same outputs(weather). So if people are using the same METAR at the same location, they should get the same thing generated and simulated and see the same thing. Then the only synchronization worry I think would be that people starting at different times would have the same thing generating, but be at different points in the simulation time wise. Player A may have started 30 seconds ahead of Player B, and in his simulation the clouds would have already started drifting and be in different position. This could easily be solved though I think by having a single central time variable sent over mp somewhat infrequently that everyone's local system synchronizes with smoothly. A single floating point value representing the weathers simulation time in seconds should be enough for that I believe.

anyway..hopefully that makes sense and I'm not just rambling on...

As for the rest, of which most of the phenomena and algorithms behind it are over my head. I can only say as with most things in real time graphics/simulation....simplify and fake it as much as possible. :)

cheers...keep it up it's looking great!
The Austria Scenery Project - more info
fg-scenery-tools - gitorious | videos
fgcomgui - Open source, cross platform, gui front end for fgcom. more info

More random musings and doings can be found on my personal site. (work in progress)
User avatar
Tuxklok
 
Posts: 1326
Joined: Tue Apr 21, 2009 6:04 pm
Location: Orlando, FL
Callsign: Tuxklok / N1292P
OS: GNU/Linux

Re: Weather dynamics

Postby Thorsten » Fri May 07, 2010 6:08 am

@ eotunun:

I wanted to explore glider flying in FG tonight, finding there was next to no slope wind lift.


There's ridge lift all right in 2.0.0 - just take care that the wind is strong also in the lowest boundary layer because that's where ridge lift is generated.

Another thing to take into account would be how to identify topological influence on weather, like fixed thermal sources. Forest areas and town areas are visualy distinguishable in the scenery, would it be possible to give such areas individual "heating textures", some guessing the albedo of the surface?


That's done already and working nicely (performance issues still being sorted out). Also daytime influence on strength and distribution of thermals is in. This thread is about making it dynamical - i.e. (among other things) how do thermals drift and evolve over time? How to change the cap cloud model to reflect the evolution stage?

Thorsten, you talk about seeing the weather tiles. What I basically miss is feeling them in aircraft movement.


Note sure what you mean - the v0.6 local weather package generates weather patterns as you fly, and for example in a test flight around Nellis AFB yesterday I had quite a variety of patterns ranging from Cirrus and Cirrostratus to Altocumulus fields and low Cumulus development to empty skies.

I must have flown through icing conditions as well without noticing any, did I just miss it or isn there none available so far?


The environment provides icing conditions - but it's up to the aircraft to react to them, so if the aircraft is designed to ignore some environment settings, then they won't affect you. If the aircraft has no provision to handle collisions, then you can fly through solid objects. I know that some aircraft at least display icing warnings and have de-icing equipment (I had this in the Concorde going through a Bilzzard) - I don't know if the FDM would actually change though.


@Tuxklok:

About synchronization over mp, rather than trying to send data for every cloud position and whatever else (which would be bandwidth excessive and slow) you should look at making the entire system deterministic and entirely client side.


A deterministic system means either strictly repeating cloud configurations (boring and unrealistic) or generating hundreds of weather patterns manually (who's going to do that?). So, there is something to be said for randomized systems. Besides, some things you can only meaningfully do in a Monte-Carlo approach.

So if people are using the same METAR at the same location, they should get the same thing generated and simulated and see the same thing.


That means that every time you see the same METAR cloud config, you see literally the same sky. Would you really like that? The beauty of weather is that it's unpredictable after all.

I'm not sure the bandwidth requirement of sending cloud coordinates is so huge - people transfer liveries over MP as far as I know - sending position information of 1000 clouds is something like 50 kb - compared with the texture size of the 777-200ER (1.6 Mb) that's nothing. And you could stretch that over 30 seconds... even a modem can do that.
Thorsten
 
Posts: 11322
Joined: Mon Nov 02, 2009 8:33 am

Re: Weather dynamics

Postby Vikthor » Fri May 07, 2010 8:20 am

Thorsten wrote:A deterministic system means either strictly repeating cloud configurations (boring and unrealistic) or generating hundreds of weather patterns manually (who's going to do that?). So, there is something to be said for randomized systems. Besides, some things you can only meaningfully do in a Monte-Carlo approach.
...
That means that every time you see the same METAR cloud config, you see literally the same sky. Would you really like that? The beauty of weather is that it's unpredictable after all.

Can't you use pseudo-random generator, which will, for a given seed generate series of random looking numbers? If you will derive the seed from precise time and date, you will get random sky each time, but if you manage to synchronize the process between all servers and clients everybody will see the same sky.
If my description does not make any sense to you try Wikipedia.
Vikthor
 
Posts: 76
Joined: Thu Mar 06, 2008 10:16 am
Location: Prague,Czech republic
Callsign: OK-VIK/Vikthor

Re: Weather dynamics

Postby Thorsten » Fri May 07, 2010 8:29 am

We discussed that option in the other thread. It would work, provided no other Nasal process apart from the local weather system uses the random number generator - which is a dangerous assumption to make.
Thorsten
 
Posts: 11322
Joined: Mon Nov 02, 2009 8:33 am

Re: Weather dynamics

Postby eotunun » Fri May 07, 2010 10:03 am

One possible solution for the varying strength of thermals was visible in Flight Unlimited. They provided "balls of lift" that climbed at various speeds and were penetratable for other liftballs. With more balls surrounding your plane the climb increased. It felt pretty authentic, giving the feel of unsteady thermals on windy days. With the liftballs being "solid" (as in "rigid") and very simple objects, that should work for multiplayer modes as well. Idea? :D
User avatar
eotunun
 
Posts: 17
Joined: Fri Apr 23, 2010 10:50 am
Callsign: D-ENUN

Re: Weather dynamics

Postby Thorsten » Fri May 07, 2010 11:17 am

WooT has developed a fairly detailed model of a thermal and its dynamics which is in steady-state already implemented - you may want to look into this thread for details.
Thorsten
 
Posts: 11322
Joined: Mon Nov 02, 2009 8:33 am

Re: Weather dynamics

Postby AndersG » Fri May 07, 2010 3:02 pm

Thorsten wrote:We discussed that option in the other thread. It would work, provided no other Nasal process apart from the local weather system uses the random number generator - which is a dangerous assumption to make.


You could have a separate pseudo-random generator instance for the weather system.
It could even be implemented in Nasal if needed.
Sending piles of weather data over MP is not a good idea with the current MP protocol.

/Anders
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2449
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: Weather dynamics

Postby Tuxklok » Fri May 07, 2010 4:04 pm

Thorsten wrote:@Tuxklok:

About synchronization over mp, rather than trying to send data for every cloud position and whatever else (which would be bandwidth excessive and slow) you should look at making the entire system deterministic and entirely client side.


A deterministic system means either strictly repeating cloud configurations (boring and unrealistic) or generating hundreds of weather patterns manually (who's going to do that?). So, there is something to be said for randomized systems. Besides, some things you can only meaningfully do in a Monte-Carlo approach.

So if people are using the same METAR at the same location, they should get the same thing generated and simulated and see the same thing.


That means that every time you see the same METAR cloud config, you see literally the same sky. Would you really like that? The beauty of weather is that it's unpredictable after all.

You can still throw some randomization in when starting off the simulation. Just once it's started it would be deterministic so you get the same thing given the same random salt and weather parameters to kick it off. For mp the random salt could be sent across mp along with the current simulation time so we all get the same pseudo random weather. I'm sure a solution to getting a random number could be found, even written in nasal as Anders said.

I'm not sure the bandwidth requirement of sending cloud coordinates is so huge - people transfer liveries over MP as far as I know - sending position information of 1000 clouds is something like 50 kb - compared with the texture size of the 777-200ER (1.6 Mb) that's nothing. And you could stretch that over 30 seconds... even a modem can do that.

There is no transmission of image data across the network, just the name of the livery. The livery is loaded from your copy of the aircraft if you have a livery with that name...otherwise you just see the default.

cheers!
The Austria Scenery Project - more info
fg-scenery-tools - gitorious | videos
fgcomgui - Open source, cross platform, gui front end for fgcom. more info

More random musings and doings can be found on my personal site. (work in progress)
User avatar
Tuxklok
 
Posts: 1326
Joined: Tue Apr 21, 2009 6:04 pm
Location: Orlando, FL
Callsign: Tuxklok / N1292P
OS: GNU/Linux

Re: Weather dynamics

Postby Thorsten » Fri May 07, 2010 4:09 pm

If a separate random number system could be generated, that would indeed be my preferred solution - it's a neat idea. I just don't really know how to do it...
Thorsten
 
Posts: 11322
Joined: Mon Nov 02, 2009 8:33 am

Re: Weather dynamics

Postby AndersG » Fri May 07, 2010 4:58 pm

Thorsten wrote:If a separate random number system could be generated, that would indeed be my preferred solution - it's a neat idea. I just don't really know how to do it...


I'm sure there are plenty of pseudo-random number generators out there. Off the top of my head and with some help from wikipedia there is the generator by Blum, Blum and Shub (easy to remember :). It'd be something like this in (untested) Nasal:

Code: Select all
var RandomGenerator = {
    new : func (seed) {
        return {
            parents      : [RandomGenerator],
            x            : seed,
            max          : math.pow(2,32),
            modulus      : p*q # where p and q are appropriate primes.
        };
    },
    # Get a random number in [0, 1[.
    next : func {
        me.x = math.mod(me.x * me.x, me.modulus);
        return math.mod(me.x, me.max)/me.max;
    }
};


The modulus needs to be chosen with care, though and my quick search didn't find any suggested ones.
IIRC Blum, Blum and Shub is for cryptographic work and might be unnecessarily expensive for our use.

Cheers,

Anders
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2449
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: Weather dynamics

Postby WooT » Wed May 12, 2010 10:58 am

I may be totally wrong, but it seems that nasal has a simple implementation of rand and srand. ( see
http://www.plausible.org/nasal/lib.html )
My understanding of rand and srand in c++ is that for a given seed ( that you set with srand(number) ), rand() will always output the same sequence of numbers, whatever the computer used. (see http://www.fredosaurus.com/notes-cpp/misc/random.html )

Is it true for the nasal version too ? I don't know. It would be worth checking, though.

just my 2 cents
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 4:09 pm

Re: Weather dynamics

Postby Thorsten » Wed May 12, 2010 4:46 pm

Well, yes, the idea is to have a random number generator for which we can be sure no other process is using it. If local weather has its own implementation local_weather.rand(); then this is pretty certainly true.
Thorsten
 
Posts: 11322
Joined: Mon Nov 02, 2009 8:33 am

Next

Return to Weather

Who is online

Users browsing this forum: No registered users and 1 guest