Board index FlightGear Development Canvas

Developing a Canvas Cockpit for the CRJ700

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.

Developing a Canvas Cockpit for the CRJ700

Postby legoboyvdlp » Mon Jul 06, 2015 3:28 am

Hi,
Hazma and I are beginning to make a canvas CRJ700.
Problem is, we don't know how to.
I personally would like to work on the PFD first...

So what do I need to know, can I have any snippets,
Also, how do I interface the controls to change something on the displays?
Thanks!
Jonathan / Lego
User avatar
legoboyvdlp
 
Posts: 7279
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: next
OS: Windows 10 HP

Re: Developing a Canvas Cockpit for the CRJ700

Postby hamzaalloush » Mon Jul 06, 2015 4:00 am

To be fair, our best bet is the wiki, as it's hard to come up with a summation that's better then that written on the wiki page.

Canvas related development would require knowledge with writing in Nasal, familiarity with the Property Tree and possibly making art work.

I would suggest focusing now on improving these skills, reading the wiki article, and exploring examples on Canvas-ready aircraft, one of which is the c172p-canvas.
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Developing a Canvas Cockpit for the CRJ700

Postby legoboyvdlp » Mon Jul 06, 2015 4:28 am

I read the wiki, and somewhere it said to check here as sometimes it can be outdated, so I did. Any help would be appreciated!
Especially experienced people like artix, Gjis, Seattle team... ;)
User avatar
legoboyvdlp
 
Posts: 7279
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: next
OS: Windows 10 HP

Re: Developing a Canvas Cockpit for the CRJ700

Postby wkitty42 » Mon Jul 06, 2015 1:10 pm

hamzaalloush wrote in Mon Jul 06, 2015 4:00 am:I would suggest focusing now on improving these skills, reading the wiki article, and exploring examples on Canvas-ready aircraft, one of which is the c172p-canvas.

there's a c172p-canvas? i wonder if the c172p-detailed guys know about that and/or if it will affect their work this late in the game one week before the next freeze...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5911
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Developing a Canvas Cockpit for the CRJ700

Postby legoboyvdlp » Mon Jul 06, 2015 1:18 pm

The old c172p had a 2d one and ifr one and a canvas one
User avatar
legoboyvdlp
 
Posts: 7279
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: next
OS: Windows 10 HP

Re: Developing a Canvas Cockpit for the CRJ700

Postby wkitty42 » Mon Jul 06, 2015 2:24 pm

i knew about the flat (and ugly) 2D panel but i didn't know about an ifr only or canvas one... there was some recent discussion about getting the 2d panel back into the -detailed craft and i think they may have mentioned combining the other two... ok...

[/OT]
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5911
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Developing a Canvas Cockpit for the CRJ700

Postby hamzaalloush » Mon Jul 06, 2015 5:13 pm

Hi Waldo,

not really off-thread... this lead to me looking at the example.

in $FGDATA/Aircraft/Instruments-3d/canvas-test/ you'll find 3 files which are used by the old c172p: canvas-test.nas CMDU.ac screen-test.png

the "CMDU.ac" is a 3d object that contains a mesh with a 256x256 transparent texture "screen-test.png".

it's implementation in $FGDATA/Aircraft/Instruments-3d/canvas-test/canvas-test.nas is:

