Board index FlightGear Development Canvas

FGCanvas Experiments & Updates

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.

FGCanvas Experiments & Updates

Postby Hooray » Sun Jul 06, 2014 6:50 pm

Subject: FGPanel: standalone panel rendering
zakalawe wrote:I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people)

Hooray wrote:Instead, it would probably make sense to make some more subsystems optional so that they can be disabled on demand, then the same fgfs binary could be used for starting up in an "instrument only" mode that only renders 2D instruments with properties being read from a master instance.

That's more or less exactly what it will be - and yes, it will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone.



Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system:

Zakalawe wrote:Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend.

If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself -
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than
sending per-frame pixel surfaces over shared memory or sockets / pipes.


Back then, we made some first experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running:

TheTom wrote:Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...


Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below:

http://wiki.flightgear.org/FGCanvas
Image
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are:
  • flight (FDM)
  • scenery (tile manager, ephemeris)
  • view manager
  • lighting
  • terrasync
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)

This means that there's basically just a handful of subsystems that now need to be made optional, and that FGCanvas will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically".

In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.
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: FGCanvas Experiments & Updates

Postby Philosopher » Sun Jul 06, 2014 7:24 pm

I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea, and will help me personally (I started a Latin experiment in Nasal and had to use the console/REPL to load it inside a minimal session.... then I used a message box to display results in Canvas, etc :D). Obviously I could help with C++ too, but in a few weeks still.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: FGCanvas Experiments & Updates

Postby Hooray » Sun Jul 06, 2014 7:55 pm

Sounds good to me, but I may also look at the Nasal side of things - because thanks to all the reset/re-init work, the C++ dependencies are fairly straightforward to decouple these days, I just made the tile manager optional in under 10 minutes, i.e. all the scenery/sky/stars is gone now - which means that FG is now utilizing less than 140 MB of RAM here using this "startup mode".

So this about more than just "FGCanvas": It will make troubleshooting so much more straightforward, and we can also explore feature-scaling and run-time benchmarking once this works.

Currently, I'd even consider restructuring initialization to always boot up like this, because it's the safest possible subset of subsystems for now - i.e. roughly a dozen subsystems that basically stand no chance of "crashing" the sim. And from then on, additional initialization could be handled by Nasal obviously - and scripts could even scale up/down, depending on hardware support and features.

With 14 subsystems remaining, I am now getting 650 fps when showing the Canvas GUI (Aircraft Center) here.

As for C++ changes, I have come to the conclusion that this could be greatly simplified by making the whole aircraft shebang optional - i.e. aircraft as such, and all its related subsystems, e.g.:
  • view manager
  • FDM (obviously)
  • Autopilot, Property Rules
  • Route Manager
  • history
  • flight recorder

These are currently hard-coded as separate SGSubsystem instances in fg_init.cxx - even though this is conceptually a headache, simply because these should be all handled by a single SGSubsystemGroup and wrapped inside it. This was also once discussed on the devel list:


http://www.mail-archive.com/flightgear- ... 18446.html
in 2003, Andy Ross (YaSim/Nasal developer) wrote:FlightGear is an old code base, and lots of the old assumptions (like
a single aircraft) need to be teased out of the code before progress
can be made on new features. This kind of work isn't glamorous, and
often requires more effort than the new development does. But it's
not brain surgery either. The problem with some great new features is
that they show up with code that is "ready" to integrate, but without
the integration work done. So they languish in the CVS tree until
everyone forgets about them. I can recall at least one occasion where
a unused module got replaced by a simpler (and arguably less
functional) one precicely because the original never got integrated
very well and the replacement actually worked.




If we were to pursure this, this would also mean that the whole shebang could also be reused for AI traffic much more easily, which is another thing that Durk & Zakalawe have been discuussing and working towards:

Subject: New ATC / AI interactions
durk wrote:Yep James and I have plans to unify our approaches. One of the reasons why I have put my plans to implement SIDs and STARs, as well as more complicated airway following in flight flightplans on the back burner is to give James some time to finish is work on the route manager. This way we can work towards a common format that is shared between the route manager and the AI system.

