Allow for arbitrary UV coordinates

[jiminy-billy-bob]

For now, if multiple vertices of a single face have identical UV coordinates, SketchUp discards them as invalid. We have observed this behavior both via the C API and the Ruby API. Please allow for these arbitrary UV coordinates.

Use-case: We have a user who uses this technique (assigning the same UV coords to all the vertices of a face), to sample a unique color in a bitmap to cover the whole face. I believe this is used for video games, to save disk space by using less bitmap files.

[thomthom]

Can you provide an example file? I think I need to bring this beyond just Extensibility. For that I need a bit more background and details to forward the use-case.

[jiminy-billy-bob]

Here you go SM_Bld_Apartment_01.zip

[thomthom]

So the API let you set such coordinates? But model repair resets?

Also, can you expand a bit more about the use case?

I believe this is used for video games, to save disk space by using less bitmap files.

It would help it to know more specifically why and how it's used.

[jiminy-billy-bob]

It seems the C API fails silently. The resulting SketchUp file has wrong coordinates AND it asks for repair : The front or back texture coordinates for CFaceTextureCoords (xxx) is not valid - fixed The Ruby API returns ArgumentError: Could not compute valid matrix from points

I'll ask Ted to explain the use case. Here is some context : https://forums.lindale.io/t/uv-coordinates-lost-in-skp-file/1493

[jiminy-billy-bob]

Note that this is not necessarily very high priority from our point of view. There is an easy workaround, something like this:

// In the case when vertices of a same face share equal UV coordinates,
// we slightly nudge their values so that they differ and SketchUp does not complain. 
//
// For instance, this is necessary for "paletted" UVs, when several vertices are
// positionned exactly at the same texture coordinates since they use the same plain color.

if (i - 1 >= 0 && SUmaterialInput.uv_coords[i].x == SUmaterialInput.uv_coords[i - 1].x) {
    SUmaterialInput.uv_coords[i].x += 0.00001;
}
if (i - 2 >= 0 && SUmaterialInput.uv_coords[i].y == SUmaterialInput.uv_coords[i - 2].y) {
    SUmaterialInput.uv_coords[i].y += 0.00001;
}

[TedVoxl]

Really, this is for interoperability between Sketchup and other modeling applications like Max, Maya, Modo, rhino etc. It is more important than ever that all the applications communicate with eachothers ecosystem because so many artists work between platforms. Any time I pull something into SketchUp, I inherently have to do a ton of gymnastics to make the model work. I would like to not have to do that with each new model I pull in.

[thomthom]

@TedVoxl - can you outline the workflow and use cases in more detail?

[TedVoxl]

I have low poly game assets that I need to import into SketchUp for visualization reasons. Because SketchUp does not support the workflow coming from other applications @jiminy-billy-bob outlined above, I end up with models that are rendered completely useless because SketchUp won't read the UVs correctly, leaving me to have to go to another application to complete the work at hand or for other applications to have to use workarounds to allow import of models with correctly UV'd geometry.

I may not be able to further answer the workflow use case for these models other than to say, I'd like models to just work when I bring them into SketchUp.

[thomthom]

Do you have some sample models to share? (You can send them to me directly if you prefer not to share publicly.)

We need something to use for understanding the data and being able to verify any potential solution.

[TedVoxl]

@jiminy-billy-bob provided the model above: https://github.com/SketchUp/api-issue-tracker/issues/186#issuecomment-453208208

[TedVoxl]

SM_Bld_Apartment_01.zip Here are the SketchUp, texture and obj files

[DanRathbun]

@thomthom This is not mentioned at all in the API release notes.

[thomthom]

achk. something went wrong with the bot trying to close the issues. I ended up trying to manually fix that via a filter. That filter was not correct. 🤦‍♂️

[DanRathbun]

There is a mention in the C API Release Notes:

• Changed SUEntitiesFill such that it will apply a textured material to faces even if the SUMaterialInput or SUMaterialPositionInput have no UV coordinates. In this case the material will be applied similar to how SUFaceSetFrontMaterial / SUFaceSetBackMaterial behaves.

This entry is mistakenly separated into two bullet items.

But again, the release notes do not mention if there was an improvement in this area for the Ruby API.