Andy Ross wrote:
Jim Wilson wrote:> Anyway, what I now remember is this: the camera position as configured > for the chase view is always in relation to the FDM location. And in > the case of Yasim that location is always the nose. Oh, good point. This will create problems for view direction too -- the viewer will expect to rotate around the "center" of the aircraft instead of the nose. But there are other places in the code that make assumptions about the "location" of the aircraft, too, and they have different requirements.
...
For some of them, definitely. The viewer (eye, camera) position for internal view must be quite precisely positioned, not just at the centre of the airframe. Also the altitude (AGL) of the wings for modeling ground effect. Many other things (measuring altitude for display, position relative to radio beacons, etc.) would be fine using any origin that is within the airframe.Or consider an ILS receiver, which really wants to use the location of the antenna on the 747, not the cockpit, c.g., or center. (I have no idea where this is, but I suspect it's closer to the tail, so that the main gear are what travel down the exact glidepath). Maybe we need separate origin offsets for all of these applications?
That would be suitable for the external views. The centre of gravity would also be fine. Use whichever is more conveniently available; there are already enough origins to choose from so don't calculate another unless it is necessary.Actually, wouldn't a sane default for the view code be to *always* pick a center point for the offset? That is, just pick the center of a bounding box computed from the model (or the FDM). This will match more closely to what the user expects in all cases I can think of.
It seems clear what ought to be done. Whenever a point on the aircraft is used for some calculation, it should specify exactly what point is required. The apparent obstacles to doing this are:
+ the required information is not available
+ concern about the run-time cost of additional calculation
+ the effort of thinking about what is required and implementing it
These can be tackled separately. For the first point, write stubs for the missing information so that it can be easily added later. Instead of this:
// Calc additional lift due to ground effect.
// Not sure exactly what FDM->getLocation() is supposed to return but it
// is about 1.2m below the C172's wings.
// Need to generalise this for other aircraft.
lift += calcGroundEffect(getTAS(), FDM->getLocation().height + 1.2);
write this:
// Calc additional lift due to ground effect.
lift += calcGroundEffect(getTAS(), getCentreOfLift().height);
Search for other bits of code that might already need the same information. If there are none, make a stub function at the top of the file (or somewhere more appropriate if you can):
// Stubs for missing information
vec3 getCentreOfLift() { return FDM->getLocationEmptyCofG() + 1.2 /* this is for C172 */; }
If there are already one or more uses, share the function.
For the second point, consider the run-time cost it in context. If it is expensive and the exact position is unimportant, make the stub do nothing, with a comment saying why.
Surely each aircraft geometry definition should be obliged to specify the position of the things we are interested in:
+ eye position of an average pilot (for internal view)
+ centre of lift (for ground effect)
+ nose, tail, wing tips (for crash detection, and for placing the model not overhanging the end of a runway)
+ landing gear when fully extended, and its compression behaviour (for ground handling)
+ centre of gravity when empty, and location of variable masses (fuel, people, baggage)
The definition file would specify these things relative to its own origin. If we cannot or do not wish to require all of these to be specified, the Flight Gear class that reads the model definitions could be made to guess reasonable values for the ones that are missing.
These statically specified offsets are all constant relative to the rigid airframe. At run time, we can provide variable ones as well:
class AircraftGeometry {
// Get location of various points as an offset relative to some arbitrary origin.
// User doesn't need to know what the arbitrary origin is; only differences between
// these offsets are meaningful.
vec3 getOffsetPilotEye(); // constant
vec3 getOffsetCentreOfLift(); // constant in simple models; may be variable
vec3 getOffsetNoseTip(); // constant
vec3 getOffsetLeft/RightWing/Tail/etc.();
vec3 getOffsetNoseGearExtended(); // constant
vec3 getOffsetNoseGearCurrent(); // variable
vec3 getOffsetEmptyCentreOfGravity(); // constant
vec3 getOffsetCurrentCentreOfGravity(); // variable
// and/or
vec3 getOffsetContactPoint(int n);
vec3 getOffsetVariableLoad(int n);
float getMassOfVariableLoad(int n);
// etc. as required.
}
Actually, since the offsets are relative to a particular set of axes, the user cannot just add them to a position in tile coordinates, so we should instead provide functions to convert one to another. No matter how it is presented, the principle is to be clear about which position is being stated, and which is wanted, and providing a framework for converting one to another, even if many of the conversions are initially null.
Oh dear ... sorry for all this "opinion" without any offer to do the work.
It sounds like that may be worth doing to make things look better in the short term.That being said, I'd be happy to put this to rest right now by moving the YASim origin for the 747 and A-4. :)
- Julian
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
