Update to canvas API and SVG parser

[jsb]

Available on next now:
additional API methods path.ellipse, path. circle, path.square
SVG parser support for circle and ellipse so you can use those in inkscape, no need to convert them to path in inkscape and lose the specific edit features anymore.

enjoy

[Hooray]

Feel free to include the following patch in your next merge request, it adds support for the <image> tag to load raster images directly:

http://wiki.flightgear.org/Howto:Extend ... age.3E_tag


Note that this could be also extended to support other SVG files, too.

[jsb]

Forgot to mention it here: SVG parser supports <image> tag now, as long as the image is not embedded but linked.
The image file must be in a folder readable for FlightGear, e.g. an aircraft folder or an add-on folder. It is probably best to put the image and the SVG file into the same folder.

[Gavinmc42]

I was looking for a SVG to OpenVG parser and stumbled on this forum.

Years ago when the Pi's first came out I thought they might make good flight sim instruments.
Then the Zero's came out and boot from USB was possible.
Then VC4 acceleration code was made to work on Ultibo.

I have yet to find where all the SVG stuff is hiding in the Flightgear source.
But sending SVG files to the Zero to be rendered into OpenVG should be possible.
4 Zeros per Pi3B+ is a bunch of Flight Sim instruments.

Test code for PFD OpenVG
https://github.com/Gavinmc42/PFD

[Hooray]

FlightGear's SVG support is basically through its built-in scripting language (called Nasal, not unlike JavaScript) that maps a certain subset of SVG/XML directives (a handful) to FlightGear's built-in 2D drawing API called "Canvas", this happens through the FlightGear property tree which uses a simple listener-based interface to fire callbacks whenever certain nodes are created/changed (updated) - which in turn processes those properties to call the underlying C++ APIs, in the case of OpenVG this is indeed Shiva VG.

The code for all this can be found in simgear/canvas - i.e. $SG_SRC, check the wiki for details and additional pointers.

[Gavinmc42]

Yep found the canvas.
So simgear/canvas use shivaVG to do the SVG to OpenVG conversion.
What I want to try to do is send the SVG file(or raw OpenVG) to a Pi Zero via USB.
VGInit would send the SVG display data to the PI and then only the changing data from then on?

As a test I need some SVG instruments, where are they hiding in the source?

[jsb]

SVG files should be found in the FGDATA / Aircrafts. However, they are not standardized in Flightgear and there are different approaches on how to create instruments on a screen (e.g. EFIS) from drawing "everything" in inkscape and save it as SVG and animate elements with the scripting language to completely procedural approach, e.g. everything is drawn by scripted commands.
So I understand you have an existing SVG "painting" of your instruments and want to start with it?

[Gavinmc42]

No I draw OpenVG direct in baremetal on Pi's.
But it is a pain to design instruments that way.

A google found you guys are using Inkscape to make the SVG files, so I am trying to install that now on a Pi.
Don't have serious PC the kid will let me use, so old Linux PC and Pi's are my development boxes.

Khronos said years ago OpenVG will make SVG, Flash etc faster in embedded apps.
But I have yet to find any SVG to OpenVG code from those years.

Ok, Inkscape 0.92 is now installed on Pi. I noticed there are plugins that can do things like G-Code.
Now all I need to do is make a plugin that converts SVG to free Pascal OpenVG code:)
Was going to grab the biggest SVG instrument and see if that will convert.

The Orville got me interested again in LCARS and Orvllle graphics.
OpenVG should be able to do those too and with Zero's so low in price a full flight deck etc could be done.

Inkscape was a missing piece of the puzzle.
Obvious next step is 3D with Blender and OpenGLES but that lots more learning yet.
Doing things in Free Pascal means C/C++ source is not the first choice but that is ok they normally have huge dependencies anyway.

[Hooray]

The thing is, the SVG stuff is translated into properties using said scripting language, which in turn creates an OpenVG representation - but all the animations/updates basically result in a fresh set of OpenVG instructions. In other words, there is no single/clean 1:1 mapping between "SVG instruments" and OpenVG, because there are some abstraction layers involved (FG scripting, properties, timers and listeners triggering actions/callbacks).

For starters, you could take a look at Phi instead, which is indeed using pure SVG files, whereas the Canvas stuff in FlightGear is using a very roundabout hybrid appraoch that totally lacks any kind of formalization. For the sake of completeness, there is also a Qt based Canvas-backend (re-implementation).

Like you said though, the primary Canvas developer was indeed hoping to run Canvas avionics on RPi devices
Also, a number of long-term contributors are indeed hoping to make FlightGear compatible with modern OpenGL, so that using/supporting OpenGL ES would become an option.

