Switching default texture format to DDS: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Check with GeForce 750M added.)
(Added my GPU/driver combination)
Line 94: Line 94:


=== ATI/AMD proprietary driver ===
=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|}


=== ATI/AMD OpenSource driver ===
=== ATI/AMD OpenSource driver ===

Revision as of 15:14, 4 September 2014

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

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

NVIDIA OpenSource driver

Intel proprietary driver

Intel OpenSource driver

Card Driver DDS ok Reported by
HD Graphics 3000 (i7-2600K) 10.2.6 Yes cdesai

ATI/AMD proprietary driver

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

ATI/AMD OpenSource driver

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
Cquote1.png let's collect some some feedback 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. That's definitely not
me - any volunteers?

Torsten


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

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

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

Contra

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