Martin Dressler writes: > There are some diferents how the viewer is initialized and from > where it take new position. Your viewpoint could be static or > change position or (and) up vector in some dependency on FDM or > maybe time.
Right, but none of that's the viewer's concern. As long as something (probably the view manager) tells each viewer every frame what the location(s), orientation(s), and offset(s) are, the viewer doesn't have to know anything else -- it can calculate all of its matrices and vectors from that. > IMHO the view also should control if panel, hud or virtual cockpit > is used. and if it preserve state if you switch to another view > and then return back. 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. 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. That way, person A who knows nothing about matrix math can design new views, etc., and person B who knows little about the rest of FlightGear, properties, etc. can optimize the matrix math, etc. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
