good news - I've done more debugging in the tile cache module and
think I already found something...

I'm seeing two issues with the tile cache, sometimes causing active
scenery to be kicked when the cache is full - and this results in the
missing patches. I'm also seeing cases where all active scenery tiles
are dropped. This can also happen when cycling through the tower view
- so this doesn't always help. Both issues are timestamp related
(maybe depend on frame rate, system load, slow USB disks :-) or

* First problem is that the tiles' timestamps are only updated when
the tiles are freshly loaded from disk or they are actively displayed
(some magic osg "CullCallback" does that - haven't fully understood
this yet). So when a tile belonging to the current position was not
displayed for a while, its timestamp is old. When the view then moves
or teleports into a new position, and then back to the original
position, the same tiles get scheduled again - but are still found in
the cache. Since their timestamps remain old, they are kicked from the
cache soon afterwards, when more tiles are loaded. This is what causes
the "random scenery tiles disappear" effect...
=> I'm testing a fix now, which updates a tile's timestamp whenever it
is scheduled to be loaded, but then found in the cache.

* The second issue is about the timestamps updated through this magic
osg "CullCallback". These timestamps can be newer than the current
time used by the cache module for loading new tiles (seems to be a
frame ahead or so). When a new set of tiles is scheduled to be loaded,
and the cache is already filled with many "future timestamp tiles",
then the new tiles immediately kick each other from the cache (are
never really loaded). When this happens, all scenery for a new
position is lost (complete whiteout)...

Is all the tile cache and osg code single-threaded? If these osg
callbacks, the cache management and tile loading were not in the same
thread, it would explain where future timestamps could come from
(maybe on slow machines only). If it's all single-threaded then I'll
have another look to locate this.

Another option I'm already testing is introducing a flag to lock all
tiles belonging to the current view position in the cache. The primary
condition checked by the cache would then be to never kick tiles
belonging to the current position (i.e. current inner or outer ring).
Timestamps remain a secondary condition to pick from tiles not
belonging to the current position. This would make things a lot more
robust than relying on whacky timestamps alone.

FG only supports one view position at a time, right? Multiple view
positions (e.g. one screen for the tower view and a second screen for
the plane) would complicate a "locked to cache" flag quite a lot...

Maybe someone could comment on the threading issue. I'll do some more
testing, and then hope to propose a patch...


Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
Flightgear-devel mailing list

Reply via email to