Jon S Berndt wrote:
Yes. I think several people are unclear about how this will work, and have concerns like "If we make the nose the reference point, then the aircraft will appear to wag because the viewer code doesn't know about the offset". That won't happen if we identify a communication problem within the software and fix it properly. The way I see it is:
Well, with proper agreement and reference point, we can make this perfect. There's just some communication and cooperation needed for a little while, and I think we are nearly there.
WHAT TO DO:
Wherever an "aircraft position"* is sent from one part of Flight Gear (e.g. an FDM) to another part (e.g. the part that positions the graphical model in the scene graph), we must define exactly what that "position" means as part of the definition of the interface function or variable or property, AND ALSO modify the data provider if necessary to ensure that it provides that particular position, and modify the receiver if necessary to ensure that it converts the position it is given into the position that it really wants. (Don't worry about the performance cost of two extra 3D transforms per frame.)
Example:
- We choose first to tackle the aircraft position reported by FDMs to Flight Gear.
- We choose the tip of the nose for that particular interface, and write "position of tip of nose" in a comment by the declaration, or preferably incorporate "NoseTip" into the name of the function or variable or property.
- In this example Jon would leave most of JSBsim as it is, generating the position of the centre of gravity, but he would add a little function to convert "position of C of G" to "position of nose" just before publishing the value to Flight Gear.
- Someone would modify the function that updates the Flight Gear scene graph so that it puts the model geometry at the right position, by transforming from "position of nose" to "origin of geometry" (which will be different for each aircraft geometry model). Similarly, any other parts of Flight Gear that use this data must be checked and modified if necessary.
HOW TO DO IT:
We need data for the 3D transforms. Jon would need to know the position of the nose relative to the C of G, and he would probably get this in two or three steps: transform from C of G to the aero reference point, which he knows already; and then transform from the aero reference point to the nose. This relative position will have to be added to the JSBsim config files if it cannot be calculated from data already there.
On the other side, putting the geometry into the scene graph at the specified position will involve converting from position of nose to origin of geometry; that transform would need to be read from the geometry file or the aircraft config file.
Clearly the reference point for an interface should be one that both sides can reasonably understand. It is likely that it will have to be specified (differently) on both sides of the interface: nose relative to aerodynamic origin, and nose relative to geometry origin. It is not practical to get all FDM authors AND all geometry authors to use the same origin natively.
By precisely defining an interface and providing the conversion offsets as data in an appropriate place, we can eliminate the errors. There is no need for arbitrary approximations to occur by design of the Flight Gear program architecture, but approximations may still occur due to lack of data. For example, to avoid having to update all config files at once, we might put in the geometry-reading subsystem something like "if this geometry file does not specify the position of the nose, then use the average vertical coordinate and the front-most horizontal coordinate".
Then move on to another interface, such as the camera/eye position, and go through the same thing. Where do we want the camera or eye to be (or to be looking towards)? Do we have the information that specifies the eye position relative to a known position? If not, it must be added to the aircraft config file (probable for the eye position) or calculated at run time (possible for a camera look-at point).
Perhaps Curt or David M could kick-start the process by defining the meaning of one of those interface functions. You can't ask an FDM author to choose the reference point because they are all biased, and none of us "lesser mortals" would dare submit a patch for such a wide-reaching change. But if we want to share models across different FDMs then this work will have to be done.
* Note that wherever I said "position" or "point" I should have said "coordinate system" or "set of axes" to include orientation as well, because especially the pitch attitude of an aircraft could easily suffer the same kind of ambiguity.
- Julian
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
