Board index FlightGear Development Canvas

NavDisplay & MapStructure discussion (previously via PM)

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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Wed Jul 16, 2014 9:18 am

no need to do that, you can just extend the hash - please read the whole wiki article, it says EXACTLY what to do, and even provides examples.
You'll just add a new "Airbus" entry to the hash, simple as that.


http://wiki.flightgear.org/Canvas_ND_Fr ... w_features
the framework is now prepared to easily style & customize it for different aircraft, we will probably add a tutorial to the wiki to explain how things are hanging together there. The constructor and init methods may still need some work to generalize things there, because they are basically still the original code.

So to replace the 747 ND and customize it, these are the steps:

  • add a new entry to the NDStyles hash, for example "777-200"
  • you can simply copy the configuration stuff from the 747 to get started
  • start customizing things there
  • open the SVG file in inkscape and change it as required, save it
  • change the SVG filename in your NDStyles["777-200"] hash entry to match your own file name
  • provide animation callbacks for any 777 specific elements
  • open your own copy of ND.nas
  • change the constructor call .new() to specify the name of your new NDStyles entry
  • by default, this is 747-400 for the time being
  • the "777-200" part needs to match the identifier used in the NDStyles hash.
To get started, just copy the whole 747-400 section in NDStyles and rename it to match your needs. Once that is working (getting a 747-400 ND via the 777-200 identifier), you can simply replace the SVG file name and add your own update handlers to incrementally come up with your own ND.
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: 11378
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby omega95 » Wed Jul 16, 2014 11:25 am

Right thank you, I did that but I still feel that it's a better idea to let the aircraft/instrument developers be able to keep the data on an external file in their aircraft directory. That way, the aircraft does not have to be in the fgdata git repository (so, not limited to the GNU GPL license) for their ND to function. This also means that non-git users will not have to wait for the next FG release. :)

Anyway, when I do that, I get this error on the console -
Code: Select all
Nasal runtime error: non-objects have no members
  at /home/narendran/fgfs/fgdata/Nasal/canvas/map/navdisplay.mfd, line 1686


Which doesn't let the ND work.

Other than that, the taOnlyBox I added doesn't seem to work. Here's what I did in the SVG File -
Image

And here's the code -
Code: Select all
{
            id: 'taOnly', # the SVG ID
            impl: { # implementation hash
               init: func(nd, symbol), # for updateCenter stuff, called during initialization in the ctor
               predicate: func(nd) getprop("instrumentation/tcas/inputs/mode") == 2, # the condition
               is_true:   func(nd) nd.symbols.taOnly.show(),
               is_false:  func(nd) nd.symbols.taOnly.hide(),
            }, # end of taOnly  behavior/callbacks
         },
         {
            id: 'taOnlyBox', # the SVG ID
            impl: { # implementation hash
               init: func(nd, symbol), # for updateCenter stuff, called during initialization in the ctor
               predicate: func(nd) getprop("instrumentation/tcas/inputs/mode") == 2, # the condition
               is_true:   func(nd) nd.symbols.taOnlyBox.show(),
               is_false:  func(nd) nd.symbols.taOnlyBox.hide(),
            }, # end of taOnly  behavior/callbacks
         },


But it seems to end up as a filled box -

Image

I know the fonts messed up too - it was also messed up for the Boeing style. I get the following error -
Code: Select all
canvas::Text: Failed to open font file /home/narendran/fgfs/fgdata/Fonts/LiberationFonts/LiberationSans-Regular.ttf


The ttf file exists, so I'm not sure what's going on.

I've never edited SVG files before this, so I'm not sure if I messed up anywhere else. But I did remove a LOT of labels, and pointers that don't exist in the Airbus 'ARC' mode - does that affect anything?

Another thing that may contribute to the errors is that my FlightGear hasn't been updated for atleast a month or 2. I'm currently pulling from git though. :)

EDIT - Oh and btw the line that triggers the error is -
Code: Select all
me.symbols[feature.id] = me.nd.getElementById(feature.id).updateCenter();
Last edited by omega95 on Wed Jul 16, 2014 11:53 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: 1223
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Wed Jul 16, 2014 11:52 am

