On Thu, Jul 16, 2009 at 1:16 PM, Rob Shearman, Jr. <rmsj...@yahoo.com>wrote:
> PROBLEM 1:
> On many of my long-haul flights I tend to notice a delay in loading scenery
> tiles -- while visibility at FL300+ has always been next-to-none, I can
> definitely see borders where there is a "white" (i.e. non-loaded) tile I am
> flying over. Occasionally I see it pop in as I get directly over it. I have
> scenery 1.0.1 for the USA and Europe resident on my hard drive. I do not use
> TerraSync. On one flight from Baltimore to Green Bay, I descended in steps
> from cruise to 10,000 MSL, 4,000 AGL, and 2,000 AGL. Approaching KGRB from
> the east, I was flying into an empty tile. Just as I finally got over top of
> the airport (say within 2 nm of it) it popped into view. I circled to the
> north and landed.
>
I think there may be problems with the tile aging and caching scheme. A bit
of historical perspective ...
Originally cache entries were flushed based on distance from the viewer
(aircraft.)
At some point this was changed to an aging mechanism so that tiles were
flushed based on time since last "used" instead of distance from the
viewer. I was some how convinced at the time that this was a good idea and
let the changes be applied to the code, although in retrospect, I'm not as
sure any more.
When we moved to OSG, this was subtly changed so the time stamp is only
updated when the tile is actually drawn. This sounded good at first except
it's very possible (especially when you start in the air) to be above a tile
you can't see. Tiles that have never been drawn have a time stamp of 0, so
when the system needs to flush a few entries out of the cache to load new
items, the tile you are over top of could potentially be flushed out from
under you. This is especially bad when it happens because the aircraft
initialization and trimming code waits for a ground elevation (i.e. a loaded
tile) before it initializes and trims your aircraft. This is a potential
deadlock situation.
So a while back, I changed the behavior slightly so that when a tile is
"scheduled" for loading (i.e. all the tiles surrounding you) the time stamp
is updated, even though the tile may not be drawn. This cured the failure
case I was able to generate so I was happy.
However, as you report (and I've noticed this too) on long flights, there is
still a problem with the tile aging and caching system. Tiles right under
you that should be higher priority are sometimes flushed out anyway. I
haven't had a chance to dig in and investigate this myself, but part of me
thinks that going back to a distance-from-the-primary-viewer based cache
priority scheme would be the smartest thing to do. It's a little bit more
work to compute a distance, but originally I used manhatten distance which
is a close enough approximation and is very quick to compute, especially if
we are only doing it for maybe 30-40 tiles.
One complicating factor is that we can jump our view point all over the
place and even query ground height of any arbitrary position via nasal.
Perhaps these nasal based queries running for some instrumentation or
feature are touching out-of-view tiles and causing local tiles to be lower
in the priority and get flushed out?
Something odd is happening and I haven't had time to get to the bottom of it
other than to verify that there is ample room in the cache (it's not a cache
size problem) so it has to be a cache aging/prioritizing problem.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
