20,741
edits
FlightGear high-level architecture support: Difference between revisions
Jump to navigation
Jump to search
FlightGear high-level architecture support (view source)
Revision as of 17:31, 17 December 2015
, 17 December 2015→Objective
| Line 19: | Line 19: | ||
= Objective = | = Objective = | ||
{{FGCquote | |||
|1= what is very near is that we can do the phsyics in parallel with the cull and draw stage on a different cpu. That will utilie multi core machines in this current generation very well. Also osg allows us to feed multiple views from within one single application where each view runs its cull and draw on its own cpu. Osg provides much more here, but for the first cut this describes it well enough. Given that in the near future only the update step does communication between the physics part and the IG part we have many places where the physics pipeline stage feeds the IG pipeline stage identified, I can see a good chance to do that update step with data feed over a network interface. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/15257350/ | |||
| title = <nowiki>Re: [Flightgear-devel] More ideas on dogfighting</nowiki> | |||
| author = <nowiki>Mathias </nowiki> | |||
| date = May 14th, 2007 | |||
| added = May 14th, 2007 | |||
| script_version = 0.23 | |||
}} | |||
}} | |||
[[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" 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 [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]] | [[File:Dedicated-aircraft-subsystem-group-for-fgcanvas.png|600px|thumb|checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" 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 [http://forum.flightgear.org/viewtopic.php?f=71&t=23499]]] | ||