On 23 February 2015 at 13:09, Nicolas Baillard <[email protected]> wrote:
> > robertosfield wrote: > > The OSG doesn't mutex lock GL objects for a single context as the costs > would be prohibitive, and it's only required for shared contexts usage so > it's not a penalty that is worth paying. > > If I didn't use render to texture at all (or if I didn't try to share the > generated textures between the contexts) then would it be safe to use > DrawThreadPerContext and context sharing ? Or could it cause other issues ? > You can't use DrawThreadPerContext when sharing contexts except when your scene graph uses no OpenGL objects whatsoever. So no display lists, no VBO's, no textures etc. Basically if you want shared contexts you have to use it SingleThread so the different threads don't contend with the same resources. > > > robertosfield wrote: > > You don't provide any information about the set up of the Cameras and > render order so there isn't any way for others to be able to guess the > cause of this. > > My master camera (the one rendering to texture) is set to PRE_RENDER. The > render target implementation is set to FRAME_BUFFER_OBJECT but using other > implementations doesn't seem to change a thing. It is linked directly to > the main scene (using View::setSceneData()). > > My two slaves cameras that are displaying the generated texture are both > set to POST_RENDER. They are linked to a single Geode with a single > drawable attached to it and using the generated texture. > > Also, both the Texture2D instance holding the generated texture and the > drawable have their data variance set to DYNAMIC. > > Do you see any obvious mistake in this ? > In principle this sounds like it should be OK. Personally I wouldn't use a master Camera as a render to texture camera. A slave Camera is probably a better way to do it. I don't know enough about what you are doing to really know where you are going with it all. I don't really have the time to go chasing up your implementation. Please have a look at the OSG examples for render to texture to see how they manage things. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
