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:
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.
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).
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.
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.
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?
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.
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.)
)