Hi. Inspired by the talk in the dds thread about cloud performance and other things, I did some quick grepping through the source about textures. I found out FG/SG has at least 5 different way of storing textures:
1. FGTextureManager in FG's Cockpit/panel.*, which at least tries to keep track of texture files which are loaded and should not load them again. This is used in some instruments and 2d panel? 2. Effects (SG: scene/material/TextureBuilder.*) have their own texture cache which reloads textures only if their parameters in effect file changes. Seems to reload the texture if e.g. clamping changes? 3. Material library (scene/material/mat.*) which handles the materials.xml. This one seems to use TextureBuilder so it might load the iamges only once, if all parameters are the same. 4. Individual pointer in subsystems. At least sky elements, splash screen, maybe trees and clouds etc use these. Texture pointers are stored inside the class and they are not exposed for other systems to use. 5, maybe worst: osg plugins which load 3d models seem to load textures directly and store them... somewhere. So no caching, if two models use the same texture it gets always loaded, no matter what. I think the problem with local weather could be that the models are always re-loaded and that's why the osg plugin re-loads the textures too... I checked some models in Models/Weather and they do point to the textures. I think this is quite a big mess currently. I think there should be only one place to store the images (maybe just the images, even if other texturing parameters change?) which should be used everywhere and the textures should be exposed so that the same image can be used in effects or animations or wherever necessary. Any thoughts on this and how to solve it? - Lauri Peltonen, Zan ------------------------------------------------------------------------------ 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
