Board index FlightGear Development Weather

Cirrus sky (download link in first post)

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

Cirrus sky (download link in first post)

Postby Thorsten » Wed Feb 24, 2010 1:58 pm

Here's why I believe in modelling local weather using an AI scenario - high altitude Cirrus and Cirrocumulus clouds over the standard 3-d Cumulus layer.

Image

This is how the Cirrus clouds look from the mean altitude of the cloud layer:

Image

This is another close-up view of some icy cloud strands from above:

Image

And here's a beautiful picture of a Cirrus cloud in sunset:

Image

(all pics done from the Ufo)

As I said elsewhere, I'm trying to document all my experiments with clouds in the Wiki if anyone wants to know how it is done. Please let me know if anyone is interested in joining AI cloud development - many things require rather time consuming fine-tuning and experiments, and I guess it could be more fun in a small group.


Edit:

An early version of the package is available for download here, and a version updated for Flightgear 2.0.0 here

Some info (v0.3):

This package contains the local weather AI scenarios 'local_weather_thunderstorm' and 'local_weather_cirrus'. Currently they populate the sky over San Francisco either with a thunderstorm or a Cirrus/Cirrocumulus sky. The thunderstorm comes with dynamical weather effects - rain, snow, turbulence and lightning inside the cloud tower. The packages contain more cloud models and textures than are actually needed in the scenarios, the scenarios are just to demonstrate what can be done using local weather AI models.

Known issues:

* AI model clouds seem to interfere with the standard layered clouds, thus for best effect any layered clouds need to be off - a low 3-d Cumulus layer on the other hand works well.

* Currently, the Cirrus and Cirrocumulus cloud models use the Aircraft AI system. Presumably, this (dependent on visibility) leads to their sudden (dis-)appearance with distance, and a better solution should be found.

* In tests, the rain inside the storm did not switch on in spite of /metar/rain-norm being set properly. This has nothing to do with the scenario as such, even without the scenario, the rain does not switch on when the menu slider is moved. Deactivating and immediately reactivating shader effects in the Rendering Options menu solves the problem.


The package should be extracted in the Flightgear root directory.

The package is developed and tested using Flightgear 2.0.0, it may or may not work properly on other versions.

Thorsten Renk, Mar. 2010
Last edited by Thorsten on Fri Mar 05, 2010 7:20 pm, edited 3 times in total.
Thorsten
 
Posts: 10587
Joined: Mon Nov 02, 2009 8:33 am

Re: Cirrus sky

Postby VaLeo » Wed Feb 24, 2010 2:25 pm

I made few experiments with cirrus too.
By now they have hardcoded tiling, so its impossible to play with size of tile through property tree. I tweaked it in code, but cannot tie it to property...

As I see, your cirrus is not 2D, but 3D clouds? Its looking great!

And I want to say, that I interested in joining AI cloud development :)
VaLeo
 
Posts: 186
Joined: Wed Nov 29, 2006 10:00 am
Location: Ukraine, Dnipropetrovsk
Version: GIT
OS: Debian 7

Re: Cirrus sky

Postby f-ojac » Wed Feb 24, 2010 6:54 pm

Lovely !

Keep on the good work !
--
If you want to support my Terrasync server, hosted on a private server, you can donate here: http://ns334561.ip-5-196-65.eu/WS2.0/WS ... 2.0.1.html
f-ojac
 
Posts: 1273
Joined: Fri Mar 07, 2008 9:50 am
Version: GIT
OS: GNU/Linux

Re: Cirrus sky

Postby Hooray » Wed Feb 24, 2010 9:10 pm

This looks really very impressive, and your interest in this area of FG addresses some of the issues that we pointed out last year when we were talking about improving glider support in FG (which led to the ridge lit system being implemented by WooT).

An all encompassing weather system that realistically creates weather phenomenons in an integrated fashion (metar, winds, temperature, clouds, humidity, precipitation, turbulence) is still missing in FG.

The fact that you are doing these things without touching any C++ code, shows the power of the technology that is already in place in FG.


good luck and keep us posted!
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: Cirrus sky

Postby Thorsten » Thu Feb 25, 2010 11:30 am

I wonder if an integrated weather system is a bit much to chew on - but I can of course put forward a few ideas how I would do it (but that would require some manpower), and then we can see if it can be done.

