Board index FlightGear Development Weather

Weather algorithms

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

Weather algorithms

Postby Thorsten » Tue Jun 08, 2010 12:40 pm

I've been working some time on algorithms which lead to a semi-realistic population of clouds in the sky, and for the upcoming release of the version 0.7 of the local weather package, I've taken some time to document my thoughts behind the convective cloud system, the altitude determination of clouds in mountain regions and the large scale weather patterns produced by the system and illustrated the results with screenshots.

If anyone is interested, the result is an appendix to the readme here. I certainly appreciate comments and ideas, tossing ideas back and forth with WooT on how to distribute thermals has been very useful for the system for instance.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Weather algorithms

Postby stuart » Tue Jun 08, 2010 1:34 pm

Hi Thorsten,

I've been thinking recently about how we can better integrate the weather systems you're writing in Nasal with the FG C-based code.

At the moment, it feels as if the Nasal code has to really fight for control of the cloud placements etc. and that there isn't a clean interface. I think there are two interfaces needed here:

1) An interface defining the weather generator (METAR, Weather Algorithms, Manual). At the moment this is mainly handled in C code. I think it might be worth splitting out completely into Nasal so it can integrate with your weather algorithms.

2) A set of properties defining the actual weather conditions. This is mainly there already, except for the generation of 3D clouds, which is all C code based on a set of properties. I think this needs to change so that you can define individual cloudlets as a set of propertie - lon/lat/alt, texture, # of sprites. Basically all the characteristics of the 3D clouds I wrote a while ago.

Thoughts?

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Weather algorithms

Postby Thorsten » Tue Jun 08, 2010 4:19 pm

You have defined the problem rather well. As I see it, the current environment controller is too 'agressive' - it writes e.g. visibility every frame, so I can't set /enviroment/visibility-m from Nasal, but rather have to change the values in the config menu and then call reinit();. A controller which would only set the visibility when asked to change it would go a long way toward a common interface.

A similar thing is how METAR is handled. Currently, it is fetched and executed if --enable-real-weather-fetch is done. It would be nice if it could be fetched and parsed, but then wait for some weather control system to make use of it. I have now written a METAR interface which sets a weather tile based on a parsed METAR, but it doesn't work with the current METAR system because if I fetch a METAR, it overrides my enviroment settings.

So it would be nice to have a system which specifies

* if METAR is fetched or not
* if yes which system executes the parsed METAR info
* if not, which system defines offline weather
* or in the absence of METAR info, which system takes over until METAR is available again

The current weather conditions menu is actually quite good to set up conditions for training approaches or so - the way I envision implementing wind (as a 4-d wind field specified within a mesh of moving control points) is clearly not something you can set up from a menu efficiently.

It seems that this would not be performance-critical, so I agree that having it all in Nasal would be nice.

As for a cloud-generating interface, that would be something... I'm a bit envious how fast your layers are created - currently waiting for clouds to appear after I have written a vector into /models is the bottleneck - all the Nasal runs fast enough. So it seems there is a lot of performance to be gained. However, I don't really know where I want to go, thinking of dynamical weather, there is still a lot of R&D to do. I may need a structure 'cloud' which is a box into which cloudlets are written, such that changing the coordinates of 'cloud' moves the whole thing, but in which I can alter the shading/texturing at runtime to simulate how a Cumulus is formed and decays. In addition, the texture content of the box isn't random - cloud top textures need to go above, cloud bottom textures below. I'm currently working with WooT trying to use high resolution cloud textures, and it seems a large part of the effect is a good mix, and to decide where to put the cloudlets.

Anyway, these are my two cents...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Weather algorithms

Postby stuart » Tue Jun 08, 2010 5:35 pm

Thorsten wrote:You have defined the problem rather well. As I see it, the current environment controller is too 'agressive' - it writes e.g. visibility every frame, so I can't set /enviroment/visibility-m from Nasal, but rather have to change the values in the config menu and then call reinit();. A controller which would only set the visibility when asked to change it would go a long way toward a common interface.


Right. FYI the /environment.visibility-m is interpolated as an L-value from the current visibility to the configured visibility for that altitude.

Thorsten wrote:As for a cloud-generating interface, that would be something... I'm a bit envious how fast your layers are created - currently waiting for clouds to appear after I have written a vector into /models is the bottleneck - all the Nasal runs fast enough. So it seems there is a lot of performance to be gained.


