api-issue-tracker
api-issue-tracker copied to clipboard
SketchUp
Wrong Inherited UVs
- All SketchUp versions so far
- All Platforms
A face painted with a default material, which has a texture applied to a parent object gives wrong UV coordinates using mesh.uv_at(), C API or C++ API. The face is using "deleted material technique" shown in the animated gif.
Originally reported three years ago here: https://forums.sketchup.com/t/bug-mesh-uv-at-wrong-uv-coordinates/41186
The skp file (zip) contains the Ruby snippet. WrongUVsTest.zip The 0,0 point in the bitmap should be positioned in the origin for clarity, but anyway - the snippet shows the wrong UVs for the specified vertices.
This test model has been created with Fredo's ThruPaint.
Front and back UVs are different, but there is no way to read front correctly.
WrongUVsTest2.zip
Yes, good.
Sketchup really ought to support control of face UV:s independently of material used.
When applying a default material, or any non-textured material including plain-colour materials, Sketchup seems to unceremoniously kill off face UV:s, contrary to justified user expectations, needlessly breaking them, and destroying important object properties.
UV:s are one thing. Materials are another. Please honor this basic distinction.
This calls for a change both in the API and in Sketchup itself.
Sketchup really ought to support control of face UV:s independently of material used.
I think this is the root of this issue. A feature we need to formally support. Right now the "deleted material technique" is an implementation detail, arguable a bug in the API not behaving consistent with the UI. But I agree it would be useful to control UVs independent of having a texture applied.
This bug prevents any rendering plugin (like our own Enscape) to duplicate what the SketchUp viewport shows. I doubt there is any way to get to the real UVs of faces without material, is there?
Please fix this. We have customers complaining and there is nothing we can do about it. E.g. https://forum.enscape3d.com/index.php?thread/6106-enscape-2-7-issue-with-textured-groups-components/ but we also had this several times before.
Yes.
May we please finally get Sketchup and its API to support persistent face UV:s – independent of any materials and the context in which they are applied?
Sketchup encourages users differentiating material application by context. Thus, best practice is using default material on raw faces in order to enable container instance materials visually carry over across container hiearchies. For end users, this is a simple and powerful workflow. It makes sense. This must be kept.
However – Sketchup lacks persistent per-face UV support.
This lack affects even casual users. Users become confused and end up needleesly destroying their UV:s, and deleting and reassigning materials, over and over again.
Many extensions, including all third-party renderers, like Enscape and V-Ray, are struggling with this. Typically, they end up either destroying the user's UV:s or destroying material application contexts or destroying both. For instance, when the user changes object UV:s in V-Ray, V-Ray forces the silent copying of the group material down to individual raw faces and rewrites their properties. This is slow, destructive and conceptually wrong.
All this can be fixed.
Add support for persistent face UV:s. In at least one UV channel.
Many developers, us included, would put these long-needed persistent face UV:s to immediate use in upcoming public extensions. To the benefit of end users.
– What is the status on persistent face UV:s? Please let us know.
@SimonWeinbergerEnscape that model in the referred forum thread, is that also a case where the face has no material, but still have texture coordinates after previously being textured?
@SimonWeinbergerEnscape that model in the referred forum thread, is that also a case where the face has no material, but still have texture coordinates after previously being textured?
It's especially is the case where the face has no material. That's the most important use case:
- properly edit the UVs using some texture
- remove the material from the face
- create component
- attach different materials via component
To summarize: Face has textured material: API reports correct UVs Face has material without texture or no material at all: API reports bogus UVs
The UV mapping of a face is conceptually and should be functionally independent of its current material, also when its material is nil.
Sketchup's API contract with extensions ought to honor the exact same UVs as applied by Sketchup itself. And as shown in the viewport to end users.
Would you please fix this API bug?