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