Re: [Flightgear-devel] DDS usage in effects files
Hi, On Monday, July 16, 2012 07:20:32 Chris Forbes wrote: If DDS is not politically acceptable, there should be an alternative way of providing premipped textures. Mipmap generation is a *significant* portion of the load time, particularly on the nicer aircraft with large textures. Even something as simple as a bunch of PNGs concatenated from small to large mips. I do mostly see nvidias binary driver suffering from this problem. And to my experience there it really helps to switch off compression at all. As a workaround append --prop:/sim/rendering/texture-compression=off to the command line. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Hi, On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote: I can see a number of options to resolve this (and I'm sure there are more): The 4. Method that I can imagine is to 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. 3) Add a /sim/rendering/use-dds property, drop the file extensions from the effects files (and possibly materials.xml entries?) and add some logic to check this flag and search for .dds extensions, and failing that .png for images. Hmm, I could think of both solutions. Both have pros and cons. Greetings Mathias-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Hi, On Friday, July 13, 2012 21:20:33 Stuart Buchanan wrote: I can see a number of options to resolve this (and I'm sure there are more): Oh, I forgot in the previous mail: There is a 5. Solution: Provide premipmapped uncompressed dds files and compress them with something like gzip. Osg can handle this kind of thing I believe, it uses the gz plugin to uncompress and the dds plugin to do images from the dds byte stream. Hmm, need to double check... Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Mathias Fröhlich a écrit : ... 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. gluScaleImage does the usual job of blurring the texture to compute the mipmaps. The advantage of pre computed mipmaps (inside .dds or not) is that we can use better algorithms (http://en.wikipedia.org/wiki/Bicubic_interpolation or http://en.wikipedia.org/wiki/Lanczos_resampling) to generate them. Perhaps gluScaleImage could be upgraded with some more algorithms ; the original code was trying to be fast but this is perhaps useless nowadays if the code runs in a separate thread. HJ. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Hi, On Saturday, July 21, 2012 11:56:39 Harald Johnsen wrote: gluScaleImage does the usual job of blurring the texture to compute the mipmaps. The advantage of pre computed mipmaps (inside .dds or not) is that we can use better algorithms (http://en.wikipedia.org/wiki/Bicubic_interpolation or http://en.wikipedia.org/wiki/Lanczos_resampling) to generate them. Perhaps gluScaleImage could be upgraded with some more algorithms ; the original code was trying to be fast but this is perhaps useless nowadays if the code runs in a separate thread. Ok, I see. I did not look into the nvidia tool too close. If somebody wants to use something better then the proposed function, that's great. Also Fred has some nearest neighbour mipmapping code somewhere in simgear. Whenever somebody provides a good mipmapper, we should probably also use that everywhere we need this. I wanted to give a sketch of how this could be implemented without a huge effort programming wise. Well, for the computation time. I expect that we can observe this on startup. May be not too much, but this could be at least measurable. For really loading something new during the simulation, I think running this in a loader thread makes most of the runtime discussions about on cpu mipmapping cost mostly obsolete. What about solution 6 with (uncompressed premipmapped dds).gz? 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. Greetings Mathias -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Am 21.07.2012 um 11:56 schrieb Harald Johnsen hjohn...@evc.net: Mathias Fröhlich a écrit : ... 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. gluScaleImage does the usual job of blurring the texture to compute the mipmaps. How does that look with textures that should fit seamless? I'm really not sure if this has to be taken into account, but when I use automated blurring (with any algorithm) I always get the same problem, the images/mipmaps loose and you will see structures and lines in the renderer because the textures do not fit seamless anymore. That's something ugly I also encountered in flightgear now with new texture work showing up, but maybe this is some texture work done with gimp/dds and automated mipmap creation, wrong compression or whatever, I don't know exactly. But would be really nice to see the result of automated/built-in scaling. The advantage of pre computed mipmaps (inside .dds or not) is that we can use better algorithms (http://en.wikipedia.org/wiki/Bicubic_interpolation or http://en.wikipedia.org/wiki/Lanczos_resampling) to generate them. Perhaps gluScaleImage could be upgraded with some more algorithms ; the original code was trying to be fast but this is perhaps useless nowadays if the code runs in a separate thread. Speaking with experience from RL work it depends heavy in which direction you scale. Bicubic might be good for scaling up and when you don't have to much details in a textures, when you scale down and have much detail in a texture it might be better to use simple bilinear, or sophisticated lanczos? I just started to use lanczos with gdal for tiff scaling and the result is promising. Cheers, Yves HJ. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
If DDS is not politically acceptable, there should be an alternative way of providing premipped textures. Mipmap generation is a *significant* portion of the load time, particularly on the nicer aircraft with large textures. Even something as simple as a bunch of PNGs concatenated from small to large mips. -- Chris -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
A number of effects files use .dds textures, leading to error messages on the console. IIRC in the last release, we suppressed these error messages for the release, and I think we need to do something for for 2.8.0 as well. Of particular concern is terrain-default.eff which uses Textures.high/Terrain/snow3.dds. Some of the 2d Cirrus and Cirrocumulus models used by Advanced Weather also still refer to dds textures created by Vivian - these would also trigger warnings. I left them in since for me it's the same, some people reported better performance and I wasn't sure what the policy on dds textures now is. In case we want to remove those, the corresponding *.ac files have to be changed. Is there an opinion on that question either way? In any case, I would suppress the warnings for the release, as they seem to lead to a lot of confusion (see forum) and many people seem to attribute the dds warnings to any problems they're experiencing. Ultimately, I would perhaps prefer a solution where dds is only used when the user expresses an intention to do so, i.e. 3). * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
On Saturday 14 July 2012 06:22:06 Renk Thorsten wrote: In case we want to remove those, the corresponding *.ac files have to be changed. Is there an opinion on that question either way? * Thorsten This should be fixed too, as of now, in GIT. Hopefuly, warning messages (if left enabled) should appear only when specificaly using Materials/dds/materials.xml Regards Emilian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
Emilian Huminiuc wrote: Hopefuly, warning messages (if left enabled) should appear only when specificaly using Materials/dds/materials.xml Many thanks for working toward a proper solution, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
On Fri, Jul 13, 2012 at 9:20 PM, Stuart Buchanan wrote: Hi All, A number of effects files use .dds textures, leading to error messages on the console. IIRC in the last release, we suppressed these error messages for the release, and I think we need to do something for for 2.8.0 as well. Of particular concern is terrain-default.eff which uses Textures.high/Terrain/snow3.dds. Yes, I really should run a git pull origin master before writing emails :) Thanks Emilian! -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DDS usage in effects files
On Fri, 13 Jul 2012 21:20:33 +0100, Stuart wrote in message CAP3ntyuH1T=2ahOgcyGKj-y++EBwc7Q0qY8yHaqx=jT=p-p...@mail.gmail.com: Hi All, A number of effects files use .dds textures, leading to error messages on the console. ..last time I saw these .dds error messages fly by, the console wailed about 5 compressed .dds files that needed to be uncompressed, is there a recommended FG or FG-developer way to do this? ..googling, I only found this: http://www.flightgear.org/forums/viewtopic.php?f=17p=161857 and a bunch wont-fix bugs, was the .dds textures thrown out? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
