Re: [Flightgear-devel] Yasim origin and model offsets
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.
...
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?
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.
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.
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.
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,
[Flightgear-devel] Yasim origin and model offsets
It seems that a while back this came up when I was working on the viewer or maybe tweaking the original 3D aircraft model rotations. After moving the AC3D model origin to where Yasim wants it (at the nose) the aircraft rotates fine. (Note that it appears the gear still compresses abit too much as when doing Curt's throw on the breaks at 40kts test, the nose comes very close to the ground). 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. So if the nose goes up so does the camera. In the air, this gives the _appearance_ that the nose is stationary during a pitch, and the 3D aircraft model moves with a kind of a wagging motion rather than a pitching motion. I understand that the motion of the aircraft is correct and the 3D model moves correctly when it matches the FDM, the problem is the way it looks on the screen when the origin is at one end of aircraft. Also, a bug report, for some reason the model offsets (e.g. /offsets/x-m) appear to no longer work. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim origin and model offsets
At 11/9/02, Jim Wilson wrote: It seems that a while back this came up when I was working on the viewer or maybe tweaking the original 3D aircraft model rotations. After moving the AC3D model origin to where Yasim wants it (at the nose) the aircraft rotates fine. (Note that it appears the gear still compresses abit too much as when doing Curt's throw on the breaks at 40kts test, the nose comes very close to the ground). 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. So if the nose goes up so does the camera. In the air, this gives the _appearance_ that the nose is stationary during a pitch, and the 3D aircraft model moves with a kind of a wagging motion rather than a pitching motion. I understand that the motion of the aircraft is correct and the 3D model moves correctly when it matches the FDM, the problem is the way it looks on the screen when the origin is at one end of aircraft. Also, a bug report, for some reason the model offsets (e.g. /offsets/x-m) appear to no longer work. FWIW I have looked at the offsets before. At one point they did work w/ the UIUC models, but I think more recently (last 4-5 months) they stopped working w/ the UIUC models. However, at that time, they did work w/ the other models. So I speculate that the bug seems to be FDM specific. It *is* broken w/ the UIUC models. Regards, Michael Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim origin and model offsets
Jim Wilson wrote: After moving the AC3D model origin to where Yasim wants it (at the nose) the aircraft rotates fine. (Note that it appears the gear still compresses abit too much as when doing Curt's throw on the breaks at 40kts test, the nose comes very close to the ground). Yeah, the nose gear compresses by 2m, which is too far. I got better results by changing to compression=1 in the nose gear definition. But with that change it ends up too stiff, and tends to end up in an undamped oscillatory bounce on its nose gear. I need to get per-gear tunable spring constants and damping coefficients working; the automatically generated ones are almost, but not quite, good enough for all cases. 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. The tile rendering and navigation stuff obviously doesn't care about a few tens of meters, but the altitude computation in the HUD (which is different from the agl property) does, and it uses aircraft origin as well. 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? 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. 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. :) Andy -- Andrew J. RossNextBus 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
Re: [Flightgear-devel] Yasim origin and model offsets
Sigh ... I thought we had already solved this one http://www.menet.umn.edu/~curt/lists/fgfs/archive-200204/msg00176.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim origin and model offsets
I wrote: I need to get per-gear tunable spring constants and damping coefficients working; the automatically generated ones are almost, but not quite, good enough for all cases. Well, that was easy enough. You can now use spring and damp attributes on gear objects to modify the default ones you get out of the solver. These are unitless scalars, specify 0.5 if you want half the damping coeffient, etc... I've checked this in, as well as a change to the 747 nose gear that fixes the wobble and bounce issues. Someone with more experience than I should try the result to see that I got it right. The nose gear now just barely bottoms out when you whip the nose down from a tail dragging situation with full braking and full down elevator, comes up but doesn't leave the ground, and oscillates once or twice. That seems like it would be the design goal for the real thing, but I dunno. Maybe it should have more bounce? Some of the other YASim planes could probably use some gear treatment too. The default damping is probably too stiff for the 172 and Cub, which have spring steel gear. Andy -- Andrew J. RossNextBus 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
Re: [Flightgear-devel] Yasim origin and model offsets
Andy Ross [EMAIL PROTECTED] said: 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). Not sure, but it would seem like the pitch axis would generally be somewhat near the wings, which aren't always centered. Note to readers: To save folks from pointing this out yet again, we all know c.g isn't a fixed location. 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. :) Maybe it would be most economical, calculation wise, to do it that way? In the model/view code we'd have to throw another offset in the mix. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
