Jon S. Berndt wrote: > I don't know if this applies at all, but it worries me to hear what > Andy wrote about the code going away. Will this have any impact on the > ability to calculate the location, height, and orientation of an > aircraft on a tile given the tile may have a non-vertical normal?
Really, this is just changing the place where we do addition. Right now, (someone correct me if I've goofed something up) the tile renders all the vertices on all the tiles relative to the centroid of one of them, and expects the view code to put the origin at that centroid. My proposition has the view code placing the origin at the eyepoint (about which it must know something) instead of the tile centroid (about which it can be clueless), and the tile renderer doing the appropriate magic to move the origin based on the eyepoint exported by the view code. That way, the tile renderer depends on the view code (it has to, if you think about it), but the view code can live completely independant of the tile renderer. And the normal will always be vertical, at least for some point on the tile. Actually, this is another spot where I think we can slice the view code apart from the tile renderer. Right now, the tile renderer gets its "up" vector as the local up vector for the aircraft. But why not just cache an "up" vector at the tile centroid instead? All locations on the tile have a valid up vector, that's just a normal property of being, er, uh, a place on earth. :) You could even argue that this is more correct if we start rendering far-off tiles. A tile 60nm away should have an up vector off by 1 degree from the aircraft's, for example. 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
