HI Stephan, On Tue, Nov 16, 2010 at 4:12 PM, Stephan Maximilian Huber <[email protected]> wrote: > So what's your opinion to tackle this issue? Another virtual method > inside GraphicsWindow? Something like > > virtual void osg::GraphicsWindow::unbindFbos() {} > > where GraphicsWindowIphone override this method and bind its fbo-ids again? > > Or is there a better approach?
I sounds a bit like the issue that the OSG's rendering backend has to deal with when managing pbuffers that are used for rendering to texture. The rendering backend has to releaseContext() on the window, then makeCurrent() on the pbuffer, do the work, then do releaseContext() on the bpuffer, then makeCurrent() on the window. Now makeCurrent() and releaseContext() have specific meaning w.r.t contexts, but perhaps this same meaning could be confered to the iOS GraphicsWindow w.r.t fbo's. It isn't quite the same though... with iOS it'd still be the same context and sharing all the same GL objects virtue of being the same context. I wonder if the FBO Id for the iOS GraphicsContext could be stored in the GraphicsContext and when it's non zero have rendering backend pick up on the fact that the GraphicsContext isn't an ordinary graphics context but really just a FBO and then have the rendering backend use the FBO id to re-enabling it after rendering to the RTT FBO's. Thoughts? Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
