Category: Info

Posted on

FGMEMBERS Statement

FlightGear FGMEMBERS Statement (v2.2):

Preface

What you see today as FlightGear is the result of 20 years of collaborative development effort by hundreds of talented people all working together to provide a freely available GPL flight simulator that anyone can contribute to.  The core FlightGear team feel that it is important to make a clear statement of their position concerning the FGMEMBERS organization, explaining why it is important to continue working in a way that will ensure that FlightGear continues to prosper for the next 20 years as well as to clear up any confusion and FUD that has been disseminated by members of the FGMEMBERS organization.

The FGMEMBERS infrastructure offers little benefit to contributors.  From experience, the core team knows that the lack of appropriate controls on contributions may, after a long period of time, lead to a divergence that may result in contributions being lost.  This includes the divergence of models as well as scenery enhancements that are not contributed to the scene models database.

TOC

Background

During five years of in-depth discussions on the development mailing list (where decisions are made[1]) a consensus of opinion was reached which defined the future direction for the core assets of the FlightGear project.  This required the removal of the aircraft models from the old fgdata repository[2], leaving the core assets and the default aircraft.  Unfortunately this necessary change resulted in a fundamental disagreement with a couple of FlightGear users who demanded that the decision making process be restarted[3].  Clearly with five years of discussions already undertaken it was not a viable path forwards to restart discussing the splitting of the assets and which revision control systems were most suited for the FlightGear project.

One of the objectives of the project is longevity and ensuring that the path taken is, with the best available knowledge, as future proof as possible, allowing authors to make their contributions with the minimum amount of disruption whilst maintaining quality and licencing standards.

As a result of the disagreement, one contributor started what is generally considered to be a hostile fork of the core asset repositories into what is known as FGMEMBERS.  This was expanded to include all the other models and assets from all non-official repositories from all corners of the internet, to form a single source for all contributed assets (core assets, aircraft, scenery, 3rd party hangars, etc.).  At a first glance this appears to be a good idea, as there is a single place where everything can be found.  However the disparate nature of contributions means that FGMEMBERS is a divergence of most of the original content.  Whilst certain repositories may be up to date within FGMEMBERS, it is not necessarily true that this will remain the case.  Taken together, this negates the key benefit of a single location for all content.  The other key point is that any changes contributed to the FGMEMBERS infrastructure may never make it into the original repositories.  This affects the availability and quality of models for the wider community of the FlightGear project, such as the aircraft that are available for download on the FlightGear website and launcher[4].  Any contributor spending considerable time making changes to aircraft or scenery may be unaware that their changes may be lost in the future, especially in the case of scenery as the FGMEMBERS scenery workflow is to modify what is considered to be an automatically generated set of temporary files from base data sources.

Since its inception, the FGMEMBERS organization has continually made very emotive statements and accusations regarding the core development team and the way the FlightGear project is run.  The core FlightGear team consider those baseless and has refuted them.

Official FlightGear Position

The core FlightGear team considers the FGMEMBERS data asset forks to be hostile and the infrastructure bad for the FlightGear project for a number of reasons:

  1. Historically, forks of Open Source projects are unsustainable because developers choose one or the other.  Over time, the vast majority of forks die.  In a small minority of cases they become prevalent and the original dies.  In either case, a huge amount of effort is wasted on the fork that eventually loses.  We feel that effort is better spent on improving the simulator.
  2. It is inevitable that the fork will diverge, as changes are made to one repository but not the other.  Attempting to keep the repositories in sync requires huge amounts of effort and is likely to fail due to incompatible changes being made to the same file by multiple developers.
  3. The FGAddon repository is actively supported by the core development team, with processes in place to ensure the long term health of the repository, and compatibility with any changes to the FlightGear core.  The core FlightGear team have been working on this project for 20 years and has a long track record of ensure the long-term health of the aircraft.
  4. We are concerned that FGMEMBERS deliberately does not have controls over commit access to the repository and as a result license violations have occurred.
  5. Different versions of the same aircraft existing in both FGAddon and FGMEMBERS causes confusion and adds to the burden of support from volunteers who may not have the same version.  This makes tracking down bugs much more difficult.
  6. We object most strongly to the way that FGMEMBERS proponents have evangelized against FGAddon and TerraSync and the accusations that they have made against the core team.  We consider this unacceptable.
  7. The constant and active recruitment of potential developers away from the core infrastructure has caused and is causing a lot of long term harm to the FlightGear project.

The FlightGear development team encourages users and developers to use the official repositories and infrastructure (FGData, FGAddon, TerraSync) and continues to support 3rd party hangars.

FAQ

Why is this important?

Question: What is the point of this document?

