Re: [Flightgear-devel] Grass and Dirt material declaration
Hi Thorsten, I added these materials, originally with lower-case (unused). Then I wanted to make them consistent with the other landcover names and changed to capitals, not taking care of the already existing names. So this introduced the problem. I corrected it some minutes ago and hope everything is fine again. Chris Renk Thorsten wrote: During the last weeks, someone added the 'Grass' landclass to the 'grass_raw' materials declaration and the 'Dirt' landclass to the 'dirt_rwy' declaration in/ Materials/regions/materials.xml. I would like to undo the changes, or discuss other solutions to fix the problems caused by them - my GIT knowledge isn't good enough to find who committed that, so please get in touch. The problems caused are as follows: * assigning 'Dirt' the dirt_rwy texture changed all rock textures in the summit regions of the Alps in the French custom scenery to dirt runway textures. I realize this isn't as it should be - potentially this could be a scenery-side issue that the summit regions are misclassified as 'Dirt' rather than 'Rock', although I think this unlikely. I've come across similar issues that some landclasses are not really separable - so by some weird effect setting Dirt also previously set Rock for me when I tried this a year ago. I have no good understanding of the underlying issue, but at least till the time this is clarified, I think the error of replacing rock by dirt runway is much worse than replacing dirt by rock. * assigning 'Grass' to 'grass_rwy' seems to suddenly reveal the fact that the green around our airport runways is two different landclasses. Since now 'Grass' gets a size of 75x75 but later AirportKeep Co get a size of 125x125 and in addition specular reflection coefficients, under the right light what formerly seemed a common green now shows pronounced differences in color and texture. For the same reason, the change spoils my RealGrass(TM) overlay texture scheme, which unfortunately inherits size and specular reflection and shows the same differences in an even worse way. I'm not quite sure why these two changes have been introduced, but maybe we can find a solution without such bad side effects? * 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 -- 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] Grass and Dirt material declaration
I corrected it some minutes ago and hope everything is fine again. Huh, that was fast, thanks. Airport green is looking good here. * 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] 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. 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
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
