Reusing TextureData object for several textures

Hi,

I’ve written a class TextureRepository containing TextureData objects for different material (like asphalt, concrete, …).
My idea was to load one TextureData object for each material so that I can later use one TextureData object with several Texture objects (several roads with concrete material).

When I’m loading the texture like that:


textureData = TextureIO.newTextureData(file, true,TextureIO.JPG);

texture1 = TextureIO.newTexture(textureData);
texture2 = TextureIO.newTexture(textureData);

I get the following exception:
Exception in thread “AWT-EventQueue-0” java.lang.IndexOutOfBoundsException: Required 786432 remaining bytes in buffer, only had 0
at com.sun.gluegen.runtime.BufferFactory.rangeCheckBytes(BufferFactory.java:274)
at com.sun.opengl.impl.GLImpl.glTexImage2D(GLImpl.java:19579)
at com.sun.opengl.impl.mipmap.BuildMipmap.gluBuild2DMipmapLevelsCore(BuildMipmap.java:311)
at com.sun.opengl.impl.mipmap.Mipmap.gluBuild2DMipmaps(Mipmap.java:721)
at javax.media.opengl.glu.GLU.gluBuild2DMipmapsJava(GLU.java:1523)
at javax.media.opengl.glu.GLU.gluBuild2DMipmaps(GLU.java:1579)
at com.sun.opengl.util.texture.Texture.updateImage(Texture.java:356)
at com.sun.opengl.util.texture.Texture.updateImage(Texture.java:244)
at com.sun.opengl.util.texture.Texture.(Texture.java:88)
at com.sun.opengl.util.texture.TextureIO.newTexture(TextureIO.java:423)

When I now disable mipmapping, everthing works fine and the textures are displayed.

I am using the following VM flags: -Dsun.java2d.noddraw=true -Xmx512m
But even using 1024m as maximum heap size does not help.

Is it somehow possible to reuse the TextureData objects with mipmapping or do I have to disable mipmapping for this approach?

Cheers,
Jens

i had this problem myself, the problem is afaik in the gluBuild2dmipmaps, the solution is to build your mipmaps yourself

I would personally classify this as a bug. What’s probably happening is that somewhere in the TextureIO#newTexture implementation, the position of the buffers of the TextureData object are being modified. If this is not considered a bug, then at least the unexpected side effect of this method should be doucmented. A nicer behaviour would be to restore the position(s) to their initial value.

Agreed. I’ve filed Issue 230 to track this; sorry about the problem.

A fix has been checked in and should be available in the nightly builds dated 6/23 or later. Please try one of these builds and post if the problem is still happening.