Board index FlightGear Development Canvas

Who is working on / using navdisplay code?

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.

Who is working on / using navdisplay code?

Postby jsb » Wed Nov 21, 2018 7:07 pm

Hi there,

is anybody currently working on the "official" nav display code in FGDATA/Nasal/canvas...?
I started to review that code and will also dive into the underlying MapStructure code with the goal to adapt/extend it for CRJ700 family.
To avoid duplicate code/work and conflicts kindly let me know who is working on this and if there are pending merges I should wait for.

Also a list of aircrafts that really use that code would be highly appreciated as I found out that some aircrafts use their local copy of the code so I believe those won't be affected by any changes, neither improvements nor possible problems due to changes.

cheers Henning
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Who is working on / using navdisplay code?

Postby legoboyvdlp » Wed Nov 21, 2018 7:13 pm

I think the IDG aircraft are one of those that use a fork - it basically started with the Artix code and then Josh made a few changes.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Who is working on / using navdisplay code?

Postby Hooray » Wed Nov 21, 2018 8:01 pm

most of the artix stuff should probably be reviewed and integrated/merged first, I believe omega95 also came up with some of his own non-MapStructure layers (IIRC, the VSD).

The whole idea behind the MapStructure framework is to use a MVC separation so that different aircraft can still use the same code without using copy/paste at all. Unfortunately, that point is difficult to communicate properly. Still, if you are using copy&paste to use MapStructure features, you are not using the framework correctly.

Apart from that, the navdisplay stuff is a freaking mess, because it got refactored well after the fact - these days, the FG1000 can probably be considered the go-to place for a reference implementation of a Canvas/MapStructure based display.
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: Who is working on / using navdisplay code?

Postby jsb » Fri Nov 30, 2018 4:54 pm

Ok, what about a library of functions to draw more complex things on a canvas? I know some people prefere Inkscape/SVG and others prefer nasal scripting. I started my work with Inkscape but I tend to implement the PFD and parts of MFD scripted. I guess I could find lots of code in all the different aircrafts for drawing things like speed tape, compass, engine instruments etc. but as far as I see there is nothing like a
canvas.draw library
I think it would be good to start such thing and my first elements would be a compass rose and a linear tape (e.g. for speed and altitude), stylable of course. So the library should also contain a structure to organize styles.
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Who is working on / using navdisplay code?

Postby Hooray » Fri Nov 30, 2018 5:57 pm

Indeed, that's a long-standing idea.
My understanding is that Thorsten and the shuttle team have come up with their own procedural "shape-drawing" library.
There's been some on and off discussions on the forum and the list, to generalize this and move/copy it over to $FG_ROOT/Nasal/canvas to make it generally available to all aircraft developers, but also so that it can be used for other purposes.

I haven't been following fg development over the last couple of months, so I don't know how things are standing currently.
If in doubt, I'd suggest to reach out to Thorsten or one of the shuttle coders (RIchard ?) to see what they have to say.

That being said, it would obviously make sense to "version" such a module, so that front-end code can make certain assumptions about the functionality available (or not). We ran into this with the MapStructure stuff, so that artix and a few others ended up copying certain modules to their aircraft and basically "forked" stuff that was never intended to be forked at all.

This could have been prevented, if the coresponding Nasal modules has a notion of versioning.


I thought there might be a wiki article or forum topic, but cannot seem to find it at the moment.

Anyway, like I said, it would seem a like a good idea to reach out to folks who have previously done related Canvas/Nasal coding, I believe that may also apply to the extra500 folks - but like I said, I am not really following the project for the time being, so take all of this with a grain of salt (of course).


EDIT: take a look at this topic for starters: Shuttle 2D drawing helpers / G1000 effort ?

By the way, there is also rleibner's work here: http://wiki.flightgear.org/Canvas_News#Plot2D_Helpers
Image

Unfortunatley, the bottom line probably is that we're lacking some integration/oversight here, i.e. tons of unnecessary duplication in heavily related areas.

I believe both, Stuart and James were also once talking about such a procedural drawing library for the FG1000/2D panels/HUD porting efforts, so you could also try to reach out to them via the devel list.
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: Who is working on / using navdisplay code?

Postby Octal450 » Fri Nov 30, 2018 9:01 pm

The A3XX ND in the IDG is self contained, not from FGDATA. It is very connected to the FMGS, AP, and such, so I do not recommend adapting/using it unless you are prepared to reverse many of my changes I made when I implemented it, or port our FMGS and AP code.

