Board index FlightGear Development Weather

A local weather system (v1.4 available)

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

Re: A local weather system (v0.5 available)

Postby WooT » Sat Apr 03, 2010 4:05 pm

I made a little patch to Environment, this makes so that environment reads local-weather/current/thermal-lift each frame, and makes the sum of
ridge lift, thermal-lift ( used by AIThermals ) and local-weather-lift into wind-from-down.

My side it works good, I can set local-weather/current/thermal-lift manually from the nasal console, wind-from-down is changing accordingly, your property is not being reset each frame, and both ridge lift and AITermals are still usable.
On the other hand, it seems your scripts do not output anything about thermals right now.

It is available here : http://www.bentha.net/fgfs/thermal/ther ... t.diff.bz2 , and goes into : src/Environment

I am not sure how to create a binary from CVS with my patch applied for you, or simply if I can do this. I am on a opensuse 11.2 32 bits machine, with quite a lot of custom libraries.
Maybe Hooray would know how to do this ?
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: A local weather system (v0.5 available)

Postby Thorsten » Sat Apr 03, 2010 6:18 pm

I guess I forgot to initialize the local-weather/current/thermal-lift property, therefore it doesn't appear. It should be set as soon as an effect volume with lift is defined - but right now none of the tiles does that. I'll look into it tomorrow and create a demo in which a constant volume of lift is set underneath strong Cumulus clouds - it's no big deal, just a few more lines Nasal and a bit testing :-)

In principle you can set sink in rain areas, or model the airflow in and out of a thunderstorm in detail - in practice, I haven't really thought about how the air currents actually are, but certainly to be realistic is must be tied to wind, and I haven't really touched that yet.

Then, when clearing the tile, or changing to a non rainy situation, the precipitations remain, and I didn't find a way to stop them.


The switching on problem of the rain occurs for me as well, that's the core Flightgear (I have it also when selecting rain from menu without local weather), but it should switch off if you go above the clouds. I had the bug that it remained on yesterday when I left the effect volume, and I thought I had tracked it down - I'm not sure if that's what you're seeing though.

Probably it doesn't switch off automatically when selecting a new non-rainy tile - I know that 'clear all' wouldn't switch it off, so if the new tile doesn't explicitly write 'rain-norm = 0' it would remain on - the standard rain/snow slider in the menu should do the trick then. Okay, I guess I can fix that by setting it in 'clear-all'.

Please feel free to improve the textures - I'm not going to tinker with those soon!
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v0.5 available)

Postby WooT » Sun Apr 04, 2010 1:43 am

I took some screenies to show how beautiful your fair weather looks above mountains :)
see viewtopic.php?f=19&t=7555&start=0&st=0&sk=t&sd=a
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: A local weather system (v0.51 available)

Postby Thorsten » Sun Apr 04, 2010 9:15 am

So - new package with support for gliders - I checked that local-weather/current/thermal-lift is initialized appropriately and is set below clouds - now it's beyond me... I included a 'Glider's sky' weather tile in which a reduced number of Cumulus clouds with lift is generated (in 'Fair weather', no lift is generated at present, i.e. before the performance impcat is clear). Some amount of lift is always associated with large clouds, none with small ones (I am unsure about performance having 900+ effect volumes in the loop, so I wanted to start out with smaller numbers, hence reduced overall cloud number and no volumes with small clouds).

You can modify the properties of thermals yourself (sorry, at the moment they are just areas of constant lift...). The essential code is in Nasal/local_weather.nas:

Code: Select all
# now see if we need to create a thermal - first check the flag
      if (getprop(lw~"tmp/generate-thermal-lift-flag") == 1)
         {
         # now check if convection is strong
         if (place_lift_flag == 1)
         {
      var lift = 1.0 + 20.0 * p *  rand();
      var radius = 300 + 300 * rand();
      create_effect_volume(1, lat, lon, radius, radius, 0.0, 0.0, balt+500.0, -1, -1, -1, -1, lift, 1);
            
            } # end if place_lift_flag      
         } # end if generate-thermal-lift-flag



