Ignored texture scaling when Append a GLB (Potential Bug ?)

Questions
1

Hi everyone !

I haven’t post on the forum since it moved from html5gamedevs ! However, still using BJS daily, so thanks A LOT to all contributors :clap: :muscle:!

I have an issue that I don’t understand when loading a .GLB which contains materials with scaled textures on my scene.
I used to work with BJS 4.0.0 ans it worked perfectly. This problem happened since migration to 4.2.0 (or 5.0.0)

Unfortunately, I am not able to reproduce it on a PG, so I will try to explain the best as I can.

On a minimalist page like the template one, trying to load a .GLB

uScale and vScale attributes of the albedo texture are ignored, which leads to the following result :

Capture d’écran 2021-02-24 à 19.14.39
Capture d’écran 2021-02-24 à 19.14.392056×1130 116 KB

(FYI, It is the same result as in a threeJS viewer, which makes me believe maybe something has changed in the GLTF format about textures).

The weirdest part is, that when I add the inspector code in the page by adding
<script src="https://preview.babylonjs.com/inspector/babylon.inspector.bundle.js"></script>
to my page, the texture scaling is ok.

Capture d’écran 2021-02-24 à 19.14.10
Capture d’écran 2021-02-24 à 19.14.102272×1632 349 KB

Inspector is loaded in both PG and sandbox, which explains why I did not reproduce this behavior using them.

Should I change something at my GLB Export ? Is it a bug ? Any answer would be really appreciated !

Thanks again !

2

pinging @bghgary

3

That’s interesting. Can you attach the glTF/GLB you are showing in your screenshots?

4

Hi @bghgary !

Here is the file
Textures urls may reference an local/offline servor.

Thank you very much !

If it may help, it seems that the problem appeared with BJS 4.1

5

Can you provide those textures?

6

I uploaded another .GLB with absolute textures urls to the online server.
You can find it : HERE
Thanks for the help :slight_smile:

7

This file looks the same as before?

  "images": [
    {
      "uri": "glb3D_image0..png"
    },
    {
      "uri": "glb3D_image1..jpg"
    }
  ],

Maybe just send me the urls. I can modify the glTF to point to them :slight_smile:

8

Hi @bghgary!

Ow, this file loaded in the sandbox seems to get textures from online server :pensive:

Anyway, there are only 2 albedo textures :

  • the one with the scaling problem can be found HERE
  • the one for the terrace : HERE

Thanks again !

1 Like
9

Ah, sorry, this is because my tool to unpack a glb doesn’t handle absolute urls. I will have to fix that. :slight_smile:

I’ll investigate and let you know.

1 Like
10

I figured out the problem. This GLB is using KHR_texture_transform but it doesn’t specify the KHR_texture_transform in extensionsUsed in the glTF. By default, the glTF loader disables the KHR_texture_transform loader extension for processing this glTF extension unless explicitly enabled. The reason why adding the inspector “fixes” it is because the inspector explicitly enables all of the glTF loader extensions right now, which is basically a bug. That’s something I’ve been wanting to fix but haven’t had the time. If you add KHR_texture_transform to extensionsUsed, then it will start behaving the way you expect.

1 Like
11

Oh, one more thing. I don’t know how this GLB is created, but make sure to run the glTF validator on assets and clear all of the errors to ensure a valid asset. This one, for example, produces the following errors that is the main cause of the issue:

      {
        "code": "UNDECLARED_EXTENSION",
        "message": "Extension is not declared in extensionsUsed.",
        "severity": 0,
        "pointer": "/materials/1/pbrMetallicRoughness/baseColorTexture/extensions/KHR_texture_transform"
      },
      {
        "code": "UNDECLARED_EXTENSION",
        "message": "Extension is not declared in extensionsUsed.",
        "severity": 0,
        "pointer": "/materials/2/pbrMetallicRoughness/baseColorTexture/extensions/KHR_texture_transform"
      },

Loading this in the Babylon.js sandbox also will run the glTF validator.

image

12

Oh ! It makes sense now ! Perfectly clear, thank you very much !

I presume that before BJS 4.1, KHR_texture_transform was enabled by default in the loader, which explains why it used to work !

For the story, the .GLB is created server-side from a custom data set, injected to the python library trimesh which allows the export in multiple formats.

Thanks again for your help and time, problem solved !

1 Like
13

I’m not sure if it was 4.1, but at some point, I fixed the loader to only enable extensions when it is specified in extensionsUsed, as that is per spec.