Switching default texture format to DDS

Note  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. — Torsten Dreyer (2014-09-03). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments.

Feedback needed - should Flightgear switch the defaults to dds format for terrain texturing?

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 textures 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 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)'

• 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

• Enter your experiences in the list below

Thanks for your help!

Tested hardware and graphis drivers

Note  Please add your own hardware/results here !

NVIDIA proprietary driver

Card	Driver	DDS ok	Reported by
GeForce GTX 670M	310.19	Yes	ThorstenR
GeForce GT 540M	331.82	Yes	Gijs
N13M-NS Optimus	340.32	Yes	Tom_ch
GeForce GT640	343.13	Yes	lumni1968
GeForce GTX 780 Ti	340.52	Yes	Avionyx
GeForce GT 750M	331.38	Yes	Dutchguy

Intel OpenSource driver

Card	Driver	DDS ok	Reported by
HD Graphics 3000 (i7-2600K)	10.2.6	Yes	cdesai
HD Graphics 3000 (i3-2330M)	10.2.2	Yes	Flyhigh/saiarcot895

ATI/AMD proprietary driver

Card	Driver	DDS ok	Reported by
ATI Radeon HD 6310	14.6-1	Yes	ZLSA

ATI/AMD OpenSource driver

Card	Driver	DDS ok	Reported by
AMD Radeon HD 7950	10.2.1	Yes	Saga

Excerpts from the ongoing discussion

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? — Torsten Dreyer (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

Misc

I'd propose [...] this process: Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are. 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. — Renk Thorsten (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

DDS Debate in 2012 (points made by Mathias)

Portability Concerns

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.

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.

(*) There are several statistics out there, this is the intel one that counts all sold computers. AMD does usually counts the revenue made with graphics boards (where ati wins I believe) or nvidia that usually limit statistics to professional systems (where nvidia wins).

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?

this is the reason for the (warning) 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'.

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.

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.

The motivation behind this mentioned change is to sort out the best compromise so that the hangs hopefully disappear - which I hope to get with precomputed mipmaps - and being able to display fine with any driver/gpu.

Approaches

Ideas raised by Mathias in 2012 [1]:

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?

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.

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

Other ideas? Also may be creative ones?

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.

Precomputed mipmaps

points made by Mathias in 2012[2]:

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?

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

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.

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!

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.

FredB implemented a mipmap control and generation tool in effects when he 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

Challenges

"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? — Renk Thorsten (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

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. — Rebecca Palmer (2014-09-02). Re: [Flightgear-devel] Download size, and hardware support (was .dds textures). (powered by Instant-Cquotes)

On my system (Intel Ivybridge), DDS works with or without libtxc, but this may not be true of all Intel hardware. — Rebecca Palmer (2014-09-02). Re: [Flightgear-devel] Download size, and hardware support (was .dds textures). (powered by Instant-Cquotes)

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. — Stefan Seifert (2014-09-02). Re: [Flightgear-devel] Download size, and hardware support (was .dds textures). (powered by Instant-Cquotes)

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". — Rebecca Palmer (2014-09-02). Re: [Flightgear-devel] Download size, and hardware support (was .dds textures). (powered by Instant-Cquotes)

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. — Torsten Dreyer (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

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. — Rebecca Palmer (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

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 — Torsten Dreyer (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

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. — Rebecca Palmer (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

Conversion

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 ?" :-) — Clement de l'Hamaide (2014-09-02). Re: [Flightgear-devel] Download size, and hardware support (was .dds textures). (powered by Instant-Cquotes)

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. — jean (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

Pros

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. — jean (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

Cons

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. — Renk Thorsten (2014-09-02). Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏). (powered by Instant-Cquotes)

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. — Saikrishna Arcot (2014-09-02). Re: [Flightgear-devel] Download size, and hardware support (was .dds textures). (powered by Instant-Cquotes)