@dodos In the 4.2 runtime, the Apply Additive Material property is automatically set when the Atlas Texture Settings preset is a straight alpha preset, so when not using PMA atlas textures as workflow.

Upon readin this code again this might be an incorrect decision, perhaps due to confusion of PMA atlas textures vs PMA vertex color. I'll investigate whether there are indeed implicit limitations imposed by e.g. Linear color space which make this setting legit, or whether it's just a mistake. I'll get back to you here on the forum once I've figured it out.

thanik_lab spine-csharp Runtime 4.3.2
spine-unity Runtime 4.2.107

Was this a typo? Please note that mixing spine-unity and spine-csharp minor versions 4.3 and 4.2 is not supported and may lead to undefined behaviour.

@zepht We have added an official parameter to the BoneFollower components. From the changelog:

• Added option to BoneFollower components to follow attachment Z spacing offset. The Inspector component property can be found under Follow Z Position - Attachment Z Spacing. Defaults to false to maintain existing behaviour.

A new spine-unity 4.2 unitypackage is available for download:
https://esotericsoftware.com/spine-unity-download
Please let us know if this resolves the issue on your end as well. Thanks for reporting.

@AHAKuo This is a known issue, and was mainly a limitation due to what the animation asset can store. We have however just pushed a fix for the issue by using the object reference value as fallback solution, which won't clash with user values either (we can't set int or float parameters to a sentinel value, as a value of 0 might be unser or a deliberately set value, read by user code).

A new spine-unity 4.2 unitypackage is available for download:
https://esotericsoftware.com/spine-unity-download
Please let us know if this resolves the issue on your end as well. Thanks for reporting.

Glad to hear you've found a solution, thanks for letting us know!

Note that you actually don't need to modify SkeletonRenderer but could instead access skeletonRenderer.zSpacing from BoneFollower or your own custom BoneFollower subclass. This way you don't have to modify the runtime.

Glad it helped, thanks for letting us know!

Thanks also for explaining your use case why you need to set the RGB color programmatically.

As you mentioned flashing red: Please note that this is typically done via tint-black slot color (secondary, dark color) instead of using the primary (light) slot color.

Yes, you can iterate over IEnumerable<Material> Materials of skeletonRenderer.SkeletonDataAsset.atlasAssets[0].

@FattyJoker Glad it helped.

@FattyJoker Likely you'll want to reset any physics movement after immediate changes or teleportation:

PhysicsConstraint[] physicsConstraints = skeleton.PhysicsConstraints.Items;
for (int i = 0, n = skeleton.physicsConstraints.Count; i < n; i++)
    physicsConstraints[i].Reset();

You're double-posted the same question, perhaps to trigger Spinebot again. Let's continue the discussion over at the other thread.

@zf3d Thanks very much for sharing the additional details. It makes sense that deleting the referenced target skeleton invalidates those references. We have added null checks to both BoneFollower and BoneFollowerGraphic on the 4.2 and 4.3-beta branches.

New spine-unity 4.2 and 4.3-beta unitypackages are available for download:
https://esotericsoftware.com/spine-unity-download
Thanks for reporting!

This issue has been tracked under this issue ticket URL:
EsotericSoftware/spine-runtimes2903

@zf3d Sorry to hear you've having troubles. Unfortunately I could not reproduce this issue, neither in the Unity Editor in Play Mode, nor in a build. Also trying all Project Settings - Editor - Enter Play Mode Setting variants did not reproduce the issue on our end. Are you using the latest version of the spine-unity 4.2 or 4.3-beta runtime?

Could you perhaps create a minimal Unity project that still shows this issue? You can send it as a zip file to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at what's going wrong.

zf3d SceneManager.sceneLoaded += 新场景加载完成处理;

Could you please describe how the sceneLoaded callback is relevant in this regard? How does it contribute to making the problem appear?

nibya In the end, we hadn’t yet tried point 6 mentioned by Spinebot, but we successfully customized the update cycle accordingly.

However, while this reduced the load from the SkeletonAnimation.Update logic, the LateUpdate still imposes a significant performance cost. We understand this is due to the structural limitations of the SkeletonRenderer component.

Why would LateUpdate, which covers updating the mesh, impose a significant cost? If it does, you likely have misconfigured your setup. See the Other Examples/FixedTimestepUpdates example scene, component SkeletonAnimationFixedTimestep.

