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.

[it0uchpods]

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