FlightGear Newsletter March 2012: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Grammar Correction and Standard-English Clarification (please confirm to make sure summary is accurate?))
Line 22: Line 22:
Let's try to describe the thing in simpler terms: Most programs (like FlightGear) have a single large code base where all subsystems get their processing time assigned by so called "main loop" which sequentially iterates over all systems and calls their "update" routine, to give each system time to do its work (update weather, update GUI, update AI, update FDM, update sound etc).  
Let's try to describe the thing in simpler terms: Most programs (like FlightGear) have a single large code base where all subsystems get their processing time assigned by so called "main loop" which sequentially iterates over all systems and calls their "update" routine, to give each system time to do its work (update weather, update GUI, update AI, update FDM, update sound etc).  


Unfortunately, this also means that every subsystem running as part of the main loop has a direct effect on the simulation frame rate, i.e. the total run time cost of each complete update iteration is determined by the time spent in each individual routine, i.e. the total update time adds up: FDM+SOUND+AI+GUI etc
Unfortunately, this also means that every subsystem running as part of the main loop has a direct effect on the simulation frame rate, i.e. the total run time cost of each complete update iteration is determined by the time spent in each individual routine. Because of this, the total update time adds up; all the work of the FDM, sound, AI, GUI... these add up to framerate losses.
 
Basically, all the work FlightGear has to do are separate subroutines systems -and having more of them and more information to run directly affects framerates in-sim.


Whenever you add a new system, you need to add it to the program's main loop and add new source files to the code base of the program. This involves rebuilding FlightGear from source.  
Whenever you add a new system, you need to add it to the program's main loop and add new source files to the code base of the program. This involves rebuilding FlightGear from source.  
Line 30: Line 32:
Only the information that is really required will be exchanged, so the exchange of this information is the only run time footprint, each simulation is responsible to compute and update its own state.  
Only the information that is really required will be exchanged, so the exchange of this information is the only run time footprint, each simulation is responsible to compute and update its own state.  


Communications between each simulation node take place using a computer network and an API (similar to CORBA). All participating simulations are being managed by a central component, called the "Run-Time Infrastructure" (RTI).  
Communications between each simulation node take place using a computer network and an API (similar to CORBA). All participating simulations are managed by a central component called the "Run-Time Infrastructure" (RTI).  
The RTI monitors the overall simulation and manages the distribution of data between all individual nodes, which are called "federates". The simulation in its entirety is called a "federation" in HLA.
The RTI monitors the overall simulation and manages the distribution of data between all individual nodes, which are called "federates". The simulation in its entirety is called a "federation" in HLA.


We have started a new article and copied earlier announcements and postings to it, please see [[FlightGear HLA support (High Level Architecture)]].
We have started a new article and copied earlier announcements and postings to it; please see [[FlightGear HLA support (High Level Architecture)]] for more information.


=== Mailing list digest ===
=== Mailing list digest ===

Revision as of 03:04, 9 March 2012

Magagazine.png
Welcome to the FlightGear Newsletter!
Please help us write the next edition!
Enjoy reading the latest edition!


We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.

Development news

FlightGear and HLA (High Level Architecture)

When reading the FlightGear forums or the FlightGear developers mailing list, you'll probably have noticed the term "HLA" being brought up more and more often recently.

In fact, FlightGear core developers and other contributors seem to bring it up whenever somebody asks about better FlightGear modularization, better concurrency support (i.e. using all your idle CPU power), but also better overall frame rates or a more consistent multiplayer experience and weather environment.

It seems as if "HLA" is the swiss army knife to deal with many long-time FlightGear challenges.

So, what is HLA after all?

In short: HLA, "High Level Architecture", is an industry standard (IEEE 1516) to standardize interactions between component-based simulation architectures in a distributed setup.

Now, that's a mouthful, right?

Let's try to describe the thing in simpler terms: Most programs (like FlightGear) have a single large code base where all subsystems get their processing time assigned by so called "main loop" which sequentially iterates over all systems and calls their "update" routine, to give each system time to do its work (update weather, update GUI, update AI, update FDM, update sound etc).

Unfortunately, this also means that every subsystem running as part of the main loop has a direct effect on the simulation frame rate, i.e. the total run time cost of each complete update iteration is determined by the time spent in each individual routine. Because of this, the total update time adds up; all the work of the FDM, sound, AI, GUI... these add up to framerate losses.

Basically, all the work FlightGear has to do are separate subroutines systems -and having more of them and more information to run directly affects framerates in-sim.

Whenever you add a new system, you need to add it to the program's main loop and add new source files to the code base of the program. This involves rebuilding FlightGear from source.

In HLA, the general idea is to split up a large simulation into a subset of smaller simulations which are interlinked exchanging information (objects and events) to create a consistent simulation environment using a well-defined interface. This division makes it possible to run these simulations in different thread or even in different processes, even running on other computers.

