Switching default texture format to DDS

From FlightGear wiki
(Redirected from DDS Textures in FlightGear)
Jump to navigation Jump to search

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

  • DDS is a more compact format than png, 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, in essence 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.

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.

Cquote1.png let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.
Cquote2.png

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures. In other words, a lack of feedback from end users might very well mean that future FlightGear versions may require DDS support and may not necessarily work for people with outdated hardware - so if you care about backward compatibility, please do get involved, test DDS support and provide feedback!

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:

  1. Open the dialog under View -> Rendering
  2. Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'
  3. Press 'Okay' - FG will reload the terrain
  4. 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, or even bright/pink, colors or other rendering artifacts, your system may have problems with DDS.
  5. Change back to the texture scheme you like best
  6. Enter your experiences in the list below

Thanks for your help!

Tested hardware and graphics drivers

NVIDIA proprietary driver

Card Driver DDS ok Reported by
GeForce GTX 670M 310.19 Yes ThorstenR
N13M-NS Optimus 340.32 Yes Tom_ch
GeForce GT 520M 344.75 Yes EliasTarasov
GeForce GT 640 343.13 Yes lumni1968
GeForce GTX 780 Ti 340.52 Yes Avionyx
GeForce GT 750M 331.38 Yes Dutchguy
GeForce GT 620 OEM 331.38 Yes C-GGKV
GeForce GTX 650 331.20 Yes dany93
GeForce 210 304.117 Yes Jean-Philippe
GeForce GT 520 332.21 Yes cossack90
GeForce GTX 260 304.117 Yes Lann
GeForce GTS 250 331.38 Yes Madbyte
GeForce GTS 450 340.32 Yes chris_blues
GeForce 8600 GT 340.32 Yes szpajder
GeForce GTX 460 SE 331.38 Yes f-jjth
GeForce GTX 560 Ti 319.32 Yes PATTEN
GeForce 8600 GT 331.38 Yes attila
GeForce GTX 750 ti 340.32 Yes f-toro
GeForce GT 650M Apple OS 10.9.4 No dersh
GeForce 9800GTX 304.117 Yes ctec356
GeForce GT 220 331.38 Yes D-ABEK
GeForce GTX 760M 331.38 Yes f-ojac
GeForce GTX 560 319.32 Yes Clm76
Quadro FX 770M 304.88 Yes OO ZVY
GTX 660 Ti 340.46 Yes JS

NVIDIA open source driver (Nouveau)

Card Driver DDS ok Reported by
GeForce GT 630 No Jakub Klawiter
GeForce GT 220 No D-ABEK
GeForce GTX460 No User:T3r

Intel proprietary driver

Card Driver libtxc_dxtn installed? DDS ok OS Reported by
Intel HD Graphics 5000 N/A N/A No Mac OS X 10.9.5 Csantz

Intel open source driver

Card Driver libtxc_dxtn installed? DDS ok Reported by
HD Graphics 3000 (i7-2600K) 10.2.6 N/A Yes cdesai
HD Graphics 3000 (i3-2330M) 10.2.2 N/A Yes Flyhigh/saiarcot895
HD Graphics Sandy Bridge (Pentium B980) 10.1.0 No Yes f-jjth
HD Graphics 4000 Ivy Bridge 10.3.0 No Yes onox
HD Graphics 4000 (Ivy Bridge) 8.15.10.2712 No Yes Red Leader

ATI/AMD proprietary driver

Card Driver DDS ok Reported by
ATI Radeon HD 6310 14.6-1 Yes ZLSA
AMD Radeon R9 200 Series 14.4 Yes Richi
Radeon HD 4850/4870 legacy 8.97.100.7-4 Yes Jano
ATI Mobility Radeon HD 4570 8.631 Yes Yury 4500

ATI/AMD open source driver

Card Driver libtxc_dxtn installed? DDS ok Reported by
AMD Radeon HD 6570 10.1.3 Yes Yes fgjosh
AMD Radeon HD 6770 10.2.5 No No Mongrol
AMD Radeon HD 7950 10.2.1 Yes Yes Saga
AMD Radeon R9 270X 10.3~git20140805 No No nine
AMD Radeon R9 270X 10.3~git20140805 Yes Yes nine
AMD Radeon HD 4850 ?? (debian sid) Yes Yes jano

Sample test

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

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.
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.

 --airport=LIME
 --aircraft=757-200-PW2040
 --disable-random-objects
 --enable-horizon-effect
 --enable-enhanced-lighting
 --enable-distance-attenuation
 --enable-ai-models
 --disable-ai-traffic
 --disable-real-weather-fetch
 --enable-clouds3d
 --bpp=32
 --texture-filtering=16
 --prop:/sim/rendering/multi-sample-buffers=1
 --prop:/sim/rendering/multi-samples=4
 --timeofday=noon
 --enable-terrasync
 --httpd=5500
 --props=5501
 --jpg-httpd=5502
 --multiplay=out,10,,0
 --multiplay=in,10,,0
 --disable-fgcom

Excerpts from the ongoing discussion

Cquote1.png Here is my suggestion how to proceed:
  • Let's do your 1) and 2) on as many information channels we have.
  • Collect the responses on a public place, I'd suggest a wiki page
  • Do this for a well defined time frame. Is three month too much/too short?
  • If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
  • Keep this for one release.
  • Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?


Cquote2.png

Misc

Cquote1.png I'd propose [...] this process:
  1. Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
  2. Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.


Cquote2.png

DDS Debate in 2012

Legalities

Cquote1.png These kind of precompressed images limits their usage to a specific set of

drivers. And no, due to the patent issues no open source code including ours
is allowed to implement compression/decompression code for these image
formats. Even if this is easy implementation wise.


— Mathias Fröhlich (2011-12-29). Re: [Flightgear-devel] Improving random trees & buildings.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png t is technically incorrect to provide these s3 patent

precompressed textures to a driver that does not announce the apropriate
extension and since we are not allowed to code something that deompresses
this, I think we should avoid using this compression for all the provided
models/textures.

I think of a warning that is issued from the image loader in flightgear that
detects when these precompressed textures are seen. So even people using
drivers that just offer this extension have a chance to see that the provided
textures will not work for others.


— Mathias Fröhlich (2012-01-01). Re: [Flightgear-devel] Improving random trees & buildings.
(powered by Instant-Cquotes)
Cquote2.png

Portability Concerns

Cquote1.png These kind of precompressed images limits their usage to a specific set of

drivers. And no, due to the patent issues no open source code including ours
is allowed to implement compression/decompression code for these image
formats. Even if this is easy implementation wise.


— Mathias Fröhlich (2011-12-29). Re: [Flightgear-devel] Improving random trees & buildings.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png And this is what I try to do now:

Object against using these patented compression algorithms.
I do not care for the on disk format of any image file we have. But the problem
is that some kind of precompression that can be stored in these dds files
cannot be used with other drivers than the closed ati and nvidia ones.
As long as these patented compression techiques are not used, every OpenGL
driver can use this and displays this fine.

Think: Intel has the hugest marketshare in graphics today. If I remember
right, they sell more than ati and nvidia together (*). This kind of change in
effect rules out the majority of users as intel cannot work with these files.


— Mathias Fröhlich (2011-12-29). Re: [Flightgear-devel] Improving random trees & buildings.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably

have the same effect. So I think simply ommitting DDS is ok?

Also, much more important, the comment is not about 'your video driver'. It is
in your (Vivian) case even wrong. Your driver will display this fine.
So, in the end I do not care if it is 'your particular video driver' that does
not like this. You will just see this in the best case as the models look
wrong, and in the worst case fgfs just crashes the driver if these textures
are used.
What I really care about is that these files are expected not to work on a huge
amount of graphics boards out there. The point is to tell people doing
textures that they should omit compression so that this message disapears.


Cquote2.png
Cquote1.png I would like to have a flightgear that is by default just running on every

average system. Having this run faster on a special configured system with some
better configuration options and hand tuned hardware and drivers is very fine.
But without tuning it must at least work in an acceptable way.

I have checked in a change to flightgear to make the use of the compressed
internal formats a starttime configuration option.
I am still interrested if we have that hangs also with texture compression
disabled and without providing precompressed dds textures?


— Mathias Fröhlich (2011-12-29). Re: [Flightgear-devel] Improving random trees & buildings.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png this is the reason for the message. If your machine would refuse to display this you,

developing that, would probably just say 'nice try, but it does not work'
before you check in something. In the case it displays fine, you probably say
'it works here, so I assume it works also for others, lets do'.
And the message tells you, 'despite of just seeing this working on this
current machine, it does not work for others'.


Cquote2.png
Cquote1.png Seriously, I think plenty people not being on this list today and probably

never will be in touch with anybody here, will run into this issue.
People here are those few guys from the power users that want to develop this
stuff.

I am not going to discuss the patent stuff. Please search the mesa-dev archives
for the discussion and see there why they think that the nvidia tools and
other stuff out there cannot be used. Really - it is not that the code for that
is too dificult or unavailable. I am not a lawyer and I cannot change this
world - even if I would like to in this regard.

I agree that techically for drivers/gpus supporting these compression formats
it would be best to use these precompressed files.


Cquote2.png
Cquote1.png Seriously, I think plenty people not being on this list today and probably

never will be in touch with anybody here, will run into this issue.
People here are those few guys from the power users that want to develop this
stuff.


Cquote2.png
Cquote1.png Your driver will display this fine.

So, in the end I do not care if it is 'your particular video driver' that does
not like this. You will just see this in the best case as the models look
wrong, and in the worst case fgfs just crashes the driver if these textures
are used.
What I really care about is that these files are expected not to work on a huge
amount of graphics boards out there. The point is to tell people doing
textures that they should omit compression so that this message disapears.


Cquote2.png

Approaches

Cquote1.png Well, the default f16 does not work anymore for example.

I have also never tried the new textures, but I assume that these also contain
precompressed data? Also you claimed that the old texture files start to bitrot
comared to the new ones which makes me think that the new standard should be
the dds files. This together makes me think that the dds files should replace
the traditional image files.


— Mathias Fröhlich (2011-12-29). Re: [Flightgear-devel] Improving random trees & buildings.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Hmm, regarding dds.

I have to say, that not all OpenGL drivers support texture compression, and
the models with dds files, are those that I cannot display, because of that.
And in fact this will not happen to the open source drivers before something
about 2020 because of patent issues.

Sorry to step in this so late - probably way too late - but is there a reason
that the on disk format must be compressed?
The previous strategy to have on disk an format that everybody can read and to
make the driver compress them as needed/possible is better I think?

So, for me the f16 lost its livery lately - where I can live with this for the
f16, I hope that this does not happen to flightgear as a whole ...


— Mathias Fröhlich (2011-12-27). Re: [Flightgear-devel] Improving random trees & buildings.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Well, I hope that we can get rid of the compression.

Can somebody with the apropriate tools convert the compressed textures to non
compressed ones? That could still be dds, but dds without these compressions
that produce the warning. So no problem with cubemaps in dds as long as the
compression is not there.
Then *everybody* is again able to use this stuff.


Cquote2.png
Cquote1.png I can see several approaches:


  • Just do not use the patented compression stuff. The precomputed mipmaps could

probably do the job of avoiding the hangs (hopefully? to be checked?). May be
we could lower disk space usage by providing a dds.gz or similar wrapper?

  • If it's just the mipmaps. May be we can precompute the mipmaps using the cpu

in the database loader thread. This would help all textures not only the ones
that could be converted. May be this is the most generic solution.

  • Implement some kind of image lookup order that knows if the compressed files

could be handled or not. On loading an image in case of available compression
first try to find a dds file with the same name of the original one. That
involves some 'magic' which often leads to problems but that could at least
work.


Cquote2.png
Cquote1.png Next step is to make sure that compression is not required to avoid the hangs.

My favorite bet would be that then the new configure option regarding texture
compression needs to be set to none.


Cquote2.png

Precomputed mipmaps

Cquote1.png Could we do dds files without compression but with precomputed mipmaps?


So at next, can you try out which combination of compression/provided
mipmaps/forced simgear compression still work fine?


— Mathias Fröhlich (2011-12-29). Re: [Flightgear-devel] Improving random trees & buildings.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The 4. Method that I can imagine is to precompute the mipmaps in the loader.

IIRC tests with some of the guys suffering from this problem, providing
premipmapped but uncompressed dds files had helped to get a fluent viewer.
The argument against providing these dds files in general was that these files
are really huge because of not including any compression and having all the
mipmaps.
But that means we could at the point where the warning happens compute the
mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be
used to do this I think (or something similar not requireing a context). This
one is an imported version of the original glu function that is included in
osg for running on an EGL stack which no longer provides GLU.
That is take the image scale this to the 1st mipmap, take the 1.st mipmap and
scale this to the 2. mipmap and so forth.

This would have the advantage that the png's do not deviate from the dds files
over time.


— Mathias Fröhlich (2012-07-21). Re: [Flightgear-devel] DDS usage in effects files.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I think then, computing mipmaps for any texture file on the CPU in the loader

thread should globally improove the situation.
Also avoiding the compression already in the files should help every use case.
Except that the on disk memory consumption is higher.
Well and except that the database loader has more work to do on the CPU.


Cquote2.png
Cquote1.png Doing that differently will provide some overhead that could be kept at a

minimum I think:
For the disk usage, I think gzip compressing these will work sufficiently fine.
Ram usage of the images should not hurt too much. Sure the images are bigger
in memory. But fgfs is not just about images - far from that.
On the GPU, you can still use compression for the textures as the internal
format. This is what flightgear tries to do if the extension is supported
(checked by osg).

The major point is that there are several ways that use slightly more
resources to get around this problem.
But once the patented compression is on disk, there is *no* way back for
people not having this feature.

If you have better ideas that do not rule out intel and the oss drivers, you
are welcome!


Cquote2.png
Cquote1.png On unix I usually get the gzip plugin installed by osg (osgdb_gz.so). Is this

also the case for the default win32 case? Is there a osgdb_gz.dll or something
along the lines in the directory containing the plugins?

If yes, we can already tackle the size problem of the uncompressed dds files on
disk by just gzip compressing these makging a xxx.dds.gz from a xxx.dds and
just refering to xxx.dds.gz instead of xxx.dds. At least this works fine here.
And I assume that this works fine for all unix like operating systems including
mac?!
James?


Cquote2.png
Cquote1.png What about solution 6 with (uncompressed premipmapped dds).gz?

On linux this should work as long as you have zlib installed which could be
regarded as a system library there.
Can we rely on zlib being compield into our osg distributions on win32? We do
need zlib in any case, it's mostly about teaching osg that it finds our zlib on
configure and build the gz plugin.


— Mathias Fröhlich (2012-07-21). Re: [Flightgear-devel] DDS usage in effects files.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I implemented a mipmap control and generation tool in effects when I last updated

the urban shader. For the moment, it relies on hardware when the average operator
is used for all texture channels but it could easily be modified to compute
all mipmap on the CPU. look the <mipmap-control> effect option and
mipmap.[ch]xx in SG material lib


Cquote2.png

Implementation

Cquote1.png As has been previously pointed out, the current DDS texture set is not

simply the global png texture set converted.

For our own sanity and those of the users, we need to ensure that there's
an apples-to-apples comparison being made when we change the default. I
therefore think we need to create a DDS version of the current default
texture set.


Cquote2.png
Cquote1.png 2) If we go down this path, we probably want to separate the underlying

texture format from the materials.xml definition entirely. For example, we
could simply remove the extention from the materials definition, and have
the C++ code append the appropriate extension based on a separate property.
This has a couple of advantages:
a) Makes testing easier and materials definitions less error-prone.
Assuming we have some batch job in place to generate dds textures, those
working on materials definitions could continue to work with png textures,
and only convert to dds as a final step (or indeed as part of the "make
release" jobs).
a) Avoids duplication of materials definitions. Having just spent quite a
bit of time making the materials definitions more efficient, I'd like to
avoid making it worse again!

I'm quite happy to do the C++ coding required for this in the materials
loader - it's probably pretty straightforward.


Cquote2.png
Cquote1.png That does leave the issue of what happens to the existing dds texture

definitions where there are special mipmap layers. I'd suggest that we
have some Clever Script (tm) that is able to work out whether the DDS or
PNG version of a texture is the master, and then generate the other version
from it. I admit that the PNG conversion of the DDS will lose some
information in this process, but it would allow those without DDS support
to at least use the textures.


Cquote2.png
Cquote1.png 3) We need a sensible process for dealing with aircraft, which has been

identified as a significant issue. Again, I think more aircraft developers
find .png easier to deal with, and there are a lot of aircraft out there
that would need conversion. It feels like we need some build scripts to
"compile" aircraft to use DDS textures.

A more far-fetched idea might be to have a cache of dds textures that are
generated on-the-fly, or when aircraft are loaded by the aircraft center.
Clearly that impacts initial load time the first time a new aircraft is
loaded, and would increase the size of .fgfs/ directories massively, but it
would remove the need for any work by aircraft/scenery developers and could
be made optional.


Cquote2.png

Challenges

Cquote1.png "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."


Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons?

Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?


Cquote2.png
Cquote1.png Another potential option would be to convert regions to .dds but keep

both global-png and global-dds, but making that user-friendly would
require a way to automatically detect lack of .dds support.


Cquote2.png
Cquote1.png On my system (Intel Ivybridge), DDS works with or without libtxc, but

this may not be true of all Intel hardware.


Cquote2.png
Cquote1.png You can specify the dependency on libtxc_dxtn, but then distributions like

openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture
compression which is patented in many parts of the world. Linux distributions
therefore cannot ship it. You can easily find it in add-on repositories, but
as I said, distributions would not be able to include FlightGear creating a
huge hurdle to installation for users.


Cquote2.png
Cquote1.png Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the

patent at a small cost in visual quality:
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn
That site also states that modern hardware doesn't need this software
fallback anyway (and hence won't hit either this quality loss or the
slowness of any software decoder), but doesn't define "modern hardware".


Cquote2.png
Cquote1.png The dds textures seem to have some advantages over our png textures and

using them is tempting.
But the points from Thorsten R. are good points and if there is any
chance to have a step-wise transition to the new format, I'd prefer that
path.

Don't we have an alternate dds texture set already in fgdata that is
enabled with an option? What about making this the default, keeping the
png texture set as an alternate. That would get us reports from users
unable to run dds textures and provide an easy fallback method.


Cquote2.png
Cquote1.png We currently have regions-png, global-png and global-dds; as I noted

earlier, switching to regions-dds, global-png and global-dds has the
issue that while changing the texture set is easy (dropdown in View >
Rendering Options), knowing that one needs to do so may not be.


Cquote2.png
Cquote1.png Can we invert the logic in, say, preferences.xml so xxx-dds is enabled

by default and switching to xxx-png has to be done in rendering options?

Torsten


Cquote2.png
Cquote1.png Changing the default (which is in preferences.xml) is easy: the problem

is how do users with non-.dds-supporting hardware (if this exists) know
they need to change back.


Cquote2.png

Conversion

Also see DDS texture conversion.

Cquote1.png the script take the .dds and not convert the png again if both exist(I remember having manually used "compare" to check if both the dds and the png looks the same, and if not i changed some names)


notice that the normal maps are a particular case as you need to tell the effect the texture is dds with a line like:

1


just be sure to include this in the normal map effects with png and it will be easier:

0


about FG doing the dds conversion , nvcompress is told to be gpl compatible, but i'm not an expert here:

http://nvidia-texture-tools.googlecode.com/svn/trunk/NVIDIA_Texture_Tools_README.txt


Cquote2.png
Cquote1.png I think this is an inheritance from some other game engine using a different convention, and therefore from the authoring tools that were developed for such an engine (photoshop exporter plugins and the like). If indeed the FGFS DDS textures are only meant to be used in FGFS then this should be fixed at the conversion time. Otherwise, if we want other applications to easily reuse the FGFS textures then it would be better to stick to the most common convention. But I think we all agree that the source for any DDS texture should be kept, which pretty much precludes importing ready made DDS textures from 3rd party sources. Incidentally I think importing DDS artwork from other sources should be discouraged, since it will most likely run afoul of the licensing terms of the original copyright owner.
Cquote2.png

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)

Cquote1.png Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
Cquote2.png
Cquote1.png A few world about the conversion: once a png/rgb/jpg found, the script

try to guess the suitable dds format: with or without alpha channel,
bumpmap, if a .dds is allready found we just erase the png one, if not
we use nvcompress to get the dds. After we change the textures name
called in the differents files and that's it. There's a way to tell the
script what to do for each file, if the automatic mode is a failure.

I guess speaking theorically is not the best to make an opinion, so if
some of you are interested to make a test, I will make a 3.2 minimal dds
fgdata this we, once on my FG pc.


Cquote2.png

Pros

Cquote1.png I always got a loading problem with png textures, large textures take

seconds to load and convert, and that ruin my close flight where you
can't afford to take pause in the air.
that's why i did a batch script to convert to dds ALL the textures in
the data, not only the matérial set, but everything. Now i only flight a
dds version of flightgear, and am quite happy with it, that's why i
propose to provide a dds fgdata for test, and maybe to make it an
alternate download possibility.


Cquote2.png

Cons

Cquote1.png 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.
Cquote2.png
Cquote1.png If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
Cquote2.png