Yeah, you should update your SG/FG/FGDATA checkouts and rebuild your binaries.

Deleting labels/symbols is not an issue as long as you also remove all references to them in your style.
However, keep in mind that the update() method may contain a few hard-coded references.
For starters, I'd probably leave them as is and focus on new additions rather than removing redundant stuff.
A good compromise would be simply hiding all unneeded symbols via .hide() - that way, there shouldn't be any errors due to missing symbols, and you'll still get a "blank" ND that you can populate.

Right thank you, I did that but I still feel that it's a better idea to let the aircraft/instrument developers be able to keep the data on an external file in their aircraft directory.


I would agree with you, maybe, 5+ years from now - but given the state of Canvas, MapStructure and the ND, it would be premature to allow that.
Just look at things like XML, the property tree, Nasal etc - these are all powerful technologies, but they are too much "free-form", i.e. these days our main problem in FlightGear is lack of consistency and lack of backward compatibility, we have a ton of great features, that end up being inconsistent more often than not - even though mainy features are heavily related/overlapping, or even identical.

Things like the "route manager" issues you keep mentioning are exactly because of this: people no longer have to use proper interfaces to use a feature, they will come up with code to use the feature, without using encapsulation that would shield/protect them from future changes and additions.

And that's something that we've been seeing in a ton of places in FlightGear lately. XML, properties and Nasal make it far too easy for people to end up with a working feature, without thinking about general designs and reusable components. Gijs went through the same experience when he came up with the original ND code: it wasn't generic at all, it was highly specific to a single aircraft, it used a ton of hand-written code, without any abstractions/helper, and it would only support a single aircraft and a single instance.

We've been working towards improving this - and we're basically almost there now, Gijs has recently done a lot of work and refactored the navdisplay.mfd file to move aircraft specific code out into the style-file. So there really isn't much left that needs to be done now.

But the instant we allow/encourage people to use separate files, we'll the same thing happen again.

Just look at the way MapStructure is structured: it is all about modularity, code reuse and encapsulation: anybody can now easily create custom layers, and use them on arbitrary aircraft, and even on arbitrary GUI dialogs. And the whole thing is designed to support styling and customizing right from the beginning, and even supports multiple instances. And all that in under 1k lines of Nasal codes.

This is a huge step and a huge accomplisment. Over time, this means that collaboration will be more streamlined, and that people may benefit from related/similar contributions automatically. For instances, Gijs' original work has meanwhile benefitted at least half a dozen of different aircraft developers (some of whom now got involved in ND development/maintenance), and the same work has also helped unifying the 2D rendering back-end by re-implementing the hard-coded Map dialog.

This is how, and why, collaboration scales so well if done properly.

We could trivially support external files, styles etc - but it would not be a good decision for the time being, for all the reasons I mentioned above: we would end up losing all the collaboration that's currently going on. We've got some extremely talented aircraft developers, including some who write exceptionally clean Nasal code - just look at some of the recent work done by the extra500 developers and their Avidyne Entegra R9: it's an awesome piece of work, but people are basically unable to fly the aircraft with >= 20 fps because it is suffering from implementation problems, many of which we've solved already on the MapStructure/ND side, and others we know how to solve easily.

Canvas is a relatively recent and novel addition to FlightGear, and it is not about certain instruments or displays like a PFD, ND, CDU or EICAS - it's just the foundation for other people to develop frameworks on top. But once we encourage/support a non-modular development strategy, we'll see the same thing happening that happened when the Route Manager got updated: people will start yelling at us that something no longer works, and that they need to update their aircraft, for which they don't have the time - without understanding the real culprit, namely their inadequate implementation strategy and original approach.

Canvas is not about a single instrument or display, which is why we have to come up with scripted frameworks for these purposes - once we encourage collaboration (shared/common code base), we can easily extract buidling blocks to help shape a framework and an API for the most-common purposes. This is what happened when Gijs' started his original ND work: it's meanwhile become 2 frameworks already: one for mapping/charting (MapStructure) and 2) one for NDs.

