Hi, The intention here is more to provide a 'priority' for expiring children. The case I have is, when viewing a very detailed terrain, my models are being expired immiadiately while some of the terrain tiles are not. My solution does not implement a proper priority but it does result in the desired outcome.
As some background, I was originaly using the 'setNumChildrenThatCannotBeExpired' (which already exists) so the models where never expired, but this results in a permanent 'memory leak', rather than one that lasts for 30 seconds or so. Essentialy I want the models to be the last thing expired as they are relatively slow to page in and don't have a good fallback LOD. Idealy the models would be better designed but I am required to support kml models from googlewarehouse, which means (even after scaling textures and using the optimizer) many, often badly designed, models being displayed. In relation to your comments, if you have any further thoughts on controlling memory use I am happy to dive in and try and implement some improvements. I am constantly battling memory constraints on our 32 bit builds as there is a hard limit of ~2gig per process under windows and I share the process with a heavweight Java application and VM. Even when I run the 3D component standalone I get out of memory errors using the default VPB terrains when viewing large areas of high detail map data. I have improved this dramtically by implementing my own scheme for deciding which child of a PagedLOD should be active (based on a mix of distance and viewing angle ), but am very keen to regain some control of memory use. Idealy, it would be great to be able to set a hard limit on memory use and higher LODs simply stop loading if this limit is reached. Cheers, Brad -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Tuesday, 18 October 2011 3:36 PM To: OpenSceneGraph Submissions Subject: Re: [osg-submissions] Small enhancement to PagedLOD Hi Brad, I haven't reviewed the submission yet but it does make me nervous that you want a means of bypassing the DatabasePager's standard maximum number of PagedLOD. If your application has the space to maintain more PagedLOD then the appropriate thing would be to up this limit to encompass the maximum number - this would result in more PagedLOD being kept around on average than your suggested scheme. One thing I have considering is changing the default MaximumNumberOfPagedLOD for different platform targets - so embedded space this number would be kept small but for normal desktop targets allow this figure to go up. Perhaps if we had a scheme for checking available memory on a system we'd be able to compute this automatically. Robert. On Tue, Oct 18, 2011 at 6:06 AM, Christiansen, Brad <[email protected]> wrote: > Hi Robert, > > > > The attached files add the ability to control when a paged child becomes > eligible for expiry based on time and/or elapsed frames. > > > > I found that some of the items that had been paged in were being expired on > the first frame that they were not visible (as the cache was full). This > resulted in excessive paging every time the view was moved. With the > following changes I could only allow children to be expired if they had not > been used for e.g. 30 seconds or 60 frames. > > > > The changes were made against trunk revision 12822. > > > > Cheers, > > > > Brad > > ------------------------------------------------------------------------- > DISCLAIMER: This e-mail transmission and any documents, files and previous > e-mail messages attached to it are private and confidential. They may > contain proprietary or copyright material or information that is subject to > legal professional privilege. They are for the use of the intended recipient > only. Any unauthorised viewing, use, disclosure, copying, alteration, > storage or distribution of, or reliance on, this message is strictly > prohibited. No part may be reproduced, adapted or transmitted without the > written permission of the owner. If you have received this transmission in > error, or are not an authorised recipient, please immediately notify the > sender by return email, delete this message and all copies from your e-mail > system, and destroy any printed copies. Receipt by anyone other than the > intended recipient should not be deemed a waiver of any privilege or > protection. Thales Australia does not warrant or represent that this e-mail > or any documents, files and previous e-mail messages attached are error or > virus free. > ------------------------------------------------------------------------- > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org ------------------------------------------------------------------------- DISCLAIMER: This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. ------------------------------------------------------------------------- _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
