FlightGear Headless: Difference between revisions

Jump to navigation Jump to search

FlightGear Headless (view source)

Revision as of 19:09, 10 August 2017

9,827 bytes added ,  10 August 2017
→‎FlightGear Headless
(24 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Non-stable|version=4.x|progress=30}}
{{Non-stable|version=2018.x|progress=30}}


{{Portability Navbar}}
{{Portability Navbar}}


= FlightGear Headless =
= FlightGear Headless =
{{Main article|Supporting multiple renderers}}
there is no document listing the minimum set of stable features. If someone wants to write one, they can do it, but I guess they won’t volunteer to test release candidates against it; indeed getting people to even run them has been a struggle.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35990557/
  |title  =  <nowiki> Re: [Flightgear-devel] carrier features: is there any modification ,
your policy related ? </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Aug 10th, 2017
  |added  =  Aug 10th, 2017
  |script_version = 0.40
  }}</ref>
with the new test framework it should be possible to add tests for carrier start, as I already did to ensure runway selection with METAR. Indeed the position init code is a very good candidate for testing this way since we broken different aspects (parking position startup, WXR runway selection, the carrier, probably some more things<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35990557/
  |title  =  <nowiki> Re: [Flightgear-devel] carrier features: is there any modification ,
your policy related ? </nowiki>
  |author =  <nowiki> James Turner </nowiki>
  |date  =  Aug 10th, 2017
  |added  =  Aug 10th, 2017
  |script_version = 0.40
  }}</ref>
The original FG scene graph design is based on rigid assumptions of the ordering of the sequence of events for start up and shut down. Branch management is highly inconsistent, and is scattered all over the flightgear and simgear codebases. But it worked perfectly due to the fixed event sequences. The new subsystem design however brings in a much more flexible design, whereby systems can be dynamically turned on, turned off, restarted, initialised, reinitialised, etc. This is essential for enabling rebooting, and allows for custom FlightGear usage of only a small subset of systems and for '''a headless mode'''. The OSG+subsystem breakage occurred once the scene manager subsystem was fully converted to the new design. The OSG scene graph root is created at the start of FGScenery::init(). With the subsystem design, the scene graph root may not be present when other flightgear/simgear code paths are called to create, manage, or destroy the various scene graph branches.<ref>{{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/35048478/
  | title  = <nowiki>[Flightgear-devel] Integration of the new subsystem design and the
OSG scene graph management.</nowiki>
  | author = <nowiki>Edward d'Auvergne</nowiki>
  | date  = Apr 28th, 2016
  | added  = Apr 28th, 2016
  | script_version = 0.26
  }}
</ref>
Another option is to make [[The FlightGear Rendering Pipeline|FGRenderer]] the optional piece - James Turner started doing some work in this direction in December 2015. I.e without FGRenderer there is no rendering at all, and hence no scene-graph.<ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/35064249/
  |title  = <nowiki>Re: [Flightgear-devel] Integration of the new subsystem design and
the OSG scene graph management.</nowiki>
  |author = <nowiki>James Turner</nowiki>
  |date  = May 4th, 2016
  |added  = May 4th, 2016
  |script_version = 0.31
  }}
</ref>
we should really do with with subclassing, making an SGDisplaySubsystem with:
* virtual void initVisuals();
* virtual void updateVisuals();
* virtual void shutdownVisuals();
With the expectation that the manager layer (FGScenery or FGRenderer) calls initVisuals / updateVisuals / shutdownVisuals if it exists. This also forces the implementation of each subsystem to distinguish simulation pieces (modifies properties) from display pieces (reads but hopefully does not modify properties, modifies OSG/rendering state, i.e. visuals) <ref>{{cite web
  |url    = https://sourceforge.net/p/flightgear/mailman/message/35064249/
  |title  = <nowiki>Re: [Flightgear-devel] Integration of the new subsystem design and
the OSG scene graph management.</nowiki>
  |author = <nowiki>James Turner</nowiki>
  |date  = May 4th, 2016
  |added  = May 4th, 2016
  |script_version = 0.31
  }}
