etc1s+draco model renders black but textures load

[hybridherbst]

Describe the bug
This is a weird one: while testing mrdoob/three.js#23321 I noticed that the etc1s+draco version of Coffeemat didn't load properly in gltf.report. Some textures display black, while in the texture view they're available:

To Reproduce
Steps to reproduce the behavior:

1. Go to gltf.report
2. Download the files referenced in the issue above
3. Drop the etc1s+draco file into gltf.report
4. Note black textures

Screenshots

Desktop (please complete the following information):

• OS: [Windows]
• Browser [Chrome]
• Version [107]

Additional context

I remember having this exact model work fine in gltf.report before

[donmccurdy]

Thanks! I'll look into this.

I remember having this exact model work fine in gltf.report before

I recently replaced THREE.GLTFLoader with @gltf-transform/view in this viewer, to support lossless roundtrip import/export. That may be the cause of the regression here.

[donmccurdy]

Found the fix, but not deployed quite yet. Because three.js doesn't support arbitrary UV assignments, THREE.GLTFLoader backfills TEXCOORD_1 with TEXCOORD_0 if necessary. Had missed that in @gltf-transform/view.

• Add fallback for TEXCOORD_1. glTF-Transform-View#47

[hybridherbst]

Ah, that old three-is-not-actually-glTF-compliant issue comes back again... really hope that Node materials are there Soon™️, if you have any pointers to what could be done to accelerate that, happy to align!

[donmccurdy]

Fixed on latest gltf.report push!

On THREE.NodeMaterial, I'm not sure — haven't been tracking that work closely enough lately. I suspect its plenty mature enough to be useful, but it remains mostly undocumented. Whether that's because it's still likely to change, or no one has documented it,... I'm not sure. In any case it does seem like some visibility into that roadmap would be reasonable at this point.