Code: Select all
# ==============================================================================
# DEMO
# ==============================================================================
var canvas_demo = {
  new: func()
  {
    debug.dump("Creating new canvas demo...");

    var m = { parents: [canvas_demo] };
   
    # create a new canvas...
    m.canvas = canvas.new({
      "name": "PFD-Test",
      "size": [1024, 1024],
      "view": [768, 1024],
      "mipmapping": 1
    });
   
    # ... and place it on the object called PFD-Screen
    m.canvas.addPlacement({"node": "PFD-Screen"});
    m.canvas.setColorBackground(0,0.04,0);
   
    # and now do something with it
    m.dt = props.globals.getNode("sim/time/delta-sec");
    m.gmt  = props.globals.getNode("sim/time/gmt");
   
    var g = m.canvas.createGroup();
    var g_tf = g.createTransform();
    g_tf.setRotation(0.1 * math.pi);
   
    m.text_title =
      g.createChild("text", "line-title")
       .setDrawMode(canvas.Text.TEXT + canvas.Text.FILLEDBOUNDINGBOX)
       .setColor(0,0,0)
       .setColorFill(0,1,0)
       .setAlignment("center-top")
       .setFont("LiberationFonts/LiberationMono-Bold.ttf")
       .setFontSize(70, 1.5)
       .setTranslation(384, 5);

    m.dynamic_text =
      g.createChild("text", "dynamic-text")
       .setText("Text node created at runtime.")
       .setFont("Helvetica.txf")
       .setFontSize(50)
       .setAlignment("center-center");
    m.tf = m.dynamic_text.createTransform();
    m.tf.setTranslation(384, 200);

    m.path =
      g.createChild("path")
       .moveTo(25, 12.5)
       .lineTo(325, 25)
       .lineTo(150, 200)
       .cubicTo(150, 225, 50, 225, 50, 200)
       .close()
       .setTranslation(200, 70)
       .setStrokeLineWidth(4)
       .setStrokeDashArray([10,6,3,3,6])
       .setColor(0.2,0.3,1);

    m.rot = 0;
    m.pos = 200;
    m.move = 50;
   
    return m;
  },
  update: func()
  {
    var dt = me.dt.getValue();

    # Change the value of a text element   
    me.text_title.setText(me.gmt.getValue());
   
    # Animate a text node a bit
    me.rot += dt * 0.3 * math.pi;
    me.tf.setRotation(me.rot);
   
    me.pos += me.move * dt;
    if( me.pos > 900 )
    {
      me.pos = 900;
      me.move *= -1;
    }
    else if( me.pos < 150 )
    {
      me.pos = 150;
      me.move *= -1;
    }
    me.tf.setTranslation(384, me.pos);

    settimer(func me.update(), 0);
  },
};

setlistener("/nasal/canvas/loaded", func {
  var demo = canvas_demo.new();
  demo.update();
}, 1);


and it's decleration in $FGDATA/Aircraft/c172p/c172p-canvas-set.xml by:

Code: Select all
  <canvas_demo>
    <file>Aircraft/Instruments-3d/canvas-test/canvas-test.nas</file>
  </canvas_demo>


using CMDU.ac as model in $FGDATA/Aircraft/c172p/c172p-canvas-set.xml by:

Code: Select all
<model>
    <path archive="y">Aircraft/c172p/Models/c172p-canvas.xml</path>
    ...
</model>


and it's placement in $FGDATA/Aircraft/c172p/Models/canvas-test.xml by:

Code: Select all
<?xml version="1.0"?>

<PropertyList>

 <path>Aircraft/Instruments-3d/canvas-test/CMDU.ac</path>
 <offsets>
   <heading-deg>90</heading-deg>
   <roll-deg>75</roll-deg>
   <pitch-deg>0</pitch-deg>
   <x-m>-0.15 </x-m>
   <y-m>-0.21 </y-m>
   <z-m>-0.2 </z-m>
 </offsets>
</PropertyList>


Image

Image

Image
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Developing a Canvas Cockpit for the CRJ700

Postby wkitty42 » Mon Jul 06, 2015 6:52 pm

thanks for the explanation, hamza... yeah, that's with the 3.4 and older c172p... there's only one -set file (at this time) in the new c172p(-detailed)... there is work being done to re-add the 2d panel but i'm not aware of anything else separate... AFAIK, everything will all be accessible from inside the one -set file... maybe the 2d panel will have a -set file so it can be used on a separate monitor for some kind of remote monitoring or controlling... i don't know, though... i just try to follow the development, give some input where i can and then test as best i can from a complete newbie, non-pilot, "i just wanna have fun" POV ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5911
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Developing a Canvas Cockpit for the CRJ700

Postby Hooray » Tue Jul 07, 2015 9:56 pm

The c172p-canvas was just a reference/example to demonstrate how to use/integrate Canvas on aircraft, back in the early days of the Canvas system, when everything was still being prototyped, and when we didn't have much in terms of examples, code snippets and docs. These days, the wiki (and existing code) should satisfy almost all needs.

