The FlightGear development team is delighted to announce the v3.2 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include an experimental aircraft manager allowing users to download and load aircraft in-sim, a very capable built-in HTTP server, built-in voice synthesizer for ATIS messages, and many improvements to the Canvas rendering framework.

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.