Hi Jannik, On 16 August 2016 at 17:44, Jannik Heller <[email protected]> wrote: > I don't need to remove it during runtime, I remove it on exit. Obviously it's > a good idea to remove stuff on exit to avoid memory leaks. You *could* just > leave your scene as it is and let OSG clean it up when the viewer exits - but > I like to follow the principle of: whoever creates an object should be > responsible for removing it ;)
The OSG uses smart pointers within the viewer and scene graph so there is no need to manually track memory management, it'll clean things up for you. >> Also something that seems a bit odd - why an in scene graph Camera has >> a GraphicsContext assigned to it. Normally in scene graph Camera >> don't have an GraphicsContext, instead inherit the GraphicsContext >> from the viewer's Camera. If Camera needs it's own >> GraphicsContext/Window then would typically best done by having a >> Camera at the Viewer level rather than in the scene graph. Again I >> don't know why you've gone for the approach you have, all I can say it >> might not be appropriate. > > I assigned the same GraphicsContext that I'm using for the window. I thought > that would be equivalent to just leaving the GraphicsContext as NULL and > letting it inherit, I didn't realize there might be side effects to > explicitely setting the GraphicsContext. The side effects are only appearing because you are mixing in lots of other things as well - i.e. threading, removing objects before the drawing thread has completed, sharing subgraphs. As a general design you should avoid assigning the GraphicsContext for in scene graph Camera's as it limits how reusable the scene graph is, you are looking high levels parts of the application with lower levels in the scene graph rather than leaving then loosely coupled. Scene graphs like the OSG are built to enable loose coupling as this provides much greater flexibility i.e. you can alter the viewer configuration and the scene graph independently. A lot of work has gone into this part of the design of the OSG, you can still break it if you wish as the design is so flexible, mostly this is fine, but in your case you've added extra complexity for no functionality gain and found a way to break things that would have otherwise work perfectly had you gone the straight fordward route. > Thanks for this note, now I have a better understanding of what > Camera::setGraphicsContext actually does :) > > So I guess we have at least 3 different workarounds then: > > - Leave the camera's GraphicsContext as NULL > - Remove the Camera's children before removing the Camera > - Wait for the graphics thread to finish (i.e. stop viewer threading) before > removing the camera Frankly we are talking about workarounds, we are talking about fixing the way you are setting up your application and scene graph to keep it nicely decoupled. Simply don't assign the graphics context to the Camera and don't remove elements in the scene graph that you don't need to. The OSG will do the right thing for you, just trust it. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
