Hi Jannik, On 16 August 2016 at 15:28, Jannik Heller <scr...@baseoftrash.de> wrote: > Yes you can break it that way but I'm actually talking about a different > breakage - the fact that resources get cleaned up that should *not* be > cleaned up because they're still in use. > > Consider: > > - Camera1 > -- Node1 > --- Geometry1 > > - Camera2 > -- Node2 > --- Geometry1 > > Now if we remove Camera1, Geometry1 gets releaseGLObjects() even though it's > still being used by Camera2. This will result in frame drops because the > objects have to be recompiled on the next frame. > > This is not a "corner case", doing resource sharing between cameras is > something that everyone will do to improve the performance.
Sharing subgraphs is normal, the thing that is not normal is removing stuff from the scene graph whilst it's being actively rendered. Adding and removing objects from the scene graph whilst it's being actively rendered is a special case that needs special handling to make sure it happens safely. > My argument is that the releaseGLObjects() in GraphicsContext::removeCamera > is so broken that we should simply remove it. Not sure why you think it's broken. > That cleanup shouldn't be necessary anyway because the GL objects are > released when objects are destroyed. So if the object was only in use by that > Camera (i.e. no other reference to it), the object gets destroyed and > releaseGLObjects() after the Camera is destroyed. If there are still > references to the object, then the user is obviously still using it so we > should not releaseGLObjects() on it. The problem is you are destroying some objects that have GL objects that need clean up so releaseGLObjects() is required, but you're breaking this by sharing objects. For the OSG to *know* what you are doing with your application and what parts you are intended to release and parts you want to reuse is not trivial to work out automatically. The only safe thing to do is release the objects and let them be reallocated as required. The alternative for you is simply not going deleting nodes. You need to think about whether you need to delete Camera's dynamically during the applications life, you haven't explained why you are doing this and why not keeping the Camera around is not appropriate so I can't comment on the validity of what you are doing. If Performance is critical for you then you shouldn't be avoiding deleting nodes during the lifetime of the rendering as deleting objects in C++ and especially in OpenGL is very expensive and can easily break frame. If performance isn't an issue then using multi-threading won't be required. I don't know what the performance requirements are you your applications. 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. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
