On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote: Hi Mathias, > Ok, for that, I can see a lot of solutions. > > Having one that is may be close: > Use the BVH tree that is used in fgelev or fgai. The fgelev one is > parametrized like you probably need today. There is one hacky switch in the > BVH paging that only loads terrain into a bounding volume tree.
I'm just using the get_elevation_m function from the scenery subsystem, inspired by Torsten's terrain sampler, but in a different way. This tests for nodes with SG_NODEMASK_TERRAIN_BIT set, which trees, houses, random buildings also have. Therefore I added a special bit only for surface SG_NODEMASK_TERRAIN_BIT, and accounted for it everywhere SG_NODEMASK_TERRAIN_BIT was referenced. This way subgraph traversal are an order of magnitude faster since they don't use other stuff generated by the BTG loader which have that bit set. If you want me to, I can place a simgear merge request and see what I changed and where wrt. traversal masks. > > Have two different bvh trees and making sure that these nodes are not > cached for scenery loading - since they are incomplete in the sense of > the visible viewer - would provide you what you need. > > Since you are doing radio stuff I expect that your main workhorse is a line > segment intersection which should be done best with this kind of structure. > True? > May be you need an other line segment visitor which measures the distance > that is covered by material. The principle is: have a general direction towards the radio station, go in that direction X meters (100-500 depending on setting) and get an elevation profile point. After acquiring a complete elevation profile for a path line, this is fed to the real algorithm which does all the hard calculations. > > Ok, what might block this approach is the amount of static variables that > is spread around. Already in face of reusability almost every > global/static variable can be a serious problem ... > > Look into fgelev and fgai and look for BVHPAger and its > getBoundingVolumes(sphere) method. > May be flightgear is not really ready for this kind of shared usage, but > the basic building blocks are there ... I'll have another look next week, it's a while since I studied that code. I don't think I need something more custom for now. The radio code is working just fine right now, but I'm definetly going to improve it in some areas, once it's merged. Featurewise, I'm not yet done either. I am also planning to get rid of the scenery subsystem dependency if possible. > Ok, in the end you might need an other custom approach. But just off my > head what I think is probably best algorithmically. > > Also keep in mind that tuesday is the deadline for new features for the > next release. I know, hence the whole discussion about this feature that took most of the mailing list space lately. Sorry about that. Let me know if you are interested in the traversal mask stuff that I have added to separate surface only, models, trees, random buildings etc. I can place a merge request tommmorow, but it has to go simultaneously in fg and simgear, since the traversal masks are used in both. Cheers, Adrian > > Greetings > > Mathias > ------------------------------------------------------------------------------ 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
