Re: [Flightgear-devel] Iceland textures
On Fri, Dec 14, 2012 at 7:25 AM, Renk Thorsten wrote: Aw, that looks bad... I've never seen anything like, so my first guess would be that it's one of these NVIDIA vs. ATI issues (which are really tough to understand from my side with just NVIDIA cards available). For reference - I've seen it running fine on a GeForce 8600M and on a GeForce GTX 670M. No idea what Stuart runs. I'm also running NVidia (GT260M). This looks to me to be one of two things: - a straight driver bug (worth checking if your drivers are out of date) - (less likely) we're going beyond the number of textures your card supports for a specific fragment shader. BTW - I just came across this: http://developer.amd.com/tools/graphics-development/gpu-shaderanalyzer/ I've yet to download it, but it looks like it might be a very useful tool for those of us trying to improve shader performance. -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
On Friday, December 14, 2012 10:15:16 Stuart Buchanan wrote: On Fri, Dec 14, 2012 at 7:25 AM, Renk Thorsten wrote: Aw, that looks bad... I've never seen anything like, so my first guess would be that it's one of these NVIDIA vs. ATI issues (which are really tough to understand from my side with just NVIDIA cards available). For reference - I've seen it running fine on a GeForce 8600M and on a GeForce GTX 670M. No idea what Stuart runs. I'm also running NVidia (GT260M). This looks to me to be one of two things: - a straight driver bug (worth checking if your drivers are out of date) - (less likely) we're going beyond the number of textures your card supports for a specific fragment shader. BTW - I just came across this: http://developer.amd.com/tools/graphics-development/gpu-shaderanalyzer/ I've yet to download it, but it looks like it might be a very useful tool for those of us trying to improve shader performance. -Stuart Hi Stuart, I've used that. Unfortunately it won't help with compatibility issues, as the shaders compile fine with it in most cases, then they fail silently with the driver compiler... Thorsten, from discussion on irc, it seems you're assigning to a varying in the fragment shaders. See this log: http://dpaste.com/845317/ Most likely the other errors will go away once you fix that. Sometimes the nvidia compiler is too lax... HTH Emilian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
On Friday, December 14, 2012 10:15:16 Stuart Buchanan wrote: On Fri, Dec 14, 2012 at 7:25 AM, Renk Thorsten wrote: Aw, that looks bad... I've never seen anything like, so my first guess would be that it's one of these NVIDIA vs. ATI issues (which are really tough to understand from my side with just NVIDIA cards available). For reference - I've seen it running fine on a GeForce 8600M and on a GeForce GTX 670M. No idea what Stuart runs. I'm also running NVidia (GT260M). This looks to me to be one of two things: - a straight driver bug (worth checking if your drivers are out of date) - (less likely) we're going beyond the number of textures your card supports for a specific fragment shader. BTW - I just came across this: http://developer.amd.com/tools/graphics-development/gpu-shaderanalyzer/ I've yet to download it, but it looks like it might be a very useful tool for those of us trying to improve shader performance. -Stuart I'd rather use this one: http://www.gremedy.com/downloadLinux.php It has general OpenGL profiling features, but it also provides nice glsl compiler errors/warnings, with a lot of other useful things (inspection of various values the varyings/unifroms/attributes, textures, etc) (The warning/error handling is better than what the drivers do in any case) Also it has very little overhead for this use-case. Emilian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
Hi Adrian, On Wed, Dec 12, 2012 at 10:12 PM, Adrian Musceac wrote: As most of you know, the main performance issues come from having to repeatedly sample terrain elevation for a large number of points. This is done though and osg::NodeVisitor, which traverses all nodes within the scenegraph which have a certain mask set (in our case, it's SG_NODEMASK_TERRAIN_BIT) Unfortunately, not only the terrain surface has this mask set, but also random objects, random trees, and 'random' buildings. They all share this mask, so an _get_elevation_ call will have to traverse through litterally thousands of nodes which are not related to the terrain surface. In order to improve the performance of the _get_elevation_ method, I have added a new mask, SG_NODEMASK_SURFACE_BIT, which is set only for the surface geometry loaded by the BTG loader. Of course, some other minor code had to be modified, especially for groundcache et al. Very minor modification, basically taking into account of this new nodemask. The BVH bounding boxes stuff has been accounted for (I think I didn't miss anything) I haven't looked at your code, and I'm sure you've already taken care of this, but: The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings is probably due to my ignorance when writing the code, and I certainly agree that the trees shouldn't have this bit set. The v2.8.0 random buildings were a simply geometry built at runtime, and IIRC people were enjoying landing helicopters on the top of them. However, the current git random buildings use a shader instantiation approach very similar to the trees. I think that means that the shouldn't be considered with the FG_NODEMASK_TERRAIN_BIT either, as the geometry itself isn't placed correctly in the scenegraph. Therefore, I think they shouldn't be considered in the get_elevation_m/groundcache/bounding box code. I think the random objects _do_ need to be included so they can be included in collision calculations. On the more general subject, I have two comments, both as a layman so take with a suitable pinch of salt! 1) I think the most important attribute of the radio code is that one can complete a published approach. I assume that approaches are specifically designed and built such that there in sufficient signal strength within some volume around the perfect approach. My concern with any advanced model is that invalid/inaccurate terrain/elevation input into the model might mean that we get too low a signal, and some approaches might no-longer be possible to fly due to (incorrectly) low signal strength. Adrian: Is that a reasonable concern, or are approaches designed such that there is always line-of-site between the station and the aircraft on the approach (and therefore any terrain interaction is irrelevant within the approach volume)? 2) Assuming we're only interested in terrain effects, then it would seem that the signal strength at a given point (lat/lon/alt) for a given station is invariant. Would it be possible to avoid the runtime hit by calculating it offline for all points within reasonable range of the station? One might be able to create a bitmap storing the minimum signal altitude (i.e. the altitude below which there is no signal due to terrain), the maximum signal strength, the altitude that occurs, etc. and then use these as parameters into a straightforward function to determine the signal strength at the current altitude. One could then overlay the published approach volumes and thereby ensure that aircraft within the approach volume receive valid signal strength. -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Friday, December 14, 2012 13:09:54 Stuart Buchanan wrote: Hi Adrian, I haven't looked at your code, and I'm sure you've already taken care of this, but: The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings is probably due to my ignorance when writing the code, and I certainly agree that the trees shouldn't have this bit set. Hi Stuart, I am much more ignorant than you are when it comes to the way trees are created :) I have modified the code in simgear now, so that they don't have the bit set. Also, I noticed they have the SG_NODEMASK_CASTSHADOW_BIT | SG_NODEMASK_RECEIVESHADOW_BIT bits set (for Rembrandt), but they don't cast shadows, probably due to their geometry, you probably know better. Should I remove them? The v2.8.0 random buildings were a simply geometry built at runtime, and IIRC people were enjoying landing helicopters on the top of them. However, the current git random buildings use a shader instantiation approach very similar to the trees. I think that means that the shouldn't be considered with the FG_NODEMASK_TERRAIN_BIT either, as the geometry itself isn't placed correctly in the scenegraph. Therefore, I think they shouldn't be considered in the get_elevation_m/groundcache/bounding box code. Same goes for random buildings, which thanks to texture mapping are now not so random :) To my surprise, they also didn't cast shadows. Now I understand why. Should those bits go too? Can Fred give his input too on this issue? About bounding boxes, perhaps there's a way to have that too, but again, I'm very ignorant on your method which relies on shaders. I think the random objects _do_ need to be included so they can be included in collision calculations. Agreed. As it is now, I have added a new bit only for terrain surface, SG_NODEMASK_SURFACE_BIT , and the rest of terrain objects which do have bounding boxes will keep the SG_NODEMASK_TERRAIN_BIT. When performing scenery elevation calls, I believe the best way is to add another parameter which can toggle SG_NODEMASK_TERRAIN_BIT on and off. The speedup in this case is pretty important, there are fewer nodes to be traversed. I think Thorsten's weather would benefit from this as well, since it needs to sample only the surface (elevation, type of terrain). On the more general subject, I have two comments, both as a layman so take with a suitable pinch of salt! 1) I think the most important attribute of the radio code is that one can complete a published approach. I assume that approaches are specifically designed and built such that there in sufficient signal strength within some volume around the perfect approach. Normally yes, I am not a pilot, but I assume that there would be no approach charts that would tell you there is localizer/gs signal behind the local mountain. Same goes for VOR etc. The published volume is one thing, but if terrain features come into play, the signal may or may not go, and that's the most interesting part of it, it adds a little uncertainty when you are at low altitude, in mountainous areas, at the limit, etc. I just had a very satisfying flight yesterday using the code, and it made me understand why there are so many VOR's in some areas, and how you need to tune from one to the other as you go through terrain at lower altitudes. I should add that I fly in SRTM terrain mostly, and I have very accurate radio signal predictions. My concern with any advanced model is that invalid/inaccurate terrain/elevation input into the model might mean that we get too low a signal, and some approaches might no-longer be possible to fly due to (incorrectly) low signal strength. The reverse is likely. The values will be most unforgiving with SRTM/high definition DEM, and most forgiving in low res terrain. Fortunately, I have a property which can be set by the user, depending on the type of terrain which is flying. This is the elevation resolution the code should expect. In low res terrain, this property can be set to 200-300 meters between profile points, and then you won't even notice the CPU footprint. Adrian: Is that a reasonable concern, or are approaches designed such that there is always line-of-site between the station and the aircraft on the approach (and therefore any terrain interaction is irrelevant within the approach volume)? I believe all approach charts respect terrain, and judging from nav.dat, there is a good reason some VOR's use greater power, or some ILS stations pump greater power in their antennas etc. To do otherwise and not keep the terrain in mind would be foolish, and I don't think the guys publishing the charts are fools. 2) Assuming we're only interested in terrain effects, then it would seem that the signal strength at a given point (lat/lon/alt) for a given station is invariant. Would it be possible to avoid the runtime hit by calculating it offline for all points within
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
Oh one more thing, The random buildings and trees definetly receive shadows, but they don't cast it. Is that the way it should be? Asking because I'm about to push the modifications to my simgear clone. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
On Fri, Dec 14, 2012 at 12:28 PM, Adrian Musceac wrote: Oh one more thing, The random buildings and trees definetly receive shadows, but they don't cast it. Is that the way it should be? Asking because I'm about to push the modifications to my simgear clone. The trees were definitely both casting and receiving shadows under Rembrandt in the past. I remember this as I was pleasantly surprised that it worked! I haven't tested recently though, so it's possible that it has been broken since. The random buildings I'm less certain about. The 2.8.0 version certainly both cast and receive shadows. I'm not sure I've tested shadows since I changed them to an instantiation model post 2.8.0. Sorry I can't be more definitive. -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
On Friday, December 14, 2012 15:05:59 Stuart Buchanan wrote: The trees were definitely both casting and receiving shadows under Rembrandt in the past. I remember this as I was pleasantly surprised that it worked! I haven't tested recently though, so it's possible that it has been broken since. The random buildings I'm less certain about. The 2.8.0 version certainly both cast and receive shadows. I'm not sure I've tested shadows since I changed them to an instantiation model post 2.8.0. Sorry I can't be more definitive. Ok, let me revert to next and test again. I don't normally enable Rembrandt since it's very slow on my machine, but when I did, I couldn't believe how much it can changed the scene and how nice it looked. So far, I think we agree trees shouldn't have the TERRAIN_BIT set, and random buildings are still up for debate, but random models should definetly set this bit. I will test the shadows again and report which bits are working in latest simgear and which are not. BTW, random models cast shadows, I saw that clearly. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
On Friday, December 14, 2012 12:33:52 Renk Thorsten wrote: Thorsten, from discussion on irc, it seems you're assigning to a varying in the fragment shaders. See this log: http://dpaste.com/845317/ Most likely the other errors will go away once you fix that. Thanks, the log was very helpful - please pull and try again, at least the assignment to the varying should be fixed now. * Thorsten Hi, Those are fixed, but you still have some implicit casts/coversions in there, those are tolerated by the nvidia compiler but not by other drivers: http://dpaste.com/845842/ HTH Emilian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
Those are fixed, but you still have some implicit casts/coversions in there, those are tolerated by the nvidia compiler but not by other drivers: http://dpaste.com/845842/ Aw, a forgotten decimal point - that's picky. Okay, how about now? * Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
On Friday, December 14, 2012 15:05:59 Stuart Buchanan wrote: The trees were definitely both casting and receiving shadows under Rembrandt in the past. I remember this as I was pleasantly surprised that it worked! I haven't tested recently though, so it's possible that it has been broken since. Ok, I've just tested this with current Git, and buildings except random models, as well as trees, don't cast shadows, but receive them. I do remember a time when buildings cast shadows too, I think. I'll try to research this further. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
On Friday, December 14, 2012 13:28:08 Renk Thorsten wrote: Those are fixed, but you still have some implicit casts/coversions in there, those are tolerated by the nvidia compiler but not by other drivers: http://dpaste.com/845842/ Aw, a forgotten decimal point - that's picky. Okay, how about now? * Thorsten Apparently that's ok now, another issue cropped up in the urban-lightfield shader, something wrong with an #if: FRAGMENT glCompileShader /home/chris/FlightGear/Shaders/urban-lightfield.frag FAILED FRAGMENT Shader /home/chris/FlightGear/Shaders/urban-lightfield.frag infolog: 0:196(22): preprocessor error: syntax error, unexpected IDENTIFIER, expecting NEWLINE 0:193(1): preprocessor error: Unterminated #if Emilian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
Hi Adrian, you are doing an excellent job at marketing your product ;-) As I do not have the time to proof you wrong, you deserve the chance to proof me wrong! I'll shut up now and stop objecting against merging your code. I won't be able to merge it myself before we enter the feature freeze but probably someone with commit rights takes care of it. I hope I find some time to test the LOWI approach which had the chance to do in RL recently... (http://data.x-plane.com/Docs/LOWI.pdf) Thanks, Torsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
Am 13.12.2012 16:28, schrieb geneb: Um, no he's not. He just happens to be a contributor like the rest of us. :) There is no herder for the Free Range Cats that make up the FlightGear project. :) How disappointing ;-) Frankly, I think your addition to FlightGear is fantastic and a needed feature for the non-entertainment side of the house. If the gamers don't like the small frame rate hit, they can just turn it off. But being called a gamer, _that_ is discouraging! Greetings Torsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Friday, December 14, 2012 18:09:04 Torsten Dreyer wrote: Hi Adrian, you are doing an excellent job at marketing your product ;-) As I do not have the time to proof you wrong, you deserve the chance to proof me wrong! I'll shut up now and stop objecting against merging your code. I won't be able to merge it myself before we enter the feature freeze but probably someone with commit rights takes care of it. I hope I find some time to test the LOWI approach which had the chance to do in RL recently... (http://data.x-plane.com/Docs/LOWI.pdf) Thanks, Torsten Hi Torsten, Sure, no problem. I hope you will find it useful in the future too, otherwise I would have kept it for myself :) Thanks for all your help last year and your patience for my noobishness in Flightgear inners. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On 14 Dec 2012, at 16:09, Torsten Dreyer wrote: As I do not have the time to proof you wrong, you deserve the chance to proof me wrong! I'll shut up now and stop objecting against merging your code. I won't be able to merge it myself before we enter the feature freeze but probably someone with commit rights takes care of it. However I still have code quality objections, unrelated to the performance of the code! (And also unrelated to the accuracy of the simulation - I have no problem with adding advanced computational systems so long as their optional, which this is) I will take a look next week at merging the changes locally and then seeing how much re-structuring is needed to make me comfortable, but right now the lack of object-orientated design and over/mis-use of properties is just not something I want to add more of, to the codebase. As I said to Adrian offline, I know there's plenty of code already checked in, of a similar quality / design / pattern to his submission, but I'd like to set a higher standard for new code than what we had previously. James -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On 14 Dec 2012, at 17:27, James Turner wrote: As I said to Adrian offline, I know there's plenty of code already checked in, of a similar quality / design / pattern to his submission, but I'd like to set a higher standard for new code than what we had previously. And it case it wasn't clear - I realise Adrian can't possibly know this stuff magically - that's why I'm happy to make the time, to make the changes myself! It would of course be easier to have these discussions when the code is at the prototype stage, but that's a harder issue to solve. James -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Fri, 14 Dec 2012, James Turner wrote: On 14 Dec 2012, at 17:27, James Turner wrote: As I said to Adrian offline, I know there's plenty of code already checked in, of a similar quality / design / pattern to his submission, but I'd like to set a higher standard for new code than what we had previously. And it case it wasn't clear - I realise Adrian can't possibly know this stuff magically - that's why I'm happy to make the time, to make the changes myself! It would of course be easier to have these discussions when the code is at the prototype stage, but that's a harder issue to solve. James, maybe now would be a good time to write up something that covers coding guidlines for the wiki? 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_! -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
Hi Thorsten - no errors on the console - latest drivers for the ati card (tested with all ati drivers from 2012 for win7 64bit) - the artifacts show up if the landmass shader is over 3 (counting from left / starting with 0) - the artefacts show up if the transition shader is over 1 / at 2 only the airport grass is showing the artefacts - the Atmospheric Scattering seems to work as far i can tell and shows no artefacts, water looks good too. - did not try change the shaders while using Atmospheric Scattering before the iceland commit, only used the default values. Hope that helps. Oliver small video: http://www.youtube.com/watch?v=NOdLtReF4Pk 2012/12/14 Renk Thorsten thorsten.i.r...@jyu.fi This may be too much to be asked, but: * any errors thrown to the console? * do the artefacts go away if you select different quality values for the transition and landmass effects? If yes, at what values does this happen? * are other effects (urban, water,...) in the Atmospheric Scattering framework working correctly? * do you know when the problem appeared - was it specifically after the Iceland commit, or since procedural texturing was introduced in summer? * are there terrain types which do not show flickering, if so which ones? * Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Iceland textures
- no errors on the console - latest drivers for the ati card (tested with all ati drivers from 2012 for win7 64bit) - the artifacts show up if the landmass shader is over 3 (counting from left / starting with 0) - the artefacts show up if the transition shader is over 1 / at 2 only the airport grass is showing the artefacts - the Atmospheric Scattering seems to work as far i can tell and shows no artefacts, water looks good too. - did not try change the shaders while using Atmospheric Scattering before the iceland commit, only used the default values. Hope that helps. Not really. Your card/driver doesn't like *something* of the procedural texturing although the shader compiles fine (you don't get the artefacts when you're running terrain-haze.vert/frag, you do get them whenever you run terrain-haze-detailed.vert/frag). It may be the overlay textures, it may be that the noise function generates values outside the [0..1] range by some weird numerical problem... Does it happen for all landclasses (for instance, agriculture doesn't have overlay textures or bump-mapping) - so in theory some landclasses would never see overlay texture or noise function issues. Does it depend on the values of the dust, snow, vegetation or wetness sliders in any way? Otherwise... if it doesn't throw an error, and if I can't reproduce it and we don't see any dependencies, I am a bit at a loss how to debug it. You could either see if there's any previous version which runs fine (in which case we can debug based on what has changed) or we can try to disable all procedural blocks, and then you have to uncomment them one by one and see when the problem occurs. Let me know if you're interested in the latter option (but it means you have to start editing around in the shader code yourself). * Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
