Re: [osg-users] Image::readPixels (3.0.1)

2012-03-29 Thread Robert Osfield
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

Re: [osg-users] Image::readPixels (3.0.1)

2012-03-28 Thread Robert Osfield
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

Re: [osg-users] Image::readPixels (3.0.1)

2012-03-28 Thread Andrew Cunningham
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

[osg-users] Image::readPixels (3.0.1)

2012-03-27 Thread Andrew Cunningham
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