Jon Berndt <[EMAIL PROTECTED]> said: > Here's an example of the concern I have. Let's say you are doing your > takeoff run in a 747 and you have begun rotating. You have rotated to 10 > degrees pitch but have not yet left the ground. JSBSim reports the > location of the CG - this is the way generalized rigid body equations of > motion work (the movement of the center of gravity is calculated). So, the > rendering code has a pitch angle and the location of the center of > gravity. Now, since the CG of an aircraft is generally slightly ahead of > the wheels, when the 747 rotated it lifted the CG slightly. If the > aircraft model origin is at the nose of the 3D model in its coordinate > system, then merely pitching it up at 10 degrees and raising the origin by > the amount that the CG has raised will actually place the wheels and part > of the fuselage under the runway. The problem is that the nose is very far > ahead of the CG, and the 10 degree rotation at liftoff has lift the nose > very much higher than the CG. Right. In other words if the nose is the 3D model origin, it's "altitude" is made that of the CG (as reported by JSBSim). The aircraft is angled up for takeoff and the nose is way down near where the wheels should be and the rest of the model is below the surface. > So, the solution is that JSBSim (and other FDMs) could report the location > of the 3D model origin at every frame for rendering purposes. OR, > FlightGear could derive it - given it may have more intimate knowledge of > the 3D model AND the CG. True? Problem is, the FDM guys don't KNOW what > point will be chosen for the 3D model origin. The FDM could report the > position of any point in our own coordinate system. If we gave the > location of the nose as a commonly known reference point, then I believe > the rendering code could have that location to use as its "pivot point". >
That's right. But if the choose the nose (which I now agree is the way to go) and report the lon/lat/alt at that nose, then we'll be way ahead at least as far as getting JSBsim and YASim in sync. You are right about the options. We could perhaps do the conversion on fg side in the fginterface. > I hope I understand the problem correctly, and that this isn't muddying > the water. The above is a possible solution to one problem, though maybe > not this one? I just woke up! Better than I for a Monday morning :-) Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
