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