Large meshes are split across multiple submesh ids when they should be shared

Description

When large meshes (65k vertices or more) are split, the splits result in new submesh ids, even when the geometry collector layer has not changed.

This results in mappings files like the one below.

In this file bff2f76e-11b4-4c55-a659-7caa3121fc32 should have one entry with multiple usages, but instead there are multiple mappings for the one element. This is not just a mappings issue - the geometry itself has multiple redundant ids.

This appears to cause problems with the rectangle select but the mechanism is not clear at this time. The number of mappings is different from numberOfIDs and maxGeoCount meaning these values cannot be used.

Currently, by chance these are not used in the current version of AssetMapLoaded, which is why this is not causing any issues - the files produced are perfectly consistent, just not as intended.

The likely candidate for the source of the bug is MeshMapReorganiser::performSplitting().

The workaround is simply not to use numberOfIDs or maxGeoCount.

{
    "model": "b17270e2-dd46-452a-a7b9-aa5d0aaab1df",
    "supermeshes": [
        {
            "id": "91792cd0-dc9a-4814-aca0-f4d0546a5442",
            "data": {
                "numberOfIDs": 2,
                "maxGeoCount": 2,
                "mapping": [
                    {
                        "name": "be261ed1-4296-4de9-baf8-b0b756763e2a",
                        "sharedID": "ffd297f4-3de8-4dd0-b246-1061712eb0e5",
                        "min": [
                            119.146484,
                            0,
                            -319.144531
                        ],
                        "max": [
                            319.146484,
                            200,
                            -119.144531
                        ],
                        "usage": [
                            "91792cd0-dc9a-4814-aca0-f4d0546a5442_0"
                        ]
                    },
                    {
                        "name": "bff2f76e-11b4-4c55-a659-7caa3121fc32",
                        "sharedID": "5c555269-6080-4c1a-9e54-e9669977322c",
                        "min": [
                            16.5898438,
                            241.378906,
                            -423.023438
                        ],
                        "max": [
                            421.699219,
                            646.742188,
                            -15.2734375
                        ],
                        "usage": [
                            "91792cd0-dc9a-4814-aca0-f4d0546a5442_1"
                        ]
                    },
                    {
                        "name": "bff2f76e-11b4-4c55-a659-7caa3121fc32",
                        "sharedID": "5c555269-6080-4c1a-9e54-e9669977322c",
                        "min": [
                            16.5898438,
                            241.378906,
                            -423.023438
                        ],
                        "max": [
                            421.699219,
                            646.742188,
                            -15.2734375
                        ],
                        "usage": [
                            "91792cd0-dc9a-4814-aca0-f4d0546a5442_2"
                        ]
                    },
                    ...
                }
            }
        }
    ]
}

This is happening in: both
This requires a hotfix to production: no

Steps to replicate

Import any model with more than 65k vertices
Inspect the supermeshes.json response

Current Behaviour

Where large meshes are split, there are multiple mappings

Expected Behaviour

Where large meshes are split, there is one mapping with multiple usages

3drepo / 3drepobouncer