Hi Roger, I don't have the time available at the keyboard to look into this issue, so the best I can do is point you in the right direction. If you are using requiring pbuffers or even a separate window then the RTT code will have switch between the original context to pbuffer and back to the original context, the later operation is what will require the handle to the graphics context, without this you'll be left with the wrong context being current. So for pbuffers to work the main thread really has to have a valid GraphicsContext the RenderStage can interface with.
Perhaps you could create a proxy GraphicsContext for the main window that implements the makeCurrentImplementation() and relaseContextImplementation() - tying them to your apps windowing. It need't implement the graphics context just allow integration with. Robert. On 3/17/07, Roger James <[EMAIL PROTECTED]> wrote:
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Robert Osfield > Sent: 17 March 2007 12:12 > To: osg users > Subject: Re: [osg-users] Problem with osg::GraphicsContext > whenRenderStage::RunCameraSetup falls back to PIXEL_BUFFER_RTT > > HI Roger, > > Have you look at the latest version of the OSG in SVN? I vaguely > recall coming across such an issue in dev of osgVIewer in that it > doesn't yet provide support for pbuffers, so will have to fallback to > frame buffer. > > Robert. > Robert, I have looked at the new code now, and it looks like the problem is still there. This problem is probably quite rare in that it will only occur when an application has a window being rendered via direct usage of osgUtil::SceneView in the old fashioned way i.e. by managing the graphics context itself and making sure it is current before calling the SceneView cull and draw methods. If that application has anything in its graph that requests a renderTargetImplemntation that is not FRAME_BUFFER both the current CVS code and the new SVN will prevent that application from using a pBuffer (or anything needing a context) even though one is available. This is because the call to osg::GraphicsContext::createGraphicsContext in RunCameraSetup in osgUtil::RenderStage will fail because s_createGraphicsContextCallback or s_WindowingSystemInterface point at the dummy default implementation. Now if the developer of such an application desires to complicate matters further by adding code to open another window on which it will use either osgProducer or the new osgViewer the mere fact of linking in either of these will cause another more serious the problem to appear, even if that new window is never in fact created. Because the call to osg::GraphicsContext::createGraphicsContext will now work and if (_graphicsContext.valid() && _graphicsContext != callingContext) { ... callingContext->releaseContext(); in RenderStage::draw will crash because _graphicsContext is now valid but callingContext is NULL. I do not know what the way forward is on this. Maybe the fix should be in SceneView and a way of initialising a context from one that has been created externally is needed or maybe it is enough to infer that NULL is a externally managed context that should not be interfered with. Enjoy. Roger _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