It would take us 2-3 hours to generalize this a little more and turn the same code into a framework for creating PFDs or other MFD-style displays, as long as the same approach is used (SVG elements animated via Nasal callbacks), it's as simple as that.

At that point, there will be 3-4 frameworks, all based on the same work created by the same developer, but with potentially 5-7 additional contributors, like Hyde, Soitanen, Michat, Philosopher or myself.

Gijs has demonstrated that he's meanwhile able to help create, edit and maintain MapStructure layers - and he'll immediately benefit from any other work related to this. And people won't have to come up with their own solutions to work around common issues - the Avidyne Entegra R9 developers are re-inventing the wheel and adapting MapStructure/ND code in a Copy&Paste fashion - which means that they'll inevitably have to update their own code once certain Canvas optimizations become available - all MapStructure-based displays (like the ND), but also any other framework-based solutions, will automatically benefit from such additions, because it is just the underlying framework that will be updated.

Just look at the amount of code that is needed to create independent ND instances these days - most of it even being boilerplate, i.e. you can basically strip it down to less than 50 lines of code, and it will continue to work, no matter what's changed on the Canvas side of things. Aircraft developers will not have to update any custom code at all, it's all delegated to framework developers/maintainers.
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: 11378
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby omega95 » Wed Jul 16, 2014 12:18 pm

Deleting labels/symbols is not an issue as long as you also remove all references to them in your style.


Aha, I messed up! Well, I think for now, the best thing I could do is to remove everything in the airbus style and start from what I still have left in the SVG file (ofcourse copying from the Boeing style and changing things around).

I really like that we can control what happens to it (the properties it depends on) from the style - it makes it easy to integrate it to my custom route management system. But are the layers bound to the FGRouteManagar? That means I'd still have to copy the waypoints and data to it to be displayed on the map, right?

We've been working towards improving this - and we're basically almost there now, Gijs has recently done a lot of work and refactored the navdisplay.mfd file to move aircraft specific code out into the style-file. So there really isn't much left that needs to be done now.


Right, but how does having everything in 1 style-file protect users using it from changes and modifications? Would we continue developing this/fixing errors in all the styles?

It would take us 2-3 hours to generalize this a little more and turn the same code into a framework for creating PFDs or other MFD-style displays


Yeah, I looked at some of it and I really like how it works - I was thinking of making the canvas VSD (vertical situation display) with something like that. Great job! :)

EDIT -

Also, I found a comment in the navdisplay.mfd file that talks about converting it to read XML data files. Would you be reading the XML files with Nasal or simgear? I think that's a great idea and make a lot of sense and would love to help do that. I also wanted to develop a new A380 mCDU which acts similar to HTML (well, it'd be XML though) and displays pages and connects links, functions etc. :) It seems pretty simple to do something like that with canvas.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Wed Jul 16, 2014 12:36 pm

  • I'd probably just change the callbacks to invoke .hide() on each symbol that you don't require - analogous to the .updateCenter() foreach loop
  • there's no tight coupling WRT to the integrated route manager, there's a single method called searchCmd() in each lcontroller file that determines where it is getting its data from, supporting other data/source would be trivial, but should NOT be the way you said, but instead using a "driver hash" that encapsulates the concept of a "data source": viewtopic.php?f=71&t=23204&p=213215&hilit=#p213215 - you could even use a completely custom RM requiring only ~30 lines of Nasal changes that way
  • people will continue to collaborate by editing their own sets of styles/symbols - over time, we'll extract common functionality and maybe generalize a few concepts, such as a simple animation framework - once that is in place, all styles will be adapted accordingly, and if/when we extend the C++ code to directly support animations, we only need to update the animation framework, and all styles/displays will use that automatically, i.e. benefit from better performance automatically
  • right, the VSD would be trivial to implement like that - but it would be better (and much faster!) to extend MapStructure itself here to support "vertical" projections/maps, see: http://wiki.flightgear.org/Talk:Canvas_ ... ._Vertical
  • the XML comment is a leftover, it's not relevant for the time being - I just wanted to demonstrate what this is about, i.e. it will only require ~25 lines of Nasal code to turn such a "style" into fully declarative XML markup - but before we consider doing that, we should have more styles/instruments implemented like that, so that some more framework functionality can evolve & standardize. And it would not affect aircraft developers, reading/processing is handled by the constructor call, i.e. ND.new() - not by you guys. You would never need to know such details, it will be totally transparent to aircraft developers - who will merely request an ND and get it delivered, without having to know how it is implemented.
  • pages etc should be handled by the frameworks, using "buttons/switches, modes and pages": http://wiki.flightgear.org/Canvas_MFD_Framework
  • Tom has already developed CDU code, it is much more consistent than most other frameworks obviously, but not as flexible as we'd want it to be probably - the basic idea is to generalize the concepts and come up with a simple framework: http://wiki.flightgear.org/Canvas_MCDU_Framework
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: 11378
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby omega95 » Wed Jul 16, 2014 1:03 pm

