Hi Gianluca, You could easily just create an entirely separate viewer for doing the screenshots. You can have this run in the background with no need to affect the main viewer's threading/graphic contexts.
Robert. On Thu, Jan 28, 2010 at 10:31 AM, Gianluca Natale <gianluca.nat...@adstorino.it> wrote: > Thank you Robert, > I like the idea of a pixel buffer completely behind the scenes, > especially since I can use a different size (that was the worst disadvantage > of my implementation using OGL). > > So, I should create a osgViewer::Viewer associated to a graphics context > with the desired > pixel format and size, and set the sceneData of the viewer with the root > node of my model. > Then make that graphics context the current context, render the model in > that viewer, > and read the pixels of the pixel buffer after drawing. > Create an osg::Image with the content of the buffer and write it in my > desired file format > (as OSG supports many different graphic file format). > Finally release the graphics context. > Does it work? > > Thanks > Gianluca > > > > -----Original Message----- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert > Osfield > Sent: giovedì 28 gennaio 2010 11.07 > To: OpenSceneGraph Users > Subject: Re: [osg-users] drawing in back buffer without swapping? > > Hi Gianluca, > > The OSG allows you to create graphics context, make the context > current and then dispatch rendering and do swap buffers yourself but > this requires you to individually set everything up yourself. > > What osgViewer does is provide all the basic functionality that 99% of > users need out of the box, including handling context creation, > multiple contexts, handling of database threading, viewer threading, > event handling etc. It makes what would be a complicated task > trivial, but with encapsulating all this functionality it has to make > some assumptions about the way it's used, and I'm afraid your specific > case isn't handled out of the box. > > You could if you want roll your own mini view with a pbuffer and do > what you want completely behind the scenes so that the user doesn't > know about it. This has the advantage that the pbuffer size can be > different than the on screen size, it also avoid issues with other > windows/toolboxes overlapping the window. > > The other route would be to stop the viewers threading, then make the > context current and then insticate your won cull and draw to do the > rendering, then release the context, and then start the viewer > threading once more. > > Another route would be to use a viewer slave camera that sole job is > to the render the screenshot, it has a NodeMask of 0x0 for all frames > except the one you want to capture the screen shot, then you just > switch it on for this frame. The slave camera would be rendered prior > to the main frame - so you'd set the RenderOrder on this slave Camera > to pre render. This approach would still require you to rendering a > normal frame and have the extra cost of the rendering the scene, but > for most apps you should be hit 60Hz anyway so it'd wouldn't be > anything a viewer would notice, at most you'd get a frame drop when > you added in the extra slave camera's rendering work. > > Robert. > > On Thu, Jan 28, 2010 at 9:46 AM, Gianluca Natale > <gianluca.nat...@adstorino.it> wrote: >> Thank you Paul. >> The reason why I need to render in background is this: >> >> I need to save an image of my model with a different camera position and >> orientation >> than that currently visible to the user on the screen (i.e. in the front >> buffer). >> So, I thought that I could draw my model from a different point of view >> in the back buffer, without swapping. >> Then get it by reading pixels from the back buffer, and saving the pixmap > in >> an image file. >> Finally, restore the camera position and orientation, >> and resume in swapping back and front buffers after drawing. >> So, the complete operation would be completely hidden to the user. >> I always did it using standard OpenGL calls (glDrawBuffers(...), >> glReadPixels(...), etc...) >> since I could control whether and when swapping the buffers or not. >> I wondered why OSG does not allow such an operation, I thought it is a >> limitation. >> But now you're saying that OSG provides a better way to do that. >> Could anyone give me some more tips and suggestions (I'm still a newbie to >> OSG)? >> >> Thanks in advance >> Gianluca >> >> >> -----Original Message----- >> From: osg-users-boun...@lists.openscenegraph.org >> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul > Martz >> Sent: mercoledì 27 gennaio 2010 19.25 >> To: OpenSceneGraph Users >> Subject: Re: [osg-users] drawing in back buffer without swapping? >> >> From a little code digging, there doesn't appear to be a way to turn >> this off. ViewerBase::startThreading always adds a SwapBuffersOperation >> per render thread, and SwapBuffersOperation::operator() always calls >> swapBUffersImplementation and clear. >> >> Maybe there's a way to delete that Operation and add your own. >> >> Or you could derive your own GraphicsContext that allows you to make >> swapBuffersImplementation a no-op, I guess. >> >> Or you could set up the Viewer embedded, in which case creating the >> context and swapping is up to you and no longer managed by osgViewer. >> >> But I guess I'd wonder why you need to do this in the first place. If >> you need to partially render, then do some app code, then render some >> more before swapping, OSG has many facilities for this already. So can >> you explain why you think you need to render into the back buffer but >> not swap? >> -Paul >> >> >> Gianluca Natale wrote: >>> >>> >>> Hi all. >>> I have an osg::viewer and its associated graphics context, that is a >>> double buffered context. >>> >>> I need to draw in the back buffer without swapping the back and front >>> after rendering traversal. >>> >>> How can I do that? >>> >>> I cannot find a way to disable the swapping after drawing in >>> osgViewer::Viewer and in osg::GraphicsContext. >>> >>> >>> >>> Thanks in advance >>> >>> Gianluca >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org