Board index FlightGear Support Interfacing

Headless mode with access to property tree

Connecting two computers, using generic protocol, connecting with Matlab?

Re: Headless mode with access to property tree

Postby Hooray » Tue Aug 02, 2016 9:23 pm

thanks for adding your findings here - yes, you are right, this will continue to render (obviously), it will just render to an invisible window basically - which means that you can still create screenshots (or even capture video) this way - the window is just hidden this way.

For the sake of completeness, you may want to consider adding an actual command line/startup option to accomplish - e.g. something like --headless - to do that, please see $FG_SRC/Main/options.cxx and $FG_ROOT/options.xml

You can also find similar patches (i.e. adding options) via the wiki - e.g. see:

http://wiki.flightgear.org/FlightGear_V ... anslations
http://wiki.flightgear.org/FlightGear-P ... Processing
http://wiki.flightgear.org/Howto:Create ... ep_by_Step
http://wiki.flightgear.org/Howto:Disabl ... rely#Patch

To disable rendering _entirely_ there's more work ahead, i.e. the comments you previously digged out are still valid - most subsystems are not designed/maintained (or added) with this use-case in mind. For the correspondind background info, please refer to:

http://wiki.flightgear.org/FlightGear_Run_Levels
http://wiki.flightgear.org/CompositeViewer_Support

Which is to say, it's definitely possible (and some of the key core developers have been working towards this), but it is definitely a bit of work, and you would undoubtedly need to be familiar with git, C++, cmake and some SG/FG and OSG specifics.

For instance, take a look at the following wiki article: http://wiki.flightgear.org/Howto:Disable_Nasal_entirely
This demonstrates how to disable Nasal scripting in its entirety - you would want to do pretty much the same thing for rendering.
Which boils down to moving all subsystem accesses to a corresponding method/wrapper (think encapsulation), so that you can do a NULL pointer check, log an error/warning to deal with all those cases where rendering is disabled, but some other subsystem is otherwise relying on it, i.e. most of the code is not aware of such dynamic dependencies.

For the corresponding background info, please see: http://wiki.flightgear.org/Reset_%26_re-init
And specifically: http://wiki.flightgear.org/Howto:Reset/ ... leshooting

You will see that there are two dedicated fgcommands to remove subsystems on demand: http://wiki.flightgear.org/Howto:Reset/ ... Fgcommands

Whatever you do to the rendering back-end, would benefit from also supporting this kind of API.
If in doubt, get in touch with the devel list (specifically Zakalawe/James Turner there)

Anyway, it will not be a quick hack, but it can definitely be accomplished within 2-3 days of spare time hacking - for starters, you'd probably want to use the minimal startup profile as the baseline: http://wiki.flightgear.org/Minimal_Startup_Profile

Next, you will need to be familiar with some kind of debugger (think gdb) and run fgfs inside a debugger session to see what other subsystems are trying to access the rendering back-end.

Looking at the "disable Nasal" patch above, you will undoubtedly touch quite a few places/files which assume that fgfs always has rendering enabled/working - but the changes are not rocket science, like bugman once mentioned regarding his FGPythonSys effort:

FGPython an propose for Python as an nasal alternative
bugman wrote:Actually my thinking is along these lines - these are exactly the same types of changes I was thinking of for fully decoupling all the various parts of FlightGear for use in a CppUnit-based test suite ;) Something for the future though.

Regards,
Edward
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: 11121
Joined: Tue Mar 25, 2008 8:40 am

Re: Headless mode with access to property tree

Postby Hooray » Sun Jul 16, 2017 12:17 pm

For the sake of completeness, the following tiny patch turns the whole thing into an actual command line option: --enable-headlless:

http://wiki.flightgear.org/FlightGear_H ... 28patch.29
Code: Select all
diff --git a/src/Main/options.cxx b/src/Main/options.cxx
index db5d84d..fb63dd1 100644
--- a/src/Main/options.cxx
+++ b/src/Main/options.cxx
@@ -1797,6 +1797,7 @@ struct OptionDesc {
     {"prop",                         true,  OPTION_FUNC | OPTION_MULTI,   "", false, "", fgOptSetProperty},
     {"load-tape",                    true,  OPTION_FUNC,   "", false, "", fgOptLoadTape },
     {"developer",                    true,  OPTION_IGNORE | OPTION_BOOL, "", false, "", nullptr },
+    {"enable-headless",              false, OPTION_BOOL, "/sim/startup/headless-mode", true, "",0 },
     {0}
 };
 
diff --git a/src/Viewer/WindowBuilder.cxx b/src/Viewer/WindowBuilder.cxx
index f4d3c33..a1ffb84 100644
--- a/src/Viewer/WindowBuilder.cxx
+++ b/src/Viewer/WindowBuilder.cxx
@@ -149,6 +149,12 @@ void WindowBuilder::makeDefaultTraits(bool stencil)
             SG_LOG(SG_VIEW,SG_DEBUG,"Using initial window size: " << w << " x " << h);
         }
     }
+bool headless = fgGetBool("/sim/startup/headless-mode", false);
+if (headless) {
+ SG_LOG(SG_VIEW, SG_ALERT, "Headless view required: rendering window to pbuffer");
+ traits->pbuffer = true;
+} // enable headless
+
 }
     
 } // of namespace flightgear

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: 11121
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Interfacing

Who is online

Users browsing this forum: No registered users and 1 guest