We are seeing strange behavior when dealing with Draco compressed GLTF files that use multiple UV sets. When compressing with Draco, any UV sets beyond the first two are lost. Here is a very simple example using a cube. This behavior can be reproduced using Modo, Blender, or GLTF Pipeline to do the compression.
I realize this isn’t really a Babylon issue but I’m wondering if anyone has encountered this problem before and found a solution?
However, if we drop that into the sandbox, it does not show up with all the UV sets. It only shows the first two. This appears to be happening on any GLTF with Draco compression. The uncompressed version works as expected.
We’ve just recently added support for more than 2 UV sets to the glTF loader. I don’t see any code in the Draco code that prevents this from happening. Can you set up a repro and test it in multiple viewers? That should rule out some things.
EDIT: Never mind. I found the code that is not loading the UVs for Draco. I will have a PR with the fix shortly.
@bghgary
I think I spoke too soon. I just pulled down the latest alpha (5.0.0-alpha.28) and I’m getting this error when using three UV maps:
BJS - [09:48:40]: Error: Varyings with the same name but different type, or statically used varyings in fragment shader are not declared in vertex shader: vBumpUV
Is there a change that also has to propagate to the the shader code?
Hi, would this be the best topic to ask how I can manually change the mesh primitives attributes TEXCOORD values, well not change the value as such. We now have mulitple TEXCOORDs in the array and I wanted to see if I can assign TEXCOORD_1 instead of TEXCOORD_0 to meshes