forceSharedVertices after convertToFlatShadedMesh is rearranging vertices (indexes?)

Starting with a mesh from BABYLON.MeshBuilder.CreatePolyhedron and applying a StandardMaterial.

If I initially use forceSharedVertices(), it looks great, rounded as expected. If I then use convertToFlatShadedMesh(), it also looks great, flat as expected. If I then use forceSharedVertices() again, I see many reversed facets and new facets connecting vertices across the mesh. If I use convertToFlatShadedMesh() again, it looks correct and flat again.

I think forceSharedVertices() is messing up the indexes somehow.

It might be an issue with thresholds. Can you please make a small playground repro?

It’s not showing the same as my scene (meshes crossing the interior), but it is still wierd (surface meshes missing).

This is the problem:

    console.log(polyArray[3].isUnIndexed) // false
    console.log(polyArray[3].isUnIndexed) // false
    console.log(polyArray[3].isUnIndexed) // true
    console.log(polyArray[3].isUnIndexed) // true


Both convertToUnIndexedMesh() and convertToFlatShadedMesh() appear to be doing similar things, so I created a private function, _convertToUnIndexedMesh(), to be used by both.

It may be related.

To see some of the behavior, I printed out the positionData, indices, and the “effective” position data (positions referenced by indices). I think I’ve noticed when using forceShared that some facets flipped (exchanging vertices within a facet) and some cross the interior (exchanging vertices between facets). Because executing convertToFlat seems to reset the mesh, I surmise that forceShared only messes up the indices.

I’ve looked into the source code for unindexed and I think it sets the private boolean, but still has (or creates?) indices with values 0->n-1. There appear to be other methods that rely on indices, and some cases where unindexed boolean is ignored, such that indices are expected even when the boolean is true. This, I think, causes some methods to fail on unindexed positions depending on whether indices are actually defined or not.

These are suspicions of mine: I don’t have examples, and so are not actionable at the moment. I’ve been playing around with each of the functions that modify a meshes VertexData and have noticed occasional odd behavior with convex polyhedra (i.e. meshes without line facets and without repeated vertices in a facet).

I’m hoping it’s reasonable that the various VertexData manipulation methods operate on a convex polyhedron such that they can be executed repeatedly in any order and the last method prevails. I don’t expect that unindexed or indexed is unchanged, but the mesh vertex positions should be interpreted as (close to) identical, with the facets and winding being the same.

I’ve listed the methods I’m playing around with here.