Cheers,
Durk



Probably, we could even add the display/cockpit stuff to the same "aircraft" group, and formalize the whole thing once and for all - at that point, simulating multiple aircraft at once, or even switching between AI aircraft would be fairly straigthforward, and they would automatically support FDMs, APs and even have unified route manager/flight plan support, while also being subject to turbulence/weather. As long as each SGSubsystemGroup has its own instances of a FDM, AP, RM, those could all be handled by a single SGThread per instance, which should help improve FG frame rates when using MP/AI.

The main challenge I see for now based on making stuff like the tile_mgr optional is that we do have Nasal APIs that are unconditionally available for now, and which basically "expect" certain subsystems, like the tile/view manager. So it might be worthwhile to explore extending cppbind in order to formalize init/shutdown handling to automatically register/remove the corresponding APIs, e.g. by using SGPropertyChangeListener APIs to handle run-level changes - for now, calling geodinfo() will simply trigger a segfault here, which we obviously don't want.

Another consideration might be delegating such APIs to the main instance, but using just raw properties would be too low-level and not handle serialization very well (Nasal types), at which point HLA would be a much better option, because it could basically be used to do RPC from a FGCanvas instance to the main fgfs instance and respond with a serialized Coord.geo() object (or even its C++ equivalent).

So I can see two interesting discussions here: 1) how to deal with varying subsystem configurations, i.e. how to respond to APIs/subsystems being available or not, and 2) how to formalize whether we want to initialize the corresponding system locally, or we just want to forward requests to the main instance.

But overall this is pretty cool, seeing a subset of FlightGear running in a maximized window with Canvas + Nasal fully working, while providing 500-800 fps, and all utilizinig under 200 MB of RAM :mrgreen:
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: FGCanvas Experiments & Updates

Postby Hooray » Mon Jul 07, 2014 3:45 pm

Hooray wrote in Sun Jul 06, 2014 7:55 pm:These are currently hard-coded as separate SGSubsystem instances in fg_init.cxx - even though this is conceptually a headache, simply because these should be all handled by a single SGSubsystemGroup and wrapped there.
If we were to pursure this, this would also mean that the whole shebang could also be reused for AI traffic much more easily, which is another thing that Durk & Zakalawe have been discuussing and working towards


I went ahead to see how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably.
Image

Obviously, all aircraft related subsystems are now in their own group, and no longer show up in the main performance monitor - but performance sampling works at the subsystem-level, so can be fixed - either through a separate dialog just for aircraft related subsystems, or simply by providing a combo/dropdown menu until we have some kind of canvas treeview :D
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: FGCanvas Experiments & Updates

Postby Hooray » Tue Jul 08, 2014 1:54 am

Philosopher wrote in Sun Jul 06, 2014 7:24 pm:I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support).


FWIW, on the FG/C++ side, the main systems that should/could probably become optional can be categorized into groups like these:
  • networking (httpd, telnet, generic, multiplay etc)
  • aircraft (fdm, control, autopilot, route manager, replay, history)
  • world (scenery, tile manager, environment, lighting, ai)
  • audio (sound, fgcom, voice)
  • visuals (gui, canvas, canvasgui)

Most others can be considered to be "platform" features, i.e. logging, properties, input etc - so shouldn't affect Nasal modules.

aircraft & world (scenery) are obviously the lowest hanging-fruits when it comes to saving significant RAM/CPU resources (aircraft.nas, view.nas).

What I've been doing so far is using SGSubsystemGroup to group related subsystems accordingly so that I can more easily exclude/disable them without requiring a ton of fg_init.cxx changes.

In the near term, it would be better to extend the fgcommand-basd re-initialization mechanism that Zakalawe came up with ($FG_SRC/Main/subsystemFactor.?xx) to specifically support such initialization groups, analogous to "run-levels". That would then allow us to script initialization, without having any hard-coded stuff in fg_init.cxx that should be optional, and it would allow people to use the same mechanism to support benchmarking, feature-scaling or even regression testing.

