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] Now Rembrandt here...
Gene Buckle On Thu, 12 Apr 2012, Frederic Bouvier wrote: Here is a video with a steady view to see shadow stability. http://youtu.be/JtEXIn2yL94 I also added 3 different sequences with different levels of filtering. Filtering is not yet configurable but is selectable in the sunlight shader with simple code modification. Fred, is there a reason the shadows on the instrument faces are so jumpy? Probably :) one reason is the moving sun that few other games have (not speaking of flight simulators, of course) -Fred -- 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] Adding Airports
John wrote: How can I append the .tpj files to apt.dat? You can export to .dat via File Export apt.dat (IIRC). You can then merge that output into apt.dat. Or feed this single-airport .dat directly into TerraGear's genapts to build a single airport. Or even combine all your Ugandesian (?) airports in one .dat file. Also what's the best way to get these airports submitted to the database, is the answer still Robin Peel? Hard one. Robin doesn't accept 810 edits any more (AFAIK). Martin used to collect FlightGear edits, but I'm not sure if he still does. And current developments of TerraGear are made towards the 850 format, so 810 is slowly dying... Cheers, Gijs -- 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] Water shader issues
I don't think your analysis can be correct; I don't particulary care. In my version of the shader, the problem is fixed for good and performance is improved, I've posted the code which does it, if you prefer your version of the code for whatever reason, be my guest. Likewise, if you and Emilian think computing normals to 0.1 deg accuracy is worth the effort, be my guest. I'm not touching your version of the shader, I'm just letting you know what I found out. The intention is to set the reflection colour as white if cover = 1.5 else set it to grey. AFAIK it works that way as well. It does, and it creates the tiling artefacts which we falsely attributed to reflection issues on the way. And as I said, loading two texture sheets to determine if a color is white or grey seems like a complete overkill to me. It's all an attempt to emulate the cloud cover over the sea and stop it being a lovely blue in the middle of a storm. I don't see that your modification honours this intent. Look again. This // de-saturate for reduced light refl.rgb = mix(refl.rgb, vec3 (0.248, 0.248, 0.248), 1.0 - smoothstep(0.4, 1.0, scattering)); turns the base sea color smoothly into (0.248, 0.248, 0.248) (grey) dependent on the value of scattering which is a one-parameter measure of the light intensity reduction due to cloud cover (I have the screenshots to prove that this works, but I just don't see the point). Proximity of land is only a very rough guide to depth of water. You can go a long way from shore in the North Sea without finding deep water, but the sea gets very deep very fast off the Azores. If we can represent all this better, then I'm all for it. We cannot get the exact base water color without introducing water classes or something like that into the scenery database. But we can make a moderately complex model for sea colors by having a Nasal script interpolate values from a table based on geography and using land proximity info, dump that value into the property tree and use it in the shader. It seems to me that a rough model is preferable to one constant sea color all over the place. Anyway, I think I will just implement it that way, and you do what you think is best. 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 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] Now Rembrandt here...
On Sat, 14 Apr 2012, Frederic Bouvier wrote: Fred, is there a reason the shadows on the instrument faces are so jumpy? Probably :) one reason is the moving sun that few other games have (not speaking of flight simulators, of course) Ok. :) I noticed the Anteworld demo of Outerra has the same issue when I was fiddling with it yesterday. The heavy filtering does help quite a bit, but there should be some way to eliminate that jitter. It's a shame we can't just slow the planet down. :D 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
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