Basically, if local-weather/tmp/generate-thermal-lift-flag is set to 1, thermal lift effect volumes are automatically generated with clouds whenever the convective system is called. place_lift_flag is 1 if the cloud is large. lift and radius are the properties of the thermal - you can alter the numbers to suit your needs - I won't GUI that, since we plan to replace the constant lift with a more sophisticated thermal model anyway. The lift extends 500 ft into the cloud - so be careful 8)


In addition, v0.51 has

* a bugfix for problems with overlapping effect volumes
* a fix to switch rain and snow off when 'Clear all' is called

I'm actually amazed that the clouds look so well in the Innsbruck area - I did not have too high hopes for mountain terrain...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v0.51 available)

Postby HHS » Sun Apr 04, 2010 2:08 pm

I tried it today and I must say I'm very impressed by so much work done!

But I have and had some issues with perfomance. Not sure because I use FGFS CVS win32.exe by Fred from 03/28/2010(Though there wasn't any changes which could explain that):

Just using "Local Weather" and defining some values like Convective System freezes FGFS.
I get an error message: nil used in numeric context local_weather.nas, line 967 called from local_weather.nas, line 1141, called from gui/bindings[31] line 1

Using "Local Weather Tile" gave me first a lot of stutterings, but then I found out that I have to disable "Real weather fetch". Now there are only some small stutterings: every two seconds FGFS hangs for a very short time. Maybe the limit of Nasal is just reached... ?

Nethertheless: this work is really promising, and I hope that we see this in near future in FGFS!
I really love to see thermals on my flights, not only in glider which would make FGFS more realistic!
Up, up and away
User avatar
HHS
 
Posts: 3625
Joined: Thu Jul 19, 2007 9:09 am
Version: GIT

Re: A local weather system (v0.51 available)

Postby WooT » Sun Apr 04, 2010 2:08 pm

IT WORKS ! :mrgreen:

It works very well, even :)

Frame rate keeps very good ( I have 70-80 fps here, in a flat country place ) . I don't see any performance hit with the numbers you tuned the 'glider's sky' with.
I will try to increase the tile size, and see how well it behaves.
The cloud spacing is great, and looks like a nice summer average situation. Excellent !

The thermal needs refinement, of course, but one can already have circuits within the limits of the tile.