Dealing with subsystem-specific Nasal APIs -like geodinfo()- is a nice challenge actually - for now, we can probably ignore it. But our way of keeping our scripting APIs separate from the actual subsystems that provide said functionality is making things pretty interesting - otherwise, each subsystem could simply use its own postinit() method to expose/release Nasal APIs, but the way FGNasalSys::init() is structured, there's the assumption that Nasal will always see a "full" session with all systems up and running, and expose the APIs accordingly.

So I am currently having a session with just a handful of subsystems, but the Nasal namespace is populated "as is" :?

For now, I have played with using the bind()/unbind() method (designed for property-tying) to handle this, but it's a workaround still.

EDIT:
Philosopher wrote:...had to use the console/REPL to load it inside a minimal session

Getting on average ~6ms and >=450 fps here when removing pretty much anything that isn't needed for just Nasal & Canvas to work, but the REPL still works :mrgreen:
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FGCanvas Experiments & Updates

Postby Philosopher » Tue Jul 08, 2014 5:50 am

Whoa, that's awesome! I hope the startup is really quick. Also, what happened to the style - I don't remember a blue bar on top ;).

I guess my preference wrt extensions is just leave out the symbols, so that we can use contains(globals, "geodinfo") (or some subsystem-enabled predicate) and it won't crash FG. I know of few extension functions that check that the corresponding subsystem is available – they usually assume the pointer is non-NULL.

Also, I've always wondered what would be involved in adopting HLA. Could we start using it today, i.e. for a very small proof of concept? Do we need an implementation? Who would be able to do it? What does the code already in SimGear do? A little message passing doesn't sound like a bad idea to me, if I understand it right.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: FGCanvas Experiments & Updates

Postby Hooray » Tue Jul 08, 2014 6:10 am

stating that the start-up is "quick" would be an understatement: It's under 500 ms here probably.
The style, yeah: I "broke" that when I removed something that I shouldn't have touched - I didn't edit the Nasal code...

guess my preference wrt extensions is just leave out the symbols, so that we can use contains(globals, "geodinfo") (or some subsystem-enabled predicate) and it won't crash FG. I know of few extension functions that check that the corresponding subsystem is available – they usually assume the pointer is non-NULL.

right, but like I mentioned previously: that would be the right thing to do technically - but the way we're populating our Nasal namespace, it happens SEPARATELY, i.e. regardless of the subsystems that actually implement/contain the functionality, all in $FG_SRC/Scripting - usually via some kind of FooPostInit() hacks (except for Canvas itself which is kinda clean here). As a workaround (without refactoring all the code), we could simply use a globals->get_subsystem("tile-manager") lookup and check if it's NULL - or maybe add a handful of "categories" to cppbind, so that this is handled implicitly, outside the actual extension function.


Also, I've always wondered what would be involved in adopting HLA. Could we start using it today, i.e. for a very small proof of concept? Do we need an implementation? Who would be able to do it? What does the code already in SimGear do? A little message passing doesn't sound like a bad idea to me, if I understand it right.

yeah, it would be possible to pass something from one instance to another already - but each type would need to be wrapped with quite a bit of boilerplate. And then there's the "setup" code for establishing the "connection". I once played with it, for simple examples it can definitely be used already (there are some demos/tests in the openrti repo), but I am not sure if we're even supposed to use that stuff already. If you're familiar with CORBA, that's basically how it works behind the scenes - so you have to establish messages and data (objects/classes) and serialization schemes to move data structures from one process to another, where you map the whole thing back to an object again.
In this particular case, we could probably get away with just wrapping the Nasal wrappers provided by cppbind already and directly process Nasal data structures.

Last I checked, it did involve quite some reverse engineering to implement anything non-trivial. And the code is fairly fancy C++ code, too.

