Adrian wrote > -----Original Message----- > From: Musceac [mailto:kanto...@gmail.com] > Sent: 12 December 2012 22:12 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Real-Time Radio Propagation > > On Wednesday, December 12, 2012 09:16:50 Renk Thorsten wrote: > > >> My suggestion is to include this feature, leave it off, and let > > >> anyone interested turn it on. > > > > +1 > > > > There may be many reasons to reject code, but they roughly fall into > > two > > categories: 1) the idea itself which is coded is not acceptable or 2) > > the actual implementation is not acceptable (unstable, degrading > > performance,...). Adrian has invested a fair share of time to make it > > work, and he introduced the project early on in this list. I think > > fairness asks that any argument of type 1) against including the code > > should have been given earlier. Otherwise the message sent to possible > > future contributors is quite negative. > > > > > That said, I think doing realtime radio signal propagations is much > > > more that we need and much more than we want. At least unless we are > > > multi-threading and have a spare CPU for those computations. > > > > Personally I don't need such a feature, since I'm not so much > > interested in IFR. However, I think in many situations we do have > > spare CPU capacity (I usually do - with lots of shader work on, GPU > > speed seems the limiting factor), and I also think it should be up to > > the user how he wants to burn his hardware performance - VFR > > sightseeing people like me want detailed shaders, IFR people may want > > to turn terrain eye candy off but spend the framerate for radio signal > > propagation. So including the code as optional feature seems entirely > > fine to me, I don't think there's such a well-defined 'we' with the same > wishlist. > > > > So I would also suggest to include it unless there are issues about > > stability, performance degradation if not running, .... which I'm not > > qualified to judge. > > > > * Thorsten > > Hi Thorsten, everybody, > > Thanks for the support messages. I have worked pretty hard to get this > feature as stable and performant as possible. > Regarding performance of the radio subsystem, I would like to make a > technical statement. > > 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) > > Right now, I've modified the _get_elevation_ method to use only this new > mask. > The performance difference is almost twice as fast, if not more. > However, since this might introduce unwanted changes in parts of the code > that rely on having radar altitude also from buildings etc., I can write a new > function to be used specifically for sampling terrain. > > I have performed a regular test, with the following parameters: terrain load > distance set to 60 km (LOD bare), 3 stations tuned in (2 VOR, 1 VOR-DME), 10 > or more minutes of flight. > > Result here: http://wiki.flightgear.org/File:Radio-perf2.png (enlarge for > details). As you might notice, the radio subsystem is not the CPU cycle > hungry monster it used to be. The amount of tiles loaded is shown on the > map. > With less view distance and less terrain, the system will be very CPU friendly > but also give innacurate results. > > Keep in mind that are various other methods to reduce even further the CPU > footprint: sample fewer points for an elevation profile, poll a station less > often (what polling time would be reasonable for a mean speed of 200 kts?) > and disabling landcover influence. >
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 ------------------------------------------------------------------------------ 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
