Hi Adrian, On Wed, Dec 12, 2012 at 10:12 PM, Adrian Musceac wrote: > 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)
I haven't looked at your code, and I'm sure you've already taken care of this, but: The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings is probably due to my ignorance when writing the code, and I certainly agree that the trees shouldn't have this bit set. The v2.8.0 random buildings were a simply geometry built at runtime, and IIRC people were enjoying landing helicopters on the top of them. However, the current git random buildings use a shader instantiation approach very similar to the trees. I think that means that the shouldn't be considered with the FG_NODEMASK_TERRAIN_BIT either, as the geometry itself isn't placed correctly in the scenegraph. Therefore, I think they shouldn't be considered in the get_elevation_m/groundcache/bounding box code. I think the random objects _do_ need to be included so they can be included in collision calculations. On the more general subject, I have two comments, both as a layman so take with a suitable pinch of salt! 1) I think the most important attribute of the radio code is that one can complete a published approach. I assume that approaches are specifically designed and built such that there in sufficient signal strength within some volume around the "perfect approach". My concern with any advanced model is that invalid/inaccurate terrain/elevation input into the model might mean that we get too low a signal, and some approaches might no-longer be possible to fly due to (incorrectly) low signal strength. Adrian: Is that a reasonable concern, or are approaches designed such that there is always line-of-site between the station and the aircraft on the approach (and therefore any terrain interaction is irrelevant within the approach volume)? 2) Assuming we're only interested in terrain effects, then it would seem that the signal strength at a given point (lat/lon/alt) for a given station is invariant. Would it be possible to avoid the runtime hit by calculating it offline for all points within reasonable range of the station? One might be able to create a bitmap storing the minimum signal altitude (i.e. the altitude below which there is no signal due to terrain), the maximum signal strength, the altitude that occurs, etc. and then use these as parameters into a straightforward function to determine the signal strength at the current altitude. One could then overlay the published approach volumes and thereby ensure that aircraft within the approach volume receive valid signal strength. -Stuart ------------------------------------------------------------------------------ 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
