Hi Alex, Just because children of a PagedLOD may be out of range doesn't mean that the PageLOD itself isn't required in memory, if the cull traversal is hitting the PagedLOD it's active an really can't be expired, even if the children are being culled at that point in time.
I rather feel that you have unrealistic expectations of what is possible to achieve. Robert. On Fri, Nov 5, 2010 at 12:07 PM, Alexandre Amalric <[email protected]> wrote: > Hi Robert, > > Reviewing the latest snv code from the databasepager, the problem remains > the same. The only expired nodes the databasepager is removing are the one > wich are in the "inactivePagedLODList" this one is only filled with node > that hasn't been traversed for a while (compare FrameNumberOfLastTraversal > from PagedLod and current FrameNumber). > So in my case, asking 20 pagedLod at max from a scene of 100 PagedLod, when > my camera is looking at those 100 pagedLod from a far distance, the > databasepager isn't removing any external nodes previously loaded. Making > the memory use very high for displaying low models... > Keeping previously loaded PagedLod out of range in the frustum culling makes > the databasepager keep them in the activePagedLODList... > Memory will decrease and 80 nodes will be removed if the camera stop looking > those 100 PagedLod at the same time. > Kind regards, > 2010/11/5 Robert Osfield <[email protected]> >> >> Hi Alex, >> >> I've got too many things on to try and get my head around your >> understand of some code that has already been modified in svn/trunk. >> In svn/trunk and the 2.9.x series the DatabasePager has been improved >> further, so go test there. >> >> Robert. >> >> On Fri, Nov 5, 2010 at 10:32 AM, Alexandre Amalric >> <[email protected]> wrote: >> > Hi Robert, >> > >> > I'm using osg 2.8.3 and it seems it's not the case. To continue with >> > this >> > sample, let's imagine I set the _targetMaximumNumberOfPageLOD to 20, in >> > "capped_removeExpiredSubgraphs" if the camera is looking to those 100 >> > PagedLod at the same time the _inactivePagedLODList is empty and the >> > _activePagedLODList size is 100. >> > So numPagedLODs = 100 and is > 20, inactivePLOD = 0 and the numToPrune = >> > 80, so the code : >> > int numToPrune = numPagedLODs - _targetMaximumNumberOfPageLOD; >> > if (numToPrune > inactivePLOD) >> > { >> > numToPrune = inactivePLOD; >> > } >> > >> > leads to numToPrune = 0, and the removeExpiredChildren function never >> > get >> > called because _inactivePagedLODList is empty, so the markerVisitor >> > never >> > mark node to remove... >> > Am I wrong ? >> > >> > >> > 2010/11/5 Robert Osfield <[email protected]> >> >> >> >> 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 >> > >> > >> > >> > -- >> > 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 > > > > -- > 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
