Hi, On Saturday, April 14, 2012 17:16:52 ThorstenB wrote: > On 14.04.2012 15:18, Mathias Fröhlich wrote: > > > Shader textures are loaded unconditionally, at least into main memory. > > > Hopefully GPU loading is optional - but I'm not sure. > > > > Textures are loaded in main memory when the model that references them > > is loaded. Handing textures over to OpenGL is done once they are > > Right. But some of the "global" shaders always seem to be loaded. For > example, start at LOWI. Doesn't matter whether shaders are enabled or > disabled - you still get the warnings about the proprietary > "sea_foam.dds" textures being loaded. Not sure whether it's really > referenced by the scenery there - the sea should be really far away ;-). Ah, thats probably everything that is referenced by the materials. Yes, this could be done on demand when the materials are really accessed.
Is this worth? Try it out ... The material states could be loaded by an other meta loader that registers statically at the loader registry. The simgear internal part of the materials would be created once the xml file is loaded but tha state sets can be done on demand by a readObject() method in this loader. Look into the SPT Loaders state sets and world texture state how this could be done. When you do this take care that this happens probably more concurrent than it happens now. > > > If someone was looking into improving the effect/texture loading code: > > > it would be great if loading shader textures could be made optional, > > > i.e. defer loading them until first access. > > > > Well, what do you mean with 'first access'? > > To somehow create the "effect" object when the model references it, but > to defer loading the texture until the effect condition becomes true for > the very first time - which is the moment when the texture is actually > needed/accessed for the first time. This would keep the feature of being > able to enable shaders at run-time, while avoiding to waste memory/CPU > performance on loading unnecessary textures. Hmm, ok. You will then need to introduce this kind of paging into osg. I see already hooks for something like that, but I never saw this finished. So I would prefer to not do this with a huge amount of adaptions at our osg integration just because of some effect textures being loaded. If it's easy to do and does not require just an other addition to the cull visitor ok. Anyway, one method that is always on top of flightgear profiles is the effect drawables interaction with the cull visitor. And in the far term I would prefer to move away from that decision about the effect being used at *every* time that drawable is being culled. IMO this should be done in advance with a set of extensions that is determined at context creation on viewer startup. And with this static decision within a single program run, instantiate the effects. for multiple contexts use the subset of extensions that is available in all contexts. Practically this should not introduce additional restrictions as usually all graphics boards in a single viewer are the same. And If you have different ones you are probably more interrested in a consistent look across the whole view than in a maximum feature special view because of a single different graphics board. Given that, you should at load time know about the required subset of the effect textures, which make the above thought less important. And much more important, I expect some improvment in the cull times with that kind of change. If you still want to change the effects being used on runtime, you need to walk the sceneraph models one time and switch the effects being used. Or may be reload the scenery or something like that. But It makes no sense to pessimize the code path that is really important and happening on every frame because of something that you mostly only do when you install flightgear and you try out if the shaders are worth being enabled or not for your use. > > That's actually something I consider having. Also for different reasons. > > All the shader stuff is really nice but there are really use cases out > > there where it does not matter if the chrome is glossy or not. For them > > it's really most important that you get stable 60hz in *any* case. Which > > is still easier to get using the fixed function pipeline. > > > > So again still having that available would be good IMO. > > +1 Ok. Greetings Mathias ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
