[osg-users] DrawElements* memory management

Paul Martz pmartz at skew-matrix.com
Thu Mar 19 13:35:20 PDT 2009

Hi Robert -- I have a question about how the DrawElements* family of
PrimitiveSets handles the pointer to the indices.
In OpenGL, data is bound/copied at call time, so if I were writing a plain
ol' OpenGL app and calling glDrawElements, I'd pass in a pointer to my index
data, and when the call returns, I'd know the indices had been copied and I
could safely delete the array of indices.
In OSG it's a bit different. Even after I create the DrawElements
PrimitiveSet, I need to hang on to the index data memory, as the memory will
be accessed during subsequent rendering and/or write operations. Unlike
other OSG objects, the index array isn't reference counted internally.
Indeed, the interface looks a lot like the glDrawElements call in that the
index data parameter is a plain pointer, but it does not act like
glDrawElements as it doesn't immediately copy the index data. This forces my
app to keep the data around and ensure it isn't deleted.
This is cumbersome in modular programming situations. Imagine I have a
NodeVisitor that converts DrawArrays to DrawElements and therefore allocates
memory to hold the index data. The processed scene graph could have a life
that extends far beyond the scope of the NodeVisitor, so it doesn't make
sense to keep the addresses stored in the NodeVisitor (where the memory was
allocated). So who should keep track of the index data memory addresses? Who
should own deleting that memory?
This isn't the first time I've encountered this situation, and I thought
perhaps you had encountered it as well and maybe had a good solution that I
was not aware of. If so, please let me know. Thanks in advance.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com <http://www.skew-matrix.com/> 
+1 303 859 9466
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20090319/3afd2d0a/attachment-0002.htm>

More information about the osg-users mailing list