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. 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
