Assigning textures to a compressed glb doesn't "work" (Babylon)

[RegitGit]

Hello,

firstly, nice work! The difference between original and compressed size is tremendous! I'm facing an issue though. Namely when using the compressed glb in Babylon and I assign a texture to it the mesh is rendered black. I'm hoping you know what this could be causing, like maybe UVs are getting messed up and there is a option to prevent it that I missed testing.

If I used the same glb with textures already assigned and compress it using your software everythings fine. But I don't want to have textures on the mesh from the get go, that's why I'm loading textures additionally and then assign them to the meshes.
This might be a bit Babylon specific and I don't know if you can help me with that, but I gotta ask.

Thank you!

[zeux]

This is somewhat intentional - gltfpack needs to know that the material in question has textures to preserve UV coordinates for the mesh. I'd consider assigning dummy 1x1 textures in the materials for textures that you will need to replace.

[RegitGit]

Hi,

I tried it with the 1x1 texture and now Babylon says the mesh at least still has a UV set. Without this texture it doesn't preserve it. I also tried it with a blank texture of the same size as the original texture, no difference. The problem however is still occuring. It seems to be rooted somewhere else. A difference between the working glb vs the compressed one is when I show the meshes wireframe. I don't know if that might have something to do with it though:
Original

Compressed (shows Wireframe in the background)

The mesh in question is the robotic arm thingie with Kuka written on it (when the texture works ;D)

[RegitGit]

New finding: it probably still is an UV issue. Although the mesh now still has a UV set unlike before, the UVs seem to be off.
Original looks like this:

Compressed:

I also tested with the original texture set. Although it is displayed correctly and it says it has a UV set, when I try to look at the UVs through debug none are displayed.

[zeux]

I'm not exactly sure how Babylon works, but when you replace textures and/or materials on compressed assets, it's important to maintain texture offset / scale settings. In Three.js for example these are stored on a texture object, so they need to be copied from the original texture during replacement.

[zeux]

Looks like Babylon might be the same and stores these in uOffset / uScale / vOffset / vScale. So you need to copy these from the source texture you're replacing.

[RegitGit]

It works! I can update the dummy textures url to my wanted one preserving the offset and scale and it works as intended! I could probably also create a new texture and copy the values as you mentioned, because these were indeed the culprits!

Thank you very much for your help! 😄