Norman Vine writes: > > globals->get_current_view()->set_orientation_offsets(r, p, h); > > > >or > > > > view_roll_node->setDoubleValue(r); > > view_pitch_node->setDoubleValue(p); > > view_heading_node->setDoubleValue(h);> > > Here is where I say you are WAY over enamoured with your 'properties'
It might help, then, if you ignore the second example and concentrate on the first: image that we did not have properties at all in FlightGear. The issue is code design -- the view code needs to be fully decoupled from the input code (whether keyboard, mouse, joystick, network, or some other source) so that we can reuse it cleanly, which we cannot do right now. As long as some of the view calculation is performed inside the mouse code, that code will have to be duplicated for other input methods that can change the view code. Even more seriously, it will be difficult for other subsystems (such as the 3D model) to determine exactly how the view has changed. > IMHO Since the properties can read/set a matrix directly all that > is needed are these values stored in a 'globally available place' > so that the property manager and its ilk can access them when they > want to. But the internal vector math operators can operate > unhindered by reading the values directly. We're not talking about internal vector math, we're talking about how input values get from the mouse to the view code -- that's fundamentally an interface problem, not a mathematical one. Andy, Jim, and I have all suggested that we need a generic interface to represent the view orientation offsets, and that all input should go through that interface. We want to be able to say that the user has requested something like roll offset is 5 degrees heading offset is 10 degrees pitch offset is 0 degrees and have that work the same way, no matter where the numbers are coming from. The mouse code can use the mouse position to calculate the user-requested offsets then pass them on to the viewer code, and the viewer code can use matrices or quaternions internally for its calculations. > Also I believe that all of the what was Viewer_RPH ie the World Positioning > code without any 'eye' or other 'local orientations applied' should be moved > out of FlightGear and into SimGear making this distinction even clearer. Yes, there's a lot that we should move out into SimGear. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
