Incorrectly scaled UV coordinates

Hi guys,

We have a case of incorrectly scaled UV coordinates when I call SUMeshHelperGetFrontSTQCoords on a particular face in a particular scene ( MODERN - carpet 02.skp (379.3 KB) )
We’ve been using the same code on hundreds of different scenes and haven’t had any problems until this case cropped up.

In this particular scene, the material is assigned to the back side of the face (it’s the only one face in the scene; no instances or groups or any other types of objects are present) and the cow hide texture looks fine in SketchUp:


However, in our glTF converted scene it looks too big by a factor of about 2.5x:

I’ve been doing some digging and the only difference between this face and any other in any of the scenes we have is the fact that SUFaceIsBackMaterialAffine(face, &is_affine) returns is_affine = false. For any other face in any other scene, as far as I can tell, it returns is_affine = true. I’m not sure how this came to be, but I’m actually more interested in how I should be handling such a case. Is there some sort of affine transformation matrix associated with the face and/or texture in question with the translation and/or scale that I need to apply to the UV coordinated I’m getting? If so, how do I access this information? So far, I couldn’t find anything pertinent is the C SDK.

Any help would be appreciated. If the problem I’m describing is not clear from the information and the files I’ve provided, let me know and I will go into more detail.

Thanks,
Lev

More detail (example models & reproducible code snippets) could be logged in the API issue tracker …
Issues · SketchUp/api-issue-tracker · GitHub


What are the model units and what are the glTF units ?

Originally, the scene’s units were mm. I have already tried setting them to inches to no avail (the results don’t change regardless of the chosen units). glTF units are always in meters. We already do the appropriate scaling via a scene level transformation matrix.

In any case, UV coordinates, as far as I know, should have nothing to do with the scene units. If you create any other shape in the same scene and apply the same exact material, than the UV coordinates for that new shape are calculated properly. It’s just that one polygon (represented by a single face) that is giving us troubles (it’s from a customer supplied scene and we don’t know how it was created).

Well @thomthom will be back from vacation in 3 days or so, perhaps next week he can look into this.

Do you have any example code that demonstrate incorrect/unexpected data being pulled from the SketchUp model? (Something that fits into a simple main app? Along with some insight to what expected data is?)

Units should make no difference. SketchUp always uses inches internally. The units set in the model only affect the display layer (input parsing and output formatting).

To confirm if the issue relates to non-affine projections, you can try creating one deliberately to test with.

Btw, in the SketchUp world “scene” refers to a saved view (yes, it is inconsistent to about every other 3d program) and the document as a whole is called a model.

The OP has specific issues with an export in glTF format in an external viewer (of that format.)

He stated …

Since inches map to 25.4 mm (or 2.54 cm) it seemed reasonable to think perhaps there is a conversion error during export to the glTF format.

He said however that …

Perhaps the problem is with the glTF viewer? @lev.faynshteyn have you tried another viewer ?

No, it’s not the problem of glTF (it just happens to the output format of our choice). The UV values I’m getting are the same regardless of what output format I’m converting to or what viewer I’m using.

Thanks eneroth3 for the tip. I will perform more experiments to see if I can get to the bottom of it. If not, then as tt_su suggested, I’ll spend some time to create a minimal code snippet that reproduces the behavior and then maybe some of you guys can point me to a solution.

1 Like

That is strange though… it’s a flat face, and the texture looks to be affine, just scaled to fit the face…
Maybe there is some tolerance issues here.

Note that SketchUp use UVQ coordinates, so if it’s not affine then the Q component won’t be 1.0.
How are you currently handling UVQ coordinates? Does your output target require UV only?

See …
https://extensions.sketchup.com/developers/sketchup_c_api/sketchup/struct_s_u_texture_writer_ref.html

So, perhaps temporarily write out the non-affine texture to disk, and then reassign it to the back face using the converted texture just written ?

I did a small test and, as Thomas mentioned above, it happens because of non-affine textures.

The simple approximation imho is acceptable in many cases.

There is a post about this (post that I used at the beginning) and I’m pretty sure Thomas wrote an even better article about it, but I can’t find this link right now.

2 Likes

I think Andreas explains it better than me on that topic. (I don’t fully understand the math behind this - I just know that with UVQ you need to divide both U and V components with Q to get a “normalized” UV value - though it’s not without some loss of information.)

Thanks guys! Dividing by the z component did it (should’ve thought of it myself :slight_smile: )
Also RaPIT, thank you for the link to the discussion.

1 Like

lev.faynshteyn
Please keep in mind, that it’s only an approximation and in some circumstances you can get distorted textures:

1

2 Likes

This is because SketchUp uses a Q coordinate for perspective while the program you are viewing the building in appears to require affine UV mapping.

1 Like