FlightGear Newsletter July 2021

From FlightGear wiki
Jump to navigation Jump to search

Magagazine.png
Enjoy reading the latest edition!
Please help us write the coming edition!
July 2021

We would like to emphasize that the monthly newsletter cannot live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. 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

2020.3.11 release

FlightGear 2020.3.11 LTS point release is out - see the change logs. FlightGear 2020.3.10 was a soft release to check for any issues that was not announced on the website or in the update available notification in the launcher. This release includes a web installer for Windows that can update old 2020.3.x versions faster by downloading only changed files - download FlightGear-2020.3.11-web.exe from sourceforge.

This follows the FlightGear 2020.3.9 LTS release that first added a web-installer for Windows. See 2020.3.9 LTS change log - included were improved regional definitions for Mediterranean Africa, improvements to shallow ocean water and inland water in certain areas, improvements to ATC dialog etc.

Web installer for Windows with 2020.3.9+

This Windows web-installer (Sourceforge download) can update any old 2020.3.x install by downloading a small ~200 MB package containing all content files changed since the first release. If you are on Windows you should use the web-installer for faster download and install - be sure to back up any changes due to tinkering you may have done to the /data folder.

  • The Windows web-installer is called FlightGear-2020.3.x-web.exe. It contains the contents of the /bin folder - like executable (.exe) files and library files (.dll). FlightGear-2020.3.9-web.exe is 59 MB.
  • If an old 2020.3.x install is present according to the Windows registry, and the folders have not been deleted or renamed, the web-installer will download FlightGear-2020.3.x-update-data.txz.from the Sourceforge 2020.3 release folder. This contains files in the /data folder that have changed since the first 2020.3 release. It's around ~200 MB compressed. The current compressed file format is TXZ - XZ This is a link to a Wikipedia article compression after combining all files into an uncompressed tar archive. TXZ archives can be opened with a tool like 7zip.
  • If no 2020.3 install is present according to the registry, or the folders have been deleted, the web installer will download FlightGear-2020.3.x-data.txz - which contains the full contents of the /data folder and is 1.7 GB currently.

Slawek and JamesT have been working on a new FlightGear Windows installer that will download most of the content from the web in compressed form - e.g. from Sourceforge servers. This installer has the ability to download more than 2GB of compressed content, and avoids the 2GB limit of the current innosetup installer configuration.

The plan is to also eventually allow in-place updating without needing to download a new installer when a new point release is published of the LTS - the idea is to download only the changed files (incremental updates). Downloading only changed files is faster, and hugely reduces bandwidth demands placed on Sourceforge. Recent installers (e.g. 2020.3.8 LTS) will also look for updates and notify users. This means that a lot of people will get bug fixes very quickly, and in-future, it should be convenient to have frequent releases with one or a few fixes as they become available. With the auto update feature there's not much reason to panic if a bug or issue has been found in your work - the fix can be distributed very quickly to the large majority of users (with the regular point release format it was pretty quick compared to previous times anyway).

Web installers for release candidate are automatically generated from 2020.3.9 onwards, and will be available from download.flightgear.org along with the normal installer.

The road ahead

See Help Wanted.

There are a lot of big projects that are currently under way - see the January newsletter for details for some of these projects. A lot of work (but not all) is already on the next branch (i.e. nightly builds). See below for info on an experimental rendering pipeline that has just been added to the next branch, as well as a new project to add Virtual Reality headset support to FlightGear.

There is a lot to check out if you are curious - power users can run multiple installs of FlightGear in parallel. To contribute to any aspect of these projects, get in touch via the "fg-devel" mailing list.

Nightly builds with some of the big changes are available at download.flightgear.org as usual.

Nightly builds and the "next" branch are building towards a "development preview" release currently planned for sometime in the 2nd half of 2021 - see the April newsletter. As usual, plans can change and progress depends on the availability of contributors (including testing).

Please report bugs and issues via the sourceforge tickets system if you come across any on the next branch, or LTS.

New rendering pipeline for Compositor - HDR pipeline

Fernando has been experimenting with adding new rendering features, using the capabilities of the Compositor - see page for the new HDR pipeline. The work is "*very* experimental", as Fernando said. The first commit has been added to the FlightGear next branch - this is a very limited prototype that is not yet fit for even bug reporting.

