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