Answer:
It is important that we all work together to ensure the continued growth and development of FlightGear.  The core team does not want to see valuable contributions being lost because these contributions were made to something outside of the FlightGear project.  What you see today exists due to the time and effort of developers.  Unfortunately in recent years FGMEMBERS has proved to be a considerable waste of developer time that could have better been spent on improving things rather than dealing with and refuting allegations, answering questions from confused users and declining attempts to reopen discussions that have no relevance for the already decided future path of the project.

Why is FGMEMBERS considered as a legal liability?

Question: Why is the core design of the FGMEMBERS system considered as a legal liability?

Answer:
The official FlightGear infrastructure operates on a basis of trust and experience, in which a committer must be prepared to accept the trust of everyone else and show an understanding of copyright issues.  This is in stark contrast with the FGMEMBERS principle that everyone and anyone can obtain commit access for improving the system.  The FlightGear way has been proven to work over many years as it results in collaborators who can be trusted not to cause damage to the FlightGear project or to cause legal jeopardy by a lack of understanding.  Without this there is an elevated risk that an inexperienced content developer may deliberately or inadvertently obtain material (3D artwork, photographs, sound bites, etc.) found somewhere on the web and include it within their own GPLv2+ licensed content without due consideration of the licencing implications.  The official FlightGear infrastructure has the *-commitlogs mailing lists[5], allowing individual commits to be reviewed; whereas FGMEMBERS has no such system and as such can be considered as a more anarchic system where illegal content will inevitably be added under the radar.  This is unacceptable in a large open source project such as FlightGear as it puts the contributor and the project at legal risk.

Why use the “hostile fork” terminology?

Question: Why is the FGMEMBERS infrastructure referred to as a “hostile fork”?

Answer:
This is standard software development terminology for the FGMEMBERS situation.  Here is one definition:

  • “A HostileFork happens when someone isn’t happy about the way a collaborative effort is being run, so they start their own competing project.  They take the work of the group in a different direction…rather than working on achieving a consensus.  Often they lobby for developers to assist their effort, rather than the original project from which they are derived.”[6]

And another:

  • “A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project.  It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split.Compare to forking to solve a very specific or specialized problem that doesn’t make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case.  In such a case, it’s common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don’t diverge too much.”[7]

The core group consider the current situation to be an exact match to the “hostile fork” definition.

Why not consider the FGMEMBERS proposal?

Question: Why is the design and operation of the FGMEMBERS system considered as unsuitable for use as the official FlightGear infrastructure?

Answer:
Firstly, the proposal was made years after a consensus had been made and a decision reached.[8].

Secondly, the design is considered to be incompatible with how the FlightGear community operates.  The FlightGear community is bound together by mutual respect and basic courtesy; there may be disagreements but it is expected that disagreements be handled in a respectful way without personal attacks.  The wishes of all contributors wherever possible are respected.  There are some models in FGMEMBERS in which the original authors have directly stated a wish to not have their aircraft be distributed as part of this system.  Instead of respecting that wish, these aircraft remain bundled as part of the FGMEMBERS.

Another concern, and in many ways for the community a large concern, is the encouragement to make contributions outside of the official or original author’s distribution channels.  This is a key aspect of the FGMEMBERS system used to advertise to new users that the FGMEMBERS system is superior to the original upstream sources.  Hence the FGMEMBERS system strongly competes against those wishing to be independent of the system, using an “improved” version of their own work.  To avoid this, a number of content creators have used specific licensing to legally block FGMEMBERS redistribution.  But in the process these authors have lost part of their freedom that the GPL licence offers — the same freedom that has allowed FlightGear to become what it is today.  This is causing long-term damage to the FlightGear project and the GPL ecosystem built around it.

We consider that redistribution for solely aggregation and deliberate divergence of GPL-licensed content is permissible legally but morally questionable.  Particularly when it is against the wishes of the original author, and implicitly competing against that author for the aim of selling the FGMEMBERS system.  This is considered unacceptable as a model of operation for the FlightGear project.

Why not peacefully coexist?

Question: Why is FGMEMBERS different from all of the other 3rd party infrastructure and peaceful coexistance not possible?

Answer:
The aim of the FGMEMBERS organization is to attract as many FlightGear users and content developers as possible to become the de-facto FlightGear content infrastructure.  To achieve this, FGMEMBERS deliberately aims to minimise or completely cut off contributions upstream to the core FlightGear infrastructure for the sole purpose of rendering it irrelevant.  However as the same design is used for both the core infrastructure and the 3rd party infrastructure, this affects the whole of the FlightGear community equally.  FGMEMBERS hoards absolute all of the content from all content creators, but then applies fixes and improvements that are not submitted back upstream to the original authors, using the excuse that upstream should find and backport the fixes themselves.  This is specifically to use as a selling point against the official and 3rd party FlightGear content infrastructure.  Because of this positioning, the FGMEMBERS organization is unlike any other 3rd party infrastructure — it is not complementary to the FlightGear ecosystem but is rather competitive to it.

