Posted on by Thorsten R.

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.

18 Replies to “Feedback on dds textures required”

    1. BTW Design patents last 14 years from the date you are granted the patent. The “patend” was filed 1999-09-21. If you read the “patend” it is so bread that it is even likely invalid for most parts.

  3. http://en.wikipedia.org/wiki/DirectDraw_Surface
    The DirectDraw Surface container file format (uses the filename extension DDS), from Microsoft, is a standard for storing data compressed with the lossy S3 Texture Compression (S3TC) algorithm

    you mean this?

    well then its a no go as S3TC is known with the patent problem.

    so why not go the route of the official opengl standard?

    http://www.khronos.org/news/press/khronos-releases-atsc-next-generation-texture-compression-specification

    http://www.opengl.org/registry/doc/glspec45.core.pdf

    I.3. ARB AND KHRONOS EXTENSIONS
    735
    based on the earlier
    GL_APPLE_flush_buffer_range
    extension, and is pro-
    vided to enable this functionality in older drivers.
    I.3.3.44 Texture Buffer Objects
    The name string for texture buffer objects is
    GL_ARB_texture_buffer_-
    object
    . It was promoted to a core feature in OpenGL 3.1.
    I.3.3.45 RGTC Texture Compression Formats
    The name string for RGTC texture compression formats is
    GL_ARB_texture_-
    compression_rgtc
    . This extension is equivalent to new core functionality intro-
    duced in OpenGL 3.0, based on the earlier
    GL_EXT_texture_compression_-
    rgtc
    extension, and is provided to enable this functionality in older drivers.
    It was promoted to a core feature in OpenGL 3.0.

    I.3. ARB AND KHRONOS EXTENSIONS
    739
    tomatic level-of-detail computations that would be performed if a texture lookup
    were to be done.
    The name string for texture level-of-detail queries is
    GL_ARB_texture_-
    query_lod
    .
    I.3.3.66 Profiled Context Creation
    Starting with OpenGL 3.2, API profiles are defined. Profiled context creation ex-
    tends the versioned context creation interface to specify a profile which must be
    implemented by the context.
    The name strings for the GLX and WGL profiled context creation interfaces
    are
    GLX_ARB_create_context_profile
    and
    WGL_ARB_create_context_-
    profile
    respectively.
    I.3.3.67 Shading Language Include
    Shading language include adds support for
    #include
    directives to shaders, and
    a named string API for defining the text corresponding to
    #include
    pathnames.
    The name string for shading language include is
    GL_ARB_shading_-
    language_include
    .
    I.3.3.68 BPTC texture compression
    BPTC texture compression provides new block compressed specific texture for-
    mats which can improve quality in images with sharp edges and strong chromi-
    nance transitions, and support high dynamic range floating-point formats.
    The name string for BPTC texture compression is
    GL_ARB_texture_-
    compression_bptc
    .
    I.3.3.108 ASTC Texture Compression
    The name string for ASTC texture compression is
    GL_KHR_texture_-
    compression_astc_ldr
    . This extension is equivalent to new core functionality
    introduced in OpenGL 4.3, and is provided to enable this functionality in older
    drivers.

  4. The use of the DDS format is a very good thing. The graphical improvements are interesting.

    But :

    FlightGear will be more close a game than a real simulator. And that will please all newcomers who do not understand the main idea of ​​FG. The airplane simulation.

    Use DDS for the ground, yes, why not. Remove the management of other formats by cons is a very bad idea. This is not in the spirit of open source. And the use of a non-free format increasingly away from its original purpose FG.

    Why to want ABSOLUTELY FG as a FSX copy ? The eyes candy has become the rule today. The “look” is more important than “being.” If this is the case the world has become sad.

    1. The proposed change is a technical switch from one format to the other, which will not affect visuals either way. The proposed change also explicitly involves keeping the master texture files as png, so no textures are migrated to a closed format. Neither of this has any impact on the fidelity of airplane simulation. So you seem to have a few things mixed up here.

      If you are concerned with the quality of the flight dynamics model, I would suggest you take action yourself and take more of your time to refine FDMs and less time creating new 3d models 🙂

    2. Don’t think anything’s wrong with being an eye candy. Besides, FG differs quite significantly from any other sim, so there’s no point in worrying about being ‘too FSX’.

  5. Works for me on Intel HD 4000 with the open source driver for Linux, version 2.99.914. I have libtxc_dxtn version 1.0.1 installed.

    Can somebody add this to the wiki, as I won’t create an account just for that ?

    Louis

  6. An optional download package with DDS would be fine. REPLACING the release package with DDS is imho a bad idea.

    Last I checked DDS was still a patent encumbered format, not to mention lossy, which makes it not an ideal conversion for those of us who would prefer maximal visual acuity.

    This is just my two cents, but I hope some other people will chime in to agree with me.

    1. We don’t know. There’s a serious bug being addressed which leads to crashes and bad performance, and while the strategy for a fix seems clear now, it’s not fully implemented and tested.

      1. Really good that you have found the bug. Keep up the good work. Will you prepare another RC for testing purposes?

Comments are closed.