The complicated thing about weather is that it probes so many size scales. From the prespective of a glider pilot, weather appears very local: A large parking lot heats up in sunlight, it heats the air above, a bubble of heated air eventually rises and a thermal forms until it hits the point where temperature equals dew point, at which point a Cumulus cloud is formed, which can be displaced from the parking lot by the wind. But all this doesn't happen in the morning (the parking lot is still too cool), in strong wind (the wind dissipates the hot air bubble before it can rise), in dry air (the thermal forms, but no cloud condenses) or when a cirrostratus layer is overhead (it may still be hot, but sunlight doesn't selectively heat the parking lot). It's pretty clear that this can't be implemented - same thing as with real 3-d clouds - one needs to go for a credible illusion instead and instead of solving atmospheric dynamics, encode the rules of what usually happens and usually doesn't in an heuristic way.

On the other end of the size scale, an airliner pilot going transatlantic will experience weather on a global scale where pressure systems of size O(100-1000) km determine what is seen. It's equally clear that those can't really be put into Flightgear in detail - but again, there should be a scheme to create the impression that they are there.

The current local METAR based weather system is not really good on either scale - it sets the weather everywhere around the aircraft to the weather parsed from the METAR. In a local sense, this fails to create a situation in which I fly in sunshine over Berkeley and see San Francisco vanishing in rain showers. In a global sense, longhaul flight weather becomes a series of disconnected sudden changes whenever a new METAR is fetched.

My idea would be to manage the weather based on 'tiles' of, say, 30x30 km or anything like that. Inside the tile, the arrangement of clouds would be according to things like wind, but heavily custom-crafted to account for things like the descending ladder of different cloud types from Cirrus down to Nimbus when looking into a warm front, or the different shape of Cumulus when caused by strong thermals or just by lots of moisture. As much of the arrangement as possible could however be randomized, e.g. the detailed selection of individual cloud models and even some of the positioning (wind will largely determine the orientation, and so on). Precipitation would then be part of this arrangement, modelled only underneath rain clouds. Detailed cloud base could be determined by METAR.

The actual weather tile would be chosen based on a snapshot of METARs in a 100 km radius - some algorithm would try to get from that the global picture where in the scheme of things (warmfront, cold front, high pressure, low pressure, what else...) the tile is, and select the closest matching tile out of a library of weather tiles which have to be created to match the typical weather situation inside a global setting, and already prepare the next tile before the aircraft enters it.

Inside the tile would also be some space for local weather phenomena - also subject to boundary conditions set by the global scheme - I don't know how ridge lift is implemented in detail, but I suspect it could be used to place Lenticularis cloud models. At least some amount of heuristics could place thermals and sinks based on ground coverage and displace them downwind. The biggest challenge here is probably local weather in the mountains - it's hellishly short range and essentially unpredictable...

This should in principle allow to see rainfronts from sunshine, or to observe a semi-realistic change of weather from high above as one crosses a large low pressure region across the Atlantic.

If there's serious interest in working on that kind of weather model, I'll make a Wiki page summarizing the ideas.

I believe pretty much everything can more or less be done with the existing technology (the Nasal + xml structure is incredibly nifty) , although some things would presumably be faster when coded in C++, and eventually it's probably cleaner to hard code it when it works. But for example the heuristics determining the global weather situation from METAR doesn't need to be fast - this can take minutes and still is fine. The only thing that really needs to be fast are transformations of 3d clouds whenever they need to be rotated - and here I'd have a few more animation tags besides the spherical and non-spherical billboard on my wishlist (see the Wiki for that). A few other things I noticed have to do with sunlight scattering on Cirrus - but these are details. I don't actually know if e.g. the Cirrus models I used readily generalize to the C++ shader technology - the curved surface on which they are projected is essentially hand-made to blend in with the cloud structure - maybe they have to remain AI models.

So, a short and mid-term to-do list:

* create a library of cloud models/textures - there is no one fits all, and each cloud takes some work to look good
* right now, the cloud models are based on the AI aircraft definition - can one find a better solution?
* create a few (static) tiles of cloud arrangements to demonstrate the concept and gain experience
* make a script to set up tiles at the local position based on heuristic rules what types of clouds occur where, but also using wind and cloud base info from METAR
* write a piece of code to assemble a more global weather picture from METARs within a given radius
* write a piece of code to place thermals, sinks and lentis in appropriate places based on terrain info when the tile should have this kind of weather
* eventually let the global weather info determine the choice of tile from a library of different tiles
Thorsten
 
