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 (v1.02 available)

Postby someguy » Sat Apr 16, 2011 5:02 am

I just flew in METAR from CYPS in Gral's new FGX git package for Mac, after updating local weather to 1.02. It was raining, of course. :) Wow, the new code is really nice. Performance was quite good (15-30 fps) with everything enabled, considerably better than v1.0. The new overcast is much improved visually, and while cloud-terrain interaction isn't perfect, it's much more realistic. Nice work, Thorsten!

When it's time to clean up the edges of the cloud textures, I might be able to help.
User avatar
someguy
 
Posts: 1650
Joined: Tue Nov 25, 2008 6:54 am
Location: USA
Version: 2019.1.1
OS: Mac OS X 10.11.6

Re: A local weather system (v1.02 available)

Postby Thorsten » Sun Apr 17, 2011 11:45 am

@yoyo:

I've got a question though. When flying close to a cloud and rotating the camera, sometimes the cloud disappears from view when it's close to the edge of the screen. Is that due to the way clouds are rendered?


Good observation... Quoting my explanation on the devel list:

Clouds are 2d sheets placed into the scenery with a true orientation,
then the shader matrix magic grabs them and rotates them into an apparent
orientation. However, generically a sheet can be outside the view when
unrotated but in view when rotated while the shader acts (and rotates)
only when the object in its true orientation is inside the field of view.
Thus, for relatively large cloudlets and in directional corridors, it can
happen that an object would be in view, but isn't actually shown, i.e. a
cloud suddenly vanishes at the edge because the true position of the
vertices is no longer in the field of view, although the apparent still
would be.

There are a few solutions inside Local Weather to lessen the problem, e.g.
using smaller cloudlets at the expense of performance, down-scaling of
models in the shader so that the true model is much larger and more likely
to be in view than the apparent model. A clean overall solution would
involve applying the shader to objects slightly ouside the view. I suspect
that effect is also there for the default 3d clouds, although less
pronounced since they use on average smaller cloudlets.


@someguy:

When it's time to clean up the edges of the cloud textures, I might be able to help.


The status is... murky. i4dnf has to my knowledge finished part of the work of texture cleaning, splitting in different sheets and converting to dds format with the aim of getting better performance. I don't know what the status of the work is. Stuart on the other hand is working to expose the current 3d cloud machinery to Nasal - which would require that the cloud pics are arranged in regular m times n matrices on the texture sheet.

Textures need to be reorganized (there are a few completely unused pics on the sheets, for some the opacity needs to increased, edges need to be cleared) - yet it is likely that any work done now will at least partially be lost. I'm unsure if it would be a good idea to get into this right now - but perhaps the easiest way is to contact i4dnf to see what is already done and to avoid double work. I believe at least until Stuart's system is available, there will be a time in which split dds textures may give some performance edge, even if we may want to merge them into larger sheets later on.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v1.02 available)

Postby Thorsten » Tue Apr 19, 2011 1:20 pm

Currently in the works:

* [GIT] The model for thermals got permission to write visibility as well - now the view deteriorates as one approaches the base of the cap cloud not only because the textures block the view, but because the visibility is explicitly limited. I inserted that because I felt that I shouldn't get away with squeezing another 100 m out of a thermal by entering the cloud so easily. I'm not completely happy with the visibility, as this is engineered to simulate ground haze, i.e. it keeps blue sky while hiding terrain as the visibility deteriorates which isn't overly realistic for a cloud, but combined with the textures it looks sort of okay. Now I have to insert a flag to prevent this from happening in a blue thermal.... not that anyone has ever reported of using those, but just in case. Also, the model doesn't blank visibility in the whole cloud, just inside the termal. Which is okay for soaring, as you can't possibly rise above the thermal, but may not give the expected effect for powered flight. Well, not that I'd know anyone who habitually uses termals in powered flight. 8/8 layers now also have some effect volume reducing visibility while in the layer - it looks a bit better I think.

* I found a way to make the Monte carlo code for placing Cumulus clouds a factor 2 more effective by rescaling the placement probabilities. This is currently the single most performance-killing subsystem on tile setup since it uses a lot of expensive geodinfo() calls. Now it can live well with half the number of calls per frame, which significantly reduces the drop in framerate. I've also thought that it'd be nice to have a transition to cloud alleys for stronger winds, so maybe the system will in the future place the activity according to three categories: 1) convective clouds dependent on terrain 2) blue thermals dependent on terrain and 3) cloud alleys where the precise mixture will depend on the weather conditions.

