Loading GLB not possible after Xeokit version upgrade

[magmerionKwa]

Describe the bug
In our project we are using the GLTFLoaderPlugin to load GLB inside the viewer. The loader whas working fine until we upgraded Xeokit to the lastest version (2.6.65 -> 2.6.90). After the upgrade we started having errors when loading GLB with the GLTFLoaderPlugin. Here the following error : "Error: assert failed: gltf".

Here a quick example of how we load the GLB :

const glbLoader = new GLTFLoaderPlugin(viewer);
try {
    await glbLoader.load({
    id: 'myModel',
    src: './models/GLB_KO.glb',
    edges: false,
    globalizeObjectIds: true,
    colorTextureEnabled: true,
    backfaces: false,
}

To Reproduce
Steps to reproduce the behavior:

1. Load a viewer
2. Init the GLTFLoaderPlugin
3. Load a GLB
4. KO -> when displaying the GLB we have an error in the console

Expected behavior
We should be able to display the GLB in the viewer

Screenshots

Additional context
Here an exemple of a failing GLB from our side :

GLB_KO.zip

[tgranie]

Hello @xeolabs,
Looks like a regression.
Do you have any clue on that issue ?
Thanks for your help

[tgranie]

In complement, the GLB attached has no error thanks to https://gltf.report/

[tgranie]

@xeolabs Any news ? It is blocking as we could not upgrade to xeokit v12.
Thanks for you help

[xeolabs]

This looks like a bug in loaders.gl, which we use internally within xeokit to parse glTF.

In xeokit 2.6.90, we upgraded loaders.gl from 3.2.6 to 4.3.4.

Within this new loaders.gl, it seems to be throwing an exception due to an assertion failing. The assertion seems to find an inconsistency within the intermediate data structure that loaders.gl is parsing from the glTF.

We will need to investigate further and see if this is something we can patch on our end, or maybe fix in loaders.gl.

Is this issue affecting all GLBs you're trying to load?

Also, please attach any other GLBs you can that cause this issue, would help to triangulate on it.

Thanks

[xeolabs]

Also, could you tell us what created the GLB files? Thanks

[drashevski]

fyi, just found this report from https://gltf-viewer.donmccurdy.com/ on the sample model about some used extensions:

[tgranie]

Hello @xeolabs and @drashevski for your investiguations.
To answer your questions :

1. No it does not affect all our GLB (Which is even harder to see and understand the issue)
2. We will send you others GLBs failing
3. We have two standard process :

• Using IfcConvert from IfcOpenShell
• Then if needed texture them in blender
• Then compress them using gltf-transform (We use Webp as image format)

[MichalDybizbanskiCreoox]

Hi @tgranie and @xeolabs, here is a reason of why this issue occurs.

The attached example file inside GLB_KO.zip atchive, relies on KHR_texture_transform, and at the same time combines POSITION and TEXCOORD_0 accessors in a single bufferView [2].

  ...
  "accessors": [
    {
      "type": "VEC3",
      "componentType": 5126,
      "count": 1377,
      ...
      "bufferView": 2,
      "byteOffset": 0
    },
    {
      "type": "VEC3",
      "componentType": 5126,
      "count": 1377,
      "bufferView": 2,
      "byteOffset": 12
    },
    {
      "type": "VEC2",
      "componentType": 5126,
      "count": 1377,
      "bufferView": 2,
      "byteOffset": 24
    },
  ...

While handling the KHR_texture_transform, the loaders.gl library modifies in place the bufferView [2] that's attached to the TEXCOORD_0 attribute (https://github.com/visgl/loaders.gl/blob/d74df445180408fd772567ca6a6bbb8d42aa50be/modules/gltf/src/lib/extensions/KHR_texture_transform.ts#L231-L233).
But doing so it breaks the same date structure for the POSITION attribute, by not taking into account, that the bufferView might be shared by multiple attributes.

This feature was implemented by visgl/loaders.gl#2175, and the last version before it (that should not break, but on the other hand will probably not handle KHR_texture_transform) seems to be v3.2.

[tgranie]

@MichalDybizbanskiCreoox Thanks for your very detailed explanation !
What do you think should be the next steps ?

[MichalDybizbanskiCreoox]

@MichalDybizbanskiCreoox Thanks for your very detailed explanation ! What do you think should be the next steps ?

We've logged an error on the loaders.gl issue tracker at visgl/loaders.gl#3225.
For the time being we'd rather not revert the dependency version, and wait for the response there.

It's likely that the "compress them using gltf-transform" step introduces the gltf structure, that loaders.gl fails to deal with.
Could you try skipping that step and trying to load the file?

[magmerionKwa]

Hello @MichalDybizbanskiCreoox,

Is there a way to skip that step for the loader configuration ? Or do we need to comment a part of the code inside the Xeokit library ?

[MichalDybizbanskiCreoox]

Hi @magmerionKwa,
I meant the gltf-transform step used by the "standard process" described by @tgranie in one of previous comments at #1985 (comment)
This step is not controlled by the xeokit SDK.

[tgranie]

Hi @MichalDybizbanskiCreoox,
Thanks for the tikect towards loaders.gl
Unfortunately, we have already used and still using gltf-transform on all the objects we load in order to compress them a lot (webp, draco...) and make their usage on a web browser possible.