Board index FlightGear Development Canvas

Simgear-based subsystem with Canvas support?

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.

Simgear-based subsystem with Canvas support?

Postby hamzaalloush » Thu Apr 02, 2015 7:01 am

Hi all,

it says on the wiki page for Canvas Development, that the Canvas is a Flightgear subsystem.

i was hoping to build a program outside the FG environment, i have found a class in FGrader, that is based on Simgear 2.9, called "SGApplication", this class provides the property list and nasal to work with i guess?? correct me if i'm wrong.

what i mean to ask is, how do i port Canvas fully to work in my application? do i simple port the latest Simgear to the "SGApplication? and are there alternatives apart from "SGApplication" to provide a Simgear-based subsystem providing the same features?

from Canvas, i need the "Graph widget", the backend to provide the X/Y axis for my application will be in C++. it's an IC engine thermodynamics analyzer.

i have not started work yet, but just thinking out loud, goal of this project is to learn about C++, the Flightgear API, and Canvas while doing something i love.

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

Re: Simgear-based subsystem with Canvas support?

Postby Hooray » Thu Apr 02, 2015 10:18 am

hamzaalloush wrote:Hello Horray,

it says on the wiki page for Canvas Development, that the Canvas is a Flightgear subsystem.

correct, see $SG_SRC/canvas and $FG_SRC/Canvas

hamzaalloush wrote:i was hoping to build a program outside the FG environment, i have found a class in FGrader, that is based on Simgear 2.9, called "SGApplication", this class provides the property list and nasal to work with i guess?? correct me if i'm wrong.

that's also correct - the whole purpose of SGApplication is to provide a SGSubsystem-based "architecture" so that Nasal + Canvas and the property tree code can be easily reused.

For a summary see: http://wiki.flightgear.org/Canvas#Using ... G_projects
and: http://wiki.flightgear.org/FGRadar#Canvas_Integration

hamzaalloush wrote:what i mean to ask is, how do i port Canvas fully to work in my application? do i simple port the latest Simgear to the "SGApplication? and are there alternatives apart from "SGApplication" to provide a Simgear-based subsystem providing the same features?

you can also use SGSubsystem/SGSubsystemMgr directly - no need for "SGApplication" at all, it's just a convenicence helper.
"porting" isn't strictly necessary - you would primarily need int main() with a top-level SGSubsystemMgr, where you can then add the property tree, Nasal, Canvas, events etc (a handful of subsystems).

to use Canvas outside FG, you would also need to look at the FGCanvasSystemAdapter in $FG_SRC/Canvas and provide your own wrapper for your own app (trivial).


from Canvas, i need the "Graph widget", the backend to provide the X/Y axis for my application will be in C++. it's an IC engine thermodynamics analyzer.

i have not started work yet, but just thinking out loud, goal of this project is to learn about C++, the Flightgear API, and Canvas while doing something i love.

ps: i know you don't like PM's so others can learn as well, i'm just in a hurray to do something unrelated and might not be able to do a proper post right now :( but i will qoute our discussions in full and post on the forum if you like!

Thank you
Hamza


that should all be possible - the SGApplication stuff isn't really needed, we just came up with it to simplify working with the SG code.
But at least it demonstrates how the whole SGSubsystemMgr stuff works.

However, just for graphing/plotting purposes, there are certainly easier ways than coming up with a harness for using Canvas outside FG ...

This can obviously be done, and it is mainly a matter of doing "copy & paste" - so pretty straightforward, but just for 2D plotting purpose outside FG, there are much easier options. However, if you also want to become more familiar with FG, I'd say go for it :D

We can certainly provide all the pointers that you need - the other option would be using FG in "fgcanvas" mode, which is FG with Canvas and all related subsystems, but everything else entirely disabled (no aircraft, fdm, scenery/terrain etc): http://wiki.flightgear.org/FGCanvas

Image

This will involve building and patching FG - i.e. removing unneeded stuff - but there are already patches doing this to some extent.
So for plotting purposes, you would basically be using a subset of FG, which would then merely be the framework/platform, but no longer be running as a "flight simulator".
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: Simgear-based subsystem with Canvas support?

Postby hamzaalloush » Thu Apr 02, 2015 12:27 pm

Hi Hooray!

