Canvas PFD framework: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎Background: forum2wiki)
Line 22: Line 22:


== Background ==
== Background ==
'''Gijs:''' Porting the displays to Canvas system for example. Right now both PFDs are identical, so there's just a single Canvas. Of course for a complete simulation we'd need independent PFDs, but that's not high on my priority list.. The PFD is mostly done now and so are the EICAS displays. It's a lot of work, but very rewarding and fun to do, since you get to dig knee-deep into all systems and discover things you never knew existed . I've been in contact with James about this, so don't worry, it won't conflict with his plans. The dialog will eventually use the same map. Anyhow, the ND is more than just a map, but for the map part I make use of the map API.  Feel free to work on the EFB (don't have that in the 744), but please don't waste any time on the rest of the displays. I already have PFD and ND for the 744 and am making them as generic as possible. They will end up in Instruments/ so we can re-use them on other aircraft. The VSD thing is nice, but it's low on my priority list. There's still lots of basic functionality missing that I'd like to have before 3.0. And then there's also the PFD that needs to be done...
'''Zakalawe:'''Gijs' experiment is looking pretty good already - I was able to give him some help with it on IRC. It certainly means we can deprecate the C++ NavDisplay code going forwards. Ideally we might want some alternative spatial queries (to address a sorting problem which also affects the C++ versions), again we discussed this and I can add them relatively easily. I believe Gijs' work on the PFD and EICAS are already in Git - you could adapt the 777 to use them already, and it would improve some features (or simplify the 3D models, and cut down on the textures). Certainly if I get any time to work on the NG (unlikely before 3.0) that's what I will be using.
'''Hooray:'''Looking at Gijs' pfd.nas file currently, does the PFD work properly with multiple instances, i.e. captain/copilot ? Just wondering because I haven't looked at how the code is loaded, but just noticed that you are initializing a bunch of global variables at the top of the script, rather than instance-specific member variables, which I would have expected here. With 2-3 helper functions, and using a vector of lookup keys (for the SVG handles, assuming that the member fields can have identical names) and automatically initializing a corresponding member field then, something along the lines of this (in the constructor). regarding multiple PFD/ND/MFD instances, I think that can be easily accomplished by doing what I suggested earlier, i.e. turning your global variables into instance variables (members), as shown above.
'''Philosopher:'''I will offer to help restructure code and such. My primary goal would be to clean up class structure, do MVC (I think I understand what that means...), etc. once we agree what module we want to develop. I'll have to take a look at Gijs' design, but map.nas looks like an easy target for me to clean up. I also need to figure out where bootstrapping fits in, because if anything it would be higher priority for me, and it might even help with dependency management here.
'''Zakalawe:'''In terms of the EADI I haven't thought about structure at all - if there is a system to use, point me at it. Certainly for the .nas file which drives the PFD & EADI, I would expect it to be 99% the same (just needs to handle missing elements better) - and likely is very similar for all PFD-type displays including Airbus and G1000. I don't think using a single global SVG file is going to work - the problem is this is a totally different technology generation to the 747-400 / 777 / 737-NG displays, so although the symbols are similar, the actual appearance is different. Maybe 'new Boeing' and 'old Boeing' files would work? Since the 737-Classics, 757 and 767 all use this earlier style of EADI. (And similarly the EHSI is a simplified version of the ND).
'''Zakalawe:'''In terms of the EADI I haven't thought about structure at all - if there is a system to use, point me at it. Certainly for the .nas file which drives the PFD & EADI, I would expect it to be 99% the same (just needs to handle missing elements better) - and likely is very similar for all PFD-type displays including Airbus and G1000. I don't think using a single global SVG file is going to work - the problem is this is a totally different technology generation to the 747-400 / 777 / 737-NG displays, so although the symbols are similar, the actual appearance is different. Maybe 'new Boeing' and 'old Boeing' files would work? Since the 737-Classics, 757 and 767 all use this earlier style of EADI. (And similarly the EHSI is a simplified version of the ND).
Anyway, as I said, my interest is to get some working - if someone provides a 'system' I'll use it but I'm not interested in writing it myself  
Anyway, as I said, my interest is to get some working - if someone provides a 'system' I'll use it but I'm not interested in writing it myself  

