Three.js to USD(A) conversion... almost - UV texture problem

Questions
1

Hi. I am converting a GLB file I imported into a USD(A) file for loading into Omniverse. I am experiencing a problem, and I thought I would ask in case anyone had seen it before.

Here is the back of a character in three.js - renders fine.
image

There is actually a seam down the back of the character. I just carefully lined up the images so they connect carefully. Here is the PNG file for the texture.

image
image1920×1920 94.7 KB

Here is what it looks like in Omniverse.

image
image616×586 70.5 KB

What I think is happening is something funny with the UV mapping near the edge. There is a gap down the middle, but I think it is related to stretching near the edge. The transparent part on the image is getting dragged up to the top (or similar).

Now, there are settings relating to clipping or wrapping UV (ST?) coordinates (wrapS and wrapT of texture for example). But I am wondering if a value of ‘1’ or higher for ST mapping is causing the confusion. Maybe it is wrapping in three.js, but I don’t have the setting right in USD, so its stretching.

My question - has anyone seen this stretching effect along the edge of the seam? Any suggestions on how to treat values out of range (e.g. truncate them, wrap them, etc). Thanks!

2

That sorta looks to me like something in the export is clamping/wrapping the UVs to 0 to 1 range, in software. The line you’re seeing is actually the whole (flipped) texture being flipped/squished into that vertical strip of triangles.

If you are writing this exporter yourself… Try to avoid modifying the UVs in any way Except for perhaps *-1 scaling on Y if needed, otherwise they will just be broken.

3

UVs can be any value, even though conceptually they are in a 0 to 1 range, in practice… they can be anything, and truncating them or wrapping them in code will not be the same as letting the texturing hardware do the wrapping/truncation.

4

D’oh! I worked out what the problem was (my fault). I was using vertex (not face varying) for UV mappings, then deduping points ignoring the UV map. So along any seam it would think its a shared vertex, but then use the same UV map coordinate for faces on the left or right f the seam. This mean faces to one side of the seam got the wrong UV map coordinate. Moving to faceVarying solved it - having a UV map per face a vertex was in instead of only per vertex.

Thanks everyone for the suggestions! Appreciated! Learning as I go!

2 Likes