Why is syncing not possible?

Question: FGMEMBERS intends to sync all changes from FGAddon, why can’t FGAddon simply merge all the changes from FGMEMBERS so the repositories remain identical?

Answer:
There are three reasons for this.  Firstly, over time the repositories will diverge in a way that is impossible to reconcile (e.g. two different developers with different end goals modify the same aircraft model at the same time).  Secondly, such a merge would require a large, continuous amount of effort just to maintain a position that would exist without FGMEMBERS.  Thirdly, we have concerns over the attitude of FGMEMBERS to licensing and accepting almost all content, and are not prepared to legally risk the GPL “health” of FGAddon.

For many years it has always been that FGAddon and its predecessor infrastructure is the definitive place for the FlightGear models.  As part the FlightGear contribution workflow, the responsibility is on the content author to contribute to FGAddon when their work is ready for release.  Once the work is present in FGAddon, the author is then expected to maintain the aircraft in FGAddon.  This is how development has always been performed and it works well and everyone understands it.
To change this now so that it becomes the responsibility of someone else, other than the contributor making the changes is clearly an unworkable solution.  However the published procedure for adding or modifying FGAddon does not preclude contributions from anyone who is prepared to follow the submission rules and content guidelines.  So FGMEMBERS could, if they so wished, follow these procedures to ensure that FGAddon remains the core asset that is definitive and up-to-date.

Why not switch the core infrastructure to FGMEMBERS?

Question: Why can you not work with the FGMEMBERS team to create a single repository?

Answer:
Primarily this is not possible as it would require reopening a discussion that was ongoing for 5 years — and this approach is merely a different way of doing things that does not provide any real benefits to the long term goals of the project.

Why Subversion?

Question: Why do you use Subversion instead of my preferred version control system?

Answer:
Subversion was agreed upon during the discussions on the development mailing list as it provided most of the required facilities in a way that worked for the wider community.

Why have gatekeepers?

Question: Why does FGAddon have gatekeepers?

Answer:
The official policy[9] is designed to allow for easy access to FGAddon for contributors whilst maintaining quality and legal standards.  As the official FlightGear repository has obligations and legal liabilities, the gatekeepers are there to ensure these quality guidelines are met.  The gatekeepers are friendly and helpful — their role is to promote the development of aircraft while respecting the community rules and to guide new contributors; who themselves may gain, or already have, the experience to be a gatekeeper.

How do I contribute?

Question: How can I send improvements to FGAddon for inclusion into the official repository of aircraft?

Answer:
As detailed on the FGAddon wiki article, there are a number of steps.  Firstly the original aircraft authors should be contacted.  If this is not possible, then send an email stating your intentions to the FlightGear development mailing list or post a message on the forum.

Why should I contribute upstream?

Question: Why would I want to contribute to FGAddon when I could just hack away and publish my changes in a forked repository?

Answer:
Contribution to FGAddon guarantees the widest distribution of your work by including your work into the FlightGear project (your improvements will be available on the official download page and inside the launcher).  You are also contributing back and collaborating with the FlightGear project.  This is a proven method to ensure continued and long term availability of your improvements for years to come.  If an original aircraft developer is still active it is normally considered respectful to work with that author as it will often benefit everyone involved, rather than taking their work and competing against them.  Otherwise this will result in two versions that have different improvements, when the goal should be to all work together to provide the best models that collaboration can build.

Can I obtain commit access?

Question: Is it possible for me to obtain commit access to the FGAddon repository?

Answer:
You are encouraged to apply for commit privileges as soon as you feel that you meet the criteria and are ready to take on the responsibility[10].  If in doubt, send an email to the FlightGear development mailing list.

Is FGMEMBERS a 3rd party hangar?

Question: Are the FGMEMBERS aircraft repositories considered as a 3rd party hangar?

Answer: No.
As FGMEMBERS has aggregated all of the FlightGear assets, including FGData, FGAddon, TerraScenery, 3rd party hangars, and all other sources, the aircraft component of this system is not considered as a 3rd party hangar.  As it is a hostile fork, unlike the 3rd party hangars, it competes directly against the official FlightGear data assets and infrastructure as well as the 3rd party hangars.  It also competes for developer resources against the FlightGear project and 3rd party hangars.

Conclusion

We believe that the best path forwards for FlightGear is for the community to work together.  We recognise the importance of contributors and collaboration and positively encourage everyone to work together with the common goal of improving FlightGear in a positive way, and to be respectful, honest, trustworthy and fair.  Let’s get the word out and make sure that FGMEMBERS has to communicate with a well informed audience.

 

Posted on

A preview of features for Flightgear 3.6

Flightgear is constantly under development and as the feature freeze for the next 3.6 release approaches, it is becoming increasingly clear what the next version will have to offer to users:

