CombineMeshes losing vertices.

I am getting stuck after combining meshes adding boneweights because the vertex arrays are different sizes. I am debugging the boneweights arrays of each individual skinnedMeshRenderer before adding them to a combineInstance, and debugging the vertex arrays as well. Then, after making the combine instances, I am debugging their count, then looping through and adding up the vertex count of the meshes in each combine instance just to be sure. You can see they are the same.
Then the combine instance runs, and I debug the vertex count on the result mesh. I am losing 192 vertices, which is no combination of the vertices of some of the meshes in the combineInstances. (They all have at least 125).

This was working with 5 skinnedMeshRenderers as I was building and testing it, adding up to about 500 vertices. I have 9 smr’s now with as you can see about 8k verts. Is this a known bug?

Narrowed it to a few meshes. Here’s the same debug with three offending meshes removed. There is nothing to indicate why these are offending.

This is a character with multiple parts and for some reason the head mesh and teeth are the ones losing vertices, the body, clothes, accessories, all are fine, same FBX… I guess time to go into Maya and see what the hell is going on here.

Fixed the problem by exporting my fbx as obj, reimporting the OBJ to Maya, exporting to FBX to Unity and running again. I really hate how there can be something wrong with a mesh that doesn’t show up in the inspector!

Hi,

I have found the reason for this issue (I was having the same problem and I cannot export to an external editor the models)

It seems that the root cause for this error is that CombineMeshes method combines meshes taking into account submeshes. I imagine that when a model is imported / exported from editor, all submeshes may be joined on a unique submesh, allowing the method to work properly.

A possible workarround solution for this issue, consists on defining on the CombineInstance array, multiple time (one per each submesh of the mesh to be merged) the same mesh and define for each of this CombineInstance element the submesh index (at least it works for me):

   public static CombineInstance[] CombineArray(GameObject obj)
   {
      MeshFilter[] meshFilters = obj.GetComponentsInChildren<MeshFilter>();
      SkinnedMeshRenderer[] skinnedMeshFilters = obj.GetComponentsInChildren<SkinnedMeshRenderer>();

      int combineLength = 0;

      for (int j = 0; j < meshFilters.Length; j++)
      {
         combineLength += meshFilters[j].sharedMesh.subMeshCount;
      }

      for (int j = 0; j < skinnedMeshFilters.Length; j++)
      {
         combineLength += skinnedMeshFilters[j].sharedMesh.subMeshCount;
      }

      CombineInstance[] combine = new CombineInstance[combineLength];

      int i = 0;

      for (int j = 0;  j < skinnedMeshFilters.Length; j++)
      {
         Mesh mesh = new Mesh();
         skinnedMeshFilters[j].BakeMesh(mesh);
         mesh.name = skinnedMeshFilters[j].name;

         for (int subMeshIndex = 0; subMeshIndex < mesh.subMeshCount; subMeshIndex++)
         {
            combine[i].mesh = mesh;
            combine[i].transform = skinnedMeshFilters[j].transform.localToWorldMatrix;
            combine[i].subMeshIndex = subMeshIndex;

            i++;
         }
      }

      for (int j = 0; j < meshFilters.Length; j++)
      {
         for (int subMeshIndex = 0; subMeshIndex < meshFilters[j].mesh.subMeshCount; subMeshIndex++)
         {
            combine[i].mesh = meshFilters[j].mesh;
            combine[i].transform = meshFilters[j].transform.localToWorldMatrix;
            combine[i].subMeshIndex = subMeshIndex;

            i++;
         }
      }

      return combine;
   }

   public static Mesh Combine(GameObject obj)
   {
      Mesh result = new Mesh();
      result.CombineMeshes(CombineArray(obj));
      return result;
   }

Hello,

I’m having the same problem. @Steamc0re_1 - the meshes that failed for you. Were they using multiple materials per piece? Or was this another issue?

In my case this only doesn’t work if I have submeshes per piece but sadly @rayuthebest 's method doesn’t work for me either. If I don’t specify submesh indices I get as expected too few verts in the resulting combine (also the faces with the second material are missing), but if I do, I now have actually too many vertices.

var combineInstances = new List<CombineInstance>();
for (var i = 0; i < skinRenderers.Count; i++)
{
for (int subMeshIndex = 0; subMeshIndex < skinRenderers[i].sharedMesh.subMeshCount; subMeshIndex++)
{
    CombineInstance ci = new CombineInstance();
    ci.mesh = mesh;
    var tris = mesh.GetTriangles(subMeshIndex);
    ci.transform = skinRenderers[i].transform.worldToLocalMatrix;
    ci.subMeshIndex = subMeshIndex;
    combineInstances.Add(ci);
}
}
var newMesh = new Mesh();
newMesh.CombineMeshes(combineInstances.ToArray(), false, false);

No idea what’s going on here…

Here is a very simple project showing the problem.

I have a very simple case, just using 2 cubes
one with multiple submeshes and one without

This works, the combined mesh has the same amount of verts as the input meshes.

when I just subdivide the cubes:

The amount of vertices in the combined mesh is increased by a big amount.
(btw: all this works fine with just one submesh per skinnedmesh renderer)

Looks like a bug to me, I don’t understand why the amount of vertices would need to increase.
Hoping somebody from Unity is seeing this…

seb

5352996–540855–CombineProblem.zip (408 KB)

If I export it back out using the fbx exporter the amount of vertices is correct again:

This was a “known issue” since Unity 5.0f.

Honestly, you should look into using this asset:

to avoid all of your headaches.
The issue doesn’t seem to occur with that asset.

Yes I tested there and indeed, exactly the same amount of verts after combining. I’ll have to test performance (this is for mobile) but to be honest I was really keen to use internal Unity code, hoping that would be more efficient…

Can’t believe that this broken behavior has made it so long - I saw quiet a few threads of it being reported too.
I filed a bug report anyway…