* I have experienced that on arrival the winds were not as the METAR at the destination reported. I have since tested extensively with the ufo hopping between San Francisco, Oakland and San Diego while printing all the interpolation info to the console, and here the system behaved correctly as expected. I have the vague suspicion that the altitude wind model might introduce some problems, and I'll try to check that - but I might just have seen a fluke or made a mistake myself.

* I'm not really too happy with the low pressure border cloud scenarios, and I'll probably rework them a bit to be more aesthetically pleasing...

Otherwise, for me the system performs fast and reliable. On the devel list, memory problems related to compiling with CACHE_ALL have been reported but I've not seen anything like that - for me it just works amazingly fast.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v1.02 available)

Postby ot-666 » Tue Apr 19, 2011 7:58 pm

Hi Thorsten

Absolutely love your local weather.
It is actually faster (besides much nicer looking) then the original (on a week old git 64bit).
Never had any problems with it. Depending on cloud cover the original clouds drop my system sometimes to 12 – 15 fps and with your system I never had any fps problems.
Testing the CACH_ALL option is not possible for me since I run windows and lack the knowledge to compile myself. Looking forward to a pimped low pressure cloud boarder system.

Many thanks for all that work.
Callsign: ot-666
Working on LOWI and other stuff - Custom Scenery Overlay Repo: http://gitorious.org/fgfs-custom-scenery/custom-scenery-overlay/
VMX22 - Osprey... sometimes in 2014
ot-666
 
Posts: 746
Joined: Sun Nov 08, 2009 6:14 pm
Location: Germany, Konstanz
Callsign: ot-666
IRC name: ot666
Version: GIT
OS: win7 64bit

Re: A local weather system (v1.02 available)

Postby truthsolo » Tue Apr 19, 2011 10:19 pm

Isn't CACHE_ALL now on by default in all builds? A recent fgdata showed this in options.xml, so I pulled new binaries from Hudson. I've noticed that Local Weather is much faster than it was a month ago, so kudos for that!

It would be nice to have an option to always use Local Weather Tiles with METAR on program load.. just my 2-lazy-to-click-the-menu-cents.
Rob — IRC: truthsolo — I used to run mpserver16.flightgear.org (Kansas City, MO)
Good hunting!
truthsolo
 
Posts: 234
Joined: Sat Feb 12, 2011 3:41 am
Callsign: C-FBAR, Snapper
IRC name: truthsolo
Version: git

Re: A local weather system (v1.02 available)

Postby Sealbhach » Tue Apr 19, 2011 10:22 pm

truthsolo wrote in Tue Apr 19, 2011 10:19 pm:It would be nice to have an option to always use Local Weather Tiles with METAR on program load.. just my 2-lazy-to-click-the-menu-cents.


I was thinking the same thing, it would be great if it was optional.

.
Sealbhach
 
Posts: 934
Joined: Wed Jun 30, 2010 10:17 am

Re: A local weather system (v1.02 available)

Postby Thorsten » Wed Apr 20, 2011 8:04 am

Isn't CACHE_ALL now on by default in all builds?


It may be - I don't pull and compile every day, but only once per month or so since I find GIT somewhat complicated to use... I also don't monitor commit logs, so I only have a vague idea what is in brand new builds.

If it's much faster, then probably the CACHE_ALL is on - I've estimated that this should give a factor 100 or so speedup for the specific task of loading clouds into the scenery. I've been comparing the performance with my 2.0.0 binary, and the difference is staggering...

It would be nice to have an option to always use Local Weather Tiles with METAR on program load.. just my 2-lazy-to-click-the-menu-cents.


It's not the default because I can't really assume that people have the internet always on (I certainly don't...). I guess the clean solution would be to get this into preferences.xml, unfortunately I have no real idea how to parse xml files (maybe it's just trivial?) - but if you're going to edit something, you might as well edit the default options in the Nasal code:

In local_weather.nas, fairly at the bottom of the file where the default menu options are set there is the line

setprop(lw~"tmp/tile-management", "realistic weather");

and if you replace that by

setprop(lw~"tmp/tile-management", "METAR");

you have METAR mode on by default. While you're on it, you may also want to change

setprop(lw~"config/wind-model","constant");

to your favoured wind model ("aloft waypoints" should be best with METAR).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v1.02 available)

Postby i4dnf » Wed Apr 20, 2011 9:28 am

My guess is it just needs a separate section in preferences.xml, in which those properties have userarchive="y". For example for one of the settings in the local weather config dialog:
Code: Select all
<PropertyList>

....lots of settings here.....

  <local-weather>
    <config>
      <asymmetric-buffering-flag type="double" userarchive="y">0</asymmetric-buffering-flag>
    <config>
  </local-weather>

.....other settings here....

</PropertyList>