Also, I found this in the file - shouldn't this be a part of individual styles instead of being general? It wouldn't be difficult to do that, would it?

Code: Select all
foreach(var element; ["compassApp","northUp","aplSymMap","aplSymMapCtr","aplSymVor",
                            "staArrowL2","staArrowR2","staFromL2","staToL2","staFromR2","staToR2",
                            "hdgTrk","truMag","altArc","planArcs",
                            "trkInd","compass","hdgBug","HdgBugCRT","TrkBugLCD","HdgBugLCD","curHdgPtr",
                            "HdgBugCRT2","TrkBugLCD2","HdgBugLCD2","hdgBug2","selHdgLine","selHdgLine2","curHdgPtr2",
                            "staArrowL","staArrowR","staToL","staFromL","staToR","staFromR"] )
         me.symbols[element] = me.nd.getElementById(element).updateCenter();


That seems to be what's causing the problem if I remove SVG objects.

pages etc should be handled by the frameworks, using "buttons/switches, modes and pages": http://wiki.flightgear.org/Canvas_MFD_Framework
Tom has already developed CDU code, it is much more consistent than most other frameworks obviously, but not as flexible as we'd want it to be probably - the basic idea is to generalize the concepts and come up with a simple framework: http://wiki.flightgear.org/Canvas_MCDU_Framework


Yes, I know, I've written a similar mCDU for the ATR 72 before - but I wanted something more like HTML - allowing the use of dropdowns, selectors, mouse pointers etc.

right, the VSD would be trivial to implement like that - but it would be better (and much faster!) to extend MapStructure itself here to support "vertical" projections/maps, see: http://wiki.flightgear.org/Talk:Canvas_ ... ._Vertical


Alright, but what's the progress on that? If no one's done anything related to do that? How would I go about doing this myself? I would mainly just need to know how to get the elevation data. Also, how exactly would this be faster?

Cheers!
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Wed Jul 16, 2014 1:13 pm

  • right, like I said previously (and as can be read on the wiki) - the constructor/newMFD() methods still contain a few hard-coded assumptions due to the origins of the code, but those can be also moved into some kind of construct() field in the hash, or you can simply use the method I suggested, i.e. hiding unneeded symbols. But you're right, that the most proper solution would be identifying non-generic code that contains hard-coded assumptions and moving that into some kind of construct() field that is simply invoked by the new/newMFD() methods. Doing that would not be difficult, it would be just copy & paste - i.e. copy from the navdisplay.mfd file into the style file, by adding a corresponding hash field entry there - and calling it instead. Takes under 3 minutes :D
  • dropdown/combo menus and other widgets will be supported post 3.2 by using native Canvas widgets - no need to reinvent the wheel here: any canvas GUI widget can also be used on MFD instruments
  • a canvas-based heightmap can be much faster due to using caching via texture-maps, and by using the hard-coded terrain presampler. Even though there are better options still - but that should get you started quickly. In the context of the VSD, it's projection handling that will be faster if handled in C++ space by a corresponding vertical Canvas::Element::Map::Projection: http://wiki.flightgear.org/Canvas_Devel ... rojections - Tom once mentioned that he wanted to support additional projections for these reasons.
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: 11378
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby omega95 » Wed Jul 16, 2014 1:21 pm