Hooray wrote:to use Canvas outside FG, you would also need to look at the FGCanvasSystemAdapter in $FG_SRC/Canvas and provide your own wrapper for your own app (trivial).

can i say that i love Canvas again?

Hooray wrote:However, just for graphing/plotting purposes, there are certainly easier ways than coming up with a harness for using Canvas outside FG ...

This can obviously be done, and it is mainly a matter of doing "copy & paste" - so pretty straightforward, but just for 2D plotting purpose outside FG, there are much easier options. However, if you also want to become more familiar with FG, I'd say go for it :D


yup, funnily i can adopt a GNU command-line plotter, that would be cool, but not as informative as using FG-Based API :mrgreen:


Hooray wrote:We can certainly provide all the pointers that you need - the other option would be using FG in "fgcanvas" mode, which is FG with Canvas and all related subsystems, but everything else entirely disabled (no aircraft, fdm, scenery/terrain etc): http://wiki.flightgear.org/FGCanvas

Image

This will involve building and patching FG - i.e. removing unneeded stuff - but there are already patches doing this to some extent.
So for plotting purposes, you would basically be using a subset of FG, which would then merely be the framework/platform, but no longer be running as a "flight simulator".



that's a new for me, i think we can let the "cat out of the bag" and say i'm aiming for a thermodynamics-based "IC engine simulator", so that will be helpful :)

the Canvas will help me far more than plotting, like real-time thermal imaging, flow simulations for example. feeding all the values into a property-tree is icing on a cake!!!

Thanks for elaborate, informative answers
-Hamza
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Simgear-based subsystem with Canvas support?

Postby Hooray » Thu Apr 02, 2015 2:59 pm

okay, what would be your preference then in terms of how to proceed ?
Would you rather create your own stubs using a SGSubsystemMGr-based design or customize fgfs to end up with a "fgcanvas" mode ?
The latter is something I have worked on for a while and for which I have a few patches to get you started quickly - also, others are interested in that as well.
However, the former could also be useful - especially for unit-testing (regressions) - i.e. having a standalone "test harness" that merely sets up canvas and a few related SGSubsystems (Nasal, property tree, timers, events).

Customizing fgfs would be a bit easier though, especially if you should already have a working fgfs build environment and git experience.
Creating a boilerplate standalone canvas application would be possible, too - but would inevitably require quite a bit of "copy & paste" - i.e. you will have to integrate at least half a dozen of existing subsystems - analogous to how the SGApplication stuff in FGRadar works.

As can be seen by FGRadar, it's possible and even useful, but definitely more tedious than using fgfs directly and disabling/removing unnecessary stuff, which would also be useful for related efforts, especially regression testing.

Regarding your comments on sending PMs as well your offer to document your journey: it would be great if you could help update the wiki accordingly and maybe document your journey there - e.g. by updating the Canvas docs or even just by contributing to the FG newsletter.

that's a new for me, i think we can let the "cat out of the bag" and say i'm aiming for a thermodynamics-based "IC engine simulator", so that will be helpful :)

the Canvas will help me far more than plotting, like real-time thermal imaging, flow simulations for example. feeding all the values into a property-tree is icing on a cake!!!

