David Megginson wrote: > I disagree -- the view code gets *very* hard to understand very > easily. If that information is tracked, it should be tracked > externally (the view manager, again?) and not in the viewer code > itself.
Amen. I spent many hours over the weekend trying to make the view code work in the presence of the virtual cockpit without breaking everything, and got essentially nowhere. I can think of only one or two other times in my career that I've been so befuddled by code. :) > The viewer code has to do some very complicated matrix and vector > math, and if we have any hope of being able to maintain the code in > the future, we need to keep it as simple as possible. > > The best arrangement I can think of is isolating all of the actual > view transformation code in the viewer class, and all of the > FlightGear-related stuff in the view manager class. This sounds best. Ultimately, the "view" is just a tuple with six degrees of freedom. The front-end code would "feed" these numbers via the appropriately complicated mechanism (aircraft phi/theta/psi plus view offset/tilt, for example), but clients would only care about the final numbers, and not the intermediary stuff. Right now, everyone has to agree on everything. There are *lots* of places where the external view is hard-coded as the "second" view, for example, because it has to be interpreted specially. In practice, everyone only sort of agrees. So most stuff works, until something (virtual cockpit) comes along that wants to interpret the existing numbers in a new way, and boom. I'm going to try tackling the back-end rewrite -- the code that takes "view" and presents it to the various clients in a consistent way. This is going to touch a lot of stuff, but should result mostly in code removal. Which brings up a good question to ask: can someone provide a quickie overview of the various coordinate systems? I've read the coordinates document, which is good, but incomplete. Really, what I want is a list of all the things that are going to be drawn, and what they expect the modelview matrix (er, plib matrix state, rather) to look like. Specifically, does scenery draw using global cartesian coordinates? Some comments seem to imply that, but I'm dubious -- these would require doubles throughout the matrix pipeline for sufficient precision. Likewise, what are the conventions for the aircraft model? I *think* that it's X-back, Y-right, Z-down, but I'm not sure. Could someone verify? And can someone tell me what the deal is with plib coordinates? I was browsing through the source code and stumbled on a very frightening-looking "axis swap matrix" (its existence was frightening, the axis swap is obviously trivial) that gets applies in various situations. Are plib coordinates different from OpenGL ones? Eek. 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
