David wrote: > As others have mentioned, though, that point moves around during > flight depending on how the plane is loaded, how much fuel you've > burned, whether you're subsonic or supersonic, whether the flaps > are extended, whether you've just dropped skydivers or a bomb, > etc. etc. In a Cessna 150, the change is going to be very small; in a > supersonic bomber, the change might be very, very large (I'm just > guessing, though).
The CG moves around with this, but not the aerodynamic reference point. And, yes, this is why the CG isn't really a good reference point. > That's why we need to establish a fixed reference point for each aero > model (it doesn't matter where, though I prefer the published FAA > weight and balance datum) and then report the offset from the C.G. to > that reference point every frame. The A/C 3D code simply has to apply > that offset so that the centre of rotation (and the plane) is always > in the right spot. 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. We all know that we can rotate the 3D model correctly, but the issue is the translation. JSBSim reports the location of the CG, which is NOT the translation for any point on the aircraft, but ONLY the CG. 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". 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! Jon
smime.p7s
Description: application/pkcs7-signature
