Talk:Switching default texture format to DDS

From FlightGear wiki
Jump to navigation Jump to search

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.
Johan G (Talk | contribs) 01:06, 5 September 2014 (UTC)
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 This is a link to a Wikipedia article 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 This is a link to a Wikipedia article 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:

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

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)

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

Proposal for a change input format "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:

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. --Abassign (talk) 09:11, 6 September 2014 (UTC)

about svg usefull for liveries: I'm not sure about. Of course, with canvas it would allow for new features (and I have many ideas, what can be done with... ;-)).
But svg-files aren't that cheap like a simple bitmap. I fear the more objects a svg-file has, the more computer ressource it will need. And a detailed livery will need a lot of objects. With canvas I already see a decrease of fps, and I'm not sure that only non-optimized nasal-scripts are the reason for.
But for .png and .jpg -files your approach sounds good, and I'm not sure if even X-Plane already uses this approach.
Cheers
--HHS (talk) 10:30, 6 September 2014 (UTC)
Gijs can probably help clarify things a little here, he mentioned several times on the forum that he's been using SVG for liveries IIRC. Obviously, a SVG file has "layers", that need to be rasterized each - with Canvas that means, that each layer becomes a "group". SVG parsing does happen in scripting space, but should normally only happen during intialization and not at run-time. Otherwise, all the groups/layers are pre-created and put into C++ data structures (CanvasElements) and directly handled by ShivaVG.
If you have doubts about the performance of Nasal/Canvas please post your code so that we can take a look - if you're right and your code is sufficiently optimized, then we can still use the Built-in Profiler to see why your code is triggering slow Nasal/Canvas code paths.
Also, it would help us if you could tell us exactly what aircraft/features you're referring to with regard to "I already see a decrease of fps" - there are varying examples of Nasal/Canvas code in FG, and generally only TheTom's code is sufficiently optimized - code like the NavDisplay is still relatively unoptimized, and even more so the Avidyne Entegra R9 code is not particularly optimized but doing a ton of stuff in Nasal that must be slow. Even if you're right, Canvas being "slow" now doesn't have to mean that Canvas will remain "too slow" in 2-3 release cycle.
Tom has already optimized several things, and I am sure we'll see more optimizations. But just making generic statements and stating assumptions obviously doesn't help improve the Canvas system. As could recently be seen on the devel list, we've had a fairly massive issues in the effects subsystem for years, tremendously slowing down effects (and FG as a whole) and even pointing at other subsystems - well informed bug reports are usually also dealt with, but just making generic claims isn't really helping anybody to check the merits of such statements.
Thus, it would make sense to use a heavily down-stripped test case, such as texturing the ufo this way to exclude other Nasal code from showing up in the profile. Let us know if you need help doing that. Thanks --Hooray (talk) 14:36, 6 September 2014 (UTC)
Excuse me, I'd insert the SVG format only as a simple example to understand the flexibility of my proposal. Canvas However I find it fantastic and definitely want to be taken to implement some instruments in the G91 we are doing. The basic concept is to clarify whether this proposal makes sense, and it may be the key to solving the problems of compatibility between formats. My proposal is an attempt to have the maximum flexibility in size of all the graphic objects in FGFs and make compatible the simulation environment of FGFs in any context. At this point I ask the question to those who can develop in C ++ for FGFs, what I'm proposing is practicable? And What I am proposing can solve the problem of non-free formats? --Abassign (talk) 19:29, 6 September 2014 (UTC)