[BUG]

[cdj88888]

Bug Report: MSFT_texture_dds extension swaps image source indices incorrectly

Description

When creating a material with texture (via MaterialBuilder.WithChannelImage or ImageBuilder), the generated glTF file has incorrectly swapped image source indices between the standard texture source and the MSFT_texture_dds extension:

1. The images array contains two entries:

   • Index 0: The correct original texture file (e.g., DDS format, which is the texture I actually want to use)
   • Index 1: An auto-generated redundant PNG "satellite image" (I never created this image manually)

2. The textures entry shows:

   {
     "extensions": {
       "MSFT_texture_dds": {
         "source": 0 // Points to the correct original image (index 0)
       }
     },
     "source": 1 // Incorrectly points to the auto-generated redundant image (index 1)
   }

Expected Behavior
The standard source field should point to index 0 (my original texture)
The auto-generated redundant PNG image (index 1) should not exist at all (unless explicitly requested)
The MSFT_texture_dds extension should not be added automatically if I don't use DDS textures intentionally
Reproduction Steps
Create a simple material with MaterialBuilder.WithChannelImage (or ImageBuilder) to bind a texture file (PNG/DDS)
Export the model to glTF format via ModelRoot.SaveGLTF()
Check the generated glTF JSON:
images array has 2 entries (1 original + 1 auto-generated)
textures[0].source = 1 (wrong), textures[0].extensions.MSFT_texture_dds.source = 0 (correct)
Additional Notes
This issue occurs regardless of how I create the texture:
Using MaterialBuilder.WithChannelImage (direct file path)
Using ImageBuilder + WithPrimaryImage
Binding single/multiple texture channels
Exporting to glTF (satellite files) or GLB (embedded)
The redundant PNG image (index 1) is never requested by my code but is always auto-generated
The source index swap breaks texture loading in external tools (e.g., Blender, Three.js) because the standard source points to a non-existent/incorrect image
Environment
SharpGLTF version: [1.0.6]
.NET version: [NET 9.0]
OS: Windows 11

[cdj88888]

    private MaterialBuilder CreateMaterialWithTextureInfo(MeshData meshData)
    {
        var texturePath = meshData.Texture?.TextureRealPath; 
        if (meshData.Texture == null || string.IsNullOrEmpty(texturePath))
        {
            return new MaterialBuilder("EmptyMaterial")
                .WithMetallicRoughnessShader()
                .WithBaseColor(new Vector4(0.5f, 0.5f, 0.5f, 1.0f))
                .WithMetallicRoughness(metallic: 0.0f, roughness: 0.5f);
        }

        var matName = $"{Path.GetFileNameWithoutExtension(texturePath)}";
        var mat = new MaterialBuilder(matName)
            .WithMetallicRoughnessShader()
            .WithBaseColor(new Vector4(0.5f, 0.5f, 0.5f, 1.0f))
            .WithMetallicRoughness(metallic: 0.0f, roughness: 0.5f);

        ImageBuilder? imgBuilder = null;
        if (File.Exists(texturePath))
        {
            var imageName = $"{Path.GetFileNameWithoutExtension(texturePath)}_{meshData.Texture.Type}";
            imgBuilder = ImageBuilder.From(new SharpGLTF.Memory.MemoryImage(texturePath), imageName);
            imgBuilder.AlternateWriteFileName = $"{Path.GetFileName(texturePath)}";

            switch (meshData.Texture.Type)
            {
                case MeshTexture.TextureType.Diffuse:
                    mat.UseChannel(KnownChannel.BaseColor)
                       .UseTexture()
                       .WithPrimaryImage(imgBuilder); 
                    break;
                case MeshTexture.TextureType.Normal:
                    mat.UseChannel(KnownChannel.Normal)
                       .UseTexture()
                       .WithPrimaryImage(imgBuilder);
                    break;
                case MeshTexture.TextureType.Specular:
                    mat.UseChannel(KnownChannel.MetallicRoughness)
                       .UseTexture()
                       .WithPrimaryImage(imgBuilder); 
                    break;
                case MeshTexture.TextureType.Alpha:
                    mat.UseChannel(KnownChannel.BaseColor)
                       .UseTexture()
                       .WithPrimaryImage(imgBuilder);
                    mat.WithAlpha(SharpGLTF.Materials.AlphaMode.BLEND);
                    break;
                case MeshTexture.TextureType.Emission:
                    mat.UseChannel(KnownChannel.Emissive)
                       .UseTexture()
                       .WithPrimaryImage(imgBuilder);
                    break;
            }
        }
        return mat;
    }

