On Mon, Mar 21, 2011 at 10:03 PM, Lauri Peltonen <lauri.pelto...@gmail.com> wrote: > 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: > It is important to keep in mind the difference between the texture in main memory as loaded from disk -- what OSG calls an Image -- and the texture object on the GPU -- called a Texture2D -- which includes other state in addition to the bits of the image. OSG does keep a cache of Images, so it shouldn't be going out to disk each time it needs to load a texture. However, OSG also avoids using up memory without bound, so if an Image becomes completely unreferenced it will drop out of the cache. > 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? > No comment. > 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? > Yes, the Effects system caches Texture2D texture objects. If a parameter such as the clamping is different from a texture that is otherwise identical in the cache, it has to create a new texture object. That's just the way it is. Note that this should not force the image to be loaded from disk again. > 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. Right, these textures should be only be loaded once. > > 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. This should not be true in general; the images should be cached and the texture objects should be too, unless some parameter is animated so the texture can not be shared. Now, I notice that cacheing is turned off for a class of models that includes AI models and may include models created through Nasal (simgear/scene/model/SGPagedLOD.hxx, line 53); I don't know what the rationale is for that and that may be the cause of the current problems. > > > 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. > You can put a breakpoint in ModelRegistry::readImage(), which should handle *all* images read by fgfs, and see if it seems to be invoked too often. > 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. That place is supposed to be OSG's Image cache.
Tim > > 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 > ------------------------------------------------------------------------------ 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
