Model viewer uses wrong UV coordinates

[MathisEngels]

Description

The model viewer uses wrong UV causing glitched texture. I was testing some asset that I did in blender. Exported without any materials but with UV map, and the baked texture saved as a png. When importing the model and adding the texture through the UI, the texture placement is false. See the example below: From https://modelviewer.dev/editor/ :

From my code using ThreeJS(r3f) :

The ThreeJS code :

const { nodes, materials, animations } = useGLTF('/test1-c.glb')
const texture = useTexture('/textures/test1.png');
texture.flipY = false;
texture.colorSpace = SRGBColorSpace;
let textureMaterial = useMemo(() => new MeshStandardMaterial({
     map: texture,
 }), []);

 return (
     <group dispose={null}>
         <group name="Scene">
             <mesh name="Table001" geometry={nodes.Table001.geometry} material={textureMaterial} position={[-61.321, 0, -10.449]} />
         </group>
     </group>
 )

The files: test1.zip

Version

• model-viewer: v3.3.0

Browser Affected

• [X] Chrome, version: 119.0.6045.200
• [X] Edge, version: 120.0.2210.61
• [ ] Firefox (Couldn't test)
• [ ] IE (Couldn't test)
• [ ] Safari (Couldn't test)

OS

• [ ] Android (Couldn't test)
• [ ] iOS (Couldn't test)
• [ ] Linux (Couldn't test)
• [ ] MacOS (Couldn't test)
• [X] Windows

AR

• [ ] WebXR
• [ ] SceneViewer
• [ ] QuickLook

[elalish]

Interesting - can you repro in MV itself or just the editor? I'm hoping this is just an editor bug.

[Kite54]

Hi… here the same… i noticed, that the editor mirrors the texture. Two week ago everything worked fine. I also have problems to assign other (fixed) textures manually.

[elalish]

Sounds like it may have been a regression in three.js. I'm going to need a lot of detail to hunt down the problem. Can you share a Glitch with your attempt at assigning textures manually that didn't work? And can you share some detailed repro steps for the mirrored texture in the editor?

[Kite54]

Hi elalish,

i made a screenshot, so I hope you can see the problem. On the left side you can see the reference gib Project (made from Substance) with the selected Material Chanel (its mirrored but looks good). On the right side you can see the original Texture png (in the model viewer it is mirrored).

If I use the same 3d model (same uv) but animated without textures – if then I want to reassign the textures , model viewer mirrored the textures while uploading it. But in that case the texture has to be in the right position.

It´s a bit weired… Maybe you have a better workflow for me… I want to visualize some step data. So first i use cinema4d to build a nice uv map… the I use Substance Painter to Texture the glb model (until now, everything is fine) then I use c4d again to animate the gib file because animation is not supported by Substance. Then I reassign the Textures from Substance to the animated glb file from cinema4d in the model viewer. Two weeks ago it worked – no problem at all.

First I thought it has something to do with the export settings in cinema4d "flip z"… but then I recognized that model viewer mirrored it. So I tried to mirror it in Photoshop first that it will be in the right position in the model viewer… but in that case it is not possible for me to assign the file at all…

[Kite54]

Additionally I testet it in Babylon Sandbox… everything worked fine. Then I put the glb file from Babylon into Modelviewer… it looks right but when I Change the Texture… the model viewer mirrored the changed Texture again… so guess it has to do with the upload…

[elalish]

Can you do this with something simple like a textured quad? Link the file here, and then make repro steps (1...2...3...) for MV and bablyon and show screenshots of the difference? I have no ability to reproduce what you're talking about yet.

[Kite54]

Hi elalish… here are the files… I hope you understand what I mean and can repro the steps…

Best Daniel

squad.zip

[elalish]

Thank you, I have a repro. I fact it repros on our example, simply by changing a texture and then setting it back. As best I can tell this seems to be some kind of three.js regression, especially since manually changing the value of texture.flipY has no effect now. FYI @mrdoob.

[elalish]

Okay, I found the problem - hasn't gotten into a release yet, so that's good. It's also not a three.js regression. The problem is I tried to use @daniele-pelagatti's HDR jpeg loader for all our images, but it uses ImageBitmap internally, so texture.flipY has no effect. It's pushing upside-down images because it sets FlipY to true, while I set it to false. Would be great to expose that setting in the decoder, or better yet to get HDR support built into core three.js. Meanwhile, I need to use two different image loaders.