For those curious to see the prototype, just switch to the HDR pipeline:

  • use the following command-line option: --compositor=Compositor/HDR/hdr
  • To enable the command-line option simply copy/paste the line into the FlightGear Qt launcher > Settings > Additional Settings, or use the command-line or add it to the fgfsrc file
  • Notes (The HDR pipeline is under heavy development - by the time you read this the prototype may have improved/changed several times):
    • Right now, FG will crash if any terrain is in view. So you need start over the ocean - or otherwise make sure no terrain is rendered e.g. by disabling TerraSync, and starting at a location for which you don't have terrain downloaded, or just temporarily rename your TerraSync folder.
    • Aircraft: The C172P is confirmed to start without crashing right now. To do a mid-air start from the FlightGear Qt launcher you need to specify a location over the ocean by typing in lat/lon coordinates and then specify an altitude. Qt-Launcher > Location tab > Location search bar > enter lat/lon coordinates over ocean separated by a comma e.g. 30,-40 > press enter. Move the altitude toggle to enable it, and enter an altitude in ft or m. CTRL+u works to gain altitude. You can also try the video assistant which can be selected from the launcher. Try a clear sky as cloud rendering is broken right now. Right now the in-sim menus may not render.
    • You can start on a Carrier like the Harry S Truman, provided it's not placed near terrain.
    • It may be that only NVIDIA cards are supported currently until the sim transitions properly to OpenGL 3+.

See Fernando's post about the first merge on the mailing list : https://sourceforge.net/p/flightgear/mailman/message/37325148/

Naming clarification

Although the pipeline is called the "HDR pipeline", it's really a suite of rendering improvements in addition to a different HDR implementation. It's sort of the way ALS framework contains a huge amount of features besides Advanced Light Scattering (including creating forest or terrain detail), and the ALS name was chosen to distinguish it from the 'Default' and 'Rembrandt' renderers which are now obsolete in the next branch. Similarly HDR pipeline name is just something to distinguish it from the suite of features in the current ALS rendering pipeline, which is currently planned to be called the "Classic" renderering pipeline in an upcoming UI revamp (no single name can cover all the different features of a rendering pipeline - so in the planned GUI, actual rendering features will be listed in the UI and there will be toggles to enable features as applicable).

OpenGL requirements

The new rendering pipeline(s) will assume a higher version of OpenGL in future (needed for World scenery 3.0 among other things), which is one of the many big projects that are being worked on. Currently the prototype HDR pipeline on the next branch needs a GPU and drivers that support OpenGL version 3.0 or later.

Compositor and rendering pipelines

The Compositor is a framework to define rendering pipelines - so far the work has been to port the ALS rendering pipeline to the new framework, and add the distinguishing features of the old unmaintained Rembrandt renderer like shadows and environmental light definitions without being slow. The idea is to port existing features from both renderers to ensure everything works - the next preview release or LTS will transition to the Compositor. The next LTS will have the existing features as the Classic rendering pipeline alongside any new pipeline(s) that are finished, so there's no need to worry about performance hits from features in the new HDR pipeline making very old hardware too slow to run FG.

New HDR pipeline

The new HDR pipeline work builds on top of existing ALS pipeline. It investigates changing the physical model of aircraft surfaces (to something involving a version of PBR), adding lighting of surfaces from light bouncing off surrounding surfaces including real-time reflections, and implementing a new way of doing HDR algorithm using the new physically based surface model. Some tunable artistic glow (known as bloom) is also supported. The new pipeline is built on top of existing work, and will use the fast shadows and lights added to the ALS port. Fernando hasn't found a way to re-use occlusion data (data about what is visible in the view and what isn't, so invisible geometry can be skipped to speed up rendering) between passes in current Open Scene Graph (OSG), so he is using a deferred rendering approach in the prototype to overcome this OSG limitation - it means that anti-aliasing is restricted to post-processing that looks at the rendered image and tries to detect edges and blur them to remove jagged lines.

The current plan is to support GlTF This is a link to a Wikipedia article (Graphics Language Transmission Format) as an alternative for 3d models in future - it supports the new surface model natively. This format also supports binary data (GLB file extension), and these will be smaller than AC files.

As Fernando said, this is all very WiP and experimental - it's an investigation of various approaches like a lot of development. Plans can change. There is no timeline, and progress can vary based on availability of volunteers.

