Hi Andrew,
Thanks for the callback code. Having a look at how this uses
osg::Image and how readPixels() calls allocateImage() it looks to me
the problems stems from the the later call not passing in the _packing
value so this defaults to 0. Your suggested fix of passing in the
_packing value to
Hi Andrew,
Calling setPacking after you've called setData or allocateImage will
break the packing of the image and is not something you should do.
There will circumstances that it would be safe, but in general it
won't be.
What to do about this flexibility of osg::Image that provides the
Just imagine this scenario of a DrawCallBack
struct SnapImage : public osg::Camera::DrawCallback
{
SnapImage(unsigned int format):
_snapImage(false),_format(format)
{
_image = new osg::Image;
_image-setPacking(4);
}
~SnapImage(){};
virtual void
I think there is an issue in Image::readPixels that I noted in 2.8.x
Assume you have set the Image packing is set to say 4 , via
image-setPacking(4) before this call.
glReadPixels might try and store 'too much' data into _data ( overwriting
memory) because glReadPixels will be expecting the
4 matches
Mail list logo