Probably best to start with the ND code from the Boeing ND or Airbus ND in FGDATA.

Kind Regards,
Josh
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: Who is working on / using navdisplay code?

Postby Hooray » Sat Dec 01, 2018 11:08 am

The current state of the navdisplay.mfd code is extremely messy - anyone hoping to use this elsewhere, should probably read up on how the MapStructure MVC framework works, to come up with additional layers and move ND logic out of navdisplay.mfd into dedicated MapStructure "layers" - this is something that Stuart has been doing over the course of the last year as part of this FG1000 project. In the process, it is likely that people will need to adapt/extend the MapStructure framework to make new types of layers possible. But given the current state of affairs, it's the right thing to do, i.e. incrementally adapt MapStructure to phase out hard-coded stuff in navdisplay.mfd and refactor the mess that is taking place there.

Like I said, it would probably be a good idea to reach out to the shuttle/extra5000 folks and rleibner for anything involving 2D drawing APIs, because they have come up with their own solutions anyway.

Anything involving svg.nas (the scripted SVG parser) should probably be coordinated with Stuart specifically, because he stated on several occasions that he's been wanting to generalize his FG1000 so that people can create new types of "skins" (or even instrument styles) at the mere cost of swapping a few SVG/XML files.

As a matter of fact, I have previously shared patches with Stuart that extend svg.nas so that it supports raster images directly, as well as included SVG files. This kind of work would make it possible to still use Nasal back-end logic, while allowing non-coders to use something like Inkscape to add/edit and maintain their MFD "pages" and page elements.

EDIT: See: http://wiki.flightgear.org/Canvas_Draw
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: Who is working on / using navdisplay code?

Postby jsb » Sun Dec 02, 2018 3:38 pm

Hi, thanks for creating the page on the wiki, I was just about to do the same. I will add my ideas to the page :)
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Who is working on / using navdisplay code?

Postby Hooray » Sun Dec 02, 2018 4:23 pm

I think there is quite a bit of existing code that could be copied and adapted. Thorsten's work is certainly a good starting point.

My suggestion would be to prototype the whole thing using a single Canvas GUI dialog for testing purposes, that will speed up things considerably. As a matter of fact, even developing the library as an "addon" might be a good idea to ensure that people can easily get involved in testing. Besides, this would ensure that there is no breakage introduced, because it would be developed as a new module.

I do think it's a good idea to incrementally hook up parts of this to svg.nas, i.e. to support more primitives there. This, too, would be a good way to grow the library, while also ensuring that people using SVG/Inkscape can benefit from this work.

Obviously, there is going to be a more abstract layer for drawing avionics elements ("widgets"), but that would ideally be using the lower level 2D API as its back-end.

As a matter of fact, James recently mentioned that he was hoping for people to come up with a parser to re-implement the existing HUD functionality (README.HUD) on top of the Canvas system. Given the overlap here, it would actually seem like a good idea to bootstrap such a parser by coming up with the 2D primitives to make this happen, this could be prototyped using Thorsten's groundwork, maybe in conjunction with some of rleibner's work - and possibly with ideas taken from the extra500 ?

Given the different modules involved here, I do think making this an addon for the duration of the protoype phase would actually be a good idea, because it would be lightweight not very invasive at all. In other words, we could get really fancy and try all sorts of new stuff, without stepping on anyone's toes.

For example, we could simply copy useful GPL'ed stuff into the new addon, and begin using it to prototype a 2D drawing API, and hook that up to svg.nas and/or a dedicated Nasal module to parse existing HUD XML.

This would ensure that we have a good stress test for the API (benchmarking, profiling, debugging), while also making sure that the API becomes sufficiently powerful and flexible.

I think James and Stuart have come up with their own 2D drawing primitives, so looking at some of their code might also be interesting. Stuart stated specifically, that he'd like to see the FG1000 evolve to a point where people can simply replace "pages" and "page elements" with custom MFD specs to "style" the FG1000.

FWIW, I actually once began writing a parser to even parse/interpret 2D instruments and panels:
http://wiki.flightgear.org/Howto:Parsin ... the_Canvas
Image

Note that these (writing Nasal parsers for legacy HUDs/2D panels to process them via Canvas) are actually ideas that James came up with originally:

http://www.mail-archive.com/flightgear- ... 38629.html
James Turner wrote:Moving the HUD to use the Canvas would be a great step from my point of view, since it and 2D panels (which I am happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally)
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 4 guests