[osg-users] Basic memory usage question

Robert Osfield robert.osfield at gmail.com
Tue Jul 24 13:39:06 PDT 2007


Hi Bob,

The osgUtil::Optimizer's TextureVisitor set the unrefImageAfterApply
flag so if you run this it will enable it.

W.r.t release vertex arrays and primitives after creation of display
lists, this isn't supported as you'll loose you ability to do any
collision testing with it.

As for the actual cause of the memory upsurge, the OSG should have
compiled all the OpenGL objects at the beginning so shouldn't normally
get a big increase once running, as you are well I'm afraid I'm don't
have any suggestions.  Perhaps you aren't running the precompile
stage?

Robert.

On 7/24/07, Robert Balfour <bob at bal4.com> wrote:
> Thanks John for pointing me to the quick start guide.  I should have
> looked there first!
>
> But when I converted my model to an .osg file to look at it, it seems to
> have UnRefImageDataAfterApply TRUE lines with all the textures.
>
> So maybe this isn't my doubling memory issue?, but I'm not sure what
> else it could be.
>
> Bob.
>
>
> ---------------------------------------------------------------------
> John Shearer wrote:
> >
> > Bob,
> >
> > I've just been coincidentally reading the osg quick start guide
> > (http://www.lulu.com/content/767629  pdf download is free), and it
> > answers your question
> >
> > "Applications that make heavy use of texture mapping require tight
> > control over memory management. The Image object derives from
> > Referenced, and Texture2D keeps a ref_ptr<> to the Image. During the
> > first render pass, OSG creates an OpenGL texture object to store the
> > image data, resulting in two copies of the texture image, one in the
> > Image object and the other owned by OpenGL. In a simple single-context
> > rendering scenario, you can reduce memory consumption by configuring the
> > Texture2D to release its reference to the Image. If the Texture2D is the
> > only object referencing the Image, this causes OSG to delete the Image
> > and the memory it occupies.
> > The
> > following code demonstrates how to configure Texture2D to release its
> > reference to the Image object:
> > // After creating the OpenGL texture object, release the // internal
> > ref_ptr<Image> (delete the Image).
> > tex->setUnRefImageDataAfterApply( true );
> > 66 Building a Scene Graph
> > By default, Texture2D doesn't release its Image reference. This is the
> > desired behavior in a multi-context rendering scenario if texture
> > objects aren't shared between the contexts."
> >
> > That should do it.
> >
> > John
> >
> > >-----Original Message-----
> > >From: osg-users-bounces at lists.openscenegraph.org
> > >[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf
> > >Of Robert Balfour
> > >Sent: 24 July 2007 16:17
> > >To: osg-users at lists.openscenegraph.org
> > >Subject: [osg-users] Basic memory usage question
> > >
> > >I have a large .FLT model with lots of .tif textures (I
> > >actually converted it offline to an ive with compressed
> > >textures).  When it initially loads it looks like it takes up
> > >about 800MB of memory. Then when it renders (after I zoom into
> > >its LOD range) the memory usage jumps to approx 1.6GB (i.e. it
> > >doubles) - I'm assuming this is due to the OGL display lists
> > >being generated/compiled.
> > >
> > >After the display lists are generated, is there a way to
> > >release all the original texture images so memory usage
> > >doesn't stay doubled, or do they need to be kept around?
> > >
> > >Or is the only way to reduce the memory usage is to go to a
> > >PagedLOD scheme?
> > >
> > >Thanks.
> > >
> > >
> > >Bob.
> > >--
> > >Robert E. Balfour, Ph.D.
> > >Exec. V.P. & CTO,  BALFOUR Technologies LLC
> > >1055 Stewart Ave., Suite 19, Bethpage NY 11714
> > >Phone: (516)396-9642  Fax: (516)396-9643  email: bob at BAL4.com
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


More information about the osg-users mailing list