(to avoid misunderstandings – this is a selection of features currently under development, not a release note, i.e. there is no guarantee that all items will appear in 3.6, nor is are the features of 3.6 limited to what is listed here)

A complete makeover for the default aircraft

The C-172p has always been Flightgear’s default plane, as it is easy to fly and great to learn the basics of aviation. Thanks to a joint effort of several gifted developers, it just got a lot better. The revised version offers improved flight dynamics with the ability to bring the plane into spins. It makes good use of the latest state of the art of Flightgear’s rendering frameworks, including hires textures, the new internal shadow effect for ALS, environment dependent fogging of the windshield and of course support for the Rembrandt rendering engine.

And it comes with a damage model, creating a very visual impression of what happens if you land too hard:

A new user interface / instructor station

Using Flightgear’s inbuilt web-server, Phi is a new way to access Flightgear from an external device. You can run a web browser on your pad, connect to a running FG instance on your PC and access everything you need from there. This makes for a great training setup in which the instructor can select challenging conditions for the student, monitor the flight or cause failures which need to be responded to. Phi supports pre-flight checklists, environment settings, a moving map widget and many features more.

‘Houston, the Atlantis has reached orbit.’

Launching vertically like a rocket, capable of limited maneuvering in orbit and entering the atmosphere again to land like a plane, the Space Shuttle is a truly unique flying experience. Based on a large body of public domain wind tunnel data by NASA, Flightgear now offers the possibility to take the Shuttle into low orbit and back in a highly realistic simulation.

Experience the strength of the aerodynamical forces during launch as thrust vectoring keeps the Shuttle on its ascent path, learn about the inherent yaw instability of the Shuttle during the hypersonic entry phase and the crucial role of the RCS jets and the body flap, explore how elevon deflection changes the airstream at the aft fuselage and alters roll and yaw stability, or simply start in orbit, enjoy the view or do a spacewalk.

The simulation includes all mission phases with many different digital autopilot settings to control thrust vectoring, RCS jets or airfoils, checks on aerodynamical and structural limits as well as damage and failure simulation in case of limit violations – basically the Shuttle can be flown by the Crew Operations Manual. A 3d cockit is already in place, and work is underway to provide the original avionics.

Rain on the windshield

The Atmospheric Light Scattering rendering framework is rolling out a new suite of effects to render the cockpit interior in more detail. These include a glass shader which renders interior reflection, damage and dirt, glare, raindrop splashes, frost and temperature-dependent fogging and an interior effect capable of drawing shadows, light filtering through colored glass or caustics as well as panel backlight illumination. Enjoy the enhanced immersion into the simulation these features provide!

Regional textures for Latin America

Thanks to local users, the whole of Latin America is receiving more realistic local textures. Look forward to the typical red roofs or urban terrain, to seeing dramatic changes in the water color where the dark Rio Negro meets the muddy Rio Solimoes close to Manaus and to many other nice touches in the area. If you haven’t done it yet, schedule a flight in South America after the next release, there’s lots to explore!

New and improved aircraft

The Citation II provides a new cockpit, making use of plenty of the new effects. Enjoy Flightgear in this nice business jet!

The new F-15 comes with a detailed JSBSim flight dynamics model with lots of wind tunnel data worked in as well as a detailed 3d cockpit with tons of functionality.

And many improvements more

* work on an integrated launcher, specifically making life easier on newer Mac OS distributions
* the aircraft center, a tool to download and manage aircraft in-sim
* expanded functionality of the Canvas 2d rendering framework
* …

Stay tuned as we fly towards our next release!

Posted on

A preview of features for Flightgear 3.4

Flightgear is constantly under development and as the feature freeze for the next 3.2 release approaches, it is becoming increasingly clear what the next version will have to offer to users:

(to avoid misunderstandings – this is a selection of features currently under development and not a release note, i.e. there is no guarantee that all items will appear in 3.4, nor are the features of 3.4 limited to what is listed here)

Precipitation

Added realism for precipitation:

The precipitation system has been partially upgraded. The speed of falling raindrops now follows a physical scaling with droplet size, and the system renders now hail in addition to rain and snow. The correct dependence of lighting with illumination of the scene has been added. In Advanced Weather, droplet size and rain intensity are now set independently, allowing to realistically render fine spray as well as splattering rain in thunderstorms. A dynamical splash-pattern of raindrops added to the Atmospheric Light Scattering (ALS) runway effect completes the visual impression.

Advanced Weather clouds

Near photo-realistic 3d clouds:

The cloud rendering system has received an upgrade, allowing to let the edges of cloud patches gradually fade out. This makes several types of cloud formations appear even more realistic.

Haze

Have you ever wondered why the terrain appears bluish in the distance?

