Norman Vine wrote: > David Megginson wrote: > > Thanks -- the internal cockpit view seems much better. Now the ball's > > in Andy's court to patch up the virtual panel code (and de-quat the > > mouse code), and we're flying! > > exactly the kind of response that led me to coin the phrase > > "MAYDAY MAYDAY FlightGear has been hijacked"
Whoa there, boys. :) First, to be fair, the issue isn't the dequating of anything. For the record, quaternions are a perfectly useful and reasonable representation of orientations and rotations and are the appropriate choice for many applications. They are not magic bullets, however, and perfectly useful and reasonable applications have been and will be written without either quaternions or the bugs and unintended interactions (gimble lock being the only big one) that you get from naive application of euler-space representations. End of story? What I need/plan to do, (once over the motivational humps -- it's a pretty daunting task) is take the responsibility for orientation management *out* of the mouse code, and the model code, and the main loop, and put it somewhere safe, where it can be modified sanely (that is, with rotate/pitch/heading eulers) by a front end interface and read sanely (as a matrix) by back end clients. Right now, the difference between "model orientation" and "viewpoint orientation" is terribly muddled, and mixed in with things like "local orientation" (the FDM term -- the view code calls is "UP", I think) that aren't very useful to anyone. For a quickie example, look at the places in the code that read the view_offset and view_tilt stuff. These are the values that represent the direction of the pilot's head, and as such should be used only by the core view code to decide on a view direction for the 3D projection. But because of the way things grew, they are also read by places like the panel (my fault), ADA FDM (no idea there), lighting code (!), and main loop. These places don't care about the difference between the pilot's head and aircraft frame -- they just want to know the ultimate direction of the view. Well, except for the panel, which rightfully should just draw in the aircraft frame and not worry about view direction at all -- my current code essentially does things backwards, because those values could be read from the FGViewer object and set via properties, while the mouse quat couldn't. I know there are egos at stake, and I'm certain that I (or David, or Curt, or Jim Wilson, or...) won't make the same choices that Norman would have. And I'm equally certain that some working code is going to get chopped out simply because I don't understand it as well as I would my own. But the plain truth is that we have a pretty severe code growth situation here, and there aren't any "simple" solutions. If we pick Norms solution (which would work perfectly well), we still have to take a machete to the rest of the code to extricate the euler angles. 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