</ref>
<references/>
== Motivation ==
== Motivation ==
{{FGCquote
|1= 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
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=277299#p277299
  | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
  | author = <nowiki>bugman</nowiki>
  | date  = Feb 23rd, 2016
  | added  = Feb 23rd, 2016
  | script_version = 0.25
  }}
}}
{{FGCquote
{{FGCquote
|1= what remains true is the that overwhelming majority of the FlightGear main loop time is spent rendering the graphics.
|1= what remains true is the that overwhelming majority of the FlightGear main loop time is spent rendering the graphics.
Line 81: Line 156:
}}
}}


{{FGCquote
== Proof of concept (patch) ==
  |the main camera is created in CameraGroup::buildCamera and a pbuffer is allocated when you set osg::GraphicContext::Traits.pbuffer to true. These traits are available in buildCamera because we set width and height there. For debugging purpose, you can add a line like
{{Note|This will not actually disable rendering, but merely hide the window by rendering to a pbuffer (FBO)}}
The main camera is created in CameraGroup::buildCamera and a pbuffer is allocated when you set osg::GraphicContext::Traits.pbuffer to true. These traits are available in buildCamera because we set width and height there. For debugging purpose, you can add a line like
<syntaxhighlight lang="cpp">window->gc->getTraits()->pbuffer=true;
<syntaxhighlight lang="cpp">window->gc->getTraits()->pbuffer=true;
</syntaxhighlight>at the end of this function.
</syntaxhighlight>at the end of this function.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=179978#p179978
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=179978#p179978
     |title=<nowiki>Re: run without osg</nowiki>
     |title=<nowiki>Re: run without osg</nowiki>
     |author=<nowiki>FredB</nowiki>
     |author=<nowiki>FredB</nowiki>
     |date=<nowiki>Sun Mar 24</nowiki>
     |date=<nowiki>Sun Mar 24</nowiki>
   }}
   }}
}}
</ref>
 
<syntaxhighlight lang="diff">
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
</syntaxhighlight>
 
 
For reference, to disable the window. It's the last thing before the return statement in WindowBuilder::makeDefaultTraits(bool stencil):
<syntaxhighlight lang="cpp">    char* fg_gui = getenv("FG_GUI");
    if (fg_gui != NULL && strcmp(fg_gui, "disabled") == 0) {
      printf ("danna_fg_gui: %s\n", fg_gui);
      traits->pbuffer = true;
    }
</syntaxhighlight>
 
just set an environment variable in my shell called FG_GUI and then this little hack works.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=291699#p291699
  |title  =  <nowiki> Re: Headless mode with access to property tree </nowiki>
  |author =  <nowiki> alexklibisz </nowiki>
  |date  =  Aug 1st, 2016
  |added  =  Aug 1st, 2016
  |script_version = 0.40
  }}</ref>
 
<syntaxhighlight lang="bash">
export FG_GUI=disabled
</syntaxhighlight>


== Status (07/2014) ==
== Status (07/2014) ==
Line 126: Line 255:


With this, change, it's possible to dynamically add and remove the traffic-manager at runtime, for example:  
With this, change, it's possible to dynamically add and remove the traffic-manager at runtime, for example:  
<syntaxhighlight lang="nasal">fgcommand("add-subsystem", props.Node.new({ "subsystem": "traffic-manager", "name":"traffic-manager", "do-bind-init":1}));</syntaxhighlight><ref>{{cite web |url=https://gitorious.org/fg/flightgear/commit/8608a480736651999c5ea31a489343ee097ee915 |title=Initial work on dynamic subsystem creation.|author=James Turner |date=Oct 01, 2012}}</ref>|James Turner}}
<syntaxhighlight lang="nasal">fgcommand("add-subsystem", props.Node.new({ "subsystem": "traffic-manager", "name":"traffic-manager", "do-bind-init":1}));</syntaxhighlight><ref>{{cite web |url={{flightgear url|commit=8608a480736651999c5ea31a489343ee097ee915}} |title=Initial work on dynamic subsystem creation.|author=James Turner |date=Oct 01, 2012}}</ref>|James Turner}}


