Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, I had a texture-size limiter for flightgear in the past. I have to dig it out first. But please have a look at these textures. I doubt that it makes sense to have a bump normal map twice the size of the livery it is applied to. Olaf Presumably you could just ask osg or the gl to discard the top mip level(s) rather than altering the source art to work around apple's driver bugs? -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
On 13 Apr 2012, at 23:28, Chris Forbes wrote: Presumably you could just ask osg or the gl to discard the top mip level(s) rather than altering the source art to work around apple's driver bugs? Yeah, unfortunately I think people want the high-res art for a reason - this needs a runtime test for the Intel chipset (on Mac only?) and something to reduce the size. Unfortunately that's a lot more work, and might require OSG changes since OSG loads the textures :( James -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, On Saturday, April 14, 2012 09:49:18 James Turner wrote: On 13 Apr 2012, at 23:28, Chris Forbes wrote: Presumably you could just ask osg or the gl to discard the top mip level(s) rather than altering the source art to work around apple's driver bugs? Yeah, unfortunately I think people want the high-res art for a reason - this needs a runtime test for the Intel chipset (on Mac only?) and something to reduce the size. Unfortunately that's a lot more work, and might require OSG changes since OSG loads the textures :( But every image goes through our hands. We can just rescale this under certain conditions. At least the uncompressed textures are unproblematic. I would introduce some property that is evaluated in the image load callback than. Today the chain of readerwriter options should in any case provide a simgear options object that contains the property tree that could be queried then. 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
On 14 Apr 2012, at 10:10, Mathias Fröhlich wrote: But every image goes through our hands. We can just rescale this under certain conditions. At least the uncompressed textures are unproblematic. I would introduce some property that is evaluated in the image load callback than. Today the chain of readerwriter options should in any case provide a simgear options object that contains the property tree that could be queried then. Ah, I thought many textures only when through osgDB, and we didn't have any callback or place to make such changes. If we do, then it's easy to add a property as you suggest. James -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
On 14 Apr 2012, at 09:48, Olaf Flebbe wrote: I had a texture-size limiter for flightgear in the past. I have to dig it out first. Okay, I think it would be a good thing to have anyway, since people have wildly varying amounts of GPU ram But please have a look at these textures. I doubt that it makes sense to have a bump normal map twice the size of the livery it is applied to. Ah, sorry, I agree this is unlikely :) Unless people are counting each rivet head ... maybe they are! James -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, On Saturday, April 14, 2012 11:05:10 James Turner wrote: On 14 Apr 2012, at 10:10, Mathias Fröhlich wrote: But every image goes through our hands. We can just rescale this under certain conditions. At least the uncompressed textures are unproblematic. I would introduce some property that is evaluated in the image load callback than. Today the chain of readerwriter options should in any case provide a simgear options object that contains the property tree that could be queried then. Ah, I thought many textures only when through osgDB, and we didn't have any callback or place to make such changes. If we do, then it's easy to add a property as you suggest. That's in ModelRegistry::readImage() Alternatively we could traverse the scenegraph of a loaded model and look for textures. That shouold work also. But the model registry thing sounds at first more plausible to me. 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
-Stuart On 14 Apr 2012, at 11:06, James Turner wrote: On 14 Apr 2012, at 09:48, Olaf Flebbe wrote: But please have a look at these textures. I doubt that it makes sense to have a bump normal map twice the size of the livery it is applied to. Ah, sorry, I agree this is unlikely :) Unless people are counting each rivet head ... maybe they are! The reason for having such a large normal map was to provide sufficient resolution that the rivets are visible. Any smaller and they appear as a raised line instead IIRC. I like the idea of resizing textures at model loading time a lot. The other option would be to switch the shader off. Presumably that would not load the normal map into the GPU. Stuart -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
On 14.04.2012 13:08, Stuart Buchanan wrote: I like the idea of resizing textures at model loading time a lot. The other option would be to switch the shader off. Presumably that would not load the normal map into the GPU. Shader textures are loaded unconditionally, at least into main memory. Hopefully GPU loading is optional - but I'm not sure. 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. As a hard work-around, we could also introduce a new command-line option to disable shaders support completely (enabling shaders at run-time via the dialog wouldn't work then). This would help those with weak GPUs/old systems - and reduce loading times and memory consumption. cheers, Thorsten -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Am 14.04.2012 um 13:08 schrieb Stuart Buchanan: -Stuart On 14 Apr 2012, at 11:06, James Turner wrote: On 14 Apr 2012, at 09:48, Olaf Flebbe wrote: But please have a look at these textures. I doubt that it makes sense to have a bump normal map twice the size of the livery it is applied to. Ah, sorry, I agree this is unlikely :) Unless people are counting each rivet head ... maybe they are! The reason for having such a large normal map was to provide sufficient resolution that the rivets are visible. Any smaller and they appear as a raised line instead IIRC. Maybe I didn't know where to look at. IMHO the rivets display perfectly even for texture size 2048. I will try to provide screen shots for comparison. Olaf -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, Here are my screen shots, please compare: 4096x4096 Texture http://dl.dropbox.com/u/17221087/fgfs-screen-003.png 2048x2048 Texture http://dl.dropbox.com/u/17221087/fgfs-screen-005.png BTW: Are there really no rivets on the left side of the aircraft at the same position? Greetings, Olaf -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Hi, On Saturday, April 14, 2012 13:51:33 ThorstenB wrote: On 14.04.2012 13:08, Stuart Buchanan wrote: I like the idea of resizing textures at model loading time a lot. The other option would be to switch the shader off. Presumably that would not load the normal map into the GPU. 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 rendered the first time. Then the driver decides when to put the buffers in which area of the gpu/cpu memory. You cant control this then. And I think you should not try to control this last part mostly since this highly interacts with paging, uses of the GPU by other applications and so on. So this really belongs hidden into the driver and interacting with the system. 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'? As a hard work-around, we could also introduce a new command-line option to disable shaders support completely (enabling shaders at run-time via the dialog wouldn't work then). This would help those with weak GPUs/old systems - and reduce loading times and memory consumption. 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. 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
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 ;-). 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. As a hard work-around, we could also introduce a new command-line option to disable shaders support completely (enabling shaders at run-time via the dialog wouldn't work then). This would help those with weak GPUs/old systems - and reduce loading times and memory consumption. 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 cheers, Thorsten -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
On Sat, Apr 14, 2012 at 1:47 PM, Olaf Flebbe wrote: Hi, Here are my screen shots, please compare: 4096x4096 Texture http://dl.dropbox.com/u/17221087/fgfs-screen-003.png 2048x2048 Texture http://dl.dropbox.com/u/17221087/fgfs-screen-005.png I can see a difference - the 4096 rivets look more round and have fewer rendering artefacts. BTW: Are there really no rivets on the left side of the aircraft at the same position? That'll be a bug. I'll look into it. -Stuart -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
On Sat, 14 Apr 2012, Stuart Buchanan wrote: I can see a difference - the 4096 rivets look more round and have fewer rendering artefacts. Looks nicer too! :) Is there a way to increase the resolutin of the texture used for the aircraft paint? Right now it looks like some kid has been after it with a spray can... g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Am 14.04.2012 12:06, schrieb James Turner: On 14 Apr 2012, at 09:48, Olaf Flebbe wrote: I had a texture-size limiter for flightgear in the past. I have to dig it out first. Okay, I think it would be a good thing to have anyway, since people have wildly varying amounts of GPU ram But please have a look at these textures. I doubt that it makes sense to have a bump normal map twice the size of the livery it is applied to. Ah, sorry, I agree this is unlikely :) Unless people are counting each rivet head ... maybe they are! Yes we are :-) Using bumpmaps of 1024x1024 or 2048x2048 give ugly edgy craters rather than fine details. It's no use doing Rivet rows in 1 pixel, this doesn't look good. A large bumpmap images with details gives another advantage as the livery texture file can be a smaller resolution, which helps with MP loading time or livery switching. Greetings D. Faber James -- 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 -- 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
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
Presumably you could just ask osg or the gl to discard the top mip level(s) rather than altering the source art to work around apple's driver bugs? -- 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