gunspike You can send us a minimal Unity project with just the relevant parts to reproduce your issue, then we can have a look at what's going wrong. You can send it as a zip file to contact@esotericsoftware.com, briefly mentioning this forum URL so that we know the context. Then we can have a look at it. Please also include the original Spine project (including the attachment image directory) in the package so that we can compare it more easily.

gunspike After switching Spine's color space to Linear, I noticed that the animation looks different compared to when it was in Gamma.
I'll revise the animation accordingly.

Yes, if it looked the same there would be no such viewport option.

Please note that alpha blending in Linear color space behaves quite different compared to Gamma space, some might say it behaves in a rather unintuitive way. That is why we suggest using Gamma space in Unity unless you have good reasons to use Linear color space.

gunspike All slots (normal + additive) are rendered using a single material, so additive blending does not appear correctly.

This is a false assumption, when Advanced - PMA Vertex Colors is enabled, an additive slot does not require separate materials. This also applies to SkeletonRenderer. What is your SkeletonDataAsset Blend Mode Materials configuration regarding Additive blend mode?

gunspike Root Cause (Suspected)
SkeletonGraphic uses only one material at runtime, so multiple blend modes cannot be expressed simultaneously.

Additive blending needs a dedicated material or render pass, which SkeletonRenderer provides, but SkeletonGraphic does not.

See above. In general, in the most recent spine-unity 4.1, blend modes should be covered automatically at SkeletonGraphic already. What are your SkeletonGraphic Inspector component settings under Advanced with Multiple CanvasRenderers enabled under Blend Mode Materials? Do you see a Blend Mode Materials subsection at all when enabling Multiple CanvasRenderers?

gunspike Suggested Feature
Provide a mechanism for SkeletonGraphic to:

Automatically split slots based on blend mode (like SkeletonRenderer)

OR allow assigning multiple materials (per blend mode) to SkeletonGraphic, either via slot detection or material override.

No need to suggest a feature that already exists for quite some time . If blend mode detection fails for some reason, that would be a bug then.

@nibya Misaki and Spinebot already listed the most important points. In addition to that, you might want to consider the following:

1. RenderExistingMesh:. Given that your mosters likely look and move in a very similar way, instead of updating every Nth frame, you could also use the RenderExistingMesh component to copy the already animated mesh of another skeleton, saving both the Update and LateUpdate cost. This might be quite feasible if you have e.g. 20 instances of the same skeleton type just playing a move-animation, you then might get by having only 3 - 5 different truly animated skeletons and let the rest be copies of the original ones via RenderExistingMesh. This should bring quite a dramatic improvement on lowering the LateUpdate and Update cost.

2. Parallelization / Threading: This feature ticket (currently in progress) will cover providing automatic parallelization infrastructure where you can utilize multiple threads with your skeleton components at the switch of an option. While it's not completed and released yet, the implementation is almost done, some cleanup and consolidation is still in progress. This will be a really handy "free" optimization.

Apart from that, let me emphasize again that optimizing the bullet points mentioned by Misaki and Spinebot (keeping the metrics as efficient as possible) will pay off a lot.

@fshakhverdiyev Glad it helped, thanks for getting back to us. It's totally understandable, sometimes a workaround has to do.

@fshakhverdiyev Thanks for sending the reproduction project. The problem is that you are using skin bones incorrectly. The to-be-hidden attachment is a normal mesh attachment at a normal bone instead of a skin placeholder:

All bones of the mesh attachment in the weights view are indeed skin-bones which are associated with the respective skin, but this is not how skin-bones work. Bones can be assigned to skins, becoming skin bones, to save performance by automatically disabling the bone calculations when the skin is not active, and make the rig setup a clearer by hiding them in the Spine Editor. You seem to expect it to be the other way round, hiding attachments via skin bones, but it's the attachment (skin placeholder) which hides bones.

Unfortunately it behaves slightly differently in the editor than on the runtime side, hiding the respective attachment as you would like it to look, making your incorrect setup seem to work correctly.

Sorry to hear you're having troubles.

What exact spine-unity runtime version (name of the unitypackage, also listed in Assets/Spine/version.txt or in the Package Manager) are you using?

cimmen 几十个皮肤的spine文件导出超过1个小时，是正常的吗？
Is it normal to export spine files of dozens of skins for more than 1 hour?

Given reasonable hardware, that's not normal, no. What are the metrics (see here) of your skeleton to be exported?