FlightGear Newsletter September 2010: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎Nasal for newbies: (recycling my forum posting))
Line 52: Line 52:
With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be  code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.
With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be  code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.


== Nasal for newbies ==
== Nasal for newbies: OOP ==
OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages").
Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields.
So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).
 
These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos).
And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object".
Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.
 
In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values.
So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.
 
This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.
 
For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);
 
That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.
 
This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.
 
Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.
 
So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).
 
Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes.
This is then called "composition".
 
Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".
 
Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.
 
For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.
 
This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.
 
Of course, one may still use objects like conventional variables for passing and returning parameters.
 
== New software tools ==
== New software tools ==
== FlightGear addons and mods ==
== FlightGear addons and mods ==

Revision as of 05:29, 15 September 2010

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.

FlightGear events

Development news

Local Weather v0.85

The version 0.85 (also on GIT) of the Local Weather package is out - with new cloud types and textures and most importantly a significant performance gain over previous versions. There is a new menu to allow the user at runtime to specify cloud visual ranges, so that the impact on framerate can be adjusted to the situation.

The increased performance means that 3d clouds on fast systems can be rendered out to 45 km, and high altitude 2d cloud sheets sometimes up to 80 km - vastly improving the visual impression of the sky from airliner altitudes.

In addition, some bugs in the wind modelling and long-range weather patterns have been ironed out - with Flightgear 2.0.0, the package performs good in tests.

In the works:

  • better hard-coded support for e.g. terrain sampling
  • a METAR interface to use real-time weather and wind data
  • full dynamics of the life cycle of convective clouds as they drift over the terrain
  • and as always - improvements to cloud placement algorithms and cloud textures

Stay tuned!


A small feature gallery:

Water shader improvements

Junkers Ju 52 flying over a lake in the French custom scenery.

Our all-time favourite shader-artist, Gral, picked up yet another project. This time it is something that covers over 70% of the entire scenery and is thus of great importance in a flight simulator: water. The new shader includes more realistic wave movements and much nicer sun "reflections". The extreme goal is to have real-time reflective water, which is still a long way to go, but with Gral's latest improvements we've at least made a step into the right direction. Transatlantic or Carribean flights have never been so exiting in FlightGear!

Weather supporting core code

The new weather dialog

The weather supporting core of FlightGear has been modified during the last weeks to better support new weather models like the above mentioned Local Weather system. Data flow between environment systems is now defined in XML config files using well known syntax and elements from the autopilot. Complex rules using predefined filters and arbitrary expressions can be defined without the need for C++ or Nasal coding. Along with this patch comes a unified weather settings dialog, combining previous dialogs for weather conditions, scenario, clouds and precipitation. Further plans are to integrate a new real world data source NWX, providing METAR, aloft and temperature at altitude.

AI Objects

[ AIWingmen and AITanker

Some of the AI code has been revisited and tidied up, in a somewhat vain attempt to reduce the impact on frame rate. The facilities in Slaved Ballistic Objects, Wingmen, Ground Vehicles, and Escorts have been generalized. Now, any of these types can be subordinated, or parented, on any AI object which has a <name> tag. Thus, a wingman can be formated on a an AI Tanker, and can have a slaved droptank.

A Wingman can be formated on a Wingman to build larger formations. B29 12 Ship Formation

With careful choice of options and locations frame rates can be kept at a reasonable level. Analysis has shown that the tall pole in the tent is the code which measures Altitude Above Ground Level. This is known to be code that is heavy on framerate and which is used extensively in the AI code. It might be possible to get a cheaper, simpler version of this function which would improve the impact on framerate. Hopefully, this will be the next stage of development.

Nasal for newbies: OOP

OOP is all about creating "things" (i.e. a cloud) with "actions" (transform,draw,update) (or "messages"). Where a class (or hash in Nasal) is the "template" for a "thing" containing a number of member fields. So the class only describes the "layout" or properties of objects that can be created. To actually use a class, it has to be "instantiated" which means creating an object using a specific "template class" (or even several different classes).

These member fields can be variables (e.g. lat, lon, alt) or functions (setAlt, setPos). And the actual instance (cloud[n] in the property tree) of such a thing is then called an "object". Functions that work with instance specific state are called "methods", they may refer to instance specific state using a "self reference" (me) in Nasal, that ensures that access to a field or method is using the right instance specific data.

In OOP, internal state is managed by wrapping everything in a class using accessor functions for modifying and getting internal values. So internal state would in turn only be modified by an abstract interface: class "methods", instead of directly accessing class-internal fields.

This provides a way for managing access to a member variable (field), such an abstract interface is also useful for keeping logics private, and internal. For example, the name of a variable "altitude" can be easily changed internally to "altitude_ft", without having to rename all users of the class - simply because all other code will refer to the methods providing access to the field.

For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);

That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.

This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods.

Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities.

So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).

Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes. This is then called "composition".

Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".