But a limited demo should be do-able, i.e. to run some RPC across two instances - even just by looking at existing HLA code (see $FG_SRC/Network/HLA/hla.cxx, $FG_ROOT/HLA/mp-aircraft.xml and mp-aircraft-fom.xml for the actual objects that are supported already)

All the marshaling/serialization between SG<->HLA can be seen in $SG_SRC/hla/HLAArrayDataElement.hxx (SGVecX etc) - thus, exchanging a SGVec would be possible already, even without coming up with our own FOM.


BTW: There's apparently a minor typo in Zakalawe's subsystem-reinitialization APIs: fdm instead of flight (needs to match $FG_SRC/Main/fg_init.cxx), maybe Tom can take a quick look or just pass it on:
Image
Code: Select all
diff --git a/src/Main/subsystemFactory.cxx b/src/Main/subsystemFactory.cxx
index 2a8d7e5..24217c7 100644
--- a/src/Main/subsystemFactory.cxx
+++ b/src/Main/subsystemFactory.cxx
@@ -77,7 +77,7 @@ SGSubsystem* createSubsystemByName(const std::string& name)
     MAKE_SUB(FGSoundManager, "sound");
     MAKE_SUB(FGInterpolator, "prop-interpolator")
     MAKE_SUB(FGProperties, "properties");
-    MAKE_SUB(FDMShell, "fdm");
+    MAKE_SUB(FDMShell, "flight");
     MAKE_SUB(FGEnvironmentMgr, "environment");
     MAKE_SUB(Ephemeris, "ephemeris");
     MAKE_SUB(FGSystemMgr, "aircraft-systems");
@@ -122,6 +122,17 @@ SGSubsystemMgr::GroupType mapGroupNameToType(const std::string& s)
 }
 
 static bool
+do_check_existing_subsystem(const SGPropertyNode* arg)
+{
+    std::string name = arg->getStringValue("name");
+
+    if (globals->get_subsystem_mgr()->get_subsystem(name))
+      return true; // subsystem exists already

+    return false; // not there
+}
+
+static bool
 do_add_subsystem (const SGPropertyNode * arg)
 {
     std::string subsystem(arg->getStringValue("subsystem"));
@@ -138,7 +149,7 @@ do_add_subsystem (const SGPropertyNode * arg)
         name =  subsystem;
     }
   