Posts: 10587
Joined: Mon Nov 02, 2009 8:33 am

Re: Cirrus sky

Postby Hooray » Thu Feb 25, 2010 1:30 pm

I wonder if an integrated weather system is a bit much to chew on - but I can of course put forward a few ideas how I would do it (but that would require some manpower), and then we can see if it can be done.


I wasn't trying to say that your work should result in such an "integrated weather system" (I do realize that this a lot of work), I was merely trying to say that your work is appreciated because it already integrates some weather phenomena that are currently supported in a standalone fashion and do not yet consistently work together.

So, you are basically already doing some "integration work" ;-)

Most of the required features for a fully integrated weather system are already in place in FG in form or another, it's just that these are not yet connected properly.

Also, the question remains whether such an integrated weather system should really be coded from scratch, or if it might be preferable, to leverage existing open source projects or libraries that already fulfill many things that would be desirable.

For example, during the scope of the ridge lift discussion last year, several other open source simulators were found that target simulation of unpowered flight.

For unpowered flight, a high degree of realistic weather simulation is obviously very important and it would probably be a good idea to check each of these out and see if any of the concepts, features or even code (licensing permitting) could be borrowed to improve FlightGear's "weather model".

Just taking a look at the list of features supported by "Slope Soaring Sim" (GPL), makes it obvious that some of these would be very useful in FG:

  • The aerodynamics part of the code is well separated from the rest. Currently a component approach is used (reading in from text-based configuration files), but it would be very easy to add in a different aerodynamics module (e.g. one based on crrcsim).
  • Thermals are simulated, including downdrafts and the inflow/outflow effects at the bottom/top.
  • Dynamic soaring is possible!
  • The terrain and wind field can either be loaded from file, or calculated at run-time. The artificial terrain generation options are currently mid-point displacement and a superposition of gaussian peaks.

It's pretty clear that this can't be implemented - same thing as with real 3-d clouds - one needs to go for a credible illusion instead and instead of solving atmospheric dynamics, encode the rules of what usually happens and usually doesn't in an heuristic way.


Yes, if you take a look at the ridge lift thread, you will see that there was a very elegant way found to simulate ridge lift, without sampling several square miles of terrain elevations (basically, the method just samples a handful of sufficiently spaced apart terrain points along a vector of the wind to see if ridge lift occurs or not).

The inventor of this approach is registered here using the forum nick "B21" and has also shown some interest in improving the weather model in FG.
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: Cirrus sky

Postby MAKG » Thu Feb 25, 2010 4:38 pm

You might want to check out NCEP's GFS for global upper-air models. It's VERY coarse (smallest available grid is 0.5 deg, about 15x30 miles at mid-latitudes). But it will tell you where the low pressure systems are, where there is turbulence (well, potential vorticity), where there are clouds, etc.

Doing this physically correctly is impossible even on the largest supercomputer, since dissipation scales are millimeters and driving scales are thousands of kilometers -- 9 orders of magnitude in dynamic range! So, quite a lot will need to get faked in order to make something feasible. The "standard" approach the US Navy uses is to make a global model (NOGAPS) and use it for initial conditions for smaller-scale regional forcasts (COAMPS). NCEP does this as well, but only for the lower-48 US.

As for the METAR problem, the largest problem is just that it changes discontinuously, which is real fun if you have the autopilot on, in altitude hold. It's massively fake, but perhaps blending the METARs with some form of linear interpolation or other smoothing might help (including in the time direction!). It's important to have continuous edges for the window functions (i.e., no sharp radius). The "right" answer is a feature-capturing advection code, but that very quickly becomes a supercomputer problem, and is not likely feasible at all.
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Re: Cirrus sky

Postby Hooray » Thu Feb 25, 2010 5:01 pm

The current local METAR based weather system is not really good on either scale - it sets the weather everywhere around the aircraft to the weather parsed from the METAR.


Yes, weather in FlightGear is inevitably "glocal" weather, so no matter where you go - the weather will be the one that you configured previously.

This is of course pretty powerful in that you can easily change the surrounding weather without having to lookup your position (or what "weather tile" you are on), because changes to the environment will inevitably also reference your current position, but it falls short at supporting realistic weather where weather should be different at different positions/times and where weather phenomena should have a mutual effect on each other.