The Atmospheric Light Scattering (ALS) rendering framework has received a significant upgrade rendering the effects of Rayleigh scattering of light with air molecules and fine dust. This includes the in-scattering of light, resulting in the blue appearance of distant objects, as well as an out-scattering effect which makes colors seen through dry haze shifted towards the red. Combined with the already existing model for rendering hazes, this leads to truly impressive visuals.

Instrumentation

Improved instruments:

A new flexible CDU framework allows aircraft developers to set up extensive CDU pages with relatively little effort. The framework supports both 3D and 2D instruments, multipages, down selecting settings to the scratchpad and various input formats (e.g. FL115 or 11500). It comes with a 2D panel popup screen so you won’t have to pan around the cockpit all the time. The CDU is expected to be introduced on the Boeing 747-400, but the framework has been designed to be flexible and fit other airliners.

Aircraft

Enjoy the latest additions:

The Extra 500 introduces a luxury aircraft one of the most advanced glass cockpits to be simulated by Flightgear. The F-14b has received a significant upgrade with an added JSBSim flight dynamics model. There is also progress on a new version of the X-15 which might make it into the release, as well as the F-20.

Atmospheric Light Scattering

Enjoy yet more interesting visuals:

ALS continues to receive a host of additions, allowing for some stunning visuals:

* tree shadows, rendered using a very performance-friendly technique
* landing and search lights for better night flight experience
* improved implementation of Fresnel scattering on water surfaces, leading to more realistic water appearance
* a procedural rock effect, capable of rendering a large variety of different rock textures and colors across the world
…

And many improvements more!

Much work is done under the hood which is not all visible:

* improvements to the rendering framework, leading to better performance
* more applications utilizing the FG-internal webserver
* a canvas-based alternative GUI and aircraft center, allowing to manage installed aircraft inside FG
…

Stay tuned as we fly towards our next release!

Posted on

Feedback on dds textures required

Should Flightgear switch to dds texture format?

What is this about?

The FG development team is considering to switch the format for terrain textures from png to dds. This would offer a number of significant advantages:

– dds is a compressed format, hence the download size of the FG base package may be decreased
– compressed dds can be directly used by many graphics cards, reducing also GPU memory consumption
– dds stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
– the resolution levels (‘mipmaps’) can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use dds for these reasons.

However, the dds compression algorithm is patented, which means that it is not readily available for OpenSource graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process dds, for older graphics cards there are non-patented workarounds available which decompress the dds on the software level). The development team is concerned about making the Flightgear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

If there are no problems reported, FG will change defaults to txtures in dds format with the 3.4 release, and then phase out the use of png textures.

What would we need?

Flightgear already provides the simple option to test a dds texture set. If you are running on Linux and especially if you use an OpenSource graphics driver, please take 5 minutes to help during your next FG session:

– Open the dialog under View -> Rendering

– Under ‘Terrain texture scheme’, change the default ‘Region-specific’ to ‘Global alternative (DDS format)’ (see red circle)

– Press ‘Okay’ – FG will reload the terrain

– Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you’re fine. If you see monochromatic colors or other rendering artifacts, your system may have problems with dds.

– Change back to the texture scheme you like best

– Go to the wiki page and report your experiences, ideally including the graphics card you have and the driver you’re using.

Thanks for your time!

Some context for those interested

The visuals you get to see of the terrain in Flightgear depend on texture scheme and rendering scheme being used.

Simply put, the texture scheme selects a set of texture sheets which are mapped to the various landclasses in the terrain, such that a forest is rendered as forest rather than as grass. The old ‘Global’ texture scheme uses one such set everywhere in the world, the ‘Global alternative’ scheme uses a different set, but the format the textures are stored in is dds rather than png, and the ‘Regional’ scheme selects different textures based on what part of the world you are in. So the texture scheme selection governs things like the basic appearance of the terrain, the format the textures are internally stored in and the definitions where in the world certain textures should be used.

However, modern graphics cards allow to modify textures dynamically, or even create them on the fly by Procedural Texturing using shader effects. Dependent on shader quality level, these effects may have quite a pronounced impact on the visuals. If you are not running Rembrandt, you can switch the main rendering schemes runtime using the ‘Atmospheric Light Scattering’ (ALS) checkbox in the rendering dialog (blue circle in the image above) and explore what it does. So in summary, the rendering scheme selection governs just what is done in detail with the basic texture layers selected above (but, confusingly enough, shader effects may even replace textures).

Some examples exploring the different texture and rendering schemes below:

This is the South Rim of Grand Canyon using regional texture definitions and ALS procedural texturing:

Regional texture definitions allow to adjust the rock color to what is prevalent in the US Southwest, whereas the banded rock structure is not part of the texture file but generated procedurally.

Same scene using global texture definitions and ALS:

Using global textures, the rock and grass color is no longer adapted to the region, and also the shader effect no longer replaces the steepest forest patches by rock.

Same scene using global alternative (DDS) textures and ALS:

Switching to global DDS textures does not alter the visuals significantly in this case, the main difference is the texture format and detail resolution.

Same scene using regional textures and default rendering scheme:

The default rendering scheme at high quality contains some texture replacements which are coded globally into the effect framework and do not mesh too well with the regional texture colors seen elsewhere in the scene.

Same scene using global texture scheme and default rendering scheme:

Such global texture replacements in the shader however work better with a global texture scheme.

Same scene using global alternative DDS texture scheme and default rendering scheme:

Here, the dds texture scheme leads to somewhat different colors.

FG supports this wide variety of textures and rendering schemes so that users can customize the visuals to the performance offered by their computer and select the best compromise between good framerate and compelling visuals.

We need different schemes for this, since in trying to render a scene faithfully, we need to decide questions whether an average level of dust should already be included into textures (as done in the global scheme) or added dynamically according to weather (as done in the regional scheme in procedural texturing). The first alternative is preferable on low-end hardware where procedural texturing is too slow, but the second alternative works much better on high-end systems. Similarly, having different texture schemes allows us to provide a quick fallback for users who might experience problems with a dds-based scheme.

Posted on

A preview of features for Flightgear 3.2

Flightgear is constantly under development and as the feature freeze for the next 3.2 release approaches, it is becoming increasingly clear what the next version will have to offer to users:

Missions

The Flightgear world is becoming more interesting…

[youtube]http://www.youtube.com/watch?v=dU7ikBZOjgk&feature=player_detailpage[/youtube]

A mission subsystem is being added. This allows to define tasks to be completed by a player which then receives points. Visual guidance symbols can be used to indicate the location of the next task. The mission system combines with the Milestone 4 release of the walker,and thus more complex adventures can be built in which the player has to exit an aircraft and walk to a certain location.

The walker subsystem now allows for more complex animated motion and adds NPCs, characters with whom a player can interact. Also, check out the selection of cars and motorbikes to explore the Flightgear world!

Cloud shadows

Finally some shade!

Cloud shadows are notoriously difficult to render, but for Advanced Weather in combination with the Atmospheric Light Scattering rendering framework, there is now an experimental option to add them (at least close to the aircraft) to the experience.

Earthview

See the world from high up!

Introduced to provide better visuals for the spacecraft in Flightgear, Earthview is an alternative rendering engine intended for use at high altitudes. It renders Earth as a simple, textured sphere surrounded by a cloud sphere. The textures are provided by the NASA Visible Earth project. By default, a set of 2048×2048 textures is distributed, but Earthview is intended to allow easy access for users who want to install their own hires texture set. At full resolution of about 21000×21000 pixels per texture provided by NASA, it looks simply spectacular even from just 50 km altitude – see the Vostok capsule above entering the atmosphere.

Built-in http server

Access the property tree in a novel way!

Flightgear now includes the Mongoose web server as a httpd. This allows for interesting new application, for instance merging information from Flightgear and OpenStreetMap or Mapquest, leading to a new moving map application covering the whole world is available which tracks the airplane’s position.

Cloud drawing distance

See clouds out to the horizon!

Flightgear’s weather rendering so far has not been up to the task of showing a plausible view from high altitude. But this has now changed – a new framerate-friendly impostor technique is used to render clouds out to the horizon – wherever that may be (the system has been tested for 1000 km visibility from low Earth orbit).

Rendering improvements

Visuals keep getting better!

Lots of work has been done on the small details. New tree textures at higher resolutions make the forests actually look nice. Novel noise function are used to improve the visuals of snow on steep terrain slopes, to change tree height in discrete patches mimicking patterns of forest management, or to remove tiling artifacts from large-scale agriculture. Enjoy all the details the new version will have to offer.

And many improvements more!

Much work is done under the hood which is not obviously visible:

* The YASim flight dynamics engine is finally being developed further, with some long-standing bugs and limitations being addressed for the time being
* Ground interactions have been added to the JSBSim flight dynamics engine
* a new text-to-speech message is about to replace the old pre-recorded ATIS messages, adding a lot of flexibility
* an interface for allowing add-ons that use FSUIPC (an addon framework for Microsoft Flight Simulator) to talk to FlightGear
* osgEarth integration is still on the horizon
…

Stay tuned as we fly towards our next release!

Posted on

A preview of features for Flightgear 3.0

Flightgear is constantly under development and as the feature freeze for the next 3.0 release approaches, it is becoming increasingly clear what the next version will have to offer to users:

Scenery 2.0

The next generation scenery has finally arrived!