right, like I said previously (and as can be read on the wiki) - the constructor/newMFD() methods still contain a few hard-coded assumptions due to the origins of the code, but those can be also moved into some kind of construct() field in the hash, or you can simply use the method I suggested, i.e. hiding unneeded symbols. But you're right, that the most proper solution would be identifying non-generic code that contains hard-coded assumptions and moving that into some kind of construct() field that is simply invoked by the new/newMFD() methods. Doing that would not be difficult, it would be just copy & paste - i.e. copy from the navdisplay.mfd file into the style file, by adding a corresponding hash field entry there - and calling it instead. Takes under 3 minutes :D


Alright, I need to wait till I finish cloning fgdata (looks like I missed copying the .git folder into my backup hard drive) but where can I join in on the development to be able to do this? I mean, the changes I make right now would just be on my system - wouldn't it? Is there any way this can go on 3.2 release?

dropdown/combo menus and other widgets will be supported post 3.2 by using native Canvas widgets - no need to reinvent the wheel here: any canvas GUI widget can also be used on MFD instruments


Ok, but I need something pre-3.2.

a canvas-based heightmap can be much faster due to using caching via texture-maps, and by using the hard-coded terrain presampler. Even though there are better options still - but that should get you started quickly


How would I go about doing this? Also again, would it be possible to get this in the 3.2 release? If not, I need to focus on a temporary solution first and then work on this when I get time.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Wed Jul 16, 2014 1:27 pm

See the release plan, the repositories are just about to open up again, i.e. the code freeze is going to be over - but it's obviously too late for this to go into 3.2 - you would have had to open a merge request several weeks ago, and people would have required a bit of time to review & test your work, because the ND is used by almost a dozen of aircraft meanwhile.

Also, the update() method also contains a few such hard-coded assumptions, that would likewise need to be generalized & refactored.

To join development, it helps being able to use gitorious and git - otherwise, just post a diff here so that we can take a look at get it committed (usually, by Gijs or Hyde).

As long as you're using git/next, you can obviously also use Canvas GUI widgets on instruments - e.g. the message box would not require much work to reuse.

The terrain height map would basically be a custom MapStructure layer whose searchCmd() method uses the hard-coded terrain presampler.
The symbol file itself would read its symbol from a PNG/texture map with different altitude gradients for altitude differences

See Tom's comments at:
http://wiki.flightgear.org/Canvas_Maps
TheTom wrote:vertical projection seems not too complicated as its basically just calculating segment lenghts on a sphere, or maybe just direct distance calculations. I think the error in comparison to the real sphere can be neglected while using typical distances (eg. at a distance of 300 miles the error is about 2.8 miles, which is ~0.9%).

As for creating a Canvas-based VSD without hard-coded support for vertical projection handling , that's mainly a matter of 2D plotting - thus, I'd suggest to take a look at the FGPlot code: http://wiki.flightgear.org/FGPlot
You'll only need a fraction of the code, and then hook it up to the terrain pre-sampler.


All of this can be 100% scripted

And no, I don't see how either of this could go into 3.2 unfortunately - you're coming up with all those ideas much too late, not to mention the fact that these are all ideas ATM, and not actual patches
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: 11378
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby omega95 » Wed Jul 16, 2014 7:17 pm

To join development, it helps being able to use gitorious and git - otherwise, just post a diff here so that we can take a look at get it committed (usually, by Gijs or Hyde).