Maybe something that needs refinement too, is the way the closest cumulus are drawn / rotated. When spiraling under the cloud, it rotates in a way that would make one dizzy quickly !
But this is really detail now, because as of April the 4th, Flightgear turned into a soaring capable simulator ! Thank you VERY MUCH for this ( hum, not sure if I should say thank you when I imagine the time I'll spend playing in this now :P )

Image

( as a note for readers, you need the patch I posted here : viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=45#p72606 , in addition to Thorsten's work , in order to have the thermals working )
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: A local weather system (v0.51 available)

Postby HHS » Sun Apr 04, 2010 2:24 pm

WooT wrote:But this is really detail now, because as of April the 4th, Flightgear turned into a soaring capable simulator ! Thank you VERY MUCH for this ( hum, not sure if I should say thank you when I imagine the time I'll spend playing in this now :P )


( as a note for readers, you need the patch I posted here : viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=45#p72606 , in addition to Thorsten's work , in order to have the thermals working )


I thought he included it in the last package? (Edit: no, because it is not nasal....)
Well, the picture looks great, and I hope for including all the stuff into FGFS! :D
Last edited by HHS on Sun Apr 04, 2010 3:44 pm, edited 1 time in total.
Up, up and away
User avatar
HHS
 
Posts: 3625
Joined: Thu Jul 19, 2007 9:09 am
Version: GIT

Re: A local weather system (v0.51 available)

Postby Thorsten » Sun Apr 04, 2010 2:30 pm

@HHS:

Just using "Local Weather" and defining some values like Convective System freezes FGFS.
I get an error message: nil used in numeric context local_weather.nas, line 967 called from local_weather.nas, line 1141, called from gui/bindings[31] line 1


The freeze for a certain period of time is (sort of) normal - the setup calls are all done in a single frame - which may take forever to execute. In tests, I had times ~minute freeze to set up 500 barrier clouds in a tricky situation. I'll soonish work on moving these calls to worker threads outside the simulation frames, I believe this will solve the freeze problem.

As for the error - can you give me details what you did? Line 967 would place a rain model within a layer call, but that wouldn't be executed from the convective system. It has the potential to cause the error if you ask for a cloud of which the size is not in the hash map - I have to fix that - but it should not be executed when using the convective system.

Now there are only some small stutterings: every two seconds FGFS hangs for a very short time. Maybe the limit of Nasal is just reached... ?


Hm, I have the effect volume loop timed to run every second and the interpolation loop every 3 seconds, so there is nothing which could have a 2 second period... I have seen the Nasal loops causing a brief delay every interval with the characteristic frequency of their timing - but these loops had vastly higher workload (trigonometry for 500 clouds). So if it's really two seconds, I simply don't know, and I don't see it on my system.

If you want to check, set local-weather/effect-loop-flag and local-weather/interpolation-loop-flag both to zero (that should stop the loops) and see if the problem disappears.

I can readily imagine that the infight between the interpolation and real-weather-fetch who gets to set the weather causes performance issues...

@WooT:
Maybe something that needs refinement too, is the way the closest cumulus are drawn / rotated. When spiraling under the cloud, it rotates in a way that would make one dizzy quickly !


I hadn't thought about that... :? Of course when soaring, you'd see the clouds from where the trafo breaks down quite frequently... You'd get the same problem with the standard 3d clouds (same trafo). The problem is, one cannot simply 'freeze' the cloud beyond some distance, because the shader doesn't really rotate the model, just its appearance, so if you stop the trafo beyond a distance, the model just snaps back to a default state. I have to think about this a while, I don't see a quick fix.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v0.51 available)

Postby WooT » Sun Apr 04, 2010 3:20 pm

WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: A local weather system (v0.51 available)

Postby HHS » Sun Apr 04, 2010 4:01 pm

Thorsten wrote:The freeze for a certain period of time is (sort of) normal - the setup calls are all done in a single frame - which may take forever to execute. In tests, I had times ~minute freeze to set up 500 barrier clouds in a tricky situation. I'll soonish work on moving these calls to worker threads outside the simulation frames, I believe this will solve the freeze problem.

Fine to hear! The freezing problem depends on the number of landclasses- detailed sceneries like Custom Scenery LOWI produces longer freezes.

As for the error - can you give me details what you did? Line 967 would place a rain model within a layer call, but that wouldn't be executed from the convective system. It has the potential to cause the error if you ask for a cloud of which the size is not in the hash map - I have to fix that - but it should not be executed when using the convective system.

Yes, you are right, it was when I selected a Rain model. I should have been clearer.

Hm, I have the effect volume loop timed to run every second and the interpolation loop every 3 seconds, so there is nothing which could have a 2 second period... I have seen the Nasal loops causing a brief delay every interval with the characteristic frequency of their timing - but these loops had vastly higher workload (trigonometry for 500 clouds). So if it's really two seconds, I simply don't know, and I don't see it on my system.

If you want to check, set local-weather/effect-loop-flag and local-weather/interpolation-loop-flag both to zero (that should stop the loops) and see if the problem disappears.

I can readily imagine that the infight between the interpolation and real-weather-fetch who gets to set the weather causes performance issues...

Yep, exactly 3 seconds. Stops when setting those two flags to zero.


I hadn't thought about that... :? Of course when soaring, you'd see the clouds from where the trafo breaks down quite frequently... You'd get the same problem with the standard 3d clouds (same trafo). The problem is, one cannot simply 'freeze' the cloud beyond some distance, because the shader doesn't really rotate the model, just its appearance, so if you stop the trafo beyond a distance, the model just snaps back to a default state. I have to think about this a while, I don't see a quick fix.


It seems that your cloud sprites for a single cloud is set on exactly one position. The standard 3d-clouds sets the sprites at different points of a single cloud so it is looking like a solid, thick cloud and the phenomen isn't visible like that.

Unfortunately I have no thermals as beeing a non-compiler of FGFS, but will wait when all this stuff hopefully will be included into FGFS! :D
Up, up and away
User avatar
HHS
 
Posts: 3625
Joined: Thu Jul 19, 2007 9:09 am
Version: GIT

Re: A local weather system (v0.51 available)

Postby Thorsten » Sun Apr 04, 2010 4:14 pm

And some greetings from the Caribbean... It's quite nice to see the scenery slowly from the ASK-13 - I usually blast through with jets...

Image

(No, I can't run the patch... I simply cheated. I started an AI containing a single thermal and wrote a few Nasal lines to copy the thermal into the right position whenever I enter an effect volume... It's a bit rough because the onset of lift is quite sudden, but does fine just for testing if the cloud spacing allows flying...).

Don't bother too much with increasing tile size - probably the first thing I will work on next is a 'repeat tile for infinity' function.


@HHS: Insert

Code: Select all
cNode.getNode("thermal-lift").setValue(lift);
   # some cheat code
   setLift(ev.getNode("position/latitude-deg").getValue(),ev.getNode("position/longitude-deg").getValue(),0);


into effect_volume_stop (the first line is already present and tells you where)

Code: Select all
cNode.getNode("thermal-lift").setValue(lift);
   setLift(ev.getNode("position/latitude-deg").getValue(),ev.getNode("position/longitude-deg").getValue(),1);


into effect_volume_start and

Code: Select all
####################################
# set thermal lift to given value
####################################

var setLift = func (lat, lon, flag) {

# this is a cheat - if you have an AI thermal present, this sets its coordinates to the
# current position

if (flag==1)
   {   
   setprop("ai/models/thermal/position/latitude-deg",lat);
   setprop("ai/models/thermal/position/longitude-deg",lon);
   }
else   
   {
   setprop("ai/models/thermal/position/latitude-deg",0.1);
   setprop("ai/models/thermal/position/longitude-deg",0.1);

   }

#setprop("environment/thermal-lift",L);
}


somewhere into the file, start an AI thermal with the run, and you should be on your way without compiling.

It seems that your cloud sprites for a single cloud is set on exactly one position. The standard 3d-clouds sets the sprites at different points of a single cloud so it is looking like a solid, thick cloud and the phenomen isn't visible like that.


Set standard clouds, use the UFo to get above them, look down 90 degrees, enjoy. They turn allright...

The difference is that all sprites in my clouds rotate around the center of the model, the 3d cloud sprites rotate each around their own center of gravity (I think) - which looks admittedly better, but has also some disadvantages - uses more CPU time and doesn't really do large-scale cloud structure so well as projecting whole photographs in a layer. I could in principle do the same by placing plenty of cloudlets into pre-defined volumes (I wanted to test that at some point), but maybe Stuart will make his clouds placeable into a given position - then we could simply use them from the system.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v0.51 available)

Postby Thorsten » Sun Apr 04, 2010 4:39 pm

After some thinking - the delay every 3 second is probably not the Nasal loop itself but rather the environment reset calls which it generates. These are in essence workarounds to pass changing weather parameters to the environment subsystem and I'm hoping for some proper solution to set them from the Nasal code to be made available by a C++ developer (see the feature request list on the Wiki...).

For the time being, just switch the interpolation loop off if performance is bad, it doesn't do much so far, it's more important for the future long-range functionality.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v0.51 available)

Postby WooT » Mon Apr 05, 2010 2:34 pm

I could in principle do the same by placing plenty of cloudlets into pre-defined volumes (I wanted to test that at some point), but maybe Stuart will make his clouds placeable into a given position - then we could simply use them from the system.


I think this approach sounds really good, for 2 reasons. First I think the current 3D clouds look better, under many angles. Then the cloudlets-into-volumes way would allow to animate the cloud nicely and smoothly, depending on its development phase, without switching from a texture to another.

I'm trying not to harm you when writing this, I'm the first to find your work absolutely amazing, but I have to confess that in its current state, the visual rendering lacks polishing.
On the other hand, I think one must balance the visual aspect with the strength of the inner concepts you are developing, and consider that for a prototyping platfrom, your visual system is more than satisfying.

I hope stuart and other skilled people would read this and see the potential that exists, so that this all could be tied together into something at production level, and reach the FG core at some point.
WooT
 
Posts: 92
Joined: Tue Mar 17, 2009 5:09 pm

Re: A local weather system (v0.51 available)

Postby Torsten » Mon Apr 05, 2010 5:26 pm

Thorsten wrote:After some thinking - the delay every 3 second is probably not the Nasal loop itself but rather the environment reset calls which it generates. These are in essence workarounds to pass changing weather parameters to the environment subsystem and I'm hoping for some proper solution to set them from the Nasal code to be made available by a C++ developer (see the feature request list on the Wiki...).

For the time being, just switch the interpolation loop off if performance is bad, it doesn't do much so far, it's more important for the future long-range functionality.

The reinit of the environment is expensive, so if you don't want/need the interpolation environment controller, it's definitely better to create an new one.
Would you want to set visibility, wind direction, windspeed, turbulence, thermal lift, pressure, temperature and humidity at altitude of the aircraft or on ground and compute the values based on standard atmosphere?
It should be fairly easy to create an environment controller that listens for the formentioned properties set by external nasal scripts and computes the remaining environment parameters. Just tell me, what you need and I'll try to work it in.

Torsten
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: A local weather system (v0.51 available)

Postby Thorsten » Mon Apr 05, 2010 6:26 pm

@WooT:

No offence taken... I'm the first to admit I can't match the standard 3d clouds in realism... yet.

But it's not quite so simple, there are a number of things to consider. First, real developed Cumulus clouds look different in the uper and lower part - the standard 3d clouds don't, because they use the same cloudlets everywhere, so they look always like developing clouds. Apart from the trafo problem (which *is* annoying when you're soaring), seen from a bit afar, I like some of my clouds actually better (some others clearly need reworked textures...). To get that right in multi-cloudlet clouds, you'd need placement rules which type of texture gets where in the volume. Definitely doable, but needs fine-tuning and work.

The second problem is more severe - it boils down to numbers. The shaders can do a few thousand of my clouds. Say it works fine with 4000 Altocumuli, that's 32.000 vertices as one Altocumulus model has 8 vertices. If I use 20 cloudlets per cloud instead of two, 32.000 vertices buy me 400 clouds only.

Not a big problem for soaring - but you can't build Cumulus congestus or Stratocumulus from that any more - if I were to try that with Stuart's clouds, Flightgear would freeze. Now - say I want to support 30 km visibility, and happen to be on the corner of a tile - means I have to be able to maintain 4 tiles at once, two of which I can see at any given time - suddenly 4000 is not such a large number any more, and 400 is a very small number. And unless you fly circles below clouds (no one except glider pilots does that) the trafo is not a big issue.

So maybe we get multi-cloudlet models for soaring only and keep that a bit separate from the normal tile system and model library...

Btw - the development and fading is not a problem - you can use the shader to adjust alpha such that the clouds fade in from the center - hat probably looks good enough for a well-designed model and doesn't need multiple cloudlets.

@Torsten:

Thanks for your offer!

I guess pressure, temperature and humidity should be specified at the ground, and the atmosphere computed as a function of altitude from these (is that sufficient info?) - condensation level could be computed from those - that would help placing cloud layers automatically.

I guess for wind and turbulence it makes little sense to interpolate their high-altitude values from something like a METAR, so I'd compute them from a wind model inside the tile (in some situations, say a thunderstorm, the wind would be very different from the ground value) and would like to set them locally wherever the aircraft is.

I think visibility should be likewise be set wherever the aircraft is, and the tile visibility model specifies how it looks as a function of position and altitude.

Thermal lift seems to be solved nicely be WooT (see the script above) - I haven't tested it myself. If you could look into the others, I think that would be very helpful!
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Weather

Who is online

Users browsing this forum: No registered users and 4 guests