DDS Loader fails on trying to load dds texture with DX9/DX10+ header encoding.

[winutta]

Unable to load dds with ddsloader

I am trying to load a envmap dds file but am getting the errors:
“THREE.DDSLoader.parse: Unsupported FourCC code” with the DX9 version
or
“THREE.DDSLoader.parse: Unsupported FourCC code DX10” with the DX10 version
these are the two options provided by the program I am using to export.

Is there any way to load this kind of file in threejs? Is this something the loader needs new functionality to handle?

I would appreciate any help, thanks.

To Reproduce

Here is a reproduced example codepen to show the error I am facing. Using the latest version 0.141.0 https://codepen.io/lablr/pen/MWQXGYy

Platform:

• Device: [Desktop]
• OS: [Windows]
• Browser: [Chrome]
• Three.js version: [0.141.0]

[Mugen87]

@donmccurdy already added some important details at the forum: https://discourse.threejs.org/t/help-loading-envmap-dds-loader-error-three-ddsloader-parse-unsupported-fourcc-code-dx9-dx10/38829

[donmccurdy]

/cc @LeviPesin – it looks like you made the most recent updates to DDSLoader, any thoughts on supporting BC6H cubemaps there?

It's on my to-do list to add BC6H support to KTX2Loader, since the format is helpful for compressed envmaps and lightmaps, but it may be a while before I can start to work on that... and (for the OP) I don't know how to convert these .dds files to KTX2 or EXR or anything else if OIIO can't read them. :/

[donmccurdy]

Oh, hah – it turns out macOS Preview can open the file and convert to OpenEXR by itself. The file looks "the same" before/after in Preview to me, is this what you expect? .exr file for EXRLoader below:

bit_bc6h_dx10_cube_specular.zip

I've exported a PNG preview as well, which won't contain the original HDR data, but is visible in github comments:

[winutta]

That's interesting that the conversion is possible with preview. Will the exr version preserve the custom mipmaps in threejs, or is it just the first image?

[donmccurdy]

It doesn't look to me like this EXR version contains mipmaps. I think the EXR format supports them, but if the original DDS file had mipmaps then perhaps Preview has ignored them. I guess Preview is not a very robust conversion tool for graphics data. 🥲

[donmccurdy]

After checking the files you shared earlier on Discord, OpenImageIO can only read the 8-bit version of the DDS file. OIIO does support 16-bit and 32-bit for other formats so I'm not sure why it has trouble with the DDS version. It does see the mipmaps in the 8-bit version too. But unfortunately 8 bits won't be enough for a correct HDR-to-HDR conversion.

oiiotool -i ~/Desktop/dds_256/bit_8_dx10_256_cube_specular.dds --printinfo

256 x 1536, 3 channel, float dds
    MIP-map levels: 256x1536 256x1536 128x768 64x384 32x192 16x96 8x48 4x24 2x12
    channel list: R, G, B
    full/display size: 256 x 256
    full/display origin: 0, 0
    tile size: 256 x 256
    textureformat: "CubeFace Environment"
    dds:CubeMapSides: "+x -x +y -y +z -z"
    oiio:BitsPerSample: 32

[winutta]

Good to know that the 8 bit version may be usable, I'll try it with the loader

[winutta]

I tried the 8 bit version of the dds with the ddsloader in threejs, (bit_8_dx10_256_cube_specular.dds) same issue as above.

“THREE.DDSLoader.parse: Unsupported FourCC code”

I guess you were trying to convert to another format using enough data to still be HDR, because the dds cubemap isnt supported at this point. Am I understanding correctly?

In that case, would support for cubemaps be available for the DDSLoader in the future?

[donmccurdy]

I guess you were trying to convert to another format using enough data to still be HDR, because the dds cubemap isnt supported at this point. Am I understanding correctly?

Yeah, I was hoping I could find a DDS version that (a) OpenImageIO could read, and (b) was still HDR, so we could convert this to a more manageable format. No luck so far.