This is My Code

[vpenades]

I'll look into it

[vpenades]

Well, technically speaking, the generated glTF is valid because glTF supports setting a fallback image for clients unable to read image formats other than JPG or PNG

So from the point of view of the specification, the generated model is well formed, so if Blender is unable to import it, then it's a bug on the Blender plugin that should be reported to them.

Another totally different matter is whether the fallback image makes sense in this case; A good approach would be to convert the DDS back into Jpg or Png for the fallback, but setting a blank PNG may deceive some clients into thinking they can skip the DDS and load the fallback image, which in this case would produce a model with white textures.

So I'll try to fix this by not adding the fallback image, but in exchange, it will set the glTF to require the DDS extension, which in turn may make the glTF unloadable by importers not supporting the extension.

But this does not change the fact that the Blender Plugin should be able to import glTFs with fallback images.

[cdj88888]

Thanks for your detailed explanation! I totally understand the design intention of the fallback image based on glTF spec, but I have some practical test results to share:

When I manually modify the generated glTF JSON:

1. Remove the auto-generated fallback PNG image (the second entry in "images" array)
2. Set the texture's "source" to 0 (pointing directly to the DDS image)
3. Remove the MSFT_texture_dds extension (or keep it with source=0)

Blender imports the model with correct textures without any issues—all materials load perfectly. However, if the fallback PNG exists (the current default behavior of SharpGLTF), Blender shows incorrect textures (white/invalid) even though the glTF is spec-compliant.

This creates an awkward situation:

• The spec-compliant output (with fallback image) causes practical usability issues in Blender (a widely used tool)
• The non-compliant (but manually modified) output (without fallback image) works flawlessly in Blender

So I'd like to suggest adding a configurable switch/option in SharpGLTF:

• A boolean flag (e.g., GenerateFallbackImageForDDS) to control whether the fallback PNG is auto-generated
• Default value can keep the current behavior (true) to maintain spec compliance
• Allow developers to set it to false when we want to skip the fallback image (and directly use DDS without index swapping)

This way:

1. Users who need spec-compliant output with fallback images can keep the default setting
2. Users who prioritize compatibility with tools like Blender can disable the fallback image

It would be a win-win solution that preserves the spec compliance while solving practical usability issues in common tools. Thanks for your consideration!

[cdj88888]

I fully get your point: the fallback image is designed for non-Windows users/clients that don’t support DDS formats, while on Windows, tools (like Blender on Windows) can natively and perfectly handle DDS textures without any issues.

This is exactly why a configurable switch would be so valuable:

• For cross-platform use cases (needing compatibility with non-Windows systems), the default fallback image behavior works as intended
• For Windows-only workflows (where DDS is fully supported), we can disable the fallback image to avoid the awkward texture issues in tools like Blender (since the fallback image swaps the source index and breaks texture loading, even though DDS itself works flawlessly)

Manually removing the fallback PNG and pointing the texture source directly to the DDS image makes Blender (Windows version) load textures correctly every time—proving that the DDS format itself is not the problem, but the auto-generated fallback image (and index swap) is the root cause of practical usability issues in Windows-based workflows.

Adding a simple toggle (e.g., EnableDDSFallbackImage) would let developers choose based on their target platform: keep the fallback for cross-platform compatibility, or disable it for Windows-only use cases where DDS is natively supported. This would make SharpGLTF more flexible for different production environments without sacrificing spec compliance.

Thanks again for your attention to this detail!

[vpenades]

as I understand it, you're setting the default image to DDS, without using an extension? that would probably work in many clients, but it's considered a malformed glTF; image formats other than Jpg and Png should be wrapped by its corresponding extension.

On my side, I'm going to remove the automatic addition of a fallback image, mostly because a white dummy image is not really a good replacement of the DDS. Adding a fallback image would umply to add support for converting DDS,Webp and KTX2 to PNG, and I don't want to add image processing services to the library.

But all these issues you're talking about Blender importer, you should also report them to blender, providing examples of these valid glTF models, so they can fix their side.

[ptasev]

For the record, the glTF plugin team for Blender is too strict in regards to this and follow the spec EXACTLY.
KhronosGroup/glTF-Blender-IO#1294

I think what @vpenades is doing makes sense for this library.