TextureIO (Non power-of-2 textures, what's the problem?)

OpenGL Development JOGL Development
#1

Hi,

In the JavaDoc, on the com.sun.opengl.util.textureTexture class, there is the following comment:

What are these issues?

I am asking, because when I load power of two textures (e.g. 512x512, or 512x256) and map it to a quad, it works fine (see attachment 01) but when I load an arbitrary size texture, nothing shows up (quad is white - see attachment 02).

Is there something special I need to do with the JOGL texture Utilities, or should I rather manage the creation of textures myself (it is possible to accomplish non-power-of-2 textures through a relatively simple algorithm). I am using the latest JOGL Beta 3.

#2

The dimensions of textures in OpenGL must be a power of two (cfr. glTexImage2D). Arbitrary sized textures are supported through the EXT_texture_rectangle and ARB_texture_non_power_of_two extensions, but I’m not sure if the Texture class supports this.

#3

Does the demos.texture.TestTexture demo in the jogl-demos workspace load and display your non-power-of-two texture correctly on your machine?

If so, please look at its source code and see how it figures out what texture coordinates to use. If not, please attach the failing image to one of your posts here so we can take a look at it. Thanks.

#4

Hi,

The texture loader demo does load my non-power-of-2 texture correctly, thank you…
I am busy downloading the source to have a look at it.

regards,
Dawid

#5

I was one of the original authors of that class. The TextureIO stuff will try to leverage the GL_ARB_texture_rectangle and GL_ARB_texture_non_power_of_two extensions whenever possible. If neither are available, it will just stick the non-pow2 image in a pow2 texture (without any special scaling), and then the texcoords will be calculated appropriately and returned via the convenience methods. The only issues with these approaches (AFAIK) is in the area of texture wrap modes. If we use the GL_TEXTURE_RECTANGLE_ARB codepath, then certain wrap modes are not legal:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_rectangle.txt

Note that these restrictions do not apply to the non-pow2 codepath, or in the default pow2 codepath. However, in the default pow2 codepath, if you rely on any of the wrap modes in your application (e.g. GL_REPEAT, GL_CLAMP_TO_EDGE) then wrapping may not work as you might expect (esp. when your image does not extend to the edges of the pow2 texture). There are probably ways to deal with this in the TextureIO implementation, but they’re all hacky (we have to resort to some of this in the OGL pipeline for Java 2D).

So anyway, the REMIND comment was referring to these issues. I think the easiest way to resolve it is to clearly document these issues (i.e. if you rely on texture wrapping modes, then be sure to specify a pow2 image, unless you can be sure that the GL_ARB_texture_non_power_of_two extension is available).

This was another thing that should be added to the docs somewhere. OpenGL developers often aren’t aware that the image data (and things like glColor()) they typically deal with is non-premultiplied, meaning the alpha component hasn’t been applied to the color components. However, the typical Porter-Duff blending rules require that both the source and destination components are premultiplied. 99% of the time OpenGL developers just want “source over” mode, and all the tutorials will tell you to use glBlendFunc(GL_SRC, GL_ONE_MINUS_SRC_ALPHA), which is a clever way to get “source over” blending (with the components premultiplied as part of the blending step, but it’s not strictly the same as the way P-D define it).

Anyway, it’s much easier to do all blending in OpenGL if you’re dealing with premultiplied components, so when I was working on the TextureIO stuff I made sure that translucent images are premultiplied before storing them in the texture. This probably makes sense to those familiar with Java 2D’s “_PRE” formats, but might not be obvious to OpenGL developers, thus the comment.

It would be great if someone could boil this down into the javadocs for the TextureIO stuff (I’m too busy with Java 2D stuff at the moment).

Thanks,
Chris

#6

I’m a little confused about the premultiply process that you mention on TextureIO. What does it mean to apply the color to the alpha components? Does that mean that the luminance of the resulting colors is then used for alpha?

For example, I’ve got a demo where I want some translucent dark textured quads to occlude lighter ones. If I use a dark PNG texture and use the alpha map to cut holes out of it, the holes definitely appear. However, it still looks like the remainder of the texture has alpha from its colors, i.e. the black areas are transparent instead of being solid black. Is this behavior the result of this premultiplication, or am I confusing something else? Is there any way to get the expected behavior: the alpha channel being independent of the color?