[Gavinmc42]

Thanks, Phi has some SVGs to play with.
Need to figure out the look from the actions.
Some sort of Object based format?

Looks like Phi was intended as a Browser based system.
While Browsers do run on Pi's you really need a Pi3B+'s, 64bit OS and updated Mesa.
Gentoo64 is my current favourite 64bit OS on Pi3B+.
But these Chromium and Firefox browser don't run well on the single core Pi's.
SVG, HTML, CSS, JS all need to be parsed to make a baremetal browser.
They now need multicore 64bit CPU's as they tend to do software rendering as default.

A baremetal SVG to OpenVG parser would be a first step and probably about the 80% that would be needed to make simple instruments.
For 3D, OBJ/MTL to OpenGLES might be enough.
Lucky glass cockpits are mostly flat designs which can be mostly done with OpenVG.
The amount of updating data would be much less, some sort of protocol would be nice.
Does the industry have one already?

Pi's also have that GPIO port and so Touch/buttons can be connected to make real interactive instruments.
That's doable for the future.

Ultibo still does not have USB OTG serial working, so even though I can load the application via USB I cannot talk to it yet.
The serial uart works but that's extra wiring and even Can bus could be done using a SPI port and hat.
Too much like real instruments and my day job:)

My goal is to use Zero's without SD cards, so any home hobbyist (like me) could make a flight sim.
We do have Bluetooth LE talking, so using Zero W's is an option too.

I can understand the lack of formalised method, this is all new, even though I have been thinking about it for 5 years.
Knowing it could be done is not the same as knowing how to do it.

I did suspect the SVG to OpenVG might have been on the fly, I have done similar stuff for webpages on Pi data logger's.
That's a hard way to do it.

Virtual Instruments are about the look which is artists intepretation not a programmers interpretation.
Until I found out SVG was Inkscapes native format I did not know how to do instruments.
Doing a good looking display by code is very slow, which is why my PFD demo is so basic.

Seperating out the graphic design look from the code should allow for more flexibility.
Swap a svg file changes the look, but not the operating code.
I have done bitmaped instruments before, painful, vector graphics is the way to go.
However bitmapped background are useful, Povray does nice woodgrain.

Ultibo handles it bitmap images no problem, embedded or read from file.
Once ClearInk have a suitable display a paraglider nav system could be made for real.
Always wanted to make my own.

[Octal450]

jsb, I just want to personally thank you! You have no idea how annoying it was to convert to paths, then later have hard time adjusting it.

Looking forward to it!
Josh

[Gavinmc42]

I was looking at some of the Instrument SVG files and learning Inkscape.
Webpanel for the Cessna c172p is where I started first.

I don't want to be critical especially since I have only been on this forum for a few days and you guys have been doing this for years.
But Inkscape has options now to save as Optimised SVG and setting the precision.

Converting the default Inkscape SVG's to OpenVG is confusing, the Optimised SVG data is much easier to read.
Would the SVG parser have less trouble with Optimised SVG?
I think I spotted something about scripting Inkscape in command line to covert files?

It looks like you can change the default preferences at least for precision in Inkscape.
Is there a wiki somewhere on how to use and setup Inkscape to design Instruments?

I still have to learn how animated SVG works to see if that transfers to OpenVG.

I have no idea how Flightgear works apart from a few diagrams.
Is there a way to get the flight data going out a serial port?
Basic data like attitude, heading, airspeed, altitude etc

[Hooray]

Regarding your constructive feedback (what you call criticism), the thing is the SVG/XML parser we're using is extremely basic, it's only using/supporting a very tiny little fraction of what SVG provides, and that is accomplished by using a FlightGear-specific parser written in the FlightGear scripting language (Nasal) that looks for this SVG subset and translates that into Canvas properties (path, text/image) to tell the underlying C++ engine to dynamically create a matching OpenSceneGraph scene using primarily OpenVG paths.

I've previously extended that parser and shared instructions to demonstrate how this is done, more recently jsb has made some useful enhancements - but other than that, you cannot expect any SVG feature to just magically work:

http://wiki.flightgear.org/Howto:Extend ... SVG_module

Speaking in general, you would have to give it a try first, and then post your findings here. We could then discuss if it makes sense to extend the parser accordingly or not. A few weeks ago, I posted a link to a wiki article (tutorial) demonstrating the required steps, the example walks you through adding support for the <image> tag - which basically required 20 lines of code (ECMAScript-oriented)

