FlightGear Newsletter November 2013: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 40: Line 40:
MapStructure is going to be common backend for all charting needs in FlightGear, not just in instruments (i.e. MFDs like the ND), but also in GUI dialogs (Map, instructor console, ATC etc).  
MapStructure is going to be common backend for all charting needs in FlightGear, not just in instruments (i.e. MFDs like the ND), but also in GUI dialogs (Map, instructor console, ATC etc).  


Currently, there are still some minor performance issues (especially on less powerful computers), which we hope to resolve by moving some parts into C++ space, hopefully in time for the 3.0 release (Out Canvas/C++ guys, TheTom and Zakalawe are looking into it).
Currently, there are still some minor performance issues (especially on less powerful computers), which we hope to resolve by moving some parts into C++ space, hopefully in time for the 3.0 release (Our Canvas/C++ guys, TheTom and Zakalawe are looking into it).


Please get in touch if you have any questions or if you'd like to get involved in some way.
Please get in touch if you have any questions or if you'd like to get involved in some way.

Revision as of 17:52, 29 November 2013

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. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release. At the end of each month, it's generally a good idea to get in touch with other contributors to ask them to add news about their contributions to the newsletter.


Available in: English Please help us translate in other languages!

Development news

Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: Next Changelog.

Atmospheric Light Scattering

The Atmospheric Light Scattering rendering framework adopts a technique that has recently been introduced for the default and the Rembrandt rendering framework which allows to utilize a global map of Ocean water depth. This allows to render the shallow waters around islands in a compelling way. Combined with the ability of ALS to change the basic water color based on location and weather conditions/sky appearance, many combination of shallows, mud content and weather conditions can now be addressed by the highest detail water shader effect.

Water depth mapping in ALS

Initial OsgEarth integration

Thanks to recent work by forum user poweroftwo we now have initial osgEarth integration featuring a runtime selectable option for the terrain scene in FlightGear. Once enabled, osgEarth renders the terrain scene by building the textured geometry at runtime from raw source imagery and elevation data. Load times for an unvisited location are surprisingly fast given a respectable Internet download rate. For locations previously visited, an optimized file cache data is saved for rapid loading.

Input data can come from a variety of sources including web mapping services or local source data (e.g. geotiff) stored on disk. Once rendering is enabled, the entire FlightGear terrain scene graph is replaced along as well as the scene elevation queries. However, the native terrain implementation remains fully intact and can be restored by disabling osgEarth from its configuration dialog.

The benefits gained from this initial osgEarth integration include geo-specific imagery rendered in real-time from a variety of sources that are available worldwide; tiled terrain on demand; and high altitude views from anywhere above the earth. However, this implementation with FlightGear includes some notable limitations listed in the compromises section.

Learn more at http://forum.flightgear.org/viewtopic.php?f=6&t=21351

Introducing two new Frameworks: NavDisplay & MapStructure

MapStructure demo
a NavDisplay-driven Canvas/GUI dialog

In a joint effort, Gijs' original Boeing 744 NavDisplay/Canvas code has meanwhile been sufficiently generalized to be also usable in other aircraft without having to copy/paste lots of code (typically, ~30 lines will do). Hyde's 777-200ER being the very first adopter for the time being, with the added bonus that the 777-200ER now also supports independent ND instances, i.e. independent displays and switches for each pilot. Hyde is also planning on implementing 777-specific features. Currently, none of this is in fgdata yet, but Gijs and Hyde are going to review the new NavDisplay framework to hopefully get it committed soon.

