On Fri, 2002-03-15 at 15:29, Andy Ross wrote: > Tony Peden wrote: > > Andy Ross wrote: > > > Tony Peden wrote: > > > > Only the gear model can and should "know" the path that the wheel > > > > follows as it compresses. > > > > > > I don't necessarily disagree, > > > > But by asking the scenery code to do the intersection for you, that's > > exaclty what you are doing, AFAICT. > > Well, to be fair, this is a hard problem. If we allow for the scenery > to be an arbitrary 3D mesh, *and* allow the gear to compress along > funny non-linear trajectories, we have a lot of complexity to deal > with. We either have to have scenery code that understands funny gear > trajectories or gear code that understands 3D collision detection.
Either there's something I'm really missing or you're making the problem way harder than it is. > > My suggestion works fine for the simple linear-compression situation > that works for most aircraft, and allows for an iterative, "probing" > metaphor in situations where it doesn't. > > That is, break the compression trajectory into small pieces and test > each one of those for intersections. Note that the pieces don't have > to be any smaller than the integration sampling wavelength, or about > 0.1m or so, so this is actually quite feasible. This gets you a > "perfect" gear simulation down to the level of integration > granulatity, which is good for all purposes. > > > > but I'm at a loss for how you get this effect by assuming that gear > > > compression is always along a line normal to the ground plane? > > > > I wouldn't make this argument, I'd say it's reasonable to assume > > *body* axis z compression only (though you shouldn't lock yourself > > into that, there are many examples where that's not the case, the F-18 > > and Cessna 172 being two), a very different thing. > > Bingo, here is the disconnect. The current terrain intersection code > gives you an altitude above the ground plane for each gear. That > allows only for compression along the ground's "up" axis, not the > body's. You could hack in a hybrid, but only by assuming flat ground > in the "area" under the gear. Why? Why does the area matter? We're talking points here. If we know the distance below ground of the contact point then we can call that the runway normal, transform it to body coords, and call the z component of that the oleo compression. > This assumption breaks under the same > circumstances that the flat ground assumption does, and thus doing > things this way just doesn't buy you much. > > I completely agree, by the way, that assuming the body frame > compression is always along the Z axis makes sense. In fact, while > YASim in principle supports any gear compression axis, I only bothered > supporting Z axis compression in the parser. > > I guess I'm just a little flummoxed at the resistance to doing things > "right" here. I don't see that that's the right way, and what you're proposing would require us to expose information that I think we shouldn't. > I mean, it doesn't take any more CPU time; it doesn't > make the FDM's job any more complicated, and it's reasonably > well-supported by the scenery code as-is. All that's needed is an > interface change and we're done. > > Andy > > -- > Andrew J. Ross NextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > _______________________________________________ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
