Board index FlightGear Development Canvas

Instruments with height maps ?

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: Changelog & Progress

Postby mr_no » Sat Aug 04, 2012 2:37 pm

How far is this from being able to create an instrument with a height map?
Mosquito-XE JT-5B-autogyro Extra-300s STOL-Ch701
User avatar
mr_no
 
Posts: 360
Joined: Thu Jan 19, 2012 3:20 pm

Instruments with height maps ?

Postby Hooray » Sat Aug 04, 2012 4:29 pm

mr_no wrote in Sat Aug 04, 2012 2:37 pm:How far is this from being able to create an instrument with a height map?


You mean an artificial 3D terrain view? Like this:
Image

As was said previously, that's a separate project, and requires certain modifications that are currently not a priority: http://wiki.flightgear.org/Canvas_Maps#Moving_Maps
http://wiki.flightgear.org/Howto:Use_a_ ... Instrument

That being said, the Canvas system remains the most accessible system to create such a display in scripting space, even without explicit support for this.

At the moment, the canvas system doesn't yet have support for static textures - once that is added, it would definitely be possible to also support the GeoTIFF format, so that textures could be mapped to a 3D view - which would be easier to implement than a full FG camera view.

Now, it might be possible to accomplish some of this by linking the Canvas system to the Effects/Shader framework, currently these are completely separate though.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Changelog & Progress

Postby mr_no » Sat Aug 04, 2012 6:24 pm

I don't actually need land class just the height.
So I was thinking of plotting (point by point) a very approximate height map, view from above like this.
Is this possible only through nasal TODAY?
Image
Mosquito-XE JT-5B-autogyro Extra-300s STOL-Ch701
User avatar
mr_no
 
Posts: 360
Joined: Thu Jan 19, 2012 3:20 pm

Re: Changelog & Progress

Postby omega95 » Sat Aug 04, 2012 6:43 pm

mr_no wrote in Sat Aug 04, 2012 6:24 pm:I don't actually need land class just the height.
So I was thinking of plotting (point by point) a very approximate height map, view from above like this.
Is this possible only through nasal TODAY?
Image


I've already achieved something like that with only a simple nasal script and xml on the 787-8, A320neo, A330-200 series and A330-300 series. :)

Image

It's still kinda pix-elated (32x32) but if you're willing to sacrifice your fps to around 50%, I can get you 64x64 resolution.
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 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Changelog & Progress

Postby TheTom » Sat Aug 04, 2012 6:54 pm

mr_no wrote in Sat Aug 04, 2012 6:24 pm:So I was thinking of plotting (point by point) a very approximate height map, view from above like this.

You can render any shape you want as long it is expressible using OpenVG/SVG paths. In your case it would mean just plotting lots of little rectangles which is already possible. Something like:
Code: Select all
var height_map = my_canvas.createGroup();
for(var x = 0; x < 64; x += 1)
  for(var y = 0; y < 64; y += 1)
  {
    # create a 1x1 sized rectangle without a border
    pixels[x][y] = height_map.createChild("path")
                             .moveTo(x,y)
                             .horiz(1)
                             .vert(1)
                             .horiz(-1)
                             .close()
                             .setStrokeLineWidth(0);
  }
# ...
for(var x = 0; x < 64; x += 1)
  for(var y = 0; y < 64; y += 1)
  {
    # Set color to whatever you want
    pixels[x][y].setColorFill(x/64.0, y/64.0,1);
  }

I haven't tested it and don't know anything about the performance, but I think getting new height data will be much slower than the rendering, which should optimally not be really noticable (~4000 Quads need to be rendered).
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: Changelog & Progress

Postby mr_no » Sat Aug 04, 2012 7:20 pm

Wow! Thanks guys, that sounds great! :mrgreen:
Mosquito-XE JT-5B-autogyro Extra-300s STOL-Ch701
User avatar
mr_no
 
Posts: 360
Joined: Thu Jan 19, 2012 3:20 pm

Re: Changelog & Progress

Postby Hooray » Sat Aug 04, 2012 8:07 pm

keep in mind that Omega95 doesn't sample all of the terrain at once, but that his geodinfo calls are spread across several frames to keep performance sane. His VSD thread should contain some more pointers regarding this strategy.

Obviously, the same technique could be used to implement a wxradar
So once you have a generic class, it doesn't matter if you are using a palette to visualize different terrain elevations or different cloud types.

Wxradar infrastructure code has been part of the local weather system since April 2012: viewtopic.php?f=47&t=14755&p=156055&hilit=wxradar#p156055
Last edited by Hooray on Sat Aug 04, 2012 8:15 pm, edited 2 times in total.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Changelog & Progress

Postby omega95 » Sat Aug 04, 2012 8:14 pm

Hooray wrote in Sat Aug 04, 2012 8:07 pm:http://flightgear.org/forums/viewtopic.php?f=30&t=15355&hilit=wxradar]wxradar[/url]
So once you have a generic class, it doesn't matter if you are using a palette to visualize different terrain elevations or different cloud types.


Well, Thorsten mentioned that it would not be possible to use that method for wxradar for the current weather system... :|
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 1:59 am
Location: -unknown-
Callsign: MIA0001, OM-EGA
IRC name: omega95
Version: 2.12 git
OS: Ubuntu 13.04