This is obviously still fairly powerful because Nasal can be used to dynamically modify the surrounding weather while in-flight (as you have no doubt noticed during your recent experiments).

But at the moment there is simply no way to tell FG to instantiate certain weather phenomena (think turbulence) at a certain given position (or time of day).
I would imagine, this type of optional granularity would also be handy for many instruction-like scenarios or even "missions", where weather phenomena need to be configurable to this degree.

Also, it's worth keeping in mind that the current model is totally unaware of multiplayer being used or not, in other words each client using multiplayer can still have its own weather settings no matter if these make sense or not.

So weather settings are not synchronized across multiplayer clients and so there may be a lack of consistency under some circumstances.

And while multiplayer consistency should probably only be considered a very low long-term priority, it makes probably sense to keep in mind that some people may not want to use a common/shared "weather system" on multiplayer, even if it should eventually exist. So, a decoupled approach seems to make sense.

Creating a weather system that may eventually work similar to a metar server should make it possible to allow multiplayer clients to optionally subscribe to server-side weather or not.

In a local sense, this fails to create a situation in which I fly in sunshine over Berkeley and see San Francisco vanishing in rain showers. In a global sense, longhaul flight weather becomes a series of disconnected sudden changes whenever a new METAR is fetched.


Yes, absolutely - this is also about the issue of weather not being configurable on a specific position/time basis.

To some extent, his could possibly be addressed by providing and using METAR-like data at a finer granularity, so that one METAR isn't directly applied to a complete "weather tile", but instead multiple METAR reports are used to dynamically populate a weather tile, and interpolations/extrapolations are used in transition zones (or those without any METAR data available).
And still users may want to individually set up custom weather (clouds, winds) at certain positions.

I believe pretty much everything can more or less be done with the existing technology (the Nasal + xml structure is incredibly nifty) , although some things would presumably be faster when coded in C++, and eventually it's probably cleaner to hard code it when it works.


Yes, that's true.
The usual approach in FlightGear is to use Nasal scripting for prototyping and as glue code, and hard code performance-critical code using Nasal helper functions, so that the code itself would be run in C++ space but would still be accessible to scripts by using a new custom functions.

Regarding Nasal coding, you only have to keep in mind that Nasal code is by default run inside the fgfs main loop, so the framerate you get is directly tied to the update rate of your scripts (i.e. something like 20-30 hz should usually not be a problem).

So either subsystem may currently slowdown the other one (rendering <-> scripting).
This makes it also unsuitable for implementhing high frequency computations, which is good to know.

If you do need things to run at a higher rate, you will either need to see if Nasal threads (without using any of the non threadsafe FG APIs inside the thread!) can be used or if the code in question can be moved into C++ space (this will however a require a recompiled/updated fgfs binary, recompiled binaries are frequently made available as CVS snapshots by some developers).

Some time ago (can't find the discussion now), I was able to easily run Nasal computations inside a dedicated helper thread at rates of several khz.

For prototyping purposes, Nasal is however very powerful and can often be used without touching any C++ at all.

When we were discussing the ridge lift system last year, we also found that it could have been largely implemented just in Nasal.

But for example the heuristics determining the global weather situation from METAR doesn't need to be fast - this can take minutes and still is fine.


Yes, and such complex computations that may take long but whose results are not necessarily required right away, can also be split up to be executed across several frames or even seconds, so that the results can be accumulated slowly.

The only thing that really needs to be fast are transformations of 3d clouds whenever they need to be rotated - and here I'd have a few more animation tags besides the spherical and non-spherical billboard on my wishlist (see the Wiki for that).


I am still not really very familiar with the latest code for 3D clouds in CVS since the migration to OSG, however the last time the 3D clouds system was discussed here, our forum moderator "stuart" was able to provide some feedback about how the 3D cloud system is designed and implemented and what its restrictions are.

So he is probably also the best person to talk to for requests regarding additional animation tags.

If there's serious interest in working on that kind of weather model, I'll make a Wiki page summarizing the ideas.


Last year when we were discussing the new "ridge lift" system, there was already one page added specifically about improving glider realism: http://wiki.flightgear.org/index.php/Im ... er_Realism

It already has a small section about weather modeling, but adding a new page specifically about weather modeling might actually be a good idea.
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: 11312
Joined: Tue Mar 25, 2008 8:40 am

Re: Cirrus sky

Postby Armchair Ace » Thu Feb 25, 2010 6:41 pm

Could you post those rather nice clod textures somewhere other than CVS? It would be much appreciated if you did! :)
Member of the FlightGear Flying Club

