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