Hi Alex, The DatabasePager already has a scheme for load balancing and will automatically expiry PageLOD's that are out of range. It only does the expiry once a user specified maximum number of PageLOD's is reached, while the default is set to 500, but you could set this to 1 if you wanted and get the behavior your talking about.
Robert. On Fri, Nov 5, 2010 at 10:15 AM, Alexandre Amalric <[email protected]> wrote: > Hi Robert, > > I am wondering why there is no way to remove PagedLod child wich are visited > by the culling but wich are also out of range from the camera. > Here is a simple case let's image I have 100 PagedLod each composed from a > low poly internal model and a high res external model (displayed when we're > close enough to the PagedLod center). > If the camera goes near from those 100 PagedLod, the high res models are > loaded in memory but only released when they are no longer in the frustum > (inactive). > If my camera is looking at those 100 PagedLod simultaneously but from a long > distance only the low res model are displayed but memory is the same > amount... > It would be interesting if the DatabasePager could remove PagedLod children > out of range and not only if they no longer are visited, to keep a good > memory consumption. > Maybe an internal "_outOfRangePagedLodList" will be the solution... > Kind regards, > > 2008/12/15 Robert Osfield <[email protected]> >> >> Hi Glenn, >> >> On Mon, Dec 15, 2008 at 3:07 PM, Glenn Waldron <[email protected]> wrote: >> > Robert, one quick clarification: does the new max-PagedLOD scheme work >> > in >> > conjunction with expiry settings, or are they mutually exclusive >> > techniques? >> > I have not studied the new code yet. >> >> The new TargetMaximumNumberOfPageLOD scheme replaces the other expiry >> delay/expriy frames one(s), all the setting for the later techniques >> have no effect when the TargetMaximumNumberOfPageLOD has an non zero >> value. >> >> My plan is to phase out the old expiry code, but won't do this for >> 2.8, we need to roll out the new code and make sure it's working well >> across the full spectrum of usage models before we starting removing >> the older code. My current belief is that the new scheme is just much >> more robust at load balance than the previous ones that there is >> little reason to carry the old ones long term. If applications won't >> to change their memory needs at runtime then can always increase and >> lower the target maximum number of PagedLOD at their own choosing. >> >> If thing looks good for the new scheme once 2.8 rolls out I'll remove >> the back end code for the old algorithms then just issue a warnings >> when users try to use the setExpiryDelay/ExpiryFrames, then finally >> remove the set methods completely as well. >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > -- > Alexandre AMALRIC Ingénieur R&D > =================================== > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > http://www.pixxim.fr > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
