Multiple UV Sets Getting Lost With Draco Compression

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?

cube-draco.zip (3.4 KB)

Adding @bghgary

1 Like

I wasn’t aware Draco had a limit in dealing with multiple UVs. Maybe you can file an issue on Draco and see what the experts say?

Thanks, that’s my next step but I assumed we would not get a prompt response there :slight_smile:

You can maybe try Latest glTF topics - Khronos Forums and see if someone from the Khronos group knows.

1 Like

@bghgary

We’re now thinking might actually be a Babylon bug. In digging into this example file, I see the following:

 "attributes" : {
                        "POSITION" : 0,
                        "NORMAL" : 1,
                        "TEXCOORD_0" : 2,
                        "TEXCOORD_1" : 3,
                        "TEXCOORD_2" : 4,
                        "TEXCOORD_3" : 5
                    },
                    "extensions" : {
                        "KHR_draco_mesh_compression" : {
                            "bufferView" : 0,
                            "attributes" : {
                                "POSITION" : 0,
                                "NORMAL" : 1,
                                "TEXCOORD_0" : 2,
                                "TEXCOORD_1" : 3,
                                "TEXCOORD_2" : 4,
                                "TEXCOORD_3" : 5
                            }
                        }
                    },

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.

1 Like

We noticed it worked in the sandbox so I just upgraded to the latest Alpha version and the issue is resolved there. We can work with this!

EDIT: We didn’t try with the Draco compressed version so thank you!

Add missing UVs to glTF draco loader extension by bghgary · Pull Request #10538 · BabylonJS/Babylon.js (github.com)

4 Likes

Gosh, that took forever! :wink:

3 Likes

Thank you!

3 Likes

@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?

@bghgary will be able to help with that one :slight_smile: he is the gltf/draco king,.

1 Like

@Alex_B would you happen to have a model to repro ???

I’m trying to see if I can get that for you…

1 Like

Messaged you…

perfect, fix should be in shortly Fix UV index > 1 by sebavan · Pull Request #10550 · BabylonJS/Babylon.js · GitHub

1 Like

Actually scratch that, working on a real fix…

@sebavan @bghgary @Alex_B

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

@jcharnley Can you add some context for your issue? Are you using Draco compression in a glTF file?