#### Board index‹FlightGear‹Development‹Weather

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

Hi all!

I didn't quite read through all the details of the messages, but I've been thinking about similar things every once in a while. I think Thorsten had some very similar vision.

I've been thinking about making a system, that makes a map of every available METAR positions (lat/lon) and then pitteway triangulates [1] that. Then, for any given point we know the 3 nearest METARS available and can interpolate between them to make smooth weather transitions. Problems are that 1) I don't know if all point sets can be pitteway triangulated and 2) how it is done.

Then, we should make a Nasal interface to request the weather model at any given point. That way all contrails, windsocks etc would work correctly.

Also, it would be possible to generate cloud layers and rain/snow near the points where METAR indicates those. I think it would be possible to see a distant storm front or something with this system. For this, we could use the voronoi diagrams statto mentioned (which are used in pitteway triangulation too, btw).

I don't know how setting the weather would work then. Maybe we could have this "spatial weather" as a separate weather model in the weather selection dialog? But how to turn on rain in certain area with nasal?

In any case, I think this must be done in C++ side, enhance the current weather models.

Lauri / Zan
Zan

Posts: 123
Joined: Tue Oct 20, 2009 10:28 am

Problems are that 1) I don't know if all point sets can be pitteway triangulated and 2) how it is done.

You don't need to triangulate for a smooth interpolation. If you have any n neighbouring METAR stations, you can simply do an average weighted with the inverse distance to the stations. That will give you

* the parameter measured at position i whenever you are at i
* the average of n parameters when the distance to each station is equal
* a smooth interpolation between

It's something like 2-3 lines code.

I don't know how setting the weather would work then. Maybe we could have this "spatial weather" as a separate weather model in the weather selection dialog? But how to turn on rain in certain area with nasal?

See here for my idea of the concept. In 1.9.1, my thunderstorm model works perfectly fine producing rain only below the storm - Nasal does just fine there.
Thorsten

Posts: 11336
Joined: Mon Nov 02, 2009 8:33 am

Zan wrote:I've been thinking about making a system, that makes a map of every available METAR positions (lat/lon) and then pitteway triangulates [1] that. Then, for any given point we know the 3 nearest METARS available and can interpolate between them to make smooth weather transitions. Problems are that 1) I don't know if all point sets can be pitteway triangulated and 2) how it is done.

Don't use Pitteway. If you want to triangulate, use a Delaunay triangulation. Where a Pitteway triangulation exists, it's equal to a Delaunay triangulation. You CAN make them for any bounded point-set.

Or just use Thorsten's inverse distance weighting. But I think it will require more than a few lines unless you are going to loop over every single METAR in existence (you need a way to find all of them within a given truncation radius, perhaps a quadtree or space-filling hash curve).
MAKG

Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Thorsten wrote:You don't need to triangulate for a smooth interpolation. If you have any n neighbouring METAR stations, you can simply do an average weighted with the inverse distance to the stations. That will give you

I thought about this too, but it has at least one drawback. Assume we use 3 nearest weather stations. Now, if the 3 nearest stations are very close to eachother, let's say a bit south from current position, and 4th on is someway farther to the north, this interpolation will give wrong result. In this case, we would like to interpolate from the weather on the north side to the weather on the south side. This is why I wanted to use the triangulation method.

If the delaunay triangulation is the same or at least close enough to pitteway, then we should use that one. I think OSG has algorithms for that built-in, we could probably use those and not reinvent the wheel.

I read the proposal on the wiki, and to me it seemed good. I don't know how evenly metar weather stations are located, so maybe we could use the voronoi graphs for large scale, and divide those to, say, 30kmx30km squares for mid-scale, to vary the weather locally.

I'm a bit against using pure nasal for weather, instead we should have nasal functions to access the weather systems. Something like set_weather_at_position and set_current_weather which could be used to set weather tiles or a global weather for e.g. thunderstorm clouds. And then we would not need to worry about the weather system overwriting the custom values and the "normal" weather could be restored with something like restore_weather. This needs a bit thinking.

