Board index FlightGear Development Nasal

Nasal+XML General wxradar Development

Nasal is the scripting language of FlightGear.

Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 7:59 am

From my PM to Hooray

omega95 wrote:Here're some extracts from the Collins WXR-2100, which may be important when we start work on it. We should also discuss how it should be done, like what classes do what, and stuff. And should we use 2D panel transformations or 3D? I'd go with 2D this time because that way, you can easily resize it for use with all aircraft.

Fully Automatic Operation: MultiScan is designed to work in the fully automatic mode. Pilots select only the desired range. Tilt and
gain inputs are not required.


That makes it a whole lot easier for us considering that we already have code for locations of objects at different ranges in the NDs, and like the ground radar instrument, we could just create a property so that users can change the range.

Optimized Weather Detection At All Ranges And Altitudes: Weather data from multiple scans at varying tilt angles is stored in memory. When the flight crew selects a desired range, information from the various scans is extracted from memory and merged on the display. Since both long and short range weather information is available due to the use of multiple tilt angles, the display presentation represents an optimized weather picture regardless of the aircraft altitude or the range scale selected

Wow, what do we do about that?

EDIT : Actually, I did a bit more reading down there... All it means is that the reflectivity at different layers of the thnderstorm are different, so it optimizes it to show it at all tilts. We won't have to worry bout that because, we could simply use a certain altitude range or (dist-to-thunderstorm * tan (max-tilt)) to find the region of altitude we need to scan. And basically, show the part with maximum reflectivity.

About the Weather moving to compensate for aircraft heading and movement, we could simply rotate it along with the hsi arc.

And there're 2 other things we must create along with the wxradar to get functionality - a WXRADAR control panel (I created a Boeing version (specifically 787)) and I'll do some quick animations to get it ready.

The PDF also showed that you have Multiscan but it can also be turned off. I have a Multiscan toggle switch, a manual tilt and master button animated at the moment.

