Lee > Subject: Re: [Flightgear-devel] Object avoidance > > > On Sunday 17 February 2008 11:35, Vivian Meazza wrote: > > Markus > > > > > Subject: Re: [Flightgear-devel] Object avoidance > > > > > > LeeE wrote: > > > > On Friday 15 February 2008 17:08, Melchior FRANZ wrote: > > > >> * R. van Steenbergen -- Friday 15 February 2008: > > > >>> Melchior FRANZ wrote: > > > >>>> ...you could abuse that by > > > >>>> launching an invisible, lightweight, and very fast submodel, > > > >>>> and check where and at which altitude it lands. > > > >>> > > > >>> Don't they call that 'radar' in real life? :) (The very fast, > > > >>> lightweight submodels being microwave photons in that > > > >>> case) > > > >> > > > >> Hehe, yes. Except that ours don't come back. And I'm not > > > > > > sure if they > > > > > > >> collide with static/random buildings. They hardly do with > > > > > > trees. Hmm > > > > > > >> ... cows? > > > >> > > > >> m. > > > > > > > > Markus Zojer has used this technique for the TFA > functions in the > > > > B-1B. I had a look at it and experimented with it when > I wanted > > > > to add TFA to a couple of aircraft I've done - it's a very > > > > appealing approach because it's almost like simulating a real > > > > radar. > > > > > > > > I had a play with the technique but hit some problems with it, > > > > mainly because the trajectory of the submodels is fixed to the > > > > pitch of the aircraft. I found it fine while the > aircraft was in > > > > level flight but I hit some issues when the aircraft > was pitched > > > > up or down to any significant degree and in the end I > decided to > > > > use the Nasal geo functions instead. > > > > > > I am still working on the terrain following function, > rewriting it > > > completely for the 3rd time and again used "the real radar" > > > approach, as you are not dependent in the scanning > resolution of the > > > geo properties. The fixed radar beam (submodels) could be refined > > > if we would add the > > > property absolute to the pitch angle of the submodel (so the > > > submodel > > > leaves the plane at always the same pitch angle). > > > > > > Due to the ongoing environment development in OSG, now low level > > > flying is really flashing :) > > > > > > Expect the new version included in the next release (coming > > > hopefully within the next 10 days). > > > > > > Fly on, > > > Markus > > > > > > > As I mentioned previously, the geo functions do interact with > > > > static buildings and structures, as long as the scanning scheme > > > > has a high enough resolution to ensure sampling them - > I haven't > > > > tried with random objects though - still on OSG 2.2 > here and the > > > > performance hit when using > > > > OSG_DATABASE_PAGER_DRAWABLE=VertexArrays is too great here. > > > > > > > > I have noticed that pylons are not detected and I would > doubt that > > > > trees are detected either, presumably because they have > no area. > > > > The pylons are made with line objects that have no > width and the > > > > trees, at least in plan, also have no width, so it'll be very > > > > unlikely to hit the exact point where they are in any scanning > > > > scheme. Adding a transparent horizontal plane poly to > the top of > > > > these objects probably would make it work, but not only > would it > > > > increase the render load but also probably introduce more > > > > transparency render artifacts and ordering issues. > > > > OK I can give you submodels which are stabilised in pitch > within a few > > days, if this is really a good approach - submodels are a big frame > > rate hit. > > > > Would an alternative be to duplicate the code which calculates the > > ground intersection for submodels, without the cost of "flying" the > > submodel? This approach would take more coding, but might be less > > frame rate intensive. However, the methods which are used > are some of > > the most frame rate heavy around so perhaps in practice not too > > different. > > > > Vivian > > It is an attractive approach because it is very similar to the way > that real radar works and it's fun to add a visible model to the > pulses so you can see them:) > > Some of the problems I found with it though, include the high > submodel overhead. Even in level flight I found I needed to 'fire' > pulses in a vertical fan, both above and below the line of flight, > to ensure detection of higher ground, especially if the aircraft is > pitched down to any significant degree. However, if there isn't > any higher ground within range, which will be the case unless you > only fly in mountainous regions, a high proportion of the pulses > will never hit anything and will only expire at the end of their > lifetime - this seemed like an unnecessary overhead. > > I also hit some problems with the resolution of the pulses, this > seeming to be tied to the pulse speed, the aircraft speed and the > frame-rate, because the location of the pulse can only be checked > once per frame. For example, if you use a pulse speed of 10000m/s > and you are running at 20fps the effective resolution of the pulses > (if the aircraft is stationary) will be 10000/20 = 500m. > > Furthermore, once the aircraft speed is added to the pulse speed, > because the pulse speed is relative to the aircraft speed, the > resolution reduces as airspeed increases (this is also a factor in > the Nasal geo solution I've done but in 'continuous' mode it is > ameliorated to a large degree by multiple scans of the same area > and in practice, and using the elevation markers to show the > high-elevation points, it usually manages to find ridge-lines and > buildings/bridges etc with a high degree of accuracy) On top of > that, the frame-rate varies so the resolution becomes > indeterminate. Using a slower pulse speed increases the resolution > but also increases the submodel overhead because they need a longer > lifetime to reach the same scanning distance whilst simultaneously > increasing the time before you get a 'return' and thus reducing the > time available to react:( > > It _is_ an attractive approach but I think the cons outweigh the > pros. >
I think I agree. Tim Moore has pointed out a totally unused and untested utility in OSG which has been ported into FG, and which looks as if it might do exactly what we want (with a bit of massaging as ever). It says that it is reasonably lightweight, but has absolutely no documentation. So, and I probably need my head examining, I'm going to see if we can't do this job properly. Vivian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