Lauri
Zan

Posts: 123
Joined: Tue Oct 20, 2009 10:28 am

I'm not volunteering for the C++ parts, but I will happily help anyone who wants to try - it should be easy. The FGPositioned code will easily give you the N closest airports (with metar, if desired) for an arbitrary SGGeod (that's lat/lon/alt). The Nasal interface parts are also pretty easy!

If anyone fancies taking the plunge, let me know (here, or email, or on IRC) and I can chat about the C++ work required - I'm also happy to help get it building and applied to CVS. Obviously it needs more work on the Nasal side to test and use the data.
zakalawe

Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

I thought about this too, but it has at least one drawback. Assume we use 3 nearest weather stations. Now, if the 3 nearest stations are very close to eachother, let's say a bit south from current position, and 4th on is someway farther to the north, this interpolation will give wrong result.

I think I disagree. The inverse distance algorithm will give a result which is not in general linear interpolation, the triangulation will give a result which is linear interpolation - but you don't know how the weather in reality changes between stations anyway. Both results are model assumptions, both are smooth interpolations - so I'd argue that both are equally credible (or equally wrong), the linear interpolation isn't in any sense better, it's just more difficult. So in the above situation the weather would change to the same end result as you fly north - it would just change faster in one algorithm than it would in the other.

I'm a bit against using pure nasal for weather, instead we should have nasal functions to access the weather systems. Something like set_weather_at_position and set_current_weather which could be used to set weather tiles or a global weather for e.g. thunderstorm clouds.

To me it would make sense to have things which need to run on a high framerate (cloud model transformations, checks if the aircraft enters certain volumes, weather parameter interpolations...) on the C++ side, whereas I'd let Nasal handle slow operations - so they remain more accessible. Tile setup can take seconds for example. I certainly wouldn't want all in Nasal, and having to overwrite the 'normal' weather system makes for a bit awkward coding - so some C++ work would be extremely useful.

I don't know how evenly metar weather stations are located

Probably O(10 km) in the SFO area to O(3000 km) over the oceans.
Thorsten

Posts: 11336
Joined: Mon Nov 02, 2009 8:33 am

Thorsten

Posts: 11336
Joined: Mon Nov 02, 2009 8:33 am

Thorsten, neither of those interpolations are rigorously smooth. Inverse-distance has singularities, and linear has singular second derivatives. The latter is not a problem unless you're using a higher order integrator (then, it's a BIG problem -- BTDT).

Inverse-distance can be coupled with another model without too much trouble, but at the expense of an ad-hoc scheme that may have exceptions. It is important that the weighting functions be continuous (though not necessarily smooth) through any boundaries.

An example of a weighting function that truly is smooth is Gaussian weighting. I've used that for synthetic telescope images, largely the same problem as the one at hand.
MAKG

Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Thorsten, neither of those interpolations are rigorously smooth. Inverse-distance has singularities, and linear has singular second derivatives.

< math geek mode on >
You're right about the smoothness of the linear interpolation of course. Inverse distance doesn't actually have true singularities, as the denominator and numerator go singular the same way simultaneously, so the analytical limit d_i -> 0 is finite and well defined. Just numerically that's a bitch for small d_i. Gaussian weighting works quite well, but doesn't gurantee you that e.g. the pressure measured at position i really is p_i after interpolation, as you always get contributions from other stations regardless the distance. But if you don't mind that (I certainly don't), it would also work fine.
<math geek mode off >
Thorsten

Posts: 11336
Joined: Mon Nov 02, 2009 8:33 am

Currently being prepared - Altocumulus clouds. Here is a real sky photograph

and I arranged the patch in a similar way

That's how they look from layer altitude

Okay, they look rather similar to the standard 3-d clouds, so where is the deal? Well, they are AI objects and have a few other nice features:

* user specified position
* user specified movement - you can make them drift with the wind
* larger variation in cloud size
* arrangeable in realistic patterns (I'm working to script that)
Thorsten

Posts: 11336
Joined: Mon Nov 02, 2009 8:33 am

Previous