[osg-users] Strange setImage behaviour

Robert Osfield robert.osfield at gmail.com
Wed Mar 11 02:17:22 PDT 2009


Hi Max,

On Wed, Mar 11, 2009 at 8:42 AM, Max <osgforum at tevs.eu> wrote:
>  The problem is when I convert my image (instead of when I open it with osgDB::readFile, but I can't do it in my final purpose) my quad isn't textured.
>
> img->imageData exists, it's an attribute of the opencv's image's class.

Looking at your code it's clear that the parameters you are passing to
setImage are screwed, so it's a case of garbage in, garbage out.

teximg->setImage(img->width, img->height,1,
                                       GL_TEXTURE_2D,GL_RGB,
                                       GL_UNSIGNED_BYTE, (unsigned
char*) img->imageData,
                                       Image::NO_DELETE, 1);

The GL_TEXTURE_2D is the key problem.  Go have a look at all the
instances of setImage in the OSG distribution. also have a look at the
parameter names of the setImage:

        void setImage(int s,int t,int r,
                      GLint internalTextureformat,
                      GLenum pixelFormat,GLenum type,
                      unsigned char* data,
                      AllocationMode mode,
                      int packing=1);

The internalTextureFormat is the pixel type when stored down on the
GPU.  Typically it's be GL_RGB, or just 3 (number of components) for
RGB data.  Both the internalTextureFormat and pixelFormat are provided
as sometimes you want the driver to change the data type on download
or pack it differently, for instance the source image might be packed
as GL_BGR.

As for the dirty() or allocateImage() calls, these are totally
redundant as setImage does a dirty so the texture will automatically
know about your image change.

Robert.



More information about the osg-users mailing list