Only the information that is really required will be exchanged, so the exchange of this information is the only run time footprint, each simulation is responsible to compute and update its own state.

Communications between each simulation node take place using a computer network and an API (similar to CORBA). All participating simulations are managed by a central component called the "Run-Time Infrastructure" (RTI). The RTI monitors the overall simulation and manages the distribution of data between all individual nodes, which are called "federates". The simulation in its entirety is called a "federation" in HLA.

We have started a new article and copied earlier announcements and postings to it; please see FlightGear HLA support (High Level Architecture) for more information.

Mailing list digest

(by far the easiest option to populate the newsletter with contents is copying/pasting stuff from the forum and the mailing list)

Forum digest

Git digest

Interview with a contributor (NAME)

In each edition we have an interview with a contributor. Suggestions for possible questions are available on interview questions, you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the list of interview volunteers! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.

  • How long have you been involved in FlightGear?
  • What are your major interests in FlightGear?
  • What project are you working on right now?
  • What do you plan on doing in the future?
  • Are you happy with the way the FlightGear project is going?
  • What do you enjoy most about developing for FlightGear?
  • Are there any "hidden features" you have worked on in FlightGear that new users may miss?
  • What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: Interview questions.

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

Snapshot releases

Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at the issue tracker.

The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found at the forum.

Nasal for newbies

New software tools and projects

FlightGear addons and mods

In the hangar

All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at Google Docs. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at Formalizing Aircraft Status. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.

New aircraft

Updated aircraft

Airbus A320neo

The Airbus A320neo have suffer a deep redesign.

Liveries

Scenery corner

KMIA preview in Sketchup

KMIA

Andyramone has returned from a 1 year Flightgear hiatus to work on modelling the Miami International Airport (KMIA.) There is a basic model already built for the main terminal, which will be available via Terrasync mid-march.

The plan is then to work on improving the model by adding more accurate textures, night textures, movable jetways, and a more accurate airport layout, with the potential to move to a 8.50 airport layout. The surrounding hangars, buildings and Cargo hangar to the south will also be added as they are built.

All models will be GPL compliant and available via Terrasync.

Aircraft of the month

Airport of the month

Screenshot of the month

Suggested flights

Aircraft reviews

Wiki updates

New articles

<DynamicArticleList>

 type=new
 count=10

</DynamicArticleList>

New aircraft articles

<DynamicArticleList>

 type=new
 count=10
 categoryRoot=Aircraft

</DynamicArticleList>

Most popular newsletters

<DynamicArticleList>

 type=hot
 count=5
 categoryRoot=FlightGear Newsletter

</DynamicArticleList>

Community news

FlightGear on YouTube

New tutorials and screencasts

Forum news

Multiplayer

Virtual airlines

FlightGear events

Useful links

And finally ...

Contributing

One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: Volunteer.

Call for volunteers

  • The OpenRadar project is looking for a new maintainer.
  • The FGFSPM (FlightGear Package Manager) is looking for a new maintainer.

Did you know

Torsten recently in Git-a new internal command: property-interpolate [1].

This exposes the SGInterpolator subsystem to bindings in xml animation files. The SGInterpolator allows the interpolation of property values over time and has so far been used via Nasal in aircraft.door.

For an example, start the Hansajet from git (fgfs --aircraft=Hansajet) and zoom to the gyrosyn heading indicator left of the HSI. Locate the black/white knob with "VOR" and "ADF" written on it. Click it (it swaps the assignment of the needle-driving sources) and notice that it does rotate smoothly to its new position (it's a 2-position toggle knob).

Now, look at the overhead panel, either by paning the view up and right or by pressing shift-v on the keyboard. Locate the six rotary buttons GEN.1, GEN.2, ALT.1, ALT.2 and the two between the AC and DC instruments. Move them by clicking their left/right edges. Notice they move smoothly instead of jumping to the new position.

Thats done completely without Nasal but from just a few lines in the animation files. Basically, you have to add two bindings to the <pick> animation: 1. property-assing the target value describing the state of the button

   (that's what you are used to do)

2. property-interpolate the position of the model to it's new state's value

   (that's the new binding to add)

3. Animate the model's rotation from the position property, not the state property

   (that's what you have to change)

4. done.

(see the animations for the object SyncKnob and SyncKnobPick.[LR] in Aircraft/Hansajet/Models/Sperry-C-6d.xml as an example).

The use of the property-interpolate may be:

Change the value of /some/target/property to the constant value of 100.0 over 3 seconds.

<binding>
   <command>property-interpolate</command>
   <property>/some/target/property</property>
   <value>100.0</value>
   <time>3</time>
</binding>

Change the value of /some/target/property to the value of /some/source/property over 0.5 seconds.

<binding>
   <command>property-interpolate</command>
   <property>/some/target/property</property>
   <property>/some/source/property</property>
   <time>0.5</time>
</binding>