uv is NaN at certain indices on the simplified mesh

[Hariharasudhan Gunasekaran]

Description
Using this to simplify a procedural created mesh. The mesh is simplified correctly. But the uv values at certain indices is NaN. Because of this texture is not applied properly.

I tried to debug, but could not find exactly where the uv is set once the mesh is simplified after each iteration.

To Reproduce
https://drive.google.com/file/d/1PyZMOA9543x4F1wod-0NUtHv0ZRUPdSH/view?usp=sharing

1. Download and extract the above
2. Place the Model.fbx in the scene
3. Simplify the mesh in the model (Attached the script I used)
4. Try applying the texture "Green_square" attached to the model with standard shader after simplification

[Hariharasudhan Gunasekaran]

Temporary fix

Placing the below snipped at the start of each iteration in SimplifyMesh() method

           for (int i = 0; i < vertUV2D[0].Length; i++)
            {
                if (float.IsNaN(vertUV2D[0][i].x))
                {
                    Debug.Log(iteration);
                    int j = 0;

                    while (float.IsNaN(vertUV2D[0][i].x))
                    {
                        vertUV2D[0][i] = vertUV2D[0][i - j];
                        j++;
                    }

                }
            }

[Mattias Edlund]

Hi @Harti177,

I have looked into this a bit more. As far as I can tell there is one triangle (that seems to appear in the second iteration) that is almost degenerate, and pretty much a segment.

See the vertices here:

a   582                   -16.6275024414063   204
b   582.000000000004      -16.6175003051758   201.999999999998
c   582                   -16.6175003051758   202

As you can see b and c is nearly identical here with a very tiny distance inbetween.

This leads to a faulty denominator that is zero which results in divisions by zero, and we have introduced NaN. It all happens when calculating the barycentric coords for interpolating the vertex attributes. Even changing from floats to doubles still had the same problem.

I have locally worked around this by preventing the denominator from being zero, and replacing it with a small enough denominator to not cause division by zero or the v and w from becoming infinite and causing u to become NaN. But I'm not sure if this is a problem with your mesh or if the algorithm produces this degenerate triangle (since it appears in the second iteration).

I'll see if I can confirm this being a problem with the mesh itself, because I feel reluctant to add the denominator "fix", since I'm not sure if I'll introduce other problems this way.

But again, it appears to be just one single triangle causing this issue. But that could also just be me since different processors could produce different results with floating-point values these tiny.

[Mattias Edlund]

I just confirmed that this is not a problem with your mesh, not even close.
I'll see what I can do, and get back to you again.

[Mattias Edlund]

@Harti177, I have created a pull request with a fix. Thinking about it, I don't think it should be too much of a problem since the problematic triangles are almost not even triangles anymore. Please try out the branch from this pull request and let me know if it fixes the problem on your end as well: #44

[Hariharasudhan Gunasekaran]

@Whinarn The issue is resolved with this https://github.com/Whinarn/UnityMeshSimplifier/pull/44
Thanks for the support!

[Mattias Edlund]

Thank you for confirming!
I have merged the pull request now, so a new version will be available shortly.
Thanks for reporting this issue 👍