[osg-users] Texture Memory Runtime Cleanliness

Argentieri, John-P63223 John.Argentieri at gdc4s.com
Mon Oct 15 09:01:28 PDT 2007


Looks like the object whose stateset has the texture as an attribute
must be destroyed in order to release the texture? Maybe creating a new
stateset and setting it on the object will have the same effect.
Regardless, it looks like my issue has been resolved. 
 
You guys make a great product.
 
John

________________________________

From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of
Argentieri, John-P63223
Sent: Monday, October 15, 2007 9:44 AM
To: OpenSceneGraph Users
Subject: [osg-users] Texture Memory Runtime Cleanliness



Folks, 

I really need to resolve this issue. I am using multiple windows,
created not by realize(), but by our application, similar to if I were
to use GraphicsWindowEmbedded. Each window has a context that shares
with a dummy context. These contexts are managed by a class I wrote that
makes OpenGL calls. They are also each using a SceneView object and
sharing a common scene graph. I am creating and destroying textured
polygons dynamically during runtime and the memory continually grows,
despite the fact that I have relatively the same amount of textured
polygons in the scene graph at all times. I can only assume that the
textures are not being unloaded properly. I've read around on this
group, and my hunch is that I might need to use osg::GraphicsContext to
resolve this issue. 


Is that true? 


If it is true, then when I load textures, which context should be
active? The shared context? 


All I am trying to do is to ensure that when I unref my ref_pointer to
osg::Texture2D that the memory gets cleaned up from osg AND OpenGL.
Please, some advice? 


Thankful osg-user, 
John Argentieri 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20071015/747f27af/attachment-0003.htm>


More information about the osg-users mailing list