Imprecise barycentric coordinates

[rafern]

Barycentric coordinates in a MeshRelation object get warped after doing a boolean operation. I made a project that restores vertex attributes like UVs from a MeshRelation. If I do an operation that does nothing to the manifold (like translating by 0,0,0) and convert the manifold back to a mesh with restored vertex attributes, then the barycentric coordinates aren't warped:

However, if I do the same thing with an operation that modifies the manifold, then the barycentric coordinates are warped, resulting in UV artifacts:

This only happens for high UV values. In the screenshots, the U values are in the 0-1 range, but the V values are in the 18-19 range (due to repeating textures), suggesting that these issues are being created due to low precision

[elalish]

I think we'll need a more complete repro to see what's going on. I'm working on an example for restoring UVs right now, so we'll see if I run into this. That doesn't really look like rounding error to me, especially the duplicated 0.1.

[rafern]

I think you're right, something else is going on. I found a seam at the beginning where UV values are in the 0-1 range, and the vertex normals also have seams when there is a seam in the UVs:

The seams also appear when I'm doing an operation that does nothing, and using the MeshRelation to get the UVs and normals back.

Hopefully I'm not wasting your time because this is a bug on my end, but if you need a project to debug this, or don't want to start from scratch for the UVs example, the project is now open-source at playkostudios/manifold-wle and playkostudios/manifold-wle-example. The project is written for Wonderland Engine instead of Three.js though.

[elalish]

I don't think I'll go so far as to debug your code. :) If you could turn this into a minimal repro, ideally into a test case for either our C++ or JS suites, that would be very helpful. My guess is the bug is on your side, but there might be something going on with our edge collapse?

[rafern]

I'll make a JS test either this week or next week and come back to this issue.

[rafern]

@elalish I modified your incomplete three-texture example and it also has the issue I found on my project. You can find the files here: https://gist.github.com/rafern/79daa30a9cc686ba4a13398513bb32ae.

Expected (note the seam in the middle, this is intentional):

Actual restored UVs (note that the seam is now gone, which is not the correct behaviour):

It's as if the barycentric coordinates turn the UVs of the trapezoid into a sheared cube, but the positions restore correctly.

I also noticed that the barycentric coordinates of a side's square are always relative to a single triangle instead of both triangles, which is probably the cause of the bug.

I didn't add normals to the example, but they are also wrong on my other project, so I'm assuming normals are also affected by this bug.

[elalish]

Great example, thank you! Did you supply your UVs as properties with appropriate tolerance? See the constructor docs. Manifold is assuming these triangles form a single face, but that's only true if the properties are all coplanar, which your UVs are not. It should do the right thing with the right inputs, but if not, it's a bug.

[rafern]

I didn't know that API existed, and it turns out that the its missing in the JS bindings! I made a new version with dummy triProperties, properties and propertyTolerance, where the original UVs are not supplied, but different values are supplied for each vertex (vertex 5 has property value 5, vertex i has property value i), and a tolerance of 1e-5 is used, so that each triangle is forced to not be merged. This completely fixed the issue, thanks for the help!

Updated gist: https://gist.github.com/rafern/3dc95ebd8b611da5eb8dd4ab64ce9f26

I've opened a PR for the missing API: #291.