Hi Vincent,

On Fri, Jan 8, 2010 at 2:30 PM, Vincent Bourdier
<vincent.bourd...@gmail.com> wrote:
> Is there a way to manage memory usage with the load of models ?
> In my case I have a lot of PagedLod to load, and my question is : is there a
> way to know is memory is sufficient for the next PageLod higher level node ?
> I just would like to stop the data loading when memory usage exceed some
> point.

The DatabasePager in svn/trunk + 2.9.x has the ability to cap the
number of PagedLOD to a maximum, and automatically recycles PagedLOD
children that aren't in the current view when new PagedLOD are
required by the current view.  What this capping doesn't do is stop
the loading of new PagedLOD, so if a single view requires a PagedLOD
it will be loaded.  To set the cap level programmatically via:

    
viewer.getDatabasePager()->setTargetMaximumNumberOfPageLOD(targetNumOfPaged);

Or using env var:

    set OSG_MAX_PAGEDLOD=200

Another feature of svn/trunk + 2.9.x is that texture and buffer
object's pools that also provide a maximum cap on the number of
texture objects and vbo/pbo/ebo's that can be allocated at any one
time.  You can set it programmatically via:

   
osg::Texture::getTextureObjectManager(contextID)->setNumberActiveTextureObjects(targetNumBytes);

Or using env var:

    set OSG_TEXTURE_POOL_SIZE=64000

Like the PagedLOD target, the texture pool size is only a target, and
if a single frame requires more memory than this it will allocated
more memory to prevent any thrashing of memory  within a single frame.
 I did do tests with a strict limit on memory size but when a single
frame requires more than this the memory thrashing cut performance
down to a fraction of it's normal, for instance going from a solid
60Hz to 1 or 2Hz.

If you wanted the LOD control then you just implement this yourself
using osgDB::Registry::ReadFileCallback that loads the tiles and then
modifies PagedLOD that it loads that are higher than a certain
resolution.

Or... just adjust the viewer's Camera::LODScale pre frame to manage
the on screen screen complexity.

Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to