[Unity] detecting dirty MeshAttachment arrangement

Pharan

Unity SkeletonCompoenent has an impending implementation issue:
("impending" because it concerns MeshAttachments)

The current SkeletonComponent detects a requirement to update its mesh triangle indexes when it detects either:
(1) a change in the value of the first triangle index of the mesh or <

(honestly don't quite get this one)
(2) when the number of triangles changes.

This seems to me like it'll work well as long as we're just drawing RegionAttachments. RegionAttachments have predetermined triangle index orders. Meanwhile, the order of the vertices and uvs values change every update.

When you put MeshAttachments into the mix, and mesh attachments change in, say, draw order or a slot swapped a MeshAttachment, there is an easily fulfillable condition where the two checks can fail:
(1) no change in first triangle index
(2) no change in number of triangles

So what'd be a good way to detect these changes?

Though honestly, how costly would it be to just update the triangle index array without checking?
Assuming the ability to detect if the triangle index array is large enough and only allocate when needed is working fine.

Nate

SkeletonComponent is nice and tricky eh? Avoiding allocation with Unity is a huge bitch. 🙁

1) Look at how indexes are calculated:

for (int i = 0; i < indexCount; i += 6, vertexIndex += 4) {
	indexes[i] = vertexIndex;
	indexes[i + 1] = vertexIndex + 2;
	indexes[i + 2] = vertexIndex + 1;
	indexes[i + 3] = vertexIndex + 2;
	indexes[i + 4] = vertexIndex + 3;
	indexes[i + 5] = vertexIndex + 1;
}

For regions which are quads, it is always the same order, but it is based on the vertex. If the first vertex in the index list is already for the vertex we need it to be, there is no reason to compute all the indexes again

they are already as we need.

2) The number of triangles can change, but only for the last submesh. This is because we can write zeros so we have degenerate triangles which should be skipped by the GPU. The idea is that this is cheaper than allocating a new array.

Computing indexes isn't really a big deal, though if it is cheap to avoid it, why not. Uploading triangle indexes to the GPU is wasteful if they don't need to be updated. It probably makes the most sense to have multiple renderers:

1) For drawing from a single material, no submesh nonsense. The indexes are computed when the vertices array is allocated and then never changed. In normal OpenGL land the indexes can be uploaded to the GPU and never changed, ideally this can be done in Unity. The code gets a lot simpler, like it used to be.

2) For drawing from multiple materials, basically the submesh stuff we have now. Indexes are updated every frame. No way around it, this is the same thing PolygonSpriteBatch in libgdx does. Maybe the existing optimizations can be kept, eg by flagging a submesh as containing a mesh attachment. If it doesn't, assume the indices are in order and can be reused for region attachments. Maybe this isn't worth it.

Pharan

I think the problem stays the same even if there's only one "submesh"/material.

The triangle indexes will need to change whenever the draw order or mesh attachment changes because the meshes use an arbitrary number of vertices and arbitrarily arranged triangles. They disrupt the regular order of 4 vertices and 6 triangle indexes per quad in a set order.

The problem is detecting a change when the number of vertices and the number of indexes stay the same. This is in the hypothetical but possibly quite common situation where you swap between two meshes that have the same number of vertices and the same number of triangles. And also when these meshes change in draw order.

I vaguely recognize a potential for using events, but that might make things messy.

For now, I'm inclined to make SkeletonComponent a bit less agnostic/universal and give it a bool or an enum that I can switch to go one way or the other. For simple/stable stuff where there won't be any MeshAttachment swapping or draw order keys, I can keep the current dumb detection which will work perfectly fine. And it can have a mode that updates the indexes every frame for when the animation is just simply too complicated. And maybe it'll have some mode in between.

I guess we can let this conundrum percolate until we find a better solution, especially if we're not sure the performance gains of the most obvious solution is worth the code. Maybe there's an elegant solution we don't know of yet.

Nate

You missed this part?

Nate ：
2) For drawing from multiple materials, basically the submesh stuff we have now. Indexes are updated every frame. No way around it, this is the same thing PolygonSpriteBatch in libgdx does. Maybe the existing optimizations can be kept, eg by flagging a submesh as containing a mesh attachment. If it doesn't, assume the indices are in order and can be reused for region attachments. Maybe this isn't worth it.

With this, we send indexes to the GPU every frame (as we do now). Whether we compute them every frame or try to reuse indexes we already have is separate and less of a big deal.

Pharan

Ah, thanks for emphasizing, Nate!
Now that I think about it, it did have that part in Update where it assigns the index array to mesh.triangles again. I suppose that also means Unity sends that to the GPU right there, regardless.

Nate

Aye, who knows what Unity-the-black-box does. 🙁 The docs don't tell what happens if we do or don't set mesh.triangles each frame.