WiP screenshots (some are be from a very early version, and screenshots may be updated by the time you read this) - keep in mind this is very proof of concept using existing art not especially designed to take advantage of the new surface models, and it only works on aircraft carriers / over the sea. It's not an end-user demo of how a craft designed for these pipeline features will look when done, and shows features that people familiar with rendering and what's been tested can pick up on.

Virtual reality (VR) support project

James Hogan, a brand new contributor (not to be confused with James Turner or James Hester), has been working on a very experimental/WiP project adding support for Virtual Reality (VR) headsets This is a link to a Wikipedia article to FlightGear. The project needs the Compositor and next branch of FlightGear (nightly builds), It will not work on 2020.3.x LTS. The work is still very experimental and has not been merged into the FlightGear next branch as of late July.

The reason that Virtual Reality support has not been worked on to date by core developers interested in relevant areas is that they do not have access to a VR headset hardware - various developers have indicated in the past they are willing to provide support to people interested in adding VR support, or even willing to directly assist implementation if they had access through sponsoring/donating VR hardware (from VR headset companies, from companies of required supporting products for VR like high-end GPUs, or others) - e.g. see an old forum thread on the topic. This general lack of VR hardware among interested core developers (including the Compositor developer), means it's important for interested contributors who use VR to get involved with development, and for people with VR to contribute with bug reports and testing. This includes testing on various VR headsets - James Hogan is developing on a HTC Vive which is 1 among a number of VR headsets This is a link to a Wikipedia article.

