Board index FlightGear Development Canvas

Using canvas in a 3d instrument ... but ...

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.

Using canvas in a 3d instrument ... but ...

Postby abassign » Mon Oct 30, 2017 10:52 am

I try to reproduce the methodology describe in the link: "Using canvas in a 3d instrument" ( http://chateau-logic.com/content/flightgear-using-canvas-3d-instrument) in my FGFS code for G91. But there are some issues, I think that the basic description of Canvas creation on 3D FGFS objects is currently rather poor.

I entered the NASAL code as described, this code is followed correctly, but does not go ahead because it reports an error for the reference of an object in the SVG file that I want to bind to a surface:

This is the NASAL code execute in G91-set.xml file:

Code: Select all
    <nasal>
        <G91>
            ...
            <file>Aircraft/G91/Models/Parts/Cockpit/Gauges/Nasal/canvas_instrument.nas</file>
            <file>Aircraft/G91/Models/Parts/Cockpit/Gauges/PHI/CanvasPHIWind01.nas</file>
            ...
        </G91>
    </nasal>


This is the NASAL code insert in the folder that contain the SVG file and .ac file:

Code: Select all
var CanvasPHIWind01=
{
    new : func
    {
        var obj = CanvasInstrument.new("Aircraft/G91/Models/Parts/Cockpit/Gauges/PHI/PHIWind01.svg", "PHIWind01M", 0,0);
        obj.face = obj.get_element("face");
        obj.face.setCenter(512,512);
        obj.canvas.setColorBackground(0.36, 1, 0.3, 0.00);
        obj.update_items = [
            PropertyUpdateManager.new("instrumentation/altimeter/indicated-altitude-ft", 1.0, func(alt_feet)
                                    {
                                        obj.face.setRotation(alt_feet*0.36*0.01744591);
                                    })
        ];
    },
};
aircraft.alt = CanvasPHIWind01.new();


The name of SVG file in my test is:
"PHIWind01.svg"

I'm sure the SVG file is read correctly because if I rename the NASAL program I get an error if I did not find the file.

If I open the SVG file with an editor I look he layer name "face", so it seems all right:

Code: Select all
</metadata>
  <g
     inkscape:label="face"
     inkscape:groupmode="layer"
     id="layer1"
     transform="translate(0,-28.362161)"
     style="display:inline">
    <g


But when the NASL code is execute (The NASAL code is Execute in the ..-set file as explained in the instructions.
Along with this NASAL file there is a second file that is run earlier and contains the standard methods for creating elements with NASAL elements.
This file also runs and reports a debug message that is shown below:

Code: Select all
PHIWind01M: Parse SVG 1 for surface CanvasPHIWind01MFace


But immediately after uploading the SVG object to display I find this message:

Code: Select all
Failed to locate face in SVG
Nasal runtime error: non-objects have no members
  at /home/abassign/Documenti/fgfs/G91/Models/Parts/Cockpit/Gauges/PHI/CanvasPHIWind01.nas, line 12
  called from: /home/abassign/Documenti/fgfs/G91/Models/Parts/Cockpit/Gauges/PHI/CanvasPHIWind01.nas, line 22


Which message says he did not find in the SVG the required layer!
At this point, I could no longer go on as the message seems to be such that I do not give another operating method.

My suspicion is that I'm using a wrong methodology, but I do not understand what it can be. Besides, there is a second problem: but how do I define the object in the .ac file that I want to cover with the image?

Thanks for your help :)
Developer of the program https://wiki.flightgear.org/Julia_photoscenery_generator
FDM developer of the G91R1B aircraft https://wiki.flightgear.org/FIAT_G91R1B
JSBSim collaborator
abassign
 
Posts: 947
Joined: Mon Feb 27, 2012 6:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2020.4
OS: Ubuntu 20.10

Re: Using canvas in a 3d instrument ... but ...

Postby Hooray » Mon Oct 30, 2017 11:01 am

Just briefly (have only skimmed through your posting), to be sure that the problem is not due to the SVG features you are using, it would be best to use a really simple (possibly hand-crafted) SVG file and try getting that to work first.

Your last question is covered at: http://wiki.flightgear.org/Howto:Add_a_ ... r_aircraft

In general it is worth pointing out that SVG support in FlightGear/Canvas is rather simple for the time being - there is a simple parser (written in Nasal) that basically looks for a handful of known features/tags that are then mapped to the corresponding Canvas primitives. Thus, you may be running into these restrictions when dealing with files that may have been generated automatically (e.g. using an editor).

To sum things up, I would suggest to only look at dealing with SVG files once you have everything else working correctly - e.g. a GUI placement displaying a raster image or a text string:

http://wiki.flightgear.org/Canvas_Snipp ... ter_Images
http://wiki.flightgear.org/Canvas_Snipp ... t_Elements

Once that is working, you can be reasonably sure, that the boilerplate is in place - when dealing with SVG files, you really need to make sure that you are using a subset of SVG that the parser supports - otherwise, you'd need to extend the parser, which I once demonstrated/documented, too: http://wiki.flightgear.org/Howto:Extend ... e#Examples

Image


(to be fair though, the svg.nas module should report unknown tags/attributes IIRC, but depending on your OS, you may need to inspect the fgfs.log file to learn more, or refer to the loglist in the Nasal Console dialog)
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: Using canvas in a 3d instrument ... but ...

Postby Richard » Tue Oct 31, 2017 12:54 am

abassign wrote in Mon Oct 30, 2017 10:52 am:I try to reproduce the methodology describe in the link: "Using canvas in a 3d instrument" ( http://chateau-logic.com/content/flightgear-using-canvas-3d-instrument) in my FGFS code for G91. But there are some issues, I think that the basic description of Canvas creation on 3D FGFS objects is currently rather poor.


Firstly take the example that I wrote exactly as it is and get it to work. Then change things - and test after each change - regardless of how small it may seem. This way you will find out what broke.

If the example in my article doesn't work when copied exactly as posted then let me know and I'll fix it.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Using canvas in a 3d instrument ... but ...

Postby V12 » Tue Nov 07, 2017 10:44 am

Download B 747/400 from fgaddons, this aircraft has nice simple implementation of the canvas PDF and ND. There are another advanced solutions for custom canvas, try IDG's A3xx family. Or try my Concorde (https://github.com/BAWV12/Concorde), there are 2 way canvas implementations - TCAS and WXR uses basic MapStructure layers FTC and WXR with customised traffic controler, captain's tablet uses full implementation of IDG's nav display.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Using canvas in a 3d instrument ... but ...

Postby Richard » Wed Nov 08, 2017 10:59 am

try changing the line that reads
Code: Select all
PropertyUpdateManager.new("instrumentation/altimeter/indicated-altitude-ft", 1.0, func(alt_feet)


to read
Code: Select all
props.UpdateManager.UpdateFromProperty("instrumentation/altimeter/indicated-altitude-ft", 1.0, func(alt_feet)


This will require FGData from after 19-sept-2017
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Using canvas in a 3d instrument ... but ...

Postby Hooray » Sun Nov 19, 2017 12:48 pm

V12 wrote in Tue Nov 07, 2017 10:44 am:Download B 747/400 from fgaddons, this aircraft has nice simple implementation of the canvas PDF and ND.


Honestly, if you are new to basic Nasal and Canvas concepts, i would not recommend looking at the mess the ND has become - it was written at a time when we were still tinkering with the Canvas system, and it was only shared well after it had grown to a certain point where simply rewriting the code was no longer feasible, despite having a number of rather serious restrictions (not supporting reuse/modularity, independent instances, styling etc) - we began adding these things well after the fact, and that is how the existing mess came to be - it would have been much better to create a MFD framework first and then take it from there.

However, unfortunately the opposite took place.

These days, I am convinced that most avionics don't need to deal with the low-level Canvas primitives directly, but that we need an MFD framework that actually encapsulates the most important use-cases (fetching/updating properties, re-computing values and updating elements structured in a Device/Page-oriented fashion). Timers and listeners should rarely be used directly - instead, anything dealing with animations should use an abstraction mechanism -otherwise, we will continue to see tons of unmaintainable Nasal code added to FlightGear that nobody is ever going to rewrite.

Like Thorsten and Richard said on several occasions - it is definitely possible to develop sophisticated avionics in Nasal space using the Canvas system, but it's a long and error-prone road if you don't have a solid background in coding and preferably experience coding similarly complex systems in FlightGear. To most people this simply won't apply, which is why using Nasal and the Canvas system "as is" is usually not a good idea, or you'll end up with nice-looking stuff that barely performs well for the majority of end-users, with many other contributors blaming Nasal and the Canvas system as the culprits.

In my opinion, we should have added dedicated MFD related elements to the Canvas system 5 years ago to help people better organize their MFD, while allowing the underlying C++ code to come up with efficient OSG-level representations - i.e. stuff like:
  • MFDScreen
  • MFDPage
  • MFDPageElement
  • MFDControl (button, dial)
  • MFDEvent

And most importantly, we should have introduced dedicated elements for dealing with animations without going through Nasal space using timers and listeners, and that also means adding state machine support to the Canvas system.

This is because the real issue arises once people want to interact with a Canvas MFD (think PFD, ND, FG1000) using out-of-process tools (FGQCanvas, Phi, tablet PCs, Android phones, Rasberry Pi etc), at which point all crucial internal state that merely resides in Nasal/scripting space is hugely problematic - whereas everything that is part of the Canvas/Element-specific property tree hierarchy can be trivially supported without people having to know anything about Nasal.

I once summed up the whole challenge/dilemma here: http://wiki.flightgear.org/Canvas_Devel ... FlightGear

That is one of the reasons why I am convinced that Richard's MFD framework will change the way people are developing FlightGear avionics, while also providing a migration path to partially re-implement some parts using native C++ hooks - especially if this is done with an IPC mechanism like Emesary in mind.


Anyway, telling people to look at nasal/canvas code that was written 5 years ago and that is suffering from rather serious restrictions is probably not a good idea in my opinion. The ND code would look very different if we had used a MFD framework back then. And that even applies to the underlying MapStructure framework, had we had an API to register Nasal based Canvas elements, i.e. elements that can be prototyped, tested and implemented in scripting space.

What's been happening instead is hugely problematic because useful stuff is usually added without much/any concern for modularity or code reuse - while it is indeed possible to do something about that, that's more work than necessary - as can be seen by the MapStructure 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: 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 5 guests