Inheritance has the added advantage of providing a means to customize class behavior without having to modify the actual class, because all member fields can be parametrized.

For example, a "cumulus" cloud class could be derived from the "cloud" class, just by parametrizing it (different cloud model, different texture, different transformations), without touching anything in the actual "cloud" class.

This is basically how OOP may be understood: things are classified according to "is a" or "has a" relationship.

Of course, one may still use objects like conventional variables for passing and returning parameters.

New software tools

FlightGear addons and mods

In the hangar

Livery hangar reaches 300

Early September, the FlightGear Livery Database welcomed its 300th livery! It is a livery of the Polish Air Force's Lockheed C130, created by Maciej Zgódka, one of the latest additions to the painters-team. In the same time, the database was upgraded with a couple of new "features":

  • thumbnails of liveries pop up when you hover over a link.
  • a contact page was added, to ease contacting the database maintainer.
  • each livery has a "Report this livery" button, through which visitors can notify the maintainer of a broken download, incorrect or unknown author, licensing issues etc.

I would like to emphasize that lots of liveries are not yet assigned an author. Please check for yourself if there is any unknown-author-livery of which you known/are the author. Lots of liveries are still in the need for a thumbnail, so those are welcome as well.

Scenery corner

UK Football Stadiums

Emirates Stadium in Flightgear

Andyramone has completed and submitted three football stadiums to the scenery database. These include Carrow Road (Norwich), Emirates Stadium (Arsenal) and Stamford Bridge (Chelsea.) Portman Road (Ipswich) and White Hart Lane (Tottenham) are complete and will be submitted to the scenery database this month. The project will continue later this year with more London stadiums including Wembley on the to do list.

Liverpool John Lennon Airport

Andyramone has begun modeling Liverpool Airport (EGGP) in the UK. The terminal is complete and will be submitted to the database this month. Work has already begun on the control tower.

KSFO Terminal 2

San Fransisco International Terminal 2 has been fully remodelled by karla in Blender 2.49b using handmade textures in Gimp 2.46. New additions include: linking wings, antennae, railings, supports, ground floors interiors, ATC equipment, vigilant controller, architecture, light masts, night textures.

It has been released and is available from the Git database or directly from http://www.mediafire.com/file/ev447wrsqrfijlf/KSFO_T2.zip

The associated 942050.stg file has been changed slightly and it may also be downloaded for replacement in /Scenery/Objects/w130n30/w123n37/.

Aircraft of the month

Airport of the month

Screenshot of the month

Suggested flights

Hawai'i

Maui03.jpg

Do you use TerraSync? If so, try a flight around Hawaii! Take off from PHNL in a light aircraft and head west until you hit Pearl Harbor; a right turn north will take you post the USS Arizona Memorial, and the Punchbowl Crater will be to your right. Or, fly east from PHNL past volcanic craters Diamond Head and Koko Head. If you follow the O'ahu coastline north from Koko Head, you can land at either old World War II airbase Bellows Field (now a wildlife reserve in real life) or at Keahole MCAS.

For a potentially more scenic route, fly east toward Molokai, and stay to the north (left) of the island. The northern part of Molokai features huge sea cliffs and a tiny airstrip on the Kalaupapa peninsula - the peninsula being the only respite from the cliffs. A former leper colony existed near the airstrip!

Also of interest are the volcanoes on Maui and the 'Big Island' of Hawai'i - flying VFR in a small plane from PHTO to PHKO over the plateau between Mauna Kea and Mauna Loa can be a challenge, as you have to take off from sea level, fly through a pass of 6500 feet, and then drop back down to sea level to land! The Hana coast of northern Maui is also a nice flight - a circumnavigation of Haleakala, starting and ending at PHOG, is quite a nice flight.

The islands will be available through the download center with the next major scenery release, but for now, fire up TerraSync and your favorite VFR aircraft and have a blast.

Aircraft reviews

Community news

FlightGear on youtube

  • Ten students at NASA's LARSS (Langley Aerospace Research Summer Scholars), put together an autonomous robotics lab, using mostly open source tools. One of which is a FlightGear Multiplayer Server.

Watch the FlightGear PlayList for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

Forum news

Wiki updates

Multiplayer

Virtual airlines

Useful links

And finally ...

Next FSWeekend event takes place November 6 & 7th 2010. Mark this date in your calendar and expect an outstanding presentation of FlightGear's features at Lelystad's airport.

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.

Reminder: Google's Summer of Code 2011

We would like to remind all readers that the FlightGear project is planning to participate in GSoC 2011. However, doing that really requires a fair amount of work, planning and organizing. This is not something that can be done by a single person. It really needs a coordinated team effort, or otherwise FlightGear won't be able to apply/participate at all.

So all users are invited to help us progress further with our preparations for GSoC 2011. If you have any questions or other feedback, please use the forum to get in touch.

Did you know