Texture Compression of very large images

OpenGL Development JOGL Development
#1

I am trying to get texture compression into my jogl program in which I have a sphere that I would like to use 2 different textures on at different times. These textures are large 8192x4096 images in .pgn format. If I want to switch which texture is being useful when rendering it takes at least 6 seconds on my mid-range 6 month hardware. This is not responsive enough.

Right now I use the following lines of code to place a texture on a gluSphere:

//stuff mostly in the constructor (the “glu” is a GLU object), I do this twice for the two textures
GLUquadric quadric = glu.gluNewQuadric();
glu.gluQuadricTexture(quadric, true); // I believe this tells it to automatically do the texture coordinates and mipmaps
Texture tex = null;
try{
tex = TextureIO.newTexture(new File(“image.png”),true);
tex.setTexParameteri(GL.GL_TEXTURE_MAG_FILTER, GL.GL_LINEAR_MIPMAP_LINEAR);
tex.setTexParameteri(GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR_MIPMAP_LINEAR);
}catch(Exception e){}
tex.bind();

//later on I call this to render the gluSphere
glu.gluSphere(quadric,10,100,100);

To switch between textures I call tex.bind() or tex2.bind() right before the gluSphere call.

Is this proper technique? Moreover, would adding texture compression improve the speed at which it can switch between my textures? Since the textures are so large I am concerned about them not fitting on my video memory simultaneously. However, I called “getEstimatedMemorySize()” on my textures and they returned 96MB for each texture which is less than the 256MB that I have to work with. I believe that my code does automatically make mipmaps which could increase the memory load to more than what I have available if I understand how that works. I noticed that my page file usage (I ran this on windows xp) increases from around 250MB to 1GB when I run my program, which seems to be more than would be possible even if everything were stored there.

#2

Do you create a new Texture object each time you switch? It might be faster to do 2 TextureIO.newTextureData() calls to get the data into cpu memory and then have 1 texture that you just set the TextureData object for. Or, if that doesn’t work fast enough, you could try call glTexSubImage2D(…), which should be have a faster transfer of data than glTexImage2D(…) which is what I assume is being called each during TextureIO.newTexture().

Or try having both textures on your graphics card at once to see what happens.

#3

Thank to some help I found at the gamedev.net forums I was able to solve my problem. For the reference of anyone reading this thread I will post what I did below. If you think there is a better way to do this, please tell me too.

When creating a texture, the lines of code I used was as follows:
TextureData textureData = TextureIO.newTextureData(new File(“Image.png”), true, null);
textureData.setInternalFormat(GL.GL_COMPRESSED_RGBA_S3TC_DXT3_EXT);
texture = TextureIO.newTexture(textureData);
texture.setTexParameteri(GL.GL_TEXTURE_MAG_FILTER, GL.GL_LINEAR_MIPMAP_LINEAR);
texture.setTexParameteri(GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR_MIPMAP_LINEAR);

(this requires importing at least the following: com.sun.opengl.util.texture.Texture, com.sun.opengl.util.texture.TextureData, com.sun.opengl.util.texture.TextureIO, and java.io.File)

This was done in a try-catch statement, and “texture” refers to a Texture object whose declaration is not shown. Apparently this call applies a compression algorithm called DXT3 on the textureData. I don’t know if this is the best argument to use in the setInternalFormat method, but it does work. I can now switch between my formerly uncompressed 8192x4096 textures smoothly and I really can’t detect any visual degradation due to the compression. The time it takes to initialize the program has increased a lot though supposedly due to the time spent compressing.

#4

Texture compression. Which format is best depends on the texture data in question. In general, DXT5 is the most general purpose, DXT3 has paletted/quantised alpha which may be more suitable for sharp-edged sprites, and DXT1 has no alpha channel support.