Current Projects :
Miscellaneous texture and sound work
User avatar
Armchair Ace
 
Posts: 1385
Joined: Sun Sep 27, 2009 7:48 pm
Location: EGP?
Callsign: G-ATPF
IRC name: ArmchairAce
OS: Mac OSX

Re: Cirrus sky

Postby Thorsten » Fri Feb 26, 2010 9:48 am

@Armchair Ace:

Could you post those rather nice clod textures somewhere other than CVS? It would be much appreciated if you did!


Actually, they are not on CVS at all. At this point I'm still tinkering with my cloud texture library and the Cirrus sky (the texture edges look sometimes a bit unrealistic and need a bit fine-tuning for example, and there'll be a few more different Cirrocumulus clouds, but I will make them available soon.

@MAKG,Hooray:

It's massively fake, but perhaps blending the METARs with some form of linear interpolation or other smoothing might help (including in the time direction!).

(...)
To some extent, his could possibly be addressed by providing and using METAR-like data at a finer granularity, so that one METAR isn't directly applied to a complete "weather tile", but instead multiple METAR reports are used to dynamically populate a weather tile, and interpolations/extrapolations are used in transition zones (or those without any METAR data available).
And still users may want to individually set up custom weather (clouds, winds) at certain positions.


Yes, that is pretty similar to what I had in mind as a structure. The time direction is not so different - I guess METAR gets fetched every 10 minutes (?) or so, so the setting stays as it is after the first METAR, after getting the second gets smoothly blended into the values of the second for the next 10 minutes, by the time you fetch the third you know what to do for the next 10 minutes - so basically there is a 10 minute delay to what happens in reality, which should be ok for all practical purposes. Based on these time-interpolated settings at given positions, spatial interpolation can be used to set up the tile.

And still users may want to individually set up custom weather (clouds, winds) at certain positions.


Yes, it'd be really handy to have generic structures to set rain, snow, turbulence, lift, visibility, wind and clouds in a given volume.

It already has a small section about weather modeling, but adding a new page specifically about weather modeling might actually be a good idea.


Okay, I'll try to set up a Wiki page dedicated to local weather modelling by next week.

For unpowered flight, a high degree of realistic weather simulation is obviously very important and it would probably be a good idea to check each of these out and see if any of the concepts, features or even code (licensing permitting) could be borrowed to improve FlightGear's "weather model".


Actually, after experimenting with Cumulus cloud models, I was wondering for a time if I should set up a dynamic thermal scenario, but decided to went for other cloud types first. But I can sketch the algorithm I came up with:

The static setup part uses a MC algorithm to distribute thermals probabilistically with more emphasis to likely origins:

* specify a radius and a number of thermals/sinks you want to place inside that radius
* choose a random position in this area
-> investigate ground cover and prominence (by comparison with nearby elevation)
-> based on that (and possibly other local factors), determine a likelihood of a thermal updraft originating here
-> modify the likelihood to include global factors like time of day, season, temperature
-> determine based on the likelihood if to place a thermal here
-> if no, get a new random position otherwise
* place a thermal
-> select its strength according to the above likelihood score
-> randomize its radius a bit
-> based on humidity, decide if a cap cloud is placed
* choose a new position for the first sink

A different loop monitors position, removes a thermal from consideration when the distance to the plane gets larger than some number, and places a new random thermal.

A dynamical loop takes care of the evolution. Each thermal gets a lifetime based on wind displacement from the source. The cloud and the thermal gets continuously displaced by the wind (a speed and orientation should become part of the C++ AI system features, as well as the 'leaning' angle) The loop reduces the lifetime each minute and does the following
* young thermals are strong and don't have a cap cloud yet
* as they get older, a cap cloud is formed
* finally there is a mature Cumulus cloud
* then the updraft is weakened
* finally it dies, only the cap cloud is left to drift
* and afterwards the cloud dissolves
* after some time lapse, a new cloud is initialized from the source point

(cloud change can probably be modelled by providing some 3-5 different cloud development stage models being switched on and off using the <type>select</type> animation tag, strength of the updraft can simply be set in the Nasal).