In the meantime, Philosopher and Hooray have started working on a new Nasal framework, called MapStructure, to easily create charting displays like the NavDisplay with very little specialized Nasal code being required. Once the MapStructure framework is completed, we will work towards porting our old *.layer/*.draw/*.model files to make use of the new MapStructure framework and adapt the NavDisplay framework accordingly.

MapStructure is going to be common backend for all charting needs in FlightGear, not just in instruments (i.e. MFDs like the ND), but also in GUI dialogs (Map, instructor console, ATC etc).

Currently, there are still some minor performance issues (especially on less powerful computers), which we hope to resolve by moving some parts into C++ space, hopefully in time for the 3.0 release (Our Canvas/C++ guys, TheTom and Zakalawe are looking into it).

Please get in touch if you have any questions or if you'd like to get involved in some way.

Getting started with CppBind

FlightGear's built-in Nasal scripting language comes with a set of standard libraries, and can be extended using FlightGear specific APIs.

Until FlightGear 2.8, the Nasal scripting engine only provided a C API to expose such hooks/bindings to scripting space or to expose scripting space data structures back to C/C++.

Exposing simulator internals to scripting space is a fairly common and useful thing, because it enables base package developers to access these internals without having to build FlightGear from source, so the barrier to entry is significantly lower and we've seen an increasing number of novel features purely implemented in scripting space, due to powerful APIs being available to aircraft developers and other base package developers.

Unlike the core Nasal engine itself (which is C), FlightGear however is mostly written and being developed in C++. For quite a while, that meant that the Nasal APIs were a bit low-level, and sometimes also awkward to use when making functions, data structures or objects accessible between C++ and Nasal.

Thanks to Tom's Canvas system, there's now a new bindings framework to be found in simgear/nasal/cppbind. This is fully object oriented and supports modern C++ features.

You will find that most of the "old" code in $FG_SRC/Scripting still uses those old C-APIs for interacting with the Nasal engine. Only the new code, #include'ing <simgear/nasal/cppbind>, uses boost templates to hide low level details.

Most of the code in the Nasal subsystem itself (FGNasalSys) also still uses the legacy C APIs - this is just to explain the two approaches, to avoid unnecessary confusion. You will find the old, low-level APIs explained at Howto:Extend Nasal.

The cppbind framework is much more generic and high level than the bare C APIs, cppbind includes unit testing support and makes use of modern C++ features like templates and STL support, including SimGear specific types like SGPath/SGGeod etc, its overhead is fairly small (not just performance, but also LoC to create new bindings). The cppbind framework is already extensively used by the Canvas system and the NasalPositioned_cppbind bindings, both of which are a good place to look for code examples.

Continue reading at Nasal/CppBind...

FGRun repository changes

The FGRun Git repository now uses the same branch concept as FlightGear and SimGear. Current development takes place in the next branch, while release/X.X branches are created for each release. In addition to that the FGRun version number is now in sync with FlightGear/SimGear, to make it easier to see whether your FGRun and FlightGear builds match.

The Walker

The Walker is currently made portable to be easily incorporated in arbitrary Aircraft. Additionally, an animatable Pilot Model for Cockpit Placement is in development. Walker and Crew will be supporting different Hand Poses, such as pointing, a Fist, thumbsup or a Victory Sign.

The male Walker The female Walker A Pilot Model, Co-Pilot and Crew are to come. Hand Poses that will be selectable within the Animation Dialog

Random Buildings

Canvas System

High Level Architecture

Usability Improvements

Getting involved as a programmer

Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.

If you are interested in contributing as a core developer, please see Howto:Start core development.

Release ChangeLog

This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

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

Nasal Internals for hackers: Intern'ing symbols

Contributed by Philosopher

As some of you experienced Nasal/C-code hackers should recall, or even those familiar with scripting languages internals, namespaces are just hashes, with keys representing symbols - right? Well yes, mostly, but each of those symbols are unique in a way from all of the other strings out there: they're interned. (Interning is a process that takes strings and a dictionary and returns a matching string, adding one if needed. That means equal strings are substituted so they have the same pointer, i.e. one string represents all instances of "io", stored in a pool/hash of all used symbols.) Though these interned strings appear at runtime in the keys in namespaces, they get created during code generation (codegen), where the symbols (TOK_SYMBOL) get converted to Nasal strings, are interned to get the correct string (using the globals->symbols hash), and are stored in the naCode's constants' block. From there, the symbol-strings are used to set and get various lvalues (both local/global symbols and objects' members) in an optimized way (that's the whole point of the exercise). Looking at hash.c, there are some specialized functions that make use of the potential optimizations:

  • naiHash_sym (looks up an interned symbol)
  • naiHash_newsym (adds a symbol in the first empty slot for the hashcode)

(There's another that looks similar, naiHash_tryset, but it does not deal with interned symbols: it uses the findkey() method, which in turn uses the equals() method that checks for more general key equality instead of simple pointer equality.)

The first, naiHash_sym, is pretty neat and the prime example of the optimization: it runs through a hashcode's potential slots, checking only pointer equality (note that interned symbols' hashcodes are computed during interning, so that's another step that doesn't have to be done are runtime). naiHash_newsym is another nice optimization but a little problematic, due to its assumption that the key doesn't exist already. It's basically used for adding another argument as a local key, but it doesn't care about if it exists already, it just sees an occupied slot and keeps going. Consider the following example that illustrates calling with an argument into a hash that already has the argument's key in it:

var f_creates_arg = func(arg...) {
    foreach (var k; keys(caller(0)[0]))
        print(k);
    debug.dump(arg);
}
call(f_creates_arg, nil, nil, {arg:nil}); # call into namespace: arg=nil; with arguments of: arg=[]

This should print:

arg
arg
nil

This shows that the key is being set twice (which violates a normal precondition of hashes): once as an argument and once to create an existing key in the namespace. The one set first is the one being picked up (e.g. the arg in {arg:nil} versus the arg... that equals []). And this behavior persists even through resizing: hashset() (which is used to reinitialize a hash after reallocation) only keeps appending keys in empty slots, so the number of keys doesn't change (even if there are multiple of the same keys).

For this reason, I would suggest amending naiHash_newsym to check keys' pointer equality before continuing; that way symbols aren't "trodden" over like this. (Please note that if "arg" exists in the hash as non-interned, then it will be trodden over anyways; having to look for non-interned symbols would mainly violate the point of the optimization at this step, and doesn't actually matter in the long run.) I would argue that finding an existing key (a few simple pointer comparisons!) would be more efficient generally, because the hash would never need to be resized if an existing one is found, whereas the old version would append regardless. (I think I once counted well over a hundred "arg" symbols in the __js0 namespace from the continual firing of bindings, which obviously isn't good.)

Continue reading at [1].

New software tools and projects

FlightGear addons and mods

New textures and lightmaps for random buildings

New textures and lightmaps for the random buildings areas.

Lightmap terrain at noon
Lightmap terrain at night

The urban lightmap works using a modified urban shader + modified urban effect, the modified files need to be improve to make work the original urban shader when the random building function is off and enable new shader when the random building function is on.

Installation:

1- unzip the file

2- copy, paste and replace a) urban.eff at $FG ROOT/Effects/ b) urban.frag , urban-gbuffer.frag and urban-lightfield.frag at $FG ROOT/Shaders/ c) buildings.png and buildings-lightmap at $FG ROOT/Textures/

3- i suggest to change the random building density to the middle of your computer default settings, you can make this by edit at autosave.xml or autosave_2_12.xml (depend your version), at the line "<building-density type="double">1</building-density>"

4- FAQ

Where is $FG ROOT? please click here

Where is autosave.xml or autosave_2_12.xml? please click here

If you want to go back to the default effects, please download this package and follow the installation instructions again

Download from here

Download default textures and effects from here



In the hangar

Tupolev Tu-134

The "whistle" taking speed for take-off.
You can choose one of the 3 noses.

The Tupolev Tu-134 dev team proudly announce a new soviet airliner for FlightGear! Some have already read a topic about it at the Forum. The release of version 1.0 is underway and will arrive soon. This YAsim aircraft has a very good FDM, great exterior and a basic cockpit. To contribute (read improve cockpit for example) contact us at the forum


Promo movie



Many Thanks to Helijah, Buckaroo, Cossack90.

New aircraft

The Oasis of the Seas has been released to the public and getting updates, it's sister ships and ferries are coming in from the ACJZA Hangar as well! If you have any skill with coding, it'll be thankful if you could help me. http://forum.flightgear.org/viewtopic.php?f=4&t=21277

Updated aircraft

EC130-B4 Ecostar

The EMS variant of EC130-B4, used by MedFlight, Ohio, USA
New Livery of Grand Canyon Helicopters
Closeup of EC130 Mainrotor, fully animated in all details
EC130 Helicopter using the SX-16 Nightsun searchlight
Even the pilot window can be opened now

The Eurocopter EC130 B4 helicopter is on short final for a new major upgrade. The existing model, which already had been of very high quality, has been refined in various aspects with lots of effort by mhab. The outside model has been enriched to a degree which should justify a 5* rating and the overall status of the aircraft improves to "production".

The Rotorhead has been brought to a new level of detail, a full detailed Fenestron was added and animations were introduced to all moving parts.

Cockpit was enriched for Pilot/Copilot controls, seats are textured now and a variable cabin configuration allows to set up an Emergency Medical Services (EMS) variant, which comes preconfigured with a new Livery of N130NE MedFlight (Ohio).

Fans of Grand Canyon Helicopters now find a livery of the N155GC and the colorful painting in red/gold.

A lot of equipment (most of which was there already but hidden) can now be used, including a full blown SX16-Nightsun searchlight.

All of this has been brought together in a fully integrated configuration dialog which allows to set-up livery, fuel, extra views, weights, cabin setup and equipment.

Extra gimmics include a fully animated pilot, glass reflection on windows and front shield and variable rotor wakes depending on the strength of the downwash.

If you can't wait for the next release check it out from the Git-Hangar

Some of the most interesting changes:

  • Mainrotor fully animated and adapted to original
  • Fenestron fully designed and animated, incl. control rod
  • Cockpit Controls added: Stick, Collective, Pedals, Co-Pilot Controls (optional)
  • Doors movable
  • Searchlight
  • Snowshoes
  • Hoist/Hook
  • Checklists implemented with conditional display
  • Pilot: fully animated
  • Autostart/Autoshutdown enabled after 15 flights
  • Rotor-Wakes off-low-medium-high cyclable
  • Sound improved (doors moving, low/high rotor rpm, overspeed warning, and noise inside depends on open doors/window)


Configuration Dialogs and Help Screens:

Things on stack for FG 3.0:

  • Rembrandt support
  • BUG fixing

Liveries

Scenery corner

Airports

Aircraft of the month

Airport of the month

Screenshot of the month

Suggested flights

Aircraft reviews

Wiki updates

Translators required

En.gif The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at Help:Translate.
De.gif Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit Help:Übersetzen an.
Nl.gif De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij Help:Vertalen.
Es.gif La FlightGear wiki todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en Help:Traducir.

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.

To learn more about how the project works, please see this short essay written by Thorsten, for a more detailed article see How the FlightGear project works.

Call for volunteers

  • The Target4Today team is looking for volunteers to help improving FlightGear's combat support

Did you know