[A bunch of notes on Norm's notes. Basically, everything he wrote
(even the editorializing) makes sense to me, with a few exceptions as
detailed below]
Norman Vine wrote:
> Easy beans - no gimble lock - infinitely stackable orientations -
> everything has it's own logical spot - quick - elegant - natural
> orientation changes < ie slerp's > - the code is basically all in PLib
> for the using already - ect ....
Heh, you're a quat nut, huh? They're nice, but hardly necessary*.
The biggest difficulty is in picking the front-end interface, for
which quats basically suck. I want to have a hat switch mapping where
"left" becomes "subtract a little from view_offset". You can't expose
the quats to the user -- you need eulers for that, warts and all.
[* YASim doesn't bother, for example -- everything is stored as an
orientation matrix. A Graham-Schmidt normalization is more
expensive than a quaternion normalization, but no less stable.
And if you have to constantly convert to the matrix space anyway,
the performance gains are a wash.]
> Now since every one seems confused a general overview of how FGFS
> determines the 'VIEW'
>
> 1) the PLib coordinate system has the same 'sense' as OpenGL but is Z'
> up. [...] this is a simple rotation of a right handed coordinate
> system and is due to the fact that the PLib author primarily
> writes FlightSimulators where this is a 'natural coordinate basis
> If you don't like this fact either get over it or quit using PLib
Chill, Norm, we can deal. :) But having it spelled out somewhere more
obvious would be nice. I discovered it accidentally while browsing
through the source code. Just a hint for the next time you guys are
auditing the documentation.
> 2) the LaRC coordinate system is different also but this should be
> handled transparently for you in existing code < see comment in
> viewer_rph.cxx >
There's a (reasonably) standard interface for the FDMs to export their
location and orientation. This bit isn't a problem.
> 'most coordinates' are manipulated in a local cordinate system that
> gets regenerated every frame relative to the 'scenery center', which
> conveniently is set each frame to the overflown tiles center point
> which is 'close to the intersection of Earth Radial Vector expressed
> in direction cosine form with the 'best fit plane' of all the points
> in that tiles scenery. < in reality I think it is just the average
> of all tiles points > but it helps to visualize it as 'this tiles
> plane'
Hrm... why not set the origin to the aircraft's (or pilot's eye)
location instead? Why should the camera code care about scenery
tiles? I'll take a look, maybe we can simplify this some. It strikes
me as easier for the tile renderer to compute an offset from the
aircraft's (double-valued) cartesian coordinates than it is for the
camera code to figure out (1) what the nearest tile is and (2) what
its center point is. Have I misunderstood?
> Finally given the above pieces an a current position expressed as Lat
> Lon AGL we first determine the XYZ offset of this Lat Lon AGL triplet
> by
> [... very long description of how the scenery renders ...]
This seems like more behavior than is appropriate for camera code.
How about this as a design:
The camera code hands the tile renderer the following information:
+ An orientation-only matrix that converts between "pilot's eye"
reference frame to "global" cartesian coordinates. This could be
placed in the scene graph and used implicitly.
+ A cartesian position of the eyepoint origin. The tile
renderer would fix up its coordinates appropriately, be that in an
OpenGL matrix or via plain old FPU addition.
This is sufficient for the tile renderer to draw itself, and is
significantly smaller than the current interface. Specifically, the
lat/lon/agl stuff (Euler angles in disguise) comes out of the
interface and can live in the implementation where it belongs.
> Now all you have to do is add in your local 'eye' rotations to this
> matrix and as should be apparent I STRONGLY suggest using individual
> quaternions for this
This seems wrong. Nothing but the camera code cares about the
difference between "eye" rotations, "model" orientations, or "world"
orientations. All they want to know is which way the camera is
pointing. Certainly, the cockpit renderer (for example) will not
include the "eye" rotation, but it doesn't care about the *value* of
the rotation. That's the whole point of the matrix stack -- just push
your modifications on to it and forget about what came before.
The business of quats is fine with me. I'm not nearly so enamoured of
them as you are, but they're a good tool for holding an orientation.
They make a very poor tool for (user-)specifying a rotation, however.
> FYI I was about to rip out the view offset stuff after first having a
> discussion about the View Pipeline and how it all tied together but
> then somehow the tilt matrix just got added into the equation even
> after I had specifically requested a peer review prior to it
> inclusion, ie I knew the problem of not having ripped out the
> view_offset stuff earlier and it's making it too tempting to add in a
> tilt variety and this is EXACTLY what I did not want to see happen as
> it could only lead to the mess that you have now trying to implement a
> 'Virtual Cockpit'.
This isn't quite fair. I wasn't party to the discussion, but the tilt
angle got added to solve a specific problem. The panel/UI world
*needs* an euler angle interface to the view direction to do its job.
Under the existing implementation, the mouse code was the sole
aribiter of those numbers, didn't export them as anything but a full
quaternion, and didn't accept input from anywhere. So a new feature
was needed. The "polite" thing to do is to add features leave the
other person's code unchanged. Yes, that's Bad Engineering, but you
seem to be equally guilty of it. I mean, after all, you *didn't* yank
the euler stuff out, right?
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