I'm pretty sure these three algorithms can be Nasalized in a short time. For the thermal AI system on the C++ side, adding motion, leaning and some turbulence would be good to improve realism - but if necessary one can move the clouds also in Nasal. Anyway, this is how I would go about doing a Cumulus-system for gliders which knows something of the local environment in terms of likely spots for seeding thermals.
Thorsten
 
Posts: 10587
Joined: Mon Nov 02, 2009 8:33 am

Re: Cirrus sky

Postby statto » Fri Feb 26, 2010 5:45 pm

What if we simulate a voronoi using weather? http://www.grass.itc.it/grass62/manuals ... ronoi.html

Then, instead of using the "closest" metar, the metar defines the area within its own voronoi diagram - so if it's clear in Washington but it's cloudy in Baltimore, as you get closer to the voronoi line between the DC and Baltimore METARS you don't just jump from clear to cloudy, but you can actually "see" the cloudy area ahead of you...

However the boundary should be fairly loose as well, for instance large cirrus clouds don't need to be clipped to the boundaries,

Cheers
John
Custom Scenery available from http://www.stattosoftware.com/flightgear
statto
 
Posts: 2100
Joined: Fri Jan 25, 2008 9:57 pm

Re: Cirrus sky

Postby Thorsten » Fri Feb 26, 2010 6:44 pm

Part of the problem in getting realistic weather is that METAR info isn't complete - for example low overcast sky following a cold front is most likely merged Cumulus clouds, overcast sky following a warm front is probably Stratus or something lower - they look completely different. You need the global picture in order to select the right clouds for the occasion.

In addition - what do you do if no close-by METAR is available (say on a transatlatic flight)? Tiles with placement rules what type of tile can follow each other can still create a realistic impression of fronts and weather systems even without METAR input.

And you'd need to solve essentially the same 'local' problems, like how to tie rain to an area such that you see it from afar, although the definition of volumes for weather effects would be much easier with the voranoi concept - that's going to be tough if tied to irregularly-shaped clouds...
Thorsten
 
Posts: 10587
Joined: Mon Nov 02, 2009 8:33 am

Re: Cirrus sky

Postby MAKG » Fri Feb 26, 2010 6:57 pm

Voronoi diagrams are the "right" way to do nearest-point location on an unstructured grid, but they are expensive and difficult to code properly. You're already doing this implicitly, and you won't gain any benefit by making it explicit. The polygons involved have an arbitrary number of sides.

For interpolation, they don't work well. It's not really what you want. But I'll suggest something related that is much closer -- Delaunay triangulation. It's mathematically equivalent to connecting the center points of each Voronoi polygon to its neighbors. But all the polygons are triangles, and every triangle determines a plane with vertices at the METAR point. That's a very well defined way to do linear interpolation, though it is not equivalent to the more familiar bilinear form. Triangulations are not unique, but Delaunay triangulations are.

I would suggest you also blend a more conventional linear interpolation for time, and perhaps altitude if you have it available. Weather reports are usually stratified in altitude.

There are PD Delaunay implementations on the Web. I have an N-dimensional version I can contribute if you need, but I'll suggest that 2D ones really are substantially simpler. It's a bit over 1500 lines of code, and it's very dense in the mathematics. And it uses templates and
has a few dependencies I can't give you (they won't be hard to excise, though -- mainly constants and vector algebra), not really necessary
for you.

A reference is Guibas, Knuth & Sharir, Algorithmica 7, 381-413 (1992)

If you want it, PM me an e-mail address.

Note that no interpolation scheme can capture discontinuous features such as fronts. For this reason, it will always be unphysical. However, it won't disrupt the autopilots so badly.
MAKG
 
Posts: 1156
Joined: Sun Oct 19, 2008 6:11 pm
Location: California Central Coast

Re: Cirrus sky

Postby Thorsten » Sun Feb 28, 2010 1:03 pm

Okay, I've set up a Wiki page outlining how I think an integrated local weather system could work here - I'll expand that a bit, but feel free to comment, add and discuss in the mean time.
Thorsten
 
Posts: 10587
Joined: Mon Nov 02, 2009 8:33 am

Re: Cirrus sky

Postby Thorsten » Mon Mar 01, 2010 9:32 am

Download link for the cloud model package and info added to first post.
Thorsten
 
Posts: 10587
Joined: Mon Nov 02, 2009 8:33 am

Next

Return to Weather

Who is online

Users browsing this forum: No registered users and 0 guests