Esoteric Software

[mugathur]

I'm currently having an issue where I have a character who loses a triangle of itself during certain frames of animation.

I've turned the image into a black square and uploaded the image to show what it looks like. It should be a black square rather than a black square with a triangle cut out of it.

Here are the interesting pieces of information
- It looks fine in the Spine Editor
- The image is attached to a slot that has other attachments that are meshes
- If I untick the "RenderMeshes" option on the SkeletonAnimation, the triangle doesn't disappear (but obviously all my meshes disappear)

Any ideas?

Obviously happy to send the file (or a simplified one) over for debugging.

[Pharan]

Can you share the simplified files?

Could you guess if there's something usual/special about your setup or skeleton?

I've seen people report weird triangles disappearing every now and then (like months apart) but I've never experienced it happening to my own projects.

[mugathur]

I've attached the spine file with the export output.

The animation in question is the only one in the file: attack_right

The only thing that jumps out to me as odd is that there is a single slot with two attachments, one of which is a mesh and the other is an image. I was about to say everything else looks normal, but at this point, there is no "everything else." Ha ha.

Let me know if I can do anything else to help.

[Pharan]

The mesh looks like a regular quad to me.
A missing triangle here should end up looking like a black triangle. Not that weird square pacman thing in the screenshot.

This looks like a runtime bug. I'll try to check what's up.

[mugathur]

Thanks. Sorry if I wasn't clear. It looks fine in spine. It looks fine in the non-running Unity editor. When I hit play in Unity, though, it looks like PacMan on some frames (but not all of them).

[Pharan]

I think I've found the problem. It's different from the problem other people had before since this only happens at runtime.

There were some relatively recent changes to SkeletonRenderer that made some assumptions that weren't reliable.

Short-term fixes for you:
Either add one vertex to your Mesh.
or
replace this line in SkeletonRenderer.cs : https://github.com/EsotericSoftware/spine-runtimes/blob/master/spine-unity/Assets/spine-unity/SkeletonRenderer.cs#L270
with

bool mustUpdateMeshStructure = true; //CheckIfMustUpdateMeshStructure(attachmentsTriangleCountTemp, attachmentsFlipStateTemp, addSubmeshArgumentsTemp);

The basic problem is that the renderer is optimizing updates by not refreshing the mesh structure when it doesn't detect "changes". Your current setup : a slot switching between a 4-vertex region and a 4-vertex mesh, (with the same number of vertices but different triangle definitions) fools it into thinking those two attachments are the same thing.

Fix #1 will make it so that it will detect the change in vertices. Fix #2 will force it to update the mesh structure every frame (this will fix it reliably, but has a performance cost). I recommend Fix #1. But use Fix#2 if you can't be bothered to update/re export too many Spine projects at the moment.

[mugathur]

Ha ha.

I'll set mustUpdateMeshStructure to true for now. It actually solves another issue I'm dealing with right now as well. (sometimes my submeshes have the wrong material for a frame).

Thanks.

[Pharan]

Thanks for reporting this. Stay tuned for the official fix.

What was that other bug you were having?

[mugathur]

Sorry. I was going to write another thread for it this morning, but I'll just add it here.

We are seeing a one-frame flicker on some of our submeshes where that particular submesh is referencing the wrong material (our atlas is spread over two materials). I had previously put in a hack by changing
https://github.com/EsotericSoftware/spine-runtimes/blob/master/spine-unity/Assets/spine-unity/SkeletonRenderer.cs#L271

to

if (true) {

It sounds similar to this reported issue:
Flickering and a solution for it

But it wasn't the triangles that were at fault in our situation, but the materials.

The situation for reproducing this issue is much more involved than the previous issue I reported, so it'd be a lot harder to send over a test case. Sorry.

[Pharan]

That's ok. Whatever info on it you can give is helpful.

I guess it was the same bug though. Or at least generally stemming from the same code.