About the other, we need to be able to get the precipitation from local weather, or if better, the combined weather system. (Btw, how come I can't find Local Weather in teh menu in the git I pulled yesterday?)

Right, so I'm getting a good idea of what we can do now... But first, how are the thunderstorms distributed? If there aren't separate thunderstorm property trees, are there atleast different precipitation levels?

And about thunderstorms, pixelation will be REALLY difficult and slow too, so I was thinking we do something like in the old WXRADAR, use textures to show different storms. As it is, I don't think FlightGear creates different shapes for the same kind of thunderstorm. And we could use color codes based on intensity and say different fixed shapes for different types of storms (scattered, nimbus etc.) And then ofcourse scale them based on range and their size.


So, is there anyone *cough* Thorsten who can tell me about different precipitation levels and storm types (single cell, multi-cell and super cell) in FlightGear? Where're their properties stored and what about Turbulence? Does FlightGear have different Turbulence for different parts of the storm? If it doesn't can we work on something like that to make stuff both interesting and real? :wink:

EDIT : And about FlightGear's weather system, looking at the old wxradar code, it looks like thunderstorms are placed like models, but does flightgear have different data for every tile/co-ordinate so we can actually create pixels and color them instead of having a ready-made storm texture?
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 8:10 am

Possible Types of WXRADAR Displays

1. Ready-made thunderstorm textures

I see that this is what's been used in the old WXR, but isn't this a little un-realistic? I mean different clouds can't have the same shape. On the other hand, this is a MUCH easier way to go.

2. Pixelize the WXR

This will be complicated but it's still possible to do it like the VSD. We could have a 'pixel' represent each time and we could have a resolution of upto 50x50 pixels and still not loose frame-rate using the partial load technique Thorsten suggested. The animation won't be too difficult as we could create the file with nasal.

But then this method will only work if FlightGear's Weather system specifies data for each few meters. :|
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 8:57 am

And can I know here the thunderstorm data is stored? I checked /local_weather/tiles/ but each individual tile' code is nil. Also the clouds tree has only their position and orientation. I didn't get much from the weather_tiles.nas file either. :(

So basically, I need to following data for different tiles:
> Position and Orientation (I have that)
> Precipitation Type (high precipitation, med. precipitation, low precipitation, no precipitation)
> Cloud Density
> Size of Tile (or the system there)

Thanks
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 9:54 am

For option number 2,

I've created a radially pixelated display, I could even do the animations but then what's really important is the nasal code and I need those data for it.

Image

There're a 1200 pixels so far and we could load about 5 every frame and sweep through the screen. :D
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby Hooray » Fri Feb 17, 2012 10:07 am

Posting a bunch of updates, i.e. things we talked about, that really belong here:

Hooray wrote:
omega95 wrote:Right, I've created a topic in the Nasal Sub-forum. I also started working on the storm textures, just incase we don't have different data for each co-ordinate.


I think, it could work like this:
- create a set of pixel textures for different reflectivity (i.e. like a handful)
- create a Nasal function that maps LW inputs to these reflectivity textures
- use a range/scale animation to visualize the frequency/density of clouds
- i.e. assemble clouds into groups and come up with a bunch of pixels meant to match the reflectivity

Basically, we would ALWAYS render ~50 "pixel textures", but we would determine dynamically the size, color and orientation (using properties)

Then, we would just need a little Nasal helper functions for controlling each pixel.
Another Nasal function could proccess the LW internals, read out all relevant cloud info, and next scale things to the range selected, so that the ~50 pixels can be animated properly (like: invisible, green, yellow, orange, red).

Like you said, we should probably create the animation code using a Nasal helper script (setprop/write_properties), all we need to get started is a single animation with parameters like
- enable/disable (show/hide)
- lat/lon (centre of position
- range (diameter of the pixel to be rendered)
- transformation (scale,rotate)
- color (i.e. sub animation?)

Once this is working, we could use it create a single pixel.
We can then look into further generalizing things, to come up with a set of 50+ animations, which we could easily address using property indices.

Like you suggested already, it'd make sense to use the HSI animation to rotate the whole map, rather than each individual pixel.

Does that make any sense?


Hooray wrote:
  • not all of the weather info is currently exposed in the property tree, some if it is "internal", i.e. in Nasal variables. Thorsten mentioned already the "create_streak*" wrappers: http://gitorious.org/fg/fgdata/blobs/ma ... s#line2510 We could add some code to each wrapper, to publish additional info using setprop - Thorsten may have some better advice, tho.
  • Yes, I originally meant to have a fixed number of pixels per screen, which would be toggled/customized according to the situation. Sort of like the CDU stuff works, by parameterizing a fixed number of visible elements. Re: Cloud shapes getting imitated, yes - sort of, but another option might be setting textures dynamically based on some different file path (if that's not possible yet, it's trivial to change in the C++ code)
  • The radial layout you mention does sound better than my idea, OTOH my idea is much simpler to get working ... i.e. like a simple prototype. But agreed, modeling it close to the real thing seems like a good idea. I actually thought about partitioning the screen/pixel space into sectors, too. But didn't want to make things too complex in the beginning ;-)
  • Yes, the way real WX images are updated, actually works pretty much like what you describe - i.e. like a radar scan, which doesn't update the whole scene at once. 2400 pixels does sound a lot tho. Have you ever tried something like that before? I would suggest to start working on the Nasal helper script to create those animations automatically, so that we can do a test with 2400 animated properties, to see if that's even feasible (dunno!).
  • Regarding the WXR colors/palette: Let's keep it simple for the moment, adding support for other colors shouldn't be too difficult, i.e. just a matter of changing the animation generator script, right?

Finally, I don't favor a certain way of doing things. But, before we do any real work, let's first talk to Thorsten and see how he'd suggest to proceed here.
The next step, should then probably be coming up with the Nasal helper script to create all those animations using setprop/write_properties. And then, we should probably do a test to see if ~2400 textures isn't causing any problems (performance).

I *assume* that transforming 2400 pixel/properties might be faster using XML animations, rather than separate Nasal calls for each pixel. But I have never done or tested this to be honest :-)

Actually, sounds like a fairly interesting test case !



Hooray wrote:
omega95 wrote:And how exactly do we do that? I'm extremely new to FlightGear's weather systems... but then Thorsten and you aren't :wink: Where're those properties stored?
Or is there a nasal function to get those?


When we previously talked about this, Thorsten suggested modifying the mid level cloud setup routines here:
viewtopic.php?f=30&t=15200&start=15#p149445
Thorsten wrote:Thinking about wxradar, it occurred to me that it doesn't seem too smart to assemble the info from the add-cloud calls. At this point, it's cumbersome and you have no information about the radar echo of the clouds. Rather, the mid-level cloud adding calls (create_8_8_stratus() and company) could write coordinates, extension and reflectivity of the created clouds into the tree, from which any wxradar code could generate a suitably fuzzy image to display. At that point, you'd deal with less than 100 distinct objects, and you can easily fit in the reflectivity because you know what cloud in what circumstances you are currently creating. If anyone wants to work on this, let me know and we can specify an interface. It's comparatively easily done from my end.


So, that's the stuff here: http://gitorious.org/fg/fgdata/blobs/ma ... s#line2510

All of them make use of the same low level call: http://gitorious.org/fg/fgdata/blobs/ma ... s#line2496

So, this function will get called - and has lots of "meta" information as you can see.



omega95 wrote:I'm also thinking of using a gradient and textranslate across it instead of different emissions as a gradient would provide more color ranges without much scripting. That means we could make it look like the edges of the clouds are blended too.


That's even better than my 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: 12260
Joined: Tue Mar 25, 2008 8:40 am

Re: Nasal+XML General wxradar Development

Postby Thorsten » Fri Feb 17, 2012 10:20 am

So, is there anyone *cough* Thorsten who can tell me about different precipitation levels and storm types (single cell, multi-cell and super cell) in FlightGear? Where're their properties stored and what about Turbulence? Does FlightGear have different Turbulence for different parts of the storm? If it doesn't can we work on something like that to make stuff both interesting and real?


That information isn't in the property tree. It exists (in implicit or explicit form) at some point during tile setup in weather_tiles.nas and is partially discarded later.

For instance

Code: Select all
create_thunderstorm_scenario (lat, lon, alt , alpha);


creates a tile with Cb towers and background Cu clouds (it's a separate function, because it's not supposed to draw Cu where Cb towers are, that looks exceedingly silly having bright white Cu clouds just under the storm tower).

That function in turn calls for example

Code: Select all
create_small_thunderstorm = func(lat, lon, alt, alpha);


and at this point you have the storm's position, altitude and size. What that function does is create all the cloudlets which make the storm (but once that's done, the information that the cloudlets represent a storm is discarded, the shader doesn't need to know that, it only knows individual cloud textures and vertices).

The same function also sets the effect volume defining visibility in and underneath the Cb tower, precipitation and turbulence - which can be as detailed as you want to make it (currently it's just constants, but it could be easily replaced by something like the 4-dim model we use for thermals which has full space and time dependence of everything).

So you need to write out everything you want to know about the storm from inside this function. Basically you can have easily

* center position (lat,lon)
* radial extension (m)
* max. altitude
* strength of precipitation (possibly at some altitudes)
* strength of turbulence (possibly at some altitudes)

and anything more would cause extra work.

So what you need to do is design a property tree interface for the wxradar which displays something nice if the properties are set accordingly, my job is to get the information written into the interface.

EDIT : And about FlightGear's weather system, looking at the old wxradar code, it looks like thunderstorms are placed like models, but does flightgear have different data for every tile/co-ordinate so we can actually create pixels and color them instead of having a ready-made storm texture?


Forget about the old thunderstorm models, they're just not competitive :-) and not supported by either Advanced or Basic weather - you have to place them manually.

1. Ready-made thunderstorm textures

I see that this is what's been used in the old WXR, but isn't this a little un-realistic? I mean different clouds can't have the same shape. On the other hand, this is a MUCH easier way to go.


You mean as radar echo? Well, just create 10 blurry of them and represent each storm's radar echo by a random selection of four. We do clouds the same way - we have 20 basic tectures and each cloud is a random selection out of that.

But then this method will only work if FlightGear's Weather system specifies data for each few meters.


If you really like, you can have each cloudlet position dumped to the tree, so then you have some 20.000 pixels to paint onto your screen. That's going to have an abysmal framerate though...

For other cloud types, as for storms, I'd use meta-info, i.e. write the radar echo from within the cloud setup call into an interface, then you don't have to store 1000 cloudlets to draw a layer, but just specify 'I have a layer centered at (lat, lon) at altitude (alt) with x-extension 4 km and y-extension 7 km rotated from the default direction by 30 deg of clouds of reflectivity x' - and draw the radar return based on that.
Thorsten
 
Posts: 12048
Joined: Mon Nov 02, 2009 8:33 am

Re: Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 10:30 am

For other cloud types, as for storms, I'd use meta-info, i.e. write the radar echo from within the cloud setup call into an interface, then you don't have to store 1000 cloudlets to draw a layer, but just specify 'I have a layer centered at (lat, lon) at altitude (alt) with x-extension 4 km and y-extension 7 km rotated from the default direction by 30 deg of clouds of reflectivity x' - and draw the radar return based on that.


Right, but if there's a function to get the precipitation and turbulence (you mentioned these 2 were available) for a co-ordinate we specify, wouldn't that be better, as we can show the actual thunderstorm shape instead of using echos.

And we don't want to really "create" any clouds because the "Advanced Weather" system is doing that really good, we just need to 'get' the 2 factors. Sorta like we 'got' the elevation at a co-ordinate with geoinfo()

The above is for the 'pixels' model of the wxradar, but then with the other available data,

* center position (lat,lon)
* radial extension (m)
* max. altitude
* strength of precipitation (possibly at some altitudes)
* strength of turbulence (possibly at some altitudes)

we could create fake echos.

Which do you suggest?
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 10:34 am

If we're continuing with the 'pixels' method, I have a quick nasal helper to create animations for all 1200 points.

Code: Select all
var location = "/temp/test/";
var filename = getprop("/sim/fg-home") ~ "/Drawing/wxradar-pixel.xml";

var drawline = func() {

   for (var deg = 0; deg < 60; deg += 1)
   {

      for (var dist = 0; dist < 20; dist += 1)
      {

         setprop(location ~ "animation[" ~ ((deg * 20) + dist) ~ "]/type", "textranslate");
         setprop(location~"animation[" ~ ((deg * 20) + dist) ~ "]/object-name", "wxr." ~ (dist + 1) ~ "." ~ (deg + 1));
         setprop(location~"animation[" ~ ((deg * 20) + dist) ~ "]/property", "/instrumentation/wxradar/pixels/deg[" ~ deg ~ "]/dist[" ~ dist ~ "]/reflectivity");
         setprop(location ~ "animation[" ~ ((deg * 20) + dist) ~ "]/factor", 0.92);

      }

   }   

   io.write_properties(filename, location);

}


Uh oh, forgot to add axis as +1 x.. I'll do it and recreate te animation file.
Last edited by omega95 on Fri Feb 17, 2012 10:42 am, edited 1 time in total.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby Thorsten » Fri Feb 17, 2012 10:42 am

Right, but if there's a function to get the precipitation and turbulence (you mentioned these 2 were available) for a co-ordinate we specify, wouldn't that be better, as we can show the actual thunderstorm shape instead of using echos.


Trust me, the actual shape in which precipitation is happening looks very unrealistic - it's either a circle or a rectangle on the radar :-)

Since you can't ever see the turbulence function, it's ok to define it in simple shapes, because that saves a lot of computation time (to determine if you are in or out of a region with arbitrary boundaries is quite a mess). But that means you can't image it.

And we don't want to really "create" any clouds because the "Advanced Weather" system is doing that really good, we just need to 'get' the 2 factors.


Yes, but unlike in the geodinfo() case, the information that a Cb tower is in the scenery only exists at one point in the system. It's like a geodinfo(); call that is supposed to tell you if you're probing above the mean terrain elevation or not. At scenery design time, it's very easy to get that information, but at runtime it's rather expensive to re-assemble it. Same case here - much easier to get what you want at design time than re-assemble it later from cloudlets.

Which do you suggest?


Take the ufo high up, create a really large cloud layer and look at all this from directly above. There's a lot of regularity in there (which you can't see from typical aircraft altitudes) - much more than nature provides. The reason is that cloud placement functions have to be reasonably simple - it doesn't really do to compute a fractal pattern for two minutes or so. At the core of the weather system are many cleverly-chosen illusions.

So I would suggest fake echos - just as we do fake clouds in many cases. Getting a pixel version to look real might take a lot more effort than you think.
Thorsten
 
Posts: 12048
Joined: Mon Nov 02, 2009 8:33 am

Re: Nasal+XML General wxradar Development

Postby Hooray » Fri Feb 17, 2012 10:46 am

Thorsten wrote:If you really like, you can have each cloudlet position dumped to the tree, so then you have some 20.000 pixels to paint onto your screen. That's going to have an abysmal framerate though...


@omega95: At some point, the local weather system made use of so called "quad trees" (spatial data structures, based on Nasal arrays/vectors) to help subdivide and partition the 3D space (and all its clouds) into relevant and less relevant areas. This was for example used to selectively update only stuff that's visible.

While doing something like this, would obviously be an option, it'd make things much more tricky than necessary for a simple prototype.

If you are interested in pursuing this, I could talk to Thorsten in order to come up with a method to generalize his existing Nasal quadtree implementation, so that it could be used for things like the wxradar, probably using a Nasal hash to create a new quad tree class: http://gitorious.org/fg/fgdata/blobs/ma ... as#line393
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: 12260
Joined: Tue Mar 25, 2008 8:40 am

Re: Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 10:48 am

Thorsten wrote in Fri Feb 17, 2012 10:42 am:Take the ufo high up, create a really large cloud layer and look at all this from directly above. There's a lot of regularity in there (which you can't see from typical aircraft altitudes) - much more than nature provides. The reason is that cloud placement functions have to be reasonably simple - it doesn't really do to compute a fractal pattern for two minutes or so. At the core of the weather system are many cleverly-chosen illusions.

So I would suggest fake echos - just as we do fake clouds in many cases. Getting a pixel version to look real might take a lot more effort than you think.


Right, I forgot that the 'realistic' I was talking about was to show FG's weather systems and not like in real life, so I guess fake echos should do it. I've created 4 different echo shapes and have them at 3 different intensity values.

Does FlightGear atleast have single cell/multi cell differences between the storms?
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 10:51 am

Thorsten wrote in Fri Feb 17, 2012 10:42 am:Trust me, the actual shape in which precipitation is happening looks very unrealistic - it's either a circle or a rectangle on the radar :-)


But then at the rate FlightGear's developing, I can expect a realistic system coming up very soon. But nevertheless, we'll stick to the echo type as you said for now and keep the other one on hold. :wink:
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 1:58 pm

I wrote the basic code for the wxradar.

Code: Select all
################################################################################
#
# COLLIN's WXR-2100 "ECHO" MODEL
# ------------------------------
#
# The Weather systems in FlightGear at the time of this wxradar development were
# either circles or rectangles thus making their actual wxradar display unreali-
# tic. The other "PIXELS" model is still available in the Boeing 787-8's 'Devel'
# directory to be used when FlightGear's weather system is further advanced.
#
################################################################################
#
# THUNDERSTORM PROPERTY TREE
# --------------------------
#
# > /instrumentation/wxradar/storm[n]/show
# > /instrumentation/wxradar/storm[n]/latitude-deg
# > /instrumentation/wxradar/storm[n]/longitude-deg
# > /instrumentation/wxradar/storm[n]/heading-deg
# > /instrumentation/wxradar/storm[n]/base-altitude-ft
# > /instrumentation/wxradar/storm[n]/top-altitude-ft
# > /instrumentation/wxradar/storm[n]/radius-nm
# > /instrumentation/wxradar/storm[n]/reflectivity-norm
# > /instrumentation/wxradar/storm[n]/turbulence-norm
# > /instrumentation/wxradar/storm[n]/type
# (single_cell, multi_cell or super_cell)
#
################################################################################

var RAD2DEG = 57.2957795; # Conversion Factor from Radians to Degrees

var wxtree = "/instrumentation/wxradar/";

var sqr = func(n) return n * n;

    var Deflection = func(bug, limit) {
      var heading = getprop("orientation/heading-magnetic-deg");
      var bugDeg = 0;

      while (bug < 0)
       {
       bug += 360;
       }
      while (bug > 360)
       {
       bug -= 360;
       }
      if (bug < limit)
       {
       bug += 360;
       }
      if (heading < limit)
       {
       heading += 360;
       }
      # bug is adjusted normally
      if (math.abs(heading - bug) < limit)
       {
       bugDeg = heading - bug;
       }
      elsif (heading - bug < 0)
       {
       # bug is on the far right
       if (math.abs(heading - bug + 360 >= 180))
        {
        bugDeg = -limit;
        }
       # bug is on the far left
       elsif (math.abs(heading - bug + 360 < 180))
        {
        bugDeg = limit;
        }
       }
      else
       {
       # bug is on the far right
       if (math.abs(heading - bug >= 180))
        {
        bugDeg = -limit;
        }
       # bug is on the far left
       elsif (math.abs(heading - bug < 180))
        {
        bugDeg = limit;
        }
       }

      return bugDeg;
    }

    var wxradar = {
       init : func {
            me.UPDATE_INTERVAL = 0.02;
            me.loopid = 0;
            me.reset();
    },
       update : func {

    var heading = getprop("orientation/heading-magnetic-deg");

   var altitude = getprop("/position/altitude-ft");

    var pos_x = 60 * getprop("/position/latitude-deg");
    var pos_y = 60 * getprop("/position/longitude-deg");

   var multi_scan = getprop(wxtree ~ "multi-scan");
   var tilt_deg = getprop(wxtree ~ "tilt");

   var range_nm = getprop(wxtree ~ "range");

   for (var n = 0; n < 8; n += 1)
   {

      var storm = wxtree ~ "storm[" ~ n "]/";

      if (getprop(storm ~ "latitude-deg") != nil)
      {

         var storm_x = 60 * getprop(storm ~ "longitude-deg");
         var storm_y = 60 * getprop(storm ~ "latitude-deg");

         var bearing_deg = RAD2DEG * math.tan2(storm_x - pos_x, storm_y - pos_y);

         var distance_nm = math.sqrt(sqr(storm_x - pos_x) + sqr(storm_y - pos_y));

         var storm_top = getprop(storm ~ "top-altitude-ft");

         var storm_bottom = getprop(storm ~ "base-altitude-ft");

         var storm_type = getprop(storm ~ "type");
      
         var storm_precip = getprop(storm ~ "precipitation-norm");

         if (multi_scan == 1) # Multi-scan
         {

            var range_alt = distance_nm * (math.sin(15) / math.cos(15));

            if ((storm_top >= -range_alt) and (storm_bottom <= range_alt)) var alt_visible = 1;
            else var alt_visible = 0;

         }
         else # Manual Tilt
         {

            if ((storm_top >= tilt_deg) and (storm_bottom <= tilt_deg)) var alt_visible = 1;
            else var alt_visible = 0;

         }

         if ((Deflection(bearing_deg, 60) != 60) and (Deflection(bearing_deg,60) != -60) and (distance_nm <= range_nm) and (alt_visible == 1))
         {

            setprop(storm ~ "show", 1);
            setprop(storm ~ "deflection-deg", Deflection(bearing_deg, 60));
            setprop(storm ~ "distance-nm", distance_nm);

            var x_textranslate = 0;
            var y_textranslate = 0;

            if (storm_precip >= 0.66) x_textranlate = 2;
            elsif (storm_precip >= 0.33) x_textranslate = 1;

            if (storm_type == "super_cell") y_textranslate = 1;
            elsif (storm_type == "multi_cell") y_textranslate = 2;

            setprop(storm ~ "x_textranslate", x_textranslate);
            setprop(storm ~ "y_textranslate", y_textranslate);

         } else setprop(storm ~ "show", 0);

      }

   }

},
        reset : func {
            me.loopid += 1;
            me._loop_(me.loopid);
        },
        _loop_ : func(id) {
            id == me.loopid or return;
            me.update();
            settimer(func { me._loop_(id); }, me.UPDATE_INTERVAL);
        }

};


setlistener("sim/signals/fdm-initialized", func
 {
 wxradar.init();
 });


The Reflectivity, Radius and Turbulence props will be directly taken from Thorsten's script into the animation.

Function of the above simple wxradar code

    > converts given latitude and longitude position into distance and bearing to be shows on a radial based ND
    > when multi-scan is enabled, checks for storms inside the +15 to -15 tilt range and enables the storm's visibility
    > when multi-scan is disabled, checks for the storm in the manual tilt angle

Thorsten, I'd need the base and top altitudes of the storms too to determine whether the WXR can see it or not. :)

EDIT : Oh and can we have atleast 3 storm types? (single cell, multi cell and super cell) That could be stored in the property "/instrumentation/wxradar/storm[n]/type"
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby omega95 » Fri Feb 17, 2012 3:08 pm

I figured that if we use a 3D model for the wxradar echo mode, the storm system indicator could go out of the screen if it's too big. Therefore, it'd probably be better to use a 2D panel.

I've done most of the required animations for a single cell low precipitation system, but how do I scale it? What is the scale transformation for 2d panel models?

Thanks :)
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1222
Joined: Sat Jul 30, 2011 12:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Nasal+XML General wxradar Development

Postby Thorsten » Fri Feb 17, 2012 4:37 pm

Thorsten, I'd need the base and top altitudes of the storms too to determine whether the WXR can see it or not.


You list looks doable. I can set storm type, but currently we don't have anything other than single cell storms (unfortunately, filling a few cubic kilometers with cloudlets doesn't agree with most GPUs...) - we may get around to model the really big storms eventually though... I might as well spend some time attending to improved storm modelling.

Hopefully I can come up with a first patch before Monday.

Do we have any data to choose reasonable values for the radar reflectivity of various cloud types?
Thorsten
 
Posts: 12048
Joined: Mon Nov 02, 2009 8:33 am

Next

Return to Nasal

Who is online

Users browsing this forum: No registered users and 1 guest