Board index FlightGear Development Canvas

Porting the map dialog for 3.2

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.

Porting the map dialog for 3.2

Postby Hooray » Thu May 01, 2014 6:26 am

Image
@TheTom: Patch at: Subject: How to display Airport Chart?
Getting this reviewed/committed in time for 3.2 would be useful for 1) porting the map dialog, 2) tutorials/missions:

Subject: How to display Airport Chart?
Hooray wrote:
zakalawe wrote in Sat Nov 09, 2013 2:51 am:Looking good, can you get this working so we can replace the map-widget for 3.0?


We need to check what's missing, or rather, what would be useful to replace the map widget completely/properly. For example, as far as I know, we don't currently have any hooks into the replay/flight recorder subsystem, which is however what's used to show flight path history,right ? So the poor-man's approach would be using a timer and sampling the position separately, but having access to the replay/recorder system would be great for many other reasons, so exposing it via cppbind would be awesome.


Subject: NavDisplay & MapStructure discussion (previously via PM)
Hooray wrote:right, history would be kind of a hack ATM, but I can ask Tom to review & commit the patch that I came up with a while ago - otherwise, we would need to register a timer that samples things like lat/lon/alt without being tied to MapStructure


Subject: Tutorials/Missions/Adventures: requests for features
Hooray wrote:anything related to piloting/aerobotatics (red bull air race) and maneuvers will require some means to do flight profile tracking, either by sampling lat/lon/alt or by hooking into the replay/history subsystems (currently not exposed to Nasal).


PS: It would also be good if the project/unproject hooks discussed in Issue 550 could be exposed, so that we can better support panning & projections (unless you have a better idea here) - performance-wise it would be great if we could beat the performance of the built-in ND, e.g. by using a pre-created lat/lon grid, stored as a raster image and referenced/transformed via a separate group. Philosopher also mentioned that he'd prefer using native Canvas windows for the new map, for which we'd only need 2-3 additional widgets (actually checkboxes should do for now), so that the whole thing could be procedurally instantiated, without requiring any PUI/XML stuff.
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: Porting the map dialog for 3.2

Postby Hooray » Sun May 11, 2014 9:09 pm

Update: Philosopher just committed some major updates:
Image
Ok, just went through the whole commit, looking really good - I am just a little annoyed that I didn't come up with some of those ideas myself, especially some of your refactoring work - moving text and styling into MapStructure is so much smarter than what I've been doing all the time ... :oops:

  • I would suggest to unify style handling and move it also into MapStructure.nas - we can then have a helper class for creating temporary styles for each layer, where the defaults would be provided by the *.lcontroller file itself - i.e. each lcontroller would provide a hash with styling information (line_width, default_color, font) and the helper hash would create temporary styles with those defaults applied - that way, we can override styling without replicating things manually:
    Code: Select all
    var Style = canvas.MapStructure.Style.new(); # implicitly populated with keys (hashs) for each supported layer using df_style
    Style.DME.line_width = 5.0; # overwrites the corresponding key in the temporary style hash, while using the rest by default
  • RTE looks really good, but maybe we should split it up and have a generic LEG layer that doesn't know anything about those flightplan APIs ? That way, we could reuse all the logic because the flightplan() stuff would be inside RTE, while leg drawing would be handled by LEG.* ?
  • not sure about dependencies among layers though: you fixed the "navaids" problem by introducing another NDB checkbox, which is fine - but I was looking into having lcontrollers that could be meta controllers to instantiate other layers, too and manage those implicitly ? Then again, that may complicate the new way of loading stuff implicitly by extension ?

PS: We should probably add a hash field to each MapStructure layer that declare its own version, as well as versions required by it, i.e. at least a FG version check might make sense, so that we can allow people to request a certain stable API, without being subject to our hacking ...

PPS: It took me under 10 minutes to go through the whole thing, but I am still wrapping my head around foreach(var type; [r('TFC',0),r('APT'),r('DME'),r('VOR'),r('NDB'),r('FIX',0),r('RTE'),r('WPT'),] ) :D
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: Porting the map dialog for 3.2

