FlightGear Newsletter March 2012
- 1 Development news
- 2 Interview with a contributor
- 3 Scenery corner
- 4 Aircraft of the month
- 5 Airport of the month
- 6 Screenshot of the month
- 7 Suggested flights
- 8 Searching Wizard Island
- 9 Wiki updates
- 10 Community news
- 11 And finally ...
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.
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.
FlightGear goes to Space, Part II
Coded in less than 8 hours, the Earthview orbital terrain rendering engine is an addon to FlightGear which allows to use orbital phototextures (such as the NASA Pale Blue Marble) on top of the default FlightGear terrain. Combined with the skydome scattering shader, this improves the realism of the visuals of orbital flight in Flightgear substantially.
With some additional patches, finally Vostok-1 is free from the 150 km altitude restriction and can enter high orbits of several hundred kilomters above the planet.
Hopefully this will trigger some activity on the modeller side to add a few more spacecraft to the Flightgear experience!
Development discussion and download is found in the forum topic.
FlightGear gets shadows and lights
The Rembrandt project, that began as a proof-of-concept mock-up and was hosted in a separate repository tree, is being merged into the main repository. A new switch (
--prop:/sim/rendering/rembrandt=true for FGRun) is available to start FlightGear with the new renderer. Without the switch, the scene should be displayed as usual. With the switch on you can get this:
The renderer has several known bugs (shadow disappears at angle, zooming shows color artifacts, ...) and few models and shaders are ready for the new renderer. A wiki page collects the technical details of the project and should help designers to convert their models. Don't hesitate to contribute to that page to bring clarification if needed.
Interview with a contributor
In each edition we try to have an interview with a contributor. Sadly there's no interview in this edition, so we'd like to invite you to write an interview (with him-/herself or others) for next month's newsletter! Suggestions for possible questions are available on interview questions
Miami International Airport
Andyramone has returned from a one 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.
TerraGear GUI updates
Over the past month, the TerraGear GUI, a graphical interface that allows you to generate FlightGear scenery, has been updated to version 0.9.0. This latest version brings support for X-Plane's (and future FlightGear's) 850 apt.dat format. This format allows airport designers to create curved taxiways, accurate lining and lighting, a custom airport boundary and much more.
Altough the 850 support is still a work in progress, it's majure enough to be tested by the average FlightGear contributor. See TerraGear GUI for more details and (download) instructions.
Aircraft of the month
Airport of the month
- Custom airport layout (v.810)
- Taxiway signs
- Terminals, hagars, tower models
- Day/night photorealistic textures
- Details like custom lamps
- Airport service vehicles (ot-666 models)
Screenshot of the month
Piper Comanche 250 off the coast of San Diego.
Searching Wizard Island
- USA, Oregon, Klamath County
Don't pull up the map, that would spoil the surprise but I promise unique views. We will land on a short lawn runway. Terrain altitude will range from 4,000 to a max of 8,930 feet and down again. Total length of the trip will be about 50 NM. Select your aircraft with care. It must have one working navigational radio (VOR-DME), a strong engine, a strong undercarriage, must be capable of a good climb and a steep descend. I suggest to use Fair weather (Environment=>Global Weather). If needed remove some clouds (View=>Rendering Options=>Slider 3d Clouds to the left).
- Park your aircraft on 2S7 (Two Sierra Seven), Chiloguin-State.
- Set NAV1 on 115.9 (Klamath Falls VORTAC) and on radial 323o (Magnetic). We are at an elevation of 4,217 feet. Set QNH. Set heading bug at 275o (Magn).
- Take off an fly the course set with the heading bug.
- Intercept the radial.
- Monitor distance and you will find Wizard Island at 50 NM from Klamath Falls. The island has an elevation of 6,673 feet. I suggest a full 360o turn, take pictures.
- Set radial 318o, keep the same frequency. Do a new radial intercept.
- Try and find the airstrip (3S6, Three Sierra Six, Toketee-State) at 71 NM from Klamath Falls with an elevation of 3,361 feet, runway heading 275o (Magn). There are bumps around you should avoid.
- If you are capable of finding the island, finding the airstrip and landing without a crash, in one go..., you are a wizard.
Click this link after you have landed so you know what amazing landscape you have seen.
As of this month, it is possible to license files on the wiki under licenses other than the GPL (which isn't a good license for images anyway). In the upload form, a dropdown menu allow you to pick a license of your choice (or, when uploading an image from another source, the license compatible with that source). This will automatically add the corresponding template to your file and place it in the license's category.
Besides licensing your files, it is also important to describe them. Therefore a file information template was introduced, which holds a description of the file, the author's name, the source and the creation date. Please add this template to your file right during the upload process.
More information on licenses and the information template can be found at Help:Upload.
FlightGear on YouTube
- ATC Session at Schiphol by Omega - 1 hour of ATCing into 4 minutes of video.
- FlightGear HowTo #23: Installing Aircraft (Revisited) & GIT plane downloading! by Osjcag - How to download aircraft for FlightGear 2.0/2.4/2.6
As of March, the forum team welcomed a new moderator: Hal (hvengel). He will help the team to combat spam, move topics to the right subfora and mediate when issues a rise. We wish Hal all the best in his new job!
And finally ...
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 introduced a new internal command in Git: property-interpolate.
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:
- property-assing the target value describing the state of the button
- (that's what you are used to do)
- property-interpolate the position of the model to it's new state's value
- (that's the new binding to add)
- Animate the model's rotation from the position property, not the state property
- (that's what you have to change)
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>