Revision as of 17:13, 2 February 2014

Canvas PFD Framework
Started in not yet...
Description PFD Framework
Contributor(s) Hooray (if nobody beats me to it),
Status discussion
Subforum http://forum.flightgear.org/viewforum.php?f=71


This article is a stub. You can help the wiki by expanding it.


Background

Gijs: Porting the displays to Canvas system for example. Right now both PFDs are identical, so there's just a single Canvas. Of course for a complete simulation we'd need independent PFDs, but that's not high on my priority list.. The PFD is mostly done now and so are the EICAS displays. It's a lot of work, but very rewarding and fun to do, since you get to dig knee-deep into all systems and discover things you never knew existed . I've been in contact with James about this, so don't worry, it won't conflict with his plans. The dialog will eventually use the same map. Anyhow, the ND is more than just a map, but for the map part I make use of the map API. Feel free to work on the EFB (don't have that in the 744), but please don't waste any time on the rest of the displays. I already have PFD and ND for the 744 and am making them as generic as possible. They will end up in Instruments/ so we can re-use them on other aircraft. The VSD thing is nice, but it's low on my priority list. There's still lots of basic functionality missing that I'd like to have before 3.0. And then there's also the PFD that needs to be done...

Zakalawe:Gijs' experiment is looking pretty good already - I was able to give him some help with it on IRC. It certainly means we can deprecate the C++ NavDisplay code going forwards. Ideally we might want some alternative spatial queries (to address a sorting problem which also affects the C++ versions), again we discussed this and I can add them relatively easily. I believe Gijs' work on the PFD and EICAS are already in Git - you could adapt the 777 to use them already, and it would improve some features (or simplify the 3D models, and cut down on the textures). Certainly if I get any time to work on the NG (unlikely before 3.0) that's what I will be using.

Hooray:Looking at Gijs' pfd.nas file currently, does the PFD work properly with multiple instances, i.e. captain/copilot ? Just wondering because I haven't looked at how the code is loaded, but just noticed that you are initializing a bunch of global variables at the top of the script, rather than instance-specific member variables, which I would have expected here. With 2-3 helper functions, and using a vector of lookup keys (for the SVG handles, assuming that the member fields can have identical names) and automatically initializing a corresponding member field then, something along the lines of this (in the constructor). regarding multiple PFD/ND/MFD instances, I think that can be easily accomplished by doing what I suggested earlier, i.e. turning your global variables into instance variables (members), as shown above.

Philosopher:I will offer to help restructure code and such. My primary goal would be to clean up class structure, do MVC (I think I understand what that means...), etc. once we agree what module we want to develop. I'll have to take a look at Gijs' design, but map.nas looks like an easy target for me to clean up. I also need to figure out where bootstrapping fits in, because if anything it would be higher priority for me, and it might even help with dependency management here.

Zakalawe:In terms of the EADI I haven't thought about structure at all - if there is a system to use, point me at it. Certainly for the .nas file which drives the PFD & EADI, I would expect it to be 99% the same (just needs to handle missing elements better) - and likely is very similar for all PFD-type displays including Airbus and G1000. I don't think using a single global SVG file is going to work - the problem is this is a totally different technology generation to the 747-400 / 777 / 737-NG displays, so although the symbols are similar, the actual appearance is different. Maybe 'new Boeing' and 'old Boeing' files would work? Since the 737-Classics, 757 and 767 all use this earlier style of EADI. (And similarly the EHSI is a simplified version of the ND). Anyway, as I said, my interest is to get some working - if someone provides a 'system' I'll use it but I'm not interested in writing it myself

