Yes, but there is more to it than (a) an implied 0 for the third coordinate (b) an arbitrary choice for dimensional units because the 3D model uses the z buffer for overlay, while the panel uses drawing order. In order for the panel to be drawn correctly by the 3D SSG tree, we have to imply non-zero third coordinates that will overlap and force the drawing order correctly. The implication presumably is different for 16 bit and 32 bit depth buffers ?
> Jim Wilson writes: > > > What would the drawbacks be of making the new code do either 2D or > > 3D and converting the old panels over to the new format? This > > could potentially solve a number of the concerns that have been > > raised. > > It's important to remember that the 2D panel is 3D -- we just happen > to keep it flat on to the viewer. The new panel would be similar, and > best practice would be to build a flat surface with a lot of > instruments then transform the whole thing to the right position; > except for the final transform, the coordinates could still mostly be > 2D as they are at present, except that you'd use real-world > measurements (meters) rather than idealized screen coordinates. > > > All the best, > > > David > > -- > David Megginson > [EMAIL PROTECTED] > > _______________________________________________ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