Re: Changelog & Progress

Postby Hooray » Sat Aug 04, 2012 8:22 pm

I am not sure what exactly you are referring to, but I sent a heads-up to Thorsten, so that he clarify the situation hopefully.

Also, I am not sure if we really want to directly render an X * Y grid of ~4000+ quads, often these would contain many identical elevations, which could probably be simplified using Canvas "groups".

Thus, it /could/ be more efficient to sample the terrain once and then add the various altitudes as geographic positions using the new "Canvas Maps" element instead, with certain dimensions (transformed via canvas), that should result in less total "drawables" in most situations, especially where differences in terrain elevation are not too pronounced, simply because the positions of these elevations would never change, so all the updating would be done by the C++ code - the Nasal could would only need to make sure to sample "new" terrain that isn't yet written to the property tree.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Changelog & Progress

Postby mr_no » Sun Aug 05, 2012 12:49 am

I was just trying to add the missing instrument to the F16 model.
That height map would definitely help, but something tells me that this should be pre-rendered, just like the scenery is.
Scrolling a texture would be much faster.. :p
Just experimenting...
Image
Mosquito-XE JT-5B-autogyro Extra-300s STOL-Ch701
User avatar
mr_no
 
Posts: 360
Joined: Thu Jan 19, 2012 3:20 pm

Re: Instruments with height maps ?

Postby Thorsten » Mon Aug 06, 2012 10:31 am

Well, Thorsten mentioned that it would not be possible to use that method for wxradar for the current weather system...


If I understand correctly, the question is about quearying the weather system for the precipitation at a given location and build a wxradar image from that.

That would work in principle, but would be very inefficient and result in completely unsatisfactory visuals. Currently precipitation exists in effect volumes with very simple shapes (rectangle, circle or ellipse) which would be imaged to a wxradar and look very artificial (a thunderstorm would be represented by a constant color circle). We do not have a realistic modelling of position-differential precipitation as imaged by a true wxradar.

This wouldn't be feasible - we use simple geometric shapes to get fast information if we are inside or outside of the given volume (we need to be able to process thuosands of these tests every few seconds) - checks for general volumes are just too slow. Nor would it be needed - visual precipitation is broken in any case, even if it works, you can't detect if it's switched on in a complicated or simple volume,...

So the wxradar support passes high level info ('there is a thunderstorm at position xy with as strength of zz and radius R') to the wxradar and relies on the radar code to translate that into pleasant visuals.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Instruments with height maps ?

Postby Hooray » Wed Aug 15, 2012 5:01 pm

For heightmaps (i.e. terrain elevations), we could have a separate Nasal helper which uses the built-in/hardcoded terrain pre-sampler developed for the local weather system:

Basically, it could sample the terrain in a certain area and the elevations could then be mapped to a Canvas texture using a simple helper - that should be slightly faster than just using the geodinfo() call from Nasal.

I don't know enough about the terrain sampler implementation currently, but obviously it would make sense to use some spatial data structure, so that unnecessary/redundant terrain samples can be avoided, which will be especially important once the surrounding terrain is repeatedly sampled in slowly flying aircraft, because then, we'd really only want to sample "new" (previously unsampled) terrain.

Ultimately, it would even be possible to implement a terrain awareness system (TAWS) using the terrain presampler, the canvas system and some Nasal "glue" code:
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Instruments with height maps ?

Postby f-ojac » Tue Aug 21, 2012 8:28 am

There was also a testing made by Zakharov a while ago: http://seb.marque.free.fr/fichiers/flig ... category/5 Dev snapshots still available.
Read here: http://wiki.flightgear.org/FlightGear_N ... tober_2010
f-ojac
 
Posts: 1304
Joined: Fri Mar 07, 2008 10:50 am
Version: GIT
OS: GNU/Linux

Re: Instruments with height maps ?

Postby Hooray » Tue Aug 21, 2012 2:56 pm

Image

That's pretty cool, but as can be seen, it's also just a workaround by using maps that were separatley pre-created using atlas.

While that's interesting, the idea is that that canvas system should make all of these "workarounds" obsolete and unnecessary (eventually).

So it's certainly good to look at it from a functionality point of view (as is looking at all the currently hard coded instruments in FG), but the implementation with Canvas is intended to be much simpler and more powerful at some point.

While the canvas system doesn't currently have support for rendering "moving maps" (i.e. terrain layers), that's one of the most-frequently requested features obviously - and there are several options, one of the simpler ones being reusing code from atlas to create the required "maps" dynamically in a background thread and making the texture then available as a geo-referenced "layer", i.e. via a new canvas element implemented in C++ space.

Brian (the atlas developer) just said this a couple of days ago:
bschack wrote:The code that comes closest to what you immediately need (creating map textures) is in TileMapper.cxx and the classes that it depends on, like Bucket.cxx and Subbucket.cxx (where the real drawing takes place).


The portion of the atlas code would obviously need to be converted to OSG to be reusable and it would need to use the FG tile manager, but that would probably be simpler than implementing CompositeViewer support.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Canvas

Who is online

Users browsing this forum: No registered users and 0 guests