How to access Texture3D data with texture coordinates?

I know for 2d textures, you either use tex coords between 0 and 1 (outside has some wrap policy) or you use 0 to width/height (if the texture has rectangular coordinates).

When experimenting with initializing 3d textures, it seemed as if I could create a 3d texture that had each dimension completely different (and non-power of two)-> the 2d slices were rectangular, and the number of slices (depth) was different from both width and height.

I did not try accessing this oddly shaped texture, but I’m wondering if it has similar access policies when it’s not a cube. I didn’t have to use a different texture target to get rectangular textures, so I’m thinking that 3d texture access still uses normalized texture coordinates.

Does anyone know this for sure? If not I’ll try to figure it out and post the results.

Textures are orthogonal in that mipmapping/filtering, wrap/clamp modes, and coordinates all (are supposed to) work the same. Or at least that’s the case for 1D, 2D, and 3D textures, with cube maps being something of an exception. But yes, glTexCoord3f would be what you’d want and the coords will need to be normalized.

just out of curiosity what file format do you use when working with 3d textures? dds?

is there a java-loader for dds out there?

Thanks for the replies, that’s what I was hoping for.

@Emzic
I’ve written my own DDS reader (can’t write files) that seems to work fairly well. It can handle mipmapped 2d, cube maps and 3d textures and the dxt compressed textures. Right now it’s tied into a graphics engine I’m working on, but if there’s enough interest, I could probably make it work directly with JOGL.

lhkbob, yes i think if your dds reader could be made “standalone” to be used with jogl only, that would be a great addition to jogl! i think that many people here would be happy about a dds reader. maybe this is something for the jogl-utils projecT?

FWIW, there is already a DDS reader in the JOGL TextureIO classes, although it is definitely possible that it needs improvement.

Yes, I’ve looked at the source code for the DDS reader (it was very helpful ;)), but it lacked some of the support that I needed. The biggest issue was the lack of 3d textures and no directX 10 support.

BTW, I’ve almost converted the class into a solo utility, so I can post that once it’s ready. If anyone wants to include in jogl or jogl-utils, that’s fine by me.

the jogl-dds loader crashes for me with this stack:

java.lang.NullPointerException
at com.sun.opengl.util.texture.TextureData.(TextureData.java:258)
at com.sun.opengl.util.texture.TextureIO.newTextureDataImpl(TextureIO.java:842)
at com.sun.opengl.util.texture.TextureIO.newTextureData(TextureIO.java:250)
at com.sun.opengl.util.texture.TextureIO.newTexture(TextureIO.java:538)

lhkbob, yeah i would be happy to have a look at your dds reader! :wink:

btw: does anyone know of a good standalone TGA loader/writer for java?

I’ve finished making my dds reader standalone, so I’ve attached it. I don’t have any license associated with it, just give credit where credit is due :slight_smile: It can go in jogl-utils or jogl core, if the owners are interested. I’ve documented most of the code, although it’s not very in-depth.

From what I could tell, it works well. There could be bugs since I don’t have many dds textures to test it with, but it correctly loads cube maps and 3d textures. Also, when lazily benchmarked against the jogl DDSReader, the new reader seemed to be between 2-6 times faster for most dds textures I had.

thank you very much lhkbob!

so far i couldn’t test it much, because i am currently forced to work with a graphics card that does not support GL_ARB_texture_rectangle.
once i am back to my normal computer i will test it more!

thanks again!

sorry for the late reply. i finally got a chance to test it out, but unfortunately all of the texture seems to be white. what could i be doing wrong?

I’ve never seen this bug, but if you followed the usage given in DDSTexture.java, it’s problem caused by a bad combination of the loader and the actual image used. I’ve only tested it on 12 dds textures, but those all work. If you could send me the problematic texture, that’d be great. One possibility is that I’ve screwed a mapping from dds pixel format onto opengl texture type and it’s causing a gl error when the texture is created.

I’d check the errors after calling glTexImage() (if you’re using that method). Also, check the number of mipmaps in the texture, since glTexImage doesn’t set any glTexParameters.

Lastly I’ve attached an updated version that provides slightly more understandable error messages if the dds texture file is formatted incorrectly or if it’s unsupported.

thanks for the update.

i have attached the texture, but you need to rename it from txt or png to dds, since the forum does not allow dds directly.

I tried using the texture, but all I got was a very pale blue color. These are the stats pulled from the loader on the image:
10 mipmap levels, starting at 512 x 256 going to 1 x 1. It’s format is set to DXT3 compression.

The sizes of each mipmap level are computed correctly (as far as I can tell because every byte is read from the file), yet the cause of the problem is a GL INVALID_VALUE error generated after the second glCompressedImage2D. According to the spec, this only happens if the specified size of the image doesn’t match the expected size based on dimensions, etc.

Reading through the ARB_TEXTURE_RECT extension, they say this about rectangular textures:

[quote]This extensions makes a blanket statement that specific compressed internal formats for use with glCompressedTexImage are NOT supported for rectangular textures. This is because several existing hardware implementations of texture compression formats such as S3TC are not designed for compressing rectangular textures.
[/quote]
My bet is that the drivers just don’t support it. If people have successfully gotten compressed rectangular textures, I’d like to know; otherwise I will code in something to fail more informatively.