This looks really good to me. A few nits below, based on the way I think about the problem.
David Megginson wrote: > 1. looking from a known position outwards > 2. looking at a known position from an offset > 3. looking at one known position from another Heh, cockpit, chase and tower. I wasn't thinking generally enough. :) > // Vectors and positions > virtual const float * get_view_pos () const; > virtual const float * get_absolute_view_pos () const; > virtual const float * get_zero_elev () const; > virtual const float * get_world_up () const; > virtual const float * get_surface_east () const; > virtual const float * get_surface_south () const; It's probably a good idea to specify the coordinate system for each of these in the name. That is, get_absolute_view_pos() clearly returns a global coorindinate, but does get_view_pos() return the pilot's position in aircraft coordinates or the eyepoint in local coordinates? I'd also suggest putting stuff like the surface directions somewhere else. These are properties of a location, strictly, not a view. Someone who wants to know what way "up" is in global coordinates can get that by running the aircraft's location through the SimGear geodesy stuff without bothering the view code. If we need to cache it for performance reasons, we can do that in the model code (each model will get its own orientation from somewhere) Also, those who really want to get it here can extract it from the orientation matrices anyway. Maybe the solution is to have a "model orientation" object per model (there might be many, each with its own orientation), and put some of the "view" stuff (what I'm calling the Local2AC matrix below) there instead? > // Matrices > virtual const sgVec4 * get_VIEW () const; > virtual const sgVec4 * get_VIEW_ROT () const; > virtual const sgVec4 * get_UP () const; Nit: those should be sgMat4's, right? Or are you returning a pointer to an array of four vectors? I'm a little fuzzy on these names. We basically have four coordinate system orientations: + global (Ghana/India/arctic-ocean) + local (north/west/gravity-up) + aircraft (back/right/local-up) + computer screen orientation (Plib coordinates) It might be more useful to name the matrices by the orientations they connect, and which direction they translate: Global2Local // defined by the aircraft location Local2AC // defined by FDM-exported phi/theta/psi eulers AC2Screen // defined by the view eulers Then client code can then assemble the appropriate matrix stack as necessary. The tile renderer will use AC2Screen*Local2AC*Global2Local, while the model will draw into AC2Screen*Local2AC. The virtual panel will actually use something like AC2Screen^T (the transpose) to do its drawing, translating the panel's notion of "screen" space back into the 3D model world. 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