James Hogan is using the OpenXR API This is a link to a Wikipedia article (https://www.khronos.org/openxr/) that supports multiple headsets and manufacturers. An API is a standard way for applications to 'talk' to the headsets via their drivers - similar to the way OpenGL allows applications to talk to the different GPU hardware cia their drivers. JamesH is working on a library called osgXR to add OpenXR support directly to Open Scene Graph (OSG) for the purposes of enabling VR support for FlightGear, after feedback from the OSG mailing list. This approach will mean the OSG project will help support and maintain osgXR in future, and non-FlightGear projects using OSG with VR will help extend and maintain osgXR in future. Similarly, Khronos and other non-OSG/non-FLightGear projects will also help maintain the OpenXR standard across new devices in future. This is an example of the strength of the Open Source approach. If you are involved in other projects that use OSG that might be interested in OSG VR support for their applications, you can give them a heads up regarding osgXR adding OpenXR support.

For people compiling from FlightGear from source, the experimental VR branch is available here : https://github.com/amalon/flightgear

As always with volunteer projects, progress depends on the availability of volunteers including testing, and plans can change in various ways - so there is no timeline.

FlightGear development is coordinated via the "fg-devel" mailing-list and people who want to get involved with any aspect of the VR project should get in touch via the mailing lists.

See the archived thread on the sourceforge mailing-list archive for more information.

Composite-Viewer is enabled on next

The CompositeViewer has reached a stable stage and Julian has enabled it by default on the next branch [1] (i.e. available on nightly builds). Feedback and bug reports can be sent to the "fg-devel" mailing-list or the issue tracker.

Render scaling factor mod for Compositor (for power-users only)

On the next branch (i.e. nightly builds) the ALS renderer, Fernando has released an example of a modification for a render quality scaling setting. This mod is an experiment/example but can be immediately useful for people with 4k/5k monitors coupled with GPUs that are suited for 1080p - this is a very common situation with laptops. People with 2k screens may also find this useful, as well as people with older/mobile GPUs .

The normal advice for 4k/5k monitors with 1080p/2k GPUs is to run at a lower resolution like 1080p, but contributors/power users may often run FlightGear windowed for testing/development or to view things like maps on other windows. GPUs that are NVIDIA 10 series or older , and the AMD equivalent don't support lower resolution without a little bit of blur that is optimised for viewing nature scenes in movies - even when the resolution is shrunk by half so each new pixel fits neatly into a 2x2 grid and there is no need for blurring. NVIDIA 11 series and newer GPUs support integer scaling and can handle half resolution without blurring - they support integer scaling.

See the post on the mailing list for info. Note: this is an experimental / temporary mod which will eventually expire e.g. when there's a tweak/fix to the ALS pipeline.

  • Create a XML file in a text editor (like notepad on windows) in the path YourFlightGearFolder/data/Compositor/Classic/classic-upscaling.xmland copy the text from here https://pastebin.com/GwwfmD4h. This contains a copy of the existing ALS pipeline in classic.xml, with a render scaling option added.
  • The Command line option to use the new pipeline can be set from the FlightGear Qt launcher > Settings tab > Advanced Settings > text entry box > enter the following lines:
    • --compositor=Compositor/Classic/classic-upscalingto use the classic-upscaling pipeline xml file. Remove this line to use the normal rendering, or set it to another pipeline such as"classic"to instead of "classic-upscaling"
    • --prop:/sim/rendering/scaling-factor=YourNumberHerewhere YourNumberHere is a value between 0.0 and 1.0 to shrink the rendered image. Try 0.5 for a 4k screen. Try values between e.g. 0.75 and 1.0 to tweak settings on older/mobile GPUs.
  • Remember that eventually the classic pipeline will be updated and to switch back sometime in the future, or use a newer mod. Remember to return things to normal (or turn render scaling to 1,0 when submitting screenshots. There are some issues such as the splash screen not being resized.

This setting reduces the number of pixels that is rendered each frame, by rendering a smaller sized image. Normally the rendered image is the same size as the screen e.g. 1920 x 1080 for a 1080p monitor. This smaller sized rendered image is then stretched to fit the screen. There is a new control for a scaling factor that determines how much the rendered image is shrunk by, For example if a monitor has a resolution of 4096 by 2160 (4k) a scaling factor of 0.5 will result in 4096*0.5 x 2160*0.5 = 1920 x 1080. That is, each dimension is multiplied by the scaling factor.

Rendering fewer pixels means proportionally less fragments - fragments are colour calculations which can contribute towards the colour of each pixel. Fewer fragments will help in cases on systems that are bottlenecked by the fragment shader. The fragment shader is where a massive amount of lighting and procedural detail math is done each frame for every fragment.

If your performance bottleneck is on the CPU reducing the size of the rendered image will not help! In fact, if you are CPU bound you are free to find settings to turn up to give the GPU something to do. A quick way to check if your FPS is bottlenecked by the fragment shader performance is to go to windowed mode, and change the widnow size slightly - if the FPS also changes it means that the bottleneck is in the fragment processing. See the discussion in the hardware recommendations page for info and tips on tuning for the bottlenecks on your system (depends on things like the craft you fly and over what terrain as well as graphics settings). Reducing anti-aliasing also reduces the fragment shader load - see the page on Anti-aliasing for more info/tips.

Related Software tools and projects

FGCom-mumble

FGCom-Mumble aims to provide a mumble based FGCom implementation. This will simulate radio communications in a seamless frequency spectrum. The project aims to be easy to use: Pilots just install the plugin, open mumble, join a specially named channel on a mumble server and start using their radio stack in Flightgear.

The development is discussed in the FGCom-mumble topic on the forum This is a link to the FlightGear forum.. Releases can be downloaded from GitHub. The project also has a flightgear wikipage: FGCom-mumble

Release 0.14.2 fixes the broken updater issue - again

The release 0.14.2 fixes a bug with the windows built. When installing trough the mumble plugin installer (or updater), the old DLL was still locked and could not be deleted.

Also, interrelated to the bug hunt, two bugs in mumble itself were found and fixed, also contributing to the behaviour. The fixes were ported back to the upcoming Mumble 1.14 release, which went into feature freeze lately. For testing, you need a download from the current Mumble nightlies (azure pipeline). Snapshot 6 from Mumble's downloads page is not enough (plugin is compatible, but need to be installed manually by unzipping the .mumble_plugin and copying the appropriate plugin library to mumbles plugin folder).

Please read the FGCom-mumble release notes for details and install instructions.

In the hangar

Updated aircraft

A320-family

Work continues on the 3D branch of the A320-family, specifically regarding the new FDM, FADEC, and 3D model. The ability to remap the detents has been added, but no UI is available yet.

MD-11

The MD-11 received massive upgrades and the beginnings of its MCDU/FMS system. Radios and some other factors can now be set in the MCDU, and much work has been done on the backend for future MCDU features. In addition, many new indications have been added to the display units, as well as an improved autoland system.

MD-80

The MD-80's systems have been further detailed, and many of the gauges now tie into the electrical system. The accuracy in behavior of the autoflight has been improved, and many of the analog instruments have been detailed.


Scenery corner

Suggested flights

Beni published a new scenic suggested flight: Crossing the alps. It takes you from Germany via Austria to Bolzano, features nice valley navigation, and visits the famous castle of Neuschwanstein as well as germanys highest peak, Mt. Zugspitze.

Help wanted

Post LTS work

After the 2020.2 release, some work lies ahead to improve the LTS and to help us pave the way for migrating to the OpenGL Core profile - any help would be greatly appreciated.

This may for example include:

Please get in touch via the developers mailing list to learn more. See Post FlightGear 2020.2 LTS changes and 2022.X Release Plan for more details.

World Scenery 3.0

The FlightGear project is in the process of exploring how Virtual Planet Builder can be adopted. For details, see: World Scenery 3.0 roadmap

Aerial (drone) photos for Terrain textures

Wanted: good top-down aerial photos to create textures from to use with the procedural Regional Texturing system. Drones This is a link to a Wikipedia article with cameras are ideal. People with access to drones are in a good position to take high-quality photographs.

A particular need as of 2020 is photos of agriculture (farm lands) from different parts of the world.

Good GPLv2 compatible photos suitable for textures are hard to find, and an easy way is for people to take photos of their region. Flightgear's procedural systems can do a lot with less art content, so photo contributions can strongly improve visuals.

See: How to: take photos of terrain for textures. For examples of final textures: see /data/Textures/Terrain. e.g. UK countryside.

You can get in touch via the Scenery forum or the flightgear-devel mailing list

Photos of trees for textures

Wanted: good quality photos of different trees and vegetation from various parts of the world. Flightgear's vegetation system can handle multiple layers of trees and bushes.

Strong shadows should be avoided. Each tree should be against a background of a different colour: sky (preferably) , clouds , or buildings. This allows the tree to be separated from the background in a photo-editor like GIMP.

See: How to: take photos of vegetation. For examples of final textures: see /data/Textures/Trees. e.g. Coniferous.

You can get in touch via the Scenery forum or the flightgear-devel mailing list.

Submissions of labels for craft

Wanted: Submissions of labels (tags) giving a rough description of aircraft - Metadata tags. A quick read of a craft's Wikipedia page will normally be enough to set labels. This info will be searchable from the launcher GUI. For example, filtering craft by propulsion like single-propeller or 4-engine jet craft, or by a manufacturer like Airbus or Grumman, or by speed like supersonic craft, or craft by era like WW2. A list of tags is here - more can be added if needed. To add tags to craft yourself, the tags are stored in the set-xml file.

A list of FGAddon craft needing tags is here. See this forum thread to submit tags. The flightgear-devel mailing list or the craft's maintainer can also be contacted.

Windows Package Maintainer

The core team needs help from Windows users able to maintain a good working Windows build. This process already exists to support our Nightly and Release builds, but we are seeking additional help to keep it in good working order. The ability to compile FG from source and some Windows batch scripting is a required skill. If you are willing and able to take up this role, please reach out to James Turner (mailing list), or get in touch via the forum [1]

AI

The AI team makes FlightGear more realistic, colorful and lively every month. You can support the development of Interactive Traffic and contribute at the FlightGear AI subforum This is a link to the FlightGear forum..


Community news

FlightGear on Facebook

Since early December 2010, FlightGear has an official Facebook page. If you have a Facebook account please feel free to join the page.

FlightGear on Instagram

In January 2018 the @flightgear_sim Instagram account was brought back to life. If you've got nice screenshots to be featured, feel free to contact the maintainer This is a link to the FlightGear forum..

FlightGear on FlightSim.com

FlightGear has also a sub-forum on flightsim.com - just like the commercial flight sims. It is an opportunity to showcase what FG can do, get people curious and answer any questions they may have with regard to the software or the project.

Multiplayer events

Contributing

Translators needed

En.gif The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at Help:Translate.
Fr.gif Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire Help:Traduire.
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 mit dem 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 wiki de FlightGear 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.
Cat.gif La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a Help:Traduir.
Pt.gif A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em Help:Traduzir.
Zh.gif FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 Help:Translate.

FlightGear logos

If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit FlightGear logos for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

Screenshots

The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings (anti-aliasing, texture sharpening, etc.). More info at Howto:Make nice screenshots.

Screenshot of the Month

If you want to participate in the screenshot contest, you can submit your candidate to the this subforum This is a link to the FlightGear forum.. Be sure to see the first post for participation rules. For purposes of convenience and organization, at the end of the month or after 20 entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there.

Thanks for reading FlightGear Newsletter July 2021!

References