I think if we could have a process that allows Nasal or C code to write clouds to a property tree, and then make a reinit() call to load them all immediately.

BTW - I put a huge amount of effort to get decent performance out of the 3D clouds. You won't believe the amount of grief I get about low frame-rates ;)

Thorsten wrote:However, I don't really know where I want to go, thinking of dynamical weather, there is still a lot of R&D to do. I may need a structure 'cloud' which is a box into which cloudlets are written, such that changing the coordinates of 'cloud' moves the whole thing, but in which I can alter the shading/texturing at runtime to simulate how a Cumulus is formed and decays.


That matches how the 3D clouds that I've got are created - a cloud which contains a set of cloudlets, each of which contains a set of billboarded sprites. (Or at least that's how it used to work - I changed the structure of the clouds about 6 months ago, and I don't recall whether they are structured with cloudlets now).

I would envisage defining a cloud as a directory node with a given lat/lon/alt, and then having some sub-nodes defining the cloudlets.

Note that this would remove the limit of a 20kmx20km box, and make it easier to set up different conditions above different airports based on METAR...

Thorsten wrote:In addition, the texture content of the box isn't random - cloud top textures need to go above, cloud bottom textures below. I'm currently working with WooT trying to use high resolution cloud textures, and it seems a large part of the effect is a good mix, and to decide where to put the cloudlets.


FYI I solved this problem rather neatly. For the C-based cloudlets, the texture is a nxm grid of individual textures. We select the horizontal texture index randomly, but the vertical texture index is based on the vertical position of the sprite within the cloud (or it might be the cloudlet, I forget).

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Weather algorithms

Postby Thorsten » Tue Jun 08, 2010 6:46 pm

Note that this would remove the limit of a 20kmx20km box, and make it easier to set up different conditions above different airports based on METAR...


I'm not quite sure what you mean here.

As far as I am concerned, the tiles (they are 40x40 km, chosen roughly 'the size of how far you can see') are a feature, not a bug. They allow to represent large scale weather structures without excessive memory use - right now, I can represent crossing a 300 km warmfront going all the way from Cirrus down to Nimbostratus with just a set of rules. I've always had the idea to make a Hurricane based on a 5x5 tile structure with border and core elements - once I have wind, it shoudn't take more than 3 hours to define it. Specifying such large structures on the basis of clouds is not really efficient.

Technically, there is no real requirement to use 40x40 km tiles. I use them because it's useful to have control over distance scales of few 100 km, and building blocks of that size give me that. If you want to set conditions above different airports based on METAR, you can use the structure given by the availability of METAR info. But that's not a real weather scale, it just traces civilization. METAR info in Africa will impose a very different grid than METAR in the US. A METAR-driven grid would have huge tiles over the ocean, and tiny ones close to New York. So the distance at which you get to see weather changes becomes a function of population density rather than atmospheric physics - not what I want.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Weather algorithms

Postby Hooray » Wed Jun 09, 2010 12:14 pm

Thorsten wrote:I certainly appreciate comments and ideas, tossing ideas back and forth with WooT on how to distribute thermals has been very useful for the system for instance.


This looks pretty interesting, while I can't really contribute anything to the algorithmic side at the moment, I think the "Slope Soaring Sim" that we found last year when WooT was working on the ridge lift support contained some neat algorithms and is open source (GPL) and cross platform software.

I downloaded it last year (fairly small) and also took a brief look at the source code, but to be honest I gave up pretty quickly when I read on the webpage that the author of SSS has a PhD in meteorology and written plenty of other simulations :lol:

So I didn't even really try to understand all the underlying maths that he is using in the source code, on the other hand didn't you mention that you are doing quantum (or fluid?) physics for a living? Maybe you are more in his "league" then ;-)

Just taking a quick look at the web page, it is obvious that this guy has done lots of impressive physics simulation stuff: http://www.rowlhouse.co.uk/main.html (i.e. worked for Crytek on the Crysis engine!!).

Given that SSS is open source and even GPL, it would be perfectly fine to look at the code and borrow ideas from it for re-implementation in FlightGear/Nasal for your local weather system.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Weather

Who is online

Users browsing this forum: No registered users and 4 guests