Ah, Thanks for the info Stephan, that might solve my issue. I'll give it a test.
Tom On 1 October 2013 15:15, Stephan Maximilian Huber < [email protected]> wrote: > Hi, > > I had problems reading the frame buffer in my app as a screenshot too. I > added a new property for the WindowData-struct called useRetainedBacking. > If this is set to true, the back buffer will not invalidate, and you can > grab the frame-buffer at any time. This fixed the problem on my end. > > Perhaps this is also a viable solution for your problem? (But I may be > completely wrong ;-) > > cheers, > > Stephan > > Am 01.10.2013 um 16:09 schrieb Thomas Hogarth <[email protected]>: > > Hi Robert > > You are probably right it is a little iOS specific. > > Yes I've only seen this issue on iOS and pretty sure it is due to the use > of FBO for windows. > It is also that we essentially need to do the > glResolveMultisampleFrameBuffer() and have that buffer bound > when we do the readpixels. Otherwise it just returns black. > > I wasn't really sure how to go about making this more generic, > other than perhaps some kind of prepareForScreenCapture, or > forceResolveBuffers in GraphicsWindow? > > Tom > > > > > On 1 October 2013 09:42, Robert Osfield <[email protected]> wrote: > >> Hi Thomas, >> >> I've just done a review and while the changes aren't significant and >> are fine by themselves I do wonder if it's the best way forward. My >> main concern is that it's solution for specific platform that won't be >> obvious to most users - one has to know that you need to do this with >> IOS when using AA and want to do screen capture. >> >> Do you know if this problem exists on other platforms where AA is >> used? I'm wondering if it's just the issue with that face that IOS >> uses FBO's for main windows. Where I'm going is trying to work out >> whether this feature is something that we'd want to formalize - but >> such as having the bind/resolve method available at higher level and >> available to all platforms that might need it. >> >> Even if we do just keep the implementation and API IOS specific I >> wonder if the naming might be too specific w.r.t >> bindScreenShotBuffer(). Is the action effectively focused around the >> glResolveMultisampleFrameBuffer() then perhaps naming should reflect >> this and the doxygen comments explain when and where it is appropriate >> to call it. >> >> Thoughts? >> Robert. >> >> Robert. >> >> >> >> On 15 September 2013 01:23, Thomas Hogarth <[email protected]> >> wrote: >> > Hi Robert >> > >> > Attached are a changed GraphicsWindow and GraphicsWindow.mm from r13788 >> that >> > provide some functions to help with Screen Capture when using >> AntiAliasing. >> > >> > Basically in a Final Draw Callback the multisample buffer needs >> resolving >> > before you >> > can call readpixels, else you just get black. >> > >> > Something like >> > >> > osgViewer::GraphicsWindowIOS* osgWindow = >> > >> dynamic_cast<osgViewer::GraphicsWindowIOS*>(renderInfo.getCurrentCamera()->getGraphicsContext()); >> > >> > osgWindow->bindScreenShotBuffer(); >> > >> > glReadPixels(x, y, width, height, GL_RGBA, GL_UNSIGNED_BYTE, buffer); >> > >> > _______________________________________________ >> > osg-submissions mailing list >> > [email protected] >> > >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > >> > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
