forceSharedVertices after convertToFlatShadedMesh is rearranging vertices (indexes?)

Bugs
1

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.

Screenshot_20240615_122319_Kiwi Browser
Screenshot_20240615_122319_Kiwi Browser1751×1087 186 KB

2

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

3

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

4

This is the problem:

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

Maybe??

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

5

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).

6

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.