Norman Vine wrote: > Andy Ross wrote: > > The location of the scenery origin is another. > > I thought I that this would have been self evident apon reading the > code sections I pointed out yesterday. > > But just to be clear > THERE IS NO FIXED SCENERY ORIGIN
Norman, stop it. The world may be full of idiots, but I am not one of them. I'm fully aware of the problem with using floats for global coordinates. Which begs the question (posed above, and still unanswered): what *is* the location of the scenery origin when the tile is drawn? Where does it come from? What must it be set to? Since it cannot be the center of the earth, it must be somewhere else; where? > The code that does this can be just thought of as a 'black box' as it > is all handled for you transparently and is made available as > scenery.get_center() Why do we consistently go in circles on this? It (where "it" means everything rendered under the modelview matrix, including the scenery tiles) is certainly not a black box, since it requires modifications. To do those modifications, I need to figure out how it works. To figure it out, I ask questions. To answer my questions, you tell me that I don't need to know how it works? Regardless, I think I've got this one now. Thanks for your (not terribly polite, but helpful nonetheless) assistance. The scenery center is set out of the main loop, and looks to me like it can be easily replaced with the eyepoint with no loss of function. This has two nice side effects: the view matrix generation is no longer dependant on data stored in scenery tiles, and the code to calculate the scenery center for each tile can simply go away. 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