Curtis L. Olson writes: > - we have a pilot view point offset from the CG. Right now this is > handled in the view code, but perhaps this would make more sense to > move to some code specific to the instance of the current > aircraft.
Perhaps, but that will require other modules to do matrix manipulations, because the offset is relative to the rotated axes, not the world-up axes. > For internal views, a heading and pitch offset to the view makes > sense. And roll, for that matter -- I don't see any good reason to leave out one degree of freedom. Think of a tail-gunner view in a bomber for one example of where we might want a roll offset. > For external views, we shouldn't use this heading/pitch offset and we > should manage the actual view point as offset from the aircraft CG > somewhere else and just feed the view code an eye point and a "lookat" > vector. If we use a pitch/heading offset for the external view, it > should pitch/yaw the view away from the aircraft in the center of the > screen. Exactly. Most of the code will still be the same, so I think that it makes sense to handle this all in one configurable viewer. > The 'position offset' to me seems to make more sense living elsewhere > (although we may not have a more appropriate place for it at the > moment.) But remember that the offset is, again, in the rotated axes, not the world-up ones. It makes sense to centralize the 3D math in the viewer class and not spread it around. The logic for calculating the position offsets may live elsewhere, of course, but it makes sense to let the viewer calculate the actual transformation from the reference geodetic position, since it will already have rotation and transformation matrices set up. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