While many SVG features might potentially come in handy, it isn't necessarily a good idea to extend the current parser "as is", there is a break-even point where adopting a different SVG-handling mechanism would be more lightweight or simply "better". Also, keep in mind, anything using svg.nas inevitably goes through props.nas (which is slow) and ultimately goes through the FlightGear property tree - in other words, there is quite a bit of bandwidth caused, depending on the complexity of the SVG DOM.

Regarding Inkscape scripting, I have previously written a simple Inkscape "plugin" to generate/customize FG/Canvas resources (SVG + Nasal code), and Stuart also used a few custom Perl scripts for the same purpose when he created the FG1000:

viewtopic.php?f=71&t=33594
http://wiki.flightgear.org/Howto:Hackin ... as_support

Is there a wiki somewhere on how to use and setup Inkscape to design Instruments?

Yeah, you could say there is such an article - but there are also different philosophies involved here, i.e. many of our MFD developers do indeed seem to prefer a procedural approach where they end up using code to customize/draw template-based vector art:

http://wiki.flightgear.org/Canvas_Draw
http://wiki.flightgear.org/Canvas_draw_library

http://chateau-logic.com/content/flight ... instrument

There also a few wiki articles, I believe abassign wrote a particularly comprehensive one recently

I still have to learn how animated SVG works to see if that transfers to OpenVG.

It certainly doesn't in FlightGear, where the 3D OpenGL scene graph is built via OpenSceneGraph (OSG).
All dynamic/animated stuff is currently implemented on top of scripted code (callbacks) invoked via timers and listeners: http://wiki.flightgear.org/Callbacks

I have no idea how Flightgear works apart from a few diagrams.
Is there a way to get the flight data going out a serial port?
Basic data like attitude, heading, airspeed, altitude etc

Yes, there is. Please see $FG_ROOT/Docs/README.serial and README.IO, README.properties

For starters, it would be best to work through the navbar shown here: http://wiki.flightgear.org/Property_tree

Finally, those are many questions, and unrelated ones, too - it would be better to split up such postings and post individual questions, rather than a collection of questions that nobody feels comfortable responding to entirely

With your current background, I would definitely suggest to start with the property tree, the property browser, the nasal console and then take it from there to tinker with a few SVG examples, so that you can make some first experiments before making concrete feature requests or suggestions for improvement.

You can learn how to make FlightGear create/load and render SVG/XML markup using just copy/paste "coding" and 10 minutes of your time: http://wiki.flightgear.org/Canvas_Snippets

[legoboyvdlp]

Just to clarify a point, props.nas is not slow: in fact, it is now much faster since it was implemented in cppbind than setprop or getprop. However, whether using props or getprop property IO is indeed a bottleneck.

[Hooray]

Just to clarify a point, props.nas is not slow: in fact, it is now much faster since it was implemented in cppbind than setprop or getprop. However, whether using props or getprop property IO is indeed a bottleneck.

Unless you are talking about a recent change/commit or ongoing development, I think that you are very mistaken here.

As a matter of fact, what you are saying is a contradiction: props.nas is either re-implemented in cppbind or it is implemented in Nasal (as it currently is).

I have previously posted my canvas/setValues related findings in the canvas sub-forum, and Thorsten has previously pointed out that the long-standing notion that props.nas is superior over setprop/getprop is a fallacy, because the latter is primarily going through native C++ code that is heavily optimized.

Like Tim Moore and Andy Ross pointed out in the original discussion, the approach underlying props.nas should conceptually be superior (it using object/node caching), but the scripting overhead is adding up too much for that to happen.

And like I mentioned previously, the lowest-hanging fruit is indeed porting/re-implementing props.nas on top of cppbind, possibly using a new/custom namespace during the transition/testing period.

This is something that bugman has been tinkering with on and off as part of his FGPython/cppunit efforts.

As far as I am aware, Stuart has been the one making the most recent changes related to this, as part of his FG1000 effort, and we were indeed in touch about this, and he was specifically asking about the benchmark I used to come up with the numbers I posted (and yes, I am also the one who originally wrote the cppbind article, so I am kinda aware of these things and would be surprised if what you say is true).

Background:
http://wiki.flightgear.org/Howto:Canvas ... nchmarking
http://wiki.flightgear.org/Property_Tree_Performance
http://wiki.flightgear.org/Shuttle_ADI_ball
http://wiki.flightgear.org/Nasal/CppBind
http://wiki.flightgear.org/Nasal_library/props
http://wiki.flightgear.org/Nasal_and_the_Property-tree