Re: [Flightgear-devel] Real-Time Radio Propagation
On Thursday, December 13, 2012 01:03:45 Vivian Meazza wrote: Don't we need radar altitude for buildings etc. for radar altimeters, but probably not trees? A radar altimeter needs to sample both the terrain and hard objects on it. However, I watch this work with interest: I think it might make it worth reviewing the AG radar that I abandoned due to the impact on frame rate, and lack of realistic range because not enough tiles were loaded, Vivian Vivian Yeah... to be discussed. I don't know much about trees, except that they are nodes made out of a couple of vertices (I think Stuat can correct me on this). But you're right about the buildings and radar alt. I suggest changing the signature of FGScenery::get_elevation_m to include a flag: surface only, and set the traversal mask accordingly. I will do just that today and report the results. I want this to be retro- compatible and no changes to other code that relies on get_elevation_m. Like I mentioned last night, not having to traverse all the random buildings, trees and whatnot speeds the intersect visitor result quite a lot, if only terrain elevation is desired. Any comments? 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
[Flightgear-devel] Sound bugfix and Jenkins
Forum: by zakalawe on Wed Dec 12, 2012 4:46 pm I've pushed a fix (to SG) for the sound issue. Better to report such issues via the developer list in the future, I don't check topics here. Jenkins FlightGear-Win64-CMake build history: #220 (pending - All nodes of label 'x64' are offline ) Last build (#219), 3 days 9 hr ago Shouldn't have the fix propagated to a new Win64 binary by 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] Sound bugfix and Jenkins
On 13 Dec 2012, at 09:02, Renk Thorsten wrote: Jenkins FlightGear-Win64-CMake build history: #220 (pending - All nodes of label 'x64' are offline ) Last build (#219), 3 days 9 hr ago Shouldn't have the fix propagated to a new Win64 binary by now? Gene upgraded the Jenkins master at the weekend and it seems the Windows slaves haven't reconnected since. I'm travelling later today, but I'll send Gene a note now. 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
Hi replying to multiple posts here, I'll try to collect and answer to some arguments. First: I totally agree that our current nav/comm radio implementation is far from being realistic w.r.t. propagation of the radio signal close to or on the ground. This should be improved. I spent an hour or two reviewing your code and I still think your implementation should not be merged into the code base. Let me explain why. - Realism Your algorithm takes into account many factors responsible for radio probagation. Most of those factors are unknown in our data set and we have to use assumptions for their values. The less data we have and the more assumptions we have to use, the more unrealistic the algorithm's result become. My definition for realism is: Does the simulator compute the same value as I would expect in the same situation in real life? I strongly doubt the algorithm together with our limited set of data can provide this. In some cases, the used algorithm is plain wrong as we know by definition (ICAO rules) the propagation of the radio signal. - Performance The most important limiting factor for radio propagation on VHF and up is question line of sight or obscured by terrain. Your approach is to perform terrain samples along the line between the sender and receiver which is expensive. My idea for the newnavradio was to traverse the scenegraph along the straight line between sender and receiver and probe for ground intersection. This is basically the functionality as the probe for ground elevation, which could be reused. The difference of performance impact is dozens or even hundrets of scenegraph traversals compared to just one. - Landcover Landcover contributes only neglible compared to terrain obscucarion to the loss of signal strength. - Coding style * You copied parts of the terrain sampler from advanced weather. Better reuse existing code, probably modify so it suits both usecases. * Using long chains of if/else or switch/case makes code hard to read and is usually a good indication for a flaw in the software design. * I prefer named constants instead of numbers to imporve readability. Summary You obviously spent a lot of time implementing the itm algorithm as a subsystem and I feel sorry if it is discouraging for you or other potential contributers that I (and I am just speaking for myself) do not support this contribution. My apologies for not speaking up earlier. This implementation only adds a pseudo-realistic radio propagation simulation due to lack of real data at the cost of cpu intensive calculations and a complex new subsystem that has to be maintained over the time. The same pseude-realism could be achived by implementing an approximation for signal attenuation for line of sight and obscured propagation paths (probably as simple as distance-squared and distance-to-the-power-of-something). Neither your implementation nor my suggestion provides a realistic prediction of the radio signal quality, both are more or less approximations. It's the gain/pain ratio that differs significantly. Please forgive my my clear words - it's not my intention to offend anybody. Regards, Torsten Oh - one last thing: Committing code just because somebody spent much time writing it or not committing would be discouraging should never be a reason to do so. -- 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 Torsten, Regardless of the fact that you support or not the inclusion of this new radio code, I have to clear up some statements which are wrong. See below. I spent an hour or two reviewing your code and I still think your implementation should not be merged into the code base. Let me explain why. - Realism Your algorithm takes into account many factors responsible for radio probagation. Most of those factors are unknown in our data set and we have to use assumptions for their values. The less data we have and the more assumptions we have to use, the more unrealistic the algorithm's result become. My definition for realism is: Does the simulator compute the same value as I would expect in the same situation in real life? I strongly doubt the algorithm together with our limited set of data can provide this. In some cases, the used algorithm is plain wrong as we know by definition (ICAO rules) the propagation of the radio signal. The Longley Rice algorithm also known as the Irrregular Terrain Model is not plain wrong, since it is used in many applications that perform signal prediction on irregular terrain, with good accuracy. As far as I know, only Splat! is open-source, but a lot of commercial software uses this model, which has valid results between 40 MHz and 20 GHz. To call the algorithm plain wrong is a mistake in my opinion. The unknown factors and the assumptions you are referring to are mostly about radio gear: output power, receiver sensitivity, antenna gains. I have spent a lot of time reseaching avionics radio products to gain specs in order to cover these unknowns. - Performance The most important limiting factor for radio propagation on VHF and up is question line of sight or obscured by terrain. Not quite true. According to frequency, radio signals can be significantly diffracted over obstructions. The Longley-Rice model makes a clear distinction between these propagation models: Line of Sight, Single Horizon Diffraction, Double Horizon Diffraction, and Tropospheric Scatter. At frequencies below 140 MHz, signals behave very differently to what you call line of sight. True line-of-sight also has to take into account Fresnel zones, and can only be talked about at 1.5 GHz and up. Your approach is to perform terrain samples along the line between the sender and receiver which is expensive. True, but there is no other way to use the ITM algorithm to obtain a good result. I need to obtain a terrain profile, which is the reason for the performance issues. I have also written a simplified function which does not take terrain into account, for use on very long distances where terrain would not be a factor anymore. My idea for the newnavradio was to traverse the scenegraph along the straight line between sender and receiver and probe for ground intersection. This is basically the functionality as the probe for ground elevation, which could be reused. The difference of performance impact is dozens or even hundrets of scenegraph traversals compared to just one. You are correct. However your results would not be the same, and would be more inaccurate to those generated by ITM calculations. - Landcover Landcover contributes only neglible compared to terrain obscucarion to the loss of signal strength. Correct on lower VHF frequencies, incorrect as we move up into UHF. Can provide results and research papers to prove this. As far as the signal is line-of-sight, only intrusion into the first Fresnel zone is of interest. When diffraction over terrain edges are involved, I can assure you landcover plays a big role. - Coding style * You copied parts of the terrain sampler from advanced weather. Better reuse existing code, probably modify so it suits both usecases. * Using long chains of if/else or switch/case makes code hard to read and is usually a good indication for a flaw in the software design. * I prefer named constants instead of numbers to imporve readability. I will not discuss coding style here, only functionality. This implementation only adds a pseudo-realistic radio propagation simulation due to lack of real data It is the most realistic radio simulation that can be obtained. Please explain more about lack of real data, so I know what to research further. at the cost of cpu intensive calculations and a complex new subsystem that has to be maintained over the time. It's true, it's CPU intensive, and quite complex. Are you thinking only about recreational usage of Flightgear, or other purposes as well? I'm thinking of other applications besides recreational usage, but in any case, enabling this subsystem causes a 3-5 FPS drop on my 5 year old machine. The same pseude-realism could be achived by implementing an approximation for signal attenuation for line of sight and obscured propagation paths (probably as simple as distance-squared and distance-to-the-power-of-something). No. I have written a
Re: [Flightgear-devel] Real-Time Radio Propagation
In some cases, the used algorithm is plain wrong as we know by definition (ICAO rules) the propagation of the radio signal. Um... I would like to understand this statement. The algorithm has a physics model in. I am no expert in radio propagation, but after doing a bit of reading, by usual FG standards it seems to be a fairly sophisticated one. Which may still yield the wrong result now and then - but how can we know reality by definition? I understand how to judge the quality of a physics model by comparison with a measurement, but I don't understand how to judge the quality by comparing with a definition. I mean, if a signal doesn't propagate physically, then you can define whatever you like, it's not going to make it happen. Is it possible to educate me here? Does the simulator compute the same value as I would expect in the same situation in real life? I strongly doubt the algorithm together with our limited set of data can provide this. I think that's not a fair question to ask. Does any rendering scheme produce the light we would expect in the same situation in real life? Just barely sometimes, usually not. Does YaSim produce correct stall behaviour as we would expect in real life? I sort of doubt this. Isn't 'Is this better than the existing (or proposed) alternative?' rather than 'Is this 100% correct?' the more relevant question? Suppose we'd implement your counter-proposal implementing a single LOS check - how easy would it be to come up with test cases in which this yields wrong results? Judging by Adrian's posts, he seems to know quite well where LOS doesn't work. This may be difficult to do in practice, but at least conceptually the most realistic code is the one which gets most comparisons with reality right. So we'd really move away from single case evidence to a study of ~20 or so test cases in which we know the true result to say what is more realistic, otherwise at least I find this incredibly hard to judge. This is basically the functionality as the probe for ground elevation, which could be reused. The difference of performance impact is dozens or even hundrets of scenegraph traversals compared to just one. Somewhat related to the above - *if* the radio propagation model could be shown to be more realistic - what framerate loss would this be worth as compared to a faster, less realistic model? And does this question matter at all if this is implemented optionally - should not the user decide this? Neither your implementation nor my suggestion provides a realistic prediction of the radio signal quality, both are more or less approximations. It's the gain/pain ratio that differs significantly. I'm sorry, I don't see that from what you have written. Is there evidence to suggest that a LOS algorithm would be an approximation *of the same quality* as far as realism is concerned? I do appreciate that it is a much faster approximation. Oh - one last thing: Committing code just because somebody spent much time writing it or not committing would be discouraging should never be a reason to do so. I don't think I said that. I sure didn't mean it. My point is - suppose someone wants to write an ICBM simulation. Given the civil aviation nature of FG, that code has pretty much zero chance of being committed. It would be fair to let the person proposing to do this know that fact up front, and not wait a year till the code is developed and in a merge request. Making someone spend a lot of time if it can be known up front that the contribution is going to be rejected is unfair. Being unfair sends a discouraging message to others. That's what I am saying. (With regard to Adrian's code, I am well aware that factors like style, performance,... are also relevant). * 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
[Flightgear-devel] Iceland textures
If anyone likes flying in Iceland - the current state of Iceland regional texturing is now on GIT with the region-specific materials file - use with Atmospheric Light Scattering, Transition Effects to max. for best effect - otherwise the endless lava fields and glaciers have very strong tiling artefacts - and procedural texturing helps a lot suppressing those. * 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] Sound bugfix and Jenkins
On Thu, 13 Dec 2012, James Turner wrote: On 13 Dec 2012, at 09:02, Renk Thorsten wrote: Jenkins FlightGear-Win64-CMake build history: #220 (pending - All nodes of label 'x64' are offline ) Last build (#219), 3 days 9 hr ago Shouldn't have the fix propagated to a new Win64 binary by now? Gene upgraded the Jenkins master at the weekend and it seems the Windows slaves haven't reconnected since. I'm travelling later today, but I'll send Gene a note now. The issue was caused by the failure of a DEC power controller that I had powering the rack. I just checked and it's building again. 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] Real-Time Radio Propagation
On Thu, 13 Dec 2012, Adrian Musceac wrote: Please forgive my my clear words - it's not my intention to offend anybody. No offence taken. I understand your pain/gain argument and we agree to disagree on that. The pain is now taken care of, the gain is present. You are one of the project leaders, not me, so I must submit to whatever decisions you take. 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. :) 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. 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] Real-Time Radio Propagation
On Wed, 12 Dec 2012 23:03:45 -, Vivian wrote in message 001201cdd8bc$f5eb6b30$e1c24190$@lineone.net: Don't we need radar altitude for buildings etc. for radar altimeters, but probably not trees? ..at some stage, tree canopies will be dense enough to mask the ground, or give double reflections, or some such. A radar altimeter needs to sample both the terrain and hard objects on it. ..tree canopies dense enough to mask the ground, are probably hard enough to make radar vendors scare their clients from touching or ignoring them. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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 Thu, 13 Dec 2012 16:29:49 +0200, Adrian wrote in message 201212131629.50248.kanto...@gmail.com: On Thursday, December 13, 2012 15:04:16 Renk Thorsten wrote: Somewhat related to the above - *if* the radio propagation model could be shown to be more realistic - what framerate loss would this be worth as compared to a faster, less realistic model? And does this question matter at all if this is implemented optionally - should not the user decide this? Hi Thorsten, Torsten, all, Regarding the performance, you are correct, the user can decide on what to spend the CPU cycles. But for the sake of documenting this issue, I have performed a test: The test is performed in standard condition: on ground, all terrain finished loading, visibility set to 40 miles, LOD range bare 6 meters, 3 stations tuned, each at limit of loaded terrain, approx 100 km medium distance to them. First image shows subsystem enabled, second shows subsystem disabled. I have highlighted with red the relevant areas in the images. As always, click for details. http://wiki.flightgear.org/File:Radio-perf7b.png Radio subsystem enabled. http://wiki.flightgear.org/File:Radio-perf9b.png Radio subsystem disabled. Notice DME indication has appeared. In both cases, the FPS observed was 39. In long flight tests, the FPS difference is more like 3-5 from disabled to enabled. Now, regarding terrain influence, modes of propagation, and clutter influence on diffraction at different frequencies, you can observe the details on the upper left of the images. I won't get into details anymore, because I have done that already in a couple of messages. If anyone wishes to add more information on the subject of performance, I invite you to use the wiki page: http://wiki.flightgear.org/Talk:Radio_propagation I'm open to any other technical questions regarding the radio propagation algorithms used. ..maybe add a commandline suggestion so we can hope to compare apples with apples and pears with pears etc? Without a commandline suggestion, you pile up all sorts of irrelevant factors such as which runway you took off from etc, whereby you may load a different set of tiles, _etc_. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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
[Flightgear-devel] ..coding style conversion ideas, was: Real-Time Radio Propagation
On Thu, 13 Dec 2012 13:04:16 +, Renk wrote in message e495a106ff5f31448739e79d34138c191e179...@mbs3.ad.jyu.fi: (With regard to Adrian's code, I am well aware that factors like style, performance,... are also relevant). ..given the diverse coder background here, with ditto diverse coding style backgrounds, I found reason to google and wound up with 'Emacs coding style conversion script' and found this: http://news.ycombinator.com/item?id=1654164 (scroll down to): I really wish I could find something for Emacs which automatically detects the style of the code I'm editing and switches the coding style to that. ..motivations, orthodoxy, etc: http://www.kernel.org/doc/Documentation/CodingStyle http://coding.smashingmagazine.com/2012/10/25/why-coding-style-matters/ http://www.yolinux.com/TUTORIALS/LinuxTutorialC++CodingStyle.html -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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 With an ati 5870 on win7 64bit the transition effect is not working as expected. I get what is best described as fast flickering artifacts... but have a look at the screen shoots yourself. http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/fgfs%20bugs/fgfs2012-12-1323-40-34-02.jpg http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/fgfs%20bugs/fgfs2012-12-1323-40-37-19.jpg http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/fgfs%20bugs/fgfs2012-12-1323-41-10-13.jpg This is with latest git from today. Oliver 2012/12/13 Renk Thorsten thorsten.i.r...@jyu.fi If anyone likes flying in Iceland - the current state of Iceland regional texturing is now on GIT with the region-specific materials file - use with Atmospheric Light Scattering, Transition Effects to max. for best effect - otherwise the endless lava fields and glaciers have very strong tiling artefacts - and procedural texturing helps a lot suppressing those. * 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 -- 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 Thursday, December 13, 2012 12:44:00 Torsten Dreyer wrote: Hi - Performance The most important limiting factor for radio propagation on VHF and up is question line of sight or obscured by terrain. Hi again Torsten, Apologising for keeping this subject up, but I rather enjoy technical discussions, especially based on tested mathematical models and data gathered in the field. Here is what technical knowledge has to say about line-of- sight at VHF (or even higher frequencies): ### Terrain features, and buildings, usually attenuate signals. (NB in some circumstances knife edge diffraction can enhance propagation beyond the horizon)### (from http://goo.gl/1la6M ) You can read more about Longley Rice there, especially the part where Longley Rice has been adopted as a standard by the FCC. Now for real data gathered by me in the field, which is consistent with ITM plots generated for the same locations. Case #1: Have one radio repeater station on 145 MHz, completely obstructed by a mountain edge. Distance between repeater site and mountain edge: ~40 km. As determined by me, acceptable and readable signal was present as low as 500 meters below the mountain edge: single horizon diffraction case. The mountain edge had no vegetation. Case #2: Have one radio repeater station on 440 MHz, completely obstructed by a mountain edge. Distance between repeater site and mountain edge: ~50 km. As determined by me, acceptable and readable signal was present as low as 300 meters below the mountain edge: single horizon diffraction case. The mountain edge had no vegetation. In both cases, no line of sight was ever present between the mobile station and the fixed station, and reflection was not possible. All signal was received from diffraction. Double horizon diffraction is possible too, depending on many factors, including how much power are you pumping into the transmitter. Sidney Shumate's improvements to the ITM, published in the latest IEEE Broadcast society newsletters, make this model the most reliable for irregular terrain. Unfortunately his modifications have a non commercial clause, but you can download, compile and test against the classic versions. Diffraction results will coincide with physical data gathered even more. I think we can close the optical line-of-sight debate now. Cheers, Adrian Regards, 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] Iceland textures
With an ati 5870 on win7 64bit the transition effect is not working as expected. I get what is best described as fast flickering artifacts... but have a look at the screen shoots yourself. http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/fgfs%20bugs/fgfs2012-12-1323-40-34-02.jpg http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/fgfs%20bugs/fgfs2012-12-1323-40-37-19.jpg http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/fgfs%20bugs/fgfs2012-12-1323-41-10-13.jpg 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. 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
