[osg-users] Refactoring DatabasePager NeedToRemovestringflagging technique

Robert Osfield robert.osfield at gmail.com
Mon Nov 23 08:10:33 PST 2009


Hi Wojtek,

On Mon, Nov 23, 2009 at 2:34 PM, Wojciech Lewandowski
<lewandowski at ai.com.pl> wrote:
> But I would strongly defend merits of arguments in the post. You say we did
> wrong, but whats you recommendation on mixing many intersections with
> rendering ?  Its very common scenario. How  should we tackle it, if current
> approach is wrong ?

The right approach is a difficult one.  Getting a paged scene graph to
work with intersections at highest resolutions and at the same time
manage things for rendering with requires just the appropriate LOD
child for the needs of visuals is awkward.   I know often vis-sim apps
don't even try to mix the two, and have a separate process entirely
for dealing intersections as for doing the visuals.  Some sims even
run the visuals and intersection testing on entirely different
machines.  Other sims use entirely separate databases for intersection
testing and visuals.  Then there are others that use a height field
for height above terrain testing...

If you do want to mix the two then you need to ask questions about how
you want to do intersections and how your thread them.  Do you do
intersections in the main loop?  In a separate thread?  Do you run the
intersections multi-threaded?  I.e. multiple intersections traversals
at one time?  Should the intersection traversal wait to load external
tiles to get the result, or should then just return the intersections
for what is already loaded into memory.

What approach you will want to use will depend upon all of this.


> Second important issue for me is usage of _name in scene graph. I always
> expected that _name is reserved for users and its a normal rule in all Scene
> Graph implementations that libraries do not change it.  Names are ususlly
> used to identify certain portions of models and hook up the code properly.
> Thats something that provide standard linking mechanisms between artists and
> programmers works.

I agree, but... in this instance the DatabasePager's algorithm was
about deleting a subgraph that would no longer have any role to play
in the applications life so the changing of name should never have got
outside that algorithm as the subgraph would be just deleted.  So it
is in theory just a black box, how it does it's job shouldn't effect
anything else.  Alas in this case it looks like the algorithm in
DatabasePager is flawed.

> Please also note that we use cache becuse we otherwise were loading PageLOD
> files twice. Is it reasonable ?.

Using a cache to prevent a subgraph from being deleted defeats the
load balancing that the DatabasePager will be attempting to do, so
it's a dangerous thing to do - it's a recipe for relentless growth in
memory usage.

> Even if we skip intersections,  other
> situations are also possible. For example we may have few highly detailed
> special PageLOD tiles with ariports which we want to preload and keep in
> memory for whole application runtime. So we modify readFileCallback to work
> for such cache and return these preloaded models each time thery are
> requested.

Use of the cache in conjunction with a paged database should be used
very sparingly and for only very specific types of assets.  It does
also open the question of how DatabasePager should deal with such
datasets, without lots of reflection on the issue I can't say.  I can
say in the design and development of DatabasePager I have made the
assumption that it'd be the master of the PagedLOD's and manage all
reading and expiring, and not have code on the outside managing things
in a parallel.

It's worth noting that PagedLOD has settings that allow you to control
what happens with expiry - so you can individually switch off the
expiry.

> Their names will be changed as well and "NeedToRemove" scheme
> stops working anyway.

I suspect the "NeedToRemove" scheme is only scratching the surface of
the issue of apps that try to mix paging and caching.

Robert.


More information about the osg-users mailing list