Yes, I use git for all my developments, but have never contributed to fgdata (well, I've tried with the ramp marshall, aircraft, my fg gui creator etc. but all of my merge requests have been rejected which is why I prefer creating external files and aircraft which interested pilots can download separately).

I suppose at this point, I would much rather just post my work here instead of creating merge requests.

The terrain height map would basically be a custom MapStructure layer whose searchCmd() method uses the hard-coded terrain presampler.


Umm alright, but how would I access those values?

Thank you for the resources on the FGPlot code, I'll definitely take a look at that.
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Thu Jul 17, 2014 12:34 am

as for the MapStructure side of things, check out any lcontroller file's searchCmd() method - and obviously also the MapStructure wiki article itself, which has a whole section about implementing custom searchCmd() methods, including an example.

For the terrain pre-sampler, check out the local weather system, which is the de-facto reference implementation for now.
You'll basically use the property tree to set up your terrain presampler, and get all the results via the property tree, too.

For the time being, you would not use a "map" mode though, because we don't currently support vertical projections, and we also don't expose projection-registration to Nasal, Tom didn't quite like this idea due to performance reasons - so you'll have to do the projection handling in Nasal space for now.

There's a projection library available called "proj4", it comes with a number of different projections, we may absorb that into simgear and use it for projection handling - which would free us from having to implement/test and maintain our own
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: 11378
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Jul 18, 2014 3:50 pm

Here a few screen shots from the open source X-Plane XHSI (737NG) project:

http://xhsi.sourceforge.net/
Image Image
Image Image
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: 11378
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby omega95 » Thu Jul 24, 2014 9:01 pm

So, how difficult would it be to make such a mapstructure layer?

Image

It'd be something similar to what's used in the Airport Select Dialog but with different colors? :)

This is also a feature on the 777/787, so it would be nice to have this not just for the A380. :)
Merlion Virtual Airlines - the experience of a flight time...
Get high quality aircraft, airports, video tutorials or development tools from my hangar.
omega95
 
Posts: 1223
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: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Thu Jul 24, 2014 9:26 pm

Not very difficult - like you say, we already have most bits in place, they just need to be ported to become MapStructure layers, and become style-able that way.

Even though it would make sense to introduce separate layers for each feature, i.e. taxiways, runways, buildings and gates.

The first two, we've got already - the other two can be easily added once we have some form of data source. For starters, you could use a hard-coded searchCmd() vector, which we can replace with a more proper solution later on.

The UI part can/should be developed using existing Canvas Widgets (buttons with image)

The main steps ahead are detailed at: http://wiki.flightgear.org/Canvas_MapSt ... xml_dialog
The main files are:

  • runways.draw
  • taxiways.draw
  • parking.draw


those files would need to be turned into MapStructure layers, as per: http://wiki.flightgear.org/Canvas_MapSt ... new_Layers
Which basically involves 1) finding an existing layer that is similar enough, 2) adapting the searchCmd() method in the lcontroller file to return what you need, 3) porting the draw() method in the *.symbol file accordingly.

Some of the more straightforward examples doing procedural rendering via OpenVG are the WPT/RTE layers (*.symbol files)
And then, it's just a matter of adding the new layer to your aircraft/dialog, as per: http://wiki.flightgear.org/NavDisplay#A ... ure_Layers

For example:
Subject: NavDisplay & MapStructure discussion (previously via PM)
Hooray wrote:Well, I guess we need to move away from the assumption that all layers have symbols, I took your APS layer and quickly adapted it to render a raster image that uses map server URLs to look up a satellite image online using Tom's recent CanvasImage/http support and the current lat/lon, and it's "kinda" working - but treating it like a symbol with a geo position now, but it's less than 20 lines of code (except for the usual MapStructure markup) - maybe we should introduce some kind of "overlay-layer" (handling zoom, lat/lon, transformation/alignment) :D
Image
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: 11378
Joined: Tue Mar 25, 2008 8:40 am

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Soitanen » Fri Sep 05, 2014 2:33 pm

Hi!
Found another bug with wind pointer:
Image
I fly with track=276 degrees, wind is from 273 degrees (from left), but pointer shows, that wind is from right. I think it's due to magnetic variation (it equal to +10 at place of screenshot). So it must not be added to needle rotation, I think.
Boeing 737-300. Reworked cockpit, FDM, autopilot and much more. WIP.
Boeing 737-800. WIP. Canvas PFD and ND.
Antonov An-24B. Made from scratch. Very good FDM. 3D model by Adrian. WIP.
Project Russia (some cities, based on OSM with custom objects).
Soitanen
 
Posts: 489
Joined: Sat Jun 16, 2012 6:50 am
Location: Saint-Petersburg, Russia
Version: git
OS: Linux Mint 17

Previous

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest