Switching default texture format to DDS: Difference between revisions

== DDS Debate in 2012 (points made by Mathias)==

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.

 

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 have checked in a change to FlightGear to make the use of the compressed internal formats a start time configuration option.

I am still interested 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 disappears.

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.

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.

I hope that we can get rid of the compression. Can somebody with the appropriate 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.

 

 

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

computing mipmaps for any texture file on the CPU in the loader thread should globally improve 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 compiled 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