BTW: Shouldn't this be a bool and not a double, also there are a couple of other settings that seem better as "int" and not double (for example the angle).

Also as a cleaner solution, the local-weather default configuration could be loaded from a separate xml:
Code: Select all
<PropertyList>

....lots of settings here....

  <local-weather include="Environment/local-weather-config.xml"/>

.....more settings here....

</PropertyList>

and the Environment/local-weather-config.xml would look like this:
Code: Select all
<PropertyList>
  <config>
    <asymmetric-buffering-flag type="double" userarchive="y">0</asymmetric-buffering-flag>
  </config>
</PropertyList>


At least saving the property works right now. Not visible in sim, probably because you reset those values at runtime.

On another note, I'm about half way through the re-texturing effort. Unfortunately, things will halt until June, as I'll be on a trip for the whole month of May.
i4dnf
Retired
 
Posts: 743
Joined: Wed Sep 09, 2009 8:17 am
Location: LRBS
Callsign: YR-I4D
Version: GIT
OS: Gentoo Linux ~amd64

Re: A local weather system (v1.02 available)

Postby Thorsten » Wed Apr 20, 2011 9:47 am

Thanks, that looks straightforward enough... so I guess I'll transfer the defaults to an xml file then.

BTW: Shouldn't this be a bool and not a double, also there are a couple of other settings that seem better as "int" and not double (for example the angle).


setprop(); makes it a double - you can't specify what type you'd like to write when using it. I'd be fine with a bool, but I'm not invoking props.globals.getNode().setBoolValue(); which would make it a bool for the purpose because that's like 5 times slower.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v1.02 available)

Postby AndersG » Wed Apr 20, 2011 9:53 am

Thorsten wrote in Wed Apr 20, 2011 9:47 am:setprop(); makes it a double - you can't specify what type you'd like to write when using it. I'd be fine with a bool, but I'm not invoking props.globals.getNode().setBoolValue(); which would make it a bool for the purpose because that's like 5 times slower.


If you create it as a boolean property in the XML file it will remain a boolean property.
In Nasal you could use initNode() to create the property with a specified type.

/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: 2524
Joined: Wed Nov 29, 2006 10:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: A local weather system (v1.02 available)

Postby Thorsten » Thu Apr 21, 2011 9:59 am

I've started reading in a config file from preferences.xml as i4dnf suggested, and it seems to work quite nicely - having the system remember your favourite settings indeed is very useful. So - I'll convert the whole default property initialization to xml and make the result available when I'm ready.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v1.02 available)

Postby Thorsten » Fri Apr 22, 2011 2:32 pm

The redesigned low pressure border is no longer a jumble of various 4/8 layers I could dream up but has a clear topic - convective clouds which either merge into vast layers of Stratocumulus or dissolve into less defined layered clouds or are overshadowed by developing higher layers. The result looks rather nice, but unfortunately the Stratocumulus fields drain a lot of performance, so they do not really reach a realistic coverage :-(

I'll maybe stretch the spacing between cloudlets a bit, maybe one can squeeze out another 10% or so.

Image

Image
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: A local weather system (v1.02 available)

Postby ot-666 » Fri Apr 22, 2011 3:25 pm

The outcome looks still very impressive. :)
Callsign: ot-666
Working on LOWI and other stuff - Custom Scenery Overlay Repo: http://gitorious.org/fgfs-custom-scenery/custom-scenery-overlay/
VMX22 - Osprey... sometimes in 2014
ot-666
 
Posts: 746
Joined: Sun Nov 08, 2009 6:14 pm
Location: Germany, Konstanz
Callsign: ot-666
IRC name: ot666
Version: GIT
OS: win7 64bit

Re: A local weather system (v1.02 available)

Postby VaLeo » Fri Apr 22, 2011 5:54 pm

First screenshot is great!

But, where is left wing and right flap?!
VaLeo
 
Posts: 186
Joined: Wed Nov 29, 2006 11:00 am
Location: Ukraine, Dnipropetrovsk
Version: GIT
OS: Debian 7

Re: A local weather system (v1.02 available)

Postby Zan » Sat Apr 23, 2011 11:01 am

Thorsten, I have a quick question which is not so much related to local weather, but you might have an idea.

I once made a contrail script that uses humidity and temperature to simulate different types of contrail, but problem was that FG's environmental model gives always 100% RH at high altitudes. I remember you had some kind of contrail thing, so do you have any ideas on how to estimate the real humidity on high altitudes?

Zan
Zan
 
Posts: 123
Joined: Tue Oct 20, 2009 11:28 am

PreviousNext

Return to Weather

Who is online

Users browsing this forum: No registered users and 3 guests