Normally, you would start by prototyping instruments using a standalone GUI dialog, which greatly simplifies the whole prototyping process, because reloading/switching aircraft in FG still works only very unreliably - equally, lose coupling is much easier to accomplish by using a standalone GUI dialog.

For starters, you will probably want to use the Nasal console and play with the code snippets from: http://wiki.flightgear.org/Canvas_Snippets

The whole idea of this article is to get people started doing basic stuff, and then let them integrate things as required - i.e. "Canvas Snippets" is all about providing building blocks that can be adapted as needed.

In other words, feel free to ask questions or help improve the wiki docs if you think anything is missing - please do so via the main Canvas forum, we should usually be able to answer most questions pretty quickly, or at least provide snippets/pointers to snippets.

You will definitely benefit from understanding Nasal, and object-oriented programming in particular, a few fairly accessible introductory articles are these:

http://wiki.flightgear.org/Howto:Start_ ... s_in_Nasal
http://wiki.flightgear.org/Object_orien ... g_in_Nasal
http://wiki.flightgear.org/Object_Orien ... with_Nasal

Once you have worked through these and played with a few examples, I would suggest to look at the Canvas docs, the API reference, and the snippets on the wiki.

For prototyping purposes, I would suggest to create a standard canvas GUI dialog: http://wiki.flightgear.org/Howto:Creati ... ialog_file
And you should also learn how to use io.include() and friends to split up your Nasal sources into separate files and make things more modular.

Note that you don't need to be an experienced Nasal coder to use Nasal/Canvas, but understanding a few basic concepts will greatly simplify the whole process.
The other part of this is artwork, which is usually created/edited using the Inkscape SVG editor.

And it also makes sense to look at people who have previously done related work (e.g. Gijs, Hyde, artix, Philosopher, TheTom etc) - if in doubt, check the commit logs of aircraft using Canvas to look up whose involved.