{{cquote|could some thought be given to producing a benchmark suite for Flightgear. It would need to take in all of the, by now well known, variables - making it by no means a simple beast to manage.
{{cquote|could some thought be given to producing a benchmark suite for Flightgear. It would need to take in all of the, by now well known, variables - making it by no means a simple beast to manage.
Line 194: Line 323:


== Introducing Regression Tests to FlightGear ==
== Introducing Regression Tests to FlightGear ==
{{See also|Testing}}
{{FGCquote
|1= I am working on a comprehensive test suite for the flightgear codebase (simgear already has its own). I will present this later on, but only once I have fully functional Windows support. The design of this test suite will allow individual subsystems to be initialised in full isolation. It will allow for the standard subsystem methods (init, reinit, bind, unbind, update, etc.) to be called in any order in a highly repetitive manner. It is a little like Hooray's segfault paradise - the reinit.nas reset/re-init control panel [1] - in that it is great for fishing out a tonne of segfaults. I have used this for stabilising the FGPythonSys experiment [2]. This would really help with implementing the above design and making the OSG heavy subsystems fully independent.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/35048478/
  | title  = <nowiki>[Flightgear-devel] Integration of the new subsystem design and the
OSG scene graph management.</nowiki>
  | author = <nowiki>Edward d'Auvergne</nowiki>
  | date  = Apr 28th, 2016
  | added  = Apr 28th, 2016
  | script_version = 0.26
  }}
}}
{{FGCquote
|1= 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.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=277299#p277299
  | title  = <nowiki>Re: FGPython an propose for Python as an nasal alternative</nowiki>
  | author = <nowiki>bugman</nowiki>
  | date  = Feb 23rd, 2016
  | added  = Feb 23rd, 2016
  | script_version = 0.25
  }}
}}
{{FGCquote
|1= Personally I would be reluctant to add a framework dependency (CppUnit / Google Test) unless the benefits are large and thus far I wasn’t convinced. The nasty macro-based tests are my hack and could / should be improved. Boost is a bit of a debating point in the project, I’d suggest to avoid it for tests again unless there is some massive benefit. Reflecting on this have written the above, if there was a common framework which could replace my hacks, but also avoid Boost, I’d personally be okay with that providing it’s an optional compile time requirement. Whatever the solution, it should be runnable via CTest, and if it generates output that Jenkins can parse, that would be fantastic. Non-Ctest compatible solutions would be possible but mean some build infrastructure changes.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/33628094/
  | title  = <nowiki>Re: [Flightgear-devel] SimGear/FlightGear Portability Patches</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Mar 23rd, 2015
  | added  = Mar 23rd, 2015
  | script_version = 0.25
  }}
}}


{{FGCquote
{{FGCquote
Line 274: Line 441:


== Milestones ==
== Milestones ==
* allow FlightGear to be run without creating a visible GUI window, i.e. in "headless" mode, using a --headless parameter {{Pending}}
* allow FlightGear to be run without creating a visible GUI window, i.e. in "headless" mode, using a --headless parameter {{Done}}
* allow FlightGear to be optionally compiled and run without any sound support/dependencies (OpenAL) {{Done}}
* allow FlightGear to be optionally compiled and run without any sound support/dependencies (OpenAL) {{Done}}
* allow replay buffers to be saved to a file in order to be replayed for automated test/demo flights, so that users can share saved replay buffers when reporting a bug {{Done}} (supported via the flight recorder subsystem)
* allow replay buffers to be saved to a file in order to be replayed for automated test/demo flights, so that users can share saved replay buffers when reporting a bug {{Done}} (supported via the flight recorder subsystem)
Line 285: Line 452:
* http://forum.flightgear.org/viewtopic.php?f=18&t=19502&p=179978&hilit=#p179968
* http://forum.flightgear.org/viewtopic.php?f=18&t=19502&p=179978&hilit=#p179968
* https://code.google.com/p/flightgear-bugs/issues/detail?id=882
* https://code.google.com/p/flightgear-bugs/issues/detail?id=882
* {{flightgear commit|af6611d7f61a6d993ce94fa6efade0b4485eb7a5}}


== Devel List ==
== Devel List ==
Line 291: Line 459:
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29907.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29907.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg02028.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg02028.html
== References ==
{{Appendix}}


[[Category:Core development projects]]
[[Category:Core development projects]]
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/92949...109551"

Navigation menu