Thanks for stabilized submodels, makes them more versatile. Using 2 beams of each 5 submodels per second (max 10 submodels at a time together, norm 4 -8) I could not monitor a frame rate drop (ok, maybe in the 1-3fps scale, but that is hardly monitorable as you never know where it is coming from), maybe because no visible model is attached.
Fly on, Markus 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 > > > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- 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