(but please don't just send tons of PMs to those, but instead ask general questions on the forum, and offer to provide something in return, i.e. document your journey, help improve the wiki/docs or help improve/write tutorials etc)

For a few more relevant pointers/discussions, please see:
search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+animated+svg
search.php?st=0&sk=t&sd=d&sr=posts&keywords=canvas+animated+inkscape
search.php?st=0&sk=t&sd=d&sr=posts&keywords=nasal+canvas+animated+timers+listeners

(it would be great, if someone could copy relevant stuff over to the wiki so that these postings can be turned into a new wiki article)

Features closely related to existing stuff (think PFD, ND, EICAS/EFIS) would ideally be based on adapting, generalizing and refactoring existing code (as per Gijs' ND effort) though - but you would inevitably benefit from knowing how Nasal/Canvas work under the hood, especially in order to learn how to use the corresponding frameworks (think MapStructure), because most people have a hard time understanding the reasons for contributing to a generic/aircraft-agnostic effort even though their primary motivation is a single project only.

Feel free to get in touch via the forum/wiki if you have any specific questions and nobody else seems to be around to answer those.

strictly speaking, 3D modeling will remain largely irrelevant for anything involving MFDs, it will only start becoming slightly relevant when all prototyping is finished, i.e. when you hook up your Nasal/Canvas code and SVG artwork to the cockpit and stop using a standalone GUI dialog. Overall, 3D modeling has little (if any) bearing on 2D MFDs - and people focusing on that, merely demonstrate to fellow coders that their priorities/interests or skills are elsewhere (you could look at the FARMIN effort).
Last edited by Hooray on Tue Jul 07, 2015 10:10 pm, edited 1 time in total.
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Developing a Canvas Cockpit for the CRJ700

Postby IAHM-COL » Tue Jul 07, 2015 10:07 pm

Thanks for the pointers Hooray
A quick question.

In the past I remember Canvas caused a very massive performance hit. In my old laptop, even rendering aircraft useless...

Is this still the case? or is it on a per=case basis? or is this a past bug and we've moved out of the bump?

IH-COL
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4064
Joined: Wed Aug 08, 2012 5:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Developing a Canvas Cockpit for the CRJ700

Postby Hooray » Tue Jul 07, 2015 10:25 pm

Canvas is just a piece of technology - there are some early adopters/attempts who began using Canvas at a time when things were very much still in flux, which is why we have code snippets/instruments (and aircraft) where Canvas related functionality is significantly contributing to lag - I think this did apply to the m2000 and the extra500.

I haven't looked at any of those aircraft in months, so I cannot say if those problems have been addressed/fixed meanwhile - but there are a handful of examples for efficient Nasal/Canvas-based features, without them causing/contributing to significant lag. We have provided a bunch of "best practices" in various threads, and also offered 1:1 help to the efforts/people affected by this.

Some have refused to accept such advice, others simply disappeared over time. So I cannot say much about any particular aircraft. But Nasal and Canvas are just tools that can be misused - and they're "interpreted" tools, both of which are basically using the concept of a "virtual machine" internally, so there's a certain overhead due to all the indirection taking place - which is to say that you don't need to be an experienced C/C++ or OpenGL/OSG programmer to use Nasal and Canvas to create sophisticated avionics - which isn't unlike the YASim/JSBSim FDM engines (or the autopilot system), which also, can be mis-used to create inefficient constructs that end up slowing down the simulator significantly.

Then again, sometimes, there simply are very real bugs - like those in the property tree/effects code that TorstenD fixed a while ago, or the memory leak that Jabberwocky brought up on the forum, and that sanhozay identified - as long as people can provide actionable bug reports and reproducible test scenarios, there's a fairly good chance for bugs (and performance issues) to get fixed within 1-2 release cycles. But just coming here and saying that feature XYZ is broken or slows down the simulator isn't helping anybody, unless you can provide all the information that is needed that people who understanding the underlying subsystems can nail down the problem and see if there's an actual problem or not.

This also involves stating exactly what hardware you are on, and what your other startup/runtime settings are - as of now, Canvas doesn't provide native support for shaders, so it will be using OSG/shivaVG for all hardware accelerated graphics, which should usually be sufficiently fast - but there are known constructs/usage patterns that are infamous for triggering unnecessary updates/re-drawing, which should be avoided.

The other obvious issue is that Canvas does require FBO support.

People writing Nasal/Canvas code should ideally understand that Canvas is not just a VM but also a state machine to some extent, so even redundant/unnecessary state changes (all of which are going through the property tree usually) will trigger updates/re-drawing under certain circumstances, which is to say that this should be avoided - and which is why I, and a handful of others, have been trying to enforce a framework-centric development philosophy when it comes to Canvas development, so that people don't use Canvas directly, but instead come up with frameworks for functionality that they need, to encapsulate any Canvas specific functionality - that we- can help review/improve over time, without having to touch tons of code files, instruments, aircraft etc

The underlying idea can be seen in the ND and MapStructure efforts, neither of which needs to be touched by aircraft/GUI developers to add/create an ND or chart/map.

In summary, Canvas certainly isn't being maintained as actively as it once used to be, but -like Nasal- Canvas is just a technology enabler, and people should introduce abstraction layers to use the system, so that possibly problematic usage patterns can be more easily encapsulated, but also reviewed/edited and optimized over time.

But please don't expect any of the people involved in Canvas related efforts to answer such broad questions with a single "yes" or "no", without also providing a proper context.
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Developing a Canvas Cockpit for the CRJ700

Postby IAHM-COL » Tue Jul 07, 2015 10:40 pm

Thanks for the comprehensive response Hooray.
I quite can't provide much detailed information at the moment. because I don't have it on the tip of my keyboard.

I found the whole canvas effort really neat. And I'd love it to work and operate efficiently. Indeed as you point out some of the problems could be related to early implementations, others to memory leaks. But the principle of canvas is really appealing to me. Also, particularly seeing some implementations on which the system worked nicely makes the canvas structure interesting --thinking on particular over tikibar's B752.

I found myself not to have the entry -level technological knowledge (source code writing skills) to attempt it... but I may need to drive myself over that wall sometime. Specifically, thinking over the B722 project.

Best,
IH-COL
If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall
User avatar
IAHM-COL
Retired
 
Posts: 4064
Joined: Wed Aug 08, 2012 5:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Developing a Canvas Cockpit for the CRJ700

Postby Hooray » Tue Jul 07, 2015 10:58 pm

the whole point of developing frameworks and encapsulating functionality there is to allow people to merely "request" a certain component (think ND, PFD, map, EICAS) and "configure" it as needed (think fonts, colors, symbols, events, images etc). And once you look at the integration "code" that loads a working ND, you will see that it is merely a mark-up dialect sligthly different from XML (in fact, it could be XML just as well, but it doesn't yet make sense to provide an XML dialect currently).

In basic terms, you are merely telling the system that you want a certain component, and how you want it to look - and you are doing that using a "configuration file" that could just as well be in a different format (it merely happens to be using JSON/hash syntax, because that's easy to support using Nasal hashes): http://wiki.flightgear.org/Canvas_ND_Framework

Equally, even creating/adding new features to the ND code is fairly accessible these days, and people don't need to be proficient coders or even understand how Nasal/Canvas work behind the scenes - for this to work, there are tons of assumptions made on what people want to do, but that is generally a safe thing to do in a use-case specific framework (think for creating PFDs, NDs, HUDs or other MFDs).

Under the hood, all that is needed is a simple animation framework to show/hide, update and animate SVG symbols using Nasal timers and listeners.

The basic ideas are summarized at:
http://wiki.flightgear.org/Howto:Coding ... _Framework
http://wiki.flightgear.org/Canvas_MFD_Framework
http://wiki.flightgear.org/Canvas_PFD_Framework
http://wiki.flightgear.org/Canvas_Animation_Framework
http://wiki.flightgear.org/Canvas_EFB_Framework

As long as people continue to fail creating/using (and extending/maintaining existing) frameworks, they will also fail at Canvas in general, and reaching good Canvas performance in general - simply because of the way Nasal, Canvas and the property tree work - all of which are abstraction layers, and each layer will only expose a subset of the required functionality, so there are inevitably many opportunities to make things unnecessarily slow. Which, at the same time, is a testimony to the accessibility of the system - because -all of a sudden- we have people writing "code" using back-end code in C, C++, OSG and OpenGL without them necessarily having a strong background in any of those technologies.

With Nasal/Canvas, you are basically given a complex aircraft that will "fly" on autopilot just fine without you ever having taken any flying lessons - yet, people complain about "performance" issues, despite never having taken the time to learn more about what it is doing under the hood.

Canvas will undoubtedly improve even more over time - but there's zero chance for any of the existing "slow" code to automatically benefit from any such updates, unless it happens to be actively maintained in the time to come, or does indeed use a framework to encapsulate key functionality properly: search.php?st=0&sk=t&sd=d&sr=posts&keywords=Nasal+Canvas+frameworks
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Developing a Canvas Cockpit for the CRJ700

Postby legoboyvdlp » Tue Jul 07, 2015 11:07 pm

I think we will use those frameworks.

You know, a gui to create a basic file to start with, you know, you give it options and it gives you the file would be nice though not needed!
User avatar
legoboyvdlp
 
Posts: 7279
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: next
OS: Windows 10 HP

Re: Developing a Canvas Cockpit for the CRJ700

Postby Hooray » Tue Jul 07, 2015 11:16 pm

well, once you begin reading, you will see that this is more about creating and "establishing" such frameworks before "using" them. Especially if you are doing something unprecedented - otherwise, you would probably still want to look at existing stuff and copy&paste things as needed. In fact, redneck & omega95 once mentioned that they were contemplating to use Gijs' ND code base for implementing PFDs (using the same hash-based configuration approach).

Generation skeletons will not get you very far to be honest - I could write such a skeleton generator within 2-3 hours - in fact, we do have something like this on the wiki for creating examples procedurally using a few templates: http://wiki.flightgear.org/Category:Nas ... _Templates

This could be easily adapted for Canvas stuff, and it would "run" without you having to install any tools locally.

But as you will see once you start working with the snippets, you will also have to understand a few programming concepts before you start the configuration stuff, or outsource/delegate this to someone else - which is how the ND/MapStructure frameworks work under the hood: aircraft developers merely "configure" what they need, and coders provide routines for doing all the fancy stuff, while aircraft devs simply provide any custom artwork they want to see updated/animated.
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: 11437
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest