-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sometimes vertices receive NaN coordinates during shape transfer. #2
Comments
I m on my phone, not at my pc atm. I see that 4 lines from There is a line that says And then in the next lines we divide by a. What if you add something after
That way we never divide by 0 |
Yep, that i did tried. This way, affected verts don't get assigned illegal coordinates, but instead just collapse to some point. At least they can be manually put in place this way, but still. Although that might be just an issue with these particular models. Now that i actually looked at them closely, UVs in affected areas are a bit of a mess, with overlaps and some of the triangles squished to a line. |
I had this issue and it occurs with UV islands that have a size of 0. Very annoying but preventable with documentation. |
For those who encounter such a problem, there is a way to solve this problem, although not very convenient, but it seems to work. If you have encountered vertexes with “-nan(ind)” as coordinates when shape keys are switched on, try the following: To understand which areas are not transferred normally we make a temporary duplicate of the geometry “dup_tmp” and transfer all shape keys and drivers to it. Then apply the Subdivision Surface modifier to the object - this will increase the size of holes if they exist. Just in case, we can change the pose a little bit to include more drivers and areas to be included in the deformation. Some areas may not be visible visually. So we go to edit_mode, select all vertexes and try to rotate the viewport. If the viewport flies to the origin or somewhere out in outer space, then the problem areas are present. That's quite a lot of manipulation with not always a guaranteed end result. And instead of solving the problem by pressing one button, I had to spend almost a week on inventing such a broken bicycle. The end user doesn't always have the ability to just pick up and edit UV maps. So of course I would like to see some solution to this problem in future versions of this plugin. |
This happens to me sometimes when i use shape transfer based on UV map, in cases where the mesh is reasonably dense. Some vertices might end up with NaN for coordinates, which effectively makes them disappear from viewport, making it impossible to select and move them manually.
I tried to look at the code myself, and i think the bug occurs somewhere in get_barycentric_coords method, particularly in:
main_triangle_areas = np.cross((triangles[:, 0] - triangles[:, 1]), (triangles[:, 0] - triangles[:, 2]))
where, i think, some values end up being 0, and then division by 0 ends up happening later down. But i don't really understand this code, and can't fix it myself.
I'll attach a file with two meshes which you can replicate the bug with.
example.zip
The text was updated successfully, but these errors were encountered: