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