-    if (globals->get_subsystem_mgr()->get_subsystem(name)) {
+    if(do_check_existing_subsystem(arg)) {
         SG_LOG(SG_GENERAL, SG_ALERT, "do_add_subsystem:"
             << "duplicate subsystem name:" << name);
       return false;
@@ -280,6 +291,7 @@ static struct {
   const char * name;
   SGCommandMgr::command_t command;
 } built_ins [] = {
+    { "subsystem-running", do_check_existing_subsystem },
     { "add-subsystem", do_add_subsystem },
     { "remove-subsystem", do_remove_subsystem },
     { "reinit", do_reinit },

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: FGCanvas Experiments & Updates

Postby Hooray » Wed Jul 09, 2014 10:59 pm

Philosopher wrote in Tue Jul 08, 2014 5:50 am:I guess my preference wrt extensions is just leave out the symbols, so that we can use contains(globals, "geodinfo") (or some subsystem-enabled predicate) and it won't crash FG. I know of few extension functions that check that the corresponding subsystem is available – they usually assume the pointer is non-NULL.


It occurred to me that the same "dependency" problem we have already WRT properties that depend on other subsystems.
For that, core developers extended SGSubsystem to provide bind() and unbind() methods, where property-tying would normally take place:
http://docs.freeflightsim.org/simgear/c ... 9145a9565f
Acquire the subsystem's property bindings. This method should bind all properties that the subsystem publishes. It will be invoked after init, but before any invocations of update.

And for unbind() it says: "This method should release all properties that the subsystem publishes. It will be invoked by FlightGear (not the destructor) just before the subsystem is removed."

thus, bind() & unbind() are automatically invoked by the subsystem manager. So that is basically where our subsystem-specific Nasal APIs could be registered and released, we'd only need to keep track of all added symbols/namespaces, so that we can easily release them in unbind() later on. Stuff like geodinfo() would then be managed via the tile manager's bind()/unbind() methods.

While initNasalPositioned() would be moved to the NavDB subsystem's bind() method.
It's not as much work as it may sound, because we can keep the code where it is (i.e. in $FG_SRC/Scripting), we only need to move the initNasalFoo() calls from FGNasalSys::init() to the corresponding subsystem's bind() method for now.

That way, all subsystem-dependent APIs will be ONLY ever registered if the parent subsystem is available.

For releasing APIs, we'd need to check cppbind to see if it can be easily extended to maintain a vector of symbols to get rid of them later on.
As far as I can tell, this would only affect a handful of bindings:

  • initNasalCanvas(_globals, _context);
  • initNasalPositioned(_globals, _context);
  • initNasalPositioned_cppbind(_globals, _context);
  • initNasalAircraft(_globals, _context);
  • initNasalHTTP(_globals, _context);

Most others only have dependencies to subsystems that will be required either way (e.g. timers -> events, clipboard -> canvas

Tom has already added getters to acquire the globals/context to FGNasalSys - so, C++-wise would could use this method to initialize Nasal much earlier, even prior to the Canvas system. Probably, shortly after props, input, logging etc
Last edited by Hooray on Wed Jul 09, 2014 11:08 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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FGCanvas Experiments & Updates

Postby Philosopher » Wed Jul 09, 2014 11:08 pm

That sounds like an excellent idea (hopefully it won't be too difficult to realize). AFAIK, most cppbind classes only create one global symbol, so we could just say, "make_objects(1,2,3)" and "remove_objects(1,2,3)". But, as Nasal can openly reference any object, the old copies of these "removed" symbols may still be around, which could create problems – meaning, taking down a subsystem while Nasal is still up might not be a good idea, so probably best not to do it.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: FGCanvas Experiments & Updates

Postby Hooray » Wed Jul 09, 2014 11:12 pm

I find Tom's cppbind code too intimidating to make any authoritative statements here (too much template meta-programming going on there ...) , but even apart from cppbind, we should be able to keep a vector of added namespaces/symbols and then use that to release symbols once the subsystems is removed.

I have it working for a single initNasalFOO() case and the patch is only ~25 lines now to move the initCall() out of the scripting subsystem into the subsystem providing the "service".
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: FGCanvas Experiments & Updates

Postby Hooray » Thu Jul 10, 2014 1:20 am

got it working now here: nasal is starting up among the first 5 subsystems now (directly after props) - would love to see your Nasal work committed to the topics/fgcanvas branch

Here's a screen shot showing the new MessageBox while the splash screen is still loading scenery & terrain (yeah, it's responding fine):
Image

Will be pushing my fg changes to either your repo or mine so that you can take a look and play with it.

Haven't yet added the other changes, but it's working without regressions currently - so far so good, I used the bind/unbind method discussed above, and added a bunch of logging statements to each ctor and each relevant init method:

Code: Select all
Enabling ATI viewport hack
Nasal added before TerraSync !
FGNasalSys ctor
NavCache bind(): Adding postioned bindings to nasal
HTTPClient bind(): Adding HTTP  bindings to nasal
FGFlightHistory bind(): Adding history() bindings to nasal
Canvas bind(): Adding Canvas bindings to nasal
Init Nasal now
Nasal init() completed
fgPostInitSubsystems().........
Nasal postinit() processing $FG_ROOT/Nasal (will be deprecated by Philosopher's script)
environment init
Nasal is now up and running!



EDIT: https://gitorious.org/fg/philosophers-f ... 293fd8abe3

Once your script is committed ,we can get rid of the step that's using loadDirectoryScripts() (which I put into postinit(), a mehod that Tom has been using, too - and it's in line with the existing SGSubsystem interface, so no need to come up with workarounds ...)
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: FGCanvas Experiments & Updates

Postby Hooray » Thu Jul 10, 2014 6:37 pm

Philosopher wrote in Tue Jul 08, 2014 5:50 am:Also, I've always wondered what would be involved in adopting HLA. Could we start using it today, i.e. for a very small proof of concept? Do we need an implementation? Who would be able to do it? What does the code already in SimGear do? A little message passing doesn't sound like a bad idea to me, if I understand it right.


I also played with this yesterday because I was feeling "adventurous" given all the recent progress :D

But this proved to be quite a challenge - the steps are basically clear: each data structure that we want to be passed, needs to be serialized by implementing a corresponing HLA interface, which tells HLA how to turn network data into objects and vice versa, analogous to Tom's cppbind to_nasal and from_nasal helpers.

And then, the "service bus" needs to be informed about the new supported object (fancy XML/C++ meta programming Mathias did there), and about messages that may contain it by editing XML files in $FG_ROOT/HLA - that much, I can gather from looking at the existing code (especially fgai, fgviewer) - but there's quite a bit of other stuff involved here, that doesn't map 1:1 to CORBA (which I am a bit familiar with). For the time being, I am getting some fancy segfaults all over the place.

So, for now, I am probably not going to explore this further - but once the other stuff is working and committed, we would primarily need to modify cppbind bindings such that all globals->get_subsystem("foo") lookups are encapsulated, so that bindings can optionally use the HLA service bus to look up a service like "scenery/tile-manager" and run geodinfo() that way, instead of doing the local globals->.... lookup.

It is certainly better exploring this than using telnet/udp/props etc - but we may need to get in touch with Mathias to ask for a few pointers, or even just a single contrived example - adapting existing code to use "delegates" should be simple enough.
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: FGCanvas Experiments & Updates

Postby Philosopher » Thu Jul 10, 2014 6:56 pm

Actually, I have an idea for subsystems: unless there's some restrictions with using the network (like if we have to run a request in another thread), we could still use the subsystem manager and insert proxy systems. So geodinfo() would call the proxy system which would run an HLA request to access the real system in the master thread (or the scenery thread, or whatever). Would that work? It might be a bit of work to implement it for each subsystem that we need to do it for, but it might work really well ;).
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: FGCanvas Experiments & Updates

Postby Hooray » Thu Jul 10, 2014 7:07 pm

yeah, that should work - instead of adding subsystems directly, we'd add a "wrapper" that internally handles either the real thing, or the HLA request.
Thus, instead of doing a globals->get_subsystem("FOO"); lookup, we could search/replace and use subsystemWrapper->get_subsstem("FOO");

I've been contemplating to use something like this for managing subsystems in groups, i.e. like pseudo run-levels, where related subsystems are put into a parent SGSubsystemGroup, like this:
(added to the top of $FG_SRC/Main/subsystem_factory.cxx)
Code: Select all
struct AUDIO: SGSubsystemGroup {
 AUDIO() {
 set_subsystem("sound");
 set_subsystem("voice");
 set_subsystem("fgcom");
 }
};


The AUDIO subsystem group would then simply represent a "run-level" where sound is available.
Changing this to internally delegate requests to some other HLA federate would work, too.

But then we could also directly change $FG_SRC/Main/globals.cxx Globals::get_subsystem() to always do this kind of lookup.
But given the number of segfaults here that I don't quite understand (yet), I'd consider it premature to implement this now.
Even just getting the Nasal/fg_init.cxx and main.cxx changes polished, tested, reviewed and committed will probably take a while (I sent a heads-up to Zakalawe, so that he's aware of this).
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: FGCanvas Experiments & Updates

Postby Philosopher » Thu Jul 10, 2014 7:15 pm

Sorry if I didn't make it clear but I was suggesting we just add the proxy to the regular subsystem manager (instead of the real subsystem – they have to implement the same .hxx class, right? there's no sense in making another pseudo-manager class)
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests