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