Maybe you could make a system where symbols can be grouped arbitrarily in SVG files, and layered together? Eg one layer for the speed-tape, one for the altitude-tape, one for the horizon. (Does Inkscape support including a layer from another SVG file?). Since I agree being able to position elements visually is very nice.

Hooray:What exactly are your Nasal/coding plans related to Gijs' PFD code ? I am asking because I mentioned a couple of times that I was hoping to look into it as some point, specifically with the intention to make things as portable and as flexible as the ND framework - i.e. to support at least multiple independent instances per aircraft, but also support different types of aircraft (beyond just Boeing and Airbus). Obviously, this requires a fair deal of generalizing things and getting rid of hard-coded assumptions. The other use-case that the ND code now supports is easily rendering these instruments in GUI dialogs, no matter if these are PUI widgets or "native" Canvas windows. Basically, my idea was to generalize the ND code some more and come up with helper classes for 1) SGSubsystems, 2) MFD instruments and 3) image generators, 4) displays and display switches/selectors. Introducing a handful of helper classes would allow us to support all important use-cases that are common in modern glass cockpits, including switching between different FMCs or PFDs/NDs.

Hooray:Overall, removing SVG elements to come up with custom SVG files is not such a good idea - the approach taken by the ND module is to have a common/shared SVG file for different types of NDs, with added symbols for different types of aircraft - these are loaded into canvas groups, i.e. can be trivially animated, but also shown/hidden. The long term idea here being to encourage developers to maintain a single SVG file that lives within $FG_ROOT, rather than within $FG_AIRCRAFT - so that we can grow a library of symbols and different "styles" (themes) - for different types of aircraft and glass cockpit systems.

This approach is also favored by Gijs and Hyde.

In general, we really don't want to see a ton of custom files for different aircraft, no matter if this is a ton of Nasal spaghetti code, or custom SVG files - these PFDs are similar enough to be driven by a common generic back-end, using symbols from a single SVG file with different groups/layers. The way the ND code has been reworked, makes it possible to factor out custom stuff into helper hashes, which animate a single element independently - this can be triggered via listeners, timers - or permanently run via polling in a single update() loop.

Generalizing Gijs' PFD code accordingly would probably take 2-3 weekends, integrating and unifying this with the ND "framework" would be another 2-3 weekends. I would really prefer to closely coordinate things here - we really don't want to have people come up with hugely different approaches for different types of MFDs.

TheTom:I'm not sure if it is really a good solution to use a single svg files with all possible PFD elements and combine them (from Nasal?). We could to a collection of elements and copy them together, but there are so many different types of layouts that it will not be possible to cover every possible visualization. Also positioning and resizing the elements is much easier and faster from within InkScape. A common framework in the background (with some common elements like "rotating" numbers, HSI logic, trend vector calculations, etc.) is definitely a good idea.

Hooray:When we came up with the idea of sharing a common SVG file, this was primarily about the Boeing series of airliners (747, 747, 777, 757 etc) - the point being that we want to avoid unnecessary duplication of functionality - if we introduce separation too early, things are likely to be adopted in a "copy & paste" fashion probably - that's in fact how Hyde started adapting Gijs' 747 ND for use in the 777, and neither Gijs or myself were really thrilled about it. As a compromise, I would suggest to maintain manufacturer specifics SVG files instead - i.e. either based on aircraft manufacturers (Boeing/Airbus) or based on EFIS manufacturers like Honeywell. Overall, I would just suggest not to separate things too early - or people are going to end up using lots of "copy & paste" to implement certain features. FG development isn't overly organized - so we basically need to "force" people to generalize things by adopting a corresponding framework that encourages generalization at its core. But I can perfectly understand that the C130J would not be well served by a Boeing or Airbus-based SVG file... so better grow a "library" of symbols for different manufacturers, but ensure that this does NOT live within $FG_AIRCRAFT

Design