> 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> <path>texturetest1.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> <path>texturetest1.ac</path> <effect> <object-name>rect</object-name> <inherits-from>Effects/clouds-thin</inherits-from> </effect> <animation> <object-name>rect</object-name> <enable-hot type="bool">false</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
