incorrect import of the attached glTF file

[vvoovv]

Describe the bug

Blender's glTF importer can't import the attached glTF file.

The online glTF viewer https://sandbox.babylonjs.com does import the file correctly.

The attached glTF file is a part of Google 3D Tiles.

To Reproduce
Import the attached glTF file and see the odd result.

A note. The imported Blender object will be located very far away from the origin:

Expected behavior

The online glTF viewer https://sandbox.babylonjs.com does import the attached glTF file correctly.

.blend file/ .gltf (mandatory)
problem_tile.zip

Version

• OS: Windows 11 Home
• Blender Version: 4.0.1

[julienduroure]

Hello,
My first thought is that it may be a Draco decoding issue

[julienduroure]

I confirm that the bug comes from Draco decompression.
Using

gltf-transform draco /tmp/problem_tile.glb /tmp/problem_tile2.glb

And the new file (still Draco compressed) imports correcly

[vvoovv]

What would be required to fix this problem?

[julienduroure]

I need to check if we can update Blender Draco lib to latest version, and check if it solves the issue of not

[vvoovv]

Hi @julienduroure

Did the update of the Draco library help to solve the problem?

[julienduroure]

Helllo,

I didn't check it yet

[vvoovv]

Hi @julienduroure

Any chance of fixing in Blender 4.3?

Thank you.

[julienduroure]

Tested on local with Draco 1.5.7, problem is still there :(

[Djdraco93]

Now unfortunately another person needs a working import of compressed .glb models (edgebreaker and sequential ways). Same problem as above, the geometry does not match what it should contain, but in the browser the browsers work correctly. One is left hoping that the next version of the library will fix this.

[vvoovv]

@julienduroure

Do you think it makes sense to report the problem to the developers of Draco?

[Djdraco93]

@julienduroure

Can you or someone push the topic further. I need importing with draco compression madly for my work, without it I can't check files from the client as the requirement is .glb compression on the client's side

[julienduroure]

So ... I have an answer!

I was looking into Draco, and the answer is probably somewhere else :)
Seems the indices accessor of the primitive is set a component type of 5121 ( UnsignedByte ), so with a max index of 255.

But ... the max indice is 314, as we have more than 255 vertices.

The good news is that I identified the root cause of the issue \o/
The bad news: it seems that the problem comes from the file, where you could not trust the indice component type. We will have to find another way to initialize the array type (based on decoded mesh number of points?)

Thanks for your patience waiting a fix :)

[julienduroure]

diff --git a/addons/io_scene_gltf2/blender/imp/draco_compression_extension.py b/addons/io_scene_gltf2/blender/imp/draco_compression_extension.py
index 94a0e8f3..d06c388b 100644
--- a/addons/io_scene_gltf2/blender/imp/draco_compression_extension.py
+++ b/addons/io_scene_gltf2/blender/imp/draco_compression_extension.py
@@ -15,6 +15,7 @@
 from ctypes import *
 
 from ...io.com.gltf2_io import BufferView
+from ...io.com.constants import ComponentType
 from ...io.imp.gltf2_io_binary import BinaryData
 from ...io.com.draco import dll_path
 
@@ -88,6 +89,16 @@ def decode_primitive(gltf, prim):
         gltf.log.warning(
             'Draco Decoder: Index count of accessor and decoded index count does not match. Updating accessor.')
         index_accessor.count = dll.decoderGetIndexCount(decoder)
+
+    # Recalculate component type based on vertex count.
+    # Because it seems the prim.indices accessor componentType is not always set correctly.
+    if dll.decoderGetVertexCount(decoder) < 255:
+        index_accessor.component_type = ComponentType.UnsignedByte
+    elif dll.decoderGetVertexCount(decoder) < 65535:
+        index_accessor.component_type = ComponentType.UnsignedShort
+    else:
+        index_accessor.component_type = ComponentType.UnsignedInt
+
     if not dll.decoderReadIndices(decoder, index_accessor.component_type):
         gltf.log.error('Draco Decoder: Unable to decode indices. Skipping primitive {}.'.format(name))
         return

This patch seems to fix the issue. But we have to be very careful, and this needs more test / non regression tests / checks

[vvoovv]

This patch seems to fix the issue. But we have to be very careful, and this needs more test / non regression tests / checks

