FlightGear high-level architecture support: Difference between revisions

Jump to navigation Jump to search

FlightGear high-level architecture support (view source)

Revision as of 05:23, 3 August 2014

1 byte added ,  3 August 2014
no edit summary
No edit summary
Line 25: Line 25:
Although the FlightGear design fairly modular it's provided as a single binary. Everyone who wants to create a new I/O module must patch the FlightGear sources and compile the FlightGear binary from scratch. This may discourage those who want to use FlightGear as a tool and extend it in some way. Moreover, it's not always possible to include all functions in a single binary. Some functions may be mutually exclusive.
Although the FlightGear design fairly modular it's provided as a single binary. Everyone who wants to create a new I/O module must patch the FlightGear sources and compile the FlightGear binary from scratch. This may discourage those who want to use FlightGear as a tool and extend it in some way. Moreover, it's not always possible to include all functions in a single binary. Some functions may be mutually exclusive.


The plan is to use HLA/RTI as an aid to parallellize flightgear on a local machine. The basic advantage is that each federate is strictly programmed single threaded. All the thread syncronization is handled by the rti library and hidden in that thing. The trick is that each of these threads must be done in a way that you can just compile that alternatively in a single standalone binary and run the same component in a networked rti - the LinuxTag booth for example.
The plan is to use HLA/RTI as an aid to parallelize flightgear on a local machine. The basic advantage is that each federate is strictly programmed single threaded. All the thread synchronization is handled by the rti library and hidden in that thing. The trick is that each of these threads must be done in a way that you can just compile that alternatively in a single standalone binary and run the same component in a networked rti - the LinuxTag booth for example.


Basically, better HLA support will make it possible for FlightGear to be split into "components" (each running in a dedicated process or in separate thread within the main FlightGear process), making better use of multi-core architectures (SMP), while decoupling the flight simulation from the "viewer" part (i.e. visualization), so that steady/reliable frame rates can be achieved (see [[FGViewer]]), but also to formalize the concept of master/slave instances and synchronizing state among multiple instances (think AI traffic/weather).
Basically, better HLA support will make it possible for FlightGear to be split into "components" (each running in a dedicated process or in separate thread within the main FlightGear process), making better use of multi-core architectures (SMP), while decoupling the flight simulation from the "viewer" part (i.e. visualization), so that steady/reliable frame rates can be achieved (see [[FGViewer]]), but also to formalize the concept of master/slave instances and synchronizing state among multiple instances (think AI traffic/weather).
Line 31: Line 31:
{{cquote|I will provide a different renderer  sometime in the future where I aim to provide better isolation of this kind of renderer options so that people with very different aims can probably coexist better.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39180.html |title=Color-shifts for textures|author=Mathias Fröhlich |date= Sun, 27 Jan 2013 08:45:22 -0800}}</ref>|Mathias Fröhlich}}
{{cquote|I will provide a different renderer  sometime in the future where I aim to provide better isolation of this kind of renderer options so that people with very different aims can probably coexist better.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39180.html |title=Color-shifts for textures|author=Mathias Fröhlich |date= Sun, 27 Jan 2013 08:45:22 -0800}}</ref>|Mathias Fröhlich}}


{{cquote|supporting the option of different viewer / rasteriser front-ends is by far the best solution here, since there are different requirements for different use-cases and target users. Plenty of people are interested in the kind of effects Thorsten's uber-shader and atmospheric model can provide, but plenty of others care more about a solid 60Hz (or even higher), and still others would prefer a solution that works with the fixed-funtion pipeline. And then there's Rembrandt as yet another rendering configuration. My plan in parallel with / after 2.12 is to work with Mathias' HLA code to make  
{{cquote|supporting the option of different viewer / rasterizer front-ends is by far the best solution here, since there are different requirements for different use-cases and target users. Plenty of people are interested in the kind of effects Thorsten's uber-shader and atmospheric model can provide, but plenty of others care more about a solid 60Hz (or even higher), and still others would prefer a solution that works with the fixed-function pipeline. And then there's Rembrandt as yet another rendering configuration. My plan in parallel with / after 2.12 is to work with Mathias' HLA code to make  
this separation possible, unless of course he beats me to it :)<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39181.html |title=Color-shifts for textures|author=James Turner |date=Sun, 27 Jan 2013 09:35:43 -0800}}</ref>|James Turner}}
this separation possible, unless of course he beats me to it :)<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39181.html |title=Color-shifts for textures|author=James Turner |date=Sun, 27 Jan 2013 09:35:43 -0800}}</ref>|James Turner}}


Chriscalef
27

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/74623"

Navigation menu