Re: [Flightgear-devel] terrain incompatibility with current terragear libs
On 11/05/2011 12:47 PM, Erik Hofman wrote: On Sat, 2011-11-05 at 13:23 +0100, Eric van den Berg wrote: Hello everyone, I am currently making some Terrain around ELLX using SRMT4 and CORINE data. For that I used a current (approx. two weeks old) terragear version, compiled against PLIB, OSG ans SIMGEAR of the same age. The Terrain generated works fine with current FG GIT, but gives errors with both FG 2.0 and 2.4. If starting on these tiles, FG hangs at start-up (indefinately) and flying to these tiles gives the error: We detected an error while reading the file. for each tile FG tries to load. So I re-compiled terragear against the FG 2.4.0 PLIB, OSG and SIMGEAR versions...problem solved. Terrain works for all FG versions again. Not sure if this is a known issue, so I thought I'd share, There have been changes to both TerraGear and SimGear to be able to handle more detailed terrain. I assume this is one of the side effects. Erik After some more testing I found out that my 'solution' can produce terrain and every FG version can handle it, but it is extremely ugly. Some textures are just kind of stretched on the vertex, like someone combed it. I guess it was just luck that current Terragear compiled with old Simgear, but it it doesn't work together in a way to make good terrain. Also not all tiles produced with the current Terragear/Simgear produce an error. Looks like only bigger files are effected. It also seems I am not the only one to have noticed this: http://www.flightgear.org/forums/viewtopic.php?f=5t=13240start=135 http://www.flightgear.org/forums/viewtopic.php?f=5t=13240start=135 I just checked with Christians EHAM terrain...looks like the same problem. So we now have a Terragear version that produces nice and more detailed terrain, but can only be seen with current GIT flightgear. As the fraction of people using older FG versions is large (95%?...just a guess, correct me if you have an accurate number) the current Terragear version is not going to find many users. Is there a way and/or will to fix the current Terragear / Simgear to be compatible with 2.4 and lower? Thanks, Eric -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrain incompatibility with current terragear libs
On 6 Nov 2011, at 09:43, Eric van den Berg wrote: So we now have a Terragear version that produces nice and more detailed terrain, but can only be seen with current GIT flightgear. As the fraction of people using older FG versions is large (95%?...just a guess, correct me if you have an accurate number) the current Terragear version is not going to find many users. Is there a way and/or will to fix the current Terragear / Simgear to be compatible with 2.4 and lower? Assuming we're only talking about the change to support larger (more detailed) BTG files, the situation is a little more intelligent, hopefully: - current tg/sg write either version '7' or version '10' files. Version 10 uses 32-bit indices, and will not be read by FG 2.0 or 2.4. But those FG versions should realise this, and reject loading the BTG file at all, since they will see version '10' and say, okay, I cannot read this. - current tg/sg writes version 7 files, *if the data will fit 16-bit indices*. So, for any tile that would previously have displayed correctly (no stretching / 'swirlies'), the result with the current code should be the same - we create a version 7 file, and 2.0 / 2.4 should load it. - I could easily add code, to force version 7, and hence reject 'large' files which exceed the index limits. However, this will make scenery generation more difficult, since you only discover the problem at the end of generating the tile, but to reduce the detail, means changing the input data... I suspect, people have been generating tiles slightly exceeding the 16-bit limit, for some time, but not noticing a few stretched textures in a few tiles, but now the code generates a 'correct', but incompatible BTG, which is noticeable. All of this is how the code should be working - of course there may be bugs :) James -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Textures sizes, DDS
Hi all I just noticed today that the textures folder in scenery growed from 50 MB to ~200 MB. But I don’t see that many new textures ? I read once here that the benefit from getting DDS is also we get smaller file sizes for the textures. But now I see textures like crop (and cropA) DDS files that take ~20 MB. Is this for testing purposes only, or do we use the space we get by splitting aircrafts in near future for the textures ? ;-) Cheers, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terrain incompatibility with current terragear libs
On 11/06/2011 11:43 AM, James Turner wrote: On 6 Nov 2011, at 09:43, Eric van den Berg wrote: So we now have a Terragear version that produces nice and more detailed terrain, but can only be seen with current GIT flightgear. As the fraction of people using older FG versions is large (95%?...just a guess, correct me if you have an accurate number) the current Terragear version is not going to find many users. Is there a way and/or will to fix the current Terragear / Simgear to be compatible with 2.4 and lower? Assuming we're only talking about the change to support larger (more detailed) BTG files, the situation is a little more intelligent, hopefully: - current tg/sg write either version '7' or version '10' files. Version 10 uses 32-bit indices, and will not be read by FG 2.0 or 2.4. But those FG versions should realise this, and reject loading the BTG file at all, since they will see version '10' and say, okay, I cannot read this. Well large files generated by current tg/sg (v10 I guess) are not loaded by 2.0 / 2.4, but hangs FG as well (CPU 100%). This prevents any other tiles from being loaded and from exiting FG the normal way. - current tg/sg writes version 7 files, *if the data will fit 16-bit indices*. So, for any tile that would previously have displayed correctly (no stretching / 'swirlies'), the result with the current code should be the same - we create a version 7 file, and 2.0 / 2.4 should load it. Understood. That is why smaller files create no problem at all FG versions... - I could easily add code, to force version 7, and hence reject 'large' files which exceed the index limits. However, this will make scenery generation more difficult, since you only discover the problem at the end of generating the tile, but to reduce the detail, means changing the input data... I can already do that I guess, compiling tg with 2.4 sg. But a fgfs-construct --force-version=7 option would be a good idea because most people want their scenery to be able to be used by everyone! An early warning / rejection system '16-bit limit exceeded, reduce input data' (or whatever) would be a good feature also. Or does the message Degenerate tri! do this already? I suspect, people have been generating tiles slightly exceeding the 16-bit limit, for some time, but not noticing a few stretched textures in a few tiles, but now the code generates a 'correct', but incompatible BTG, which is noticeable. All of this is how the code should be working - of course there may be bugs :) James Thanks for your answers James! Eric -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
Hello, I just noticed today that the textures folder in scenery growed from 50 MB to ~200 MB. But I don’t see that many new textures ? I read once here that the benefit from getting DDS is also we get smaller file sizes for the textures. But now I see textures like crop (and cropA) DDS files that take ~20 MB. Is this for testing purposes only, or do we use the space we get by splitting aircrafts in near future for the textures ? ;-) No one said, that the benefit of .dds is smaller file size! The benefit of .dds is, that it can be loaded much, much faster into Video-Ram as mipmaps can be saved directly into the texture. With other formats it has be done seperatly and that's slow. So perfomance has even increased with. Quality compared with other compressed texture-formats like .png is btw. much higher. And Mipmaps also allow some interesting effects which you can see when you enable the use of .dds-scenery-texture in FGFS. Btw. the size of the texture-folder is compared with the aircraft-folder really, really small. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
Am 06.11.11 13:50, schrieb Heiko Schulz: Quality compared with other compressed texture-formats like .png is btw. much higher. Hi Heiko What I am thinking about at the moment is: Where are the GPL origins of the new textures ? In the textures folder too ? And btw. there have been only 4 or 5 replacements/additions for covers and now the textures folder is 3 times bigger than for 2.4.0 release ... and when I start to work with the textures, changing some details and send some commits, where is the history of this folder going ? Aren’t we running into the same with git and textures soon? Just a technical question: I know it is not a big deal to convert new textures to .dds format, but when I want to start to work on textures should I convert back to another format and convert to dds again ? Or should I start with origins and where are this origins going to ? Cheers, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 9:10 AM, HB-GRAL flightg...@sablonier.ch wrote: Just a technical question: I know it is not a big deal to convert new textures to .dds format, but when I want to start to work on textures should I convert back to another format and convert to dds again ? Or should I start with origins and where are this origins going to ? DDS/DXT is lossy so in general you would want to use source textures of another (lossless) format and only convert to dds for final distribution. cheers -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
Am 06.11.11 15:22, schrieb Jacob Burbach: On Sun, Nov 6, 2011 at 9:10 AM, HB-GRALflightg...@sablonier.ch wrote: Just a technical question: I know it is not a big deal to convert new textures to .dds format, but when I want to start to work on textures should I convert back to another format and convert to dds again ? Or should I start with origins and where are this origins going to ? DDS/DXT is lossy so in general you would want to use source textures of another (lossless) format and only convert to dds for final distribution. cheers Hi Jacob Thanks, I will do so. And where do I find the lossless origins now in the repo ? Do the origins co-exist in the repo, as png, or as GIMP files ? Cheers, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
And btw. there have been only 4 or 5 replacements/additions for covers ... Thanks, I will do so. And where do I find the lossless origins now in the repo ? Do the origins co-exist in the repo, as png, or as GIMP files ? Ouch!! 1.) the whole .dds-texture are currently additional in 2.5.0 to the old .png-textures. When using FGFS you have to decide if you want to use .dds or .png via FGRun or comand line. 2.) there have been much, much more replacements/additions. The whole rwy-textures has been converted to .dds, and many other textures as well. 3.) this whole thing is part of current ongoing shader-effects and texture work, announced by Vivian and Emillian here on the list. This can bring us a improved translation shader, more realistic water-effects with ripples, foam etc. depending on wind and rain, a flutter-effect to flags, reflective rwys depending on rain In many cases the original files are the .png. And when new textures added as only .dds then take Gimp, add the .dds-plugin, open the file and see: this is the origin! ;-) Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [FGMAP] Request icon update
Hi all, Here is my first mail to the Flightgear-devel mailing list :) My first contribution is to ask an update on FGMAP project. I hope I use the good mailing list. Can you change the icon of the Robinson Raven II R44 ? Currently it use an aircraft icon, but the Raven is an heli ;) This is the new line to put in fgmap.js : var FGMAP_CRAFT_MODELS_HELI = [ bo105, sikorsky76c, ec135, r22, s76c, Lynx-WG13, S51-sikorsky, CH47, R22, apache-model, uh-1, uh60, OH-1, raven, clipper ];(clipper is the amphibious version of the raven) I have an other request : I participe to the Douglas DC-3 C47 developement and we would like to have our icon on MPMAP. I have create the red 40x40 icon available here : http://i49.servimg.com/u/f49/16/09/76/33/shadow10.png This is the new line to put in fgmap.js : var FGMAP_CRAFT_ICON_DOUGLAS = douglas/dc3; var FGMAP_CRAFT_MODELS_DOUGLAS = [ dc-3, dc-3-copilot, dc-3-psg1, dc-3-psg2, dc-3-psg3, dc-3-psg4, dc-3A ];Thanks in advance, Clément de l'Hamaide -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
Am 06.11.11 16:32, schrieb Heiko Schulz: And btw. there have been only 4 or 5 replacements/additions for covers ... Thanks, I will do so. And where do I find the lossless origins now in the repo ? Do the origins co-exist in the repo, as png, or as GIMP files ? Ouch!! Ouch ? 1.) the whole .dds-texture are currently additional in 2.5.0 to the old .png-textures. When using FGFS you have to decide if you want to use .dds or .png via FGRun or comand line. 2.) there have been much, much more replacements/additions. The whole rwy-textures has been converted to .dds, and many other textures as well. 3.) this whole thing is part of current ongoing shader-effects and texture work, announced by Vivian and Emillian here on the list. This can bring us a improved translation shader, more realistic water-effects with ripples, foam etc. depending on wind and rain, a flutter-effect to flags, reflective rwys depending on rain I am aware of this, almost. In many cases the original files are the .png. And when new textures added as only .dds then take Gimp, add the .dds-plugin, open the file and see: this is the origin! ;-) Ehrm, this is not a origin I guess, doing this 10 times with a .dds file you will end up with a mystery game instead of flightgear scenery ;-) But maybe I am wrong. Cheers, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
In many cases the original files are the .png. And when new textures added as only .dds then take Gimp, add the .dds-plugin, open the file and see: this is the origin! ;-) If your using dxt compression, which is why most people use dds, then it is NOT equal to the original image. Amount of degradation will depend on the image, resolution, type of dxt used, etc..but will never be the same or better quality. cheers -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Textures sizes, DDS
If your using dxt compression, which is why most people use dds, then it is NOT equal to the original image. Amount of degradation will depend on the image, resolution, type of dxt used, etc..but will never be the same or better quality. This applies to every texture file which use compression. So it belongs to .png, .rgb and .jpg as well. I never heard that anyone asked for the source here There is always a degradation, the question is, is it visible to human eyes? -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
Hello, Ouch ? This was regarding about your statement about the 4-5replacements/additionals and maybe I'm wrong, but I think I can read something between your lines. You are not happy with the conversion to .dds-files, right, though you didn't spoke out yet ? With .dds editing and reediting we will indeed have problems, as the qualitity will decrease each time, like you and Jacob said. That means we would need the original raw-texture-file in FGdata as well, which will increase file-size. I guess, that is what you want to say here, right? still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
One could argue that things like dds do not belong in the 'source' data distribution at all, but be generated automatically by some tool when building the 'release' data. For example content devs only work with, and check in/out source imagery, and then run the tool to generate the final dds imagery when needed, ie for testing or release. Many projects work this way, each in their own way, but of course require some set up and tools to make it work. If this would this be a good path for fgfs to try though, I cannot say. Maybe something to think about though. cheers --Jacob -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 11:23 AM, Heiko Schulz aeitsch...@yahoo.de wrote: If your using dxt compression, which is why most people use dds, then it is NOT equal to the original image. Amount of degradation will depend on the image, resolution, type of dxt used, etc..but will never be the same or better quality. This applies to every texture file which use compression. So it belongs to .png, .rgb and .jpg as well. I never heard that anyone asked for the source here There is always a degradation, the question is, is it visible to human eyes? Well, not quite-- PNG and SGI/RGB use non-lossy algorithms for compression-- when uncompressed you get back exactly what you put in. They don't degrade the data, so archiving in these formats is fine. Formats like JPG and DDS/DXT use the source data to generate a compressed version, but the new version can't be restored to the exact original data. (Try a comparison between original and compressed versions examined on the pixel level-- it's interesting and revealing.) This means these are not good formats for archiving source material that might be edited later. With lossy formats using high-quality, low-compression settings, you might not visually notice degradation on the first edit, but you will eventually see substantial differences on subsequent edits. Each time you edit from an new lossy-compression source, you lose information, but you do not with the algorithms used by PNG and SGI/RGB. On a personal note, I had a lot of trouble getting co-workers to stop archiving their source images as JPG files. It took a lot of explaining and re-explaining. ;) -Gary -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 7:50 AM, Heiko Schulz aeitsch...@yahoo.de wrote: Hello, I just noticed today that the textures folder in scenery growed from 50 MB to ~200 MB. But I don’t see that many new textures ? I read once here that the benefit from getting DDS is also we get smaller file sizes for the textures. But now I see textures like crop (and cropA) DDS files that take ~20 MB. Is this for testing purposes only, or do we use the space we get by splitting aircrafts in near future for the textures ? ;-) No one said, that the benefit of .dds is smaller file size! The benefit of .dds is, that it can be loaded much, much faster into Video-Ram as mipmaps can be saved directly into the texture. With other formats it has be done seperatly and that's slow. So perfomance has even increased with. Quality compared with other compressed texture-formats like .png is btw. much higher. And Mipmaps also allow some interesting effects which you can see when you enable the use of .dds-scenery-texture in FGFS. Btw. the size of the texture-folder is compared with the aircraft-folder really, really small. Heiko Adding to what Heiko mentioned: The main win for DDS, at least from a game design point of view, is the ability to maintain a kind of compression while loaded into the graphics memory. This is (as far as I know) unique to DDS/DXT. It uses an interesting technique where data is loaded as tiny unique blocks that are indexed and mapped to locations within the image as needed. The bottom line is that game designers can pack many more textures into large but still limited memory resources. DDS is relatively fast because it is natively supported by video cards. But if I remember right, for pure speed of loading it's hard to beat good-ol' RGB. -Gary -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
This topic raises a point about distribution of non-critical files. For example, my 1049H Constellation has a number of large files that aren't necessary for flying the plane. I have source PSDs for livery-makers, and Yakko's terrific How-to for flying the 1049H. Both are directly beneficial to interested Flightgear users, but not essential, and both sets are large files (10MB or so each) that would bloat the plane's base distribution. Currently these are maintained and available at my home site. Provided that all materials are GPL, it would be nice to attach them somehow to the plane as a kind of optional secondary download, a sort of 'developers kit'. Does this concept make any sense? Would it be too seldom-used to be worth it? Is it even possible? Or are others already way ahead of me on this kind of idea? I'll stop cluttering up the bandwidth now. :) -Gary -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, 6 Nov 2011, Gary Neely wrote: This topic raises a point about distribution of non-critical files. For example, my 1049H Constellation has a number of large files that aren't necessary for flying the plane. I have source PSDs for livery-makers, and Yakko's terrific How-to for flying the 1049H. Both are directly beneficial to interested Flightgear users, but not essential, and both sets are large files (10MB or so each) that would bloat the plane's base distribution. Currently these are maintained and available at my home site. Provided that all materials are GPL, it would be nice to attach them somehow to the plane as a kind of optional secondary download, a sort of 'developers kit'. Does this concept make any sense? Would it be too seldom-used to be worth it? Is it even possible? Or are others already way ahead of me on this kind of idea? Now that we have per-aircraft repositories I plan to add my source material (blender, svg, datcom, octave, gerris etc files) below a dev directory in the aircraft's repository. Probably further structured in FDM, models, ... subdirectories. If we use a small set of names (I'd suggest dev, development or src) for the base directory of such files it shouldn't be too hard to make the aircraft packaging script(s) omit these files from the release .zip files. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 3:03 PM, Gary Neely grne...@gmail.com wrote: The main win for DDS, at least from a game design point of view, is the ability to maintain a kind of compression while loaded into the graphics memory. This is (as far as I know) unique to DDS/DXT. There is a texture compression extension that is used to allow storing textures compressed in video memory. I don't know the details of compression used (could be vendor specific), or how it compares to dxt compression which gives you 4x or 8x compression levels though. With dds the artist has control of which compression type to use as well as specifying custom mip maps, which makes it the winner in my book. I see the real benefit of dds as the ability to use a much higher resolution for the same (usually less) memory cost, have user defined mip map images, and faster loading in many cases. Even though it is lossy format, it still allows for a much higher overall quality level with better resource usage in most cases. DDS is relatively fast because it is natively supported by video cards. But if I remember right, for pure speed of loading it's hard to beat good-ol' RGB. Loading dds from disk is usually quite quick due to not needing to decompress it into main memory, generate mip maps, etc. I can personally testify that osg/fgfs can load dds textures several magnitudes faster than the png counterpart...not sure about rgb. cheers --Jacob -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
Am 06.11.11 17:56, schrieb Heiko Schulz: Hello, Ouch ? This was regarding about your statement about the 4-5replacements/additionals and maybe I'm wrong, but I think I can read something between your lines. You are not happy with the conversion to .dds-files, right, though you didn't spoke out yet ? To be clear, I am really happy with .dds and all the new possibilities we get for a better graphics for models and the scenery. A-n-y-t-i-m-e ! ;-) But I didn’t spoke out what Gary, Jacob and Anders write here. This is exactly what I meant and it was no vote against every improvement of the old shaders where I contributed too. Me and myself would be very happy when we get a directory structure with origins (maybe still png’s, state: before compressing) and with deployed .dds files. For models, aircrafts and scenery textures. And when I think that i.e. in one HANGAR you can have only ONE src/dev directory for all your origins, but I will stop now ... I made a small test, taking the crop.dds (20.3 MB here): - crop.xcf (51.2 MB) - crop.xcf.zip (24.6 MB) - crop.png (14.5 MB) Cheers, Yves -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
I hope that all you guys involved in the dds transition use nvidia-texture-tools because: 1. It is Free/OpenSource and platform independent 2. The compression quality is much higher than with the dds-plugin for GIMP Also keep in mind that maybe there are users out there who use OpenSource graphics drivers that don't support S3TC yet because of patent issues. This is one more reason to keep uncompressed/lossless textures alongside with dds textures. Cheers -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 7:17 PM, Robert dogg...@googlemail.com wrote: I hope that all you guys involved in the dds transition use nvidia-texture-tools because: 1. It is Free/OpenSource and platform independent 2. The compression quality is much higher than with the dds-plugin for GIMP However, and correct me if I'm wrong, the nvidia tools do not let you use pre-defined mip maps do they? I prefer the nvidia tools if for no other reason than they are command line and I can easily script and automate batch jobs. But if you do need pre defined mip maps I don't believe you have a choice except the gimp plugin..on linux anyway. cheers -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
