On Sun, Sep 19, 2010 at 4:40 PM, ThorstenB <bre...@gmail.com> wrote:

> Hi,
>
> 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
> so...).
>
> * 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
>
The cull callback is called from OSG's culling traversal. If OSG determines
that an object's bounding sphere intersects the viewing frustum, it calls
the cull callback -- if there is one -- to traverse that object and perform
finer grain culling. If there is no cull callback, OSG does the traversal
itself. Anyway, it's a good way to perform an action when an object is in
view.

> 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.
>
That sounds correct.

>
> * 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)...
>
> The timestamp used by the cull callback comes right from OSG's "frame
stamp" and should be consistent with the tile code. there could be a logic
error in the tile cache.

> 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.

It is possible for the tile cache code, which runs in the update traversal,
and the cull callback to run in different threads. However, they should
never run at the same time: the cull traversal starts when the the update
traversal has finished, and the next update traversal blocks on the cull and
draw traversals. Now, the code that actually loads the tiles -- the database
pager -- does run asynchronously. I'll need to check if any of the tile
cache code runs in the database pager thread, but don't think any does.

Tim

>
> 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...
>
Yes, and that's not really supported by the current architecture, neither by
the tile cache nor by osgViewer::Viewer. We would need to move to a
CompositeViewer model, which supports several scene graphs, and rely
completely on the osg database paging machinery.

Tim

>
> Maybe someone could comment on the threading issue. I'll do some more
> testing, and then hope to propose a patch...
>
> cheers,
> Thorsten
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to