Wrong Clipping Result When Exporting Multiple Atlas with Clipping Attachments

rita

Problem statement

1) Setting: There is one clipping attachment used. The EndSlot of Clipped Attachments is set to slot.a=0 at first, and then slot.a is transfered to 1.
2) Expected: Slots after the EndSlot shouldn't be clipped.
3) What happened: SLOT_ALPHA_DISABLES_ATTACHMENT is true. In 'MeshGenerator.cs' line 370，if slot.a=0, the slot will not execute next codes. However, that slot is EndSlot, so line490 will never execute since EndSlot is already considered in line 370. So slots after the EndSlot will be clipped due to line490 never execute. If the EndSlot and the slot after EndSlot are using different material, in "MeshGenerator.cs" line551, AddSubmesh function, slots after EndSlot will still be clipped.

Choose example "spineboy", animation "portal"
1)Add key for EndSlot"head-bb", set slot.a=0 from certain time(like in the middle, e.g.42frame), then set slot.a=1 in the end.
2)Change texture packing setting: max height=256, max width=192, output scale=0.5, make sure that there are multiple atlas.

Runtime information

Using spine editor 4.2.35v, spine-unity 4.2v.

Previous submeshInstructions are right and slots after slot39 will not be clipped. Now submeshInstructions are wrong and slots after slot39 will be clipped.

Spinebot

The issue you're experiencing with clipping attachments in Spine when exporting multiple atlases seems to be related to how the MeshGenerator.cs handles the slot.a (alpha) value. Specifically, if the slot.a is set to 0 for the EndSlot, the subsequent slots are not processed correctly, leading to unintended clipping.

Steps to Reproduce:

Use the "spineboy" example and the "portal" animation.
Add a key for the EndSlot "head-bb", set slot.a=0 at a certain frame (e.g., frame 42), and then set slot.a=1 at the end.
Change the texture packing settings to:
- Max height: 256
- Max width: 192
- Output scale: 0.5
Ensure that multiple atlases are generated.

Observations:

The SLOT_ALPHA_DISABLES_ATTACHMENT flag in MeshGenerator.cs causes the EndSlot to be skipped if its alpha is 0.
This results in the slots after the EndSlot being incorrectly clipped because the necessary code in line 490 is never executed.
If the EndSlot and the slot after it use different materials, the AddSubmesh function in line 551 still clips the slots after the EndSlot.

Example Code Adjustment:

You might consider adding a condition to ensure the EndSlot is processed correctly:

if (slot.a == 0 && slot != endSlot) {
    continue;
}

This ensures that the EndSlot is not skipped, allowing the subsequent slots to be processed correctly.

Additional Information:

Spine Editor version: 4.2.35
Spine-Unity version: 4.2

If the problem persists, you might want to share your project files with the support team for a more detailed investigation.

rita

Spinebot Yes. I already changed codes to make this work. However, I wonder if this should be fixed by Spine Official.

Harald

@rita We're sorry for the troubles! Thanks very much for reporting with such a perfect bugreport, much appreciated!

We've just pushed a bugfix for this issue to the 4.2 branch. A new spine-unity 4.2 unitypackage is available for download here:
https://esotericsoftware.com/spine-unity-download

Issue ticket URL for later reference:
EsotericSoftware/spine-runtimes2623

rita

Harald Thanks very much! We've updated codes now.