I wrote: > Subject: Re: [Flightgear-devel] Object avoidance > > > 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. >
Well, it works. Not as lightweight as I had hoped, but I have developed a reasonably faithful simulation of the Blue Parrot radar (as fitted to the Buccaneer) Terrain Warning mode. The patch is here: ftp://abbeytheatre2.org.uk/fgfs/TerrainWarning/ It simulates a radar beam fixed to the ac centreline with -2 deg tilt. The beam dimensions are +-2 deg in elevation and +-1 deg in azimuth. If ground is detected within this beam at less than 4000m and greater than 250m then the terrain warning is triggered. These parameters and others, are all settable in the property tree. But excessive beam width, or too-small steps will result in a frame rate hit. The default settings are pretty much free. The air-to-ground radar is a sub-class of the weather radar class, so all the modes available there are also available in the air-to-ground radar. Blue Parrot has other modes, which I will develop in due course. If anyone can describe modes of other radars then I will consider them for inclusion. This development would not have been possible without Tim Moore's guidance when I got stuck a couple of times, and AJ's testing. AJ has also provided some lovely instrumentation for the Buccaneer to make use of this utility and which is already in cvs. I hope the air-to-ground radar will follow shortly. 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
