HI Wojtek,
The crucial part you don't talk about is the performance constraints.
Can you pause a frame for hundreds of milliseseconds while the
required high res tiles are pulled in off disk? Or are you trying to
stick with a solid 60Hz? Loading any tiles in the update phase is not
possible if you want to keep to a solid 60Hz.
You are right, we do not keep 60 hz then. But its rare case, we prepared our
ReadCacheCalback to wait for highest level of detail only when camera is
repositioned by more than some margin distance. There is an assumption that
warp move will not keep decent LOD anyway, so then we trade hz for qualtiy,
and force HIGHEST_LEVEL_OF_DETAIL to properly compute initial elevations and
preload highest level of detail for camera neighbourhood. Once the camera is
moved and new initial conditions are met we switch back to highest
avaialable PageLOD because we are sure that preloaded tiles will be fairly
high level and Paging will offer fairly good continuous intersection results
that will fit into our wiggle room. This is actualy a hybrid approach but I
have not mentioned it because it would complicate things even more.
I think something that might provide a "work around" such as replacing
the"NeedToRemove" is just a work around it's very unlikely to be a
solution of trying to use the DatabasePager beyond it's current design
assumptions.
I agree, but such replacement of original name seems like similar trick to
me, thats why I proposed to get rid of the cause completely. This is what
this thread is about, isn't it ?
Memory leaks were the result of extra NeedToRemove nodes that appeared in
activePageLOD lists when some nodes were resurected from Cache because
camera moved over them again. I know its sophistry, but in some way, it
was
more effective than native DatabasePager management because it loaded
nodes
in no time while DatabasePager would have to load them from disk in this
case ;-).
I can't understand why you want to do what you are trying to do, but
it still doesn't change the fact that DatabasePager hasn't been
designed with this in mind. We can certainly look to take this into
account in another rev of DatabasePager.
Thank You.
As a general note a good OS will actually cache file accesses,
especially if you don't overload virtual memory/swap space too much so
the cost of reloading a tile might not be quite as expensive as you
think... I know that when I benchmark under Linux I have the file
cache makes a huge difference, so I can to be careful about running
test apps in sequence.
True. On the other hand, with large datasets like Paged 400 GB database
constantly moving back and forth this genaral cache may have much worse hit
ratio then application cache tuned for the particular usage patterns. With
OS cache the terrain LOD switching was still more distracting than when we
turned on both OSG caches.
Well I thought that if PagedLOD class is public and offers public
interface
and methods we could use it as long as we do not hit compiler errors.
Perhaps different set of classes should be created for use in more VPB
specific closed way.
I don't think this is a VPB database specific issue. The problem you
are trying to solve is really to do with trying to juggle user manage
caching with how the DatabasePager manages expiry.
Maybe I am. But additionally I also want to stress the fact: that if some
node is no longer present in current viewer scenegraph, it does not exactly
mean its no longer used. And assumption that DatabasePager can do anything
with such node, is at least a dangerous practice to me.
When I get on to reviewing the multiple viewpoint issue with
DatabasePager I'll have a think about the consequences of users
caching subgraphs.
Thank You. Does it mean I should try to prepare the proposed submission or
not ?
Wojtek
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
