Degenerate triangles or wired triangles (wrong topology) generated

[fengliancanxue]

trafficstars

Hi, when I use meshoptimizer to optimize terrain, it generated Degenerate triangles or wired triangles (wrong topology, original is regular 2d grid), Is this an known issue?

[zeux]

This is probably the same as #346, but it would help if you could attach the example mesh before the simplification (eg in .obj format) as well as simplification parameters to make sure this is fixed.

[fengliancanxue]

Thanks for your reply, version: version 0.15 cmd: gltfpack.exe -si 0.2 -i ./TerrainTest.obj -o ./TerrainSimplified.gltf TerrainTest.zip real world case: I slightly modified the code to support edge locks and use error instead of target triangle num to simplify mesh.

[zeux]

Oh, I didn't realize you're using 0.15. Since 0.16 meshopt_simplify tries to prevent triangle flips, and since 0.18 it also has an option to lock edges - you might be able to upgrade to 0.18 to resolve these? If you want to simplify to the largest degree possible within a given error you can simply pass target_index_count = 0.

[fengliancanxue]

I tried using the new version, using the same input, the result is quite different, it looks like the error is magnified a lot. and yes, the target_index_count is set to 0, and use error only.

[fengliancanxue]

Oh, I didn't realize you're using 0.15. Since 0.16 meshopt_simplify tries to prevent triangle flips, and since 0.18 it also has an option to lock edges - you might be able to upgrade to 0.18 to resolve these? If you want to simplify to the largest degree possible within a given error you can simply pass target_index_count = 0.

Use ver 0.18, the test obj result is much better, but there are still weird triangles

[vtroxi]

Hi, I am having the same issue when simplifying a grid-like mesh to half its triangle count (border locking enabled). Some triangles seem to get flipped while other triangles are generated out of nowhere, causing z-fighting. Is there any progress on this issue? I am using the latest version. I can also provide an obj file for reference.

[zeux]

@vtroxi If you can provide an .obj file that would help make sure that a fix for this fixes all known instances of the problem.

[vtroxi]

@zeux Thanks for looking into the issue! I have created a small repository that should contain all files necessary to replicate the issue: https://github.com/vtroxi/meshoptimizer-bug

[zeux]

Great, thanks! The problem in this specific scene seems to be that the triangle can be flipped in two stages - first by getting collapsed to a degenerate triangle (normal = 0), second by moving one of the resulting vertices basically anywhere. In both cases the dot product hasTriangleFlips computes at the end is exactly zero, so it returns false. On your scene the problem is fixed by changing < to <= in condition return nbc.x * nbd.x + nbc.y * nbd.y + nbc.z * nbd.z < 0;.

I will need to look at other examples here to see if this improves them. The "perfect" solution likely requires adjusting the predicate in a more complicated way but that could wait if the simple fix improves the situation without regressing anything.

[zeux]

On the original example scene in this issue the fix also helps although one triangle still gets flipped.

Before (view from below the mesh):

After:

[zeux]

The example in the issue #346 requires a more complex fix to hasTriangleFlip which effectively involves restricting the triangle movement somewhat more severely than we do now, and that involves additional computations. I think I might close this issue with the simple fix and use the other issue to track the more complex one.

[zeux]

Future improvements to this will be tracked as part of #346 that has a couple examples that don't get fixed by the simple tweak.