After long years of waiting, a new version of the world-wide scenery shipped with Flightgear is now being rolled out. This scenery makes use of CORINE data in Europe, utilizes other custom enhancements elsewhere in the world, brings new and improved airport layouts and includes roads and other line data from the Open Street Map project. Especially in the CORINE covered regions, this leads to a much better visual appearance.

Novel water effects

Enjoy watching the shallows around tropical islands in fine weather!

At high quality levels of the water shader, a global water depth map is now used to change the water color in the shallow regions around islands and close to the coast. Especially in the Caribbean, this corresponds to a significant improvement in visual quality. The effect combines with the other variations in water color based on weather and base color due to algae or mud content.

The walker

Now you can get out of your airplane!

The walker project allows to leave an aircraft and explore the scenery on foot. This effectively allows adventure-game like scenarios in Flightgear such as The evil Graveyard where the walker also interacts with the scenery. Combined with the hires procedural terrain texturing options, you can start exploring the scenery from quite a different perspective and walk into your favourite virtual airport bar after a long and exhausting flight.

New airplanes

Enjoy a few new, highly detailed airplanes!

Some recent addition to the list of Flightgear aircraft, the new Boeing 707 (shown above) and the Robin DR400 Dauphin (a single propeller engine plane) impress with impressively detailed modelling of the cockpit, plenty of attention to realistic flight dynamics and especially in the case of the 707 a sometimes frustratingly realistic level of systems modelling.

More complex glass cockpits

Enjoy more realistic instruments!

The canvas 2d rendering technology allows the creation of more realistic glass cockpits with complicated instruments. Shown here is the new PFD and ND of the Boeing-747-400 as an example.

Phototexturing using osgEarth

Explore the scenery textured by aerial imagery!

An experimental implementation of generic phototextured terrain using osgEarth is now on the way and might make it into the 3.0 release. Once enabled, osgEarth renders the terrain scene by building the textured geometry at runtime from raw source imagery and elevation data. The input data can come from a variety of sources including web mapping services or local source data (e.g. geotiff) stored on disk. This feature is runtime-switchable from the default scenery rendering.

Better rendering of fog and haze

We take bad visibility seriously!

For some 3d applications, fog may just be a device to hide the terrain in the distance, but in Flightgear rendering fog and haze is taken quite seriously. The Atmospheric Light Scattering framework now comes with an improved way to render fog patches and variations in fog layer altitude, combined with even more impressive lighting of fog in low sun. You’ll never enjoy bad visibility this much!

And many improvements more…

And that’s not all:

* new regional textures for Scandinavia, Ascension Island and Corsica
* user-controlled moonlight effect for the Atmospheric Light Scattering framework
* added and improved airplanes
* more AI traffic/models
*…

Stay tuned as we fly towards the next release!


b

Posted on

A preview of novel features for the next release

Flightgear is constantly under development, and the current development version (2.11) contains already a number of interesting features beyond what 2.10 could do – so here is some (incomplete) list of what to expect from the next release:

Novel water effects

As part of the Atmospheric Light Scattering rendering scheme, some novel features have been added to the water shader:

Subtle variations in sea color and surface reflectivity are rendered at high quality, which together with slighly patchy fog improves the visual impression significantly. In addition, an experimental effect generating surf at some coastlines is under active development (coast of Lanai, Hawaii from the EC-135 cockpit).

The environment control allows to a drift ice overlay effect to render winter scenes in cold climate (coastline near Juneau, Alaska).

Improved usability

Flightgear becomes better accessible for the novel user:

A new tooltip system has been added, identifying knobs, gauges and levers for the new user and also indicating their value, thus eliminating the need to zoom to read badly visible instruments. On-screen messages are rendered in a new gnome-like semi-transparent window style. These changes are part of a larger restructuring of the user interface, which standardizes the interaction with cockpit clickspots and adds a more intuitive view mode by right-click/drag as option.

Lighting

The Rembrandt rendering does shadows best, but this does not mean other frameworks can do nothing:

The balance of direct and indirect light has been re-adjusted to simulate the self-shading of terrain better. In clear weather, shaded surface are now rendered much darker, leading to much improved visuals in low morning or afternoon light (the B-1900D over the French Alps near Grenoble).

Air-air refueling

Fans of realistic air-air refueling will be happy:

The air to air refueling system has been much improved. It now contains a menu to select tanker type, speed and contact radius. Two new tanker planes have been added, and the contact points are now correctly specified, allowing for a much more realistic aerial refueling experience.

Ground texture resolution

Landing somewhere off an airport was never before this nice:

A high resolution shader effect has been added to the procedural terrain rendering of the Atmospheric Light Scattering framework, which renders cm-scale detail resolution. This allows for a much improved low level flight experience and more interesting helicopter operations in the terrain, as there are now visual markers available to gauge distance to the terrain (the EC-135 landing on Lanai shrubland).

Weather

