"Curtis L. Olson" <[EMAIL PROTECTED]> said: > So, I will assert that distance is a better metric than time. Time > may work ok, if you are flying in a straight line it is probably > equivalent, but when you consider that at any time a pilot could turn > and fly any direction, distance based caching makes the most sense.
Yes I can see that. But how do we manage cache for the fdm? Perhaps each fdm should just have its own cache, covering a smaller fixed radius. This could mean some tile loading when we switch views, if the previous viewpoint is far from the aircraft, and the visibility is high, but the fdm cache could be large enough that it wouldn't be too bad of a problem. Hmmm...actually, now that I think of it, the real problem is that suddenly switching view positions will create a mess when there are tile loads pending and the current view now wants to discarded them. Of course it won't actually try to unload a pending tile, but there could be some nasty thrashing for a bit. > Doing additional terrain intersects per frame is costly ... maybe one > extra will get lost in the noise, but a terrain intersect is costly > enough for me to be concerned about doing this more than absolutely > necessary. As Norman suggests, if a view isn't moving, I think it's > worth the effort to cache the height above the terrain and avoid > recalculating it every frame. I'm going to add something that checks the viewer based query against a tolerance of change so that we'll save time if the aircraft moves only a short distance. Probably something like, if lon=oldlon && lat=old-lat return oldelev. Then a tolerance check (if we're only looking at a very tiny change) also return oldelev. I could do that in the viewer update and only query the tilemgr if position actually changes. > Another comment you made was related to only needing to check the > current tile when doing a terrain intersect. This is *not* a valid > assumption unfortunately. Airports can span multiple tiles and when > they do, the airport model is attached to only one of the tiles. > Which one is decided "arbitrarily" at least for the purposes of this > discussion. You would have to at least check the current tile and the > surrounding 8 others. Oh yeah...I was only thinking about what was necessary to calculate just the cur_elev under a given location. Not so much changing our current method but noting that we don't need that many tiles with the fdm for the purpose of calculating elevation (the intersection with a normal vector at a particular position). Beyond the current tile and surrounding eight, the only reason for loading tiles around the fdm location is to make switching to a view at the same location (eg back to the cockpit) faster and smoother. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
