Re: [Flightgear-devel] Adventures in dds
On Friday 25 March 2011 17:27:34 Rob Dosogne wrote: Just wanted to add that transparency is working with Alpha Exponent (DXT5) for me.. I'm using the latest Hudson build (Win7 x64) with fgdata cloned last night. I converted the F-16 liveries to DXT5, and used Alpha Exponent for the markings (which are mostly transparent). It looks ugly in the dds viewer, but in FG it works perfectly. Exterior texture load time on F-16 went from 20s to 1s in my case! I am using an old set of x64 OSG libs—don't know if that matters. I have no SDK installed to compile new ones (I probably should though). Final two cents: DDS is very much worth the relatively small increase in file size. cheers, Rob Another point in favor of .dds textures. They might be larger on disk, but can be compressed further by any archiver thus decreasing the package size, making it better for downloading. Png's as far as I know don't get compressed further. size test: --- iar80 base texture: png texture: size on disk 8.1MB - targzipped size 8.1MB dds texture: size on disk 21.3 MB - targzipped size 4.5MB --- complete IAR80 package: png textures: IAR80 zip size: 45MB dds textures: IAR80 zip size: 31.1MB --- (can be reduced further as not all the textures were converted so far). -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Just wanted to add that transparency is working with Alpha Exponent (DXT5) for me.. I'm using the latest Hudson build (Win7 x64) with fgdata cloned last night. I converted the F-16 liveries to DXT5, and used Alpha Exponent for the markings (which are mostly transparent). It looks ugly in the dds viewer, but in FG it works perfectly. Exterior texture load time on F-16 went from 20s to 1s in my case! I am using an old set of x64 OSG libs—don't know if that matters. I have no SDK installed to compile new ones (I probably should though). Final two cents: DDS is very much worth the relatively small increase in file size. cheers, Rob On Tue, Mar 22, 2011 at 8:36 AM, Heiko Schulz aeitsch...@yahoo.de wrote: With Gimp there is Alpha exponent (DXT5) available. The file opened in Gimp shows that transparency is perectly kept, but in FGFS it is not. Maybe just an issue with .dds by OSG? -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Mon, 2011-03-21 at 17:50 -0600, syd adams wrote: Interesting.I just did my own quick test ... converted 1 out of 3 livery (png) files to a dds with Gimp plugin .Had to flip the image vertically before converting. I changed liveries with the dialog , and the 2 png files took several seconds to change , the dds changed instantly.I saw no difference in quality , but the load time was impressive.The original png file is 158.6 KB , the dds is 16.8 MB.This should swell fgdata significantly , unless Tim does (hopefully) does the /Aircraft split... Maybe a better idea would be to use .dds as a local cached version of texture files but that requires instant conversion upon loading, and dds writing code. Erik -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Well that's exactly what I was proposing you to test, split the big texture into 9 smaller ones, thus making 1texture/model. If the graphic engine is somehow being stupid and forgets that it has already loaded that texture we should see a dramatic improvement in performance and loading time. I extracted one of the nine textures from a 1024x1024 sheet and placed in on an 512x512 sheet. By naive scaling this should improve the loading time by a factor 4 if it scales with texture size. The actual factor I observed was about 3.5 - so I guess that's a straight hit - the way this currently works, I'd be better off to split multi-texture files into as small units as possible. The performance once the objects are loaded is, as far as I could observe, not changed in any significant way. But I agree very much with Lauri that a clean solution which applies to all loaded textures would be preferable. With 1.9.1 there wasn't a big difference between placing pure .ac-models and .xml-wrapped models into scenery. Both had the same fps. Now it is different. The same number of .ac-models will give higher fps than the same number of wrapped .xmls. It turns out Heiko is partially right - my apologies. If I load the ac files only, it's so fast that I have to use a 100x100 configuration instead of 50x50 to measure the time properly. A 100x100 configuration of bare ac models loads in 15 seconds and renders with 13 fps. Of course, it's completely unusable for clouds, because since no hot animation is set, the clouds are solid, and they are non-rotated. With an xml wrapper like ?xml version=1.0? PropertyList pathtexturetest1.ac/path /PropertyList the loading time increases to a whopping 43 seconds and the framerate goes to 12 fps. If I add the full bells and whistles ?xml version=1.0? PropertyList pathtexturetest1.ac/path effect object-namerect/object-name inherits-fromEffects/clouds-thin/inherits-from /effect animation object-namerect/object-name enable-hot type=boolfalse/enable-hot /animation /PropertyList these numbers hardly change - I go to 11 fps and my loading time is unchanged. Somewhat surprisingly, all the matrix operations inside the shader are apparently a non-issue here. From past experience I know that a range animation within the xml wrapper is a performance killer though... So, something is clearly very odd here, I don't really think a bare xml wrapper *should* take so much resources... Interesting.I just did my own quick test ... converted 1 out of 3 livery (png) files to a dds with Gimp plugin .Had to flip the image vertically before converting. I changed liveries with the dialog , and the 2 png files took several seconds to change , the dds changed instantly.I saw no difference in quality , but the load time was impressive.The original png file is 158.6 KB , the dds is 16.8 MB.This should swell fgdata significantly , unless Tim does (hopefully) does the /Aircraft split... Here I would argue the other way - changing liveries is not a performance-critical task, it's not done regularly or on a per-frame basis, and as a user I usually don't mind if I have to wait for 3 seconds (on the other hand, I do mind waiting three seconds in flight for a cloud bank to be loaded). So in this case I'd stick with the png file. * Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Tuesday 22 March 2011 10:33:19 thorsten.i.r...@jyu.fi wrote: Interesting.I just did my own quick test ... converted 1 out of 3 livery (png) files to a dds with Gimp plugin .Had to flip the image vertically before converting. I changed liveries with the dialog , and the 2 png files took several seconds to change , the dds changed instantly.I saw no difference in quality , but the load time was impressive.The original png file is 158.6 KB , the dds is 16.8 MB.This should swell fgdata significantly , unless Tim does (hopefully) does the /Aircraft split... Here I would argue the other way - changing liveries is not a performance-critical task, it's not done regularly or on a per-frame basis, and as a user I usually don't mind if I have to wait for 3 seconds (on the other hand, I do mind waiting three seconds in flight for a cloud bank to be loaded). So in this case I'd stick with the png file. * Thorsten Hmm, I'd say it's rather critical when in place of one highly detailed airplane you can have about four with the same level of detail in the texture ;)., or a texture with doubled dimensions, thus having more detail ;)(since, as Gary said .dds files get loaded compressed in video RAM). Also there would be less (or maybe none) stuttering and freezes when somebody spawns in your area, and their plane gets loaded.(but that's multiplayer specific). Or maybe a groud texture that's 'twice' the size of the current ones? One other thing I've noticed, that with .dds files, (with or without pregenerated mipmaps) the blurring due to mipmap rendering is noticeable less pronounced. Of course, .dds isn't the answer to all our performance related troubles... and I don't think it should be used everywhere, but it has it's benefits in certain cases. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Tue, 2011-03-22 at 10:33 +0200, thorsten.i.r...@jyu.fi wrote: these numbers hardly change - I go to 11 fps and my loading time is unchanged. Somewhat surprisingly, all the matrix operations inside the shader are apparently a non-issue here. From past experience I know that a range animation within the xml wrapper is a performance killer though... XML files are a dog to decode into something useful, every XML node has to be processed recursively. It's nice for one time configuration files but I'm starting to wonder if they're that useful for anything more than that. Erik -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
I'd Certainly make a case at least for using .dds files with bc5 compression for normalmaps. We lose(?) the alpha channel in the normalmap, but the quality difference is huge. This needs a small tweak to the shader code: the normal extracted from the normalmap needs to be flipped. Maybe a parameter like the reflection map one, that if set true means we're using .dds bc5 and thus the normal needs to be flipped ? -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Emilian wrote On Tuesday 22 March 2011 00:57:07 Vivian Meazza wrote: Nope, doesn't work. But this does: Map the .png file onto the AC3D model as usual - convert the .png into .dds in XnView - load the .dds into AC3D No flipping of vertical required. Perhaps XnView flips it for us? Vivian Probably xnview sets the origin in the lower left (as is in OpenGL). Problem with .dds is that each tool used to convert the might set the origin where it wants :( So far I haven't found a way of specifying the origin... OK - here's what I have discovered: XnView converts to .dds, and doesn't require flipping, but AFAIKS it doesn't generate mipmaps either. The Gimp (with the dds plug-in) does require that the image is flipped vertically, but it does generate mipmaps. Either way I can observe no discernable difference in quality or performance using a 1024 x 1024 texture on my current .ac model. However, I haven't carried out any quantative tests. All very interesting, but I'm not sure how to proceed now. Back to .rgb perhaps? Vivian -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Hmm, I'd say it's rather critical when in place of one highly detailed airplane you can have about four with the same level of detail in the texture ;)., or a texture with doubled dimensions, thus having more detail ;)(since, as Gary said .dds files get loaded compressed in video RAM). Also there would be less (or maybe none) stuttering and freezes when somebody spawns in your area, and their plane gets loaded.(but that's multiplayer specific). Or maybe a groud texture that's 'twice' the size of the current ones? So far all I've seen, tried and heard indicates that dds may have an impact in the time it takes to load a texture, not on the time it takes to render it. Loading times are imho not performance critical unless it is a task you repeat over and over. If you load a cockpit texture once at startup, it's there, you don't reload it all the time. That basically goes for all textures having to do with the plane you're sitting in. The way I see it, loading times are a real performance issue only for external objects in the scenery. Well, and perhaps for multiplayer. But consider: Increasing aircraft texture size from 158 kb to 16 MB simply isn't viable - if that roughly scales, it means that FGData would go from 4 GB to 400 GB (!) - I barely have the harddisk to store that, having access to a university T3 connection I also have the bandwidth to transfer it assuming the server can keep up - but I doubt so many others have. If that means I have to wait 3 seconds for a livery change instead of getting it immediately, then fine with me, I'd stick with the 4GB. * Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Tuesday 22 March 2011 11:29:04 Vivian Meazza wrote: Vivian, OK - here's what I have discovered: XnView converts to .dds, and doesn't require flipping, but AFAIKS it doesn't generate mipmaps either. The Gimp (with the dds plug-in) does require that the image is flipped vertically, but it does generate mipmaps. Either way I can observe no discernable difference in quality or performance using a 1024 x 1024 texture on my current .ac model. However, I haven't carried out any quantative tests. All very interesting, but I'm not sure how to proceed now. Back to .rgb perhaps? Vivian Compare livery loading time, between a .png (or .rgb), and .dds livery. You can also notice decreased texture blurring at extreme angles (probably due to better mipmap generation from .dds, or better quality pregenerated mipmaps embeded in the .dds). The most noticeable quality improvement is on normalmaps, so if you're not using any you won't notice it.. take a look here for a simple comparison of the same normalmp texture (once loaded as .png and then as .dds): http://flightgear.org/forums/viewtopic.php?p=118547sid=b3fd401bbab73e70d3b4031ec1c02030#p118547 -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Tuesday 22 March 2011 11:43:06 thorsten.i.r...@jyu.fi wrote: Increasing aircraft texture size from 158 kb to 16 MB simply isn't viable - if that roughly scales, it means that FGData would go from 4 GB to 400 GB (!) - I barely have the harddisk to store that, having access to a university T3 connection I also have the bandwidth to transfer it assuming the server can keep up - but I doubt so many others have. If that means I have to wait 3 seconds for a livery change instead of getting it immediately, then fine with me, I'd stick with the 4GB. * Thorsten I haven't seen such a dramatic increase in filesize, if that's the case maybe the texture is in fact just one colour? The most dramatic increase I see is from 3.5MB to 21.3 MB (we're talking 4096x4096 textures here), and that's probably a texture I wouldn't convert. For small files it might even decrease in size... (with mipmaps all included). But, as I've said.. I'm not arguing for a complete conversion here, I'm just saying there are benefits in using these compressed textures... most important for me being the increased quality in bumpmapping... Btw: is there a way to monitor Video RAM usage in fgfs or osg ? -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Tuesday 22 March 2011 14:12:45 Heiko Schulz wrote: Hi, I'd Certainly make a case at least for using .dds files with bc5 compression for normalmaps. We lose(?) the alpha channel in the normalmap, but the quality difference is huge. So much as I know is there a mode available, which does not lose the alpha channel. At least what I can remember from reading about MSFS. Heiko There is bc3n, but so far I haven't managed to make it behave... :( -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Hi, Heiko There is bc3n, but so far I haven't managed to make it behave... :( With Gimp there is Alpha exponent (DXT5) available. The file opened in Gimp shows that transparency is perectly kept, but in FGFS it is not. Maybe just an issue with .dds by OSG? Where are our OSG/ Graphic specialists when we need them? -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Tuesday 22 March 2011 14:36:12 Heiko Schulz wrote: Where are our OSG/ Graphic specialists when we need them? Probably scared of the coup we're trying to stage here :P... .. whoops, I've revealed our supa' sikrit plan :D -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Heiko Schulz wrote: Where are our OSG/ Graphic specialists when we need them? Hehe, that's a matter of 'housekeeping': If you're in need of specialists, make sure to care for them, don't scare them away ;-) Have fun, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Am 22.03.11 13:36, schrieb Heiko Schulz: Where are our OSG/ Graphic specialists when we need them? Just found: http://www.mail-archive.com/osg-submissions@lists.openscenegraph.org/msg06199.html Cheers, gral -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Okay, to summarize what I take from the discussion and all the tests: 1) Texture types: png seems to be best for load-once, then-keep problems because it has the smallest filesize, but takes a lot of time to load. dds seems to work well for some problems, possibly those involving opaque textures - here loading times can be reduced at (un?)-reasonable cost of file size. For my particular problem involving transparent textures, rgb seems to work best, so I keep it. The decision what format to use is not a 'one fits all' but must be made according to situation. 2) Texture cache: It seems clear, both by experiment and by Lauri's investigation that such a thing doesn't exist for models loaded from Nasal, possibly also other situations. If we had it, it would speed part of my code by factors O(100). So I'd seriously like to have it... However, since I can't do it myself, the alternative is to live with 'each model reloads the texture'. In this case, splitting multi-model texture sheets into one sheet for each model would possibly gain a factor 3 in speed - which is much less than a factor 100, but much better than 1. Thus, I'd like to know if somebody would be working on a general texture cache system in the future - if not, then I split texture sheets, that's messy but at least a bit faster. 3) xml: Somehow, xml wrappers are extremely bad. However, due to the need to make clouds immaterial and give them a dedicated shader, it's not an option to load the bare ac file. If anyone comes up with a faster way of passing this information, then I'll gladly use it - but for the time being I guess I am stuck with xml wrappers even if that means reduced performance. Using multi-layered models might help here, as then there's only a single xml wrapper to be parsed for 2 or more texture sheets, so maybe a factor 2 is possible here. So, all in all, one can come up with a number of ugly workarounds which would help a bit, although a texture cache for models loaded from Nasal would be the 'big thing' needed here. * Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
I think there are a couple more points to consider with .dds format: a) you can pregenerate the lower mip-map levels using a higher quality algorithm than the simple box-filter OSG provides when it generates them on the fly. This can often lead to noticeably better looking models. b) The compressed dds format can be loaded into the video card and the data can be kept in a compressed format on the card itself, saving texture ram. c) png is smaller on disk, that's probably it's only benefit ... but jpg would be even smaller at reasonable compression levels. Load times are longer, most likely because the system is forced to compute the mip-maps on the fly when the texture is loaded. One other comment. I *thought* at one point we could load a single xml reference model with animations and stuff, and then insert it many times into the scene graph where ever we wanted (and only one copy would actually exist with appropriate ref counting so it wasn't deleted until the last one is removed from the scene graph.) For some critical models we used to bump up the ref count by one when we first loaded it so the model was never removed. Perhaps this ability went away when we converted to OSG, or maybe some subtle nuance of that changed? For clouds it would make perfect sense to load a library of individual cloud fragment models, and then insert a reference to those individual models into the scene graph ... but that may not be possible though the nasal model loading and positioning interface. Regards, Curt. On Tue, Mar 22, 2011 at 12:50 PM, thorsten.i.r...@jyu.fi wrote: Okay, to summarize what I take from the discussion and all the tests: 1) Texture types: png seems to be best for load-once, then-keep problems because it has the smallest filesize, but takes a lot of time to load. dds seems to work well for some problems, possibly those involving opaque textures - here loading times can be reduced at (un?)-reasonable cost of file size. For my particular problem involving transparent textures, rgb seems to work best, so I keep it. The decision what format to use is not a 'one fits all' but must be made according to situation. 2) Texture cache: It seems clear, both by experiment and by Lauri's investigation that such a thing doesn't exist for models loaded from Nasal, possibly also other situations. If we had it, it would speed part of my code by factors O(100). So I'd seriously like to have it... However, since I can't do it myself, the alternative is to live with 'each model reloads the texture'. In this case, splitting multi-model texture sheets into one sheet for each model would possibly gain a factor 3 in speed - which is much less than a factor 100, but much better than 1. Thus, I'd like to know if somebody would be working on a general texture cache system in the future - if not, then I split texture sheets, that's messy but at least a bit faster. 3) xml: Somehow, xml wrappers are extremely bad. However, due to the need to make clouds immaterial and give them a dedicated shader, it's not an option to load the bare ac file. If anyone comes up with a faster way of passing this information, then I'll gladly use it - but for the time being I guess I am stuck with xml wrappers even if that means reduced performance. Using multi-layered models might help here, as then there's only a single xml wrapper to be parsed for 2 or more texture sheets, so maybe a factor 2 is possible here. So, all in all, one can come up with a number of ugly workarounds which would help a bit, although a texture cache for models loaded from Nasal would be the 'big thing' needed here. * Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list
Re: [Flightgear-devel] Adventures in dds
On Mon, 2011-03-21 at 13:15 +0200, thorsten.i.r...@jyu.fi wrote: ... and the winner is: The rgb format. To be honest I was expecting this but didn't have proof for it. Remember that the RGB format was developed by Silicon Graphics to be used for OpenGL and it probably resembled at least the internal format used by SGI back then. Erik -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On 21 Mar 2011, at 11:15, thorsten.i.r...@jyu.fi wrote: rgb: filesize 1.7 MB, time to appear 12 s, framerate for rendering 32 fps png: filesize 0.8 MB, time to appear 135 s (!), framerate for rendering 21 fps dds: filesize 1.1 MB, time to appear 13 s, framerate for rendering 20 fps I have also tried other dds options, some didn't even render properly, and none was better than the bc3 shown here. Maybe you already did this, but this needs a 'average of 3' (or 5) tests, because I would be very surprised if the input file format changes the final frame-rate after loading - it's all uncompressed to the same format in GPU memory, as far as I know. The PNG loading time also seems suspicious - decompressing a PNG is certainly more work than RGB or DDS, but decompressing a 1MB PNG shouldn't take even one second on a computer of the past few years. James -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
I've been doing some tests with dds textures too, only in the airplane models, and there's an increase in both performance and quality. Take the IAR-80 for example, changing liveries with .png textures takes ~6 seconds, while with the dds texture it takes ~2seconds. The increase in file size is of about one third: .png - ~12.5 MB .dds - 16 MB But what nails it for me is the quality of the normalmap effect, wich for the same texture shows a dramatic improvement. You may want to check this post I've made yesterday on the forums for some visual comparisons: http://flightgear.org/forums/viewtopic.php?p=118570#p118570 Is it just me, or is the graphic engine performing some kind of cheap texture compression? (Maybe that's why you did't notice any performance improvement). -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
woops sorry, link was to the last post instead of the right one: http://flightgear.org/forums/viewtopic.php?p=118547#p118547 -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Maybe you already did this, but this needs a 'average of 3' (or 5) tests, because I would be very surprised if the input file format changes the final frame-rate after loading - it's all uncompressed to the same format in GPU memory, as far as I know. Yes, I checked it (I couldn't believe it...). Just *maybe* the conversion by gimp screwed the pnd file and altered the texture somehow, so that all derived from the png is then problematic (?). But the effect as far as my procedure is described is real. The PNG loading time also seems suspicious - decompressing a PNG is certainly more work than RGB or DDS, but decompressing a 1MB PNG shouldn't take even one second on a computer of the past few years. Yes - now multiply this by 2500 since it's done for every cloud being loaded, and you get a large number. Of course the system *should* realize that it has the texture loaded already and doesn't need to load it any more, but evidence suggest that it actually decompresses 2500 times. Cheers, * Thorsten -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Here is one thing to consider when dealing with texture files, OpenGL, and scene graphs (like OSG or PLIB.) OpenGL has a concept called mip-mapping. When a texture is loaded, successively smaller versions are generated automatically using a simple box filter. So if you start with a 256x256 original texture, the system builds a 128x128, 64x64, 32x32 ... etc. down to a 1x1 I believe. For each smaller version, 1 pixel is the average of 4 pixels in the next size up. This scheme works pretty ok for most picture type textures and it happens automatically so artists don't have to worry about it. Then when rendering a scene, the opengl system automatically chooses the mipmap level (texture size) that best fits the triangle it is getting applied to ... has a closest to 1-to-1 match with screen space pixels. This helps prevent aliasing artifacts or texture swimming effects that you might remember from older games. Where this can lead to problems is with textures that have transparency (i.e. an alpha channel.) The box filter scheme of generating successively smaller versions of the texture doesn't work well with the alpha layer. The transition from fully opaque to fully transparent gets wider and wider relative to the overall texture and can lead to problems. More generally, the default box filter scheme of generating the smaller versions of the texture files is very simple and usually not quite optimal, and is definitely non-optimal when working with textures that have a transparency layer. In addition, the mipmaps are generally computed in software when the texture is loaded which takes some time. I suspect that some of these fancier formats might have the mipmap layers pre-computed using a more sophisticated size reducing scheme -- thus producing slightly better visual results in the end. Regards, Curt. On Mon, Mar 21, 2011 at 9:14 AM, thorsten.i.r...@jyu.fi wrote: Maybe you already did this, but this needs a 'average of 3' (or 5) tests, because I would be very surprised if the input file format changes the final frame-rate after loading - it's all uncompressed to the same format in GPU memory, as far as I know. Yes, I checked it (I couldn't believe it...). Just *maybe* the conversion by gimp screwed the pnd file and altered the texture somehow, so that all derived from the png is then problematic (?). But the effect as far as my procedure is described is real. The PNG loading time also seems suspicious - decompressing a PNG is certainly more work than RGB or DDS, but decompressing a 1MB PNG shouldn't take even one second on a computer of the past few years. Yes - now multiply this by 2500 since it's done for every cloud being loaded, and you get a large number. Of course the system *should* realize that it has the texture loaded already and doesn't need to load it any more, but evidence suggest that it actually decompresses 2500 times. Cheers, * Thorsten -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Hello, Where this can lead to problems is with textures that have transparency (i.e. an alpha channel.) The box filter scheme of generating successively smaller versions of the texture doesn't work well with the alpha layer. The transition from fully opaque to fully transparent gets wider and wider relative to the overall texture and can lead to problems. More generally, the default box filter scheme of generating the smaller versions of the texture files is very simple and usually not quite optimal, and is definitely non-optimal when working with textures that have a transparency layer. In addition, the mipmaps are generally computed in software when the texture is loaded which takes some time. So this is the explanantion of decreasing fps with textures with transparency? Comparing with other games/sims I'm surprised that it is so much noticeable in FGFS. I suspect that some of these fancier formats might have the mipmap layers pre-computed using a more sophisticated size reducing scheme -- thus producing slightly better visual results in the end. Slightly? Have you seen the pictures comparing .png vs .dds? This is more than slightly! Indeed .dds creates mipmap layers while converting to it. The qualitity is much better, loading seems to be much smaller compared with .png. Indeed nearly all commercial games and sims uses .dds. The only disadvantage I can see and that's why I never considered yet to use it is the fact that the size itself is increasing. As we have people here which consider space saving more important than qualitity I feared that it could lead to problems. Regards Heiko Regards, Curt. On Mon, Mar 21, 2011 at 9:14 AM, thorsten.i.r...@jyu.fi wrote: Maybe you already did this, but this needs a 'average of 3' (or 5) tests, because I would be very surprised if the input file format changes the final frame-rate after loading - it's all uncompressed to the same format in GPU memory, as far as I know. Yes, I checked it (I couldn't believe it...). Just *maybe* the conversion by gimp screwed the pnd file and altered the texture somehow, so that all derived from the png is then problematic (?). But the effect as far as my procedure is described is real. The PNG loading time also seems suspicious - decompressing a PNG is certainly more work than RGB or DDS, but decompressing a 1MB PNG shouldn't take even one second on a computer of the past few years. Yes - now multiply this by 2500 since it's done for every cloud being loaded, and you get a large number. Of course the system *should* realize that it has the texture loaded already and doesn't need to load it any more, but evidence suggest that it actually decompresses 2500 times. Cheers, * Thorsten -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson:http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -Integrierter Anhang folgt- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -Integrierter Anhang folgt- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Mon, Mar 21, 2011 at 9:52 AM, Heiko Schulz wrote: So this is the explanantion of decreasing fps with textures with transparency? Comparing with other games/sims I'm surprised that it is so much noticeable in FGFS. No, this is another issue I believe. When the opengl system draws a triangle with a texture that has some transparency, it needs to read back in the current color buffer and mix the pixels of the new surface with the pixels that have already been drawn before. This takes longer (sometimes *much* longer) than just writing out solid pixels. If you dig into how modern 3d hardware works, you'll fine a lot of parallelization and multiple cores. Your 3d card is really a whole computer itself. OpenGL is carefully designed so that the application can send a set of commands to the hardware and the hardware figures out the best way to render them. The problem with alpha textures is that they can disrupt the fastest pipeline operations, certain draw commands need to finish before the next one can start. I don't know if there are good ways to avoid this other than to try to minimize the amount of transparency we use. Clouds are especially bad because we stack many many layers of partially transparent surfaces on top of each other and we end up having to render the same pixels on the screen many many times over ... and do that with a slower, harder-to-optimize rendering path. There are probably tricks that could be used. I recently saw a demo engine (used for benchmarking graphics cards and systems). I forget the name now, but it was amazing. I need to start learning some of their tricks ... blades of grass waving in the breeze with dynamic shadows being cast over them from everything else in the scene ... beautiful clouds, amazing lighting effects, really cool and realistic material surface effects (like weathered/beaten metal fittings on a ship, etc.) They didn't do any reflection/glass effects though in that demo so we had them beat there. :-) The only disadvantage I can see and that's why I never considered yet to use it is the fact that the size itself is increasing. As we have people here which consider space saving more important than qualitity I feared that it could lead to problems. Most likely due to the fact that it is storing all the smaller versions of the texture along with the original ... that makes sense though because if it didn't store the mipmaps, then we'd be back to the same low quality default box filter. These days I tend to lean towards the disk space is cheap camp. (But anything taken to it's extreme is probably not good.) Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/http://www.flightgear.org/blogs/category/personal/curt/ -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Just to add to the fun, .dds has an added benefit that I didn't see mentioned here-- unlike other formats, .dds has the ability to store textures compressed in memory, not just on disk. This can result in a considerable savings of graphic card RAM. Most .dds formats are lossy though, which requires some consideration and care. The .dds format is natively supported on graphics cards, which accounts for much of the speed given all that is happening. I'm not particularly advocating .dds, but it's worth considering for certain applications, especially where large numbers of textures are used for a similar task. -Gary aka Buckaroo -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Regarding mipmaps, all the pictures in the post on the forum are done without mipmaps in the dds (-nomips option in nvcompress). Just done a couple more tests, this time with pregenerated mipmaps, and texture loading time when switching liveries is 1s, with instant swithcing in subsequent runs (the first time i suspect the delay to be in fact the disk read wich is slow). So much of the texture loading time is in fact spent by the gpu (or cpu?) in genertaing mipmaps from the texture.. time we can spend just once when creating the texture. (This is done with a big 4096x4096 texture ;) ) With the clouds issue, I have this feeling that something is amiss with the way clouds are generated, but i can't put my finger on it.. :(. Thorsten, have you done the same test with individual textures instead of a big one ? -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Hi, So much of the texture loading time is in fact spent by the gpu (or cpu?) in genertaing mipmaps from the texture.. time we can spend just once when creating the texture. (This is done with a big 4096x4096 texture ;) ) Yep, texture size is higher at the end, but perfomance is better. And I guess the latter is more important in my eyes. With the clouds issue, I have this feeling that something is amiss with the way clouds are generated, but i can't put my finger on it.. :(. Thorsten, have you done the same test with individual textures instead of a big one ? Taking a closer look on the Local Weather, I can see that each cloud is placed per .xml. Or better said: you can take the UFO and place each of the clouds in the scenery. But the fact is, the more .xml has to be loaded the more slower FGFS runs. That's one issue behind making Paris unusuable for most of our users. Heiko -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
With the clouds issue, I have this feeling that something is amiss with the way clouds are generated, but i can't put my finger on it.. :(. Thorsten, have you done the same test with individual textures instead of a big one ? Huh? Not sure what you mean, I don't think I have a single instance of just one cloud on a texture. altocumulus_textures.rgb is a sheet containing 9 different textures referenced by 10 distinct 2-layer *.ac models - all of which are part of the 2500 cloud sheet being generated. So the sheet contains about ~250 identical copies of each of the 10 distinct models. Can you be more specific what you'd like to test. Taking a closer look on the Local Weather, I can see that each cloud is placed per .xml. Or better said: you can take the UFO and place each of the clouds in the scenery. Quite so. But the fact is, the more .xml has to be loaded the more slower FGFS runs. That's one issue behind making Paris unusuable for most of our users. That's (at best) part of the issue: When I replace the rgb by a png or dds texture, the xml wrapper stays the same - and yet I see 1/3 difference in rendering speed of the final result and dramatic differences in loading speeds. I don't know what that has to do with xml - it seems generic that if I increase the number of objects to render, the framerate drops. I can see the same thing with trees (which to my knowledge are not xml-wrapped models) - if I increase tree density by a factor 10, I see my framerate drop like a rock. 5000 additional models in the scenery will affect framerate, quite possibly inversely proportional to their texture quality and proportional to the operations required by the relevant shader - regardless if that's houses or clouds. The system (as far as my experience goes) isn't particularly slow in rendering the clouds once they are in the scene. It is slow in placing them into the scene - dramatically slower (a factor 1000 or so) than with the standard 3d clouds. If you want to call that 'wrong' is in the eye of the beholder - that's how the interface for model placement from Nasal is at present. That slowdown for sure is generic for the way models are placed from Nasal - something appears to be *very* inefficient with that. I am rather skeptical if it's to be blamed on the xml wrapper - I see no supporting evidence. The dependence on texture type and detail level suggests to me that it's about uncompressing and loading textures into the GPU memory. As a side note, loading speeds depend on the presence/absence of a second available CPU. Not sure what that means. My problem is that I have no real knowledge about 3d rendering. I can do the experiments and know what scales with what, but I lack the theory to understand what is going on behind the scenes. * Thorsten -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Monday 21 March 2011 19:53:36 thorsten.i.r...@jyu.fi wrote: With the clouds issue, I have this feeling that something is amiss with the way clouds are generated, but i can't put my finger on it.. :(. Thorsten, have you done the same test with individual textures instead of a big one ? Huh? Not sure what you mean, I don't think I have a single instance of just one cloud on a texture. altocumulus_textures.rgb is a sheet containing 9 different textures referenced by 10 distinct 2-layer *.ac models - all of which are part of the 2500 cloud sheet being generated. So the sheet contains about ~250 identical copies of each of the 10 distinct models. Can you be more specific what you'd like to test. Well that's exactly what I was proposing you to test, split the big texture into 9 smaller ones, thus making 1texture/model. If the graphic engine is somehow being stupid and forgets that it has already loaded that texture we should see a dramatic improvement in performance and loading time. (instead of loading one big texture thousand of times, we're loading smaller bits of it). If the performance stays the same, that means the problem lies elsewhere in the model placement pipeline. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Hello, I don't know what that has to do with xml - it seems generic that if I increase the number of objects to render, the framerate drops. I can see the same thing with trees (which to my knowledge are not xml-wrapped models) - if I increase tree density by a factor 10, I see my framerate drop like a rock. 5000 additional models in the scenery will affect framerate, quite possibly inversely proportional to their texture quality and proportional to the operations required by the relevant shader - regardless if that's houses or clouds. With 1.9.1 there wasn't a big difference between placing pure .ac-models and .xml-wrapped models into scenery. Both had the same fps. Now it is different. The same number of .ac-models will give higher fps than the same number of wrapped .xmls. The system (as far as my experience goes) isn't particularly slow in rendering the clouds once they are in the scene. It is slow in placing them into the scene - dramatically slower (a factor 1000 or so) than with the standard 3d clouds. If you want to call that 'wrong' is in the eye of the beholder - that's how the interface for model placement from Nasal is at present. Hmm... I did not have found time for a detailed table of fps comparement, but it seems to me that some of your clouds are decreasing fps more than the default 3d-clouds. It looked different to me at the beginning, but making some videos showed me this. That slowdown for sure is generic for the way models are placed from Nasal - something appears to be *very* inefficient with that. I am rather skeptical if it's to be blamed on the xml wrapper - I see no supporting evidence. The dependence on texture type and detail level suggests to me that it's about uncompressing and loading textures into the GPU memory. If I'm right, .xmls and nasal are handeld by the CPU. The Default clouds are mostly done by the GPU. Heiko -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Hmm... I did not have found time for a detailed table of fps comparement, but it seems to me that some of your clouds are decreasing fps more than the default 3d-clouds. It looked different to me at the beginning, but making some videos showed me this. If you use default settings, you're comparing 20 km visibility with 35 km - that's 400 km^2 vs 1225 km^2 of cloud covered scene, or a factor 3. If you place the same number of clouds, I guess the fact that I use sometimes ~4 times higher texture resolution is bound to show. You possibly initially saw higher framerates around TNCM because Local Weather doesn't place many convective clouds over open water. I decided that a fair comparison is: Same scenery, same visibility, same cloud visibility, same cloud coverage in oktas, no wind drift. Under these conditions, local weather was 10% slower for a Cumulus layer in my tests. If you ask for overcast skies, than Local Weather is dramatically faster (the default clouds for me are unable to even render a decent 6/8 cover, and with the densest coverage I can get I get single digit framerates while passing through the layer - that's a factor 3 or more slower than Local Weather where I routinely get 20+ fps in rainy overcast conditions, more above the layer where the terrain isn't visible ). If you fly supersonic, then you're not dominated by rendering but by loading/unloading... and so on. So it's not clear to me what your standard of comparison is, and it's not a trivial question what it should be. But some cloud configurations (Coldfront, Tropical) are much slower than the standard 3d cloud Cumulus layer. But that's an apples/oranges comparison if you ask me. * Thorsten -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Heiko wrote, I don't know what that has to do with xml - it seems generic that if I increase the number of objects to render, the framerate drops. I can see the same thing with trees (which to my knowledge are not xml-wrapped models) - if I increase tree density by a factor 10, I see my framerate drop like a rock. 5000 additional models in the scenery will affect framerate, quite possibly inversely proportional to their texture quality and proportional to the operations required by the relevant shader - regardless if that's houses or clouds. With 1.9.1 there wasn't a big difference between placing pure .ac-models and .xml-wrapped models into scenery. Both had the same fps. Now it is different. The same number of .ac-models will give higher fps than the same number of wrapped .xmls. The system (as far as my experience goes) isn't particularly slow in rendering the clouds once they are in the scene. It is slow in placing them into the scene - dramatically slower (a factor 1000 or so) than with the standard 3d clouds. If you want to call that 'wrong' is in the eye of the beholder - that's how the interface for model placement from Nasal is at present. Hmm... I did not have found time for a detailed table of fps comparement, but it seems to me that some of your clouds are decreasing fps more than the default 3d-clouds. It looked different to me at the beginning, but making some videos showed me this. That slowdown for sure is generic for the way models are placed from Nasal - something appears to be *very* inefficient with that. I am rather skeptical if it's to be blamed on the xml wrapper - I see no supporting evidence. The dependence on texture type and detail level suggests to me that it's about uncompressing and loading textures into the GPU memory. If I'm right, .xmls and nasal are handeld by the CPU. The Default clouds are mostly done by the GPU. I still have some old textures in Git that I have not yet changed over to .png. Do I take it from these discussions that it would be best to leave them as is? I'm right in the middle of texturing a new model. .dds is not an option because it looks as if the loader has some co-ordinate issues. It looks OK in AC3D, but when loaded in FG it's wrong. Should I revert to .rgb rather than use .png? Vivian -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Vivian, I'm right in the middle of texturing a new model. .dds is not an option because it looks as if the loader has some co-ordinate issues. It looks OK in AC3D, but when loaded in FG it's wrong. Should I revert to .rgb rather than use .png? Vivian You have to flip the .dds-texture vertically after converting to it. That's due to OpenGL. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Heiko, -Original Message- From: Schulz [mailto:aeitsch...@yahoo.de] Sent: 21 March 2011 20:35 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Adventures in dds Vivian, I'm right in the middle of texturing a new model. .dds is not an option because it looks as if the loader has some co-ordinate issues. It looks OK in AC3D, but when loaded in FG it's wrong. Should I revert to .rgb rather than use .png? Vivian You have to flip the .dds-texture vertically after converting to it. That's due to OpenGL. A simple vertical flip doesn't seem to work - it looks a bit more like a scaling issue here. Perhaps I need some tool? Vivian -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Monday 21 March 2011 23:02:18 Vivian Meazza wrote: A simple vertical flip doesn't seem to work - it looks a bit more like a scaling issue here. Perhaps I need some tool? Use nvcompress from the nvidia-texture-tools: i.e. nvcompress -bc3 -repeat your-flipped-texture.png your-texture.dds If it's a normalmap use : nvcompress -normal -bc5 -repeat your-flipped-texture.png your-texture.dds but you'll have to flip the normal in the shader. i.e. for the reflect-bump-spec.frag add a line after line 47: n = -n; HTH Emilian -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
A simple vertical flip doesn't seem to work - it looks a bit more like a scaling issue here. Perhaps I need some tool? Vivian Maybe this helps you: http://www.flightgear.org/forums/viewtopic.php?f=4t=7225start=135#p118570 -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Heiko, Vivian, I'm right in the middle of texturing a new model. .dds is not an option because it looks as if the loader has some co-ordinate issues. It looks OK in AC3D, but when loaded in FG it's wrong. Should I revert to .rgb rather than use .png? Vivian You have to flip the .dds-texture vertically after converting to it. That's due to OpenGL. Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian That's exactly what me and Heiko were saying, you need to flip the texture vertically, BEFORE converting it to a .dds. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
-Original Message- From: Emilian Huminiuc [mailto:emili...@gmail.com] Sent: 21 March 2011 22:00 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Adventures in dds On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian That's exactly what me and Heiko were saying, you need to flip the texture vertically, BEFORE converting it to a .dds. Heiko said this: You have to flip the .dds-texture vertically after converting to it So that what I did. Now I'll try it the other way. Vivian -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
That's exactly what me and Heiko were saying, you need to flip the texture vertically, BEFORE converting it to a .dds. I meant BEFOR but did say after... My fault. Oops! -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Vivian, Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian The workflow would be like this, you map the model onto a .png texture. You finish drawing the texture, and before loading it into flightgear these two steps should be the last ones: You flip that texture verticaly (in gimp for example), then you convert the flipped texture to .dds. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
I wrote: -Original Message- From: Emilian Huminiuc [mailto:emili...@gmail.com] Sent: 21 March 2011 22:00 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Adventures in dds On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian That's exactly what me and Heiko were saying, you need to flip the texture vertically, BEFORE converting it to a .dds. Heiko said this: You have to flip the .dds-texture vertically after converting to it So that what I did. Now I'll try it the other way. Makes no difference flipping before conversion or after - Looks OK in AC3D, but not in FG. So it doesn't look like .dds is a proper option without further work. Vivian -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
The workflow would be like this, you map the model onto a .png texture. You finish drawing the texture, and before loading it into flightgear these two steps should be the last ones: You flip that texture verticaly (in gimp for example), then you convert the flipped texture to .dds. There is just one problem though: The Hudson Nightly Builds for win32 doesn't contain the .ddls for .dds Report to Bugtracker? -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Emilian, On Monday 21 March 2011 23:47:51 Vivian Meazza wrote: Vivian, Here's the AC3D version: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_AC3D.png And here's what I see in FG: ftp://abbeytheatre2.org.uk:2121/flightgear/Tempest/TempestV_FlightGear.png Vivian The workflow would be like this, you map the model onto a .png texture. You finish drawing the texture, and before loading it into flightgear these two steps should be the last ones: You flip that texture verticaly (in gimp for example), then you convert the flipped texture to .dds. OK, I'll try that Vivian -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Hi, Makes no difference flipping before conversion or after - Looks OK in AC3D, but not in FG. So it doesn't look like .dds is a proper option without further work. Vivian You must doing something wrong. here for Gimp, assumed that you have the plugin needed already: 1.) UVmap the aircraft in ac3d as usual with your png-file Then: 1) Take the .png-file you want convert 2)Image -- Transformation --Mirror (flip?)vertical 3)Save as name.dds 4.)a popup appears, select DXT5 and check mipmap 5) click o.k. Open the .ac-file with a text-editor and just change name.png to name.dds -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Heiko, -Original Message- From: Schulz [mailto:aeitsch...@yahoo.de] Sent: 21 March 2011 22:32 To: vivian.mea...@lineone.net; FlightGear developers discussions Subject: Re: [Flightgear-devel] Adventures in dds Hi, Makes no difference flipping before conversion or after - Looks OK in AC3D, but not in FG. So it doesn't look like .dds is a proper option without further work. Vivian You must doing something wrong. here for Gimp, assumed that you have the plugin needed already: 1.) UVmap the aircraft in ac3d as usual with your png-file Then: 1) Take the .png-file you want convert 2)Image -- Transformation --Mirror (flip?)vertical 3)Save as name.dds 4.)a popup appears, select DXT5 and check mipmap 5) click o.k. Open the .ac-file with a text-editor and just change name.png to name.dds Nope, doesn't work. But this does: Map the .png file onto the AC3D model as usual - convert the .png into .dds in XnView - load the .dds into AC3D No flipping of vertical required. Perhaps XnView flips it for us? Vivian -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
On Tuesday 22 March 2011 00:57:07 Vivian Meazza wrote: Nope, doesn't work. But this does: Map the .png file onto the AC3D model as usual - convert the .png into .dds in XnView - load the .dds into AC3D No flipping of vertical required. Perhaps XnView flips it for us? Vivian Probably xnview sets the origin in the lower left (as is in OpenGL). Problem with .dds is that each tool used to convert the might set the origin where it wants :( So far I haven't found a way of specifying the origin... -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Interesting.I just did my own quick test ... converted 1 out of 3 livery (png) files to a dds with Gimp plugin .Had to flip the image vertically before converting. I changed liveries with the dialog , and the 2 png files took several seconds to change , the dds changed instantly.I saw no difference in quality , but the load time was impressive.The original png file is 158.6 KB , the dds is 16.8 MB.This should swell fgdata significantly , unless Tim does (hopefully) does the /Aircraft split... Cheers On Mon, Mar 21, 2011 at 5:04 PM, Emilian Huminiuc emili...@gmail.com wrote: On Tuesday 22 March 2011 00:57:07 Vivian Meazza wrote: Nope, doesn't work. But this does: Map the .png file onto the AC3D model as usual - convert the .png into .dds in XnView - load the .dds into AC3D No flipping of vertical required. Perhaps XnView flips it for us? Vivian Probably xnview sets the origin in the lower left (as is in OpenGL). Problem with .dds is that each tool used to convert the might set the origin where it wants :( So far I haven't found a way of specifying the origin... -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
