Hello,

My spine animation mesh only has 2700+ vertices

But when rendering, the submesh takes all the vertex array to do rendering, just like the image shows:

I did lots of attachments replacement for the dress-changing game.

So how could I reduce the count of vertices?

Sorry for the omitted description.

The problem I encountered is all of the submeshes rendered with the full-size vertices array.
Imagine a submesh only has 4 vertices in the shared vertexBuffer, when rendering it will use all the vertices in shared vertexBuffer.
It leads to 20k+ vertices used when rendering a total of 2700+ vertices mesh.

Harald escribió

The main question is: do you really need 37 material or texture switches?
Please have a look at the documentation section here on how to save draw calls, most likely you can pack your atlas pages grouped in a better way:
spine-unity Runtime Documentation: Material Switching and Draw Calls

Yes, our game character has many parts to be replaced and I know material block overriding would break the batching.
Creating atlases for these parts is not a good way in actual practise because of large scale of images.

All DC count is OK for us, the only problem is the vertices count.

According to the phenomena in-game, a DC would send all vertices in shared vertex buffer to GPU separately.

So is there any way to optimize the count?

Harald escribió

I assume this screenshot is captured from the frame debugger, is this correct?

Yes, it's from Frame Debugger

Harald escribió

Strangely we could not reprocduce this behaviour in the frame debugger in either Unity 2017 or Unity 2021, it always shows only the submeshes vertex and index count of a single quad on our local setup. How did you create this screenshot? Which target platform did you take this screenshot from, or is this from the Editor on PC? Is this from a single active skeleton, or perhaps already multiple skeletons being batched?

Maybe you could use these codesTestSpine.cs which implemented the dress-switching feature to reproduce this problem and these codes coming from this forum.

The results show below, after we changed most of slots' attachments, the vertices count is 35k+.

Harald escribió

You could use SkeletonGraphic if you want to test performance of multiple separate meshes instead of a single Mesh with submeshes. Just add a SkeletonGraphic object under a canvas and enable Multiple Canvas Renderers. Then you can compare it to the performance of a single MeshRenderer on SkeletonAnimation.

I did not find an option named Multiple Canvas Renderers, where is it?
And I don't want to use SkeletonGraphic to develop my game main contents, but willing to use it for UI.

Harald escribió

If you still think this will be beneficial, you could create e.g. your own SkeletonAnimation subclass which overrides LateUpdate and creates and fills separate meshes instead of a single mesh, as can be seen here.

I checked the source code of how to fill separate meshes, but the question is how could I set multiple meshes for only one MeshFilter ?

Harald escribió

You should see it in the SkeletonGraphic Inspector under the Advanced section, as described on the documentation pages here:
spine-unity Runtime Documentation: Parameters
In general, please always consult the documentation pages first before asking questions. We wrote them in order to save both you and us the time to repeatedly answer the same questions.
If you don't see this parameter, then you must be using a very old spine-unity runtime.

Yes and sorry about my lazy behaviour, I'm using an old version of Spine supporting v3.8 data and corresponding with 3.8 spine editor.

Harald escribió

I did not suggest to switch your workflow to SkeletonGraphic. I said that you can use SkeletonGraphic to test if performance would be improved or made worse. Otherwise you might likely waste time adjusting code to split meshes just to find out that you have to discard the solution again.

We are using SkeletonAnimation and the problem happens in SkeletonAnimation, besides SkeletonGraphic and SkeletonAnimation's mesh rendering are not same, so I don't want to dig SkeletonGraphic performance results in wasting time. The only thing is I wanna reduce the count of vertices when spine rendering.

Harald escribió

Unity does not allow to assign multiple meshes or vertex buffers at a single MeshFilter or Mesh, neither in the Editor, nor via the API. Please see the text as written in a posting above:

I'm not a newbie in unity, I know how unity mesh filter works, how submesh works and why this issue happens. Why I ask you about how to set multiple meshes to mesh filter is just because I don't understand your suggestion and why you suggest this.

At last, did you test the codes I upload in last post?

Harald escribió

Otherwise you might likely waste time adjusting code to split meshes just to find out that you have to discard the solution again.

I fixed this bug by changing MeshGenerator.cs code:
ORIGINAL:

public void AddSubmesh (SubmeshInstruction instruction, bool updateTriangles = true) {
      var settings = this.settings;

  int newSubmeshCount = submeshIndex + 1;
  if (submeshes.Items.Length < newSubmeshCount)
     submeshes.Resize(newSubmeshCount);
  submeshes.Count = newSubmeshCount;
  var submesh = submeshes.Items[submeshIndex];
  if (submesh == null)
     submeshes.Items[submeshIndex] = submesh = new ExposedList<int>();
  submesh.Clear(false);

FIXED:

public void AddSubmesh (SubmeshInstruction instruction, bool updateTriangles = true) {
      var settings = this.settings;

  int newSubmeshCount = submeshIndex + 1;
  if (submeshes.Items.Length < newSubmeshCount)
     submeshes.Resize(newSubmeshCount);
  submeshes.Count = newSubmeshCount;
  var submesh = submeshes.Items[submeshIndex];
  if (submesh == null)
     submeshes.Items[submeshIndex] = submesh = new ExposedList<int>();
  // when list capacity is too large, clear it!
  if (submesh.Count * 10 < submesh.Capacity)
  {
     submesh.Clear(false);
     submesh.Items = new int[0];
  }
  else submesh.Clear(false);

Performance image shows below:

Just needs to clear buffer's redundancy data, it may lead to GC collection periodically.
Is there a better way to do this?

Harald escribió

I have fixed it a bit differently, using an overloaded Mesh.SetTriangles() method variant that allows to specify a length parameter in addition to the int[] array. You can see it in this commit. This method overload only exists on Unity 2019.3 and newer versions, which Unity version are you using?

If you need to use an older Unity version, you could use the Mesh.SetTriangles(List<int>) overload. Then you would change the line ExposedList<ExposedList<int>> submeshes to ExposedList<List<int>> and adjust the code similarly. This should then avoid some GC overhead.

A new 3.8 unitypackage has just been released, it can be downloaded here as usual:
Spine Unity Download
The bugfix will be merged to the 4.0-beta branch soon.
Please let us know if this resolves the problem for you as well.

For later reference: This issue has been tracked under this issue ticket:
https://github.com/EsotericSoftware/spine-runtimes/issues/1894

We are using the Unity2019.4 LTS version. The new patch works perfectly and nothing wrong found for now, but we will still keep an eye on it for some time.

As this problem has been fixed, it's not necessary to upload a demo project for you to test.

In the end, thanks for your better solution.