> 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.
Please no! No hardcoded views. I want to run FlightGear one day in RC
mode with tower view as a default view. If you think that somewhere in the
code you need to know type of view, there should be function
globals->get_current_view()->get_type()
>
> 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.
>
Heh, you can also to say that we need only one type of view.
You always look from one point towards another point and differnts
is only in how which one each point move.
> 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...
I suggest leave all view props in /sim/views/ tree
make under each view node default and current subtree and when you
switch between views load default values (this should be controled by some
property)
>
> Andy
Madr
--
Martin Dressler
e-mail: [EMAIL PROTECTED]
http://www.musicabona.com/
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