Postby Philosopher » Sun May 11, 2014 9:33 pm

Thanks H.

  • About RTE vs LEG: essentially we have a generic LEG already - that's what LineSymbol is for, it draw Geo-positioned lines. If fact, the FLT history layer (!!!!) uses that too. It's just really simple that way, and *.symbol file has very little content.
  • My concern with the NDB vs VOR vs DME vs TLA (I have no idea what these actually are!!) is that, once we start putting style information there, each layer will want to have its own information, and that might not work. Now, we can certainly combine them into a single checkbox and have all layers update on that.
  • Yeah, the text styling was just a proof-of-concept, I still need to adopt it. I added a couple lines to ensure that a style that is passed in always inherits from the default style, so that won't be a problem. This should go in the *.symbol file, because that's were it's used. I'm even debating moving styles from layers to symbols maybe? That is where they are actually used, and would eliminate the ugly "me.layer.style" pattern. Adding helpers would be good.

Next goal: controller & symbol reform. *.scontrollers don't have much to do these days (especially now that we have access to layers), and then *.lcontrollers need to be more independent in determining when they update. FLT + TFC need to update pretty frequently, while VORs + DMEs + NDBs + APTs + FIXes are distance-sensitive. Most would update when range or visibility changes, and aircraftpos.controller might not be the best place for that. Styling needs to occur better and files can usually be simplified.

P.S. Also seeing some weird reposition occurring - like it renders in the center then decides to move it to where it should be the next frame? Only occasionally with like 1 object at a time, particularly labels.
P.P.S. I forgot how I came up with the "r" name (probably not layer->Rayer->r, or layeR->r), but it's a shorthand way to encode z-index and automatic visibility.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: Porting the map dialog for 3.2

Postby Hooray » Sun May 11, 2014 9:59 pm

indeed, good points - you mentioned a few things I missed.

symbol: should probably integrate more closely with caching
scontroller: should expose a notification callback that can be implemented to deal with updates, e.g. for LOD handling (different symbols after setPos/setRange)
BTW: my setRange() stuff doesn't actually work - it would be better to use a listener for ref-lat/ref-hdg et al, to ensure that callbacks are invoked even if they don't use the proper APIs
your comments about RTE/LEG make sense, I really missed the similarities here...
FLT/TFC are basically examples for your notion of "volatile" (or "dynamic") layers, and Gijs's WXR/STORMS would be too - so better introduce a helper class here ?
navaids and fixes should ideally also work for AI traffic, so the position controller really needs to be generic. One stress test I used last year was rendering a handful of NDs for different AI aircraft.
controller-wise, there's quite a bit of stuff inside navdisplay.mfd that encapsulates things like radios (comm/nav-anything referencing /instrumentation really) which would actually belong into some kind of encapsulated "driver hash" (class)

The reposition/re-centering I am seeing too, I was actually wondering if it's due to our code or some canvas issue, not sure if we can easily troubleshoot that to see what's going on.
For instance, I am seeing all text labels rendered atop each other for roughly 1-3 frames until they show in the correct spot. Would need to come up with
a fancy unit test to check what's going on there. I was hoping it would be a C++ issue *g*
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: Porting the map dialog for 3.2

Postby Hooray » Sun May 11, 2014 10:26 pm

Referring to our previous discussion on LOD and switching between different representations/symbols based on range, I am more inclined to hide/show certain layers based on range, unless they're really trivial (single symbols) - but anything that is as complex as airports (taxiways/runways) should probably go into its own layer file, so that we can easily show/hide layers on demand, i.e. switch between different layers rather than squeezing everything into a single "airport" layer that handles all representations - that should also make some optimizations pretty straightforward, i.e. having sub-groups for each "feature" that can be individually toggled (and cached!), what do you think ?

And stuff like panning support is another reason why we need to register an update() listener to watch the ref-lat/ref-lon/ref-hdg/range properties, or things may become pretty fragile once a different system manipulates those properties directly. Even our way of rendering the centered "cursor/airplane" symbol needs to be implemented via a callback that uses ref-lat/ref-lon etc, so that mapping modes can be easily switched.
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 10 guests