The weather system has received a major upgrade. The grouping of sparse clouds into patterns is now much more realistic, replacing simple clusters by visually more interesting undulatus or wavy patterns.

As part of these changes, the rendering of low visibility scenes in Atmospheric Light Scattering has also been made more consistent.

EC-135

The next version of a well-known aircraft arrives:

The Eurocopter EC-135 is currently undergoing a major overhaul. The FDM is completely revised, leading to a more stable experience in level flight, and the cockpit is done in high-resolution photorealistic texturing (over the French Alps, close to Grenoble).

A large selection of different models is provided, all with different liveries, equipment and slightly altered FDM (over the French Alps, close to Grenoble).

Canvas

The environment becomes more interactive:

Canvas is a technology to render 2-d information into the scene – it can be used for complicated instruments or a HUD. However, it has now been extended to be applicable to scenery objects as well – this allows for novel features such as airliner docking guidance systems as shown here.

Seasonal effects

Now you don’t only have to fly in summer or winter:

As part of a restructured tree shader, deciduous trees now shed their foliage if they are above the snowline, thus they adapt to the shader-drawn snow effects better. In addition, Atmospheric Light Scattering includes now an experimental season effect (mostly tested for Europe) which allows to simulate the autumn coloring of deciduous forests and pastures.

And many improvements more…

And that’s not all:

* regional textures for Middle East, the UK, Greenland, Indonesia, the arctic sea and Madagascar have been added
* improved aircraft checklists
* better interface between Basic Weather and Atmospheric Light Scattering rendering
* tree movement in the wind
* novel animations, allowing e.g. for more realistic rendering of complex gear motion
[youtube]http://www.youtube.com/watch?v=bWGLapFgOtw&feature=player_detailpage[/youtube]

*…

Stay tuned as we fly towards the next release!

Posted on

12 Days of Flight Tips (Season 2)

Last year, Oscar (youtube user: osjcag) created a series of short “howto” movies called the 12 Days of FlightGear Tips.  This year he is producing Season #2!  Each day he releases a new tip in honor of the twelve days of Christmas. Make sure you check back each day for the new tip!  Even “seasoned” FlightGear pilots may pick up a new trick or two.  Enjoy!

[youtube]http://www.youtube.com/watch?v=zoLuf3wfrEs[/youtube]

[youtube]http://www.youtube.com/watch?v=zMvGkJfoBVo[/youtube]

[youtube]http://www.youtube.com/watch?v=-AuEqnpnT0Q[/youtube]

[youtube]http://www.youtube.com/watch?v=6sSiSz2z9q8[/youtube]

[youtube]http://www.youtube.com/watch?v=VRYDHpjiTrM[/youtube]

[youtube]http://www.youtube.com/watch?v=GbfauLTlW90[/youtube]

[youtube]http://www.youtube.com/watch?v=Szoyj2AniJQ[/youtube]

[youtube]http://www.youtube.com/watch?v=5jahhoLY9sQ[/youtube]

[youtube]http://www.youtube.com/watch?v=1aY3m9s10s4[/youtube]

[youtube]http://www.youtube.com/watch?v=AKsP-IgyYwY[/youtube]

[youtube]http://www.youtube.com/watch?v=W3kaBY0CFQA[/youtube]

[youtube]http://www.youtube.com/watch?v=m1u9mnWv3Cs[/youtube]

Posted on

12 Days of Flight Tips (Season 1)

Oscar (youtube user: osjcag) has created a series of short movies called the 12 Days of FlightGear Tips. Each day he releases a new tip in honor of the twelve days of Christmas. Check back each day for the new tip!  Even “seasoned” FlightGear pilots may pick up a new trick or two.  Enjoy!

[youtube]http://www.youtube.com/watch?v=9FSdbw_c9qA[/youtube]

[youtube]http://www.youtube.com/watch?v=NeDMwBMg6Gs[/youtube]

[youtube]http://www.youtube.com/watch?v=HdVCVH0XMXM[/youtube]

[youtube]http://www.youtube.com/watch?v=CLCXwuWvDGQ[/youtube]

[youtube]http://www.youtube.com/watch?v=rITkJyTb5-Q[/youtube]

[youtube]http://www.youtube.com/watch?v=_LcZ93Q33D4[/youtube]

[youtube]http://www.youtube.com/watch?v=0HjkFHatYMI[/youtube]

[youtube]http://www.youtube.com/watch?v=CeFpvAR6sqg[/youtube]

[youtube]http://www.youtube.com/watch?v=hz1c8nuY62U[/youtube]

[youtube]http://www.youtube.com/watch?v=L1aNBV7JBIs[/youtube]

[youtube]http://www.youtube.com/watch?v=hLB7jui1U5c[/youtube]

[youtube]http://www.youtube.com/watch?v=RbB5Sn_ag-A[/youtube]