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

Reply via email to