Hi Robert,

Robert Osfield wrote:
Hi Robert,

2009/12/8 Robert Milharcic <[email protected]>:
I'm aware of camera callbacks, but unfortunately once you pick the
image at the post draw callback ther isn't much to do except to to
post process resulting image and then copy results to new ussually
larger image (when you need image tiling or banding for example).
Processing and copying to new image can be huge problem once you
start to deal with several thousands*several thousands pixel
images. Another usage of read pixels callback would be to
completely bypass image allocation by outputing pixels directly to
the destination device (printer for example).

I don't believe you have grasped what I'm suggesting about using Camera post/final draw callback, rather than attaching and osg::Image and then processing this with the callback, you manage everything related to the allocation, image reading and post processing in the callback - this way you have complete control over the whole post process pipeline and can do as you wish.

just one comment/question... Yesterday I was experimenting with PBO image readback from FBO RTT camera's generated textures. It is possible to do this in the camera callback by binding the texture one wants to read from manually and doing glGetTextImage, but I did not find a way to use glReadPixels with a PBO, because in the camera callback the FBO is already unbound and glReadBuffer is not set (all this is handled in RenderStage). I'm not sure how to do this all manually in the callback. Is it possible?

regards
jp


The Camera post/final draw callbacks offer you far more flexibility than a Image::readPixels callback could ever do so I can't see any point in the readPixels callback, and believe it's simply the wrong way to tackle the problem you want to solve.

Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support.

_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to