I'll defer to @LeviPesin and @Mugen87 on whether cubemap support is something we'd want to (or can) add to DDSLoader.

[LeviPesin]

/cc @LeviPesin – it looks like you made the most recent updates to DDSLoader, any thoughts on supporting BC6H cubemaps there?

I was just fixing a broken check there, sorry. I do not know much about it...

[Mugen87]

@donmccurdy I can set this point on my todo list. At least it's worth an investigation since this topic is related to #9688.

@winutta Are you fine when I use your S3TC texture for tests and maybe an official example?

[winutta]

@Mugen87 I'd prefer to just use a more common env map if thats okay, I created some more examples though that give the same error. I used a texture from poly haven with CC0 licensing, https://polyhaven.com/a/provence_studio.

Here are the cubemaps https://github.com/winutta/DDS_cubemaps

filenames are data/compression type, header encoding, resolution (256px squares)

[Mugen87]

I've hacked around a bit in the last days but I'm not having a good feeling to implement loader code without a reference 😓 . Does somebody know a better documentation than the Programming Guide for DDS that covers the processing of formats like DXGI_FORMAT_R32G32B32A32_FLOAT? I don't get the final colors right and I assume there is something wrong when extracting the data from the DDS file.

[donmccurdy]

Related:

• Fully support DDS to KTX2 pipeline KhronosGroup/KTX-Software#92
• https://github.com/microsoft/DirectXTex
• https://github.com/KhronosGroup/BC6H-Decoder-WASM

[Mugen87]

According to Unpacking and Packing DXGI_FORMAT for In-Place Image Editing there is a way to extract the raw data from textures but it requires the usage of DirectXTex.

To be clear, the S3TC support in WebGL is limited to a bunch of formats related to DXT1, DXT3, DXT5 (e.g. COMPRESSED_RGBA_S3TC_DXT5_EXT). If we want to load a texture in the DXGI_FORMAT_R32G32B32A32_FLOAT format, it's necessary to extract the raw floating point data and produce an uncompressed RGBA texture. However, the extracting/reading is meant to be done with DirectXTex.

So there is the option to rewrite the code based on DirectXTex's implementation or use DirectXTex somewhow in the browser (if technically possible).

Not sure it's worth the effort if we could redirect users to other texture formats like KTX2.

[mrdoob]

Is it time to remove the loader and examples from the repo?

[Mugen87]

I've seen the usage of DDSLoader quite often in the past so I would not recommend to remove it at this point. Instead, I would suggest the following:

• Define that DDSLoader only supports the DDS formats specified in the respective WebGL extensions WEBGL_compressed_texture_s3tc and WEBGL_compressed_texture_s3tc_srgb. That is already the case so there is no need to further enhance DDSLoader (meaning this issue can be closed).
• Wait until KTX2 is more established and then eventually remove DDSLoader and PVRLoader.

[mrdoob]

That sounds good to me 👍

[donmccurdy]

Perhaps we also mark it deprecated like BasisTextureLoader? Users can let us know if it provides something the other loaders currently do not.

[mrdoob]

That also sounds good 👍👍

[Mugen87]

Perhaps we also mark it deprecated like BasisTextureLoader? Users can let us know if it provides something the other loaders currently do not.

How would users convert existing DDS or PVR files to KTX2? Are there tools for doing this?

[donmccurdy]

I'm not sure what authoring tools can read DDS or PVR files at all, much less convert them to something else. Given these are older formats, there may not be much to look forward to there. 😢

I'd keep an eye on KhronosGroup/KTX-Software#92, beyond that OpenImageIO is probably the best tool to investigate, but its DDS support is incomplete as described above.

[Mugen87]

I'm just asking since it feels not ideal to deprecate DDSLoader and PVRLoader but offering no solution for converting existing files. If users encounter a deprecation warning, this is probably the first thing they are going to ask.

Since both loaders are actually quite compact, I would prefer to not deprecate them. Instead I would state that both loaders only support the formats specified by the respective WebGL extensions (which both loaders already do).

No matter how we decide, this issue can be closed in any event.