Talk:Switching default texture format to DDS: Difference between revisions
m (→Using patented algorithms: heading: Patented algorithms and creating textures (legally) → Using patented algorithms) |
No edit summary |
||
| Line 42: | Line 42: | ||
}} | }} | ||
}} | }} | ||
==Proposal for a change "on the fly" in the texture format== | |||
At the end of it all, I have always found problems when I used proprietary formats for my programming work. Consider the case of Java, a language with which development every day, when Sun was a lot of promises on possibility to open Java development, but when became property of Oracle all Java technology become closed source. Fortunately, common sense prevailed and was made the open version that I use daily as 90% of the developers. I think the best thing is not to generate constraints, but make our environment "flexible", ie that it can use either format, depending on the constraints present in a given country. I do not like to think that a user embargoed, such as an Iranian person, FGFS can not use because the DDS is part of a proprietary technology which can be banned for export.<BR>In my work it is normal to try to make the system flexible. In this case I think it is better to write a few hundred lines of code in more and introduce a scheme like the one I included in the diagram: | |||
[[File:Automatic format convert 01.jpg|thumb|800px|DDS-PNG-JPG Automatic format convert]] | |||
The idea is simple, you can use various formats, such as SVG which is also very useful for liveries, when the format is read a process transforms it into the format you want to use for your graphics card, such as the DDS , PNG or S3TC, the transformation could also use an appropriate pixel density as a function of monitor used! The everything is sent to a cache that can only be in RAM or, as I often do, mixed RAM-HD according to the type of use. This approach allows to minimize the load of conversion and at the same time allows to have the images already ready for use. Normally a pilot flies in areas fairly restricted and then the cache may already contain all what interests him limiting in this way the load of the CPU. An index, if the cache is mixed RAM-HD can handle various things, such as whether a file has been updated and then redoing the conversion, manage LIFO etc ... This seems like a solution is not too complicated, but extremely flexible, which separates the authors of the texture from the problems of format and its licenses. When the cache is stabilized, the CPU load is very small compared with its other activities. Fact that I have always occurred when I implemented these features in Java. --[[User:Abassign|Abassign]] ([[User talk:Abassign|talk]]) 09:11, 6 September 2014 (UTC) | |||
Revision as of 09:11, 6 September 2014
devel list quotes: yay or nay ?
been in touch with Thorsten about the quotes I started adding before anybody got involved in the article, and working towards summarizing the main points to see if things can be cleaned up a bit. However, this might be one of the few cases, where having a bunch of quotes could actually be a good thing, opinions ? --Hooray (talk) 12:44, 4 September 2014 (UTC)
- In this case I think it is a very good idea to use quotes here as many people can be "passionately opinionated" about things like these. It might be very important for the reader to have a good idea of who said what. I even took a look at the devel list at sourceforge, but I have to say that the quotes are easier to follow. While I am at it, thank you for putting the quotes in different section depending on content.
- ok, I used bigstones' Instant-Cquotes script to replace those quotes with proper cquotes now - even though Gijs is right, the formatting is still not quite right, I guess we need to update the script eventually to remove redundant stuff like all those <br/> tags. Also, some quotes should probably be re-arranged and shuffled around, like you say: having proper sections is a good idea and helps navigating all those quotes, so we could add a few more sections and re-arrange things accordingly. And like you said, the legalities were already raised 2.5 years ago on the devel list, but for some reason people tend to forget such things ...--Hooray (talk) 01:48, 5 September 2014 (UTC)
Using patented algorithms
I assume there are plugins for example for GIMP out there and perhaps also specialized tools for creating the textures, but something I have not got a clear answer to when searching the web briefly is how one would legally create the compressed textures if the compression algorithms 
are patented. Unfortunately, at this point it does not seem possible.
This is a bit of a pickle for me. While we have been firm about using non-free resources (though unfortunately some seem to not be). I would say that using patented algorithms without the permission of the patent holder (or his representatives) would be just as bad as doing complete airport layouts using aerial footage form Google maps, or using sound captured from non-free movies in aircraft (or using FlightGear with a stolen joystick...). Note the distinct difference between being published and being free for use.
Browsing a bit more it seems that while there is support for these formats as OpenGL extensions, they still have to be licensed in order to use them. While I am not a lawyer and me be a bit confused, have a look at the section "IP Status" in http://www.opengl.org/registry/specs/EXT/texture_compression_s3tc.txt and at https://www.khronos.org/files/ip-disclosures/opengl/S3_IP_Cert_NOV_2011_clean.pdf (The Khronos Group is the not for profit industry consortium that have written and published latest versions OpenGL specification).
I have also seen this note about using these compression algorithms with Mesa:
|
S3TC support has been partially implemented in Mesa. We cannot integrate and enable S3TC code by default due to the patents on the algorithm.
... Please be aware of the patent law in your own country with respect to using this code, as it is illegal in many places without a proper license from the patent holder.— freedesktop.org – dri/S3TC. Published by freedesktop.org. Retrieved 5 September 2014.
|
|
Based on this I would say that we do not make DDS textures default. In fact they should probably not have been added in the first place. :-(
Sorry if I am a party-pooper...
—Johan G (Talk | contribs) 01:06, 5 September 2014 (UTC)
|
|
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 — Mathias Fröhlich (2012-01-15). Re: [Flightgear-devel] DDS texures (Was: Improving random trees &.
(powered by Instant-Cquotes) |
|
Proposal for a change "on the fly" in the texture format
At the end of it all, I have always found problems when I used proprietary formats for my programming work. Consider the case of Java, a language with which development every day, when Sun was a lot of promises on possibility to open Java development, but when became property of Oracle all Java technology become closed source. Fortunately, common sense prevailed and was made the open version that I use daily as 90% of the developers. I think the best thing is not to generate constraints, but make our environment "flexible", ie that it can use either format, depending on the constraints present in a given country. I do not like to think that a user embargoed, such as an Iranian person, FGFS can not use because the DDS is part of a proprietary technology which can be banned for export.
In my work it is normal to try to make the system flexible. In this case I think it is better to write a few hundred lines of code in more and introduce a scheme like the one I included in the diagram:
The idea is simple, you can use various formats, such as SVG which is also very useful for liveries, when the format is read a process transforms it into the format you want to use for your graphics card, such as the DDS , PNG or S3TC, the transformation could also use an appropriate pixel density as a function of monitor used! The everything is sent to a cache that can only be in RAM or, as I often do, mixed RAM-HD according to the type of use. This approach allows to minimize the load of conversion and at the same time allows to have the images already ready for use. Normally a pilot flies in areas fairly restricted and then the cache may already contain all what interests him limiting in this way the load of the CPU. An index, if the cache is mixed RAM-HD can handle various things, such as whether a file has been updated and then redoing the conversion, manage LIFO etc ... This seems like a solution is not too complicated, but extremely flexible, which separates the authors of the texture from the problems of format and its licenses. When the cache is stabilized, the CPU load is very small compared with its other activities. Fact that I have always occurred when I implemented these features in Java. --Abassign (talk) 09:11, 6 September 2014 (UTC)