Board index FlightGear Development Aircraft Cockpit development

FG1000 in 2D panels or fgpanel

Discussion about creating 2d and 3d cockpits.

FG1000 in 2D panels or fgpanel

Postby quique086 » Sat Jan 12, 2019 10:44 pm

Hi,

I wanted to ask if it is posible to add the FG1000 display to a 2D panel or to use it with fgpanel.

Thanks!

Enrique
quique086
 
Posts: 2
Joined: Sat Jan 12, 2019 10:06 pm

Re: FG1000 in 2D panels or fgpanel

Postby Hooray » Sun Jan 13, 2019 5:46 pm

quique086 wrote in Sat Jan 12, 2019 10:44 pm:I wanted to ask if it is posible to add the FG1000 display to a 2D panel or to use it with fgpanel.


Hi & welcome,

the short answer is this: The FG1000 is based on the so called "Canvas" system and makes heavy use of OpenSceneGraph (OSG) code and so called "Nasal" scripting - neither of which is supported by the fgpanel code base, which predates the Canvas/Nasal systems by many years - as a matter of fact, fgpanel is basically extracted from FlightGear's "xml/texture" based 2D instrument subsystem.

Making canvas based instruments work via fgpanel is not straightforward, and the core developer who came up with fgpanel, specificaly said that he considers it obsolete due to his ongoing Phi/mongoose work. The latter of which provides support for streaming FlightGear textures to another process over http, which ThomasS adapted to also stream an arbitrary Canvas texture over http, a feature that got recently reviewed/integrated by TorstenD: http://wiki.flightgear.org/Read_canvas_image_by_HTTP

Image

In addition, there is a dedicated Qt-based re-implementation of the Canvas system by another FlightGear core developer (James Turner): http://wiki.flightgear.org/FGQCanvas

Image

Apart from that, the Canvas system works using the notion of so called "placements" that merely replace a texture based on its identifier at runtime - which is to say, that it should be relatively safe to try if this works for 2D panels (see the Canvas placement API).

Likewise, even if this should not work "out of the box", it should not take more than 5 lines of C++ code to change this, simply because all that is needed for this to work, is changing the OSG node traversal to also traverse the 2D panel graph. Anybody familiar with C++ should be able to implement this in a few minutes - especially, because there is already a hard-coded NavDisplay, and other od_gauge based display (agradar, wxradar) that are basically using the same mechanism.

In other words, if you cannot get this to work, feel free to file a feature request - or let us know if you are able to patch/rebuild fgfs from source, so that I can provide the corresponding pointers to get you going.
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: FG1000 in 2D panels or fgpanel

Postby Octal450 » Sun Jan 13, 2019 10:12 pm

TL:DR Answer: No, unless you want to submit a patch to FG to make it possible

J
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: FG1000 in 2D panels or fgpanel

Postby Hooray » Sun Jan 13, 2019 11:53 pm

it0uchpods wrote in Sun Jan 13, 2019 10:12 pm:TL:DR Answer: No, unless you want to submit a patch to FG to make it possible


Actually, I wouldn't simply discount the idea - my response mentioned already the fact that the idea is not as far-fetched as it may seem to people not familiar with the code in question.

The point being not just that Torsten stated fgpanel would now be superseded by Phi (which in turn supports streaming Canvas textures these days), but that the 2D panel code does in fact use so called od_gauge instruments (=owner-drawn), which is also how the Canvas system started out, i.e. both systems were basically sub-classing/using the same class. Under the hood, it's using an OSG StaticTextureVisitor to traverse the scenegraph and replace the static texture with the dynamic one.

Thus, the only thing that really matters is having an identifier token for the visitor, and obviously using a scenegraph handle that contains the node to be replaced.

Without having looked at the code in question (and without having access to fgfs), I would definitely recommend playing with this - because ultimately it depends really only on the node that the visitor is traversing and the token that is used to look up the matching texture.

If you can make the Canvas system replace/attach to a static panel texture to show canvas contents, you can also make it show the FG1000. You may be in for a surprise here, under the hood the same mechanisms are in use, and the APIs involved are fairly basic, too.

Let's keep in mind that the 2D panel code only works in terms of static textures stacked on top of each other - the only exception being od_gauge based instruments (wxradar, agradar, groundradar, navdisplay), which are using static textures that are to be replaced with the dynamic ones later on.

In turn, the only relevant "output" that a Canvas creates is in fact also an OpenGL texture.

PS: You should be able to invoke addPlacement() using either combination of texture/node/parent to "filter" the graph. If you don't mind experimenting a bit, I'd suggest to dump the scenegraph (debug menu) and use a really simple location/aircraft to see what the scenegraph looks like. I wouldn't be that surprised if you can just make it work without having to patch FlightGear at all (again, without access to fgfs and without having looked at the code, purely based on the underlying texture visitor/replacement mechanism being de-facto the same). Personally, I'd expect event handling to be possibly problematic, because that is touching issues that we ran into when we began supporting Canvas widgets rendered via PUI (which is kinda using the same basic OpenGL functionality that the 2D panels code is using).
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: FG1000 in 2D panels or fgpanel

Postby Octal450 » Mon Jan 14, 2019 12:58 am

I'm not discounting the idea, I'm just summarizing your answer to his question.

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: FG1000 in 2D panels or fgpanel

Postby Torsten » Mon Jan 14, 2019 7:40 pm

There is no way to display the fg1000 in fgpanel but there is FGQCanvas which is under active development.
It's main purpose is to display Canvas based instruments on remote devices. It runs on IOS, Android and of course any desktop system with Qt support - even on the Raspberry PI.
The fg1000 is probably not fully supported but I am quite sure James will target any issues reported.

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux


Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 0 guests