Canvas PFD framework
| This article is a stub. You can help the wiki by expanding it. |
|
Note:
While this article is based on considerable community feedback, there's nobody working on this currently.
Mentors: Gijs, Hooray (get in touch to learn more) |
 | |
| Started in | not yet... |
|---|---|
| Description | PFD Framework |
| Contributor(s) | Hooray (if nobody beats me to it), |
| Status | discussion |
| Subforum | https://forum.flightgear.org/viewforum.php?f=71 |
 |
The FlightGear forum has a subforum related to: Canvas |
Background
| Note Please also see Howto:Coding a simple Nasal Framework and check out the 744 and Avidyne Entegra R9 PFD https://gitorious.org/extra500/extra500?p=extra500:extra500.git;a=blob;f=Nasal/AvidyneEntegra9/page_PFD.nas |
|
Note that I'm still working on the PFD, so I'd suggest not to spend too much time on it right now. I've planned to have an aircraft agnostic version, like the ND, well in time for FlightGear 3.4..
|
|
|
|
Regarding the PFD, I'd prefer not to add too much to that code, until it is sufficiently generalized, too - currently, it's suffering from very real design limitations, and we cannot easily support multiple instances, or different aircraft. Before anybody adopts/integrates the 747 PFD code, please do get in touch so that we can coordinate the necessary steps. It is not necessarily much work, and not even very difficult - but it may take a few iterations to be sufficiently generic. But anybody who understands basic Nasal OOP, and maybe even Canvas, should be able to work through the necessary steps within 3-4 weekends. We wouldn't be changing any functionality, it would be just about refactoring, generalization and modularization - very much in line with the original ND restructuring efforts. In other words, I'd urge anybody interested in a Canvas-based PFD to get in touch first, and not to use the code directly "as is".
— Hooray (Sat Jun 21). Re: NavDisplay & MapStructure discussion (previously via PM).
(powered by Instant-Cquotes) |
|
|
|
Gijs has started cleaning up the update() method in navdisplay.mfd - once that work is finished, navdisplay.mfd should be down to ~500 lines probably. The ND-specifics should be under 100 lines by then, which means that we can reuse the same code to also port the existing PFD.nas code to use a more flexible approach by coming up with a generic "MFD" class that deals with switches, pages and modes and which merely uses a hash of SVG element IDs and Nasal animation callbacks.
|
|
|
|
Given the lack of progress in the PFD department, people interested in developing a simple PFD framework should look at Torsten's recent work which is sufficiently generic to support any kind of SVG-based MFD instrument, includinig PFDs and NDs - but also other EICAS/EFIS stuff, e.g. CDUs/EFBs etc.
|
|
|
|
If Torsten's keeps on making this degree of progress, it would probably make sense for "us" (the PFD/ND guys) to look at his code and reuse the generic stuff in the PFD/ND code prototyped by Gijs.
|
|
Gijs: now that I've most of the 744's EICAS pages done, I started converting the PFD to Canvas. I think I can implement all of its functionality. Right now both PFDs are identical, so there's just a single Canvas. Of course for a complete simulation we'd need independent PFDs. 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: 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, the idea iss 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
Roadmap
Also see https://forum.flightgear.org/viewtopic.php?p=201333#p201333