odd problem with glTexImage3D

OpenGL Development JOGL Development
#1

Ok; I’m probably overtaxing the 3D texture hardware with all this, but hey; if they didn’t want me to use it, they shouldn’t have put it in there :stuck_out_tongue:

Anywho, I’m using a 3D texture object to store a volume of data (naturally). It works like a charm with power of two dimensions.

For various reasons specific to my project, it would be VERY desirable to use NPOT dimensions for that texture, however, as all the code i’ve written to compensate for the POT padding is quite cumbersome. But there’s a nasty little bug preventing me from doing so; namely that glTexImage3D will not accept an NPOT dimension on the X axis. The y and z axes will accept any value i throw at them (shy of the 512 driver maximum) quite happily, but the width (x axis) causes a crash if I give it a NPOT value.

Clearly this is not the intended behavior, but so far i have no idea whose bug this probably is. My first thought was an NVidia driver bug… but perhaps it could also be something in jogl?

PLEASE PLEASE tell me somebody that you know something about this. This bug has single handedly doubled the complexity of an already complicated highly special-purpose renderer.

OS = W2K
GFX = MSI GF6600 256MB
driver = latest NVidia release
jogl = latest build (but bug also occurs with both jsr-231 release versions)

#2

Sorry but I don’t think there’s any way this can be a bug in JOGL. It does nothing with the outgoing texture data or any kind of behind-the-scenes argument manipulation. Have you posted on NVidia’s developer forums?

#3

doesn’t really surprise me; I was having a hard time envisioning any way that jogl could be responsible. I’ve just been pulling my hair out about it for so long i’m willing to consider any possibility.

I’m still trying to gain access to nvidia’s forum. been about a week since i spent half an hour signing away my first born on that “registered developer” application; still haven’t heard back. I plan to ask about it on their forums when (if) i get access.

#4

You might also try the forums on opengl.org, which don’t have any registration requirements.

#5

OK - new revelation; somehow i’ve been an idiot and misjudged the error. I apparently was testing with my data buffer when i determined (wrongly) that it was an opengl issue.

The method that calls glTexImage3D is this:

private void initializeIntensityVolume(int width,int height,int depth,ByteBuffer data,
                                        GL gl) {
    makeActive(gl);
    data.rewind();
    //the hard coded values in this line are equal to the current values of width, height, and depth
    //if uncommented, this line works.
    //gl.glTexImage3D(GL.GL_TEXTURE_3D, 0, GL.GL_INTENSITY, 354, 252, 168, 0, GL.GL_LUMINANCE, GL.GL_UNSIGNED_BYTE, null);
    //this line causes the crash
    gl.glTexImage3D(bindTarget,0,GL.GL_INTENSITY,width,height,depth,0,GL.GL_LUMINANCE,
                    GL.GL_UNSIGNED_BYTE,data);
  }

so… apparently something is wrong with my data buffer.

I’ve confirmed several times that it does have enough data, and is rewound… is there any other idiot mistake i might be making that would cause an access violation on the native side of glTexImage3D? Whatever it is i’m doing wrong, my padToPowersOf2() method appears to magically fix it; so i’m looking there now for differences between the new buffer it creates (with the contents padded) and the old buffer it throws away; cuz apparently whatever’s wrong is only a problem with the old (unpadded) buffer.

#6

I’m guessing it has to do with GL_UNPACK_ALIGNMENT which by default is set to 4. Your texture format consumes one byte per sample, so if your row length is not a multiple of 4 then that’ll cause the access violation.

Try this before calling glTexImage3D():


gl.glPixelStorei( GL.GL_UNPACK_ALIGNMENT, 1 );

Also, make sure the other UNPACK states are reset (GL_UNPACK_SKIP_ROWS, GL_UNPACK_SKIP_PIXELS, and GL_UNPACK_ROW_LENGTH, and there’s more I can’t remember now for 3-D textures).

#7

the unpack alignment appears to have resolved the issue. seems kinda silly that it should default to 4… but whatever. it probably makes sense for people doing normal things with OpenGL.