On 11/07/2009 08:03 PM, John Denker wrote: > I wrote: > >>> I'm gradually figuring out a little bit of what the viewer >>> code is doing. >>> >>> In particular: As for the basic "cockpit lookfrom" view, >>> the viewer.cxx "reference frame" for attitudes is as follows: >>> >>> Suppose you are over the Gulf of Guinea, at (lat,lon) = (0,0). >>> Then the reference frame orientation can be achieved via: >>> -- The aircraft X-axis (nose) headed south. >>> -- The aircraft Y-axis (starboard wingtip) pointing up. >>> -- The aircraft Z-axis (belly) pointing west. >>> >>> Equivalently, but with less stress on the passengers, suppose >>> you are over the Indian Ocean, at (lat,lon) = (0,90). >>> Then the reference frame for attitudes can be achieved via: >>> -- Heading = south. >>> -- Pitch = level flight. >>> -- Bank = level flight. >>> > > On 11/06/2009 02:48 PM, Tim Moore wrote: > >> You need to show your work :) > > The behavior reported above was observed using the feature > I implemented whereby the orientation quats are exposed in > the property tree. Erik committed the code, so anyone can > easily replicate the observations. > > Also the observed behavior is entirely consistent with the > apparent intent of the viewmgr.cxx code, as I read it. > OK, I now see what you're saying: a zero view orientation implies those attitudes at those locations. It's not a surprising result; when working with an earth-centered frame, the orientation of the view is often non-intuitive. I was confused by your use of "reference frame" above. Although the orientation value is zero where you describe, I/we never think of those configurations as "reference" as it's not that useful. Better to think of the earth centered frame or the local relative frame as a reference.
> Note: Since there was some criticism of one of the > property names I used, and more importantly some quite > useful criticism of the underlying concepts and > interpretation, I have submitted a follow-on patch > that should fully deal with these issues. > http://www.av8n.com/fly/fgfs/viewframe.patch > >> This doesn't agree with my understanding of >> viewer.cxx, but I didn't write it. This is what I thought was going on: >> >> The basic reference frame for all geometry is your Earth Centered - Earth >> Fixed >> frame. > > Right. ECEF is the first item on my list of reference frames > documented at > http://www.av8n.com/physics/coords.htm > > I reckon the real issue here is not ECEF itself, but rather > the fact that as mentioned at > http://www.av8n.com/physics/coords.htm#sec-orientation > to describe the orientation of a body in space, you need > *two* things, not just a set of coordinates (and the > vector basis induced by those coordinates), but also a > set of identifiable axes attached to the body. Yes, and in the case of the viewer, it's not well documented that the body axes are the OpenGL viewing axes. > > If you use the conventional aviation body axes, > i.e. X=forward, Y=starboard, Z=belly > then the standard orientation, achieved by aligning the > body axes with the ECEF axes, corresponds to flying at > (lat,lon) = (0,0) with > nose = vertically up > starboard wingtip = east > belly = north > >> After this, the rotation from an X-forward Z-down frame to the OpenGL >> Z-back Y-up frame is added in. > > I agree with that ... except perhaps for the words "after > this". My point here is that viewmgr.cxx converts to OpenGL > coordinates fairly early ... and in particular Erik's new > code passes around the OpenGL representation and does lots > of calculations using that representation. Quite understandably, > he found some of this surprising and confusing. In terms of the viewer, it's the last rotation applied to form the view orientation, so I'm comfortable in saying it is applied late. If you want to do further calculations with the view orientation in some other frame of reference you might think the OpenGL rotation is applied early. > > In particular, if you align the OpenGL axes > i.e. Xprime=starboard, Yprime=top, Zprime=aft > with the ECEF axes, then you get exactly the orientation > described in my previous note and quoted above. It may > seem implausible, unconventional, and/or inconvenient, > but it *is* what the code is using. > > The more unconventional and implausible something is, > the more important it is to document it. My recent > patch contains a bunch of explanatory comments. I'm still not seeing why this is so implausbile, unconventional, etc. Not only is the OpenGL convention common in the world of, well OpenGL, but in simulation in general you have to deal with different reference frames all the time and get used to moving between them. In the end I suppose is a matter of better documenting the viewer conventions; we could also expose the view orientation pre-OpenGL rotation if it is useful to do so. > > Also, in my recent patch, I took steps to cancel out > the OpenGL transformation, so that the exposed quats > use the conventional aviation body axes. This should > make it easier to interpret the displayed properties. > I realize most folks were not born with the ability > to look at a quat and understand what it means, but > it is a skill that can be learned. This is one of the reasons I prefer matrices; it's easy to visualize the rows of the matrix as the axes of a coordinate frame in an enclosing frame and thus easily form a mental image of the rotation. Tim ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
