David Megginson wrote:
> > Wolfram Kuss writes:
> > > Are r,p,h relative to the plane or the current view?
>
> I imagine two RPH vectors: the main vector (which would in some cases
> be the orientation of the plane) and the offset vector, which are
> relative to the main ones. For the pilot view, the main vector would
> be the plane's RPH, and the offsets would be relative to that; for the
> tower view, the main vector would usually be 0,0,0.
It's just occurred to me that we may want to back off on the 100%
general view solution. One immediate problem is that the euler angle
conventions, in face, depend on context.
Inside the cockpit, when you move the view to the left (by moving the
mouse or hat switch to the left), you expect the "forward" view vector
to rotate to the left. In a chase view, when you push left you really
mean for the *viewer* to move left, as if stepping to the left around
the aircraft. Likewise for pitching up and down -- the directions are
reversed.
I'm thinking that maybe it would be simpler to hard-code the three
"canonical" flight simulator view types, and have them interpret the
input properties as needed:
+ Out-of-the cockpit view, with the origin based on the pilot's eye
position plus a settable offset and the view direction modifiable
via the view Eulers in the normal sense.
+ External/chase view, with the origin fixed at some settable radius
from the aircraft, the offset limited to a 1D change in radius, and
the view eulers interpreted in a negated sense.
+ Tower view, with the origin fixed to some location on the earth, the
view direction fixed to point at the aircraft, and the offset
ignored.
There's no reason that these couldn't be arbitrarily modifiable and/or
scripted at runtime, so that there are multiple external views, a
copilot cockpit, a quat-slerped "animated" chase plane view, a tower
view that always snaps to the closest airport, etc... But it strikes
me that all of the views we'll want to implement are just variations
on one of these three themes. If so, doing anything more general
strikes me as only adding complexity.
So, you'll have a possible "static" view configuration property layout
(forgive me for not using XML syntax -- I'm lazy) like:
/sim/views[0]/type=cockpit # normal cockpit
/sim/views[1]/type=cockpit # copilot, and zoomed
fov-deg=20
offset-y-m=2
/sim/views[2]/type=external
offset-r-m=100
/sim/views[3]/type=tower
airport=KSFO # A symbolic location...
lat=37.nnnnn # ... or absolute
lon=-122.nnn
All of which would interpret the following input properties in their
own way (are these "controls" or something else?):
/controls/view/rotate-deg # left/right
pitch-deg # up/down
tilt-deg # cw/ccw
zoom # magnification factor, unitless
offset-x-m
offset-y-m
offset-z-m
offset-r-m # radius, for external views
Changing views would probably just reset these all to zero. Or maybe,
if we wanted to be fancy, would could have a separate
/controls/view[n] tree for each defined view. Or cache the values
upon exiting , so they can be restored when we get back, or...
Andy
--
Andrew J. Ross NextBus 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