Great news! I'll test the patch.

[julienduroure]

@donmccurdy You have maybe better understanding of this Draco issue.

the prim.indices of the file have ComponentType 5121, but have more than 255 indices.
Should we ignore this, and always recalculate the ComponentType based on DracoMesh data?

Or is this a bug in this file?
In that case, do you know who I can contact at google to discuss about that?

[donmccurdy]

Copying the JSON header out of the GLB...

problem_tile.glb

{
  "asset":{
    "version":"2.0",
    "generator":"draco_decoder",
    "copyright":"Google"
  },
  "scenes":[
    {
      "nodes":[
        0
      ]
    }
  ],
  "scene":0,
  "nodes":[
    {
      "mesh":0,
      "translation":[
        851227.05319905072,
        4379922.724366514,
        4543783.8765163999
      ]
    }
  ],
  "meshes":[
    {
      "primitives":[
        {
          "attributes":{
            "POSITION":1,
            "TEXCOORD_0":2
          },
          "indices":0,
          "mode":4,
          "material":0,
          "extensions":{
            "KHR_draco_mesh_compression":{
              "bufferView":0,
              "attributes":{
                "POSITION":0,
                "TEXCOORD_0":1
              }
            }
          }
        }
      ]
    }
  ],
  "accessors":[
    {
      "componentType":5121,
      "count":513,
      "type":"SCALAR"
    },
    {
      "componentType":5126,
      "count":314,
      "max":[
        53.494731903076172,
        37.779499053955078,
        -9.2874250411987305
      ],
      "min":[
        -69.238937377929688,
        -95.882095336914062,
        -92.276382446289062
      ],
      "type":"VEC3"
    },
    {
      "componentType":5126,
      "count":314,
      "type":"VEC2"
    }
  ],
  "materials":[
    {
      "pbrMetallicRoughness":{
        "baseColorTexture":{
          "index":0,
          "texCoord":0
        },
        "baseColorFactor":[
          1,
          1,
          1,
          1
        ],
        "metallicFactor":1,
        "roughnessFactor":1
      },
      "emissiveFactor":[
        0,
        0,
        0
      ],
      "alphaMode":"OPAQUE",
      "extensions":{
        "KHR_materials_unlit":{
          
        }
      }
    }
  ],
  "textures":[
    {
      "source":0,
      "sampler":0
    }
  ],
  "samplers":[
    {
      "wrapS":33071,
      "wrapT":33071
    }
  ],
  "images":[
    {
      "bufferView":1,
      "mimeType":"image/jpeg"
    }
  ],
  "bufferViews":[
    {
      "buffer":0,
      "byteOffset":0,
      "byteLength":1108
    },
    {
      "buffer":0,
      "byteOffset":1108,
      "byteLength":3108
    }
  ],
  "buffers":[
    {
      "byteLength":4216
    }
  ],
  "extensionsRequired":[
    "KHR_draco_mesh_compression",
    "KHR_materials_unlit"
  ],
  "extensionsUsed":[
    "KHR_draco_mesh_compression",
    "KHR_materials_unlit"
  ]
}

Indeed, the file has too many vertices for the uint8 indices being used. This is certainly a bug in the software producing the file, it might be good to report the issue at https://github.com/google/draco, but I'm not sure who would be involved in producing 3D Tiles specifically.

As a workaround, detecting this problem in the import process and using uint16 instead of uint8 might work, assuming the encoder has stored the larger indices in the compressed bitstream.

Guessing at what the encoder might have done wrong ... I will note that Draco compression can increase the vertex count slightly, as part of the compression process. If a mesh is near the vertex count limit for uint8 indices, it might be necessary to change the index type if the vertex count increases after compression. I guess the Draco encoder is question has failed to do so. I handle this in glTF Transform with a special case for UNSIGNED_SHORT though it's possible that I need a special case for UNSIGNED_BYTE too. But I don't think glTF Transform was used to produce this file, so that's just an aside.

Related comments and issues:

• Expectations for mesh indices: optional? auto-generated if not set? google/draco#720 (comment)
• Encoding merges vertices and breaks blendshapes in the process google/draco#929 (comment)
• Verify vertex count when Draco-compressing meshes with morph targets donmccurdy/glTF-Transform#355