with that in mind, I would probably consider adapting fgfs instead of coming up with a completely new application from scratch - unless licensing is an issue (i.e. fgfs being GPL'ed).
the main reasoning for that being that sooner or later you may/will need a bunch of other subsystems (think sound, effects, shaders, logging, networking etc) - at which point you would end up replicating most of the existing fgfs main loop.
Which is why I am inclined to say that it would be easier to focus on an fgcanvas-equivalent subset of FG subsystems and simply disable everything else - which means that you will be using a subset of FG, so that you can easily use other features (think effects/shaders) later on - without having to duplicate any fgfs code using copy & paste.

if that is not an option, "fgpanel" is a code base that is using the "copy & paste" approach - so could serve as another example (beyond fgradar).
But like I said, I'd probably prefer customizing fgfs directly - and removing/disabling stuff that you don't need any time soon (think FDM, aircraft, multiplayer).

Once you think about it, that is basically how fgfs ended up being what it is these days: by people contributing to the main project, without starting their own projects from scratch.
Thanks to the property tree, XML, Nasal/Canvas and extensive I/O options, FG is no longer just a flight simulator, but can be a pretty powerful platform for pretty much arbitrary purposes requiring an OpenGL window, scripting and a flexible user interface.
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: Simgear-based subsystem with Canvas support?

Postby hamzaalloush » Thu Apr 02, 2015 9:47 pm

Hi Hooray,

Hooray wrote:okay, what would be your preference then in terms of how to proceed ?
Would you rather create your own stubs using a SGSubsystemMGr-based design or customize fgfs to end up with a "fgcanvas" mode ?
The latter is something I have worked on for a while and for which I have a few patches to get you started quickly


i don't have the actual requirements because i do not understand the limit of the sub-systems. which is what i intend to learn from our conversation and reading from the wiki, so i still don't have a decision at this point.


Hooray wrote:Regarding your comments on sending PMs as well your offer to document your journey: it wiould be great if you could help update the wiki accordingly and maybe document your journey there - e.g. by updating the Canvas docs or even just by contributing to the FG newsletter.


+1 will document, for now i'm on paper, but right now i have to get the basics right first, the design of my application, i.e create the thermo processes abstract classes, create the engine rotation model loop with phase/stroke conditionals returning phaseNum, crankTiming members, establish STP initial conditions, and using a currentCondition pointer(maybe array holding all conditions) for the phase classes, while these "phase classes" inherint from the relevant thermo class.

Code: Select all
class Intake: public Isobaric; Intake.updateCondition(*currentCondition);
.
Code: Select all
class Compression: public Adiapatic; Compression.updateCondition(*currentCondition);
.

ofcourse it have to return something, which is initially to establish a "P-V diagram"(2-d plot). bear in mind i'm still learning C++ so forgive me for any mistakes, but it was just as an example.


Hooray wrote:with that in mind, I would probably consider adapting fgfs instead of coming up with a completely new application from scratch - unless licensing is an issue (i.e. fgfs being GPL'ed).
the main reasoning for that being that sooner or later you may/will need a bunch of other subsystems (think sound, effects, shaders, logging, networking etc) - at which point you would end up replicating most of the existing fgfs main loop.


to be honest, my worries are with Nasal updating my content, by using it to access the property tree for Canvas drawing, as something like this will have to run at 700hz! a motorcycle or F1 engine can run upto 20,000 RPM=(20000/60)*2 for each phase.

wiki.flightgear.org wrote:In FlightGear, a Canvas is a dynamically created image (OpenGL texture) that can be created and modified (drawn to) at runtime by using the Property Tree, i.e. via the built-in scripting language Nasal and setting a few properties via setprop() or its object-oriented wrapper props.nas.


i think i need to use multi-threading. one unblockable thread for calculating, and the other for rendering "real-time" analysis to the screen, i'm thinking of using the C++ backend for that.

and please advice, do i really need shaders? i don't understand how they work.. are they related to drawing to a texture? i thought to use SVG dynamic drawing at first with Canvas. sorry for such noob questions :oops:


Hooray wrote:Once you think about it, that is basically how fgfs ended up being what it is these days: by people contributing to the main project, without starting their own projects from scratch.
Thanks to the property tree, XML, Nasal/Canvas and extensive I/O options, FG is no longer just a flight simulator, but can be a pretty powerful platform for pretty much arbitrary purposes requiring an OpenGL window, scripting and a flexible user interface.


i agree, it's awsome, which is why i want to join this effort!!

edit: for 3d, i want to do something that looks like this but for mbt(maximum spark advance) vs temp: Image
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Simgear-based subsystem with Canvas support?

Postby Hooray » Fri Apr 03, 2015 2:22 am

Well, I think you may want to do a little more research to understand the pros & cons of your options here.

Existing FlightGear subsystems will be involved either way: either you need to create an application from scratch that provides the necessary SGSubsystemMgr-based design to reuse existing subsystems, or you will have to adapt FlightGear to remove everything that you don't need by making those subsystems optional.

I only mentioned effects/shaders as features that may come in handy at some point, just like logging, networking or scripting - sooner or later, you would probably end up replicating the majority of the fgfs main loop either way. Just imagine for a second that you'd like to show a fully animated 3D model of an engine at work - with fgfs you could do that right away, because there's support for loading/displaying and updating/animating 3D models easily. An application written from scratch would be a different beast. Which is why I consider it more straightforward to adapt fgfs instead of coming up with an application from scratch - there's probably only 5-8 subsystems that you may need to disable right away, e.g. stuff like AI traffic, multiplayer, fgcom, scenery/terrain (terrasync) - most other subsystems may turn out to be useful down the line.

Creating a "shell" or "harness" for a standalone application using SGSubsystemMgr is likely to be more work than simply disabling what you don't need in fgfs.

Regarding your requirement to run the simulation at 700 hz - you need to differentiate between simulation and rendering - the latter often being affected by vsync, i.e. 60 hz/fps. That said, osg does have pretty good support for splitting up these two tasks.
Like you say, the existing property tree/Nasal mechanism for using Canvas isn't designed for handling 700 hz/fps - mainly due to the way the main loop is structured, and due to the Nasal GC, as well as the fact that Canvas lives in the global property tree.
Then again, in "fgcanvas" mode, it is possible to disable tons of features that you won't need - which means that AFTER disabling vsync, you can still get impressive update rates in terms of fps/frame space - for instance, here's Philosopher's Nasal/Canvas-based interactive Nasal console (REPL) running in fgcanvas mode on a 7-year old laptop (look at frame rate and frame spacing):

http://wiki.flightgear.org/FGCanvas
http://wiki.flightgear.org/Interactive_Nasal_Console
Image

In addition, you need to understand that Canvas is not all about Nasal - it's probably save to say that 95-99% of all Nasal code using Canvas ends up being "just" property I/O i.e. properties being read/written, or updated via timers/listeners. Usually, the idea is to initialize a Canvas texture by setting up all important state early on, and then "update" and "animate" things using timers/listeners - or even property rules later on. That will usually help minimize most Nasal-induced overhead.

However, Canvas can definitely also be used without using Nasal - to see for yourself, just use the property tree browser to create/display canvas textures, or even the telnet/httpd protocols.

For the time being Nasal merely happens to provide the most abstract interface/mechanism to deal with Canvas - but you could just as well use the Canvas system from C++ by doing the corresponding property I/O using the C++ property interface directly - which would eliminate all Nasal overhead, even timers/listeners could then implemented in C++ space for animation/update logic.

That being said, this isn't necessarily the smartest/best thing to do - primarily, Canvas is all about exposing hardware-accelerated 2D rendering to fgdata space, so that non-core developers can easily address their 2D rendering needs, without having to rebuild FG from source and without having to be intimately familiar with C++ and OSG/OpenGL. Which is where the performance overhead is coming from, i.e. Canvas APIs being modeled on top of the property tree and wrapped using Nasal bindings - which adds two fairly massive layers of abstraction in terms of property I/O and Nasal<->C++ marshalling.

Once you start coding in C++ space, there are frankly much better ways to do everything Canvas is good at - and the OSG examples/docs are pretty good, too - so you are unlikely to really benefit from Canvas here - unless you happen to require support for certain element (e.g. SVG/OpenVG drawing) that isn't otherwise available in OSG land.

As I have shown above, even fairly complex Nasal/Canvas applications can be pretty fast with some tweaking (see the REPL screen shot), which even is the case on old hardware. In addition, there are C++/OSG level optimizations that may further help optimize Canvas. One relatively straightforward option would be using a dedicated property tree instance for certain canvas textures and asynchronously update those using a Nasal worker thread that would never touch the main property tree - in other words, that Nasal code would also be able to run at much higher rates than your frame rate (I think someone once tested background threads in Nasal providing roughly a few khz). Then again, the GC will definitely remain an issue.

Overall, you may want to state your requirements or simply start reading/experimenting a bit - personally, I am not convinced that you really need to use Canvas/Nasal for your purposes - especially if you're looking to create an application from scratch anyway.
Otherwise, I would suggest to really modify fgfs as per the fgcanvas discussion to get rid of unnecessary features/subsystems and disable sync-to-vsync while enabling frame-throttling to end up with a Nasal/Canvas platform that could easily provide 400-500 hz.

But just for drawing a 2D graph with two X/Y axes, there are much better ways in C++/OSG land than going with Canvas ...
Especially 3D stuff like your screen shot are much more easily expressed in OSG than using the existing Canvas system and its elements which focus on 2D drawing - in fact, even using Torsten's browser-based UI called "Phi" may be a better option IMO.
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: Simgear-based subsystem with Canvas support?

Postby Hooray » Sun Oct 04, 2015 4:43 pm

Subject: Space Shuttle

Hooray wrote:Using Canvas for visualizing orbital flights (cont'd PM)
Thorsten wrote:progress on the groundtrack map. I don't think it's part of the real instrumentation, but it's still a very useful feature [...]
The real avionics is surprisingly (or perhaps not) spartan and not very visual. The entry management displays are velocity vs. altitude diagrams with the pre-calculated track for the mission and the envelope lines shown and the current state of the orbiter as a triangle plotted inside.
Image


diagrams like those (velocity/altitude and lift/drag vs. AOA) should also be pretty straightforward to recreate -and dynamically update- using Canvas, i.e. could be shown in the same GUI dialog if needed (using clipping), which would probably come in handy while developing the other fancy stuff you mentioned above (guidance computer/autopilot modes) - i.e. for debugging/troubleshooting purposes.

It's basically the same technique you're using currently - but you would probably want to use VG_CUBIC_TO or VG_SCUBIC_TO for doing curves between x/y points instead of straight line segments (see api.nas), while considering the x/y axes "static" and only update ~20-30 points per graph.

The triangle/space shuttle symbol could then be loaded from a SVG file or created procedurally using OpenVG paths (line segments).



Subject: Using Canvas for visualizing orbital flights (cont'd PM)
Hooray wrote:As a first step, I have edited the Canvas Snippets article to demonstrate how to draw quadratic/cubic curves (this should help lower the total number of Canvas path elements needed, because you're currently using a high number of line segments for approximating the curve):

http://wiki.flightgear.org/Canvas_Snipp ... enVG_Paths

Image

Image

Once this is working, I would consider creating an array (=Nasal vector) of path objects and simply update (translate, hide/show) those instead of using removeAllChildren() - so instead of invoking removeAllChildren(), you'd merely hide(), update()/transform() and show() the corresponding path elements



Hooray wrote:Once you start coding in C++ space, there are frankly much better ways to do everything Canvas is good at - and the OSG examples/docs are pretty good, too - so you are unlikely to really benefit from Canvas here - unless you happen to require support for certain element (e.g. SVG/OpenVG drawing) that isn't otherwise available in OSG land.


Subject: How to tell if you are CPU or GPU limited (split)
Hooray wrote in Wed Sep 23, 2015 2:19 pm:
hamzaalloush wrote:Maybe through the use of Canvas to plot/track properties and then using a native image exporter lib(we already export PNG), that comes with FG?

I would not use Nasal/Canvas for plotting, because that will only add to the mainloop overhead (Heisenberg), which will not be an issue for the non-scenery test-case that runs at >= 250 fps, but will quickly show once scenery/terrain, weather etc is running.
For the time being, Canvas (and Nasal) are strictly single-threaded, so there is really no good way to make use of OSG's concurrency support for doing this stuff asynchronously.


I got a few questions related to this, so answering in public: Trivial graphs can certainly be plotted using Nasal/Canvas (as per the screen shots/examples discussed above), but anything more complex (think multiple 2d/3d graphs) are unlikely to benefit from the explicit nature of using Canvas (OpenVG) for plotting purposes, keep in mind all the property I/O and setup overhead for otherwise identical graphs.

So anybody really wanting to do 2D/3D plotting (analogous to gnuplot), inside the fgfs main process, would be well-advised to use an existing library like MathGL (GPL, multi-platform), or GNU Octave, and expose this to Canvas as a custom element, specifically dedicated to 2d/3d plotting - possibly with Nasal/CppBind support:

http://mathgl.sourceforge.net/doc_en/Main.html
MathGL is:
  • a library for making high-quality scientific graphics under Linux and Windows;
  • a library for the fast data plotting and data processing of large data arrays;
  • a library for working in window and console modes and for easy embedding into other programs;
  • a library with large and growing set of graphics.
    http://mathgl.sourceforge.net/doc_en/Pi ... l#Pictures
    Image



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


Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest