I started working with JMonkey (great engine btw!) and I see that it supports dds textures as well as texturearrays.
Unfortunately, when filling my texturearray with DXT1, DXT3, or DXT5 compressed textures, the output geometry is completely black.
Only if I use RGB888 (I use ATI Compressonator), the textures work, but the resulting file is pretty big (a single 1024x1024 texture takes up to 4 MB oO).
JPG or PNG work without any problems btw.
The odd thing is, that the DDS texture (even DXT1, 3 or 5) works well when I do not use texturearrays, but “default” texture2d, so it seems to be a problem with texturearrays? Or am I doing something wrong perhaps?
Unfortunately, the output textures from the nvidia tool also don’t work, at least if I use DXT (bc1-5).
When using the -rgb option, the texture works, its recognized as RGB8, but consumes a lot of memory (170kb DXT1 vs. 1,33mb RGB, 512x512 image).
I guess the RGB is uncompressed, isn’t it? So it seems that texturearrays don’t like compressed textures.
The DXT output from the nvidia tool can still be used as texture2d, but not within a texturearray =/
Alright, it looks like the texturearray feature in the nvidia tool does not work, it always creates a cubemap. There is another tool that can produce texturearray-dds (PVRTexTool), but it looks like the jme DDSLoader is having some problems with it. When trying to load a texturearray-dds, it throws an exception “Only DXGI_FORMAT_BC5_UNORM is supported for DirectX10 DDS! Got: 0”, independent of the format.
So just for the record: The DDSLoader cannot load texturearray-DDS, and texturearrays cannot be filled with single compressed texture2D-DDS?
The problem can be reproduced by using the provided TestTextureArray.
With the default test you only see a single texture (Pond.jpg) where it should be 2 different textures as been seen in earlier builds. This is even a new problem!
And when changing it to load DXT5 textures the test wont even start.