Switching default texture format to DDS: Difference between revisions

== Feedback needed - should FlightGear switch the defaults to DDS format for terrain texturing? ==

However, the DDS compression algorithm is patented, which means that it is not readily available for open source 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.

=== What we need you to do? ===

FlightGear already provides the simple option to test a DDS texture set. If you are running on Linux and use an open source graphics driver, please take 5 minutes to help during your next FG session:

== Tested hardware and graphics drivers ==

=== NVIDIA proprietary driver ===

{| class="wikitable sortable"

|Tom_ch

|-

|343.13

|{{yes}}

=== NVIDIA open source driver (Nouveau)===

{| class="wikitable sortable"

!Card

|HD Graphics 3000 (i7-2600K)

|10.2.6

|{{yes}}

|cdesai

|HD Graphics 3000 (i3-2330M)

|10.2.2

|{{yes}}

|Flyhigh/saiarcot895

|HD Graphics Sandy Bridge (Pentium B980)

|10.1.0

|{{yes}}

|f-jjth

|AMD Radeon HD 7950

|10.2.1

|{{yes}}

|Saga

|-

|AMD Radeon R9 270X

|10.3~git20140805

|{{no}}

|nine

|-

|AMD Radeon R9 270X

|10.3~git20140805

|{{yes}}

|nine

== Sample test ==

=== DDS Test at the airport of Orio (Bergamo - Italy) ===

[[File:Terrain texture scheme DDS 01-2000.jpg|800px|thumb|Comparison of texture in relation to the three possible choices in "Rendering Options" -> "Terrain texture scheme"]]The final result, with all the "Shader Options" active, is not very satisfactory, I would say very poor. Apparently not check on any improvement in the speed of image loading. I think on modern machines with quad-core processors 16 GB, with latest graphics cards (NVIDIA 870) 6 GB, the loading of these images is not really a "bottleneck". I propose to insert the DDS functionality, but in a transparent way, ie convert "on the fly" the images before inserting them into the temporary memory, for example using the convert function of ImageMagick. However, I do not know if it really is a useful feature, I think there are many other things to do before this.<BR>These are the parameters used by the startup script "run_fgrun.sh":

{{Note|To reproduce this test, you can use the following [[Fgfsrc]] file - you should set up [[$FG_ROOT]] and [[$FG_SCENERY]] specifically for your own system though.}}

== Excerpts from the ongoing discussion ==

{{FGCquote

   |Here is my suggestion how to proceed:

== DDS Debate in 2012 ==

=== Legalities ===

{{See also|Talk:Switching default texture format to DDS#Using patented algorithms}}

   }}

}}

{{FGCquote

=== Approaches ===

{{FGCquote

   |Well, the default f16 does not work anymore for example.<br/>

   }}

}}

{{FGCquote

   }}

}}

=== Precomputed mipmaps  ===

{{FGCquote

   |Could we do dds files without compression but with precomputed mipmaps?<br/>

   }}

}}

{{FGCquote

== Implementation ==

{{FGCquote

   |As has been previously pointed out, the current DDS texture set is not<br/>

   }}

}}

{{FGCquote

   }}

}}

{{FGCquote

== Challenges ==

{{FGCquote

   |"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib."<br/>

   }}

}}

{{FGCquote

== Conversion ==

Also see [[DDS texture conversion]].

Nothing as exotic. Just a different "origin" between OpenGL and Direct3D image conventions. OpenGL image origin is located in the lower-left corner, while Direct3D (hence DDS too) considers the top-left as the origin, resulting in a DDS image to appear vertically flipped when read in an OpenGL context. This has repercussions in the way normal-map decoded normals appear (hence the flag in the effects, which signals to the shader to flip the decoded normals). The rest is simply a matter of workflow: either use flipped coordinates and skewed/reversed conventions throughout your whole workflow, or just flip the image and (eventually) set a flag for the shader at "publish" time (said flag could be automatically set by the code on DDS texture load). ''(the latter seems more pragmatic/appealing)''

{{FGCquote

== Cons ==

{{FGCquote

   |FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.